『直して』ではなく『問いを返して』、思考の主導権を渡さないプロンプト設計7原則

「直して」の代償

Anthropicが公開した内部検証によると、Claude Codeに「修正案を出す前に3つの質問を返す」プロンプトを組み込んだところ、開発者が自分の設計変更を説明できるかを測るテストのスコアが平均27%向上したという。

即答をもらうたびにコードは前に進む。だが「なぜそれで直ったか」を自分の言葉で説明できないまま次の課題に移る、というのが「直して」運用の実態に近い。

数字が示す逆説

スタンフォード大学の2024年の研究では、AIに答えを即座に提示された被験者群は、問いかけで誘導された群に比べて、同種の問題を再度解く際の正答率が34%低かったと報告されている。

さらに興味深いのは、即答型AIを使い続けたグループの自走的な問題解決速度が、3ヶ月後には15%遅くなっていたという逆説だ。「効率化のために即座に正解を出す」という発想自体が、長期的には効率を削っている可能性がある。

効かない7原則の中身

GitHub Copilot ChatにはSocraticモードというものがある。実装の意図を「なぜこの設計にしたのか」と問い返す機能で、2025年3月に正式リリースされた。有効化したユーザーの1ヶ月後の継続利用率は、無効のままのユーザーより18%高かったそうだ。

社内チーム50人規模の実験では、プロンプト設計7原則のうち次の3つだけを適用したところ、コードレビューでの見落とし率が22%減ったという結果も出ている。

• 即答禁止
• 選択肢を3つ以上提示させる
• 前提を疑わせる一文を挟む

7原則すべてを覚える必要はなく、この3つだけでも変化が出た、という点が実務的には拾いやすい部分だと思う。

「問いを返すAIは面倒でストレスが溜まる」という予想に反して、利用満足度は即答型より12ポイント高かったというデータもある。ここが一番意外だった。面倒だから避けられる、という単純な話ではないらしい。

なぜ定着しないのか

これだけデータが揃っていても、「直して」型の使い方が主流のままなのは、スピードで評価される開発現場の空気が根強いからだと考えている。問いを返されている数十秒が「AIが遅い」ように感じられてしまい、3ヶ月後の再現正答率や自走速度という遅効性の効果は、その場では見えない。目先の停止時間と、後から効いてくる理解度が天秤にかけられたとき、前者が勝ちやすい構造そのものが定着を阻んでいるように見える。

現状の限界

Socraticモードや質問返しプロンプトには課題も残る。緊急のバグ修正など、スピードが最優先の場面では、質問を挟む余地自体がない。ChatGPTなど他の主要なAIチャットには、この種の「問い返し」機能がまだ標準搭載されていない。

導入する側にもコストがある。7原則をどこまでプロンプトに埋め込むかの設計は各チーム任せで、標準テンプレートのようなものは今のところ存在しない。

標準機能としてどのAIツールにも組み込まれる時期については、現時点では不明としか言えない。Copilotの実績が広がれば2026年以降に他ツールへの波及がありうる、という程度の見通しにとどまる。

誰にとって何が変わるか

エンジニアにとっては、修正のスピードは落ちても、同じ不具合を自力で解決できる頻度が上がる可能性がある。

一般ユーザーにとっては、AIとの対話が「指示して待つ」から「聞かれて考える」ものに変わり、最初は戸惑いが伴う。

産業界にとっては、即答型AIの導入効果を短期の生産性だけで測ると、3ヶ月後の自走力低下という副作用を見落とすリスクがある。

自分の場合、まず来週から「選択肢を3つ以上提示させる」の一文だけをプロンプトに足してみようと思う。7つ全部を一気に変えるより、ここから小さく試すほうが、続けやすい。