「ステップバイステップで考えて」の次に試すプロンプト設計
LLMに難しい問題を解かせるとき、よく使われる指示があります。
Let's think step by step.
この一文は今でも役に立つことがあります。ただし、2025年以降の研究を見ると、実務の初期設定としては少し粗いです。ここでいう「粗い」とは、精度だけでなく、コスト、監査性、タスク適合性を区別せずに同じ指示で済ませてしまう、という意味です。
数学推論では、段階的に考えさせることで改善する場合があります。一方で、心理課題、単純問題、pattern-based ICL、評価タスクでは、CoTやlong-CoTが直接回答より悪くなる例も報告されています。長く考えさせるほど、トークン、レイテンシ、コストも増えます。
この記事では、2025年以降の論文や公式記事をもとに、認知的プロンプトと推論ワークフローを整理します。後半では、Hono公式ドキュメントを題材にした小さなQA検証も紹介します。
ここでいう「認知的プロンプト」とは、単に「詳しく考えて」と指示することではありません。問題理解、根拠確認、想起、計画、自己点検、脱バイアス、評価計画、バックトラックなど、考えるための足場をプロンプトやワークフローとして用意する方法を指します。後で出てくる Cognitive Tools は、その一例であり、この記事全体で使う上位概念とは分けて扱います。
この記事の目的は、新しいプロンプト技法を網羅することではありません。どのタスクで、どの型を、どのリスク込みで試すかを考えるための足場を置くことです。
先に結論
私なら、まず次の順番で確認します。
-
直接根拠型をベースラインにする
まず「与えた根拠だけで答える」短いプロンプトを測ります。ここを測らないと、工夫を足した効果が分かりません。 -
ドキュメントQAでは、根拠引用型と自己点検型を比べる
HonoドキュメントQA 30問の探索的検証では、cite_then_answerとself_checkがルール採点で同率の25/30でした。 -
短さと品質のバランスを取りたいなら、自己点検型を候補に残す
同じ検証では、self_checkは平均212.3文字で25/30でした。cite_then_answerより短く、ルール通過数は同じでした。ただし、section_hintありの小規模検証であり、通過例の誤陽性も網羅確認していません。一般に優位だと結論づけるのではなく、自分の質問セットで再評価する候補として扱うのが安全です。 -
数学・論理推論では、認知ツール型を別枠で試す
Cognitive Tools は数学推論で改善が報告されています。ただし、今回のHono検証で使ったのは論文手法そのものではなく、着想を使った簡易テンプレートです。 -
CoTをデフォルトにしない
CoTは効く場面もありますが、悪化する場面もあります。精度だけを見ず、出力長、レイテンシ、コスト、失敗例も一緒に見ます。
用語を短くそろえる
| 用語 | 意味 |
|---|---|
| CoT | Chain-of-Thought。「ステップバイステップで考えて」のように途中の考え方を出させる方法 |
| long-CoT | CoTをさらに長くした推論。難問では役立つことがあるが、簡単な問題では冗長になりやすい |
| RAG | 外部ドキュメントを検索し、その結果を根拠に回答させる作り方 |
| retrieval | RAGで、どの文書・どの箇所を取ってくるかを決める検索部分 |
| chunking | 長い文書を小さなまとまりに分けること |
| context window | モデルに一度に渡せる入力量の上限 |
| token | モデルが扱う文字列の単位。入力や出力が長いほど増える |
| Hono | TypeScript向けの軽量Webフレームワーク。今回は公式ドキュメントQAの題材として使った |
つまり、見るべきなのはプロンプトだけではありません。検索、文書の切り方、採点方法も一緒に見る必要があります。後述のHono検証でも、失敗の一部はこの点に関係していました。
実務で使うプロンプトの型
| 型 | 何を足すか | 向いている場面 | 主なリスク |
|---|---|---|---|
| 直接根拠型 | 「根拠だけで答える」「不明なら不明」と明示する | RAG QA、仕様確認 | 検索が外れると不明回答になる |
| 根拠引用→回答型 | 回答前に根拠文を抜き出させる | 監査可能なQA、サポート回答 | 回答が長くなる |
| 自己点検型 | 初期回答後に、根拠不足・推測を点検する | 仕様QA、レビュー | レイテンシと出力長が増える |
| 認知ツール型 | 理解、想起、検査、バックトラックを手順化する | 数学、論理、多段推論 | 簡単な問題には重い |
| 脱バイアス型 | ステレオタイプや一般化を避ける | 採用、教育、医療説明、意思決定支援 | 「公平そうな文」だけでは不十分 |
| 入力書き換え型 | 誘導的な入力を中立化する | 金融、法務、医療などの判断支援前処理 | ユーザー意図を削りすぎる |
| 方法選択型 | 先に解法や手順を選ばせる | 問題タイプが混在するQA | 方法選択自体を間違える |
| 評価計画型 | 採点前に評価観点を作らせる | LLM-as-a-Judge、比較評価 | judgeのバイアスが残る |
この分類は、網羅を狙ったものではありません。実務で最初に試す候補を選ぶための簡易地図です。
図解: タスク別に最初に試す型
CoTを先に足すのではなく、タスクの失敗モードから型を選びます。
最小テンプレート
ここでは、Hono検証で使った4種類に絞ってテンプレート化します。脱バイアス型、入力書き換え型、方法選択型、評価計画型も実務では重要ですが、今回の小さな検証対象ではないため、別途評価が必要です。
直接根拠型
あなたは与えられたCONTEXTだけを根拠に答えるアシスタントです。
制約:
- CONTEXTに書かれていることだけで答えてください。
- 不明な場合は「コンテキスト内では確認できません」と答えてください。
- できるだけ簡潔に答えてください。
QUESTION:
{question}
CONTEXT:
{context}
ANSWER:
まず測るベースラインです。検索されたコンテキストに根拠がない場合は「分からない」と答えます。これはモデルの失敗というより、retrieval側の失敗です。
根拠引用→回答型
手順:
1. CONTEXTから、回答に必要な根拠文を最大3個だけ抜き出してください。
2. その根拠に基づいて答えてください。
3. CONTEXTにないことは推測しないでください。
出力形式:
根拠:
- ...
回答:
...
QUESTION:
{question}
CONTEXT:
{context}
回答の検査がしやすくなります。サポート回答や仕様確認に向きます。欠点は、回答が長くなりやすいことです。
自己点検型
次の順で処理してください。ただし出力は最終回答だけにしてください。
1. 初期回答を作る。
2. その回答が次を満たすか確認する。
(a) CONTEXTに根拠がある
(b) 質問に直接答えている
(c) 推測を含まない
3. 問題があれば修正する。
QUESTION:
{question}
CONTEXT:
{context}
最終回答:
回答を長くしすぎずにミスを減らしたいときに試しやすい型です。ただし、根拠が検索されていなければ正答にはなりません。
認知ツール型
内部手順を短く実行してください。長い思考ログは出さないでください。
- understand_question: 質問が求める事実を1行で特定する。
- recall_related: CONTEXT内の関連箇所を最大3点に絞る。
- examine_answer: 回答がCONTEXTから外れていないか確認する。
- final: 日本語で答える。
出力には final だけを書いてください。
CONTEXTにない場合は「コンテキスト内では確認できません」と答えてください。
QUESTION:
{question}
CONTEXT:
{context}
final:
Cognitive Tools に着想を得た簡易版です。論文のtool-calling設計そのものではありません。
2025年以降の研究で見えていること
大きく3つの方向があります。
以下の表は、各研究手法の効果をそのまま実務に持ち込めるという意味ではありません。実務で試す候補として読み替えたものです。
| 使いどころ | 近い手法 | 実務での読み方 |
|---|---|---|
| バイアスを減らす | Intent-aware self-correction / SACD / “Could you be wrong?” | 採用、教育、医療説明、意思決定支援などで、属性に関する雑な推測を減らす候補 |
| 数学・複雑推論を解く | Cognitive Tools / CoM / CoRE-Eval | 理解、想起、検査、解法選択などの足場を作る候補 |
| QAや評価を安定させる | SRP / EvalPlanner | 根拠経路を扱うQAや、LLM-as-a-Judgeで評価手順を作る候補 |
Intent-aware self-correction は、回答生成、フィードバック、修正を反復します。BBQの曖昧文脈、9カテゴリ、2,118例で改善が報告されています。
SACDは、入力プロンプト中の認知バイアスを検出、分析、書き換える反復方式です。回答を直すのではなく、質問を中立化する点が特徴です。
Cognitive Tools は、understand_question、recall_related、examine_answer、backtracking を内部推論操作として使わせます。GPT-4.1のAIME 2024でpass@1が32%から53%へ上がった一方、平均出力トークンも約2,000から約4,200へ増えたと報告されています。
CoMは、問題状態に応じて methodology を選びます。問題タイプが混ざるQAでは参考になりますが、方法選択を外すリスクは残ります。
EvalPlannerは、回答を採点する前に評価計画を立てる手法です。ただし、主結果は学習済みjudgeモデルを含むため、単なるプロンプト改善として読むと誤解しやすいです。
CoTをデフォルトにしない理由
CoTは性能を下げることがある
"Mind Your Step (by Step)" は、心理学的に熟慮が悪化させる課題で、CoTが6課題中3課題でSOTAモデルの性能を有意に下げ、最大36.3%絶対精度低下を報告しています。
"The Curse of CoT" も、pattern-based ICLでCoTやreasoning variantsがdirect answeringを一貫して下回ったと報告しています。
長く考えるほどコストが増える
"Do NOT Think That Much for 2+3=?" や "Stop Overthinking" は、long reasoning modelが簡単な問題でも冗長な解法を生成する問題を扱っています。
CoThinkは、単純問題でreasoning-optimized modelsが5〜10倍長い出力を出す例を示し、平均22.3%のトークン削減を保ちながらpass@1差を平均0.42%以内に抑えたと報告しています。
CoTログは監査証跡ではない
"Reasoning Models Don't Always Say What They Think" は、モデルがヒントを使った場合でも、多くの設定でCoTがその使用を20%未満しか開示しないと報告しています。
CoTは説明文としては便利です。しかし、実際の推論を忠実に表すログとしては過信できません。外部根拠、実行テスト、検索結果、別モデル検証と組み合わせた方が無難です。
小さな検証: HonoドキュメントQA
Hono公式ドキュメントの llms-full.txt を使い、30問の仕様QAで4種類のプロンプトを比べました。
| 項目 | 内容 |
|---|---|
| 対象ドキュメント | Hono公式 llms-full.txt
|
| 質問数 | 30問 |
| 質問範囲 | API仕様、Routing、Middleware、Helper、Testing、Deployment、RPC、型安全 |
| 比較対象 | 4種類のプロンプトテンプレート |
| モデル | openai-codex/gpt-5.4-mini |
| thinking設定 | minimal |
| 採点 | 期待語句ベースのルール採点 + 失敗例のみ軽量レビュー |
section_hint は検索補助に使いました。一方、expected / acceptable_ja は回答後の採点だけに使い、検索コンテキストの選択には使っていません。
結果は次の通りです。
| prompt | pass_rate | passed | mean_latency_s | mean_answer_chars |
|---|---|---|---|---|
direct_grounded |
0.767 | 23/30 | 8.337 | 157.1 |
cite_then_answer |
0.833 | 25/30 | 9.437 | 405.6 |
cognitive_tools_compact |
0.800 | 24/30 | 8.030 | 161.0 |
self_check |
0.833 | 25/30 | 9.253 | 212.3 |
ルール採点では、cite_then_answer と self_check が同率でした。ただし、cite_then_answer は平均405.6文字で、self_check の212.3文字より長くなりました。
なお、レイテンシは手元環境での平均値です。p95レイテンシ、入力・出力トークン、API costは測っていないため、速度や費用の優劣をこの表だけで判断することはできません。
失敗例だけを非ブラインドで軽く見ると、意味としては正しいのに期待キーワード不足で落ちた例もありました。通過例の誤陽性は網羅確認していないため、この検証は正式な人手評価ではありません。
どう選ぶか
正答率、短さ、速さ、監査しやすさのどれを重視するかで、選ぶ型は変わります。
| prompt | 向いている場面 |
|---|---|
direct_grounded |
まず測るベースライン。短い仕様確認に向く |
cite_then_answer |
根拠を見せたいサポート回答や監査ログ向き |
self_check |
今回の小規模検証では、回答を長くしすぎずに誤答を減らしたい場面の候補 |
cognitive_tools_compact |
数学・論理・複数条件の推論で再評価したい候補 |
今回のHono検証では、失敗の多くは「モデルが考えられない」ことより、「必要な根拠がコンテキストに入っていない」ことに近い問題でした。RAGやドキュメントQAでは、プロンプトだけでなく、retrieval、chunking、context window、採点方法も一緒に見る必要があります。
実務での検証手順
自分のタスクで試すなら、次の順番にします。
-
根拠付き直接回答をベースラインにする
追加の根拠引用、自己点検、認知ツールを足さず、最小プロンプトを測ります。 -
候補プロンプトを1つずつ追加する
複数の工夫を同時に入れると、何が効いたのか分からなくなります。 -
精度だけでなくコストも記録する
accuracy、pass@1だけでなく、入力トークン、出力トークン、p95レイテンシ、APIコストも見ます。 -
失敗例を分類する
誤答、不十分な根拠、過剰推論、フォーマット違反、バイアス、幻覚、コスト過多に分けます。 -
retrievalも評価する
ドキュメントQAでは、検索コンテキストの切り出しが結果を大きく左右します。 -
モデル更新時に再テストする
プロンプトの暗黙要件は、モデル更新で退行する可能性があります。
まとめ
2025年以降の研究を見ると、LLMの推論を改善する方向は「もっと長く考えさせる」だけではありません。
この記事で重く見たいのは、問題理解、根拠確認、想起、検証、反省、バックトラック、脱バイアス、評価計画などを、明示的な足場として設計することです。
ただし、どの手法も万能ではありません。CoTやlong-CoTは課題によって悪化し、コストを増やし、監査証跡としても不十分です。
実務では、まず根拠付き直接回答をベースラインにします。そのうえで、候補手法を1つずつ追加し、精度、コスト、失敗例を同時に見ます。RAGやドキュメントQAなら、retrieval、chunking、context windowも一緒に見る。今回のHono検証も小規模な探索であり、一般的な優劣を決めるものではありません。プロンプトだけを触り続けるより、自分の質問セットで測り直す方が原因を探しやすくなります。
Discussion