C4モデルを現実的な例で解説

C4モデルは説明するのは簡単ですが、間違った使い方をするのも簡単です。多くのチームが、ユーザー、マイクロサービス、Javaクラス、クラウドの箱をひとつの巨大な図に詰め込んでしまいます。C4はまさにそれを防ぐための手法です。このガイドでは、C4モデルの図の例をひとつ通しで紹介します。架空のシステムをレベル1、2、3で描き、各図に何を載せるのか、誰が読むのか、よくある間違いがどこで起きるのかを確認していきます。

1分でわかるC4モデル

Simon Brownが考案したC4モデルは、ソフトウェアアーキテクチャをズームできる一連の図として表現します。各レベルは、異なる読者に向けて異なる問いに答えます。

C4における「container」は、単独で動作する、またはデータを保存するものすべてを指します。Webアプリ、API、ワーカー、データベース、メッセージキューやトピックなどです。Dockerコンテナのことではありません。C4は図形や色ではなく抽象概念を定義しているため、表記は自分たちで決めます。公式リファレンスは c4model.com です。

例として使うシステム：オンライン書店 Folio

具体的に考えるために、架空のシステムを使います。Folioは紙の本と電子書籍を販売する架空のオンライン書店で、実在の企業ではありません。

• 顧客はカタログを閲覧し、本を購入し、電子書籍をダウンロードします。
• バックオフィスのスタッフがカタログ、在庫、価格を管理します。
• Folioは3つの外部システムに依存しています。決済プロバイダー、メール配信サービス、倉庫パートナーのフルフィルメントシステムです。

レベル1：System Context図

コンテキスト図では、Folioを1つの箱として描き、その周囲にあるものをすべて示します。内部の詳細は一切載せません。

• Customer（Person）：本を閲覧・購入する。
• Back-office Staff（Person）：カタログ、在庫、価格を管理する。
• Folio（Software System、対象範囲内）：紙の本と電子書籍を購入できるようにする。
• Payment Provider（Software System、外部）：カード決済のオーソリとキャプチャを行う。
• Email Service（Software System、外部）：注文・発送メールを配信する。
• Fulfilment System（Software System、外部、倉庫パートナーが所有）：紙の注文をピッキング、梱包、発送する。

すべての関係には、意図を表すラベルを付けます。

• Customer → Folio：「本を閲覧・購入する」
• Back-office Staff → Folio：「カタログと在庫を管理する」
• Folio → Payment Provider：「カード決済を処理する」
• Folio → Email Service：「注文メールを送る」
• Folio → Fulfilment System：「紙の注文を送る」

誰向けか： プロダクトマネージャー、新メンバー、セキュリティレビュー担当、他チーム。ひと目で理解できないなら、情報を詰め込みすぎです。プロトコルや技術は通常このレベルには載せません。

レベル2：Container図

Folioの中にズームします。人と外部システムはそのまま残り、Folioはコンテナを囲むboundaryになります。

ここからは、関係に意図とプロトコルの両方を書きます。

• Web Storefront → API Application：「カタログを読み、注文する [JSON/HTTPS]」
• API Application → Main Database：「読み書きする [SQL/TCP]」
• API Application → Payment Provider：「決済を作成・キャプチャする [HTTPS]」
• API Application → Order Events Queue：「OrderPaidイベントを発行する [AMQP]」
• Order Worker → Order Events Queue：「OrderPaidイベントを購読する [AMQP]」
• API Application → E-book Store：「電子書籍ファイルのダウンロードリンクに署名する [HTTPS]」
• Order Worker → Fulfilment System：「紙の注文を送信する [JSON/HTTPS]」
• Order Worker → Email Service：「確認メールを送る [HTTPS]」

誰向けか： エンジニア、アーキテクト、SRE。日々の業務では、多くの場合これが最も役に立つC4の図です。設計レビューで映したり、新メンバーに渡したりするのはこの図です。載っていないものにも注目してください。Pod、VPC、ロードバランサーはありません。それらはデプロイ図に載せます。

レベル3：Component図

ひとつのコンテナ、API Applicationにズームします。すべてのコンテナにコンポーネント図が必要なわけではありません。内部が説明に値するほど複雑な場合にだけ描きます。

• Catalogue Controller（Spring MVC RESTコントローラー）：検索と書籍詳細のエンドポイント。
• Checkout Controller（Spring MVC RESTコントローラー）：カートとチェックアウトのエンドポイント。
• Order Service（Springサービス）：カートを検証し、注文を作成し、イベントを発行する。
• Payment Gateway Client（Springコンポーネント）：決済プロバイダーのAPIをラップする。
• Order Repository（Spring Data JPA）：注文を永続化する。
• Catalogue Repository（Spring Data JPA）：書籍、価格、在庫を読み取る。

関係のルールはレベル2と同じです。たとえば Order Service → Payment Gateway Client「決済のキャプチャを依頼する」、Order Repository → Main Database「[SQL/TCP]」のように書きます。

誰向けか： そのコンテナを所有する開発者。コンポーネント図は最も早く古くなる図です。

レベル4、Code： 手で描かないでください。必要なときにIDEからクラス図を生成しましょう。

C4の図を読みやすくする表記のコツ

• すべての箱に4つの情報を入れる： 名前、要素の種類、技術、1行の責務。

API Application
[Container: Java, Spring Boot]
Provides catalogue, ordering and account functionality via a JSON/HTTPS API.

• すべての関係にラベルを付ける： 意図と、レベル2以降はプロトコルも。「使う」だけの矢印は何も伝えません。
• 矢印は1本につき1方向、送信元の視点で説明します。
• 凡例（キー）を付ける： 図形、色、線の種類、略語を説明します。破線の意味は、説明するまで誰にもわかりません。
• すべての図にタイトルを付ける： 種類と範囲を書きます。例：「Container図：Folio」。
• 対象システムのboundaryを描く： 自分たちが所有するものと、呼び出すだけのものを区別できるようにします。

よくある間違い

1. いきなりコンポーネントから描く。 コンテキストとコンテナの図がないと、そのコンポーネントがどこにあり、なぜ存在するのか読者にはわかりません。
2. レベルを混ぜる。 Person、Pod、Javaクラスが同じ図にあると、どれも十分に説明されません。
3. ラベルのない矢印。 意図もプロトコルもない線は読者に推測を強い、人によって解釈が変わります。
4. Codeレベルを手で描く。 描き終えた翌日には古くなっています。
5. Container図にインフラを載せる。 Namespace、サブネット、インスタンスタイプはデプロイ図に載せます。

補助的な図：デプロイ図と動的図

C4には補助的なビューも定義されています。特に役立つのは次の2つです。

• デプロイ図（Deployment）： コンテナをインフラに対応付けます。Folioなら、API ApplicationとOrder WorkerがKubernetesクラスター上のDeploymentとして動き、PostgreSQLはマネージドデータベース、E-book Storeはオブジェクトストレージ、といった形です。Kubernetesやクラウドの詳細はここに載せます。
• 動的図（Dynamic）： 特定のフローを番号付きのステップで示します。たとえば「顧客が電子書籍を購入する」なら、1) Storefrontがチェックアウトを送信、2) APIが決済をキャプチャ、3) APIがOrderPaidを発行、4) ワーカーがダウンロードリンク付きのメールを送信、となります。

このC4モデルの図の例をArchboardで作る方法

Archboardには、Person、Software System、Container、Component、Databaseのノードとboundaryを含むC4 Modelパックがあります。これらは汎用の図形ではなく、ポートを持つファーストクラスのノードなので、関係はポート同士をつないで表します。

1. GoogleまたはGitHubでサインインし、ダイアグラムを作成します。
2. レベル1： Personノードを2つ（Customer、Back-office Staff）、Folio用のSoftware Systemノードを1つ、決済・メール・フルフィルメントの各システム用のExternal Systemノードを3つ配置します。ポートをつなぎ、各エッジに意図のラベルを付けます。
3. レベル2： Folio用のboundaryを追加し、Web Storefront、Admin Portal、API Application、Order Worker、Order Events Queue、E-book StoreのContainerノードと、Main DatabaseのDatabaseノードを配置します。名前、技術、責務を入力し、エッジに意図とプロトコルのラベルを付けます。
4. レベル3： API Application用のboundaryを追加し、その中にComponentノードを配置します。
5. 凡例とメモ： 凡例にはCore要素のMarkdownブロックやTableを使い、各レベルを無限キャンバス上の別エリアに分けるにはFrameを使います。
6. 隣にデプロイビュー： C4のビューは、KubernetesパックやCloudパックと同じキャンバスに置けます。API ApplicationとOrder Worker用に、Deployment、Service、Ingressノードを含むNamespaceフレームを、それが実装するコンテナビューのすぐ隣に描きましょう。

Archboard はキャンバスなので、各ビューを意図を持って描きます。どのレベルに何を載せるかを自分で決められ、C4 のノードは同じボード上で Kubernetes パックや Cloud パックのノードと並べられます。そのため、デプロイメントビューをコンテナビューのすぐ隣に置いておけます。

Freeプランでは1つのダイアグラムに15ダイアグラムノードと150件のメモ・テキスト・ステッカー・マインドマップのトピックを置けるので、Folio程度のシステムならダイアグラムごとにC4の1レベルを描けます。すべてのレベルを1つのキャンバスにまとめたい場合は、ノード数とダイアグラム数の上限がないProをご利用ください。C4の活用方法について詳しくはC4のユースケースをご覧ください。

無料テンプレート

C4コンテナビューの例は公開ダイアグラムで、この事例を使うでご自身のワークスペースにコピーできます。boundaryのレイアウトに使い、そのあと前述のとおり各エッジに意図とプロトコルのラベルを付けてください。

よくある質問

4つのレベルすべてが必要ですか？ いいえ。多くのチームにとって、最も価値があるのはコンテキスト図とコンテナ図です。コンポーネント図は必要な箇所だけに追加し、Codeレベルは必要なときだけ生成してください。

C4のcontainerはDockerコンテナのことですか？ いいえ。データベースやSPAを含め、個別に実行・デプロイできる単位すべてを指します。Docker上で動くかどうかは問いません。

Kubernetesの詳細はどこに書きますか？ デプロイ図です。コンテナ図は責務と通信に集中させます。

無料で始める — 1シート、クレジットカード不要