C4モデル vs UML：あなたのチームはどちらを使うべきか？

チームがソフトウェアアーキテクチャをどう図示すべきかを決めるとき、選択はたいてい2つの名前に絞られます。1990年代から2000年代を支配した形式的標準であるUMLと、モダンなエンジニアリングチームでそれをほぼ置き換えた軽量なアプローチであるC4モデルです。

「C4 vs UML」への率直な答えは、ほとんどのブログ記事が認めるよりも微妙です。UMLは無用ではなく、C4は完璧ではありません。それらは異なる問題を解決するために設計されており、正しい選択は、チームが図から実際に何を必要とするか、すなわちコミュニケーション、仕様化、あるいはその両方によって変わります。

この記事は、バランスの取れた比較を提供します。UMLが本当に優れている点、実際にどこで失敗したか、なぜC4がほとんどのチームにとってデフォルトのUMLの代替になったか、そしてチームのタイプ別の具体的な結論です。

UMLとは？

統一モデリング言語（UML）は、1990年代半ば、Grady Booch、Ivar Jacobson、James Rumbaughが競合するオブジェクト指向モデリング表記を統一したときに登場しました。それは1997年にObject Management Group（OMG）によって標準化され、今日も公式のISO標準であり続けています。

UMLは、2つのファミリーに分かれる14種類の図を定義します。

• 構造図：クラス、オブジェクト、コンポーネント、複合構造、デプロイメント、パッケージ、プロファイル図。
• 振る舞い図：ユースケース、アクティビティ、状態機械、シーケンス、コミュニケーション、相互作用概要、タイミング図。

その幅広さがUMLの定義的特徴です。それはほとんど何でもモデル化できます。コードベースの静的構造、注文のライフサイクル、サービス間のメッセージ交換、決済の状態。理論上、完全なUMLモデルはシステムの完全な仕様です。

UMLの本物の強み

ここで公平になる価値があります。なぜなら、UMLはあまりに早く退けられるからです。

• それは本物の標準である。 UMLには形式的な仕様、精密なセマンティクス、ISOの刻印があります。どちらもUMLを知る2人のエンジニアは、同じ図を同じように読みます。他のどのアーキテクチャ表記もそれを主張できません。
• 振る舞いのモデリングが優れている。 シーケンス図と状態機械図は、「時間とともに何が起きるか」のために広く知られた最良の表記であり続けています。C4のコアレベルにそれらを置き換えるものはありません。
• 深いツールの歴史。 何十年ものツール（Rational RoseからEnterprise Architect、PlantUMLまで）がUMLをサポートし、コード生成、リバースエンジニアリング、モデル検証を含みます。
• 一部の産業で期待されている。 航空宇宙、自動車、医療機器、防衛は、しばしば認証とトレーサビリティのために形式的なモデルを要求します。UML（とその兄弟であるSysML）はそこでの共通語です。

UMLが実際にどこで失敗したか

それでも、UMLの利用は主流のソフトウェア開発で崩壊しました。調査と業界の経験は一貫して同じ物語を語ります。「UMLを使う」ほとんどのチームは、実際には2〜3種類の図を、非形式的に、一貫性なく使っています。その理由はこうです。

• 複雑さ。 14種類の図、数百の表記要素、700ページを超える仕様。UMLの習得はそれ自体がプロジェクトであり、ほとんどの開発者は決してやりませんでした。
• 見返りのない形式性。 UMLは、モデルがコード生成を駆動する、ビッグ・デザイン・アップ・フロントの時代のために設計されました。アジャイル開発はそれを逆転させました。コードが真実の源となり、重厚なモデルは誰も維持したがらないオーバーヘッドになりました。
• アーキテクチャの会話に対する間違った抽象度。 UMLはクラスとオブジェクトのレベルで最も強力です。まさに最も頻繁に変わり、アーキテクチャの議論で最も重要でないレベルです。「このシステムの大きな可動部は何で、どう互いに話すか？」に答える、明確で共有された方法を決して定義しませんでした。
• エンジニアリングの外の誰も読まない表記。 UMLのコンポーネント図をプロダクトマネージャーに見せて、その目がうつろになるのを見てください。白抜きの矢印 vs 塗りつぶしの矢印、集約のひし形、ギュメで囲まれたステレオタイプ。表記はアクセシビリティより精度に最適化されています。

結果：今日のほとんどの企業で、「アーキテクチャドキュメント」は、その場しのぎのボックス＆矢印、陳腐化したVisioファイル、ホワイトボードの写真の寄せ集めです。UMLはより良い標準に負けたのではありません。標準が何もない状態に負けたのです。それこそまさにC4モデルが埋めるギャップです。

C4モデルとは？

2010年代にSimon Brownが作成したC4モデルは、逆のアプローチを取ります。豊富な表記を定義する代わりに、小さな抽象化のセットと4つのズームレベルの階層を定義します。

1. System Context — あなたのシステムを1つのボックスとして、ユーザーと外部システムを加える。
2. Containers — システム内部のデプロイ可能なユニット（アプリ、サービス、データベース）。
3. Components — 各コンテナ内部の主要な構成要素。
4. Code — クラスと関数。たいてい描かれるのではなく生成される。

各レベルの完全な解説が欲しいなら、C4モデルの完全ガイドを読むか、System Context図ガイドから始めてください。

C4の強み

• 抽象化が第一、表記は第二。 C4は各ズームレベルで何を示すかを言いますが、どう描くかについては意図的に寛容です。ボックス、矢印、ラベルで十分です。これがチームが実際に採用する単一最大の理由です。
• わずか4つのレベル。 開発者は午後一回でモデル全体を学べます。UMLのトレーニングコースと比べてみてください。
• チーム全体が読める。 System Context図はCEOに機能します。Container図はプラットフォームチームに機能します。同じモデルが、表記ではなくズームレベルを変えることで、すべてのオーディエンスに役立ちます。
• システムが実際に構築される方法に対応する。 「コンテナ」（デプロイ可能なユニット）と「コンポーネント」（モジュール）は、クラスやオブジェクトよりはるかに、モダンなクラウドネイティブ開発のメンタルモデルに合致します。

Simon BrownがUMLのアイデアを拒絶したのではなく、蒸留したことに注目する価値があります。C4は、アーキテクチャには複数の抽象度レベルが必要だというUMLのコアな洞察を意図的に再利用し、そのContainer/Componentの概念はUMLのコンポーネント図とデプロイメント図を反映しています。違いは、C4が形式的な仕様化ではなくコミュニケーションのためにすべてを最適化していることです。

C4の率直な限界

C4は、UMLがやったすべての完全な代替ではありません。

• 構造に焦点を当てている。 4つのコアレベルは、何が存在し何が何につながるかを示します。時間とともに何が起きるかではありません。振る舞いについては、C4は補足的な動的図を案内し、多くのチームは単純にC4をUMLのシーケンス図やフロー図と組み合わせます。
• 形式的標準ではなく慣習である。 ISO仕様も形式的セマンティクスもありません。ほとんどのチームにとってそれは特長ですが、規制された産業にとっては問題になり得ます。
• レベル4はほぼ理論的である。 Simon Brownでさえ、Code図を手作業で描かないことを推奨します。必要なら、そもそもソースから生成してください。

C4 vs UML：横並びの比較

まだUMLを使うべきとき

C4を選ぶことは、UMLを禁止することを意味しません。UMLの図の種類が依然として正しいツールである状況が3つあります。

1. 複雑な相互作用のためのシーケンス図

5つのサービスにまたがる「ユーザーがチェックアウトするとき正確に何が起きるか」をドキュメント化する必要があるとき、UMLのシーケンス図は依然として利用可能な最もクリアな表記です。C4の動的図は単純なケースをカバーしますが、alt/loopフラグメントを伴う込み入ったリクエスト／レスポンスの振り付けには、シーケンス図が勝ちます。

2. ライフサイクル重視の領域のための状態機械

注文、サブスクリプション、決済インテント、ドキュメントワークフロー — 意味のあるライフサイクルを持つものは何でも、UMLの状態機械図から恩恵を受けます。C4に同等のものはなく、それを発明するのは間違いでしょう。

3. 規制され安全性が重要な環境

あなたの領域が形式的な仕様化、認証成果物、要件から設計へのトレーサビリティ（医療、航空宇宙、自動車、防衛）を要求するなら、UMLまたはSysMLが契約上または法律上期待されるかもしれません。C4は依然としてその上のコミュニケーション層として役立ちますが、単独では監査人を満足させられません。

ほとんどのチームが落ち着く実践的なパターンはこうです。構造にはC4、振る舞いにはひと握りの補足的な図。 C4の4つのレベルをアーキテクチャドキュメントの背骨として使い、振る舞いの説明が必要なときに、特定のコンテナとコンポーネントにシーケンス図、状態機械、ユーザーフロー図を付け加えます。その組み合わせは、典型的なプロダクトチームのほぼすべてのドキュメントニーズをカバーします。誰も14種類の図を学ぶ必要なく。

結論：あなたのチームはどちらを使うべきか？

スタートアップとスケールアップ：迷わずC4

あなたは、新入社員が初日に理解でき、次のピボットを生き延びる図を必要とします。C4のSystem ContextとContainer図は、5%の労力で80%の価値を与えます。個々のサービスが本当に複雑になるまでComponent図は飛ばしてください。特定のシーケンス図が元を取らない限り、UMLには触れないでください。

エンタープライズ：背骨としてのC4、報われるところでUML

大組織は、C4のSystem LandscapeとContextレベルから最も多くを得ます。ついに、誰もが読めるポートフォリオビューです。チーム横断の構造ドキュメントをC4で標準化し、それを正当化するワークフローにはUMLのシーケンス図と状態機械図を明示的に許可します。規制産業にいるなら、認証のために形式的なUML/SysMLモデルを保ち、他の全員のための人間に優しい層としてC4を使ってください。

プラットフォーム・インフラチーム：デプロイメント重視のC4

プラットフォームチームはContainerレベルで生きています。サービス、データベース、キュー、ゲートウェイ。C4のContainer図とデプロイメント図は、あなたの世界に直接対応します。UMLのクラス図はここではほぼ無用です。状態機械図は、プロビジョニングのワークフローにときどき役立ちます。

一行のまとめ

C4をデフォルトのアーキテクチャ図の標準として使う。振る舞いがそれを要求するときに、UMLのシーケンス図と状態機械図を借りる。完全なUMLは規制された環境のために取っておく。

Archylはこれを実際にどう実装しているか

ArchylはC4モデルをファーストクラスの概念として中心に構築されており、C4の振る舞いのギャップに直接対処します。

• インタラクティブな4レベルの図。 システム、コンテナ、コンポーネント、コード要素がナビゲート可能な階層を形成します。コンテナをクリックしてそのコンポーネントにズームインする、まさにC4モデルが意図するとおりです。C4モデルのページでアプローチを探索してください。
• コードからのAIディスカバリ。 手作業で図を描く（UMLと手作業のC4の取り組みの両方が死ぬ部分）代わりに、Archylは接続されたリポジトリを分析し、C4モデルの草案（システム、コンテナ、コンポーネント、関係）を生成し、それをあなたがレビューして洗練します。
• 振る舞いのドキュメントのためのユーザーフロー。 古典的なC4が振る舞いを補足的な図に任せるところ、Archylはユーザーフローを含みます。ユースケースがアーキテクチャをどう移動するかのステップバイステップの可視化で、関与するC4要素にリンクされています。これは、チームが以前シーケンス図に使っていたものの大半をカバーします。
• ドリフト検知。 すべてのUMLモデルとすべての手描きのC4図が共有する失敗モードは陳腐化です。Archylはドキュメント化されたモデルを実際のコードベースと継続的に比較し、ドリフトをスコアリングするので、ドキュメントは信頼できるままです。

現在PlantUMLでアーキテクチャ図を維持していて代替を評価しているなら、詳細なArchyl vs PlantUML比較をご覧ください。

FAQ

C4とUMLを一緒に使えますか？

はい。そしてそれはほとんどのチームに推奨されるアプローチです。C4の4つのレベルを構造ドキュメントに使い、ランタイムの振る舞いの説明が必要なところにUMLのシーケンス図や状態機械図を付け加えます。C4自身の動的図はUMLのシーケンス図に明示的に着想を得ているので、両者は自然に組み合わさります。

UMLは死んだのですか？

いいえ。しかしそのスコープは劇的に縮小しました。日常的なソフトウェアチームのための完全なモデリング方法論としては、UMLは主流の実践から事実上消えました。特定の優れた表記の源として（とりわけシーケンス図と状態機械）、それは大いに生きています。また、規制され安全性が重要な産業では依然として必須です。

C4モデルはUMLのような公式標準ですか？

いいえ。C4はSimon Brownが作成した広く採用されている慣習であり、ISO標準ではありません。一貫した定義と推奨される表記を持ちますが、形式的な仕様はありません。ほとんどのチームにとって、この非形式性こそがそれが機能する理由です。認証重視の環境では、それは制約になり得ます。

新しい開発者のオンボーディングにはどちらが優れていますか？

明らかにC4です。新しい開発者は、System Context図、次にContainer図、次に自分が取り組むサービスのComponent図を読めます。最初に表記を学ぶことなく、段階的にズームインできます。対照的に、UMLのクラス図は、コードから直接読んだ方がよい詳細レベルをドキュメント化します。

ボックスを1つも手で描かずにC4モデルを構築する準備はできましたか？Archylを無料で試して、数分でコードからアーキテクチャ図を生成しましょう。あるいは読み進めてください：C4モデルとは？完全ガイド | C4 System Context図ガイド | Archyl vs PlantUML。