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

C4 モデルの特徴と、UML やインフラ構成図との違いを整理し、相手のロールに合った粒度でソフトウェアアーキテクチャを伝える方法を解説します。

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 ダイアグラムで補うと、設計の意図と実装先を分離して説明できます。