新しいプロジェクトを立ち上げるとき、バックエンドのアーキテクチャ選定は避けて通れない。Claude Code や GitHub Copilot といった AI コーディングツールが当たり前になった今、この選定にはもう一つ考慮すべき軸が加わった。AI が生成するコードの品質は、プロジェクトのアーキテクチャ設計に大きく依存するという事実である。
本記事では、AI 駆動開発を前提としたアーキテクチャ選定の判断基準を5つに整理し、主要なアーキテクチャパターンをその基準で比較する。読み終えた時点で、自分のプロジェクトに最適なパターンを選べる状態を目指す。
AI コーディングツールが突きつける「アーキテクチャの重要性」
結論から述べる。AI 駆動開発において、アーキテクチャの整備度合いはコード生成品質に直結する。
個人開発者が Claude Code とクリーンアーキテクチャ（Go + React）で 40万行規模のフルスタックプロジェクトを構築した事例がある。この事例では、整備されたアーキテクチャのもとで「既存パターンに沿った実装は比較的うまくいった」と報告されている。一方で、アーキテクチャが未整備の状態で AI エージェントを使うと「一貫性のない実装が生成されたり、既存のパターンを無視した実装が追加される」という問題が起きる。
この差は偶然ではない。AI コーディングツールはコンテキストウィンドウに読み込んだ情報をもとにコードを生成する。アーキテクチャが明確であれば、AI は既存のパターンを認識し、それに沿ったコードを出力する。逆に、パターンが曖昧な状態では、AI は毎回異なるアプローチを選択する可能性がある。
つまり、設計の質が AI の出力品質を決める。この前提に立つと、アーキテクチャ選定は単なる開発者体験の問題ではなく、AI との協働における生産性の根幹となる。
AI が「実装しやすい」アーキテクチャの5つの条件
AI 駆動開発に適したアーキテクチャには、共通する条件がある。リサーチの結果、以下の5つに整理できた。この5条件は、後述するアーキテクチャ比較の「評価軸」として機能する。
条件1: コンテキスト効率 ― 30〜50ファイル/モジュールが最適
AI コーディングツールの最大の制約はコンテキストウィンドウの大きさにある。大規模コードベースでは AI が全体を把握できず、重複機能の生成や一貫性のないパターンの適用が発生する。
具体的な指針として、1モジュールあたり30〜50ファイル程度に収めることが推奨されている。この規模であれば、AI がモジュール全体を理解し、エンティティ間の関係やパターンを把握できる。さらに、コンテキスト使用率が 70% を超えると応答品質が平均25%低下するとの報告もある。AI に渡すコンテキストは「必要十分」に留めることが重要となる。
条件2: 型安全性 ― 成功率を劇的に向上させる要因
型安全性の強化は、AI コード生成の品質に対して最もインパクトの大きい施策の一つである。mycoder.ai の開発者 Ben Houston は、自身のブログ記事 “Agentic Coding Best Practices” で、強い型付け（discriminated unions 等）の導入後、ルート/コマンド関連タスクの AI 成功率が 60% から 100% 近くに改善したと報告している。
型システムが厳密な言語（Rust、TypeScript の strict mode 等）では、AI の誤りをコンパイラが即座に検出し修正を促す。品質のフィードバックループが高速に回るため、AI が自律的にエラーを修正できる確率も上がる。
条件3: インターフェースによる境界の明示
依存性注入とインターフェース分離は、AI が実装すべき範囲を明確にする。AI は抽象インターフェースの実装に集中でき、他のコンポーネントとの結合を意識する必要がない。
この効果は具体的に3つの形で現れる。テストコードの自動生成が容易になること（モック実装が定型化される）、実装の差し替えがアダプタの入れ替えだけで完了すること、そして AI が生成するコードのスコープが自然と限定されることである。
条件4: 予測可能なファイル構成
AI は一貫性のあるパターンで最もよく動作する。ファイル構成が予測可能であれば、AI は関連コードの場所を推測でき、不要なファイル探索によるコンテキストの浪費を防げる。
推奨される構成原則は明快で、コンポーネントに関連するファイル（テスト、型、ユーティリティ）をコロケーションすること、各パッケージルートに README.md を配置すること、ディレクトリ階層はフラットに保ち深いネストを避けることの3点に集約される。
条件5: ドキュメントインフラ ― CLAUDE.md / AGENTS.md
CLAUDE.md や AGENTS.md によるコンテキストエンジニアリングが、AI 協調開発の基盤として確立されつつある。Anthropic の公式ガイドラインでは、CLAUDE.md は .gitignore と同様に「必須インフラ」であり、オプションのドキュメントではないと位置づけられている。
学術論文 “Codified Context: Infrastructure for AI Agents in a Complex Codebase”（arxiv、2026年2月）による 283の開発セッション（70日間）にわたる実証研究でも、構造化されたドキュメントが AI の出力品質を安定させることが確認された。この研究では、コンテキストインフラがコードベース全体の約24%を占める一方、人間プロンプトの80%以上が100語未満で済んでいた。ドキュメントに投資することで、人間側の指示コストが大幅に下がる。
ただし、CLAUDE.md の肥大化には注意が必要となる。推奨サイズは 60〜100行程度で、150〜200の指示が限界とされる。それ以上はモデルの注意力が低下するため、詳細な指示は別ファイルに分離して参照する方式が望ましい。
主要アーキテクチャパターンの比較
ここからは、前節で整理した5条件を評価軸として、主要なアーキテクチャパターンを比較する。各パターンの特徴を「AI 駆動開発における強みと弱み」の観点で整理していく。
なお、ヘキサゴナルアーキテクチャ（Ports and Adapters）もリサーチ対象に含めたが、依存性逆転とインターフェースによる境界定義という設計思想がクリーンアーキテクチャと共通するため、本記事ではクリーンアーキテクチャに代表させる形をとった。ポート/アダプタの概念は外部連携が多いシステムで特に有効であり、この点は「条件3: インターフェースによる境界の明示」で既に評価軸として反映している。
クリーンアーキテクチャ ― 境界の明確さとコンテキスト散在のトレードオフ
Robert C. Martin が提唱したクリーンアーキテクチャの核心は「依存性ルール」にある。ソースコードの依存方向は常に内側（より抽象的な層）に向かわなければならず、Entities、Use Cases、Interface Adapters、Frameworks & Drivers の4層で構成される。
AI 駆動開発での強みは明確である。依存性逆転によって、AI の実装範囲が自然と限定される。各層がインターフェースに依存するため、AI はインターフェースの仕様に従って具象クラスを実装するだけでよい。テスタビリティも高く、DI 構造によりモック実装が容易なため、AI が生成するテストコードの品質も向上する。
前述の40万行プロジェクトでは、クリーンアーキテクチャをベースにしつつ「実用性を考慮して DB 実装を簡略化」するなど、実用的な調整が行われている。
# 40万行プロジェクトのバックエンド構成（Go）
pkg/
├── application/ # config, db, interactors
├── domain/ # entity, usecases
└── presentation/ # handler, controller一方で、弱みも無視できない。レイヤーごとにディレクトリを分割するため、1つの機能に関連するクラスが複数ディレクトリに散らばる。AI が機能全体を理解するにはより多くのコンテキストが必要になり、コンテキスト効率（条件1）の面で不利に働く。各層の境界にインターフェースと DTO を定義する必要があるため、ボイラープレートも増加する。
| 5条件での評価 | 判定 |
|---|---|
| コンテキスト効率 | 中 ― レイヤー分散により機能単位での把握にコンテキストを消費 |
| 型安全性 | 高 ― インターフェース定義により型の恩恵を受けやすい |
| 境界の明示 | 高 ― 依存性逆転が AI の実装スコープを明確に限定 |
| 予測可能性 | 高 ― レイヤー構造が一貫したファイル配置を強制 |
| ドキュメントインフラ | 中 ― レイヤー間の関係を CLAUDE.md で補足する必要あり |
向いている場面: 大規模プロジェクト、複雑なドメインロジックを持つシステム、長期運用を前提としたプロダクト。
Vertical Slice Architecture ― コンテキスト効率と DRY のトレードオフ
Vertical Slice Architecture は、機能（ユースケース）単位でコードを垂直に分割するアプローチである。1つの機能に必要な全コンポーネント（API、ビジネスロジック、データアクセス）を1つのフォルダにまとめる。
AI 駆動開発での最大の強みは、コンテキスト効率にある。機能単位の凝集度が高いため、AI が1つのユースケースに必要な全コンテキストを効率的に取得できる。「局所性参照（locality of reference）」の最適化により、AI がコンテキストウィンドウを浪費せずに完全な機能コンテキストをロードできる点は、条件1の要件に最も直接的に対応する設計方針と言える。
機能間の依存が少ないことも利点となる。ある機能の変更が他の機能に影響を与えにくいため、AI が安心してコードを生成・修正できる。
トレードオフとして、DRY 原則を犠牲にする「重複税（duplication tax）」が発生する。機能間で類似のロジックが重複することを許容する設計であるため、共通処理の変更時には複数箇所を修正する必要がある。この重複を許容するかどうかが採用の分岐点になる。
| 5条件での評価 | 判定 |
|---|---|
| コンテキスト効率 | 高 ― 機能単位の凝集度が AI のコンテキスト制約と好相性 |
| 型安全性 | 中 ― パターン次第。機能ごとに型定義が分散する可能性あり |
| 境界の明示 | 中 ― 機能間の境界は明確だが、機能内の層の分離は弱い |
| 予測可能性 | 高 ― 機能名ベースのフラットな構成で直感的 |
| ドキュメントインフラ | 高 ― 機能単位で自己完結するため説明コストが低い |
向いている場面: 機能数が多い Web アプリケーション、マイクロサービスへの段階的移行を視野に入れたシステム。
モジュラーモノリス ― モジュール境界がもたらす AI の可視範囲制御
モジュラーモノリスは、コードをバウンデッドコンテキストに基づくモジュールに分割し、各モジュールが明確なプログラミングインターフェースを公開するアーキテクチャである。
Shopify の事例が象徴的である。同社は Ruby on Rails モノリスをモジュラーモノリスに移行し、バウンデッドコンテキスト・明確なインターフェース・内部サービス境界を確立した。この移行により、社内 AI アシスタント「Shopify Magic」が設計の整合性を損なわずに意味のある機能追加を生成できるようになった。Leap CRM でも、モジュラーモノリスへの移行で機能デリバリーが43%高速化し、AWS コストが22%削減されている。
モジュール単位（30〜50ファイル）が AI のコンテキストウィンドウに収まるという点は、条件1の指針と直接合致する。モジュール境界が AI の可視範囲を適切に制限し、関係のないコードへの干渉を防ぐ。
| 5条件での評価 | 判定 |
|---|---|
| コンテキスト効率 | 高 ― モジュール単位が AI のコンテキスト制約に合致 |
| 型安全性 | 高 ― モジュール間のインターフェースで型を強制しやすい |
| 境界の明示 | 高 ― バウンデッドコンテキストによる明確なモジュール境界 |
| 予測可能性 | 高 ― モジュール単位での一貫した構造 |
| ドキュメントインフラ | 高 ― モジュール単位で AGENTS.md を配置可能 |
向いている場面: 成長段階のプロダクト、将来的にマイクロサービス化を検討しているシステム、複数チームで開発するプロジェクト。
ハイブリッド（Vertical Slice + Clean Architecture）― バランス解
機能単位で垂直に分割しつつ、各機能の内部にクリーンアーキテクチャの層を適用するアプローチがある。複数の技術ブログやリサーチ事例で、Vertical Slice の高いコンテキスト効率とクリーンアーキテクチャの堅牢な依存管理を両立する構成として推奨されている。
具体的なディレクトリ構成は以下の通りとなる。
src/
├── features/
│ ├── orders/
│ │ ├── domain/ # エンティティ、バリューオブジェクト
│ │ ├── usecases/ # ユースケース
│ │ ├── adapters/ # リポジトリ実装、外部API
│ │ └── presentation/ # ハンドラ、DTO
│ ├── users/
│ │ ├── domain/
│ │ ├── usecases/
│ │ ├── adapters/
│ │ └── presentation/
│ └── ...
├── shared/ # 共有カーネル
│ ├── domain/ # 共通ドメインオブジェクト
│ └── infrastructure/ # 共通インフラ
└── config/このアプローチでは、各機能のディレクトリ内で依存性ルールが保たれる。AI は features/orders/ 配下だけを読み込めば、orders 機能に必要な全レイヤーの情報を把握できる。クリーンアーキテクチャの弱点であったコンテキスト散在を、Vertical Slice の凝集性で解消している形となる。
共有カーネル（shared/）で共通機能の重複を防止できるため、Vertical Slice 単体で発生する重複税も軽減される。
| 5条件での評価 | 判定 |
|---|---|
| コンテキスト効率 | 高 ― 機能単位でコンテキストが完結 |
| 型安全性 | 高 ― レイヤー間のインターフェースで型が活きる |
| 境界の明示 | 高 ― 機能間 + レイヤー間の二重の境界 |
| 予測可能性 | 高 ― 機能名 + レイヤー名の2軸で予測可能 |
| ドキュメントインフラ | 高 ― 機能単位で自己完結し、共有部分も分離 |
向いている場面: AI 親和性と保守性の両立を求める中〜大規模プロジェクト。学習コストは高いが、長期的に見合う構成を目指す場合に適している。
判断フレームワーク: 自分のプロジェクトに最適なパターンを選ぶ
ここまで4つのアーキテクチャパターンを比較してきたが、どれが「正解」かはプロジェクトの状況次第である。以下のフレームワークを使って、自分のプロジェクトに当てはめて判断してほしい。
判断基準チェックリスト
判断の軸は4つに集約される。プロジェクト規模、ドメイン複雑度、AI 活用度、成長フェーズの4つである。
| 判断軸 | 内容 | 確認ポイント |
|---|---|---|
| プロジェクト規模 | ファイル数・チームサイズ | 1モジュールが30〜50ファイルに収まるか |
| ドメイン複雑度 | ビジネスルールの量・外部連携数 | ドメインロジックに厳密な境界制御が必要か |
| AI 活用度 | 補完レベルかエージェントレベルか | AI にどこまで任せるか（補完 / タスク単位 / 機能単位） |
| 成長フェーズ | MVP・成長期・成熟期 | 現在と1〜2年後のシステム規模の見通し |
これらの軸に対する推奨パターンを以下のマトリクスにまとめた。
| 条件 | 推奨パターン |
|---|---|
| 小規模（〜100ファイル）・MVP | Vertical Slice |
| 中規模・機能数が多い | モジュラーモノリス or ハイブリッド |
| 大規模・複雑ドメイン | クリーンアーキテクチャ or ハイブリッド |
| AI をエージェントレベルで活用 | ハイブリッド or モジュラーモノリス |
| AI は補完レベルで利用 | どのパターンでも大差なし |
| 将来マイクロサービス化を検討 | モジュラーモノリス |
| 複数チームで並行開発 | モジュラーモノリス or ハイブリッド |
よくある判断の分岐点
実際の判断場面で頻出するシナリオごとに、推奨パスを整理する。
「クリーンアーキテクチャを採用済みだが、AI との相性が気になる」
クリーンアーキテクチャ自体を捨てる必要はない。まず取り組むべきは、CLAUDE.md の整備とレイヤー間の関係の明文化である。40万行プロジェクトの事例でも、クリーンアーキテクチャをベースにしつつ実用的な調整を加えることで成果を上げている。コンテキスト散在が問題になる場合は、段階的にハイブリッド構成（機能単位 + レイヤー構造）へ移行する方法もある。
「小規模スタートアップで最小構成にしたい」
MVP フェーズでは Vertical Slice Architecture から始めるのが合理的である。機能単位の分割は直感的で学習コストが低く、AI のコンテキスト効率も高い。プロダクトが成長してドメインの複雑度が増した段階で、必要な機能から順にクリーンアーキテクチャのレイヤー構造を導入する（ハイブリッドへの段階的移行）ことを検討すればよい。
「既存モノリスを AI 親和性高く改善したい」
一度にリアーキテクチャするのではなく、モジュラーモノリスへの段階的な移行が現実的な選択肢となる。バウンデッドコンテキストに基づいてモジュール境界を引き、モジュール間のインターフェースを定義する。各モジュールの内部構造は後から整理できるため、まずは境界の確立に注力する。CodeScene の研究（“Agentic AI Coding: Best Practice Patterns for Speed with Quality”）では、コードヘルスが 9.5未満のコードベースでは AI エージェントのパフォーマンスが大幅に低下することが示されている。AI 導入前のリファクタリングも視野に入れたい。
アーキテクチャの先にある「制約設計」という考え方
アーキテクチャパターンの選択は出発点に過ぎない。AI が生成するコードの品質を構造的に保証するには、アーキテクチャの上に「制約」を乗せる必要がある。「正しいコードしか生成できない環境を作る」という発想への転換である。
Stable Skeleton and Vertical Tissue パターン
システムを「人間が定義する不変の構造（Skeleton）」と「AI が生成する具体的な実装（Tissue）」に分割するアプローチがある。
# Skeleton: 人間が定義（AIは変更不可）
class BaseTask(ABC):
def run(self): # final - ログ、認証、例外処理を一元管理
self._authenticate()
self._log_start()
result = self._execute() # AIはここだけ実装
self._log_end()
return result
@abstractmethod
def _execute(self): # Tissue: AIが実装
passTemplate Method パターンによって制御フローを固定し、AI が実装するのは _execute() メソッドだけに限定される。セキュリティチェックの欠落やログ出力の忘れといった、AI が起こしがちなミスを構造的に防止できる。
三層制約設計
「生成後にレビューで修正する」のではなく、「生成時点で正しいコードしか出せない」ようにする。この考え方を体系化したのが三層制約設計である。
| 制約層 | 内容 | 効果 |
|---|---|---|
| ビジネス制約層（BDD） | 自然言語でビジネスルールを定義 | AI に「何を実装すべきか」を明示 |
| 論理制約層（形式手法） | 数学的な不変条件を定義 | 論理的な矛盾を防止 |
| 実装制約層（型安全） | 型システムで不正状態を排除 | コンパイル時にエラーを検出 |
三層すべてを導入するのはハードルが高い。最低限として、以下の3点を「制約インフラ」として整備することを推奨する。
- 型安全性の強化: TypeScript の strict mode、Rust の型システムなど、言語レベルで不正な状態を排除する
- CLAUDE.md の整備: アーキテクチャ方針・コーディング規約・ワークフローを明文化し、AI の行動を方向づける
- テスト先行（AI TDD）: Red → Green → Blue → Commit のサイクルで、AI が生成したコードを即座に検証する。併せて Plan → Execute → Verify のアプローチを採用することも有効である。SFEIR Institute の報告では、このサイクルにより複雑なタスクでの修正イテレーションが 60% 削減された
この3点を押さえるだけでも、AI の出力品質は安定する。アーキテクチャパターンの選択とあわせて、制約設計を組み合わせることが実効性を高める鍵となる。
まとめ: アーキテクチャ選定で押さえるべき3つのポイント
本記事の要点を3つに集約する。
1. AI の出力品質はアーキテクチャで決まる。 コンテキスト効率、型安全性、境界の明示、予測可能なファイル構成、ドキュメントインフラ ― この5条件がアーキテクチャの AI 親和性を左右する。
2. 「自分のプロジェクト」の条件に合った選択が正解。 プロジェクトの規模・複雑度・AI 活用度・成長フェーズの4軸で判断する。本記事のマトリクスを起点に検討してほしい。
3. パターン選択後の制約設計こそ差がつく。 型安全性・CLAUDE.md・テスト先行の制約インフラが、AI の出力品質を構造的に安定させる。
次に取るべきアクションとして、まず現在のプロジェクトで CLAUDE.md を作成し、アーキテクチャ方針とコーディング規約を明文化するところから始めてみることを勧める。60〜100行程度の小さなファイルから始め、AI との協働の中で育てていく形が実践的である。
参考リンク
- Claude Code と 1 人で 40 万行規模のフルスタック＋インフラを構築した話 ― 40万行規模のクリーンアーキテクチャ + Claude Code 実践記録
- 「Claude Code Week」既存事業で1週間AI縛りで開発したことで見えたゲームチェンジと開発フローの再構築の必要性 ― 三層制約設計の提唱、AI 駆動開発フローの再構築
- クリーンアーキテクチャ入門 Part 4: 実践的な開発フローとAI活用 ― Rust でのクリーンアーキテクチャ + AI 活用
- 生成AIの時代にレイヤードアーキテクチャは古いかなと思った ― Vertical Slice Layered Architecture の提案
- Agentic Coding Best Practices ― 型安全性と AI 成功率の実証（60% → 100%）
- Using CLAUDE.MD files ― Anthropic 公式の CLAUDE.md 活用ガイド
- Context Engineering for Coding Agents ― Martin Fowler サイトによるコンテキストエンジニアリング解説
- Spec-driven development ― Thoughtworks による仕様駆動開発の体系化
- Why Modular Monolith Architecture is the Key to Effective AI-Assisted Development ― モジュラーモノリスと AI 開発の相性分析、Shopify 事例
- Codified Context: Infrastructure for AI Agents in a Complex Codebase ― 283セッションにわたるコンテキストインフラの学術的実証研究
- The Clean Architecture ― Robert C. Martin によるクリーンアーキテクチャの原典
- Beyond Code Completion: Architecting for the AI Era ― Stable Skeleton and Vertical Tissue パターンの提唱
- Agentic AI Coding: Best Practice Patterns for Speed with Quality ― CodeScene によるコードヘルスと AI パフォーマンスの関係