AIが指示書を書いても、AIが間違える
AIに指示書を書かせれば楽になる。そう思っていた時期が私にもありました。
ところが実際にやってみると、AIが書いた指示書を、別のAIが「ここ間違ってますよ」と突き返してくる。書いたのもAI、間違いを見つけたのもAI。で、間に立って頭を抱えているのが私。
何をやってるんだろう、と思いながら、でもこの構図には学びがあった。AIは賢い。賢いけれど、平気で事実を間違える。今日はその間違いを3パターンに分けて晒します。あなたも同じ罠にハマったことない？
パターン1：技術的な事実の誤り
最初にやられたのがこれ。AIにCursor向けの実装指示書を書かせたら、curlコマンドの接続先ポート（通信の出入口を示す番号）が「8000」になっていた。
ところが実物のサーバー設定ファイルを見ると、デフォルトのポートは「8765」。指示書の数字が、実物と違っていた。AIは「だいたいこのへんのポートでしょ」という顔で、それっぽい番号を埋めてくる。
これをCursor側が「ソースと違いますよ」と指摘して直してくれた。AI同士の指摘で助かったけれど、人間がそのまま流していたら数十分は溶けていた。
ポート番号、パス、コマンド。この手の「調べれば一発で分かる事実」を、AIは調べずに推測で書く。ここが第一の落とし穴。
パターン2：仕様書と指示書の食い違い
次は、書類が2枚あるときに起きる。
私は仕様書のMDと、実装の指示書を別々のタイミングで書かせていた。仕様書のほうでは関数の戻り値（処理の結果として返ってくる値）を「list」と決めていたのに、指示書のほうでは「dict」で返す前提になっていた。listもdictもデータの入れ物の型で、別物だ。
同じ機能の話なのに、2枚の紙で言っていることが食い違う。人間でもやらかすやつ。AIは前に書いた内容をいちいち覚えていないから、平然と矛盾する。
これもCursorが「仕様書と契約が合ってません」と拾ってくれた。書類が増えるほど、この手のズレは静かに増えていく。1枚ずつは正しく見えるのが厄介なところ。
パターン3：実物の画面を知らずに書く
これがいちばん笑えなかった。
ブラウザでの動作確認シナリオを書かせたら、AIは「session一覧を開いて…」という手順を組んできた。でもそれ、前のバージョンの画面なのよ。
今の実物は「ダッシュボード／会議室／タスク／プロジェクト」という構造に変わっていた。AIの頭の中にある画面と、目の前で動いている画面が別物。相方に「これ、どれのこと言ってんの？」と聞かれて、ようやく気づいた。
AIは実物を見ていない。学習した記憶や仕様書の文字だけで「たぶんこういう画面」を組み立てる。UIはとくに変わりやすいから、ここのズレが一番出やすい。
対処法：3つのチェックポイント
晒すだけだと愚痴で終わるので、運用をどう変えたかを置いておく。
- 指示書を書く前に、AIに現物のソースを読ませる。ポートもパスも、推測させずファイルを開かせてから書かせる。これでパターン1はぐっと減った。
- 仕様書と指示書を書いたら、その直後に型と契約を突き合わせる。後でまとめて確認しようとすると、ズレが埋もれる。書いた瞬間が一番見つけやすい。
- UI絡みは、現物の画面のスクショを見せてから動作確認シナリオを書かせる。文字情報だけだと、AIは過去の画面を再生してしまう。
3つとも共通しているのは「推測の前に現物」。AIに想像で埋めさせない、という一点に尽きる。
まとめ：完璧を期待しない、人間が間に立つ
AIは事実を間違える。これは欠陥じゃなくて仕様だと思って付き合うのが早い。
AIに「これで完璧でしょ」と渡したら、別のAIに3か所直された。
賢いAIに賢いAIを突き合わせて、間で人間が現物を確認する。この三角形が、今のところ一番事故が少ない。AIを信じすぎず、かといって全部を手で書くのも面倒。だから現物を見せる手間だけはケチらない。
道具が間違える前提で組めば、間違いは事故じゃなくて想定内になる。で、あなたの指示書、現物と突き合わせたのはいつ？