本文へ移動
cccskills
無料GitHub で公開

d3-c4-level2-container

C4モデル レベル2(コンテナ図)の新規作成・更新を支援する。対象システムをコンテナに分解し、連携方式を設計して Mermaid で図示する D3 成果物。C4モデル レベル1・レベル1 シーケンスの整備後に呼び出す。

Acceler-Digital/karura
インストール方法を見る

含まれるファイル（2）

  • SKILL.md6.9 KB
  • template.md2.5 KB

SKILL.md（原文）

インストールする前に、エージェントに与えられる指示の中身を確認できます。

D3: C4モデル レベル2(コンテナ)

遵守すべき重要ルール

  1. レベル1 を変えない: 人(ACT-*)・外部システム(EXT-*)・対象システムの境界はレベル1 に従う。過不足があれば本書で辻褄を合わせず、レベル1 の見直し要否をユーザーに確認する。
  2. 未決で残さない: コンテナの分割・連携方式は、ADR に決定があればそれに従い、なければレベル1 シーケンスから設計して埋める。ADR に基づかない箇所には要確認マーカーを付す。
  3. 技術を書かない: 言語・フレームワーク・製品・クラウドサービス・プロトコルの名称は、図にも表にも書かない。
  4. ID を振り直さない: CNT-* はレベル2 シーケンスのライフラインから参照される。採番済みの ID は変えず、欠番も再利用しない。
  5. 画面は SPA と BFF に分ける: 利用者の画面ごとに、ブラウザで動く SPA と、サーバーで動く BFF を別々のコンテナとして置く。
  6. 業務起点で、細かすぎないマイクロサービスにする: 業務サービスは業務の流れを起点に分け、ドメインごとに機械的に分けるほど細かくしない。業務で分けたうえで、データアクセス要件やその他の要件を満たせるかを確かめる。

インプットする成果物

成果物のパス内容
docs/D2.system-requirements/c4-level1-system-context.mdC4モデル レベル1。人・外部システム・対象システム境界の定義元
docs/D2.system-requirements/c4-level1-sequences/**/*.mdC4モデル レベル1 シーケンス。コンテナ・連携方式の設計根拠
docs/D2.system-requirements/adr/**/*.md(想定パス・未作成)ADR。確定済みの設計判断

アウトプットする成果物

成果物のパス内容
docs/D3.system-design/c4-level2-container.mdC4モデル レベル2(コンテナ)

アウトプットに使用するテンプレート

テンプレートのパス内容
.claude/skills/d3-c4-level2-container/template.mdC4モデル レベル2 テンプレート

処理

1. 分岐する

  • docs/D3.system-design/c4-level2-container.md が存在しないなら、§2(新規作成)に進む。
  • それ以外なら、§3(更新)に進む。

2. 新規作成

2.1 上流を読む

レベル1 シーケンスを読み、UC ごとに、操作する人・外部とのやり取り・記録対象・利用者の操作を起点としない処理を控える。もし ADR が存在するなら、承認済みの決定だけを採用する。

2.2 コンテナを設計する

コンテナは独立して実行・デプロイされる単位とし、1 つが止まっても他の業務を続けられるように分ける。

  • 業務処理は、レベル1 シーケンスの工程間の引き渡しを境界に業務サービスへ分ける。同じ手続きの中で結果を待ち合わせる業務は同じサービスに置き、外部サービスへの依頼と結果待ちが続く業務は 1 つのサービスにまとめる
  • 業務サービス間の引き渡しは非同期とし、他の業務サービスを同期で呼ばない
  • 利用者の入口(SPA・BFF)は、一緒に止まってよい業務の利用者ごとに分ける
  • 複数の業務サービスが共通で依存する処理は作らず、担当するサービスに持たせる。もし通知のように業務を止めずに後から処理できるものなら、共通のコンテナに分けてよい
  • 計算負荷の特性が大きく異なる処理は、業務サービスから切り出す
  • 各業務サービスのデータは専有とし、データストアは図に描かない

いずれのコンテナにも割り当たらない UC・人・外部システムが残るなら、分割を見直す。

2.3 連携方式を決める

線は呼び出す側から呼び出される側へ引き、同じ組のやり取りは 1 本にまとめる。もし ADR に決定があるなら、それに従う。そうでないなら、応答を待つ場合は同期、待たない場合は非同期とする。

2.4 図と表を埋める

  • 図は flowchart LR で描く(C4 専用記法は使わない)。人・外部システムの subgraph はレベル1 と同じ括りにする。
  • 名称は、業務サービスは「業務名+サービス」、SPA は「利用者名+用SPA」、BFF は「利用者名+用BFF」とし、業務担当者が読んで分かる語にする。
  • BFF からの線は、その利用者の UC が扱う業務サービスごとに 1 本ずつ引く。
  • 工程間で引き渡しを行う業務サービスは subgraph で囲み、囲みの中の全サービスに共通する線(通知・証跡へのイベント)だけを囲みから 1 本で引く。
  • もし外部システムが対象システムの境界の右に並ばないなら、非表示の線(~~~)で位置を整える。
  • CNT-* は図の上から順に 1 から振る。
  • ノード名と線のラベルは 1 行 12 文字以内で改行し、線のラベルにはやり取りする内容と連携方式を書く。もし ADR に基づかない連携方式や、根拠となる UC が無い線があるなら、図の直後のブロック要確認マーカーにまとめる。
  • 設計根拠列には、ADR に基づくなら ADR の ID、そうでないなら分割の根拠にした UC と特性を書く。
  • sidebars.ts の「D3. システム設計」カテゴリに登録する。

3. 更新

  • 上流(レベル1・レベル1 シーケンス・ADR)で変わった箇所に関わるコンテナと線だけを §2 の手順で見直す。
  • 新しいコンテナには全体の最大値の次の ID を振る。不要になったコンテナは行を削除し、ID を欠番にする。
  • もしコンテナの分割・統合で既存 ID の引き継ぎ先が決まらないなら、ユーザーに確認する。

完成時のセルフチェック

  • 図の ACT-* / EXT-* の集合が、レベル1 §登場要素の集合と一致している
  • レベル1 シーケンスの全 UC-* が、コンテナ表の関連 UC 列に現れている
  • 図のコンテナのノードが、コンテナ表の行と過不足なく対応している
  • ADR に基づかない設計根拠・連携方式に要確認マーカーが付いている
  • CNT-* に重複が無く、更新時は既存の ID とコンテナの対応が変わっていない
  • {{ が残っていない

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

ログインしてレビューを書く

同じリポジトリのスキル

概要と使いどころ

d1-actor-list

無料日本語概要

アクター一覧の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、本システムに関わるすべての人間アクター(関係者)を一覧化する文書。TOGAFのActor Catalog相当。BRDの下流に位置する成果物。後続の成果物であるプロダクト要求仕様書やユーザーストーリー一覧、C4モデルレベル1、C4モデルレベル2、L1シーケンス、L2シーケンスなど、様々な成果物から参照される。BRD策定後、アクター整理の段階で呼び出す。

Acceler-Digital/karura82026年9月26日 更新

d1-business-requirement-document

無料日本語概要

ビジネス要件定義書(BRD)の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)の中でも最上流に位置する成果物であり、ドメイン定義書・プロダクト要求仕様書(PRD)本体・ドメイン要求仕様書群すべての根拠となる業務観点の要求文書。新規プロジェクト立ち上げ時の最初の成果物作成、戦略・スコープの大きな変更、KPI見直しのタイミングで呼び出す。

Acceler-Digital/karura82026年9月26日 更新

d1-domain-common-requirement-document

無料日本語概要

ドメイン共通要求仕様書の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、プロダクト要求仕様書(PRD)が方針・概念を扱うのに対し、本書は **3 ドメイン以上で横断的に効く具体的な要求(水準・方針・原則)** を集約する文書。**ドメイン要求仕様書群(個別)とは並列の関係にあり、横断的な水準・方針・原則は本書が単独で責務を持つ(=厳密な MECE。個別ドメインで言い換えない)。** 機能要求・非機能要求・UI/UX 方針・セキュリティ要求・データアクセス要求・法務/コンプライアンス要求 の各節を持つ。PRD・アクター一覧・ドメイン定義書 を上流とし、PRD策定後、ドメイン要求仕様書群(個別)の作成前に呼び出す。

Acceler-Digital/karura82026年9月26日 更新

d1-domain-definition-document

無料日本語概要

ドメイン定義書の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、本プロダクトを構成する業務領域(ドメイン)を網羅・分類する文書。問題空間(プロダクトが扱う業務領域)の整理であり、DDDにおけるBounded Context(解空間としての実装上の境界)とは別レイヤーで扱う。BRDの下流に位置する成果物。後続のプロダクト要求仕様書、ドメイン要求仕様書群(各ドメインごとに1つ)など、様々な成果物から参照される。BRD策定後、ドメイン整理の段階で呼び出す。

Acceler-Digital/karura82026年9月26日 更新

d1-domain-requirement-document

無料日本語概要

ドメイン要求仕様書の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、プロダクト要求仕様書(PRD)を親文書とし、ドメイン定義書で定義された各ドメインごとに1冊作成される。**ドメイン共通要求仕様書(横断的な水準・方針・原則)とは並列の関係にあり、当該ドメイン固有の業務ルール・業務状態遷移・業務運用(イレギュラー対応)のみを扱う(共通要求と内容が重なる要求は本書に書かない=厳密な MECE)。** PRD・ドメイン定義書の策定後、ドメインごとの業務要求を具体化する段階で呼び出す。下流のユーザーストーリー一覧・ユースケース一覧・機能一覧(D2)・画面要件群(D2)・L1/L2シーケンス図の起点となる。

Acceler-Digital/karura82026年9月26日 更新

d1-product-requirement-document

無料日本語概要

プロダクト要求仕様書(PRD)の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、方針・概念・体験設計・制約・受け入れ基準を扱う文書。具体的な横断要求(機能要求・非機能要求・UI/UX・セキュリティ・法務 等)は独立成果物のドメイン共通要求仕様書に集約し、PRD は要求 ID を持たない。BRD・アクター一覧・ドメイン定義書 を上流とし、BRD策定後、ドメイン共通要求仕様書の作成前に呼び出す。

Acceler-Digital/karura82026年9月26日 更新

Acceler-Digital のスキルをすべて見る

このスキルの問題を報告する