C4モデルとは？構成図を4段階で描く方法

はじめに

「システム構成図を作ってください」と依頼すると、担当者ごとに違う図が出てくる。ある図には利用者と外部サービスが並び、別の図にはAPIやデータベースが並ぶ。さらに別の図にはクラスや関数まで書かれている。どれも間違いではないが、一枚に重ねると読めない。

問題は作図ツールではなく、どの縮尺で何を合意する図なのかが決まっていないことだ。

C4モデルは、ソフトウェアの構造をコンテキスト、コンテナ、コンポーネント、コードという4段階のズームで表す考え方である。相手に合わせて必要な詳細だけを見せられるため、経営・業務部門との境界確認から、開発者との実装分担までつなげやすい。

この記事では、C4モデルの4段階をただ紹介するのではなく、実案件で構成図を作る順番と、各図に書くべき情報を整理する。

C4モデルは「4枚すべて描くルール」ではない

C4モデル公式サイトは、静的な構造図をSystem Context、Container、Component、Codeの4種類に分けている。名称の頭文字がすべてCであるためC4と呼ばれる。

重要なのは、4枚を必ず納品することではない。公式ガイドも、価値のあるレベルだけを使い、多くの開発チームにはコンテキスト図とコンテナ図で十分だとしている。

C4モデルの目的は、細かい図を増やすことではなく、異なる読者へ異なる縮尺で同じシステムを説明することだ。

この順番なら、上位の合意を保ったまま必要な場所だけを拡大できる。逆に、最初からコードレベルを描くと、そもそも対象システムの外にある責任や、外部連携の漏れを見落としやすい。

レベル1：コンテキスト図で対象範囲を決める

コンテキスト図には、対象のソフトウェアシステムを一つの箱として置き、その利用者と直接つながる外部システムを描く。

たとえば受注管理システムなら、営業担当、受注担当、顧客、会計システム、在庫管理システム、認証サービスが候補になる。この段階ではWebアプリ、API、データベースといった内部構造を書かない。

各要素には次の3点を添える。

• 名称：社内で通じる固有名詞
• 役割：何を提供する人・システムか
• 関係：どちらから何を依頼・提供するか

矢印に「連携」とだけ書くのは弱い。「確定した受注を送る」「在庫引当結果を受け取る」のように、方向と目的が分かる動詞を書く。

ここで確認するのは、機能一覧より前の境界だ。対象システムが責任を持つ処理は何か。外部システムへ委ねる処理は何か。利用者は誰か。個人情報や契約情報はどの境界を越えるか。コンテキスト図は、非技術者も参加できる最初のレビュー資料になる。

業務上の登場人物とシステムの関係が曖昧な場合は、ユースケース図の書き方も併用するとよい。ユースケース図で利用目的を確かめ、コンテキスト図でシステム間の境界を確かめる。

レベル2：コンテナ図で実行単位とデータを分ける

コンテキスト図で対象範囲を合意したら、対象システムの箱だけを拡大する。

C4モデルでいう「コンテナ」はDockerコンテナに限らない。公式のコンテナ図ガイドでは、サーバー側Webアプリ、SPA、モバイルアプリ、データベーススキーマ、ファイル領域、オブジェクトストレージなど、アプリケーションまたはデータストアをコンテナとして扱う。

コンテナ図には次の情報を置く。

• コンテナ名
• 主な責任
• 主要な技術
• 他のコンテナや外部システムとの通信
• 保存する主要データ

例として、受注管理システムを「管理画面」「受注API」「非同期処理ワーカー」「受注データベース」に分ける。管理画面は担当者の操作を受け、APIは業務ルールを実行し、ワーカーは会計・在庫との再送を担い、データベースは受注と処理状態を保持する。

ここで大切なのは、製品名を並べる前に責任を分けることだ。「React」「Node.js」「PostgreSQL」だけでは、何を担当する箱なのか分からない。まず責任を書き、技術はその責任を実現する選択として添える。

また、コンテナ図は本番の台数やロードバランサーを表す配置図ではない。公式ガイドも、クラスタリング、複製、フェイルオーバーなど環境ごとに変わる情報はDeployment diagramへ分けるとしている。論理的な責任と物理配置を一枚に混ぜない。

通信の詳細は、外部インターフェース一覧へ連携IDを渡す。図の矢印と一覧の一行を対応させれば、認証、頻度、最大件数、再処理、監視まで追跡できる。

レベル3：コンポーネント図は複雑な箱だけ描く

コンポーネント図は、一つのコンテナ内部を拡大し、責任を持つ主要な部品と関係を示す。

受注APIなら、「注文受付」「価格計算」「在庫引当」「承認」「外部連携」「監査記録」といった単位が候補になる。画面ごと、ファイルごとに分けるのではなく、変更理由と責任がまとまる単位で切る。

各コンポーネントには、次を短く書く。

1. 何を受け取るか
2. 何を判断するか
3. 何を返すか
4. どのデータや外部機能へ依存するか
5. 失敗時にどこまで責任を持つか

すべてのコンテナにコンポーネント図を作る必要はない。複数チームが同じコンテナを変更する、業務ルールが複雑、障害の影響範囲を分けたい、といった場所に絞る。

単純なCRUDアプリまで細分化すると、図の更新コストが価値を上回る。コンテナ図だけで担当範囲と変更影響を説明できるなら、そこで止めてよい。

レベル4：コード図は自動生成できる範囲に絞る

コード図は、クラス、インターフェース、関数など実装に近い構造を表す。ここは変更頻度が高いため、手作業で維持するほど陳腐化しやすい。

コード図を残すのは、複雑なドメインモデル、設計パターンの中心部分、安全性に関わる状態遷移など、文章やコードだけでは意図を共有しにくい箇所に絞る。可能ならソースコードから生成し、リポジトリの変更と同じレビューに載せる。

画面の動きやAPI呼び出し順序を説明したい場合、静的なコード図ではなくシーケンス図の書き方が向いている。構造を示す図と、時間順の振る舞いを示す図を分けると読みやすい。

実案件でC4モデルを作る5ステップ

1. 読者と判断事項を一文で決める

「経営会議で外部サービス依存を承認する」「開発チームがAPIとワーカーの責任を分ける」のように、誰が何を判断する図かを書く。目的が違えば図を分ける。

2. コンテキスト図から始める

利用者、対象システム、直接関係する外部システムを並べる。境界外の責任を先に確定し、内部構造へ進む。

3. コンテナ図で責任とデータ所有を置く

実行単位とデータストアを描き、各箱の責任を一文にする。データを更新できる主体、同期・非同期、外部連携の方向を確認する。

4. 詳細化が必要な箱だけ拡大する

レビューで質問が集中するコンテナを、コンポーネント図へ拡大する。コード図は実装意図を保つ価値がある箇所だけにする。

5. 図と仕様のIDをつなぐ

各システム、コンテナ、連携へ安定したIDを付け、要件、API仕様、テスト、監視、障害記録から参照する。図をきれいに描くことより、変更時に影響をたどれることのほうが重要だ。

レビューで確認する7項目

最後に、次を確認する。

• 図の対象範囲と読者が明記されている
• 要素の名称と責任が一文で説明されている
• すべての矢印に方向と目的がある
• コンテナと配置先を混同していない
• 外部連携がインターフェース一覧へつながっている
• 詳細化しすぎた図を別レベルへ分けている
• 更新責任者とレビューの契機が決まっている

C4モデルは、構成図の見た目を統一するだけの記法ではない。対象範囲から実装まで、同じシステムを段階的に説明するための会話の枠組みだ。

まずコンテキスト図で境界を決め、次にコンテナ図で責任を分ける。必要な場所だけコンポーネントとコードへ進む。この順番なら、業務部門との合意と開発者の設計を一つの流れにできる。

Atsumellでは、業務フロー、システム境界、外部連携、責任分界を整理し、要件から実装・テストへ追跡できる仕様づくりを支援している。構成図が担当者ごとにばらばらで、開発へ渡せる粒度にそろえたい場合は、お問い合わせフォームから相談してほしい。

構成図の前提となる業務フローや責任分界を整理する段階では、Kakusillの活用も選択肢になる。