はじめに
こんな経験はありませんか？
- 新しいプロジェクトにアサインされたが、システム全体像が掴めない
- 先輩に説明しても「結局どこの話？」と聞かれる
- Excelの謎の図とER図とネットワーク構成図がバラバラに存在している
- 非エンジニアの人に構成を説明すると理解してもらえない
その悩み、C4モデルで解決できるかもしれません。
本記事は、実務経験2〜3年目でこれから設計ドキュメントを書き始めるエンジニアを対象に、C4モデルの基本的な考え方と実践的な使い方を解説します。
読み終える頃には、以下ができるようになっていることを目指します。
- C4モデルの基本構造（4つの階層）を理解する
- それぞれの図が「誰のため」「何のため」かを説明できる
- 明日から自分のプロジェクトに使える状態になる
C4モデルとは
C4モデルは、Simon Brown氏が提唱した、ソフトウェアアーキテクチャの可視化手法です。「C4」は4段階の抽象度の頭文字を表しています。
| 階層 | 英語 |
|---|---|
| 1 | Context |
| 2 | Container |
| 3 | Component |
| 4 | Code |
Google Mapのズームのように、見る人の関心に応じて詳細度を切り替えるのがポイントです。
なぜ必要なのか
従来のアーキテクチャ図には、よくある問題があります。
- UMLは厳密だが、書くのも読むのも重い
- パワポの自由図は分かりやすいが表記が人によってバラバラ
- 「全体像」と「詳細」が同じ図に混ざって情報過多になる
C4モデルは、シンプルな記法と明確な抽象度の分離でこれらを解決します。
4つの階層を1つずつ見ていく
階層1: Context図
「このシステムは何なのか、誰が使うのか」 を示す図です。
- 自分たちのシステムを1つの箱として描く
- 利用者（人・ロール）を描く
- 外部システムとの連携を描く
経営層・他部署・新メンバーなど、全員が最初に見る図になります。
階層2: Container図
「システムは何で構成されているか」 を示す図です。
Contextの箱を開けて、主要な実行単位に分解します。
- Webアプリ
- モバイルアプリ
- APIサーバー
- データベース
- バッチ処理
⚠️ 注意：ここでの「Container」はDockerコンテナではありません。「デプロイ可能な単位」という意味です。
階層3: Component図
「各コンテナの中身はどうなっているか」 を示す図です。
例えば、APIサーバーというContainerを開けると、次のようなコンポーネントに分解できます。
- 認証コンポーネント
- 注文管理コンポーネント
- 通知コンポーネント
- 外部連携コンポーネント
主にそのコンテナを実装・保守するチームが対象読者になります。
階層4: Code図
「実装レベルの詳細」 を示す図です。
- クラス図やER図に近いレベル
- 通常はIDEやツールで自動生成することが多い
- 手動で書くことは少ない（実務では省略されがち）
実務では Context〜Componentの3階層で運用されることが多いです。
4階層まとめ
| 階層 | 見る人 | 問いに答える |
|---|---|---|
| Context | 全員 | このシステムは何？ |
| Container | エンジニア全般 | 何でできている？ |
| Component | 実装担当チーム | 中身はどうなってる？ |
| Code | 個々の開発者 | 実装の詳細は？ |
ズームイン・ズームアウトで必要な情報だけを届けられるのが、C4モデルの強みです。
C4モデルとADRの違い
C4モデルとよく混同されるものに ADR（Architecture Decision Record） があります。両者は目的が異なります。
| C4モデル | ADR | |
|---|---|---|
| 目的 | 構造を可視化 | 決定の理由を記録 |
| 形式 | 図 | テキスト文書 |
| 答える問い | 今どうなっているか | なぜそうなったか |
セットで使うと強い組み合わせです。
- C4で現在の構造を示す
- ADRでその構造に至った経緯を残す
実践Tips
①まず描くのはContainer図
- Context図はシンプルすぎて情報量が少ない
- Component図はいきなり描くと粒度がブレる
- チーム内共有ならContainer図から始めるのが実務的
②ツールは何でもいい
- draw.io / diagrams.net
- Mermaid（コードで書けてGit管理しやすい）
- PlantUML（C4-PlantUMLという拡張もある）
- Structurizr（C4公式ツール、DSLで記述）
重要なのは記法の統一であり、ツールではないという点です。
③更新されない図は死んでいる
- 「初回だけ気合を入れて描いて放置」が最大の失敗パターン
- リポジトリ内にMermaidやPlantUMLで置き、コードと一緒に更新する運用にする
- 更新ルールをチームで決めておく（例：Container構成を変える度に更新）
まとめ
- C4モデルは Context / Container / Component / Code の4階層でアーキテクチャを可視化する手法
- 見る人の関心レベルに合わせて抽象度を選べるのが最大のメリット
- ADRとは別物だが、セットで使うとドキュメントの質が上がる
- 実務ではまずContainer図から始めてみるのがおすすめ
次にやること：自分のプロジェクトのContainer図を1枚描いてみましょう。
参考
- Simon Brown, "The C4 model for visualising software architecture" https://c4model.com/
- C4-PlantUML（GitHub）
上記の引用元URLは執筆時点の記憶に基づくものです。念のためご自身でも参照先をご確認ください。