複雑なタスクではなぜ間違いやすいのか？
突然、複雑な問題を処理するよう言われた場面を想像してください。考えずに、いきなり答えを出したら、どれほどよい成果を出せるでしょうか？
おそらく間違えます。
始める前に問題をよく読み、条件を確認してから一段階ずつ処理すれば、通常は結果の信頼性が高まります。
大規模言語モデルでも同じです。
ただし、一つ注意が必要です。モデルに非公開の思考過程をすべて公開するよう求める必要はなく、長々と書かれた「考えています」という文章を正しさの証明にすることもできません。
本当に必要なのは、人が確認できる内容です。どの条件を使ったか、どの式や根拠を採用したか、必要な中間結果は何か、そして最終的な答えは何かを示します。
まず簡単な問題を見てみる
コービー・ブライアントとマイケル・ジョーダンは、同じ国の出身ですか？
直接回答し、確認できる根拠を一文で示してください。
この問題は複雑ではありません。コービー・ブライアントもマイケル・ジョーダンもアメリカ出身なので、同じ国の出身です。
このような簡単な問題なら、答えと必要な事実だけを明確に示せば十分です。慎重に見せるためだけに、長い過程を書く必要はありません。
では、少し込み入った問題ならどうでしょうか？
もう少し複雑な問題を見てみる
3 人が 3 日間で 3 桶の水を飲みました。
全員が 1 日に同じ量の水を飲むとすると、9 人が 9 日間で飲む水は何桶ですか？
答えを直接示してください。
「3、3、3」と「9、9」だけに目を向けると、表面の数字だけで感覚的に答えてしまいがちです。
本当にそうでしょうか？
まず、自分で計算してみます。
3 人が 3 日間なら、合計は 9 人日です。3 桶を 9 人日で割ると、1 人が 1 日に飲む量は 1/3 桶です。
9 人が 9 日間なら、合計は 81 人日です。これに 1 人 1 日当たり 1/3 桶を掛けると、27 桶になります。
したがって、表面の数字だけで置き換えるのは誤りで、正しい答えは 27 桶です。
重要な道筋を示す
このような問題で、モデルに「よく考えて」とだけ伝えても、役に立たないことがあります。
何でもできそうなインターンが、複雑な問題をうまく処理できない場面に似ています。能力がまったくないのではなく、何を先に確認し、何を次に計算すべきかを知らないのです。
そのようなときは、重要な道筋を少し示します。
Prompt は次のように書き換えられます。
次の問題を計算してください。
3 人が 3 日間で 3 桶の水を飲みました。全員が 1 日に同じ量の水を飲むとすると、9 人が 9 日間で飲む水は何桶ですか？
次の重要な手順で計算してください。
1. まず、3 人が 3 日間で合計何人日になるかを計算する。
2. 次に、1 人が 1 日に何桶飲むかを計算する。
3. 9 人が 9 日間で合計何人日になるかを計算する。
4. 最後に、全体の量を計算する。
答えを確認するために必要な式と中間結果を示し、最後に最終回答を分けて書いてください。
非公開の思考過程全体は出力しないでください。
確認可能な結果は次のとおりです。
元の状況の合計人日：3 × 3 = 9 人日
1 人 1 日当たりの量：3 ÷ 9 = 1/3 桶
目標の状況の合計人日：9 × 9 = 81 人日
合計量：81 × 1/3 = 27 桶
答え：27 桶
ここで本当に役立つのは、重要な道筋を示し、式と中間結果を検算できるようにすることです。
計算根拠と最終回答を分ける
なぜ、この二つを分けるのでしょうか？
答えをすぐに確認したい一方で、疑問があれば根拠まで戻って確認したいからです。
ただし、「確認可能な計算根拠」は、モデルの非公開の思考過程全体とは異なります。この問題なら、3 × 3 = 9 人日、3 ÷ 9 = 1/3 桶、81 × 1/3 = 27 桶 があれば、答えを確認できます。
最後に、モデルが手順を詳しく書いたからといって、必ず正しいとは限りません。計算問題は計算機やコードでもう一度検算し、事実に関する問題は一次情報に戻って確認してください。
簡単な問題では、答えと必要な根拠を明確にします。
複雑な問題では、重要な道筋を示し、確認可能な根拠と最終回答を分けます。
前の章： XML タグを活用する
はじめに戻る： Prompt Engineering とは？
Independent product builder · AI, agents and real workflows.