de_DEen_USes_ESfa_IRjapt_PTru_RU

C4コンテナ図の習得：技術選択、責任、コミュニケーションに焦点を当てる（PlantUMLの例付き）

C4コンテナ図とは何ですか？

コンテナ図はレベル2サイモン・ブラウンのC4モデルにおけるもので、レベル1（システムコンテキスト）で定義された単一のソフトウェアシステムに焦点を当て、以下を示します：

The Ultimate Guide to C4 Model Visualization with Visual Paradigm's AI Tools - ArchiMetric

  • その高レベルな構造システム境界内のアーキテクチャの概要。

  • 主要なデプロイ可能／実行可能な単位と呼ばれるコンテナ.

  • 各コンテナの技術選択各コンテナについて。

  • コンテナがどのように相互に作用するかお互いおよび外部のエイジェント／システムと。

重要な補足：C4における「コンテナ」とは必ずしもDockerコンテナであるとは限りません。コードを実行するかデータを格納することができる、別々にデプロイ可能／実行可能な単位を指します。例：

  • Webアプリケーション／シングルページアプリケーション（SPA）

  • モバイルアプリ

  • サーバーサイドAPI／マイクロサービス

  • データベース（スキーマ）

  • ファイルストレージ（S3バケット、ファイルシステムフォルダ）

  • メッセージブローカー／キュー（明示的にモデル化された場合）

  • デスクトップ／CLIアプリケーション

  • バッチ処理／スケジュールされたジョブ

図は依然としてハイレベル — 内部のクラスやコードの詳細は含まれない（それはレベル3のコンポーネントまたはレベル4のコードである）

コンテナ図を作成するタイミング

以下の状況では、コンテナ図を作成（および維持）する：

  • 以下の図を完了した（または少なくともスケッチした）場合：システムコンテキスト 図を完成させ、次のような問いに答える必要がある場合：「私たちのシステム内部の主要な構成要素は何ですか？」

  • 新規の開発者、アーキテクト、または運用スタッフのオンボーディング時 — 彼らは技術スタックとハイレベルな責任を素早く理解する必要がある

  • 重要な技術的またはアーキテクチャ的決定を行うとき（モノリス → マイクロサービス、モバイルアプリの追加、データベースの選定、メッセージキューの導入、クラウド移行）

  • 監査、コンプライアンス、セキュリティレビュー、インシデント対応のための文書化（攻撃面やデータフローを可視化するのに役立つ）

  • リポジトリに存在し、システムと共に進化する「アーキテクチャをコードとして」実現したい場合

  • 大多数のチームはここで止まる — シモン・ブラウン自身が指摘しているようにシステムコンテキスト + コンテナ 図は、大多数のソフトウェアチームにとって十分である。コンテナ内の複雑さがそれを正当化する場合にのみ、さらに深く（コンポーネント／コード）掘り下げるべきである

以下の場合はスキップまたは先送りする：

  • システムが非常に単純な場合（1つのプロセス＋データベース）

  • 非常に初期のアイデア段階であり、大まかなコンテキストだけが必要な場合

なぜコンテナ図を使うのか？（主な利点）

  • 異なる対象者に対する明確さ
    開発者は技術と統合ポイントを見ることができる
    運用／インフラチームはデプロイ可能な単位と通信経路を見ることができる
    アーキテクトは責任の境界と技術的負債のリスクを見ることができる
    マネージャーは、技術に依存しすぎず、かつ具体的な視点を見ることができる

  • 「一つの大きな図」問題を回避する
    すべて（ユーザー＋インフラ＋クラス＋クラウドアイコン）を一つの過負荷な図に押し込むのを防ぐ

  • 重要な意思決定を強調する
    SPA＋API＋リレーショナルDB vs. サーバーサイドレンダリング＋NoSQL、または同期型 vs. イベント駆動型といった選択肢を明確に可視化する

  • コミュニケーションと協働
    設計会議、インシデントの事後分析、脅威モデル化、ロードマッピングの際に共有地図として機能する。

  • 生きているドキュメント
    PlantUML / Structurizr DSL / 類似の形式で記述された場合 → Gitでバージョン管理され、CIで自動再生成され、常に最新状態を保つ。

素晴らしいコンテナ図の作成方法（ステップバイステップ＋ベストプラクティス）

  1. レベル1から始める
    コンテキスト図からPersonと外部ソフトウェアシステムをコピーする — これらはコンテナと対話するエイクターとなる。

  2. システム境界を描く
    使用する System_Boundary PlantUMLで「私たちのシステム内部」を明確に範囲指定する。

  3. コンテナを特定する
    尋ねる：システムの機能を提供する、独立して実行・デプロイ可能なものは何か？
    一般的なパターン：

    • Web SPA ↔ APIバックエンド ↔ データベース

    • モバイルアプリ ↔ フロントエンド用バックエンド（BFF） ↔ 共有サービス

    • メッセージブローカーを備えたマイクロサービス

    • レガシーモノリス + 新しいAPIレイヤー

  4. 技術と簡単な説明を追加する
    各コンテナには、名前、技術、短い目的を表示する。
    説明は15語未満に抑える。

  5. 相互作用（関係）を定義する
    方向 + プロトコル + 意図を表示する（例：「JSON/HTTPS」、「読み込み・書き込み」、「公開先」、「消費元」）。
    関係には動詞を使用する。

  6. ベストプラクティス

    • 読みやすく保つ — コンテナ数は10～12個未満を目指す。それ以上なら、焦点を絞ったビューを作成する（例：「APIサブシステムのコンテナ」）。

    • 一貫性を保つ — 同じレイアウト方向（上から下、左から右）、同じ詳細レベルを維持する。

    • アイコン／スプライトを使用する — 視覚的なインパクトを加える（PlantUMLはdevicons、font-awesomeなどをサポート）。

    • 凡例とキー — PlantUMLで凡例を自動表示するように設定する。

    • ごちゃごちゃを避ける — 値を追加しない場合、キューまたはトピックを省略する。代わりに矢印にプロトコルをラベルする。

    • バージョン管理とコードとして保存 — .puml ファイルをリポジトリにコミットする。

    • 対象読者に合わせた調整 — 開発者向けには詳細な技術情報、ステークホルダー向けには簡潔なバージョンを用意する。

PlantUMLの例 – 伝統的なインターネットバンキングシステム（Big Bank plcスタイル）

ここでは、公式の C4-PlantUML ライブラリを使用した、クリーンで本番環境対応の例を示します。

@startuml
!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Container.puml

' オプション: きれいなアイコンを追加（tupadr3スプライトから）
!include https://raw.githubusercontent.com/tupadr3/plantuml-icon-font-sprites/master/devicons/angular.puml
!include https://raw.githubusercontent.com/tupadr3/plantuml-icon-font-sprites/master/devicons/java.puml
!include https://raw.githubusercontent.com/tupadr3/plantuml-icon-font-sprites/master/devicons/postgresql.puml
!include https://raw.githubusercontent.com/tupadr3/plantuml-icon-font-sprites/master/devicons/android.puml

title コンテナ図：インターネットバンキングシステム

Person(customer, "個人向けバンキング顧客", "Big Bank plcの顧客")

System_Boundary(c1, "インターネットバンキングシステム") {
    Container(spa, "シングルページアプリ", "JavaScript & Angular", "顧客がウェブブラウザ経由ですべてのインターネットバンキング機能を利用できる", $sprite="angular")
    Container(mobile, "モバイルアプリ", "Android/iOS (React Native)", "限定的なインターネットバンキング機能", $sprite="android")
    Container(api, "APIアプリケーション", "Java & Spring Boot", "API経由でインターネットバンキング機能を提供", $sprite="java")
    ContainerDb_Ext(db, "バンキングデータベース", "PostgreSQL", "ユーザーの設定、キャッシュデータ、セッションを保存（コアアカウント/取引はメインフレームに保持）", $sprite="postgresql")
}

System_Ext(core, "コアバンキングシステム", "メインフレームシステム – 既存")
System_Ext(email, "メールシステム", "メールを送信（例：AWS SES）")

Rel(customer, spa, "使用", "HTTPS")
Rel(customer, mobile, "使用", "HTTPS")

Rel(spa, api, "呼び出し", "JSON/HTTPS")
Rel(mobile, api, "呼び出し", "JSON/HTTPS")

Rel(api, db, "読み書き", "JDBC/SQL")
Rel(api, core, "使用", "JSON/HTTPS")
Rel(api, email, "メール送信", "HTTPS")

LAYOUT_WITH_LEGEND()
LAYOUT_TOP_DOWN()

@enduml

これにより、以下の特徴を持つクリーンな図が描画されます：

  • システム境界

  • 技術ラベル

  • スプライト/アイコン

  • 明確な関係性

  • 凡例

このコードをPlantUMLのオンラインサーバー、または互換性のあるIDE/エディタに直接貼り付けることができます。

この構造をテンプレートとして使用してください。自システムの名前、技術、データフローに置き換えてください。より高度なスタイル（テーマ、カスタムカラー）が必要な場合は、C4-PlantUMLのGitHubサンプルを確認してください。

図を描くことを楽しんでください — そして思い出してください：目的は 効果的なコミュニケーション、UMLの完璧さではないのです！

C4コンテナ図リソース