Clean Architecture は AI時代に過剰設計か、それとも救世主か

この記事でわかること:

• Clean Architectureの本質的価値と現代的課題
• AI時代における適否の判断基準
• 2026年の現場での折衷案

結論: 適切に使えば救世主、雑に使えば過剰設計

Clean Architecture（Robert C. Martin著、2017年）はAI時代に「過剰設計か、それとも救世主か」という議論が続いています。結論を先に言うと、適切に使えば救世主、雑に使えば過剰設計です。判断軸を整理します。

Clean Architectureの本質

Clean Architectureの核心は2つです。

1. レイヤー分離: Entity / UseCase / Adapter / Frameworkの同心円
2. 依存性逆転の原則（DIP）: 内側のレイヤーは外側を知らない

これにより、ビジネスロジック（UseCase）はDB・UI・フレームワークから独立し、テストしやすく、変更に強いコードベースが作れます。

AI時代の救世主としての側面

1. テスト容易性が高い

UseCaseが純粋関数に近いため、AIエージェントが容易にテストコードを生成できます。モックも最小限で済みます。

2. 変更影響範囲が限定される

DBを切り替えてもUseCaseは変えなくてよい、UIを変えてもビジネスロジックは無傷—この性質はAIが安全に改修するうえで強力です。

3. 構造が明示的

レイヤーごとにディレクトリが分かれているため、AIが「どこに何を書くべきか」を迷いません。

過剰設計としての側面

1. ボイラープレートの多さ

1機能追加で、Entity・Repository Interface・UseCase・Controller・DTOと5ファイル以上作る必要があります。小規模プロジェクトでは明らかに過剰です。

2. AIが書く量が増える

AIに任せても5ファイル分の生成が必要で、トークン消費と時間が増えます。シンプルなCRUDなら冗長すぎます。

3. 学習コストが高い

初学者にとってレイヤー分けの原則を理解するのが難しく、結果として「形だけClean」な実装になりがちです。

判断基準

採用が向くケース

• 業務ロジックが複雑（金融、医療、保険など）
• 長期メンテナンス（5年以上）を想定
• チームに経験者がいる
• 外部依存（DB、API）が頻繁に変わる可能性

採用が向かないケース

• シンプルなCRUDが大半
• プロトタイプ・MVP段階
• 3年以内に作り直し前提
• チーム全員がClean Architectureに不慣れ

2026年の折衷案: Lightweight Clean

多くのチームは「軽量版Clean Architecture」を採用しています。レイヤーは3つ（Domain / UseCase / Adapter）に簡素化し、DTOやMapperは必要な時だけ作るアプローチです。

具体的なディレクトリ構造の例:

src/
  domain/      # Entity、ValueObject
  usecase/     # ビジネスロジック
  adapter/     # DB、API、UI
  infra/       # フレームワーク依存

これにより、Cleanの恩恵を残しつつボイラープレートを抑えられます。AIエージェントもこの3層構造ならスムーズに書けます。

事例: SaaSスタートアップ

あるBtoB SaaSでは、創業1年目は最低限のレイヤー分けで開始し、ユーザーが1万社を超えた段階で軽量Cleanに移行しました。テスト網羅率が48%から81%に上がり、AIが書いたPRのバグ率が半減しました。

逆に、創業初期からフルCleanを導入した別のスタートアップでは、機能追加速度が遅すぎて競合に先を越され、設計を捨てる結果になりました。タイミングが重要です。

AIとの相性を上げる工夫

Clean Architectureを採用するなら、以下を併用するとAI効果が最大化します。

• 各レイヤーにREADME.mdを置き、責務を明記
• UseCaseのテンプレートをスニペット化
• CLAUDE.mdに「各レイヤーで書くべきこと・書くべきでないこと」を明記
• linterでレイヤー違反を検知

まとめ

Clean ArchitectureはAI時代に有効ですが、プロジェクトの段階と複雑性によって適否が変わります。MVP段階なら避け、複雑性が増したタイミングで軽量Clean に移行するのが現実解です。2026年は「原則は守りつつ、軽量化する」のがバランスの取れた選択肢です。