マルチステップ推論とは？多段推論の仕組みと実装3方式・採用判断を実装目線で解説【2026年版】

小学校レベルの文章題データセットGSM8Kで、PaLM 540Bの正答率は標準的なプロンプトでは17.9%、答えの前に途中の考えを書かせると56.9%になりました（Wei et al., arXiv:2201.11903・2022年1月）。同じモデル、同じ問題で、変えたのは中間ステップを出させるかどうかだけです。この記事では、マルチステップ推論（多段推論）を単発回答型との処理の違いから定義し、プロンプト誘導・モデル側の思考設定・複数経路の突き合わせという実装3方式、追加で載るトークンとレイテンシの見積もり手順、そして採用を見送る条件までを実装目線で整理します。

まとめ：多段推論を入れる条件と、単発回答のままでよい境界

マルチステップ推論とは、モデルが最終回答を出す前に中間ステップを生成し、それを手がかりに結論へ進む推論のやり方を指します。実装の入口は3つあります。プロンプトで中間ステップを促す方式、モデル側の思考設定を使う方式、同じ問いを複数回解かせて答えを突き合わせる方式です。この3つは排他ではなく、後ろへ行くほど精度が上がり、そのぶん出力トークンと待ち時間が積み上がります。

効果が出るのは、途中に計算・場合分け・制約の確認が挟まる課題です。逆に、感情の分類、固有名詞の抽出、決まった形式への変換のように一手で答えが決まる課題では、中間ステップは待ち時間と費用を増やすだけで終わります。判断の順序としては、まず単発で解かせて誤答の中身を見て、誤りが「知識の欠落」ではなく「途中で手順を飛ばしたこと」に由来するときだけ多段化する、が現実的です。

費用の効き方も確認が必要です。思考トークンは出力トークンとして課金され、応答の上限値は思考と本文の合計に対してかかります。上限を据え置いたまま多段化すると、思考で枠を使い切って本文が途中で切れます。レイテンシ予算が1秒を切る画面、監査で推論過程の再現性を求められる処理、単段で正答率が足りている処理には入れません。

マルチステップ推論の定義と、単発回答型との生成処理・費用の違い

まず用語を固定します。多段推論、多段階推論、multi-step reasoning はいずれも同じ対象を指し、実務では「思考させてから答えさせる」という表現で通っています。ここで扱うのは、外部ツールを呼ばずにモデルの生成だけで完結する範囲です。検索やAPI実行を挟む形は別の設計で、後半の責務分担の節で切り分けます。

中間ステップを挟む生成処理の仕組みと、正答率が動く理由の言語化

言語モデルは、直前までのトークン列から次のトークンを選ぶ処理を繰り返しているだけです。結論をいきなり書かせると、問題文から答えのトークンまでを一足飛びに埋める形です。中間ステップを先に書かせると、問題文と結論の間に自分が生成した足場が入り、次のトークンを選ぶ条件が具体的になります。1回の生成で決める距離が短くなる、と言い換えられます。

この効果は数値で確認されています。前掲のWei et al.（arXiv:2201.11903・2022年1月）では、PaLM 540BのGSM8K正答率が標準プロンプトの17.9%から、8件の例示に途中式を含めた思考連鎖プロンプトで56.9%へ動きました。同論文はモデル規模が小さい場合には効果が出にくいことも報告しており、「指示を足せば常に上がる」という性質ではない点は最初に押さえるべきところです。

単発回答型との比較：出力量・待ち時間・誤りの現れ方の3観点で判断

設計判断に効くのは、精度そのものより「何が増えて何が変わるか」です。同じ課題を単発で解かせる場合と多段で解かせる場合を、実装側から見える形で並べます。

右の列で見落とされやすいのが最終行です。中間ステップが残ると、誤答を「どの段で外れたか」まで切り分けられます。プロンプトを直すのか、参照情報の与え方を直すのか、そもそも課題設定が悪いのかを分けて考えられるようになるため、精度が同じでも改修の速度は変わります。

手法の系譜：zero-shotからTree of Thoughtsまでの位置関係

論文名で語られる手法は多いものの、実務で押さえるべき軸は「誰が中間ステップを作るか」と「経路を1本にするか複数にするか」の2つです。この2軸で主要な手法を並べると、選択肢の重なりが見えます。

• few-shot型（arXiv:2201.11903・2022年1月）：例示の中に途中式を入れ、同じ書式を真似させる。書式を固定したいときに強い
• zero-shot型（arXiv:2205.11916・2022年5月）：例示なしで、指示文1行だけで段階的に書かせる。導入が最も軽い
• 自己整合性（arXiv:2203.11171・2022年3月）：同じ問いを複数回解かせ、多数決で答えを決める。経路を複数にする最初の一歩
• 木探索型（arXiv:2305.10601・2023年5月）：途中の候補を枝分かれさせ、評価しながら探索する。Game of 24でGPT-4が4%から74%へ動いた実測がある
• 過程への報酬（arXiv:2305.20050・2023年5月）：結論ではなく途中の各段の妥当性を検証器に採点させる。学習側と推論側の両方に効く系譜

実装の順序としては、zero-shot型で当たりを取り、書式が揺れるならfew-shot型へ、正答率が足りないなら自己整合性へ、という段取りが素直です。木探索型は探索の実装と評価関数を自前で持つ必要があるため、パズル的な課題や候補生成が主目的の課題に絞ります。

実装3方式の使い分けと、思考トークンが課金と上限に効く仕組み

中間ステップを出させる手段は、書く場所によって3層に分かれます。プロンプト、モデルのパラメータ、呼び出し回数です。層が違えば、効く範囲も、費用の乗り方も、制御できる度合いも変わります。

プロンプト誘導方式の実装手順と、指示だけで多段化する限界が生じる条件

最も軽いのはプロンプト側で促す形です。手順は3段階に収まります。

1. 結論の前に検討過程を書く欄を、出力形式として明示する（見出しや項目名で場所を作る）
2. その課題で踏むべき段を、抽象語ではなく具体的な確認項目として並べる（「単位をそろえる」「例外条件に当たるか確かめる」など）
3. 誤答例を集め、飛ばされていた段を確認項目に追加する

限界もはっきりしています。指示で得られるのは「途中式らしい文章の書式」であって、計算そのものの正しさではありません。桁の大きい四則演算や厳密な日付計算では、もっともらしい途中式のまま数値だけ誤る挙動が残ります。数値の確度が要る処理では、計算部分をコード実行や自前の関数に逃がし、モデルには段取りだけを担当させる分担が現実的です。

推論モデルの思考設定と、出力課金・上限値の扱いで詰まる実装箇所

2つめは、モデル側が持つ思考の仕組みを呼び出す形です。ここは各社とも仕様の更新が速いため、実装前に一次情報を確認します。2026年8月時点のAnthropic Claudeでは、思考量を固定トークン数で渡す budget_tokens は新しい世代のモデルでは受け付けられず、思考を adaptive に指定したうえで深さを effort（low から max）で調整する形です。旧世代のモデルでは budget_tokens が残り、最小1024トークンかつ応答上限より小さいという制約が付きます。OpenAIの推論モデル系でも、思考の深さを段階値で渡す設計が採られています。

実装で詰まりやすいのは課金と上限の扱いです。思考トークンは出力トークンとして課金対象となります。そして応答の上限値は、思考と本文の合計に対して適用される仕組みです。単発前提で上限を切り詰めていた処理をそのまま多段化すると、思考で枠を使い切り、本文が途中で切れて返ります。多段化のときは上限を先に広げ、そのうえで実測の出力トークン数を見て絞り込む順番にします。

もう一点、生の思考文はそのまま返らない設計が広がっています。要約された形で返るか、空の状態で返るかは設定と世代によって変わるため、思考文を画面表示や保存の前提に置いた実装は壊れやすくなります。表示するなら要約を、記録するなら自前で書かせた検討結果を使う、と分けておくと版が上がっても崩れません。

複数経路の突き合わせで底上げする方式と、費用が比例で増える構造

3つめは、同じ問いを複数回解かせて答えを突き合わせる形です。自己整合性（arXiv:2203.11171・2022年3月）では、GSM8Kで+17.9%、SVAMPで+11.0%、AQuAで+12.2%、StrategyQAで+6.4%、ARC-challengeで+3.9%の改善が報告されています。改善幅が課題によって4倍以上開く点は、導入前に自分のデータで測る理由になります。

この方式の費用はサンプル数にほぼ比例します。5経路なら推論費用も5倍です。並列で投げれば待ち時間の増加は抑えられますが、レート制限には正面からぶつかります。実務では、全件に掛けるのではなく、1本目の答えの確信度が低い場合や、金額・日付など誤りの損失が大きい項目に限って追加サンプルを回す形に絞ると、費用対効果が合いやすくなります。多数決の代わりに検証器で各段を採点させる方向もあり、過程への報酬付与の系譜（arXiv:2305.20050・2023年5月）がその出発点です。

追加トークンとレイテンシの見積もり手順と、効く課題の切り分け

多段化の可否は、精度の伸びと費用の伸びを同じ土俵に載せて初めて判断できます。ここは感覚で決めず、実測の手順を固定します。

1件あたりの出力トークンから月次費用を出すまでの実測手順と判断方法

見積もりは4手で済みます。

1. 代表30件から50件を単発で流し、1件あたりの出力トークン中央値と正答率を記録する
2. 同じ入力を多段設定で流し、思考分を含む出力トークン中央値と正答率を記録する
3. 差分のトークン数に単価を掛け、月間件数を乗じて追加費用を出す
4. 正答率の差分を、誤答1件あたりの手戻り工数や損失額に換算して並べる

この4手を踏むと、議論が「賢くなった気がする」から「1件あたり0.8円増やして誤答率が11ポイント下がる」に変わります。判断の分かれ目は3手目と4手目の突き合わせで、費用増より損失減が小さければ入れません。レイテンシも同じ手順で測り、初回トークンまでの時間ではなく完了までの時間で比べます。中間ステップは応答の前半を占めるため、逐次表示の画面でも体感待ち時間は伸びます。

多段化が効く課題と効かない課題を分ける、導入前の3つの判定基準

実測の前に候補を絞る基準も置けます。次の3点のうち2つ以上に当てはまるなら、多段化を試す価値があります。

• 正解に至るまでに2手以上の変換や場合分けが挟まる（金額の按分、期間の重なり判定、条件付きの適用可否など）
• 誤答の内容が、知識の欠落ではなく手順の飛ばしに見える（前提の確認を省いた、単位をそろえずに比べた）
• 入力ごとに踏むべき手順が変わり、固定のルールでは書き切れない

逆に、正解が入力の一部をそのまま写す型（抽出）、選択肢が数個に閉じている型（分類）、変換規則が完全に決まっている型（整形）では、多段化しても伸びしろがほとんどありません。この3型で正答率が足りないときは、推論の段数ではなく、指示の曖昧さか参照情報の欠落を疑う方が早く解決します。

多段推論の失敗モードと、推論文を運用監査の証跡として扱えない理由

ここからは、手法の紹介記事ではほとんど触れられない側面を扱う章です。多段化は誤りの総量を減らす一方で、誤りの現れ方を変えます。運用に載せる前に、変わり方を知っておく必要があります。

途中の一手が結論まで波及する失敗と、誤りの検出を置くべき実装位置

単発回答の誤りは結論だけで完結する型です。多段推論では、第2段で単位を取り違えると、第3段以降はその誤った値を正しい前提として扱い、結論まで一貫した誤答が出てきます。文章としては筋が通っているため、読み手のレビューをすり抜けやすい性質です。誤りが増えるのではなく、見つけにくい誤りに変わる、という理解が正確です。

対策の置き場所は3つあります。第1に、途中で確定した数値や条件を構造化した形でも出させ、結論と機械的に突き合わせること。第2に、検算できる部分をコード側へ移し、モデルの計算結果を採用しないこと。第3に、複数経路を回して答えが割れた入力を人のレビューへ回すこと。いずれも「推論文を読んで判断する」という運用から離れる方向で、そこが要点になります。

出力された推論文と内部処理のずれ、監査用途で必要になる線引き

もう一つの落とし穴が、推論文の位置づけです。モデルが出力する中間ステップは、内部で行われた計算の忠実な記録ではありません。生成された文章であり、結論に至った実際の経路と食い違うことがあります。結論が正しくても説明が後付けである場合、その逆で説明が妥当でも結論が誤っている場合の両方が起こります。

したがって、規程上の説明責任や監査証跡として推論文をそのまま採用するのは避けます。求められるのが「なぜその結論になったか」の説明責任であれば、モデルの推論文ではなく、判断に使った入力データ・適用した規則・照合結果を構造化して残す設計に切り替えます。推論文は開発時の当たりを付ける材料、構造化した記録は運用の証跡、と用途を分けておくと、後から監査要件が付いても作り直しになりません。

多段推論の採用を見送る3条件：レイテンシ予算・単段充足・再現性要件

ここは条件を付けて言い切ります。次のいずれかに当てはまる処理には、多段推論を入れません。

第1に、応答が1秒を切る前提の画面内処理です。入力補完、逐次バリデーション、検索候補の提示などが該当します。中間ステップの生成時間は削れないため、体感を守るなら単段で回し、重い判断は非同期の別処理へ寄せます。第2に、単段で正答率が業務要件を満たしている処理です。ここで多段化しても、増えるのは費用と待ち時間だけになります。第3に、同じ入力に対して同じ出力を返すことが要件になっている処理です。多段推論は経路の揺れがそのまま出力の揺れになるため、再現性を求める処理はルールベースか、判断そのものを人の側に残す形で設計します。

逆に、これら3条件に当たらず、かつ前節の判定基準に2つ以上該当するなら、まずzero-shot型で試し、実測の4手で費用対効果を確認したうえで段階的に方式を上げていく、が推奨の進め方です。

エージェント実装における位置づけと、周辺コンポーネントの責務分担

ここまでは、外部ツールを呼ばずモデルの生成だけで閉じる範囲を扱ってきました。エージェントとして組む段階では、推論の周りに行動・計画・制御の層が乗ります。どこまでを推論の話として扱うかを決めておくと、設計の議論が短くなります。

推論・行動・計画・制御を分ける、4層の責務と処理の送り先の判断基準

マルチステップ推論が担うのは、1回の生成の内側で結論までの足場を作る部分です。ここに外部の観測を挟み、思考と行動を交互に回す形になるとReActパターンの領域に入ります。タスクを分解して手順の並びを先に決め、失敗時に立て直す部分はAIエージェントのプランニングの担当です。そして、何回まで回すか・どの状態で止めるかという制御はエージェントループの設計に属します。

この分け方が効くのは、不具合の切り分けです。答えが的外れなら推論側、必要な情報を取りに行けていないなら行動側、手順が行き当たりばったりなら計画側、止まらない・早く止まりすぎるなら制御側と、直す場所が一意に決まります。4層を混ぜたまま「エージェントの精度が出ない」と扱うと、プロンプトの書き換えだけで何日も溶かすことになります。

多段推論の効果測定の入口と、受託開発で持ち込むときの体制の作り方

多段化の効果は、最終回答の正誤だけでは測り切れません。どの段で外れたか、余計な段を踏んでいないか、同じ入力で経路がどれだけ揺れるかまで見て初めて、方式を上げるか下げるかを判断できます。エージェントとして組んだ後の測り方はAIエージェント評価の指標設計に譲りますが、少なくとも代表入力のデータセットと、段ごとの正誤ラベルは推論方式を決める段階から作り始めます。

体制面では、実測の4手を回せる人と、業務要件の側で誤答1件の損失を金額に置ける人の両方が必要です。この2つがそろわないと、方式の議論が技術的な好みの話に流れがちです。社内に測る役割を置きづらい場合は、方式選定と評価データの整備までを外部と組んで進める選択肢もあります。AIエージェント開発では、推論方式の切り分けから評価の仕組みづくりまでを実装と一体で扱っており、既存業務のどこに多段推論を載せるかという段階からの相談にも対応しています。

よくある質問

マルチステップ推論の導入検討でよく挙がる論点を、実装判断に直結する5つに絞って回答します。

マルチステップ推論と思考連鎖（CoT）は同じものですか？

包含関係にあります。マルチステップ推論は「最終回答の前に中間ステップを生成する」やり方の総称で、思考連鎖はその中で最も広く使われる代表的な手法です。自己整合性や木探索型のように、中間ステップを複数経路で生成する手法も多段推論に含まれます。会話の中では両者がほぼ同義で使われる場面も多く、経路が1本か複数かを確認すると認識のずれを防げます。

推論モデルを使えば、プロンプトでの誘導は不要になりますか？

不要にはなりません。モデル側の思考設定は「どれだけ考えるか」を制御しますが、「何を確認しながら考えるか」は指示側の担当です。業務固有の例外条件や、社内規程で定めた判定順序は、モデルが自力で推測できるものではありません。思考設定で深さを与え、プロンプトで確認項目を渡す、という併用が現実的な形になります。

中間ステップの出力をユーザーに見せてもよいですか？

見せる目的によります。処理が進んでいることを示す進捗表示としては有効です。一方で、内容の正しさを示す根拠として提示するのは避けます。推論文は内部処理の忠実な記録ではなく、結論が正しくても説明が後付けになる場合があるためです。根拠を示す必要があるなら、参照した文書や適用した規則を構造化して別に出す設計にします。

多段推論を入れると回答は必ず良くなりますか？

なりません。分類・抽出・整形のように一手で答えが決まる課題では、正答率がほぼ動かないまま費用と待ち時間だけが増えます。モデル規模が小さい場合に効果が出にくいことも初期の研究で報告されています。導入前に代表30件から50件で単発と多段を測り、正答率の差分と出力トークンの差分を並べて判断してください。

小さいモデルでも多段推論は効きますか？

大きいモデルほどの伸びは期待しにくい、というのが実測ベースの見方です。中間ステップの書式は真似できても、各段の判断そのものが崩れると、誤った前提のまま結論まで進みます。小さいモデルで多段化する場合は、確認項目を細かく指定し、計算や検索を外部の処理へ逃がして、モデルには段取りの管理だけを任せる分担にすると成立しやすくなります。

関連記事

• ReActパターンとは？思考と行動を交互に回す仕組みと採用判断を実装目線で解説：外部ツールの観測を挟んで推論を回す形の設計
• AIエージェントのプランニングとは？計画を立てる仕組みと再計画の設計を実装目線で解説：手順の並びを先に決める層の担当範囲
• エージェントループとは？AIエージェントが自律的に動く仕組み・ReActと終了条件の設計を実装者視点で解説【2026年版】：何回まで回すかという制御側の設計
• AIエージェント評価とは？軌跡・ツール呼び出し・タスク達成を測る指標と実装の進め方【2026年版】：多段化の効果を測る指標の作り方