【ITニュース解説】Who One-Shot Ya? Why the One-Shot Benchmark Isn't Useful

最近、「ワンショット開発」という考え方が話題になっている。これは、AIに一度指示を与えるだけで、プロジェクト全体を自動的に構築してくれるという夢のような話だ。まるで映画の登場人物がスーパーコンピュータに命令するだけで、完璧なものができあがるかのようなイメージを持つ人もいるかもしれない。しかし、現実のAIの能力や、実際の開発現場での利用方法を考えると、この「ワンショット開発」は現実とはかけ離れた幻想であることが次第に明らかになってきている。

AIは人間の心を読み取ることはできない。AIは自律的なロボット人間ではなく、あくまで与えられた情報を基に処理を行うツールである。例えば、あなたが建築業者に「家を建ててほしい」とだけ伝え、すぐにその場を離れたら、どのような家が建つか想像できるだろうか。おそらく、業者は困惑し、あなたが何を求めているのか具体的な情報がなければ、作業を進めることはできないだろう。AIを使った開発もこれと全く同じだ。プロジェクトの目的、期待する機能、使用する技術、動作環境、予算、納期など、あらゆる具体的な情報、つまり「コンテキスト（文脈）」がなければ、AIは適切に機能しない。

筆者が最近行った実験でも、このことは明らかになった。AIに「ある統合機能を作ってほしい」とだけ指示してみたところ、AIは様々な質問を返してきた。どのようなことをしたいのか、どのように構築したいのか、といった、まさに筆者が最初の指示で与えなかったコンテキストを求めてきたのだ。AIは合理的な仮定に基づいて作業を進めようとするが、その仮定が必ずしも正しいとは限らない。必要なコンテキストをすべて一つの指示に詰め込むことは現実的ではないし、そもそもそうする必要もない。AIとの開発は、一度で全てを終わらせるものではなく、協力しながら少しずつ進めていく「協調的で反復的なプロセス」と捉えるべきだ。

この考え方に基づいたツールとして「Claude Skills」のようなものが挙げられる。これは、AIエージェントに必要なコンテキストを与え、タスク実行時の成功の定義や方向性を示すことで、開発者のアシスタントとして機能するように設計されている。まるで経験豊富な同僚をトレーニングするように、AIにプロジェクトの現実を伝え、目的に合った解決策を導き出す手助けをするのだ。プロジェクトの特定の側面では、人間が常に介入し、AIを導く必要がある。

では、なぜ開発に人間のエンジニアが必要なのだろうか。その一つに「スコープ（プロジェクトの範囲）」の決定がある。AIエージェントを使ってプロトタイプを作った際に、AIがそのプロトタイプをいきなり本番環境で使えるレベルにしようとして、過剰なセキュリティ機能やログ機能、認証機能などを勝手に付け加え、時間やリソースを無駄にしてしまった経験はないだろうか。AIは「ユーザーを満足させるために可能な限り最高の製品を作ろう」と考えるため、テスト用のちょっとしたアプリでさえ、完璧なものにしようとする傾向がある。しかし、人間のエンジニアはプロジェクトの全体像を把握し、この機能はテスト用だから最低限で良い、この部分は将来的に拡張できるように設計しよう、といった抽象的な判断や、創造的な思考ができる。これにより、不必要な機能の追加を防ぎ、スコープクリープ（プロジェクトの範囲が当初の計画を超えて拡大してしまうこと）を回避できる。

また、AIは与えられた情報に基づいて作業するため、たとえ人間の指示が不完全でも、合理的な範囲で不足している部分を補おうとする。しかし、「合理的」なことが必ずしも「正しい」こととは限らない。例えば、AIが作成したファイルを本来とは違うディレクトリに保存してしまったり、異なる顧客環境で作業すべきところを、別の環境で実行してしまったりすることがある。これらはAIの能力不足ではなく、人間が与えたコンテキストの不足が原因で起こる問題だ。AIは与えられた現実に基づいて最善を尽くすため、指示されていない部分は「合理的」な推測で補うが、それが結果的に間違いにつながることがあるのだ。

こうしたコンテキストのギャップを見つけ出し、AIの出力が意図した通りになっているかを確認するプロセスが「Eval（評価）」と呼ばれるものだ。これは地味な作業に思えるかもしれないが、非常に重要だ。AIを人間の知能を持つ存在と誤解していると、その出力をチェックするのは失礼だと感じたり、無意味だと考えたりするかもしれない。しかし、AIをコンテキストを受け継ぐ単なる「ツール」だと理解すれば、その出力のチェックは当然の行為となる。Evalを通じて、AIの生成物が本当に求めていたものと一致するかを体系的に検証することで、「たぶん動いているだろう」という曖昧な状態から、確信を持って「これが正しい」と言えるようになる。

ただし、Evalにも限界がある。Evalは、あなたが定義した仕様に対してAIの出力がどれだけ適合しているかを測定するものだ。プロジェクトは生き物のように変化するため、たとえ3週間前に完璧だと思って作成した仕様書でも、現在のプロジェクトの状況を完全に反映しているとは限らない。Evalは重要な作業だが、それだけでは不十分だ。プロジェクトは常に動いている目標であり、あなたもその動きに合わせて対応していく必要がある。

筆者は、複数の顧客のシステム内に組み込まれて動作するような、複雑な「組み込みインテグレーション」の開発も手掛けている。このようなシステムでは、一つの統合機能が複数の顧客環境にデプロイされ、それぞれの環境で独自の構成、認証情報、フィールドマッピング、そして各顧客特有の複雑な要件が存在する。つまり、あなたは一人の顧客のためだけでなく、現在および将来の全ての顧客のために開発を行っているのだ。これほど膨大なコンテキストをたった一つのプロンプトに詰め込むことは不可能である。だからこそ、自分の作業を丁寧に確認し、AIが奇跡を起こしてくれると期待するのをやめるべきなのだ。

結局、「ワンショット開発」は、怠惰な夢想に過ぎない。AIが間違いを犯すのは、AIが愚かだからではなく、あなたが不完全な現実を与え、それをAIが正しく埋めてくれると期待するからだ。AIは合理的にギャップを埋めようとするが、合理的なことが常に正しいとは限らない。開発者としての目標は、AIがあなたの意図から外れたときに、それを素早く見つけ出し、修正することにある。AIに早い段階で適切なコンテキストを与え、正しい方向へ導くことで、Claude Skillsのようなツールは「良い仕事の形」を保ちながらプロジェクトを進めることができる。さらに、自身の仮定をチェックするための評価基準を作成し、人間独自の能力である「なぜ」という問いに集中することで、AIを最も効果的に活用できるだろう。AIは、あなたが最も深く考えるべき部分を、喜んで通り過ぎて構築してしまうからだ。