C4 Model

C4 Model とは

C4 Model は、Simon Brown が考案したソフトウェアアーキテクチャの可視化手法である。名前は静的構造図の 4 種 (System Context, Container, Component, Code) の頭文字に由来し、地図を拡大していくように同じシステムを異なる縮尺で描き分ける。UML や ArchiMate のような記法を強制せず、どの抽象レベルで何を描くかという整理だけを与えるため、作図ツールも問わない。

4 つのレベル

レベル	対象読者	描くもの	粒度
C1: System Context	全員 (非技術者含む)	システムと外部アクター	最も粗い
C2: Container	開発チーム	アプリ、DB、メッセージキュー	技術選択が見える
C3: Component	開発者	Container 内部のモジュール群 (同一プロセス空間)	内部構造
C4: Code	開発者	クラス、関数	最も細かい (通常は省略)

公式ドキュメントは 4 レベルすべてを使う必要はないとしており、多くの開発チームにはシステムコンテキスト図とコンテナ図で足りるという立場を採る。C3 は内部が複雑な Container に限って描き、C4 は IDE や UML ツールが必要なときに生成できるため、長期間保守するドキュメントとしては公式も非推奨としている。

C1: System Context 図

[顧客] → [EC サイト] → [決済サービス (外部)]
              ↓
         [配送サービス (外部)]

システムの境界と、外部のユーザー・システムとの関係を示す。技術的な詳細は一切含めない。

C2: Container 図

[ブラウザ (React)] → [API Gateway] → [Lambda (注文)]
                                    → [Lambda (商品)]
                          ↓
                    [DynamoDB]  [S3]  [SQS]

Container は、動いていなければシステム全体が成り立たない実行単位を指す。サーバーサイドアプリ、ブラウザ内で動く JavaScript アプリ、モバイルアプリ、サーバーレス関数、データベース、ブロブストア、メッセージキューなどがこれにあたる。公式の定義は「実行されるコードまたは保存されるデータを囲む実行時の境界」であり、Docker のコンテナとは無関係である (「プロセス」「デプロイ単位」といった語が持つ含意を避けるためにこの名前が選ばれた)。技術選択 (React、Lambda、DynamoDB) が図に現れるのはこのレベルからである。

つまずきやすいのは実行時の境界と物理的な配置の区別である。1 台のアプリケーションサーバー上で 3 つの Web アプリを動かしていても、プロセス空間が分かれていれば Container は 3 つで、それらを何台のホストへどう置くかは別の関心事として扱う。逆に、サーバーサイドで HTML を組み立てて返すだけのアプリは 1 Container だが、まとまった量の JavaScript アプリを配信しているならサーバー側とブラウザ側で 2 Container として描く。プロセス空間が分かれ、プロセス間通信でつながるかどうかが分割の基準になる。

C3: Component 図

[注文 Lambda]
  ├── OrderController (API ハンドラー)
  ├── OrderService (ビジネスロジック)
  ├── OrderRepository (DynamoDB アクセス)
  └── PaymentClient (決済 API 呼び出し)

1 つの Container の内部構造を示す。クリーンアーキテクチャやヘキサゴナルアーキテクチャの層が見える。ここでいう Component は「関連する機能をインターフェースの背後にまとめた塊」であり、単体でデプロイできる単位ではない。同じ Container 内の Component はすべて同一プロセス空間で実行される。したがって別プロセスとして動くマイクロサービスは Component ではなく Container 側に置くのが C4 Model の整理である。

静的構造図を補う 3 つの図

C4 という名前が指すのは静的構造の 4 レベルだが、公式にはこれを補う図が 3 種ある。システムランドスケープ図は組織にある複数システムの全体像を、動的図は特定のシナリオで処理が要素間をどう流れるかを、デプロイメント図は Container が実行環境 (物理サーバー、仮想マシン、コンテナオーケストレーターなど) のどこへ配置されるかを示す。C2 を描いていて「どのホストに何台置くか」を書き込みたくなったら、それはデプロイメント図の役割である。

ADR との補完関係

C4 Model は「今のアーキテクチャがどうなっているか」を図示し、ADR (Architecture Decision Record) は「なぜそのアーキテクチャにしたか」を記録する。両者を組み合わせることで、アーキテクチャの現状と意思決定の経緯を体系的に管理できる。

ツール

• Structurizr: Simon Brown が開発した C4 Model 専用ツール。DSL でモデルを定義し、図を自動生成
• Mermaid: Markdown 内に C4 図を書ける記法を持つ。ただし 2026 年 8 月時点でも実験的扱いで、構文は将来変わり得る (PlantUML の C4 記法と互換)
• draw.io / Excalidraw: 汎用の作図ツールで手動作成

現状の構造を図で残す C4 Model と、そう決めた理由を残す ADR は対で使うと効く。作図の手段としては Mermaid が手軽で、Container の切り分けをどこで入れるかは ドメイン駆動設計 (DDD) の境界づけと マイクロサービス の粒度の議論とあわせて考えたい。