c4-model

c4-model

canonical-C4 の LikeC4 モデルを生成します。デフォルトでは Context ビューと Container ビューを作成し、Deployment は任意です。Simon Brown の canonical C4 を逸脱する LikeC4 の機能はすべて拒否します。ここで使用する canonical-C4 の機能は LikeC4 のバージョン間で安定していますが、インストール済みのバージョンで確認するには npx likec4 validate で再検証してください。

このスキルで作成するもの

• 仕様とモデルを含む model.c4 ファイル
• 注目対象の単一システムに範囲を限定した <system>.c4 ファイル
• Context ビューを1つ、Container ビューを1つ（任意で Deployment ビューを1つ）含む views.c4 ファイル
• likec4.config.js ファイル

このスキルで拒否するもの

拒否するもの	理由	アーキテクト向けの代替案
Component ビュー	「Component ビューは、ADR が扱う範囲よりも深いレベルのものです。」	コードレベルの図ツール（例：ソース内の Mermaid）を使用してください。これは C4 の範囲外です。
Dynamic ビュー	シーケンス／ランタイムのフローは canonical C4 ではありません。	別途、シーケンス図ツールを使用してください。
カスタム要素種別	canonical C4 の要素は Person／Software System／Container のみです。	container を使用し、technology 属性に種別を記述してください。
カスタム関係種別	canonical な関係は uses、reads、writes、publishes、consumes です。	最も近い canonical な種別を選んでください。
カスタムスタイル	図はひと目で C4 と認識できる見た目にする必要があります。	canonical であることよりスタイルを重視する場合は、このスキルの範囲外で LikeC4 を直接使用してください。
入れ子のシステム	C4 には Context と Container があります。システムをシステム内に入れ子にすると、各レベルが曖昧になります。	モデルを分割してください。
注目対象の複数システム	.c4 ファイルごとに1つのシステムを記述するのが canonical です。	システムごとに個別のモデルを作成し、externalSystem でリンクしてください。

拒否することがこのスキルの要点です。LikeC4 の自由な機能をすべて使いたいアーキテクトは、このスキルを使用しないでください。

用語

• Actor — C4 用語での Person（人間の役割）です。システム境界の外に描画します。
• 外部システム — チームが所有していないシステムです。システム境界の外に描画します。
• システム — 注目対象となる、境界が定められた単一のプロダクトです。ファイルごとに必ず1つだけです。
• Container — 注目対象のシステム内にある、実行またはデプロイ可能な単位です。コードのクラスではありません。
• 関係 — 1行の説明を伴う有向エッジです。説明は必須です。

厳守事項

1. すべての関係に1行の説明を付けます。 説明がなければ、エッジもありません。
2. 要素名は、ディスカバリーでアーキテクトが確認した名称と一致させます。 翻訳、略記、複数形への変更はしないでください。
3. アーキテクトから明示的な依頼がない限り、スタイルを追加しません。
4. 各 .c4 ファイル内の system 定義は必ず1つだけにします。

固定仕様ブロック

この specification ブロックをそのまま使用してください。編集、拡張、名称変更はしないでください。

specification {
  element actor {
    style {
      shape person
    }
  }
  element externalSystem {
    style {
      color secondary
    }
  }
  element system
  element container

  relationship uses
  relationship reads
  relationship writes
  relationship publishes
  relationship consumes

  tag open-question {
    style {
      color red
      border dashed
    }
  }
}

未解決の質問に関する規約

存在するものの詳細が未解決の要素または関係には、次のように対応します。

• タグ #open-question を追加します
• 説明の先頭に OPEN Q<N>: を付けます。<N> は docs/architecture/open-questions.md の項目番号と一致させます
• スタイルは赤色＋破線で描画され、ひと目でわかります

例：

container payments-service "Payments Service" "OPEN Q7: tech stack unconfirmed" {
  #open-question
}

8つのフェーズ

フェーズ1 — インテーク

docs/architecture/discovery-brief.md に CONFIRMED 要素がある場合は、それをそのまま使用し、再度質問しないでください。そうでない場合は、adr-discovery と同じ手順（1ターンに質問1つ）で、アーキテクトと各要素について1つずつ確認してください。

フェーズ2 — 検索またはひな形の作成

**/*.c4 と **/likec4.config.* を Glob で検索します。次の2つのケースがあります。

• ファイルが存在する場合： ファイルを読み込みます。注目対象のシステムを特定します。アーキテクトが範囲を確認した場合は、既存のモデルに追加します。
• ファイルが存在しない場合： アーキテクトが選択したパス（デフォルトはリポジトリのルートにある likec4/）に、model.c4、<system>.c4、views.c4、likec4.config.js のひな形を作成します。

フェーズ 3 — DSL の生成

model.c4 に次の 3 つのブロックを記述します。

1. 仕様 — 上記のロック済みブロックをそのまま記載します。
2. モデル — アクターと外部システムは最上位に配置し、コンテナーは system ブロック内にネストします。references/likec4-dsl-cheatsheet.md を参照してください。
3. ビュー — views.c4 に、context ビュー（システムとそのアクター、外部システム）、container ビュー（システム内のコンテナー）、および任意で deployment ビューを記述します。

フェーズ 4 — Canonical-C4 リント

検証の前に、次の 11 項目のチェックリストを実行します。

#	チェック項目
1	system 定義がちょうど 1 つである。
2	すべてのコンテナーが、その 1 つのシステム内にネストされている。
3	すべてのアクターが最上位にある（システム内にない）。
4	すべての外部システムが最上位にある。
5	すべてのリレーションシップに空でない説明がある。
6	正規の 5 種類以外のリレーションシップ種別がない。
7	actor、externalSystem、system、container 以外の要素種別がない。
8	ネストされたシステムがない。
9	context、container、deployment 以外のビューがない。
10	仕様ブロックがロック済みブロックと完全に一致している。
11	#open-question タグが付いた要素の説明に、OPEN Q<N>: の接頭辞がないものがない。

違反項目を番号付きリストにして、PASS または FAIL を出力します。FAIL の場合は先に進みません。

フェーズ 5 — 適用せずに差分を表示

提案するファイル変更を、ハンクごとに差分として表示します。ハンクごとに承認を得ます。アーキテクトが承認するまで、ファイルには書き込みません。

フェーズ 6 — 構文を検証

npx likec4 validate を実行します。検証に失敗した場合は、エラーをアーキテクトに提示し、自動修正はしません。

フェーズ 7 — 表示方法を案内

図の表示方法をアーキテクトに伝えます。依頼がない限り、サーバーを起動しません。

To view: npx likec4 start    # interactive browser at http://localhost:5173
To serve: npx likec4 serve   # static export

フェーズ 8 — ドリフトチェック

ADR ディレクトリ（docs/adr/、docs/decisions/、docs/architecture/decisions/、**/adr/*.md。また、旧形式の architecture/decisions/ も確認）を glob で検索します。各 ADR について、テキスト中に記載されたコンポーネント名を LikeC4 モデル内の名前と比較します。名前の不一致は drift 候補として報告し、どちらを正とするかはアーキテクトに判断してもらいます。どちらの側も自動で改名しません。

DSL に関する注意事項

スコープ付きビュー、extend、デプロイメント仕様など、複雑な DSL の質問については、references/likec4-dsl-cheatsheet.md を参照してください。正規の C4 の範囲外の機能については、このスキルで実装せず、アーキテクトに LikeC4 の公式ドキュメントを案内してください。

参考資料

• references/likec4-dsl-cheatsheet.md — 正規の C4 に準拠した LikeC4 DSL の簡易チートシート
• references/canonical-c4-refusals.md — 許可されていない機能についての拒否文例
• adr-discovery スキル — 確認済みの要素とリレーションシップの上流ソース
• adr-critique スキル — ADR とのドリフト検出に使う下流のコンシューマー