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