Clean Architectureって何？まずは基本を理解しよう
Clean Architecture（クリーンアーキテクチャ）は、ソフトウェアの設計方法の一つです。有名なソフトウェアエンジニア、ロバート・C・マーチン（通称Uncle Bob）が提唱しました。
「アーキテクチャ」という言葉は難しく聞こえるかもしれませんが、要するに「プログラムの構造をどう組み立てるか」という設計の考え方です。
身近な例で例えると 家を建てるとき、リビング、キッチン、寝室を適切に配置して、住みやすい家を作りますよね。Clean Architectureも同じように、プログラムの各部品を適切に配置することで、「変更しやすく、壊れにくいソフトウェア」を作る方法なのです。
なぜClean Architectureが必要なの？
プログラムは一度作って終わりではありません。機能追加、バグ修正、技術の更新など、常に変化し続けます。
よくある問題
- データベースを変更したら、画面のコードまで修正が必要になった
- 一つの機能を変更したら、他の機能が壊れてしまった
- テストを書きたいけど、どこから手をつければいいかわからない
Clean Architectureは、こうした問題を解決するための設計原則です。
Clean Architectureの4つの層を理解しよう
Clean Architectureは、プログラムを4つの層（レイヤー）に分けて考えます。これらは同心円のように配置され、中心に行くほど重要な部分になります。
第1層：Entities（エンティティ層）- 最も内側
役割：ビジネスの核となるルールを管理
ここには、アプリケーションの「本質的なルール」が入ります。例えば、ECサイトなら「商品」「注文」「顧客」といった概念と、それらに関する基本的なルールです。
具体例
- 「注文金額は0円以上でなければならない」
- 「ユーザーのメールアドレスは一意である」
- 「商品の在庫は負の数にならない」
この層は、UIの見た目やデータベースの種類が変わっても、絶対に変わらない部分です。
第2層：Use Cases（ユースケース層）
役割：アプリケーション固有の処理の流れを定義
「ユーザー登録する」「商品を購入する」「レビューを投稿する」といった、アプリケーション特有の操作の手順を書きます。
具体例：ユーザー登録のユースケース
- 入力されたメールアドレスが既に登録されていないか確認
- パスワードが条件を満たしているか検証
- ユーザー情報を保存
- 確認メールを送信
この層も、UIやデータベースの詳細は知りません。「何をするか」だけを定義します。
第3層：Interface Adapters（インターフェースアダプター層）
役割：データの形式を変換する
内側の層（ビジネスロジック）と外側の層（UIやDB）の間で、データの形式を変換します。通訳のような役割です。
具体例
- Webフォームから送られてきたデータを、Use Caseが理解できる形に変換
- Use Caseから返ってきた結果を、画面表示用のJSONに変換
- ビジネスオブジェクトを、データベース保存用の形式に変換
含まれるもの
- Controller（コントローラー）：入力を受け取る
- Presenter（プレゼンター）：表示用にデータを整形
- Gateway（ゲートウェイ）：データベースアクセスの窓口
第4層：Frameworks & Drivers（フレームワーク＆ドライバー層）- 最も外側
役割：具体的な技術の実装
実際の技術やツールを使う部分です。変更が最も頻繁に起こる層でもあります。
含まれるもの
- UIフレームワーク（React、Vue.js、SwiftUIなど）
- データベース（MySQL、PostgreSQL、MongoDBなど）
- Webフレームワーク（Express、Django、Railsなど）
- 外部API連携
依存性ルール：Clean Architectureの最重要原則
Clean Architectureには、絶対に守らなければならないルールがあります。それが「依存性ルール」です。
ルール：依存の方向は常に外側から内側へ
簡単に言うと、
- 外側の層は内側の層を知っていてOK
- 内側の層は外側の層を知ってはいけない
具体例で理解しよう
❌ ダメな例
ビジネスロジック → データベース（MySQL）を直接参照
この場合、MySQLから別のDBに変更すると、ビジネスロジックも変更が必要になります。
✅ 良い例
ビジネスロジック → データ保存の抽象的な窓口
↑
MySQL実装
この場合、データベースを変更しても、ビジネスロジックは影響を受けません。
なぜこのルールが重要？
内側の層（ビジネスロジック）は、アプリケーションの最も重要な部分です。これが外側の技術的な詳細（UIやDB）に依存してしまうと、技術を変更するたびにビジネスロジックまで変更が必要になってしまいます。
Clean Architectureのメリット：なぜ採用すべき？
技術の選択肢が広がる
フレームワークに縛られない Reactで作ったUIを、将来Vue.jsに変更することも可能です。ビジネスロジックはそのまま使えます。
データベースを自由に変更できる 開発初期はSQLiteを使い、本番環境ではPostgreSQLを使う、といったことが簡単にできます。
テストが書きやすい
ビジネスロジックを、UIやデータベースなしでテストできます。これにより、
- テストの実行速度が速い
- テストが安定する（外部要因の影響を受けない）
- テストの作成が簡単
変更に強い
機能追加や修正をしても、影響範囲が限定的です。
- UIの変更 → ビジネスロジックは無傷
- データベースの変更 → ビジネスロジックは無傷
- ビジネスルールの変更 → 該当する部分だけ修正
チーム開発がしやすい
役割が明確なので、分担しやすくなります。
- Aチーム：UIを担当
- Bチーム：ビジネスロジックを担当
- Cチーム：データベース周りを担当
それぞれが独立して作業できるため、効率的です。
Clean Architectureのデメリット：注意点も知っておこう
学習コストが高い
初めて触れる人には、「なぜこんなに複雑にするの？」と感じられるかもしれません。概念の理解に時間がかかります。
初期開発に時間がかかる
シンプルな機能でも、多くのファイルや抽象化が必要です。プロトタイプを素早く作りたい場合には不向きです。
小規模プロジェクトには過剰
簡単なツールや個人開発の小さなアプリには、複雑すぎる場合があります。
チーム全体の理解が必要
一部のメンバーだけが理解していても効果は薄く、チーム全員が原則を守る必要があります。
Clean Architectureはこんなプロジェクトにおすすめ
適しているケース
- 長期運用が予定されているプロジェクト
- 大規模なチームでの開発
- 頻繁な機能追加や変更が予想される
- 複数のプラットフォーム（Web、モバイル）で同じビジネスロジックを使いたい
- テストを重視したい
適していないケース
- 短期間で完成させるプロトタイプ
- 個人開発の小規模アプリ
- 要件が不明確で頻繁に大きく変わる可能性がある初期段階
- 学習コストをかけられない状況
他のアーキテクチャパターンとの関係
MVCやMVVMとの違い
MVC（Model-View-Controller）やMVVMは、主にUIの構造を整理するパターンです。一方、Clean Architectureは、アプリケーション全体の構造を定義する、より包括的な原則です。
VIPERとの関係
VIPERは、Clean Architectureの原則を具体的に実装したパターンの一つです。特にiOS開発でよく使われます。
- VIPER：具体的な実装パターン
- Clean Architecture：抽象的な設計原則
Clean Architectureという大きな傘の下に、VIPERやその他のパターンが存在するイメージです。
実践例：ユーザー登録機能で理解しよう
Clean Architectureで「ユーザー登録機能」を実装する場合、各層での役割は以下のようになります。
Entities層
ユーザーエンティティ
- メールアドレスは必須
- パスワードは8文字以上
Use Cases層
ユーザー登録ユースケース
1. メールアドレスの重複チェック
2. パスワードの妥当性検証
3. ユーザー作成
4. 確認メール送信
Interface Adapters層
- コントローラー：Web APIからのリクエストを受け取る
- プレゼンター：成功/失敗のレスポンスを整形
- リポジトリ：データベース保存の窓口
Frameworks層
- Express.js（Webフレームワーク）
- PostgreSQL（データベース）
- SendGrid（メール送信サービス）
データベースをMySQLに変更したい場合、Frameworks層のデータベース実装部分だけを変更すればOKです。ビジネスロジックには一切手を加えません。
まとめ：Clean Architectureで保守性の高いソフトウェアを作ろう
Clean Architectureは、「依存性の方向を制御する」という原則に基づいた設計手法です。
重要ポイントまとめ
- 4つの層（Entities、Use Cases、Interface Adapters、Frameworks）で構成
- 依存性は常に外側から内側へ
- ビジネスロジックを技術的な詳細から独立させる
- テストしやすく、変更に強いソフトウェアを作れる
- 学習コストと初期開発時間はかかる
- 大規模・長期運用プロジェクトに特に適している
プロジェクトの規模や目的に応じて、Clean Architectureの原則をどの程度厳密に適用するかを判断することが大切です。小さく始めて、必要に応じて段階的に導入していくのも良いアプローチです。
Clean Architectureの考え方を理解することで、より保守性が高く、長期的に成長できるソフトウェアを設計できるようになるでしょう。
