「オニオンアーキテクチャ」「ヘキサゴナルアーキテクチャ」「クリーンアーキテクチャ」、名前は聞いたことがあるけれど、それぞれの違いを正確に説明できますか？
この記事では、3つのアーキテクチャの設計思想・レイヤー構造・依存関係のルールを図解で比較し、「結局どれを選べばいいのか」の判断基準まで解説します。
実務で何度もアーキテクチャを書き直してきた私が、混同しやすいポイントを整理しました。
設計初心者から中級者まで、読み終わる頃には自信を持って選択できるようになります。
オニオン・ヘキサゴナル・クリーンアーキテクチャが混同される理由
設計の勉強を始めると、必ずと言っていいほど「オニオン」「ヘキサゴナル」「クリーン」の3つに出会います。
これらはどれも「依存関係をどう整理するか」を説いたものですが、正直なところ、パッと見の図解がどれも円や多角形で構成されているため、違いが分かりにくいと感じるのが普通です。
私も最初は「円の色が違うだけでは？」なんて本気で考えていた時期がありました（笑）。
実際、以前のプロジェクトでは「クリーンアーキテクチャ」を名乗りながら、ドメイン層がインフラ層に直接依存している設計が放置されていました。
チーム内で「これのどこがクリーンなのか」と議論になったのが、違いを本気で学び始めたきっかけです。
しかし、これらを混同したまま設計を進めると、チーム内で用語の定義がズレてしまい、結果として「自称クリーンアーキテクチャ」のような、中途半端で扱いにくいコードが生まれてしまいます。
なぜ3つのアーキテクチャは混同されやすいのか
これらのアーキテクチャが混同される最大の理由は、目指しているゴールが同じだからです。
どれも「ビジネスロジックを外部（データベースやUI）から独立させる」という目的を掲げています。
また、オニオンアーキテクチャやクリーンアーキテクチャは、先行して存在したヘキサゴナルアーキテクチャの思想を色濃く受け継いでいます。
歴史的な背景や進化の過程が地続きになっているため、共通点が多いのは当然です。
「設計思想」と「構造」の違いを分けて考えると見えてくる
違いを理解するコツは、抽象的な「思想」と具体的な「構造」を切り分けて捉える点にあります。
ヘキサゴナルは「外部との接続」をポートとアダプタという概念で整理するスタイル。
オニオンは「ドメインを中心に据える」レイヤー構造に重きを置いています。
そしてクリーンは、それらを統合して「依存関係の逆転」を厳格なルールとして定義しました。
この「何を強調して伝えたいか」というニュアンスの違いが、実装における自由度や制約の差として現れてくるのです。
3つのアーキテクチャに共通する設計思想
個別の違いに入る前に、これら3つのアーキテクチャが「共通して守ろうとしているもの」を明確にしておきましょう。
ここを外すと、どんなアーキテクチャを採用しても失敗します。
結論から伝えると、すべての根底にあるのは「依存の方向を制御して、システムの中心部を汚さない」という鉄則です。
この鉄則を守るだけで、テストが書きやすくなり、技術の流行り廃りにも強い、寿命の長いシステムを構築できます。
私もこの原則を意識するようになってから、データベースの変更や外部APIの差し替えに怯える毎日から解放されました。
関心の分離と依存関係のコントロールが目的
プログラムにおける「関心」とは、例えば「計算ロジック」「データの保存」「画面への表示」といった役割のことです。
これらが密に結合していると、どこかを直すたびに全体が壊れます。
3つのアーキテクチャは、この関心を物理的なレイヤーやインターフェースで強制的に引き離します。
依存の方向を「外側から内側へ」と一方通行に制限することで、内側にある重要なプログラムが、外側の都合に振り回されないようにコントロールしているのです。
「外側が変わっても内側を守る」という共通ゴール
私たちの業界では、流行のフレームワークやデータベースが数年単位で入れ替わります。
しかし、ビジネスの核となるロジック（例えば「利息の計算方法」など）はそれほど頻繁には変わりません。
外側のレイヤー（UI、DB、外部サービス）がどれだけ変化しても、内側のドメイン層は一切修正不要である状態。
これこそが、3つのアーキテクチャが共通して追い求めている「聖杯」のようなゴールだと言えます。
オニオンアーキテクチャとは？ドメイン中心のレイヤー構造
オニオンアーキテクチャは、その名の通り玉ねぎのような多層構造が特徴です。
ジェフリー・パレルモ（Jeffrey Palermo）氏が2008年に提唱したこの手法は、それまでの「データベースが中心」という考え方を真っ向から否定しました。
一番大切なのは、データの持ち方ではなく「アプリケーションが何を成したいか」というドメインの知識です。
私は初めてこの図を見たとき、中央にある「Domain Model」という文字を見て、コードの主役がどこにあるべきかを再認識させられた記憶があります。
レイヤー構造と依存方向が明確な点が特徴
オニオンの特徴は、依存の矢印が常に中心に向かっている点です。
中心から順に「Domain Model」「Domain Services」「Application Services」と重なり、一番外側に「Infrastructure」などが位置します。
従来の3層アーキテクチャではビジネス層がデータアクセス層に依存していました。オニオンではその関係を完全に逆転させています。
インターフェースを内側に置き、実装を外側に置くという徹底した構造が、堅牢なシステムを支える土台となるのです。
ドメイン中心設計との相性が良い理由
オニオンアーキテクチャは、ドメイン駆動設計（DDD）の実装パターンとして非常に優秀です。
ドメイン層が何にも依存していないため、ビジネスロジックを純粋なオブジェクトとして記述できます。
外部のライブラリやフレームワークの影が一切ないコードは、まるで仕様書をそのまま読んでいるかのような見通しの良さを提供してくれます。
ただし、オニオン＋DDDの導入にはチームの学習コストも考慮が必要です。
私の経験では、まずドメイン層のインターフェース定義だけを先に決め、外側の実装は後から埋めていく進め方が効果的でした。
この「内側から外側へ」の開発順序が、チームの理解を最も促進します。
技術的な制約に縛られず、ビジネスの言葉でコードを語りたいチームには、これ以上ない選択肢と言えるでしょう。
ヘキサゴナルアーキテクチャ（ポートとアダプタ）の特徴
ヘキサゴナルアーキテクチャ、別名「ポートとアダプタ」は、アリスター・コーバーン（Alistair Cockburn）氏によって2005年に提唱されました。
名前の「ヘキサゴナル（六角形）」には、実は数学的な意味はあまりありません。
重要なのは「アプリケーションには表も裏もなく、多くの接続先がある」という多角的な視点です。
UIからのリクエストも、DBへの保存も、外部通知も、すべてアプリケーション外部の「プラグイン」として扱います。
この実用的な思想がヘキサゴナルの核心です。
「ポートとアダプタ」という考え方の意味
このアーキテクチャの核は、内側のアプリケーションが用意する「ポート（接続口）」と、外側の世界を繋ぐ「アダプタ」の分離にあります。
ポートは単なるインターフェースであり、アプリケーションが何を必要としているかを定義します。
一方でアダプタは、そのポートに合わせて具体的な処理を実現する変換器です。電源コンセントと変換プラグの関係を想像すると分かりやすいでしょう。
この仕組みにより、アプリケーション本体は「相手が誰か」を詳しく知る必要がなくなるのです。
UIやDBを入れ替えやすくする設計意図
ヘキサゴナルの素晴らしい点は、テストの容易さにあります。
本物のデータベースの代わりに、メモリ上で動くテスト用のアダプタをポートに差し込むだけで、ロジックの検証が瞬時に終わります。
また、将来的に「REST APIではなくGraphQLにしたい」とか「MySQLからPostgreSQLに変えたい」といった要求が出たとしても、アダプタを新しく作るだけで対応可能です。
変化の激しい現代の開発現場において、この「付け替え可能性」は強力な武器になります。
クリーンアーキテクチャとは？依存性逆転を徹底した設計
クリーンアーキテクチャは、"Uncle Bob"ことロバート・C・マーチン（Robert C. Martin）氏が2012年に提唱した設計モデルです。
それまでに存在したさまざまなアーキテクチャを研究し、最も重要なエッセンスを凝縮して一般化しました。
2012年のブログ記事で示された有名な4色の同心円図は、設計に詳しくない人でも一度は見たことがあるはずです。
クリーンアーキテクチャは、単なるレイヤー構造の提示に留まらず、SOLID原則をどうアーキテクチャ全体に適用するかという「規律」を強く打ち出しています。
依存関係逆転のルールを最も強く打ち出した構造
クリーンアーキテクチャが他の2つと一線を画すのは、「依存性の逆転原則」をシステムの隅々にまで適用することを求めている点です。
内側の円は、外側の円について1ミリも知ってはならない。
クラス名はおろか、外側で定義された変数名さえも内側で使ってはいけません。
この厳格なルールのおかげで、中心部にあるエンティティやユースケースは、外部のフレームワークという汚染から完全に守られた、清浄な領域として保たれるのです。
ユースケース層を独立させる意味
クリーンアーキテクチャのもう一つの特徴は「Use Case」層の存在です。
オニオンではApplication Servicesと呼ばれていたものに近いですが、クリーンでは「アプリケーション固有のビジネスルール」を明示的に一つの層として切り出します。
これにより、システムが「何をするものか」が一目で分かるようになります。
DBのスキーマを見るのではなく、ユースケースのコードを見るだけで、そのシステムが提供する価値を理解できる。
これこそが、開発者にとっての「クリーンさ」の正体です。
原典を読んでより深く理解したい方にはこちらがおすすめです。本記事で扱った依存性逆転の原則を、提唱者自身の解説で体系的に学べます。
オニオン・ヘキサゴナル・クリーンアーキテクチャの違いを比較
これまで3つの特徴を見てきましたが、結局のところ何が違うのでしょうか。結論を言うと「表現の抽象度」と「制約の厳しさ」が異なります。
ヘキサゴナルは「外との境界線」にフォーカスし、オニオンは「内側のレイヤー構造」をより詳細に定義しました。
クリーンは、それらを統合した上で「依存方向のルール」を最も厳格に体系化しています。
3つは対立する概念ではなく、カメラのズーム倍率を変えて同じ対象を見ているような関係です。
3つのアーキテクチャ比較一覧表
| 比較項目 | オニオン | ヘキサゴナル | クリーン |
|---|---|---|---|
| 提唱者 | Jeffrey Palermo（2008年） | Alistair Cockburn（2005年） | Robert C. Martin（2012年） |
| 設計思想 | ドメインを中心に据えるレイヤー構造 | 外部との接続をポートとアダプタで整理 | 依存性逆転を全層に厳格適用 |
| 構造の表現 | 同心円（玉ねぎ） | 六角形（多方向接続） | 4色の同心円 |
| レイヤー | Domain Model → Domain Services → Application Services → Infrastructure | Application Core ← Ports ← Adapters | Entities → Use Cases → Interface Adapters → Frameworks |
| 依存ルール | 外→内の一方通行。インターフェースを内側に、実装を外側に配置 | ポートを介した疎結合（内部構造は自由） | 外→内の完全一方通行（例外なし） |
| 自由度 | 中程度 | 高い | 低い（厳格） |
| 適用場面 | DDD採用のプロジェクト | 外部接続が多い・変更頻度が高いシステム | 大規模・長期運用・複数チーム |
構造の表現方法の違い
ヘキサゴナルは「対称性」を重視し、入力側（Driver）と出力側（Driven）を同じレベルで扱います。
対してオニオンは「中心に向かう」という同心円状の構造を強調し、よりレイヤー同士の上下関係が直感的です。
クリーンはさらにそれを整理し、4つの円という極めて具体的なテンプレートを提示しました。
どれも本質は「依存の逆転」ですが、チームに説明する際に「六角形」で語るか「玉ねぎ」で語るか「4色の円」で語るかという、コミュニケーション上の選択肢が生まれているわけです。
設計ルールの厳密さと自由度の差
実装の自由度という観点では、ヘキサゴナルが最も自由で、クリーンが最も厳しいと感じるはずです。
ヘキサゴナルは「ポートとアダプタさえ守れば、中身はどう作ってもいいよ」というスタンスです。
一方のクリーンは、依存関係の方向や層の役割が細かく規定されており、それに従わないと「クリーンではない」と判断されがちです。
私の経験上、初心者が多いチームでヘキサゴナルをやると中身が混沌としやすく、逆にクリーンを厳格にやりすぎるとコード量が増えすぎて疲弊する傾向があります。
プロジェクト規模別アーキテクチャの選び方
「で、私のプロジェクトにはどれがいいの？」という質問への答えは、プロジェクトの寿命とチームの成熟度に依存します。
私が数々のプロジェクトで失敗と成功を繰り返してきた結果、導き出した一つの基準をお伝えしましょう。
結論として、最初は「ヘキサゴナル」のポートとアダプタを意識しつつ、プロジェクトが大きくなるにつれて「クリーン」の規律を取り入れていくのが最も現実的で失敗が少ないルートです。
最初からクリーンを完璧に目指すと、ボイラープレート（定型文のようなコード）の多さに心が折れます（笑）。
小規模・個人開発で考える選択軸
個人開発や、数ヶ月で終わるような小さなプロジェクトであれば、ヘキサゴナルアーキテクチャの考え方を取り入れるだけで十分です。
データベースをインターフェースで隠す。
それだけで、いざという時の変更に対応できますし、テストも書けるようになります。
あまりに重厚なクリーンアーキテクチャを採用してしまうと、一つの機能を作るために10個以上のファイルを作る羽目になり、開発スピードが著しく落ちてしまいます。
身軽さを保ちつつ、要所だけ締めるのがコツです。
チーム開発・長期運用で考える選択軸
3年、5年と続く大規模なプロジェクトや、複数チームで開発する場合は、クリーンアーキテクチャのような「厳格な規律」が必要になります。
誰が書いても同じような構造になる強制力こそが、長期的なメンテナンス性を担保するからです。
オニオンアーキテクチャのドメイン中心という考え方も非常に有効です。
複雑なビジネス要件をドメインモデルに閉じ込めることで、仕様変更のたびに関連箇所を全検索するような、地獄の作業から卒業できるでしょう。
現場でよくある誤解と、少し現実的な捉え方
アーキテクチャを学び始めると、どうしても「正解」を探したくなります。
「このフォルダ構成はクリーンアーキテクチャ的に正しいのか？」と悩み、コードレビューで議論が白熱する。
それ自体は素晴らしいことですが、あまりに教条主義になりすぎるのも問題です。
現場で大切なのは、アーキテクチャの「名前」を守ることではなく、その「目的」を達成することです。
私も昔、クリーンアーキテクチャを盲信して、逆にコードを複雑にしてしまった苦い経験があります。
どれか一つを厳密に守らないといけないわけではない
「うちはオニオンだから、ヘキサゴナルの考え方は入れない」なんて考える必要はありません。
これらは互いに補完し合う関係です。
クリーンアーキテクチャをベースにしつつ、接続部分はヘキサゴナルのように「ポート」として定義し、中身はドメインを主役に据える。
そんな「いいとこ取り」が現場では日常的に行われています。
大事なのは自分たちが何を守りたくて、そのためにどのルールを採用しているのかを言語化できているかどうかです。
思想を理解して部分的に取り入れるという選択
「今のプロジェクトに導入するには、最初から書き直さないとダメですか？」と聞かれることがありますが、そんなことはありません。
まずは、外部APIを叩く処理をインターフェースの裏側に隠すことから始めてみてください。
あるいは、計算ロジックだけを「純粋な関数」として切り出すだけでもいいでしょう。アーキテクチャの思想を少しずつコードに染み込ませていく。
その一歩が、数年後の自分や後任のエンジニアを救う最高の手土産になるのです。
まとめ：アーキテクチャの違いを実務に活かすポイント
3つのアーキテクチャの違いを整理できた今、あなたのエンジニアとしての視座は一段高くなっているはずです。
これからは「なんとなくフォルダを分ける」のではなく、「依存関係を制御するためにインターフェースを定義しよう」という、意図を持った設計ができるようになります。
この「意図」こそが、プロのエンジニアとアマチュアを分ける境界線です。
言葉の定義を正しく使い分けられるようになれば、チームメンバーとの議論もより建設的で、楽しいものに変わっていくでしょう。
アーキテクチャ名を目的ではなく手段として使う
「クリーンアーキテクチャを導入すること」を目的にしてはいけません。
それはあくまで、バグを減らし、変更を容易にし、開発者のストレスを下げるための「手段」です。
アーキテクチャという武器を振り回すのではなく、目の前の課題を解決するために最も適した刃を選ぶ。そんな冷静な視点を持ってください。
もし、「この要件にこのアーキテクチャは重すぎるな」と判断できるようになったなら、あなたはすでに設計の初心者から脱出している証拠です。
オニオン・ヘキサゴナル・クリーンアーキテクチャに関するよくある質問
オニオンアーキテクチャとクリーンアーキテクチャの違いは何ですか？
どちらもドメイン中心・依存性逆転という思想は共通ですが、クリーンアーキテクチャはユースケース層を明確に独立させ、依存性のルールをより厳密に定めています。オニオンはレイヤーの円環構造を重視し、クリーンはユースケースを主役に据える点が実務上の違いです。
ヘキサゴナルアーキテクチャとクリーンアーキテクチャの違いは何ですか？
ヘキサゴナル（ポート＆アダプタ）は「内部と外部の境界」に焦点を当てた設計で、外部依存をポートとアダプタで抽象化します。クリーンアーキテクチャはこの考え方を取り込みつつ、レイヤーをより細かく（Entities・Use Cases・Interface Adapters・Frameworks）分割している点が異なります。
小規模プロジェクトでもこれらのアーキテクチャは必要ですか？
小規模・短命なプロジェクトでは過剰設計になりがちです。ドメインロジックが薄く変更頻度も低い場合は、シンプルなレイヤードアーキテクチャで十分なケースが多く、「アーキテクチャ導入自体」を目的化しないことが重要です。
