見出し画像

UMLよりも簡潔で実用的なC4モデル

Kazuma Oshiro🐧大城 和真

C4モデルとは

C4モデルはイギリスのソフトウェアアーキテクトであるSimon Brown氏によって提唱された、ソフトウェアシステムの構造を可視化するためのモデルです。C4モデルの「C」は以下の4つのレイヤーを指します。

  1. Context (コンテキスト)

  2. Container (コンテナ)

  3. Component (コンポーネント)

  4. Code (コード)

一般的には、Context → Container → Component → Codeという順に、全体像から細部へとドリルダウンしていきます。これによって、ステークホルダーの技術的知識や興味の深さに応じて適切な粒度でシステム構造を説明できるようになります。

https://c4model.com/abstractions  より引用

1. Context Diagram (コンテキストダイアグラム)

目的

  • システムの「全体像」を把握する

  • システムが誰によって、どのように利用されるかを示す

  • システムが外部システム（他のサービスや外部データソースなど）とどのように連携するかを示す

内容

  • 対象となるシステム（システム境界が分かるように大枠で描く）

  • アクター（ユーザや外部システム）：システムを利用したり、システムに影響を与える存在

  • 関係・データのやりとり：ユーザや外部システムとのやりとり（入力や出力）を矢印などで示す

ポイント

  • 図全体はシンプルにする（細かい技術要素や詳細は描かない）

  • 「このシステムを利用する人はどんな人か？」「このシステムと連携する外部システムは何か？」を明確にする

  • ビジネス関係者やステークホルダーにも直感的に分かるレベルにする

https://c4model.com/diagrams/system-context より引用

2. Container Diagram (コンテナダイアグラム)

目的

  • システム内部がどのような「コンテナ」で構成されているかを示す

  • コンテナ間の責務と通信関係を把握する

内容

  • コンテナ：アプリケーションやサービス、データベース、フロントエンド、バックエンドなど、論理的・物理的なまとまり

  • 関係：コンテナ間の通信プロトコル、データの流れ、依存関係

コンテナとは、たとえば次のような単位を指します:

  • Webアプリケーション

  • モバイルアプリ

  • REST APIサーバ

  • データベース

  • バッチシステム

  • メッセージングキュー

  • 外部SaaS連携

ポイント

  • 「アプリ群やデータストアなど大きなまとまり」を区切って示す

  • 技術スタックやプロトコルを簡単に記載する

  • コンテキストダイアグラムよりもう少し具体的な技術情報が入る

https://c4model.com/diagrams/container より引用

3. Component Diagram (コンポーネントダイアグラム)

目的

  • 各コンテナの内部構造（どんなコンポーネントで成り立っているか）を示す

  • クラスより粒度の大きいまとまりを想定（サービスクラス、モジュール、ライブラリなど）

内容

  • コンポーネント：コンテナ内の主要な責務や機能単位

  • 関係：コンポーネント同士の依存関係ややり取り

ポイント

  • 1つのコンテナに対して「メインコンポーネントはどんなものがあるか？」を示す

  • 重要なビジネスロジックやサービスのまとまりを可視化する

  • 細部に踏み込みすぎず、大事な責務分担が一目で分かるレベル

https://c4model.com/diagrams/component より引用

4. Code Diagram (コードダイアグラム)

目的

  • コンポーネントを実装するコードレベル（クラス、関数など）の構造を示す

  • 実際の実装（ソースコード構造）がどのように作られているかをドキュメント化する

内容

  • クラスや関数の関連、継承関係、実際のコードパッケージ構成など

ポイント

  • すべてのクラスを網羅する必要はない（重要な部分に焦点を当てる）

  • 開発者同士で詳細設計を議論するときに役立つ

https://c4model.com/diagrams/code より引用

使用例

  1. 要件定義や上流工程での合意形成
    Contextダイアグラムを使い、ビジネス側ステークホルダーやクライアントに対して「システムがどのようにユーザや外部システムとやり取りするのか」を説明します。

  2. システムアーキテクチャレビュー
    Containerダイアグラム、Componentダイアグラムを用いて、システムの分割や通信経路などを確認します。冗長性の有無、可用性、セキュリティなどの観点をレビューできます。

  3. 実装の詳細確認
    コンポーネントの内部構造（Componentダイアグラム）やコードレベルのクラス設計（Codeダイアグラム）を利用して、開発チーム内で詳細仕様を詰めます。

C4モデルを導入するメリット

  1. わかりやすい段階的な可視化
    Context → Container → Component → Codeの4段階で抽象度を変えながら、同じシステムを多面的に捉えられます。非技術者から開発者まで、関わる人のスキル・興味に応じて適切な粒度で説明することが可能です。

  2. アーキテクチャの共通言語を作れる
    設計ドキュメントがメンテナンスされない問題はよくありますが、C4モデルを使えば「このシステムはどうやって動いている？」という質問に対して、「C4図を見ればわかる」という形で整理・共有しやすくなります。

  3. 設計・レビューがしやすい
    開発途中でも、まずContextやContainerから決め、あとで細部を固めていく進め方ができます。また、レビューもそれぞれのレイヤーごとに行うことで、抜け漏れを減らすことが期待できます。

  4. ツールサポートが充実
    PlantUML、Structurizr、その他のドキュメントツールなど、C4モデルを描くためのツールが多数公開されています。自動生成やクラウド連携なども活用すると、開発者の手間を削減しつつ常に最新化されたドキュメントを保ちやすくなります。

注意点・導入時のコツ

  1. モデルと現実の乖離に注意
    システムの実態が変わったのに図が更新されないと、徐々にドキュメントが信用されなくなります。CI/CDパイプラインと連携した自動生成や、定期的なレビューを実施し、現状と図を同期させる運用を考えましょう。

  2. レベル分けをしっかり運用する
    「どこまで描くのか」の決定が曖昧だと、コンポーネント図にクラス情報を入れ始めて煩雑になるなど、レイヤーの境界が崩れやすくなります。

    • Contextダイアグラムは「外部の俯瞰レベル」

    • Containerダイアグラムは「システム内部のアプリ/データストアレベル」

    • Componentダイアグラムは「コンテナごとの主要機能単位」

    • Codeダイアグラムは「重要なクラスやメソッドレベル」
      というルールを明確にしましょう。

  3. 必要十分な情報量を意識する
    細かすぎる情報を詰め込みすぎると逆に理解が難しくなります。導入時は「シンプルに描く」「本当に必要な部分だけ詳細化する」という方針で進め、必要に応じて追加していくのがおすすめです。

まとめ

C4モデルは、「ソフトウェアシステムを4つのレイヤー（Context, Container, Component, Code）で表現する」というシンプルなルールでありながら、段階的に詳細を掘り下げられる強力な可視化手法です。

  • Context：システムを取り巻くユーザや外部システムとの関係

  • Container：システム内部を構成する大きな技術単位（アプリ、DB等）

  • Component：各コンテナ内の主要な責務・機能単位

  • Code：実装レベルのクラス・メソッド設計

これを順番に描くことで、非技術者に対する概要説明から、エンジニア同士の詳細設計議論まで、一貫した視点を提供できます。今後システムの拡張・運用をしていく上でも、アーキテクチャの共通理解を保つ上で大変有用です。

特にチーム開発やマイクロサービスのように複数のコンテナに分割されたシステムでは、C4モデルが威力を発揮します。ぜひプロジェクトでのドキュメント化やアーキテクチャレビューに活用してみてください。

参考


いいなと思ったら応援しよう！