クリーンアーキテクチャとは？設計原則・レイヤー構造を解説【2026年版】

クリーンアーキテクチャとは？基本概念

クリーンアーキテクチャ（Clean Architecture）は、ロバート・C・マーチン（通称「アンクルボブ」）が2012年に提唱したソフトウェアアーキテクチャの設計原則です。その核心は「依存関係は常に内側（ドメイン）に向ける」というシンプルかつ強力な原則にあります。

この原則により、ビジネスロジックがフレームワーク・UI・データベース・外部APIなどの技術的要素に依存しない設計を実現します。技術の変化に強く、テストが容易で、長期間メンテナブルなシステムを構築できる点が最大の特徴です。

クリーンアーキテクチャの4つの層

1. エンティティ層（最内部）

ビジネスの本質的なルールを表すオブジェクトの層です。特定のアプリケーションロジックに依存せず、ビジネスの根幹をなす不変のルールを保持します。例えば「注文の合計金額は税込価格で計算する」といったルールがここに属します。この層は外部の変化（フレームワークの変更・DBの変更など）の影響を受けません。

2. ユースケース層

アプリケーション固有のビジネスロジックを担当する層です。「ユーザーが商品を購入する」「管理者が在庫を更新する」といったアプリケーションの具体的な操作を表します。エンティティ層に依存しますが、フレームワークやデータベースには依存しません。

3. インターフェースアダプター層

ユースケースとフレームワーク・外部ツールの間でデータ変換を行う層です。コントローラー・プレゼンター・ゲートウェイなどがここに含まれます。ユースケースが期待する形式にデータを変換したり、その逆を行ったりする役割を担います。

4. フレームワーク・ドライバー層（最外部）

Webフレームワーク・データベース・UI・外部APIなどの具体的な技術が配置される層です。この層はシステムの詳細（技術的実装）を担当し、変更が最も多い部分ですが、内側の層には影響を与えません。

依存関係の逆転原則（DIP）

クリーンアーキテクチャの要となるのが「依存関係の逆転原則（Dependency Inversion Principle）」です。外側の層が内側の層に依存し、内側の層は外側の層を知らないという設計を実現するため、インターフェース（抽象）を介して依存関係を逆転させます。例えば、ユースケース層はデータベースの具体的な実装（MySQL・PostgreSQLなど）を知る必要がなく、「リポジトリインターフェース」という抽象に依存します。データベースを変更しても、ユースケース層のコードを変更する必要がありません。

クリーンアーキテクチャの実装方法

ディレクトリ構成の例

クリーンアーキテクチャを実装する際の典型的なディレクトリ構成では、domain（エンティティ・値オブジェクト・リポジトリインターフェース）・usecase（アプリケーションサービス）・interface（コントローラー・プレゼンター）・infrastructure（リポジトリ実装・DBクライアント）という4層に分けて配置します。

各層の実装ポイント

• エンティティ：外部依存のないPure Classとして実装
• ユースケース：リポジトリをインターフェースとして受け取りDI（依存性注入）を活用
• インフラ層：リポジトリインターフェースを実装し、具体的なDB操作を記述

クリーンアーキテクチャとDDDの関係

DDD（ドメイン駆動設計）とは

DDDはビジネスの複雑さをドメインモデルに封じ込め、ドメイン専門家と開発者が共通言語（ユビキタス言語）でコミュニケーションする設計手法です。

クリーンアーキテクチャとDDDの違い

クリーンアーキテクチャはアーキテクチャの「構造・依存関係の方向」を規定するものであり、DDDはビジネスロジックの「意味・モデリング方法」を規定するものです。両者は補完関係にあり、DDDで設計したドメインモデルをクリーンアーキテクチャの層構造に配置するという組み合わせが一般的です。

クリーンアーキテクチャのメリット・デメリット

メリット

• フレームワーク・DBの変更が容易（技術的負債が溜まりにくい）
• ユニットテストが書きやすい（依存関係が明確なためモックが容易）
• チーム開発での責務分離が明確
• 長期的なメンテナビリティが高い

デメリット

• 初期の設計コストが高く、小規模プロジェクトではオーバーエンジニアリングになりやすい
• ボイラープレートコードが増えがち
• チームメンバーの理解・習熟が必要

よくある質問（FAQ）

あわせて読みたい

• AIコンサルティングの4つの型
• AI導入の相談前に準備すべき5つのこと