はじめに
「当社独自のAI駆動開発手法を確立しました」「AI駆動開発で工数を90%削減！」という提案書や研修案内を、この1年で山ほど見ました。
多方面かつ主に前線を退いたおじさん方から叱られそうな主張ですが、ぶっちゃけ誰でもそれなりに品質の高いアプリケーションが作れるのが今の時代（opus5.5以降特にそう感じます）です。こんな時代にこういった売り文句は少し嘘くさいというか、凄みを感じませんよね。
この記事で言う「AI駆動開発手法」は、「AIにどういう順番で作らせるか」を手順として固めたもの全般を指します。社内の独自手法も、研修で売られている手法も、OSSで公開されている手法も、いったん同じ括りで話します。そのうえで、前半でAI駆動開発の胡散臭さの正体 を、後半で手法を固める前に何を固めるべきか を書きます。
1. AI開発の手順はモデル/エージェント性能向上のたびに大幅に見直されるべき
まずは事実から。
Anthropicは2026年3月、「Harness design for long-running application development」という技術記事を公開しました。Claudeに数時間かけてアプリを丸ごと作らせる仕組み(ハーネス)を、モデルの更新に合わせて組み替えていった記録です。
中身を並べると、こうなります。
| 時期 | モデル | 外した部品 | 外せた理由 |
|---|---|---|---|
| 前作(2025年11月) | Sonnet 4.5 | — | 上限が近いと思い込んで作業を切り上げる癖があり、コンテキストリセットが必須だった |
| 今回の初版 | Opus 4.5 | コンテキストリセット | その癖がほぼ消えた |
| 今回の改訂版 | Opus 4.6 | スプリント分割 | 分割なしでも2時間以上一貫して作業できた |
半年もたたないうちに、作り手が自分の組んだ手順を2回削っています。
記事はこのAnthoropicの経験を原則として書いています。ハーネスの部品はどれも「モデルが単独ではできないこと」についての仮定であり、その仮定はモデルの進化ですぐ古くなりうる。だから新しいモデルが出たら見直せ、と。
AI駆動開発手法を売りにしている時点で、その手法は固定されている前提を裏の意味に持つと思います。
その中身を固めれば固めるほど、モデルの進化で一瞬にして陳腐化してしまいます。
世に出ている（特に企業が謳っている）ほとんどのAI駆動開発方法論はすでに陳腐化しているといっていいでしょう。
2. 「順番」を売りにした手法は、モデル更新1回で賞味期限が切れる
ここから先は私の意見です。
「この順番でAIに作らせれば上手くいく」という手法は、モデルが1つ更新されるだけで前提が崩れます。
手順というのは、今のモデルの弱点を人間が補うために組まれたものです。長い作業で集中が切れるから、細かく区切る。自分の間違いに気づかないから、工程ごとにチェックを挟む。どれも筋は通っています。ただ、その弱点がモデル側で消えた瞬間、手順はただの手間になります。Anthropicがスプリント分割を外したのは、まさにこれです。
誤解のないように言っておくと、GitHubのSpec KitやAWSのKiroのような仕様駆動の手法が、全部ダメだと言いたいわけではありません。仕様から入る発想は、Anthropicが最後まで残した「計画役」に近いものです。Spec Kitは現在、収束と判定されるまで実装を繰り返す(ループする)流れも持っています。
問題は手法の中身ではなく、手順を「完成品」として固めて売ること です。モデルが変わったときに、その手順のどこがまだ効いていて、どこが重荷になったのか。** それを確かめる仕組みを持たない手法とその改善を人手でちまちま行うような仕組み** は、半年後には完全オワコン化めでたしです。
3. レビュー用のエージェントはプロジェクトの特性ごとに鍛えないと使えない
最近は「レビュー役のAI」を組み込んだ手法も増えてきました。それ自体は正しい方向です。ただ、入れただけの評価役は、ほぼ確実に甘い採点をします。
これも私の思い込みではありません。Anthropicの記事では、エージェントに自分の成果物を評価させると、凡庸な出来でも自信満々に褒める傾向が報告されています。役を分けても、評価役は同じLLMなので甘さは残ります。実際、初期の評価役は問題を見つけておきながら「大したことはない」と自分を納得させて合格を出していました。
それでも記事が評価役を手放さなかったのは、鍛えれば使えるからです。
もちろんAI駆動開発キットの中で一般的な尺度の評価エージェントを鍛えるのではなく、プロジェクト固有の問題として評価役を鍛える必要があります。
Anthropicがやったことは3つです。
- 「デザイン品質」「独創性」のように、判断基準を言葉にして渡す
- 動いているアプリを、Playwright MCPでユーザーのように実際に操作させる
- 基準ごとに閾値を決め、1つでも下回ったら不合格にする
ここまでやると、指摘はかなり具体的になります。たとえば、アニメーションのフレームを並べ替えるAPIが動かない原因を、FastAPIのルートの定義順だと突き止めています。並べ替え用のパスがIDを受けるパスより後ろにあったため、「reorder」という文字列がIDとして解釈されていた、という指摘です。
評価役の価値は「いること」ではなく、どの基準で、何を実際に触って、どこで落とすかにあります。
こういったサブエージェントをAI駆動開発手法の中に入れ込んでしまうパターンは多いと思いますが、プロジェクト固有の特性の中で順応させていくサブエージェントを作れる構造になっていないと、意味がありません。
4. 手順の代わりに固めるべきものは2つある
ここまで読んで「じゃあ手法なんて要らないのか」と思われそうですが、そうは思っていません。Anthropicのハーネスで、モデルが変わっても最後まで残ったものがあります。それを2つ挙げます。
(1) 完了を、作り手と別の目で確かめる評価
生成役が「できました」と言っても、それは完了ではありません。完了かどうかは、動くものに対して、作った本人とは別の評価役が確かめて初めて決まります。Opus 4.6でも、評価役はスタブのまま放置された機能や、見た目だけで操作できない機能を指摘し続けました。
(2) 評価の結果で、ハーネスそのものを直すループ
記事の筆者は、評価役のログを読んで自分の判断とずれた箇所を探し、評価役のプロンプトを何周も直しています。モデルが変わったときは、部品を1つずつ外して出力を比べ、効いていないものを剥がしました。一気に削ったときは性能が戻らず、どの部品が効いていたのかもわからなくなったそうです。
手順は一度決めたら終わりですが、このループは回すほどハーネスが今のモデルに合っていきます。
ただし、ループも万能ではない
条件つきの話です。ループを回せば何でも解決、というのもまた言い過ぎです。
- タスクが簡単なら、評価役はただのコストです。 Opus 4.6では、モデルが単独でこなせる範囲のタスクに評価役を付けても、オーバーヘッドにしかなりませんでした。評価役が割に合うのは、タスクがモデルの単独の実力を超えるときです。
- ループは高くつきます。 先のゲームメーカーの例では、コストは20倍以上でした。
- 基準が間違っていれば、間違ったものを作り続けます。 評価役にも限界があり、深い階層のバグは見逃されました。Claudeは音を聞けないので、音楽ソフトでは音楽的な良し悪しにQAが効きにくかったとも書かれています。
自己改善を前提として、どこまでを仕組みにできるかが、これからの勝負どころだと私は考えています。
5. 言いにくい話ですが、詰まっているのはもう「書く」工程ではない
AI駆動開発の手法の多くは、いまだに「どうコードや設計を書かせるか」に力を入れています。でも、現場で詰まっているのはそこではありません。
DORAの2025年レポートでは、AIの導入でデリバリーのスループットは上がった一方、デリバリーの不安定性は上がり続けているとされています。私の現場も同じです。エージェントが出すPull Requestの量を人間のレビュアーが捌けず、結局エージェントの出力を絞っています。
これは手順の出来不出来の話ではなく、確かめる仕組みがないまま書く速度だけ上げると、検証待ちの山が人間の前に積み上がるという構造の話です。手順をどれだけ磨いても、この山は低くなりません。
ヒントになるのが、Geoffrey Huntleyが広めたRalphです。素の形は、同じプロンプトをエージェントに渡し続けるだけの1行のbashループ。ただ本人が強調しているのは、テストや型チェック、静的解析で誤った生成を弾くことと、挙動を見ながらプロンプトを調整し続けることです。エージェントが学んだことをAGENT.mdに書き戻させる工夫もしています。つまりRalphの肝は、回し続けることより、回すたびに確かめて直すことにあります。
最後に
まとめると、私の考えはこうです。
「この順番で作らせれば上手くいく」を売りにしたAI駆動開発手法は、モデルが変わるたびに賞味期限が切れる上にそれ自身がAIのポテンシャルを制限してしまう危険をはらんでいることは理解しましょう。
そのうえで残るのは、出てきたものを別の目で厳しく確かめる評価役と、その結果でハーネスを直し続けるループです。
言い換えると、モデルの単独の実力を超える仕事を任せるなら、独立した評価のループを前提にしないエージェント開発は、もう成り立ちません。 逆に、モデルが単独でこなせる仕事にまでループを常設するのは、ただの浪費です。
「うちのAI駆動開発手法」を語る人がいたら、ひとつだけ聞いてみてください。
「その手法は、1か月後にどうなってますか?」
-- 手順は腐る。評価ループは育つ --
参考
- Anthropic「Harness design for long-running application development」(2026年3月24日)
- Anthropic「Effective harnesses for long-running agents」(2025年11月)
- Geoffrey Huntley「Ralph Wiggum as a "software engineer"」(2025年7月14日)
- GitHub Spec Kit
- Kiro Specs ドキュメント
- InfoQ「DORA Report Finds AI Is an Amplifier in Software Development, But Trust Remains Low」(2025年9月29日)