クリーンアーキテクチャとは｜4層構造とDDDの関係を実務目線で解説

クリーンアーキテクチャとは

クリーンアーキテクチャは、2012年にRobert C. Martin氏（通称Uncle Bob）がブログで提唱した設計思想です。翌年以降、書籍『Clean Architecture』などを通じて広く知られるようになりました。

同心円状の図を思い浮かべてください。中心には業務ルールがあり、外側にDB・Web・UI・フレームワークが配置されます。ここで最も重要なのが、依存の矢印を必ず「外→内」の方向に向けるという一貫したルールです。

「クリーン」の意味

クリーンとは、業務ルールが外部要因（フレームワーク、DB、UI、外部API）に汚染されていない状態を指します。フレームワークをバージョンアップしても、DBをMySQLからPostgreSQLに切り替えても、業務ロジックへの変更を最小化しやすい。これが「クリーン」の実務的な意味です。DB固有機能やORM制約により内側に影響が及ぶケースはあるため「完全にゼロ」を保証するものではありません。

提唱の背景

Uncle Bobは、それ以前にヘキサゴナルアーキテクチャ（Alistair Cockburn氏、2005年頃）、オニオンアーキテクチャ（Jeffrey Palermo氏、2008年）、DCIアーキテクチャなど、複数の設計手法が「同じことを違う言葉で言っている」と指摘しました。共通していたのは「ビジネスロジックを外側の関心事から隔離する」という発想です。これらを統合・整理したものがクリーンアーキテクチャです。

中心思想は「依存性の方向」

クリーンアーキテクチャで最重要のルールが依存性のルール（The Dependency Rule）です。ソースコードの依存関係は、外側の円から内側の円へのみ向かなければなりません。内側の層は、外側の層の存在を一切知りません。

4層構造とそれぞれの責務

クリーンアーキテクチャの図では4つの層が示されますが、実装では層数はプロジェクトによって前後します。まずは典型的な4層で整理します。

Entities（最内層）

事業そのもののルールです。たとえば「注文金額は税抜き合計に消費税を加算する」「会員ランクは年間購入額で決まる」といった、ビジネス側で決められた不変の性質を表現します。

Entitiesは業務のあり方が変わらない限り変わりません。フレームワークやDBが変わったからといって書き換えるものではない、というのがポイントです。

Use Cases

ユーザーがシステムに対して行う「1回のやりたいこと」を表現する層です。「商品を購入する」「配送先を変更する」といった具体的なシナリオを扱います。

Use CasesはEntitiesを組み合わせて操作を組み立てますが、DBへの永続化やHTTPレスポンス生成の詳細は知りません。永続化は「PurchaseRepositoryにsaveと投げる」というインターフェース越しに依頼するだけです。

Interface Adapters

外部世界とUse Casesの間で、データ形式を翻訳する層です。

• Controller：HTTPリクエストをUse Casesが理解できる形へ変換

• Presenter：Use Casesの結果を、画面表示用のViewModelへ変換

• Gateway（Repository実装）：Use Casesが定義したインターフェースを、実際のDBアクセスに変換

「翻訳者」の層と考えると理解しやすいでしょう。

Frameworks & Drivers（最外層）

Spring Boot、Rails、Laravel、Express、Djangoといったフレームワーク本体。PostgreSQL、MySQL、Redisといったミドルウェア。React、Vue、Blade、Thymeleafといったビュー層。これらは全て最も外側に配置される「詳細」です。

技術選定は変わりうる。だから中央に置かず端に置く。この配置の哲学がクリーンアーキテクチャの核心です。

依存性のルールと依存性逆転の原則

「Use CasesがDBにアクセスするなら、Use Cases → DB という依存が発生するのでは？」という疑問がここで出てきます。答えは依存性逆転の原則（DIP：Dependency Inversion Principle）で解決します。

依存性逆転の原則の役割

Use Casesは自分が必要とするデータ操作を、自らインターフェースとして定義します。たとえば「注文を保存する OrderRepository」というインターフェースをUse Cases側に置きます。DBアクセスの実装（外側の層）は、そのインターフェースを実装する側に回ります。

結果として、実装コード上の依存は「DB実装 → インターフェース（内側）」の方向になります。矢印は常に外から内へ、というルールが崩れません。

境界を跨ぐデータの受け渡し

層をまたぐときは、フレームワーク特有の型（HttpServletRequestなど）をそのまま渡してはいけません。プレーンなデータ構造（DTOやRecord）に詰め替えて渡します。これによって内側の層が外側のフレームワークに縛られなくなります。

DDDとの関係と違い

「DDD（ドメイン駆動設計）とクリーンアーキテクチャは同じでは？」という質問はよく出ます。実務では両者を組み合わせて語られることが多いですが、目的は別物です。

DDDとクリーンアーキテクチャの位置づけ

DDDは「何を作るか」を業務側と揃えるアプローチ、クリーンアーキテクチャは「作ったものをどう配置するか」の指針、と分けて理解すると混乱しにくくなります。

組み合わせて使われる理由

DDDで抽出したエンティティ・値オブジェクトは、クリーンアーキテクチャのEntities層に自然に収まります。ドメインサービスやアプリケーションサービスはUse Cases層と親和性が高い。両者が組み合わせて語られるのは、この収まりの良さが理由です。

よくある誤解

「DDD＝クリーンアーキテクチャ」ではありません。DDDを取り入れつつも従来のレイヤードで実装しているプロジェクトはありますし、逆にDDDの概念を使わずにクリーンアーキテクチャのフォルダ構造だけを採用しているケースもあります。

現場でのミニ質問

Q. DDDを知らないとクリーンアーキテクチャは書けませんか？

A. 書けます。ただしEntities層で扱う「業務ルール」を整理するときにDDDの語彙（集約、値オブジェクト）を知っていると設計判断がスムーズになります。学習順としては、クリーンアーキテクチャの4層を先に押さえ、必要に応じてDDDに踏み込む流れが取り組みやすいでしょう。

似た設計手法との違い

同じ発想を共有する設計手法との位置関係を整理しておきます。

ヘキサゴナル・オニオン・クリーンは共通する発想が強く、実務上は近い文脈で語られることが多い関係です。厳密には重視点や表現体系が異なりますが、用語の細部にこだわりすぎず「依存を内向きに揃える」という共通目的を押さえておけば入り口として十分です。

実装時の判断ポイントと迷いやすい落とし穴

理論を知っていても、実装に落とすときは選択肢の連続です。現場で頻出する迷いどころを整理します。

フォルダ構成の悩み

層ごとにフォルダを分けるか、機能（feature）ごとに分けるか、で必ず議論になります。層で分けると全体像は掴みやすいものの、1つの機能変更で複数フォルダを触ることになります。機能で分けると変更範囲は集約できますが、依存ルールの見通しはやや悪くなります。

小〜中規模プロジェクトは「機能で分けた中に層を作る」ハイブリッドが扱いやすい部類です。ただしチーム規模や既存資産により最適解は変わります。

ORMの扱い

JPA、Eloquent、ActiveRecord、Prisma、Ent などのORMは、便利さと引き換えにエンティティをORMの型に縛る傾向があります。厳密に分離する設計では、DBに永続化するためのPersistence用モデルと業務ロジック上のEntitiesを分ける方針が採られることがあります。一方で分離しない流派も存在し、プロジェクトの規模やチーム方針で選択が分かれます。

とはいえ小規模プロジェクトで完全に分離するとコード量が増えて割に合わないケースもあります。「ORMの型を業務ロジックが直接触らない」ラインを守るところから始めるのが実務的です。

DTOの粒度

Use Casesの入力（Input Boundary）と出力（Output Boundary）は、プレーンなDTOで受け渡します。フレームワークのRequest／Responseオブジェクトをそのまま使ってはいけません。ただしDTOを層ごとに全て別クラスにすると、コピー処理が大量発生します。責務の切り替えが明確な境界（Controller↔Use Cases、Use Cases↔Repository）だけDTOを設けるのが現実解です。

インターフェースの過剰化

依存性逆転を意識するあまり、あらゆるクラスにインターフェースを切ってしまうケースがあります。入れ替え可能性が本当に必要な境界のみ（永続化、外部API、通知など）にインターフェースを設けるのが健全です。

ミニ質問

Q. Use Casesは1メソッドにつき1クラスにすべき？

A. 提唱者は「1 Use Case = 1 クラス」を推奨していますが、実務では類似操作を集約したServiceクラスにまとめるチームもあります。方針はプロジェクトで統一するほうが可読性を保ちやすくなります。

導入すべきプロジェクトの判断基準

クリーンアーキテクチャは万能ではありません。導入判断の目安を整理します。

向いているケース

• 業務ルールが複雑で、事業側との仕様調整が頻繁に発生する

• 長期運用（5年以上）を前提とし、フレームワークやDBの入れ替えが将来ありうる

• テストコードを厚くしたい（Entities／Use Cases単体でテスト可能な構造を活かせる）

• 複数チームで並行開発する規模で、責務の境界が明確なほうが良い

向いていないケース

• 小規模なCRUD中心のWebアプリで、業務ルールがほとんどない

• プロトタイプ・PoCで短期に検証したい

• 少人数（1〜2人）で機能追加が中心のフェーズ

判断の目安フロー

1. 業務ルールが「単なるCRUD」ではなく、条件分岐や計算ロジックが多いか？

2. フレームワークやDBを将来入れ替える可能性があるか？

3. テスト容易性を長期にわたり確保したいか？

4. 3項目のうち2つ以上に該当するなら導入検討価値あり。全て「No」なら従来のMVC／レイヤードで十分な可能性が高いです。ただし既存システムとの整合性やチームの設計経験も併せて判断が必要です。

フリーランスエンジニアから見たクリーンアーキテクチャ

ここからは、設計概念そのものではなく、フリーランス案件でどう評価されるかを補足します。以下の記述は、2026年7月時点で主要フリーランスエージェント（レバテックフリーランス、フリーランスHub、フリコンなど）の公開案件を確認した範囲で見られる傾向をベースにしています。時期・エージェント・商流によって数字は変動します。

案件での関わり方

新規開発の設計フェーズから参画するケースでは、アーキテクチャ選定・レイヤー設計・DDDとの統合の議論に加わります。エンタープライズ規模の業務システム（金融、SaaS、EC基盤）で募集が見られる傾向があります。特に、業務ルールが複雑で、外部連携や長期保守を前提とする案件で採用されやすい傾向があります。

既存プロジェクトの保守・機能追加フェーズから参画するケースでは、既に採用されているアーキテクチャの意図を読み解き、その方針に沿った実装ができるかが問われます。中堅〜大規模の業務システム保守で頻出です。

面談で問われるポイント

公開案件のスキル要件や、経験者から聞かれるヒアリング項目としてよく挙がるのは次のような論点です。

• 依存性のルールを自分の言葉で説明できるか

• DDDとクリーンアーキテクチャの違いを整理して話せるか

• ORMを使ううえでのEntities分離の実務経験

• 実装での「線引きの妥協点」をどう決めたか

• テストの書き分け（Use Cases単体テスト／Interface Adaptersのモックテスト）

単価に与える影響

アーキテクチャそのものが単価を決めるわけではありませんが、業務ドメイン理解と設計判断が求められる案件は上限が高くなる傾向があります。2026年7月時点の公開案件ベースでは、バックエンド設計経験や上流工程経験を前提に「クリーンアーキテクチャ／DDD経験」を明示している募集で月額80万〜120万円前後のレンジが見られます。特に、テックリード経験・要件整理・設計レビュー経験がある人材向けでは、それ以上の募集も見られます。単価は言語・商流・稼働率・地域・上流経験で大きく変わるため、あくまで公開案件の観測レンジとして参考にしてください。

学習の順序

1. 従来のレイヤードアーキテクチャとMVCを実装レベルで理解する

2. SOLID原則、特に依存性逆転（DIP）を書けるようになる

3. 『Clean Architecture』（Robert C. Martin著）で全体像を掴む

4. 実際のプロジェクト（自作でも既存の勉強用リポジトリでも）で4層構造を実装してみる

5. DDDの入門書（『実践ドメイン駆動設計』など）で語彙を補完する

6. ORMの扱い、テスト戦略、フォルダ構成を現場のコードで実感していく

まとめ

クリーンアーキテクチャは、依存の矢印を必ず内側に向けることでビジネスロジックを外部要因から独立させる設計思想です。以下のポイントを押さえておきましょう。

• 中心思想は「依存性のルール」の一言に集約される

• 4層はあくまで例示。層数よりも依存方向のほうが重要

• DDDは業務モデリング、クリーンアーキテクチャは依存関係の設計と、目的を分けて理解する

• ヘキサゴナル・オニオンはほぼ同じ発想の別名で、用語より共通目的を押さえる

• 過剰設計のリスクがあるため、導入範囲は業務複雑度と運用期間で判断する

• フリーランス案件では設計フェーズから関われる募集で経験が評価されやすい傾向がある

長期運用する業務システムを担う際は、コードの「配置ルール」を持っておくと保守判断がぶれません。次のステップとして、書籍で全体像を押さえた後に、既存プロジェクトのコードを層ごとに分解して読む練習をおすすめします。フリーランスとしてキャリアの選択肢を広げたい方は、フリコンの非公開案件情報も併せて確認してみてください。

参考リンク

• The Clean Architecture（Robert C. Martin公式ブログ）

• Hexagonal Architecture（Alistair Cockburn）

• 書籍『Clean Architecture 達人に学ぶソフトウェアの構造と設計』（KADOKAWA）