もうクリーンアーキテクチャはやめた。AI時代に勝つための「AI-Oriented Architecture（AOA）」という割り切り

概要

直近、生成AIによるプログラミングが急速に主流になっています。
いち早く Claude Code を導入した企業では「もうほとんどコードを自分で書いていない」というエンジニアが増えてきています。私自身もほぼコードを書かなくなってきており、最初のアーキテクチャ設計を固めるのに時間を使い、あとは爆速でAIに開発をしてもらう、というスタイルになってきています。

そうした中で、コードの設計も「AIが開発しやすいスタイル」に寄せていったほうが圧倒的に早く開発できるのでは、という考え方が急速に広まっています。これを「AI-Oriented Architecture（AOA：AI指向アーキテクチャ）」と呼ぶようです。

これまでの「人間に優しいモダンな設計」の最適解とされていた DDD やクリーンアーキテクチャは、AIにとっては迷子になりやすい複雑な設計であることが認識されつつあります。AI時代に勝つためには、既存の設計を捨てて AOA にいち早く切り替える必要があるかもしれません。

設計の Before / After

例として「ユーザー登録機能」を作るケースを出して、ディレクトリ構造の違いを比較してみます。

Before：人間に優しい設計（DDD / クリーンアーキテクチャ）

DDD やクリーンアーキテクチャの考え方では、役割ごとにファイルを細かく分割し、インターフェースを挟んで依存関係を疎結合にするのが「綺麗なコード」とされていました。

src/
├── domain/
│   └── user/
│       ├── userEntity.ts            # ドメインエンティティ
│       └── userRepository.ts        # リポジトリのインターフェース定義
├── usecase/
│   └── user/
│       └── createUserUseCase.ts     # ユースケース・ビジネスロジック
├── infrastructure/
│   └── user/
│       └── prismaUserRepository.ts  # DBアクセスの具象実装
└── presentation/
    └── user/
        ├── userController.ts        # コントローラー・コントローラロジック
        └── userDto.ts               # リクエスト・レスポンスの型定義

このように1つの機能を作るために7〜8個のファイルをまたぐ構成（ファイルホッピング）にすると、AIは途中で参照を見失ったりトークンを浪費したりします。

After：AIに優しい設計（AOA）

AI時代においては、レイヤー（層）で分けるのをやめ、フィーチャー（機能）ごとのディレクトリにすべてを閉じ込めます。ファイル数も現実的な2〜3ファイルに集約します。

src/
└── features/
    └── user/
        ├── userSchema.ts  # Zod等によるリクエスト/レスポンスのバリデーションと型定義
        ├── userHandler.ts # APIのエンドポイント・HTTPルーティング処理
        └── userModel.ts   # ビジネスロジックとDBクエリ(Prisma等)をベタ書きするコア

複雑な抽象化を挟まずに userModel.ts 内で直接SQLやORMのクエリを叩く（ベタ書きする）スタイルに寄せることで、AIの生成精度や開発速度が爆発的に向上します。

国内外で起きている「事実」

「多層ディレクトリアーキテクチャの終焉」はやや極論に感じられたかもしれませんが、ここ1年（2025〜2026年）のソフトウェアエンジニアリング界隈における明確なパラダイムシフトが事実として起きています。

著名アーキテクトによる「LLMオンデマンド・ルール」の提唱

著名なiOS/Webアーキテクトである Krzysztof Zabłocki 氏らは、AIにコードを書かせる実験を重ねた結果、複雑なDI（依存関係注入）コンテナやクリーンアーキテクチャのレイヤーを廃止した方が、AIの出力精度が劇的に上がり、手戻りが減ることを報告しています。彼らは「AIの文脈（コンテキスト）を無駄に消費しないフラットな設計思想」への転換を強く推奨しています。

v0 や Bolt.new がもたらした「1ファイル完結」の設計

Vercelの「v0」や「Bolt.new」といった最新のUI生成・開発ツールでは、コンポーネント、スタイル、ロジックをあえて細切れに分散させず、1つのファイルにガッツリ記述するスタイルが標準となっています。このアプローチにより、AIは「そのファイルだけ」を書き換えれば済むため、バグの混入率が劇的に下がることが実証されています。

AIエージェント（Aider / Claude Codeなど）のベンチマーク

GitHub上で近年最も勢いのある、コードを自律修正するAIエージェント（Aider や Claude Code など）の運用データからも事実が明らかになっています。抽象化レイヤーが高くファイルが何重にも分かれているリポジトリほど、AIエージェントは修正すべきファイルを見失って打率（タスク成功率）が下がり、逆に手続き型でシンプルなリポジトリほど、一発で正確に修正できるという特性が広く認知されるようになりました。

AI駆動で最重要となる「行動の局所性（LoB）」とは何か

このAOA（AI指向アーキテクチャ）の根底にあるのが、「行動の局所性（Locality of Behavior: LoB）」という思想です。

言葉だけ見るとめちゃくちゃわかりにくいので、簡単に言うと「あるコードの振る舞いを変えたいとき、そのファイルのその場所（コンテキスト）だけを見ればすべての情報が完結している度合い」を指します。

これまで私たちがやってきた「DRYの原則」や「関心の分離」は、LoBとトレードオフの関係にあります。

DRYとLoBの比較

例えば、ユーザー登録のバリデーション処理を共通化（DRY）する場合と、ベタ書き（LoB）にする場合を比較してみます。

• Before: 過剰なDRY:
  バリデーションルールが src/utils/validation.ts に共通化されている。AIがユーザー登録ロジックを修正するとき、わざわざ別ファイルにある共通関数の中身を読みに行き（ファイルホッピング）、共通関数側の仕様に引きずられてバグを生むリスクがある。
• After: 行動の局所性(LoB)を高めた状態:
  多少の重複を恐れず、userService.ts の中に直接バリデーションルールをベタ書きする。AIは「このファイルの、この関数の、この数行」だけを読めばすべてを理解できるため、アテンション（LLMの注目度）を1箇所に集中させ、完璧な修正を出力できる。

人間から見ると「多少書き味を悪くしてでも、1ファイル内、1関数内で話を完結させる（LoBを高める）」ことこそが、AIのパフォーマンスを最大化する鍵になります。

ただし、行きすぎた LoB にしないこと

ここで1つ注意なのが、「なんでも1ファイルに押し込める」ことを推奨しているわけではないということです。
LoB（行動の局所性）がAIに有利だからといって、全ての DRY を無視して重複コードを量産すると、ただのレガシーなスパゲッティコードを生み出します。

例えば重要なドメインロジック（ビジネスルール）を扱ったもの、あとで変更されそうな定数などもベタ書きしてしまうと、今度は1つの修正をしたいだけなのに大量のファイルを修正することになり、かえってパフォーマンスが落ちる、バグだらけになる可能性があります。

ここはまだ最適解が見つかっていないかもしれませんが、私の考えでは「構造のDRYは捨ててもいいが、ドメインロジックはDRYにする」というバランスが良いような気がしています。

レビュープロセスもなるべく人間を介在させない

AIにより爆速に開発ができるようになったら、次に問題になるのはコードレビューです。
もはや人間だけによるレビューは不可能になってくるでしょう。

現在では「AIがレビューして、それをまた別のAIが直す」という自律的なループをいかに上手く回すか、という試行錯誤がされています。

最新のAIレビューのやり方

最近のAIレビューの動向を調査してみました。
以下のようなツール、やり方がありそうです。

• CodeRabbit (コードラビット)
  2026年現在、多くのテック企業で導入されている代表格です。PRを出すと数秒でコードの意図を要約し、バグになりそうな箇所にピンポイントでレビューをくれます。さらに、「この指摘を修正するコミットを作って」とPRのコメント欄でチャットするだけで、AIがコードを直してプッシュまで完了します。
• GitHub Copilot Code Review
  GitHubが2025年末に本格導入し、2026年現在急速にシェアを広げています。GitHubネイティブで動作し、セキュリティ脆弱性や設計のアンチパターンを自動で弾きます。
• MCP (Model Context Protocol) を使った内製エージェント
  Anthropic（Claude）が提唱したMCPを使い、自社のGitHubリポジトリとCI環境を連携させた独自の「自律修正エージェント」を構築する企業（特にスタートアップ）が増えています。

人間の役割はどう変わる？

人間はもう、タイポや構文エラー、インポート漏れといった「コードの正しさ」を見る必要はありません。
人間にしかできないのは、以下の2点に集中することです。

• 仕様の確認： コードとしては完璧に動くしテストも通る。しかし、ビジネスの要件や将来のプロダクト方針、法律的な観点から見て「そもそもこの仕様で合っているか」のチェックをする
• 人間の認知負荷の最終防衛： AIにとっては読みやすくても、いざ本番障害が起きたときに「人間が状況を把握できるシンプルさ」になっているかの確認をする

まとめ

これまでは「いかに複雑なドメインを上手く抽象化するか」がエンジニアの腕の見せ所でした。しかしこれからは、「いかにAIに一発で正しいコードを出力させ、開発サイクルを最速化するか」の仕組み作りがエンジニアリングの主軸となっていくのではないでしょうか。

あえて書き味を泥臭くしてでも、AIが迷わないシンプルな設計（AOA / LoB）に寄せ、人間の介在をなくしていく。この仕組みを早く作れた企業が勝つ世界になっていくと考えています。