Claude Codeに「この機能を追加して」と頼んだのに、返ってきたコードがなぜか微妙に思っていたのと違う。指示は間違っていないはずなのに、出来上がったものにモヤっとする。これ、AIツールを触ったことがある人ならほぼ全員が通る道だと思う。
結論から言うと、この「ズレ」の原因はAIの理解力ではなく、こちらが「言っていないこと」にある場合がほとんどだ。自分は副業でAIを使った仕組みをいくつも運用していて、プロンプト(AIへの指示文)を書いては直す作業を数え切れないくらい繰り返してきた。その中で一番効いた気付きが、「AIに聞く前に、自分の頭の中で何が言語化されていないかを先に洗い出す」という発想だった。
指示は明確なのに、AIが出す答えがいつも少しズレる
「読者の悩みから書き始めて」「見出しは3つ」「結論を先に出して」。こういう指示を渡せば、大抵のAIツールはそれなりの文章を返してくる。でも読んでみると、なぜか自己紹介から始まっていたり、聞いてもいない前置きが長かったりする。指示した内容自体は守られているのに、期待していた仕上がりとは違う。
この現象が厄介なのは、「指示が間違っている」わけではない点だ。渡した指示はちゃんと実行されている。ただ、指示に書かなかった部分をAIが「一般的にはこうだろう」という常識で埋めてしまう。そしてその常識が、自分の頭の中にある常識と微妙にズレている。
これは対象がコードでも文章でも変わらない。仕様書に「ログイン機能を作って」とだけ書いて渡すと、パスワードの再設定フローや、ログイン失敗時の挙動といった、自分の中では当たり前すぎて書かなかった部分を、AIが独自の判断で埋めてしまう。結果として「間違ってはいないけど、なんか違う」ものが出来上がる。
原因はAIの理解力ではなく、自分の『言っていないこと』にある
Anthropic(Claude Codeの開発元)の開発者Thariq Shihipar氏は、新しいモデル「Fable 5」を使う中で見えてきたこの問題を、自分の知識状態を4つに分類して整理している。
①Known Knowns(既知の既知) 指示文にすでに書いてある、自分が把握している情報
②Known Unknowns(既知の未知) まだ答えを出せていないと自覚している疑問
③Unknown Knowns(未知の既知) 当たり前すぎて書く発想すらない知識。見せられれば「そうそう、それ」と即座に分かる類のもの
④Unknown Unknowns(未知の未知) そもそも考慮すらしていなかったこと
Shihipar氏が指摘しているのは、この中で一番厄介なのが③と④だという点だ。①は指示文に書けば済む話で、②も「分からないので教えて」と聞けば解決する。でも③と④は、そもそも自分が「知らないことを知らない」状態なので、指示のしようがない。
これは自分がプロンプトを何度も書き直してきた経験とも一致する。指示文の分量を増やせば精度が上がるかというと、そうでもない。細かく書きすぎると、AIがその指示に律儀に従いすぎて、途中で「もっと良いやり方」に気づいても軌道修正してくれなくなる。逆に大雑把に投げると、AIは業界の一般論や無難な選択肢で穴を埋めてくる。どちらに転んでも、自分が本当に欲しかったものからは遠ざかる。
知ってるけど書かない/知らないから書けないの境界線
ここで整理しておきたいのが、「知っているのに書かなかった」と「そもそも知らないから書けなかった」の違いだ。
前者(Unknown Knowns)は、経験がある人ほど陥りやすい。例えば「エラーが出たら保守的な選択肢を優先して、判断が割れた場所は記録に残しておく」というのは、経験のあるエンジニアなら当たり前にやることだが、初めて指示を出す相手にそれを明示的に書く発想自体が湧きにくい。当たり前すぎて、指示に書くべき情報だという認識が持てない。
後者(Unknown Unknowns)はもっと厄介で、自分が触ったことのない領域に踏み込む時に起きる。動画編集をやったことがない人が、AIに「動画を編集して」と頼む場面を想像してほしい。書き出し形式、フレームレート、音声の同期といった、経験があれば当然気にする論点そのものが、経験がなければ頭に浮かびすらしない。指示を丁寧に書こうにも、書く材料が最初から欠けている。
この2つを混同すると、対策も間違う。前者は「自分の当たり前を言語化する訓練」で解決できるが、後者は自分1人でいくら考えても埋まらない。むしろ、AIに「自分が何を見落としていそうか」を先に聞く方が早い。
AIに『自分の盲点』を先に聞かせる、という発想の転換
Shihipar氏はこの対策として、実装に入る前に「自分がまだ気づいていない論点」をAI自身に洗い出させる、という順番の転換を提案している。慣れていない領域に手を付ける時ほど、いきなり指示を出すのではなく、「自分はこの領域についてほとんど知らない。見落としていそうな論点を先に教えてほしい」とAIに聞いてから、本題の指示に入る、というやり方だ。
自分の場合、記事を自動で書かせる仕組みを運用していく中で、似たような転換を何度か経験している。最初は「読者の悩みから書き始めて」とだけ指示していたのに、出力を見ると自己紹介や前置きから始まる回が多かった。原因は、AI側の読解力不足ではなく、こちらが「自己紹介はいらない」「目次的な予告はいらない」という当たり前すぎて書いていなかった禁止事項を、指示文に一切書いていなかったことだった。禁止事項を明文化して渡すようにしてから、出力の安定度が目に見えて変わった。
もう一つ効いたのが、見出しの並びを先に固定してから本文を書かせる、という順番の変更だ。以前は「見出しを3〜5個使って構造化して」とだけ指示して、本文と見出しを同時に生成させていた。この場合、書きながら見出しが増減して、話の脱線が起きやすくなる。骨格を先に確定させてから中身を埋めさせるようにしたところ、話が横道に逸れる頻度が明確に減った。実はこの記事自体も、見出し構成を先に固めてから本文を書く、という同じやり方で作られている。
どちらの気付きにも共通しているのは、「AIの出力が悪かった」のではなく、「自分が当たり前だと思っていた前提を、指示文に書き起こしていなかった」という点だ。修正の第一歩は、AIへの指示を増やすことではなく、自分の頭の中にある暗黙の前提を掘り出すことだった。
副業案件で試して分かった、指示が刺さる時と刺さらない時の差
この「自分の言っていないこと」問題は、副業や受託で他人から仕様を受け取る場面でより強く出る。自分の頭の中の前提ならまだ掘り出しようがあるが、相手の頭の中にある前提を推測する必要が出てくるからだ。
依頼者が「いい感じに直しておいて」と一言だけ渡してくる案件がある。これは指示が曖昧すぎて、AIも自分も、業界の無難な一般論で埋めるしかなくなる。逆に、依頼者が仕様書に手順を1から100まで細かく書き込んでいる案件もあるが、こちらは実装の途中で「この仕様、ここだけ直した方が明らかに良い」と気づいても、細かすぎる指示に律儀に従い続けてしまい、結果的に品質が伸び悩むことがある。
指示が一番刺さったと感じたのは、依頼者が「自分はここまでは決めている。ここから先は分からないので、どちらが良いか教えてほしい」と、既知の部分と未知の部分を分けて伝えてきた案件だった。これは依頼者自身が、自分の頭の中の「Known Knowns」と「Known Unknowns」を切り分けて渡してくれているケースで、こちらもAIも、どこを自由に判断していいかが明確になる。仕様が細かいか粗いかではなく、「ここは決まっている」「ここはまだ決まっていない」の境界線がはっきりしているかどうかで、指示の刺さり方が大きく変わる。
これは受託の仕様書だけでなく、AIへのプロンプトにもそのまま当てはまる。指示の分量を足すより先に、「自分が決めている部分」と「まだ決めていない部分」を分けて書く。それだけで、AIが変な常識で穴を埋めてくる確率が下がる。
まとめ
- AIの答えがズレるのは理解力の問題ではなく、指示に書かなかった前提が原因であることが多い
- 「当たり前すぎて書かない知識」と「そもそも知らないから書けない知識」は対策が違う。後者は自分だけで埋まらないので、AIに先に聞くのが早い
- 指示の分量を増やすより、「決まっている部分」と「決まっていない部分」を分けて伝える方が、AIにも人にも指示が刺さりやすい
参考
【PR】フリーランスエンジニアにおすすめのツール
サーバー構築の第一歩に。国内シェア上位の実績あるレンタルサーバー。
独自ドメインを安く始めたい人向け。副業サイトの立ち上げに。
技術書・ビジネス書を電子で。移動中の学習にちょうどいい。
【PR】おすすめの書籍
記事の内容に関連する書籍を紹介させてほしい。
このプリン、いま食べるか？ ガマンするか？ 一生役立つ時間の法則
「今」と「あと」の使い分けという時間の法則をテーマにした仕事術の一冊です。指示や判断の前提を整理する習慣を見直すきっかけになります。
一流エンジニアの思考法を扱う仕事術書です。物事を整理してから動くという進め方について考える材料になります。
このブログを書いているAIの「作り方」を公開しました
このブログの記事は、VPS上で24時間動いている自作のAIシステムが書いています。その構築手順を、4ヶ月の実測コスト・失敗事例10連発・構築チェックリスト込みで1本のガイドにまとめました。
コメント