AI駆動開発の生産性は、プロンプトではなく「検証可能性」で決まる

AIを使った開発で差がつくのは、もうプロンプトの巧拙ではない。AIが自分の作業結果を確かめられる環境があるかどうかだ。本稿では、私たちが実案件で使っている開発の組み立て方と、案件の段階に応じて「規律の量」を決める物差しを紹介する。

この記事の要点

• 価値の源泉は、指示の質から、AIが反復して自己検証できる「ループ」の設計へ移った
• 状態は会話ではなくリポジトリに置く。モデルは忘れるが、リポジトリは忘れない
• 規律は多いほどよいわけではない。段階とリスクに合わせて積み上げる

価値の源泉は「指示」から「ループ」へ

Loop Engineeringとは、人が毎回指示を出すのをやめ、目的と完了基準を決めて、AIが完了まで反復する仕組みを設計することだ。前の世代の技術は消えない。プロンプトも文脈も実行環境も、ループの部品として組み込まれる。

ボトルネックは、AIが自分の仕事を確かめられるかどうか

AIが「完了しました」「テストは通るはずです」と言うことと、実際に完了していることは別だ。ループを回す以上、完了の判定を人の目視に頼ることはできない。テスト、型検査、画面の自動操作、ログ、CIといった「証拠」を、AI自身が取得できる状態にする。プロンプトの言い回しを磨くより、この整備のほうがはるかに効く。

もう一つの制約が、コンテキストウィンドウだ。対話が長くなるほど、初めに伝えた前提や途中の決定は埋もれ、モデルの振る舞いは不安定になる。そこで私たちは、開発の状態を会話ではなくリポジトリに置いている。

作業の分担にも同じ考え方を使う。調査・実装・検証を別々のサブエージェントに担わせ、それぞれ独立したコンテキストで動かす。親には要約だけを返す。検証役は実装役の思考の過程を知らないほうが、甘い判定をしにくい。

ループは次の5つの手順で回す。

1. 目標を契約にする。完了の条件を、テストや数値で書く
2. 分担して実行する。調査・実装・検証を別のエージェントに任せる
3. 証拠で判定する。テスト結果、ログ、画面、CIで確かめる
4. 止める条件を先に決める。合格、巻き戻し、時間切れのそれぞれで何をするか
5. 学びを戻す。繰り返した失敗は、ルールファイルやSkillに書き戻す

規律の量を決める：5つの方法論と判断の問い

開発の規律には強弱がある。私たちは次の5つを、案件の段階とリスクで使い分けている。これらは競合ではなく積み上げであり、下の層がないまま上の層を入れても機能しない。

避けたいのは2つの失敗だ。PoCの段階で本格的な統制を作り込む過剰投資。そして、本番開発に入っても「なんとなく動く」まま進める過小投資だ。自然言語だけで組んだコードは、規模が大きくなると変更の影響を読み切れなくなる。どこで次の層を入れるかを、案件の初めに決めておく。

実案件から：仕様駆動開発を「軽く」した

ある開発案件で、私たちは仕様駆動開発（SDD）を採用した。コードだけでは読み取りにくい設計の意図や責務の境界を、AIエージェントに伝えるためだ。初期は効果があった。だが機能が増えると、要件・設計・タスクの文書をすべて更新し続ける負担が重くなった。表示ラベルの修正にも同じ手続きがかかり、同じ事実が複数の文書に散らばった。完了したタスクと現在の仕様の境界も曖昧になった。

そこで変更を3つに分類し、仕様を更新する場面を絞った。

あわせて、運用の原則を決めた。一つの振る舞いは一つの仕様が持つ。仕様は長く参照する契約であり、タスクは一つの実装サイクルだけの作業メモである。正はコードとテストに置く。AI向けの文書は一貫性を重んじ、人向けの文書は読みやすさを重んじて、書き分ける。

仕様を「作業手順」ではなく「将来参照する契約」と位置づけたことで、維持の負担は大きく下がった。規律は、量よりも「誰が、いつ、何を更新するか」の設計で効き目が決まる。

規律は、理解の負債に備える保険である

AIが書くコードが増えるほど、人が中身を理解していないコードも増える。いわば「理解の負債」だ。そして「AIがそう言ったから」と判断を止めてしまう。この2つは、障害が起きたときに初めて表に出る。

仕様、テスト、ルールファイルは、AIへの指示であると同時に、人がシステムを理解し続けるための地図でもある。規律が効いているかは、例えば「レビューで差し戻された変更の割合」や「本番障害につながった変更の割合」で確かめられる。顧客が自分たちでシステムを育てられる状態を残すためにも、この地図は欠かせない。