C4モデルで構成図を2枚描く

対象は、一つのソフトウェアシステムについて、利用者、外部との関係、内部のアプリケーションとデータストア（データを保存する単位）を整理したい人です。構成図が初めてでもかまいません。始める前提は、対象システムの名前と目的が分かること。要件、コード、設定、運用資料を調べ、必要なら担当者へ確認します。資料や権限が足りない項目は推測せず、未確認として残します。

C4モデルは、ある時点で何があり、どうつながるかというソフトウェアシステムの静的な構造を、範囲と詳細度の異なる図で表す方法です。ここではSystem Context図とContainer図の2枚を作ります。読み終えたときの完了状態は、2枚の要素と関係を照合でき、確認できなかった項目に確認先、担当、期限を付けた状態です。

この2枚だけでは、業務の流れ、状態の変化、データ項目、実行環境への配置は決まりません。2枚で答えられない問いは、未確認事項または別の図で扱う対象として残します。

AIで下書きする場合も、2枚を一度に依頼しません。確認済み情報だけでSystem Context図を一枚作り、人が内容を確認してからContainer図へ進みます。

C4では最初に2枚を描く

C4モデルには、ソフトウェアシステム全体（Software System）、内部のアプリケーションやデータストア（Container）、その内側の構成要素（Component）、コードの詳細（Code）という4段階があります。C4モデル公式の概要は、この4段階と対応する図を示し、特定の作図記号やツールを必須としていません。

C4モデル公式の図の説明では、4段階すべてを使う必要はなく、多くのソフトウェア開発チームにはSystem Context図とContainer図で十分だとしています。ただし、これはすべての設計が2枚で完了するという意味ではありません。まず次の二つの問いに答えるための開始点です。

図	答える問い	主に記載するもの
System Context図	対象システムは、誰と何につながるか	対象システム、利用者、直接つながる外部システム、関係
Container図	対象システムの内側は、どの実行・保存単位に分かれるか	アプリケーション、データストア、責務（受け持つ役割）、主要技術、通信

対象を一つのソフトウェアシステムに絞り、確認したいことが外部との関係と内部の主要な構成までなら、最初に共有する範囲はこの2枚です。内部の構成要素、配置先、処理順、状態の変化、データ構造が判断に必要なら、対応する図や文書を追加します。

C4モデルが定めるのは構造を説明する方法です。開発工程やチームの担当分けは規定しません。C4モデル公式FAQでも、この境界が明示されています。

描く前に対象を決める

System Context図の対象範囲は、一つのソフトウェアシステムです。図の中心には一つのソフトウェアシステムを置きます。そのシステムの名前、目的、含める範囲を説明できる状態にします。どこまで含めるか決められない場合は、責任者と確認範囲が決まるまで未確認にします。

次の項目を先に記録します。

項目	記入欄
対象システム名
このシステムが果たす目的
構成を確認する範囲
対象外にする範囲
図の内容が現状を表すか判断する責任者
事実の確認先（利用部門・外部システムの担当など）
実際の構成変更を承認する人
図を更新する担当（主・副）
根拠として確認する資料
図と資料の保管場所

最初のSystem Context図に必要なのは、対象システム名、目的、確認範囲、事実の確認先です。それ以外をその場で確定できなくても、未確認として担当と期限を付ければ作図を始められます。2枚の完了前に図の内容責任者、更新担当、保管場所を決め、実際の構成を変える前に承認者を確認します。

同じ人が複数を担う場合も、事実確認、変更承認、図の更新は別の役割として記録します。確認したことを変更許可と取り違えないためです。

入力情報は次の三つに分けます。

確認済み：要件、契約、設定、コード、運用資料、担当者への確認で裏づけられた情報
未確認：存在や接続は推測できるが、根拠をまだ確認していない情報
設計判断：これから採用する構成や責務分担

未確認の情報は確定した要素として図へ入れず、確認先と期限を付けて別に残します。管理画面や設定を変更する権限がなくても、確認できた範囲の作図は可能です。ただし、図の完成は構成変更の許可を意味しません。変更は承認者と戻し方を確認してから、別の作業として扱います。

この分類と作図順は本記事の作業方法であり、C4公式の指定フォームではありません。

1枚目：System Context図

System Context図の公式説明は、一つのソフトウェアシステムと、そのシステムへ直接つながる人、外部ソフトウェアシステムを対象としています。内部の技術や通信方法より、利用者とシステム間の関係を優先する図です。

対象システムの範囲を示す

図の中央には対象システムを一つ置き、名前と目的を短く添えます。目的は、利用者に対して何を担うシステムなのかを示すものです。内部技術と詳細な機能一覧は別の資料へ分けます。

図のタイトルには、System Context図であることと対象システム名を含めます。色、線、記号を独自の意味で使う場合は、その意味をまとめた凡例も付けます。これはC4のNotationと公式チェックリストで推奨されている確認項目です。

利用者と外部システムを選ぶ

利用者は、システムとの関わり方が分かる役割名で整理します。外部システムには、対象システムと直接関係を持つソフトウェアシステムを記載します。

外部システムは通常、対象チームが責任や所有権を持たない範囲にあります。C4のシステム境界は、図で扱うソフトウェアシステムの範囲です。ここで扱う境界を、契約、ネットワーク、セキュリティ上の境界と同一視しません。これらが判断に必要なら、それぞれの責任者と資料で確認します。

関係の方向と目的を決める

関係は一方向で描き、接続の目的が分かるラベルを付けます。「使用する」「連携する」だけでは、やり取りの目的を判断できません。双方向の通信で方向ごとに目的が異なるなら、分けて記録します。

System Context図では、内部アプリケーション、データベース、サーバー、通信プロトコルは扱いません。それらは次のContainer図または別の図に記載します。

System Context作図票

要素

種別	名前	短い説明	対象との関係	確認状態
対象システム
利用者の役割
外部システム

関係

送信元	送信先	目的	確認した根拠

2枚目：Container図

Container図の公式説明は、一つのシステム境界の内側にあるアプリケーションとデータストアを対象としています。それぞれの責務（受け持つ役割）、主要技術（動作や保存に使う技術）、Container間の通信、直接つながる利用者と外部システムを記載します。

ContainerはDockerと同じ意味ではない

Containerという抽象概念の公式説明では、C4のContainerを、コードが一つのアプリケーションとして動く範囲、またはデータを保存する範囲として説明しています。Dockerコンテナと同じ意味ではありません。ライブラリ（他のコードから呼び出して使うコードの集まり）やモジュール（責務ごとにコードをまとめる単位）など、アプリケーション内部のコード整理単位も通常はContainerに含めません。

Containerの候補ごとに、コードが一つのアプリケーションとして動く単位か、データを保存する単位かを確認します。確認に使う根拠は次の四つです。

起動や配布の単位が分かる設定
データの保存先と管理単位が分かる設定
他の単位との接続先が分かる設定
アプリケーションまたはデータストアの名前と責務が分かる運用資料

コードの保存場所やフォルダが分かれていても、実行・保存の単位まで確認できなければ確定しません。コードや設定から判断できない場合はファイルを変更せず、起動、配置、接続先を把握する担当者へ確認します。確認できないものは、未確認のまま作図票へ残せます。

責務、主要技術、通信を書く

各Containerには、名前、種別、短い責務、主要技術を書きます。責務は何を受け持つか、主要技術は動作や保存に何を使うかを示します。技術名だけで役割を判断しません。

Container間の関係は一方向で示し、通信の目的に加えて、確認できた技術や通信方法（プロトコル）も書きます。この作図票では、Container図に記載しただけで、送るデータ、認証、権限、暗号化の確認が完了したとは扱いません。これらは別の設計記録で確認する項目です。

外部との関係も省略しません。System Context図にある利用者と外部システムが、内部のどのContainerへ直接つながるのかを示します。

Container作図票

要素

一つのContainerにつき、次の「識別」と「項目」の2表を一組として使います。名前、種別、責務、主要技術、扱うデータをそれぞれ記録します。種別の「確認した根拠」には、実行単位または保存単位と判断できる設定や運用資料を記載します。責務、主要技術、扱うデータは、項目ごとに「確認済み」または「未確認」と記録します。一部を確認できても、Container全体を確認済みとは扱いません。

識別

Container名	確認状態	確認した根拠

項目

項目	記入内容	確認状態	確認した根拠
種別
責務
主要技術
扱うデータ

関係

送信元	送信先	通信の目的	技術・プロトコル	確認した根拠

2枚を照合する

2枚の名前、境界、接続先を次の表で照合します。この照合表はC4公式フォームではなく、この記事で確認漏れを見つけるためのものです。

確認項目	確認方法	結果
対象システム	2枚で同じ名前と説明を使っているか
システム境界	Container図の全Containerが対象システム内にあるか
利用者	Context図の各利用者に、Container図の接続先があるか
外部システム	2枚で同じ名前を使い、Container図に接続先があるか
関係	Context図の各関係を、Container図のどの通信が担うか説明できるか
未確認事項	推測した要素や通信を確定情報として描いていないか

対応しない項目が見つかったら、すぐに線や要素を追加せず、要件、コード、設定、運用資料のどれを調べるか、誰へ確認するかを決めます。図に記載がないだけで、その項目が存在しないとは確定しません。

2枚で扱わない範囲

System Context図とContainer図は、静的な構造を共有するための図です。次の問いには別の図や文書を使います。

知りたいこと	追加する記録
一つのContainer内部を、どのComponentに分けるか	Component図。内部を説明する必要がある場合だけ追加する
重要または複雑なComponentのコード構造をどう示すか	Code図。長期保存する図としては慎重に判断する
本番、検証などの環境へ何をどう配置するか	Deployment図
処理がどの順序で進むか	シーケンス図や処理フロー
状態がどう変わるか	状態遷移図
データ項目や関係をどう定義するか	ER図とデータモデル

Component図の公式説明は一つのContainer内部を扱い、説明に価値がある場合だけ作るよう案内しています。Code図の公式説明では、重要または複雑な構成要素のコード詳細を示す図を任意としています。

Container図には、本番や検証などの実行環境へ何を配置するか、停止に備えてどのように分けるかという詳細を詰め込みません。必要ならDeployment図の公式説明に従って分けます。

C4モデル公式FAQは、業務プロセス、処理の流れ、状態の変化、ドメインモデル（業務上の概念、規則、関係を表すモデル）、データモデルをC4の対象に含めていません。これらが不要なのではなく、静的構造とは目的が異なるためです。

図を確認する

作図者以外の関係者に、2枚を図だけで読んでもらいます。説明を補わなくても、次を特定できるか確認します。

図の種類と対象システム
対象システムの目的と境界
各要素の種別と責務
関係の方向と目的
Container図で使う主要技術と通信方法
独自の色、線、記号の意味
未確認のため図へ入れていない事項

C4の公式チェックリストでは、図の種類、要素、関係、表記を読み手が理解できるかを確認します。構成が要件を満たすか、安全性や可用性（必要なときに使える状態）を確保できるかは、別の設計・検証で確認します。

図の更新担当は主担当と副担当を決め、保管場所と最終確認日を残します。外部システム、Container、主要技術、通信方法、責任範囲が変わったときは、2枚と未確認事項を見直します。

作業順と完了条件

作図を始めるときは、次の順に空欄を埋めます。最初に必要なのは対象の決定とSystem Context図です。Container図と2枚の照合までをこの記事の完了範囲とし、Component図などは問いが生じた場合だけ追加します。

対象システム名、目的、対象範囲、対象外、図の内容責任者を記録する
System Context票へ利用者、外部システム、関係を書く
確認済み情報だけでSystem Context図を描く
Container票へアプリケーション、データストア、責務、主要技術を書く
関係表へ通信の目的、技術またはプロトコル、根拠を書く
Container図を描き、Context図との対応表を埋める
未確認事項を図から分け、確認先、担当、期限を付ける
2枚で答えられない問いに必要な追加記録を選ぶ

未確認事項を残す

未確認の内容	なぜ必要か	確認先・根拠	担当	期限	確認後に直す箇所

作図ツールは問いません。図形や色を増やす前に、要素の種別、短い説明、関係の方向、具体的なラベルを確認します。

完了条件

完了条件は、2枚で同じ対象名と境界を使い、System Context図の各関係についてContainer図の接続先を説明でき、未確認事項が表へ分けられていることです。最後に作図者以外の人が図の種類、要素、関係を読めるか確認します。

AIで下書きする場合

AIへ渡してよい情報を確認する

AIへ情報を渡す前に、利用するサービスが組織で認められているかを確認します。個人情報保護委員会の注意喚起は、個人情報を入力する場合、利用目的、応答生成以外への利用、学習利用、利用規約、プライバシーポリシーを事前に確認するよう案内しています。IPAの中小企業向けガイドラインは、漏えいすると問題になる機密情報や個人情報を生成AIへ入力しないよう求めています。

認証情報（利用者やシステムの身元確認に使う情報）、秘密鍵（署名や暗号処理に使い、外部へ公開しない情報）、個人情報、顧客情報、契約上の機密情報は入力しません。図に必要な要素と関係だけに絞り、入力できる範囲が分からない場合は作業を止めて、情報管理、セキュリティ、契約の担当者へ確認します。

1枚ずつ下書きする

AIへは2枚をまとめて依頼しません。最初に渡すのは、System Context図に必要な確認済み情報だけです。人が要素と関係を確認した後、確認済みのContainer、責務、主要技術、通信を加え、Container図を1枚作るよう依頼します。未確認事項とこれから決める設計判断は、確認済み情報から分けて入力します。

AIの出力では、次を確認します。

入力にない利用者、外部システム、Container、通信を追加していないか
C4のContainerをDocker、サーバー、モジュールと自動的に同一視していないか
System Context図へ内部構成や通信技術を混ぜていないか
Container図へ配置詳細や内部Componentを混ぜていないか
関係の方向と目的が入力内容に合っているか
推測を確認済みとして表示していないか

AIが入力にない情報を補った場合、その内容は未確認です。要件、コード、設定、運用資料を調べ、必要なら担当者へ確認します。それでも確認できないものは未確認事項として残します。

次に進む記事

2枚を作る前提が足りない場合は、要件を受入条件まで落とすか技術選定の判断票へ戻ります。
Container内部のコード責務を決める段階では、コードアーキテクチャの種類と選び方とソフトウェア設計原則へ進みます。
ブラウザ、サーバー、ビルド時の処理場所を決める場合は、レンダリング方式の違いを参照します。
図をもとに実際の構成を変える場合は、Gitで変更を確認・保存・戻すで変更前後と戻し方を記録し、Webサービスの最低限の運用設計でバックアップと復旧の条件を確認します。

出典

以下の資料はすべて2026年8月20日に内容を確認しました。