AI仕様駆動開発で、なぜ仕様が必要なのか――推論を減らし、AI開発のコストを下げる

AI仕様駆動開発で、なぜ仕様が必要なのか。仕様はAIの推論を否定するものではなく、推論が必要な範囲を絞ることで、手戻りと高価なモデルへの依存を抑えるための仕組みです。公開した解説動画の内容をもとに整理します。

著者
岡崎 太
CTO / AIアーキテクト
公開日
読了時間
7分で読めます
Share

AIに任せるほど、なぜ「仕様」が重要になるのか

AIにコードを書いてもらうとき、私たちはつい「どのモデルを使うか」「どのツールを選ぶか」に目を向けます。もちろんモデルの性能は重要です。しかし、同じモデルに同じような依頼をしても、渡す前提や制約が違えば、結果は大きく変わります。

「いい感じに作ってください」と依頼すれば、AIは不足している情報を推測しながら実装します。推測が当たれば速く進みますが、既存の設計、業務ルール、例外処理、完了条件が共有されていなければ、もっともらしいけれど意図とは違うものになる可能性があります。

今回公開した動画では、AI仕様駆動開発において、なぜ仕様が必要なのかを解説しています。

AI仕様駆動開発|AIに丸投げはキケン?「仕様」の有無で開発結果はどう変わるか

サムネイルをクリックすると、YouTubeで動画を再生できます。

この記事では、動画で扱っている考え方を、特に「推論」と「コスト」の関係に焦点を当てて紹介します。

仕様を決めることは、AIが推測する確率を下げること

AIに仕事を依頼すると、AIは与えられたコンテキストから、次に必要な処理や実装を推測します。

たとえば「顧客情報を管理する画面を作って」とだけ伝えた場合、AIは次のようなことを考えなければなりません。

  • どの項目を表示・編集できるのか
  • 権限のない人には何を見せないのか
  • 入力に失敗したとき、どのメッセージを返すのか
  • 既存の画面やAPIと、どの設計方針を合わせるのか
  • どの状態になれば完成と判断するのか

これは、AIが賢くないから起きる問題ではありません。依頼の中に判断材料がないため、AIが複数の可能性から推測する必要があるのです。

仕様は、この可能性の数を減らします。

「顧客情報には氏名・会社名・メールアドレスを表示する」「管理者だけが編集できる」「メールアドレスの重複はエラーにする」「既存のエラー形式を使う」と決めておけば、AIが推測しなければならない範囲は小さくなります。

ここでいう「確率を下げる」とは、AIの回答が数学的に一つに固定されるという意味ではありません。実装の選択肢や、AIが補わなければならない前提を減らし、意図と異なる方向へ進む余地を狭めるという意味です。

曖昧な依頼では実装候補が分岐し、仕様・制約・受け入れ基準を渡すと実装へ向かう経路が絞られる図

推論を減らすことは、AIの能力を下げることではない

仕様を細かく書くと、「AIの自由な発想を奪ってしまうのではないか」と感じるかもしれません。

しかし、開発において必要なのは、毎回新しい答えを発明することではありません。既存の設計やチームのルールに沿い、決められた目的を安全に実現することです。

仕様によって減らすのは、価値のある設計判断ではなく、AIが本来知らないはずの情報を推測する作業です。

人間が先に決めるべきことを仕様に書き、AIには仕様に沿った設計・実装・検証を任せる。この分担にすると、AIの推論能力を「何でも推測させるため」ではなく、「仕様から最適な実装を組み立てるため」に使えます。

つまり、仕様はAIを弱くするものではありません。AIが力を使う場所を、意図的に選ぶためのコンテキストです。

推論を減らすと、なぜコストが下がりやすいのか

AIサービスの料金は、サービスによって異なりますが、利用するモデルや入出力するトークン量、追加の推論処理などに左右されます。複雑な判断を何度もAIにやり直させれば、その分だけ利用量が増えます。

仕様が曖昧なままだと、次のようなループが起こりやすくなります。

  1. AIが不足した前提を推測して実装する
  2. 人間が意図と違う箇所を見つける
  3. 追加の説明を送り、AIに修正させる
  4. 別の箇所で新しい解釈のズレが起きる
  5. 高性能なモデルに切り替えて、もう一度考えさせる

この状態では、コードを一度生成しただけでは終わりません。推測、修正、再確認の回数が増え、結果としてトークンと作業時間の両方を消費します。

一方で、仕様・制約・受け入れ基準が揃っていれば、AIは最初から狭い問題設定に取り組めます。実装の骨格が決まっている定型的な作業なら、必ずしも最上位のモデルでなければならないとは限りません。

推測、修正、再確認、高性能モデルへの切り替えが繰り返され、トークンと時間を消費するコストループ

ここで大切なのは、「仕様を書けば必ず安くなる」と単純化しないことです。仕様を書くための人間の時間も必要ですし、複雑な設計判断には高性能なモデルが有効な場合もあります。

それでも、推論が必要な仕事と、仕様に沿って実行できる仕事を分けることで、高価なモデルを使う場面を絞れる可能性があります。AIのモデル料金を下げるというより、高価な推論を必要な箇所にだけ使う。この考え方が、AI仕様駆動開発におけるコスト設計の出発点です。

モデルを使い分けるための仕様

AI仕様駆動開発では、すべての作業を同じモデルに任せる必要はありません。

たとえば、次のように仕事を分けられます。

作業 仕様が担う役割 モデル選択の考え方
目的や要件の整理 判断すべき論点を明確にする 高性能モデルを使う価値がある
既存コードの探索 見る範囲と確認観点を指定する 軽量モデルでも進めやすい
定型的な実装 入出力・制約・例外を固定する コスト効率のよいモデルを検討できる
複雑な設計判断 トレードオフと未決事項を明示する 高性能モデルや人間のレビューを組み合わせる
テスト実行と結果整理 合否条件を明文化する 実行・整理を分担しやすい

もちろん、実際の適性はタスク、モデル、ツール、コンテキストの量によって変わります。表は固定的な正解ではなく、モデルを一律に選ぶのではなく、仕事の性質に応じて配分するための考え方です。

複雑な判断と仕様に沿った実行を分け、タスクの性質に応じてAIモデルを使い分ける図

仕様は「AIへの指示書」ではなく、チームの判断基準

仕様という言葉から、分厚い要件定義書を想像する必要はありません。

AIに任せるタスクについて、最低限次のことが分かれば、推論の余地は大きく減ります。

  • 何を実現するのか
  • 今回はどこまでを対象にするのか
  • 何を対象外にするのか
  • 守るべき既存ルールは何か
  • どうなれば完了なのか
  • どのコマンドや画面で確認するのか

これらは、Markdownの仕様書、GitHub Issue、受け入れ基準、テストケースとして残せます。重要なのは形式の立派さではなく、AIと人間が同じ判断基準を参照できることです。

仕様がリポジトリに残っていれば、次のタスクでも再利用できます。AIに毎回背景を説明し直すのではなく、チームの前提をコンテキストとして渡せるようになります。

「AIに丸投げしない」とは、人間がすべて実装することではない

AIに丸投げしない、という言い方をすると、結局は人間が細かくコードを書くことになると思われるかもしれません。

AI仕様駆動開発で人間が担うのは、主に次の領域です。

  • 目的と優先順位を決める
  • 業務上のルールや制約を言語化する
  • AIに任せる範囲と任せない範囲を決める
  • 受け入れ基準を定める
  • 結果をレビューし、次の仕様へ反映する

人間の役割は、手作業でコードを積み上げることから、AIが正しく動ける環境を設計することへ移ります。AIは実装や調査を進め、人間は判断の境界と品質の基準を持つ。この分担ができると、AIを使うほど開発プロセスが安定していきます。

動画で解説しています

今回の動画では、AIに丸投げしたときに起こりやすいズレと、仕様の有無によって開発結果がどう変わるのかを、AI仕様駆動開発の考え方から解説しています。

「仕様を決めると、AIの推論能力を使わなくなる」という見方を出発点に、推論の範囲を制御すること、モデルを使い分けること、そして開発コストを設計することのつながりを説明しています。

AI開発を始めたものの、毎回修正指示が増えてしまう。高性能なモデルを使っているのに、成果物が安定しない。そのように感じている方には、モデルを変える前に「AIが推測している前提は何か」を見直すヒントになるはずです。

YouTubeで動画を見る

まとめ

仕様が必要なのは、AIの推論能力を否定するためではありません。AIが推測しなければならない範囲を狭め、重要な判断に推論を集中させるためです。

仕様によって選択肢と曖昧さを減らすと、手戻りが抑えられ、定型的な作業にはコスト効率のよいモデルを使いやすくなります。その結果、高価なモデルを使う場面を、複雑な判断や高い失敗コストを伴う仕事に絞れる可能性があります。

AI仕様駆動開発が目指しているのは、AIに考えさせないことではありません。何を人間が決め、何をAIに推論させ、何を仕様に沿って実行させるのかを設計することです。

モデルの性能を追いかけるだけでなく、AIに渡すコンテキストの質と、推論させる範囲を見直す。そこから、品質とコストの両方を考えたAI開発が始まります。

関連する考え方は、AI仕様駆動開発の紹介ページと、AI仕様駆動開発はなぜ生まれたのかでも紹介しています。