2-13　プロンプトのデバッグ：うまくいかない原因を切り分ける

直しても直しても噛み合わず、「このAIとは相性が悪い」と結論づけてツールを乗り換えた。そして新しいツールでも、同じことが起きた——心当たりはありませんか。

相性ではありません。原因の切り分け方という、手順の問題です。この記事は、その切り分けの手順書です。

うまくいかないプロンプトは、感覚ではなく手順で直せます。プログラマーがバグを直すのと同じ、デバッグという技術です。切り分けの原理はどのAIでも共通なので、ツールを乗り換えても効きます。

反復改善サイクル（2-12）を回していても、「何度直してもうまくいかない」状況は起きます。そこで必要になるのがプロンプトのデバッグ——プログラマーがバグを直すように、論理的に原因を切り分けて改善する技術です。

まず、デバッグが必要な症状は5つに分類できます。
①指示の無視（伝えたのにやらない）
②形式のズレ（内容は良いが形が違う）
③内容の的外れ（そもそも方向が違う）
④品質不足（浅い、雑）
⑤過剰（長すぎる、余計なことをする）
まず自分の不満がどの症状かを特定します。ここが曖昧なままだと、修正は当てずっぽうになります。

次に、4ステップで進めます。
ステップ1：問題の特定。「回答が長すぎる」のように症状を一文にします。
ステップ2：原因の切り分け。依頼前の6問（2-2〜2-6：目的・利用場面・根拠・操作・制約・受け入れ条件）のどこに判断漏れがあるかを点検します。長すぎるなら受け入れ条件、的外れなら目的・利用場面、根拠のない断定なら資料の扱いが候補です。
ステップ3：仮説を立てる。「長さの上限がないため、AIが詳細さを優先したのでは」と原因を一つ選びます。
ステップ4：改善を試す。仮説に対応する修正を1箇所だけ行い、再実行して検証します。
複数箇所を同時に変えると、何が効いたのか分からなくなります。

たとえば「回答が長すぎる」ケース。仮説1「長さ指定がない」→「400字以内で」を追加。それでも長いなら仮説2「役割が『丁寧な解説者』になっている」→役割を「要点だけ話すアドバイザー」に変更。このように仮説→検証を重ねれば、必ず原因に到達します。

最後にチェックリストを持ちましょう。症状を一文で言えるか。6問のどこに判断漏れがあるか見当を付けたか。修正は1箇所ずつか。改善したら、その学びを次の依頼に反映したか。デバッグの経験は、そのまま依頼設計力の向上になります。

保存版・デバッグ4ステップ

• ①症状を一文にする（無視／形式ズレ／的外れ／品質不足／過剰）

• ②依頼前の6問（2-2〜2-6）のどこに判断漏れがあるかを切り分ける

• ③原因の仮説を1つ選ぶ

• ④修正は1箇所だけ行い、再実行して検証する

デバッグの記録は、そのまま次の依頼設計の資産になります。"相性が悪い"と乗り換える前に、切り分ける——冒頭の「新しいツールでも同じ失敗」の悪循環は、ここで断てます。

やってみよう: 最近の「うまくいかなかった依頼」を1つ取り上げ、症状の分類→容疑要素の特定→修正1箇所、をやってみましょう。切り分けは次のプロンプトが手伝います。

関連する無料ケーススタディ: 33「『回答が長すぎるAI』を、手順どおりに直してみた実録」 ／ 34「『昨日は通ったのに』を、運のせいにするのをやめた」

📍 番号や読む順に迷ったら講座マップへ。目的別ルートと全84レクチャーの対応表があります。