第4章 推論と多段階タスク

学習目標

• 推論モデル、推論トークン、推論の強度が品質・費用・遅延に及ぼす影響を説明する。
• 推論の強度を、タスクの種類と遅延の要件に合わせて選び、その選択を評価によって確かめる。
• 推論モデルに合う指示の水準に調整し、思考過程ではなく検証可能な根拠を求める。
• 多段階タスクを段階ごとのプロンプトに分け、段階間の入出力契約とゲートを設計する。
• 分割が損になる場合を見分け、並列と逐次を区別する。

はじめに

あるマーケティング代理店が、広告文を作るプロンプトに「段階ごとに、丁寧に考えよ」と入れ、推論の強度を最も高く設定しました。結果は少しよくなりましたが、応答ごとに数十秒かかり、請求額は3倍になりました。反対に、契約書の確認機能は、速く処理しようと低い強度で一度に処理していましたが、3つ以上の条件が絡む条項では、判断が頻繁に間違っていました。広告チームは応答を待つうちに締切を逃し、契約確認チームは誤った判断を信じ、危険な条項を1つ、そのまま見過ごしました。両チームは正反対に見えましたが、同じ間違いをしていました。考えることにかかる費用を、タスクの性質に合わせていなかったのです。

この章では、モデルが「考える」とは何か、その費用がどこで発生するのかという話から始めます。続いて、推論モデルと通常モデルの違い、推論の強度という調整つまみとそれを合わせる手順、出力上限と推論トークンの関係、推論モデルに合ったプロンプト、思考過程を出力に書かせてはいけない理由を見ていきます。後半は、タスクの分け方です。ワークフローパターン、段階間の入出力契約、自己レビューを具体的な検査にする方法、並列と逐次、サブエージェントを扱います。「さらに深く」では、過度な分割の費用と、複数のコンテキストウィンドウにまたがるタスクを見ていきます。

重要な概念

推論は計算用紙

数学の試験で計算用紙に解法を書いて解く生徒は、暗算する生徒より難問に強い一方、時間がかかります。推論モデルも回答前に用紙へ考えを書きます。Anthropicは、思考機能が有効なモデルは問題を整理し直し、複数の方法を試し、中間結果を確かめ、合わない道を捨てると説明しています。

この用紙は無料ではありません。両社は同じ構造を説明しています。

いつ、どれほど推論するかも設計の一部です。推論は手元の情報を深く検討するだけで、コンテキストにない新しい事実を生み出すものではないことも覚えておく必要があります。

推論モデルと通常モデル

OpenAIのガイドは、推論モデルを「先輩の同僚」、通常のGPTモデルを「新人の同僚」にたとえています。先輩は高い水準の指針だけでも働けますが、新人には明確な指示が必要だということです。推論のベストプラクティスは、推論モデルを、複雑な多段階の問題を計画する「計画担当」、GPTモデルを、よく定義されたタスクを速く安く処理する「実務担当」にたとえ、ほとんどの業務フローでは両方を併用すると説明しています。

Anthropicは、最新モデルで適応型思考（adaptive thinking）を使っています。モデルがリクエストの複雑さと推論の強度設定を見て、考えるかどうか、どの程度考えるかを自分で決める方法で、簡単な質問には、考えずに直接答えます。一部の最新モデルでは、思考は常に有効で、無効にできません。以前の拡張思考（extended thinking）で使っていたbudget_tokensは、Claude Opus 4.6とSonnet 4.6ではまだ動作しますが、廃止予定であり、Claude 4.7以降のモデルでは400エラーになります。現在は、推論の強度が主な調整手段です。

推論の強度という調整つまみ

両社とも低強度は速度・費用、高強度は徹底した推論に有利と説明しています。Anthropicによれば、強度は思考だけでなく説明やツール呼び出しを含む全トークンに影響し、低強度では呼び出しが減り短くなります。「振る舞いを誘導するシグナル」とは、低強度でも十分難しければ考えるものの、同じ問題について高強度設定時ほど多くの推論を行わないことを意味します。厳密な上限には強度でなくmax_tokensを使います。

長さを調整するつまみでもありません。Anthropicは一部モデルでは強度を変えても最終応答の長さを安定して制御できないため、長さは指示で決めるよう案内しています。

強度を費用・遅延に合わせる手順

強度は、勘ではなく測定によって選びます。Anthropicのドキュメントが示すベストプラクティスは、強度を明示的に設定すること、単純なタスクや速度が重要なタスクには低い強度を使うこと、自分のタスクで試験すること、そしてタスクの複雑さに応じて強度を変えることです。これを手順にすると、次のようになります。

1. タスクを種類に分ける。 同じ機能でも単純照会、定型抽出、多条件判断は別種とする。
2. 種類ごとに、許容できる遅延と品質の下限を決める。 「2秒以内、正答率95%以上」のように数値で定める。
3. 強度を変えて同じ評価セットを実行する（スイープ）。 正答率、平均・最大応答時間、出力トークンを記録する。
4. 品質の下限を超える中で、最も低い強度を選ぶ。 その強度で遅延の要件を満たせなければ、モデルやタスクの構造を見直す。
5. 低い強度で特定の種類だけ推論が浅くなるなら、対象を絞った指示を加える。 Anthropicのドキュメントは、遅延のために強度を低く保たなければならない場合、「このタスクは複数段階の推論を必要とするため、応答する前に慎重に考えよ」といった、対象を絞った指示を例に挙げている。
6. モデル変更時は再スイープする。 同名の強度でもモデルごと思考量は違う。

出力上限と推論トークン

上限には推論も含まれます。OpenAIのmax_output_tokensは、推論トークン、可視の出力テキスト、非表示のフォーマットトークンを含む全生成トークンの上限です。低すぎると推論中に切れ、incompleteとなり、回答テキストが一切出力されない場合もあります。OpenAIは初試験時に推論と出力を合わせて25,000トークン以上確保し、使用量を見て調整するよう勧めています。Anthropicもmax_tokensは思考と応答の合計の厳密な上限なので、高強度では余裕を持たせるよう案内しています。

例：上限を4,000トークンにしたが、モデルが思考に3,600を使った。
→ 最終回答に使える残りの枠は最大400トークン。途中で途切れるか、回答が全く出力されない。
→ 使用したトークン分は課金される。

答えの長さは上限ではなく指示文で調整します。上限は思考が際限なく長くなることを防ぐ安全策です。

推論モデル用のプロンプト

推論モデルには、手順よりも目標を与えます。OpenAIのドキュメントは、明確な目標、強い制約、明示的な出力形式を与える一方、すべての段階を細かく指示しないよう勧めています。また、推論のベストプラクティスは、推論が内部で行われるため、「段階ごとに考えよ」のような文言は不要であり、ときには性能を下げることもあると説明しています。Anthropicのドキュメントも、「十分に考えよ」のような一般的な指示が、人が手で書いた段階ごとの計画よりも、よい推論を生むことが多いとしています。

OpenAIのドキュメントは、エージェントや調査タスクでは、何をもって「完了」とするか、モデルが自分の結果をどう検証するかを定義するよう強調しています。Anthropicのドキュメントも、調査タスクには明確な成功基準を与え、複数の出典で情報を確認させるよう勧めています。範囲が開かれたタスクほど、終わる条件をプロンプトに入れる必要があります。

思考過程を出力に書かせない

思考機能がなかった時代は、「まず考えを書き、その後で答えよ」という指示が、よく使われる手法でした。Anthropicのドキュメントは、現在でも、思考が無効になっている状況では、この方法を代替手段として使えると説明していますが、思考が有効な最新モデルでは事情が異なります。モデルの内部推論を応答テキストに再現するよう求めると、stop_reasonがrefusalで、カテゴリがreasoning_extractionの応答が返る場合があります。公式ドキュメントが挙げる、よくある原因は次のとおりです。

• 回答前に埋める<thinking>、<reasoning>、メモ欄
• JSONやツール入力のreasoning、thinking、traceフィールド
• 私的なメモや推論記録を継続して書かせる指示
• 推論をそのまま、または全部書く要求

こうした文言は、システムプロンプトだけでなく、ツールの説明にも潜んでいる可能性があります。このカテゴリには推奨される代替モデルがないため、再試行するよりも、プロンプトを修正する必要があります。それでも、根拠は受け取れます。短い説明、結果を裏付ける証拠、実施した作業の要約を求めればよいのです。モデルがどのように推論したかを見たい場合は、displayをsummarizedに設定し、思考ブロックの要約を読みます。確認担当者が確かめるべきものは、思考の痕跡ではなく、結論を支える根拠、使われた仮定、そして確認可能な計算です。

タスク分解とワークフローパターン

長いタスクを一度に依頼する代わりに、複数の呼び出しに分けることを、プロンプトチェイニングといいます。Anthropicのエージェント設計の記事は、最も単純な解決策から始め、必要な場合だけ複雑さを増すよう勧め、よく使うパターンを次のように整理しています。

適応型思考とサブエージェントの調整によって、多段階の推論の大部分がモデル内部で処理されるようになったため、チェイニングが常に必要なわけではありません。Anthropicのドキュメントは、明示的なチェイニングが今でも有効な場合として、中間結果を検査しなければならないときと、特定のパイプライン構造を強制しなければならないときを挙げています。段階を別々の呼び出しに分ければ、段階ごとに記録、評価、分岐ができ、人による承認のようなゲートを間に入れられます。

段階ごとの入出力契約

段階を分けたら、段階の間で何をやり取りするかを、契約のように決めます。契約がなければ、前の段階が形式を少し変えただけで次の段階が崩れ、根拠が途中で失われます。

原則は3つです。第1に、次の段階で必要なものだけを渡しつつ、根拠の位置（文書番号、段落番号）は、最後まで引き継がれるようにします。第2に、ゲートは、できる限りコードで検査します。第3に、段階ごとに第1章のタスクの種類を明示し、抽出段階で文章の推敲が行われないようにします。契約が特に防ぐのは、誤りの伝播です。抽出段階で数値を1つ読み間違えると、その後の段階は、その数値の上に滑らかな論理を積み重ね、最終文書だけを見る確認担当者は、誤りに気付きにくくなります。段階ごとに中間成果物を原文の位置とともに残しておけば、結果が間違っていたときに、最初からやり直さず、誤りが始まった段階から再実行できます。

自己レビューを具体的検査にする

最もよく使われるチェイニングのパターンは、自己レビューです。Anthropicのドキュメントは、草案を作る、基準に照らして確認する、その確認に基づいて修正する、という3つの段階を、それぞれ別の呼び出しに分けるよう説明しています。

呼び出し1：チェックリストを含む指示で草案を生成
呼び出し2：同じリストで項目別に確認（合格／失敗と位置）
呼び出し3：失敗項目だけを直して修正版を生成

「もう一度確認して」という漠然とした依頼では、効果は弱くなります。要件の抜け、原文と数値の一致、例外条件と反例、そして「修正する必要がない条件」まで書く必要があります。最後の項目がなければ、確認段階で、問題のない部分まで変更してしまいます。1回の呼び出しで終えなければならない場合は、「終える前に、［試験基準］に照らして回答を確認せよ」と付け加えます。ただし、Anthropicのドキュメントは、一部のモデルは指示がなくても自分の作業をうまく検証するため、以前のモデル用の検証指示が、過剰な検証を招く場合があると警告しています。修正回数の上限を決め、上限に達したら、残る問題を明示して人に引き継ぎます。

並列と逐次、そしてサブエージェント

互いに依存しないタスクは同時に、前の結果が必要なタスクは順に処理します。Anthropicのドキュメントは、最新モデルが独立したツール呼び出しを並列に実行し、その行動を指示で調整できると説明しています。指示例では、依存関係のない呼び出しはすべて同時に行い、前の呼び出しの結果によってパラメータが決まる場合は順に実行し、不足したパラメータを推測したり、プレースホルダーで埋めたりしないよう求めています。並列は遅延を減らし、逐次は正確さを守ります。両者を分ける基準は、依存関係です。

サブエージェントは、さらに大きな単位の並列化です。まっさらなコンテキストで、対象を絞ったタスクを行い、要約だけを返すため、幅広い調査に強い一方、費用が大きくなります。Anthropicのマルチエージェント調査システムの記事は、エージェントがチャットの約4倍、マルチエージェントシステムは約15倍のトークンを使うと報告しています。また、単純な事実確認では、エージェント1体とツール呼び出し3〜10回で十分となるよう、ルールを設けたと説明しています。Anthropicのドキュメントも、一部のモデルがサブエージェントを過度に起動するとして、並列実行できるか、コンテキストを分離する必要のある独立したタスクにだけ使い、単純なタスクや逐次的なタスクは自分で行う、という指示例を示しています。

さらに深く

細分化しすぎたチェーンの費用

分割すればよくなるという思い込みは危険です。段階ごとに往復の遅延が生じ、段階間で文脈が途切れ、管理するプロンプトが増えます。OpenAIの遅延最適化ガイドは、逐次的な段階を1つのプロンプトと応答にまとめると、往復の遅延がなくなると説明しています。その一方で、小さいモデルが大部分の作業を担えるなら、分けるほうが有利な場合もあるため、実際の運用例で両方を試すよう勧めています。同じガイドは、生成トークンを減らすことが、入力トークンを減らすことよりも、遅延にはるかに大きな影響を及ぼすとも説明しています。

分割を判断する問いは次のとおりです。

複数ウィンドウにまたがる長い作業

数日にわたるタスクは、1つのコンテキストウィンドウには収まりません。Anthropicのドキュメントは、最初のウィンドウで枠組み（テスト、準備スクリプト）を作り、以後のウィンドウで、やることの一覧を繰り返し処理するよう勧めています。テストのような構造化された状態はJSONなどの定型ファイルに、進捗メモは自由なテキストに、作業履歴はgitに残し、新しいウィンドウでは、まずこれらの記録を読む手順から始めます。圧縮する代わりに、新しいウィンドウでファイルから状態を取り戻すほうがよい場合もあります。また、テストを削除したり変更したりして合格を作り出してはいけない、という原則を、最初から明記するよう勧めています。

実務の場面

かたやま金属：見積比較報告を段階に分ける

精密部品メーカー「かたやま金属」の購買チームは、原材料の供給業者の見積書を比較し、購入稟議書の下書きを作る機能を使っています。見積書の書式は業者ごとに異なり、1案件に見積書が4〜5件ずつ届きます。現在は、見積書をすべて入れ、高い強度で「比較して稟議書を書け」と一度に指示しています。稟議書の文章は滑らかですが、先月は2回、単位がkgの見積もりとトンの見積もりを、同じ単位として比較し、見当違いの業者を推薦しました。稟議書だけを見たチーム長は、気付きませんでした。

購買担当のチョンさんは3段階に分け、入出力契約を書きました。

1. 抽出（低い強度）。 見積書ごとに、供給業者、品目、単価、単位、納期、有効期間を、構造化出力で抽出する。各項目に、見積書のページ番号も残す。単位は原文の表記どおりにする。
2. ゲート（コード）。 コードで換算表に合わせて単位を統一し、必須項目が欠けた見積書は担当者に差し戻す。換算表にない単位が出たら、処理を止める。
3. 比較と作成（高い強度）。 統一した表と、社内の購買基準（価格、納期、取引履歴の重み）を入れ、供給業者ごとの判定と根拠のページ番号を受け取ってから、稟議書の下書きを作る。

最後に、同じチェックリストによる自己レビューの呼び出しを、もう1回設けます。チェックリストは、「推薦した供給業者の単価は表の最安値か、そうでなければ、その理由は基準表にあるか」「すべての数値にページ番号があるか」「有効期間が過ぎた見積もりを推薦していないか」です。修正する必要のない項目には手を加えないように書きました。

チョンさんが採用しなかった案は2つあります。1つは、一度に処理する方法を保ち、「単位に注意せよ」を太字で入れる方法です。抽出の誤りが最終的な文章に隠れる構造は変わらないため、採用しませんでした。もう1つは、5段階にさらに細かく分ける案でした。中間結果を誰も見ない段階が生まれ、遅延が増えるだけなので、3段階で止めました。強度も段階ごとに変えました。抽出は定型タスクのため、低い強度でも、評価セットの正答率は高い強度と同じでした。一方、比較は複数の基準が絡むため、高い強度でしか下限を超えませんでした。

過去3か月の見積書の組、40案件で比較すると、単位の混同はすべてゲートで検出され、1案件あたりの処理費用は、むしろ減りました。抽出段階の費用が下がったためです。稟議書にページ番号が付くようになり、チーム長の確認時間も短くなりました。

カラム市若者就労センター：質問ごとに違う思考量

「カラム市若者就労センター」は、若い求職者の質問に答える相談ボットを運用しています。質問は大きく3つです。営業時間や所在地のような簡単な案内、研修プログラムの日程照会、そして助成金の受給資格の判定です。資格の判定には、年齢、居住期間、所得、ほかの助成金との重複の有無などの条件が絡みます。最初はすべての質問を最も高い強度で処理していましたが、営業時間を尋ねる質問でも応答が遅く、利用者が画面を閉じることが多くありました。

担当職員のハさんは、質問をルーティングすることにしました。まず、軽い分類の呼び出しが質問の種類を決め、種類ごとの経路に送ります。簡単な案内は、あらかじめ書いた回答の一覧から選ばせ、モデルによる生成を最小限にしました。日程照会では、日程ツールを呼び出した結果を短く整理します。資格の判定では、資格基準表と利用者が入力した条件を入れ、判定、根拠条項、不足している情報の一覧を受け取ります。

強度は、スイープによって決めました。種類ごとに評価用の質問を60個ずつ作り、遅延の下限と品質の下限を、先に書き出しました。

資格の判定では、中程度の強度でも正答率の下限を超えましたが、4つ以上の条件が絡む質問だけに誤答が集中しました。ハさんは、強度を上げるほうを選びました。許容される遅延には余裕があり、誤った資格案内は、利用者が応募の機会を逃すことにつながるためです。また、以前のプロンプトに残っていた「思考過程を<생각>タグにすべて書け」という文を削除し、代わりに「判定の根拠となった基準表の条項番号と利用者の条件を短く書け」に変えました。相談員が確認すべきものは根拠であり、思考の痕跡ではありませんでした。

検討会議では、「質問の種類を間違って分類したらどうするのか」という質問が出ました。ハさんは、分類に自信がない場合は、資格判定の経路に送るという基本ルールを設けました。遅いほうへ間違えるほうが、誤った案内をするよりもよいためです。導入後、簡単な案内の応答は体感できるほど速くなり、資格判定の正確さは維持されました。モデルを入れ替えるたびに、同じ評価用の質問でスイープをやり直すことを、運用規則に記しました。

間違えやすいポイント

• 最高強度が常に最善。 単純・大量処理では費用と遅延だけ増えます。タスクごとに選び評価します。
• 「段階ごとに考えよ」の1行で十分だ。 推論モデルには不要だったり、有害だったりする可能性があり、タスクごとの遅延・正確さの要件を満たすこともできません。
• 思考過程を本文に書かせれば、検証できる。 見える思考は要約にすぎず、思考機能が有効な最新モデルでは、推論の再現を求めると拒否される場合があります。根拠、仮定、計算を求めます。
• 出力上限を下げれば、回答が短くなる。 推論モデルでは、推論の途中で途切れ、空の回答が返ることがあります。長さは指示で決めます。
• 分けるほど品質が上がる。 誰も見ない中間段階は、遅延と管理費用を増やすだけです。一度に処理した版と比較します。
• サブエージェントは常に速い。 トークンが大幅に増え、単純照会はむしろ遅くなります。
• 依存した呼び出しも並列が速い。 前の結果が必要な呼び出しを同時にすると、値を推測させます。

ひと目でわかるまとめ

公式ドキュメントで確認する

• OpenAI — Reasoning models：強度値、推論課金、max_output_tokens、25,000トークン確保の推奨を読む。
• OpenAI — Reasoning best practices：推論とGPTの役割分担、プロンプトの助言を読む。
• Anthropic — Effort：強度別の説明、ツールとの関係、ベストプラクティスを読む。
• Anthropic — Refusals and fallback：reasoning_extractionの原因と代案を読む。
• Anthropic — Prompting best practices：「Thinking and reasoning」「Chain complex prompts」「Subagent orchestration」「Optimize parallel tool calling」を読む。
• Anthropic — Building effective agents：各パターンと適用場面を読む。

セルフチェック

4-1. 推論トークンの費用とコンテキストへの影響を2つ書き、思考ブロックのテキストと元の思考過程の違いを説明してください。

4-2. Anthropicのeffortが「厳密な予算でなく行動の信号」である意味と、厳密な出力上限に使うものを答えてください。

4-3. 社内文書検索の質問を単純照会と比較分析に分けて強度を決めます。選択手順を順番に書いてください。

4-4. 小さい出力上限の推論リクエストで、見える答えが空でした。原因と対処2つを書いてください。

4-5. 通常モデル向けに書かれたプロンプトに、「第1段階：問題を読む……第7段階：答えを書く」という手順と、「段階ごとに考えよ」という指示が入っています。推論モデルに移す際、何を残し、何を変えるか書いてください。

4-6. 評価結果のJSONにthinkingフィールドを設け、判定理由を長く受け取ろうという設計案が出ました。思考機能が有効な最新モデルで生じうる問題を説明し、目的を保てる別のフィールド設計を提案してください。

4-7. 新商品の発売プレスリリースを、（ア）製品仕様書からの事実の抽出、（イ）競合製品との比較、（ウ）プレスリリースの作成、という3段階で作ります。段階ごとの入出力契約の表を書き、段階間に置くゲートを1つ提案してください。

実習課題