C4 ダイアグラムでチーム間のコミュニケーションを改善する

C4 モデルの4つのズームレベルを軸に、ビジネス、開発、運用、セキュリティの各担当者に合ったアーキテクチャの見せ方を考えます。

Takahiro Iwasa

2026-08-26

8 min read

同じシステムをレビューしていても、参加者によって目に入るものは違います。プロダクトオーナーはユーザーへの価値を、インフラエンジニアは実行環境を、開発者はモジュールの依存関係を見ています。1枚の巨大な構成図にすべてを詰め込んでも、ある人には情報過多で、別の人には説明不足です。

C4 モデルは、この食い違いを図の異なるズームレベルで解消します。地図と同じように、周囲を含む全体像から特定箇所の実装詳細までを切り替え、会話の相手に必要な情報量を選べます。

C4 モデルの4つのズームレベル

C4 ダイアグラムの特徴

C4 という名前は、4種類の中心的なダイアグラムの頭文字に由来します。

レベル	表現するもの	主な読み手
System Context	対象システム、利用者、連携する外部システム	ビジネス、プロダクト、技術の関係者全員
Container	システム内のアプリケーションとデータストア、通信、主要技術	アーキテクト、開発、運用、セキュリティ
Component	1つの Container 内の責務と主要コンポーネント	アーキテクト、開発者
Code	クラス、インターフェースなどの実装要素	実装を担当する開発者

C4 モデルは、記法や作図ツールを規定していません。箱の色や形よりも、要素の名前・種類・責務・技術を明記し、関係線に方向と説明を付けることを重視します。既存の作図ツールや Diagram as Code の仕組みを変えずに導入できるのも、このためです。

4レベルすべてをそろえる必要もありません。公式ガイドでは、多くのチームには System Context と Container で十分とされています。変更頻度の高い Component や Code は、意思決定に必要な箇所だけ作るほうが保守しやすくなります。

UML やインフラ構成図との違い

C4、UML、インフラ構成図は競合する方式ではなく、答えようとしている問いが異なります。

方式	主な問い	強み
C4	誰がシステムを使い、ソフトウェアがどの責務に分かれているか	一貫した抽象度で全体から詳細へ移動できる
UML	システムの構造や振る舞いをどう厳密に表現するか	標準化された記法で、クラス、シーケンス、状態などを表現できる
インフラ構成図	アプリケーションやデータストアをどの実行環境に配置し、どう接続するか	ホスト、クラスタ、ネットワーク境界、冗長化などの配置とトポロジーを伝えやすい

UML は標準化されたモデリング言語です。一方、C4 はソフトウェアをどの抽象度で分解して見せるかを定めるモデルで、記法には依存しません。両者は併用でき、例えば C4 の Code レベルを UML クラス図で、処理の流れを UML シーケンス図で表現できます。

インフラ構成図は、サーバー、実行基盤、ネットワーク境界などを示し、デプロイ先やトポロジーを説明するのが得意です。しかし、実行基盤のアイコンだけでは、その上で動くアプリケーションの責務までは分かりません。反対に、C4 の Container ダイアグラムは責務や通信を示せますが、リージョンやゾーン、冗長化、ファイアウォールルールといった配置の詳細は通常扱いません。

C4 で論理的な構造と共通語彙をそろえ、配置の話になった段階でインフラ構成図または C4 の Deployment ダイアグラムを加えると、設計の意図と実装先を混同せずに説明できます。

異なるロールとのコミュニケーションに使う

C4 で目指すのは、きれいな図ではなく、会話の焦点を合わせることです。新しい注文機能をレビューする場合なら、相手に応じて話の入口を変えます。

プロダクトオーナーやカスタマーサポートとは、System Context で利用者、対象範囲、外部サービスとの境界を確認する
セキュリティや運用チームとは、Container でデータの流れ、認証境界、主要技術、外部通信を確認する
開発チームとは、必要な Container だけを Component へ拡大し、責務、API、依存関係を確認する
実装レビューでは、複雑な部分に限って Code やシーケンス図を追加する

図を切り替えても、要素名がそろっていれば会話は途切れません。System Context の「注文システム」が Container の境界になり、その中の「注文 API」が Component ダイアグラムの対象になる、というように対応を保てば、読み手は用語を覚え直さずにズームできます。

導入時のポイント

C4 の導入は、目の前の問いに答える図から小さく始めます。

対象システムを1つ決め、System Context で利用者と外部システムを整理する
Container でアプリケーション、データストア、主要技術、通信プロトコルを示す
すべての要素に短い責務を、すべての関係線に方向と目的を記載する
レビュー相手が判断するために必要な場合だけ、Component や Code へ掘り下げる
設計変更と同じ Pull Request で図を更新し、コードと用語のずれを防ぐ

まとめ

1枚の図ですべての会話をまかなうことはできません。C4 はその前提に立ち、同じソフトウェアを異なる粒度で見せるための共通言語を用意します。

C4 は、UML やインフラ構成図に取って代わるものでもありません。UML は構造や振る舞いの詳細、インフラ構成図は実行環境への配置、C4 はソフトウェアの境界と責務を伝えるのに向いています。読み手に合わせて一貫した図を数枚用意するほうが、あらゆる情報を詰め込んだ1枚よりも設計の意図を伝えやすくなります。

記事一覧に戻る