AI駆動開発は「答え」を外部に求めてはいけない

AI駆動開発について調べると、今は本当にいろいろな手法が出てくる。

Claude Code、Codex、Cursor、GitHub Copilot、AIエージェント、Vibe Coding。

ツールの話だけではなく、

• AIに仕様書を書かせる
• Markdownを大量に用意する
• AIにIssueを分解させる
• 人間はコードを読まない
• 逆にコードは全部人間がレビューする
• 既存開発の一部分だけAIに置き換える

など、開発プロセスそのものについても様々な主張がある。

しかし、最近かなり強く思うことがある。

AI駆動開発について、外部に「正解」を探しに行きすぎない方がいい。

なぜなら、2026年現在のAI駆動開発は、まだ「正解が確立された分野」ではないからだ。

AI駆動開発は、まだ一つの開発手法ではない

AI駆動開発のセミナーや事例を見ていると、大きく二つの極端なパターンをよく見る。

一つは、既存の開発プロセスをほぼそのまま残し、一部分だけAIに置き換える方法だ。

例えば、

今まで担当者が書いていたテストコードをAIに書かせる
設計書からDTOを生成させる
コードレビューの一次チェックだけAIにやらせる

といった形だ。

これは導入しやすい一方、話が具体的になるほど、

「その会社で人間がやっていた作業を、そのままAIへのプロンプトに変換しただけ」

になっていることも多い。

もう一つの極端な例が、いわゆるVibe Codingを最大限まで進める方法だ。

人間はほとんどコードを書かず、

• 要件
• 設計方針
• コーディングルール
• 引き継ぎ
• タスク
• AIへの指示

を大量のMarkdownとして管理し、AIエージェントに実装させ続ける。

もちろん、この方法で高速にプロダクトを作ることもできる。

ただし、そのまま規模を大きくすると、今度は大量のMarkdownと大量のAI生成コードの整合性を、人間が追えなくなることがある。

同じ「AI駆動開発」という名前で呼ばれているが、この二つはほとんど別の開発手法である。

現在は、その中間も含めて無数のやり方が存在している。

だから、

AI駆動開発のベストプラクティスは何ですか？

という問いそのものが、まだ少し早いのだと思う。

少なくとも、

「あなたのプロジェクトにとっての正解」

を、誰かが既に持っている可能性は低い。

---

私が辿り着いた方法

私自身も、AIをかなり深く開発プロセスへ組み込んでいる。

ただし、コードをすべてAIに任せているわけではない。

むしろ逆で、システムの根幹になる部分はかなり人間が書く。

設計のベースとして使っているのは、大きく二つだ。

• ドメイン駆動設計（DDD）的な責任境界
• Metadata-drivenなデータアクセス設計

例えばバックエンドでは、かなり乱暴に分けると次のようになる。

システム層

• 認証・認可
• セキュリティ
• Filter / Interceptor
• Exception Handler
• Logger
• Session管理
• 共通的なAOP

インフラストラクチャ層

• DB接続
• SQL生成
• Query Builder
• DataModel
• DataObject
• Metadata
• 共通Repository相当の機構
• 楽観ロック等の共通制御

業務・ドメイン層

• ユーザー固有の業務ルール
• 各機能のApplication Service
• Domain Service
• API
• 画面固有ロジック

このうち、上二つはかなり慎重に扱っている。

AIに実装させることもあるが、その場合でも基本的にソースを細かくレビューする。

理由は単純で、

ここをAIが間違えると、間違いが全機能へ伝播するからだ。

逆に言えば、この基盤さえ安定していれば、その上の業務ロジックはかなり大胆にAIへ任せられる。

---

「AIにコードを書かせる」のではなく「AIが安全に書ける構造」を作る

ここが、自分の中で最も重要なポイントになった。

AI駆動開発というと、

どういうプロンプトを書けば良いコードを書いてくれるか

という方向に目が向きやすい。

しかし、長期間AIを使っていると、プロンプトよりも重要なのは、

AIが間違えにくいコードベースを先に作ること

だと感じる。

例えば私は、バックエンドをマルチモジュール化している。

概念的には、

root
├─ engine
│  ├─ security
│  ├─ database
│  ├─ logging
│  └─ common
│
└─ application
   ├─ user
   ├─ billing
   ├─ content
   └─ feature-x

のような構造になる。

engine側には共通基盤を置き、application側にはプロダクト固有のロジックを置く。

さらに業務側も、責任単位でできるだけ分割する。

これは人間だけで開発していた頃であれば、多少面倒な構成でもある。

モジュールが増えれば、

• dependency管理
• build設定
• package管理
• interface管理

なども増える。

しかし、AI駆動開発では、この「分割」がむしろ大きなメリットになる。

AIにとって探索範囲が狭くなる

AIエージェントは、コードを書く前に既存ソースを探索する。

巨大なリポジトリであれば、

認証を見る
↓
ユーザーを見る
↓
DBを見る
↓
似たAPIを探す
↓
古い実装を見つける
↓
別機能も見る

と大量のコードを読み始める。

当然、

• コンテキストを消費する
• Tokenを消費する
• 時間がかかる
• 無関係な実装を参考にする可能性が上がる

という問題が起きる。

責任単位でモジュールやパッケージを分けておけば、

この機能の正解はこの範囲にある

という状態を作れる。

AIにとってこれは非常に大きい。

---

AIは「書かなすぎる」より「書きすぎる」

AIに長期間コーディングさせていて感じる特徴がある。

AIは、必要なコードを書かないよりも、

必要以上にコードを書く方向へ失敗することが多い。

例えば、

• 念のためValidationを追加する
• 念のためDTOを追加する
• 念のためMapperを追加する
• 念のためFallbackを追加する
• 念のため別テーブルを参照する
• 念のためRuntime Checkを追加する

といったことをする。

一つ一つを見ると「親切な実装」に見える。

問題は、それが積み重なった時だ。

---

一番危険なのは「責任と依存のメッシュ化」

例えば、次のようなシステムがあるとする。

Billing
  └─ 課金情報

Application
  └─ アプリ固有機能

設計上、この二つは責任を分離していた。

データベース上もForeign Keyを張らず、

Billing DB
     ×
Application DB

という疎結合な状態を意図していたとする。

ところがAIが、あるApplication Serviceを書く際に、

有料ユーザーだけ処理すればいいのだから、BillingテーブルをJOINすればいい

と判断する。

結果として、

SELECT ...
FROM application_data a
JOIN billing b
  ON ...
WHERE b.status = 'ACTIVE'

のようなコードを生成する。

そのSQL単体では正しい。

テストも通る。

画面も動く。

だからレビューで見逃しやすい。

しかし、設計上は大きな問題が発生している。

Application
     ↓
Billing

という新しい依存が生まれたからだ。

これを各AIエージェントが繰り返すと、

User ───── Billing
 │   ╲      │
 │    ╲     │
Content ─ Application
 │      ╲   │
 └──── Feature

のように、責任境界を無視した依存関係が増えていく。

私はこれを勝手に、

「責任と依存のメッシュ化」

と呼んでいる。

最初はよく動く。

むしろ開発速度は速い。

しかし半年、1年と運用すると、

Billingを変更したらなぜかContentが壊れた

Userを変更したら別機能のテストが落ちた

このテーブルを削除したいが、どこから参照されているか分からない

という状態になっていく。

つまり、AI駆動開発で本当に怖いのは、

AIが動かないコードを書くことではない。

動くけれど、

アーキテクチャを少しずつ壊していくコードを大量に書くこと

だと思っている。

---

Markdownを増やせば解決するわけではない

これを防ぐために、

ARCHITECTURE.md
RULES.md
DATABASE_RULE.md
AI_INSTRUCTIONS.md
DEVELOPMENT_GUIDE.md

のようなドキュメントを大量に用意するアプローチもある。

もちろんドキュメントは重要だ。

私自身もAI向けの指示書や設計書はかなり使っている。

ただし、

Markdownに「BillingとApplicationは疎結合にしてください」と書いたから安全

とは限らない。

AIはその時読んでいるソース、現在のタスク、既存コードのパターンにも強く影響される。

さらに、ドキュメントが増えすぎると今度は、

どのMarkdownが最新なのか

という問題が発生する。

これは人間の設計書でも昔から存在した問題だが、AI時代にはさらに厄介になる。

AIは古い仕様書でも非常に真面目に従うからだ。

だから私は、重要な制約ほど文章だけではなく、

プロジェクト構造そのものに埋め込む

べきだと考えている。

例えば、

• モジュール依存をbuild設定で制限する
• package境界を明確にする
• 共通APIをinterfaceとして限定する
• DBアクセス経路を共通化する
• dependency directionを固定する
• CIで禁止dependencyを検出する

といった形だ。

文章で、

ここを参照しないでください

と頼むより、

そもそも参照しにくい構造にする方が強い。

これはAIだけの話ではないが、AI駆動開発では特に重要になる。

---

人間が書くコードを減らすことが目的ではない

ここまで読むと、

それって普通の設計をちゃんとやって、AIに一部書かせているだけでは？

と思うかもしれない。

実際、見た目だけならそう見える。

しかし、自分の目標はむしろ逆だ。

最終的にはかなり広い範囲をAIに実装させたい。

いわゆる「ガッツリAI駆動」の方向を目指している。

そのために、

AIに任せてはいけない部分を先に人間が作っている。

という方が近い。

例えば、

人間
 ↓
Architecture
 ↓
System Boundary
 ↓
Infrastructure
 ↓
Common Contract
 ↓
--------------------
 ↓
AI
 ↓
Application Logic
 ↓
API
 ↓
Test
 ↓
UI

という形だ。

基盤が安定していれば、AIは既存のパターンをコピーしながら非常に高速に実装できる。

逆に基盤まで毎回AIに自由に考えさせると、タスクごとに「その時AIが考えた最適解」が入り込む。

AIは毎回かなり賢い。

しかし、

毎回違う賢い答えを出す。

大規模なソフトウェアで必要なのは、毎回の局所最適より、

多少退屈でも同じ答えが繰り返されること

だったりする。

---

「AIが賢くなるから設計は不要」にはならない

AIモデルはこれからさらに賢くなる。

コード生成能力も、リポジトリ探索能力も、長期タスク能力も上がるだろう。

では、将来的にはアーキテクチャ設計が不要になるのか。

私はむしろ逆だと思っている。

AIが書けるコード量が増えるほど、

間違った設計の上に積み上げられるコード量も増える。

人間が1日に数百行書いていた時代なら、アーキテクチャの問題が表面化するまで数か月かかった。

AIが1日に数万行相当の変更を行えるなら、その問題が数日で発生する可能性がある。

AIによってコーディング速度のボトルネックが外れるほど、

• 責任境界
• データ所有権
• Dependency
• Contract
• State
• Transaction境界
• Failure isolation

といった「設計」の重要性は相対的に大きくなる。

---

ただし、これは「私の正解」でしかない

ここまで偉そうに書いたが、重要なことがある。

この方法は、

私にとって使いやすい方法

でしかない。

私は過去の開発経験から、

• ドメイン分割
• データアクセス抽象化
• Metadata-driven設計
• マルチモジュール
• Dependency管理
• DB設計

といったものを理解していた。

だからAI駆動開発でも、それを土台にした構造へ自然と辿り着いた。

しかし、同じ方法をそのまま別の人が使っても、うまくいくとは限らない。

そもそも、この設計思想をゼロから理解しようとすれば、DDDやデータアクセス設計などについて、それなりの量の本を読む必要がある。

実際の開発で、

この分割はきれいだけど実装が辛い

この依存方向だと運用で困る

Repositoryを抽象化しすぎた

といった失敗も何度も経験しなければ、なかなか感覚は身につかない。

つまり、この記事に書いた方法も、

私の経験という巨大なコンテキストにフィッティングされたAI駆動開発

である。

これは、最初に批判した「特定の現場にフィットした手法」と、本質的には同じなのだ。

---

だから、AI駆動開発は答えを外部に求めてはいけない

AI駆動開発の事例を見ることに意味がない、という話ではない。

むしろ大量に見た方がいい。

Vibe Codingも試した方がいい。

AIエージェントも使った方がいい。

他人のプロンプトも読んだ方がいい。

DDDもClean Architectureも、既存の設計手法も知っておいた方がいい。

ただし、

この人が成功しているから、この方法が正解だ

と考えた瞬間に危険になる。

その方法が成立している背景には、

• チーム人数
• プロダクト規模
• 開発者の経験
• リリース頻度
• 求められる可用性
• データ量
• セキュリティ要件
• 運用期間
• 技術スタック
• AIに渡せるコンテキスト

といった無数の条件がある。

その条件を切り離して「手法」だけコピーしても、同じ結果にはならない。

AI駆動開発について今できることは、

他人の正解を探すことではなく、他人の事例を材料にして、自分の正解を作ること

だと思う。

AI時代になって、コードを書く能力そのものの価値は相対的に下がり始めた。

一方で、

どこを分けるのか
何を共通化するのか
どこまでAIに任せるのか
何を絶対にAIに自由に決めさせないのか

を決める能力は、むしろ重要になっている。

AI駆動開発には、まだ教科書がない。

だからこそ面白い。

そして少なくとも今は、

「AI駆動開発の正解」をAIやセミナーや他社事例に求めるのではなく、自分のプロジェクトの中から作っていくしかない。

それが、今のところ私が辿り着いた答えである。