arc42とC4モデルの違いと組み合わせ方

チームの誰かが、アーキテクチャドキュメントにarc42を使おうと提案します。別の誰かが、うちはもうC4を使っていると言います。そこから始まる議論はたいてい、どちらか1つを選ばなければならないという前提に立っています。まず捨てるべきなのは、その前提です。

arc42とC4を比べるのは、レポートの章立てと、その中に入れるグラフを比べるようなものです。arc42はテンプレートです。品質目標からリスクまで、アーキテクチャについて何をドキュメント化すべきかを示す12のセクションです。C4はモデルであり記法です。ソフトウェアシステムの構造をどう描くかを示す4つのレベルのダイアグラムです。両者はいくつかの箇所で重なり、うまく組み合わせられます。このガイドでは、それぞれが何をカバーするのか、C4では描かないがarc42が求めるもの、C4がarc42に加えるもの、そしてどのC4ダイアグラムをどこに置くかのセクション別の対応表を扱います。

ひとことで答えると

arc42はアーキテクチャドキュメントのテンプレートです。C4モデルはソフトウェアアーキテクチャ図の描き方です。両方を使うチームの多くは、C4ダイアグラムをarc42のセクションの中に置いています。

arc42自身のFAQもこの関係をそう説明しています。「arc42とC4については？」という質問に対し、C4モデルは「arc42のいくつかのセクションと_多くの_共通点を持つが、特定の部分（品質要求、横断的な概念、リスク、その他いくつか）を省いている」と答えています（arc42 FAQ、B-17）。同じFAQは、Simon BrownのC4モデルをarc42の代替手段の1つとして挙げています（A-6）。ダイアグラムだけが必要なら正しい話ですが、ドキュメントが担うそれ以外のすべてが必要なら誤解を招きます。

	arc42	C4モデル
何か	ソフトウェアアーキテクチャをドキュメント化し伝えるためのテンプレート	ソフトウェアアーキテクチャを図示するための階層的なモデルと記法
作者	Peter HruschkaとGernot Starke、「2005年から実践で実証済み」（arc42.org）	Simon Brown
形	12のセクション。実際にはすべて任意	4つのコアレベル（Context、Container、Component、Code）と補助的なダイアグラム
カバー範囲	目標、制約、コンテキスト、構造、ランタイム、デプロイ、概念、決定、品質、リスク、用語集	4つのズームレベルでの静的構造、およびランタイム（ダイナミック）とデプロイのビュー
記法	規定なし	少数の要素タイプからなるボックスと矢印、各ダイアグラムに凡例
成果物	ドキュメント（AsciiDoc、Markdown、Word、Confluenceなど）、CC BY-SA 4.0	手で描くか、モデルから生成したダイアグラム

arc42の12セクション

何かを対応付ける前に、正確な番号付きでセクションを手元に置いておくと便利です。以下はarc42のドキュメントにあるもので、テンプレートのバージョン9.0（ダウンロードページによれば2025年7月）です。

#	セクション	内容（arc42自身の要約）
1	Introduction and Goals（導入と目標）	要求、ステークホルダー、最重要の品質目標
2	Constraints（制約）	技術的・組織的な制約、規約
3	Context and Scope（コンテキストとスコープ）	ビジネスコンテキストと技術コンテキスト、外部インターフェース
4	Solution Strategy（ソリューション戦略）	設計の背後にある根本的な決定とアイデア
5	Building Block View（ビルディングブロックビュー）	ソースコードの抽象化、ブラックボックスとホワイトボックス
6	Runtime View（ランタイムビュー）	実行時のシナリオ：ビルディングブロックがどうやり取りするか
7	Deployment View（デプロイメントビュー）	ハードウェアと技術インフラ、デプロイ
8	Crosscutting Concepts（横断的な概念）	繰り返し使われるアプローチとパターン
9	Architecture Decisions（アーキテクチャ上の決定）	重要な、コストの高い、リスクのある、議論を呼ぶ決定
10	Quality Requirements（品質要求）	品質要求の概要と詳細な品質シナリオ
11	Risks and Technical Debt（リスクと技術的負債）	既知の問題、リスク、技術的負債
12	Glossary（用語集）	重要なビジネス用語と技術用語の定義

arc42がはっきり述べていることがもう1つあります。すべてを埋める必要はない、ということです。FAQは「どの部分が必須か？」に対して、「_すべてを埋めよう_とはしないでください。ステークホルダーが必要とするものだけをドキュメント化してください」と答えています。書いたものはすべて「将来メンテナンスの手間を必要とする可能性がある」からです（B-1）。この助言は、後で述べる組み合わせにとって重要です。3つのセクションに良いC4ダイアグラムがある簡潔なarc42ドキュメントは、誰も更新しない完全なドキュメントに勝ります。

arc42がカバーし、C4がカバーしないもの

C4が扱うのは構造と、補助的なダイアグラムを通じたランタイムとデプロイです。アーキテクチャのうちボックスではない部分については何も語りません。arc42の用語でいえば、次のセクションにはC4の対応物がまったくありません。

セクション1、Introduction and Goals（導入と目標）。 システムがなぜ存在するのか、誰が関心を持っているのか、そして後のあらゆる決定を方向づける3〜5つの品質目標。C4のコンテキスト図は誰がシステムを使うかを示します。けれども、「チェックアウトは2秒以内に完了しなければならない」が「管理画面がきれいである」より重要だとは言えません。
セクション2、Constraints（制約）。 「社内のKubernetesプラットフォームで動かすこと」「Javaで書くこと」「データをEU外に出さないこと」。制約は、ダイアグラムが表示するだけの選択の理由を説明します。
セクション4、Solution Strategy（ソリューション戦略）。 根本的な選択（まずはモノリス、台帳にはイベントソーシング、検索エンジンは購入する）を一か所にまとめたもの。
セクション8、Crosscutting Concepts（横断的な概念）。 認証、エラー処理、ロギング、永続化のパターン、国際化。これらはすべてのボックスを貫いているため、どれか1つのボックスで示すことはできません。
セクション10、Quality Requirements（品質要求）。 具体的な品質シナリオ：刺激、応答、測定基準。
セクション11、Risks and Technical Debt（リスクと技術的負債）。 脆いとわかっているもの、後回しにしたもの。
セクション12、Glossary（用語集）。 ビジネスで使われる言葉を、一度だけ定義したもの。

これらはまさに、arc42のFAQがC4は「特定の部分を省いている」と言うときに挙げているセクションです。アーキテクチャドキュメントがC4ダイアグラムだけなら、新しく来たアーキテクトや監査人は、読み終えた後もこれらの疑問を抱えたままになります。

C4がarc42に加えるもの

arc42は意図的に記法を規定していません。セクション5は「ブラックボックスとホワイトボックスの階層的な集まり」を求め、セクション3は「システムをブラックボックスとして示すあらゆる種類のダイアグラム」を提案し、セクション6は番号付きのステップ一覧からシーケンス図、BPMN、ステートマシンまで何でも受け入れます（セクション5、セクション3、セクション6）。この柔軟性はテンプレートの強みであると同時に、arc42のドキュメントが最もばらつきやすいところでもあります。書き手ごとに描き方が違うのです。

C4はこの隙間を2つのもので埋めます。

一貫したズーム。 arc42のビルディングブロックビューにはすでにレベルがあります。レベル1は「システム全体のホワイトボックスの記述と、それに含まれるすべてのビルディングブロックのブラックボックスの記述」であり、レベル2は「レベル1のいくつかのビルディングブロックにズームインする」ものです（セクション5）。C4のレベルは、そのズームの段階に固定の意味（システム、コンテナ、コンポーネント、コード）を与えます。そのため、C4を知っている読み手は、ラベルを読む前に何を見ているのかがわかります。
小さな共通語彙。 人、ソフトウェアシステム、コンテナ、コンポーネント、関係。それぞれに名前、説明、そしてたいていはテクノロジーがあります。チーム間でダイアグラムを比較可能にするには十分な記法であり、誰もトレーニングを必要としないほど少ない記法です。

実用上の利点もあります。C4ダイアグラムを作図ツールではなくモデルから作れば、同じ要素がセクション3、5、6、7に同じ名前で現れます。arc42はそれをどう実現するかについて何の意見も持っていませんが、それこそがセクション同士の整合性を保つものです。

対応表：どのC4ダイアグラムをarc42のどのセクションに置くか

この対応付けは私たちのもので、arc42のセクション定義とC4のダイアグラム定義から導き出しました。arc42のFAQは、組み合わせ方を規定するのではなく、コミュニティの例を紹介しています（たとえばbitsmuggler氏のarc42 + C4サンプルリポジトリ）。最後の列に記した細部については、チームによってやり方が異なります。

C4ダイアグラム	arc42のセクション	合う理由	注意点
System Context（レベル1）	3 Context and Scope、ビジネスコンテキスト	arc42は、すべての通信相手とともにシステムをブラックボックスとして示すことを求めています。それはC4のコンテキスト図の定義そのものです	arc42は技術的コンテキスト（チャネルとプロトコル）も求めています。矢印にプロトコルのラベルを付けるか、各相手とそのチャネルを対応付ける表を加えましょう
Container（レベル2）	5 Building Block View、レベル1	レベル1は、含まれるビルディングブロックをブラックボックスとした、システム全体のホワイトボックスです	arc42のビルディングブロックは「ソースコードの抽象化」ですが、C4のコンテナはデプロイ可能な単位です。サービスベースのシステムの多くでは一致します。モジュラーモノリスなら、レベル1はコンテナではなくモジュールになるかもしれません
Component（レベル3）	5 Building Block View、レベル2	レベル2は選んだレベル1のブロックを開きます。C4のコンポーネント図が1つのコンテナに対して行うことと同じです	必要なコンテナについてだけ描きましょう。arc42も「選んだ」と言っています
Code（レベル4）	5 Building Block View、レベル3、またはどこにも置かない	必要ならより深いレベルも許されています	たいていは、ドキュメントに残しておくより、必要なときにコードから生成するほうが良い結果になります
ダイナミック図	6 Runtime View	arc42はビルディングブロックがやり取りする具体的なシナリオを求めており、C4のダイナミック図は1つのシナリオの番号付きのやり取りを示します	arc42は「多数のシナリオを記述することは重要_ではない_」と述べています。アーキテクチャ上意味のある少数を選びましょう
デプロイメント図	7 Deployment View	どちらも環境ごとに、ソフトウェアのビルディングブロックをインフラに対応付けます	arc42は「関連するすべての環境」をドキュメント化するよう求めており、これはたいてい環境ごとに1枚のデプロイメント図を意味します
システムランドスケープ	専用のセクションはなし。付録にするか、arc42ドキュメントの外に置くことが多い	arc42は1つのシステムをドキュメント化するもので、ランドスケープは多くのシステムにまたがります	必要なら、各システムのドキュメントにコピーするのではなく、共有のランドスケープ1枚にリンクしましょう
アーキテクチャ決定記録（C4ダイアグラムではない）	9 Architecture Decisions	arc42自身が、Nygardの構成による「重要な決定ごとにADR（アーキテクチャ決定記録）」を提案しています（セクション9）	arc42は、決定をそれが影響するビルディングブロックの中でローカルにドキュメント化することも認めています。どちらかの約束事に決め、セクション9に索引を置きましょう

表にないセクション（1、2、4、8、10、11、12）は、C4ダイアグラムではなくテキストと表です。それはどちらの手法の欠落でもなく、役割分担です。

実例

以下は、私たちのC4モデル完全ガイドにあるECシステムで両者を組み合わせた場合の姿です。ReactのSPA、APIゲートウェイ、注文・商品・ユーザーのためのGoサービス、PostgreSQLデータベース、Kafka、通知サービスから成ります。これは完全なドキュメントではなく、C4ダイアグラムを配置した簡潔なarc42の骨組みです。

1. Introduction and Goals（導入と目標）
   - 目的：顧客が商品を閲覧・注文し、倉庫スタッフが在庫を管理する
   - 品質目標：(1) チェックアウトが p95 で 2 秒未満に完了する
               (2) 決済のオーソリが成功しない限り、注文は確定しない
               (3) 既存のサービスを変更せずに新しいサービスを追加できる

2. Constraints（制約）
   - 社内の Kubernetes プラットフォームで動かす。バックエンドサービスは Go

3. Context and Scope（コンテキストとスコープ）
   - ビジネスコンテキスト：C4 System Context 図
     [Customer], [Warehouse Staff] -> [E-Commerce Platform]
     -> [Stripe], [FedEx API], [SendGrid]
   - 技術コンテキスト：相手 / プロトコル / やり取りするデータの表

4. Solution Strategy（ソリューション戦略）
   - サービスごとにデータベース。通知は Kafka 経由で非同期

5. Building Block View（ビルディングブロックビュー）
   - レベル1：C4 Container 図（SPA、API Gateway、Order/Product/User
     サービス、3つの PostgreSQL データベース、Kafka、Notification Service）
   - レベル2：Order Service のみの C4 Component 図
     （Order Handler、Order Service、Order Repository、Payment Client、
     Inventory Client）

6. Runtime View（ランタイムビュー）
   - 「顧客が注文する」：C4 ダイナミック図、番号付きの 10 ステップ

7. Deployment View（デプロイメントビュー）
   - 本番：C4 デプロイメント図
   - ステージング：本番との差分のみ

8. Crosscutting Concepts（横断的な概念）
   - ゲートウェイでの認証。POST /orders の冪等性キー。
     リクエスト ID 付きの構造化ロギング

9. Architecture Decisions（アーキテクチャ上の決定）
   - ADR-001 サービスごとにデータベース
   - ADR-002 同期呼び出しではなく、注文イベントに Kafka を使う
   - ADR-003 注文を書き込む前に決済のオーソリを取る

10. Quality Requirements（品質要求）
   - シナリオ：セール中に毎分 500 件のチェックアウト、p95 で 2 秒未満

11. Risks and Technical Debt（リスクと技術的負債）
   - 在庫は決済前に確保される。決済失敗時の補償処理はまだない

12. Glossary（用語集）
   - 注文、確保、オーソリ、フルフィルメント

ダイアグラムがどこにあるかに注目してください。セクション3、5、6、7です。それ以外は数行のテキストです。また、セクション11のリスクとセクション9のADR-003が、セクション6のダイナミック図が示しているのと同じことを指している点にも注目してください。こうした相互参照こそ、arc42とC4を組み合わせたドキュメントが真価を発揮するところです。ダイアグラムはステップの順序を示し、ADRはその理由を述べ、リスクはまだ何が間違っているかを述べます。

ダイナミック図そのものについては、C4 Dynamic図ガイドがまさにこのシナリオをステップごとに解説しています。セクション9については、アーキテクチャ決定記録の完全ガイドが、arc42が推奨するフォーマットと索引の保ち方を扱っています。

arc42の12セクションがチームには多すぎると感じるなら、私たちのソフトウェアアーキテクチャドキュメントのテンプレートが、同じ考え方から作ったより短いMarkdownのアウトラインです。arc42との対応を説明するセクションも付いています。

両方を最新に保つ

arc42とC4には共通の失敗パターンがあります。どちらも、書かれたその日は素晴らしいのです。arc42自身のFAQも、埋めたセクションはどれも、引き受けたメンテナンスだと警告しています（B-1）。長持ちする習慣をいくつか挙げます。

できるだけダイアグラムをドキュメント本文に入れない。 スクリーンショットを貼るのではなく、モデルから生成したダイアグラムを参照または埋め込みましょう。コンテナ図のスクリーンショットは、コンテナが改名された日に古くなります。モデルからレンダリングしたダイアグラムは、モデルが古い分だけしか古くなりません。
変化の速いセクションはコードの隣に置く。 セクション5、6、9はコードとともに変わります。セクション1、2、10はビジネスとともに変わります。前者をリポジトリに置けば（arc42はそのためにMarkdownとAsciiDocのテンプレートを提供しています）、プルリクエストで更新できます。
ADRは前に向かって書き、決して編集しない。 置き換えられた決定には新しいADRを書きます。セクション9は、書き直された物語ではなく履歴になります。
すべてのセクションにオーナーとレビュー日を付ける。 オーナーのいないドキュメントは、誰も更新しないドキュメントです。
構造に関するセクションをコードと照合する。 セクション3と5はコードに存在するものを記述しているので、自動でチェックできます。セクション1、8、10はそうはいきません。定期的に人がレビューする必要があります。

最後の点がarchylの出番で、それも問題の一部に対してだけです。archylが保持するのはC4モデルであって、arc42ドキュメントではありません。AI発見がリポジトリからシステム、コンテナ、コンポーネント、関係を提案し、あなたがそれを承認します。ADRは影響するC4要素に紐づけられ、ドリフトスコアが文書化された要素がまだコードに存在するかをチェックします。これでダイアグラム中心のセクション（3、5、6、9）はカバーできます。品質目標、横断的な概念、リスク一覧は書いてくれませんし、arc42へのエクスポートもありません。テキストのセクションはarc42ドキュメントに残り、モデルにリンクします。

よくある質問

arc42はC4より優れていますか？

どちらが優れているということはありません。同じ仕事をしていないからです。arc42は、目標、制約、構造、ランタイム、デプロイ、決定、品質、リスクをカバーするドキュメントのテンプレートです。C4は、構造を一貫して描くための方法です。完全なアーキテクチャドキュメントが必要ならarc42（またはそれに似た形のもの）を使いましょう。一貫したダイアグラムが必要ならC4を使いましょう。両方が必要なチームの多くは、arc42の中でC4ダイアグラムを使っています。

arc42とC4は一緒に使えますか？

はい、よくある組み合わせです。arc42は記法を規定していないので、C4ダイアグラムをそのままセクションに入れられます。コンテキスト図はセクション3に、コンテナ図とコンポーネント図はセクション5に、ダイナミック図はセクション6に、デプロイメント図はセクション7に置きます。

C4のコンテナ図はarc42のどこに置きますか？

セクション5、Building Block Viewのレベル1、つまりシステム全体のホワイトボックスビューです。コンポーネント図は、必要なコンテナについてレベル2に置きます。システムがモジュラーモノリスなら、レベル1のビルディングブロックはコンテナではなくモジュールになるかもしれず、対応はゆるくなります。

arc42ではUMLが必須ですか？

いいえ。arc42はいくつかのセクションで記法を提案しています（たとえばセクション3では、技術的コンテキストにUMLのデプロイメント図を挙げています）が、選択はあなたに委ねています。C4、UML、シンプルなボックスと矢印のどれもarc42と組み合わせて使われています。

arc42ではADRをどこに置きますか？

セクション9、Architecture Decisionsです。arc42自身が、重要な決定ごとにMichael Nygardの構成でADRを書くことを推奨しており、そのほうが読みやすければ、決定を影響するビルディングブロックの中でローカルにドキュメント化することも認めています。

arc42は無料ですか？

はい。テンプレートは無料のオープンソースで、ライセンスはCC BY-SA 4.0です。12の言語で提供され、AsciiDoc、Markdown、Word、Confluenceなどの形式があります（ダウンロードページ）。

arc42ドキュメントのC4の部分を、コードに忠実なまま保ちたいですか？ archylを無料で試し、リポジトリからモデルを生成しましょう。続けて読む：C4モデルとは？完全ガイド | Architecture Decision Records：完全ガイド | C4 Dynamic図ガイド | ソフトウェアアーキテクチャドキュメントのテンプレート