Chain of Thoughtとは？CoTプロンプトの書き方・推論モデルでの扱いと限界を実装目線で解説【2026年版】

指示文に一行だけ「Let’s think step by step」を足したところ、算数文章題データセットMultiArithの正答率が17.7%から78.7%へ、GSM8Kが10.4%から40.7%へ動いた、という報告があります（Kojima et al., arXiv:2205.11916・2022年5月）。使ったモデルも問題も同じで、変えたのは一行だけです。この記事では、Chain of Thought（CoT）をプロンプト技法として定義し直し、例示・指示文・出力形式をどう設計するか、思考機構を内蔵した推論モデルではその指示をどう扱うべきか、そして推論文を検証や証跡にどこまで使えるのかを、実装の解像度で整理します。

まとめ：CoTプロンプトを入れる条件と、書き足さずに済む境界

Chain of Thoughtとは、モデルに最終回答を出させる前に、そこへ至る中間ステップを言語として書かせるプロンプトの書き方を指します。入口は2つで、途中式を含む例示を数件見せるfew-shot型と、指示文を一行足すzero-shot型です。原典が示した伸びはどちらも大きいものの、実測されたのは2022年時点の非推論モデルであり、その数字をそのまま現在のモデルに当てはめる読み方は成立しません。

2026年8月時点では、主要ベンダの推論モデルが思考の深さをパラメータ側で受け取る形になりました。この世代では「段階的に考えて」という一文は既定動作の言い直しに近く、追加の伸びは乏しくなります。CoT指示に残る仕事は、考えさせること自体ではなく、業務固有の例外条件や社内規程の判定順序といった、モデルが推測できない確認項目を渡すことに移りました。深さは設定で、確認項目はプロンプトで、という分担が実務的な形です。

もう一点、運用側で先に決めておくべきことがあります。出力された推論文は、内部で行われた処理の忠実な記録ではありません。したがって監査証跡や説明責任の材料に推論文を据える設計は避け、途中で確定した数値や条件は構造化出力で別に出させて機械的に突き合わせる形へ寄せます。CoT指示を書き足さない判断が正しいのは、既定のまま業務要件の正答率を満たしている処理、一手で答えが決まる分類・抽出・整形、そして同じ入力に同じ出力を返すことが要件になっている処理の3つです。

Chain of Thoughtの定義と、CoTプロンプトが指す範囲の整理

CoTという語は、プロンプトの書き方を指す場面と、モデルが内部で行う推論そのものを指す場面の両方で使われています。実装の議論を始める前に、この混同を先に外しておきます。

思考連鎖・CoT・推論モデルの思考設定という3語の切り分け方

本記事で扱うChain of Thoughtは、入力側の技法です。プロンプトの書き方によって、モデルの出力を「結論だけ」から「中間ステップののち結論」へ変える手段を指します。思考連鎖という訳語も同じ対象です。

これに対して、推論モデルが備える思考の仕組みは、モデル側の機構であり、リクエストのパラメータで深さを指定します。プロンプトの文面ではなく設定で制御する点が決定的に違い、後述するとおり両者は競合することもあれば補い合うこともあります。

さらに広い言葉として、中間ステップを挟む推論のやり方全体を指す総称もあります。プロンプトで促す方式、モデル側の思考設定を使う方式、同じ問いを複数回解かせて答えを突き合わせる方式のどれを採るか、追加でどれだけトークンと待ち時間が積み上がるかという方式選定と費用の話は、マルチステップ推論とは？多段推論の仕組みと実装3方式・採用判断で扱う内容です。本記事はその中の「プロンプトで促す方式」に絞り、書き方の設計へ降ります。

few-shot型とzero-shot型の違いと、原典が示した実測値

CoTプロンプトの原典はWei et al.（arXiv:2201.11903・v1は2022年1月）で、途中の考え方を書いた例示を8件与えるだけで、540Bパラメータのモデルが算数文章題GSM8Kにおいて当時の最高精度に達したと報告されました。検証器つきで微調整したモデルを、例示8件のプロンプトが上回った点が当時の驚きどころです。

その4か月後、例示すら不要だという報告が続きます。Kojima et al.（arXiv:2205.11916・v1は2022年5月）は、答えの前に「Let’s think step by step」を挟むだけで、text-davinci-002においてMultiArithが17.7%から78.7%へ、GSM8Kが10.4%から40.7%へ動いたと報告しました。前者をfew-shot型、後者をzero-shot型と呼び分けます。

ここで押さえるべきは、両方とも「中間ステップを自分では書かないモデル」に対して、書くよう仕向けた結果だということです。同論文はモデル規模が小さい場合に効果が出にくいことも報告しており、条件を選ぶ技法である点は最初から示されていました。現在の推論モデルは中間ステップを既定で生成するため、この前提が崩れます。その扱いは後述の章で切り分けます。

CoTプロンプトの書き方：例示の作り方と指示文・出力形式の設計

ここからは書き方に入ります。few-shot型とzero-shot型は排他ではなく、導入の軽さと書式の固定しやすさを天秤にかけて選ぶ関係です。

few-shot例示の作り方：件数・粒度・書式を固定する手順

件数から決めます。原典は8件でしたが、実務では3件から5件で始めて、誤答の傾向を見ながら増やす進め方が扱いやすいでしょう。例示は入力トークンとして毎回課金されるため、件数の増加はそのまま単価に乗ります。

次に粒度です。例示の中の途中式は、実際に踏ませたい段の数と粒度をそのまま示す見本です。モデルは書式を真似るため、例示が3段なら出力も3段前後に寄ります。段が細かすぎる例示を置くと、単純な入力に対しても細かい段を並べる挙動が定着し、トークンだけが増えます。

最後に、選ぶ例示の中身です。最も避けたいのは、同じ解き筋の例示だけを並べることでしょう。金額の按分だけを3件見せると、期間の重なり判定が必要な入力にも按分の型を当てにいく挙動が出ます。踏ませたい判断が複数あるなら、その分だけ型の違う例示を混ぜてください。

zero-shot誘導文の設計と、出力形式で段を分ける実装手順

zero-shot型は指示文だけで完結する形式です。ただし「段階的に考えて」の一言では、書式も段の内容もモデル任せになります。実装として安定させるなら、次の3つを指示文に含めます。

• 結論の前に検討過程を書く欄を、出力形式として明示する（見出しや項目名で場所を作る）
• その課題で踏むべき段を、抽象語ではなく具体的な確認項目として並べる（単位をそろえる、例外条件に当たるか確かめる、など）
• 結論だけを機械が拾える位置に固定する（末尾の決まった項目名に置く、など）

3つめが実装で効く要素です。検討過程と結論が同じ文章の中で混ざると、後段のパースが推論文の言い回しに依存してしまい、モデルを差し替えた途端に壊れる原因です。項目名で分けたうえで、結論側だけを型で受け取る形にすると、この依存が切れます。型そのものをスキーマで保証する方法はLLM構造化出力とは？JSON Schemaで出力形式を保証する仕組みにまとめています。

段の粒度をどこで切るかを決めるための、業務側から見た判断基準

段をどこで切るかは、モデル側の都合ではなく、レビューする人の都合で決めると迷いません。基準は一つで、その段だけを取り出したときに、業務を知っている人が是非を判定できる単位かどうかです。

たとえば契約期間の按分なら、「重なり日数を出す」「日割り単価を出す」「按分額を出す」の3段は、それぞれ単独で正誤を判定できます。一方で「計算する」の一段にまとめると、誤りがどこで起きたか追えません。逆に日数を数える工程を開始日と終了日の特定まで割ると、判定単位が細かすぎて読む手間だけが増えていきます。

この粒度の決め方は、エージェントとして組む場合の手順分割とは別物です。1回の生成の内側で足場を作るのがCoTの段であり、外部の観測やツール実行を挟んで手順そのものを組み立てる話はタスク分解とは？AIエージェントの分解粒度・3手法・妥当性検証の領分になります。

推論モデルの時代にCoT指示をどう扱うかという判断の分かれ目

ここが、2022年の原典をそのまま読んだだけでは判断を誤りやすい部分です。手法の紹介記事では触れられることが少ない一方、実装では真っ先にぶつかります。

思考設定を備えたモデルでCoT指示が効きにくくなる条件の整理

2026年8月時点で、主要ベンダの推論モデルは思考の深さをリクエストのパラメータで受け取る形が主流になりました。Anthropic Claudeでは思考をadaptiveに指定したうえで深さをeffort（lowからmax）で調整する形が採られ、旧世代で使われていた固定トークン数の指定（budget_tokens）は新しい世代のモデルでは受け付けられません。OpenAIの推論モデル系でも、思考の深さを段階値で渡す設計です。仕様の更新は速いため、実装前に一次情報で当たってください。

こうしたモデルは、指示がなくても中間ステップを生成する設計です。そこへ「段階的に考えて」を足すことは、既定動作の言い直しになります。追加の伸びが乏しいだけなら害はありませんが、実務では2つの副作用が出ます。ひとつは、思考を促す指示が深さの設定と競合し、簡単な入力にも長く考える方向へ振れることです。もうひとつは、思考の書式を細かく指定した結果、モデル側の思考と出力側の説明が二重になり、出力トークンだけが積み上がる状態でしょう。

もう1点、思考文の見え方も変わりました。生の思考文はそのまま返らない設計が広がっており、要約された形で返るか、空の状態で返るかは設定と世代によって変わります。「思考過程をそのまま出力して」と書いても、返ってくるのは内部の思考の再現ではなく、本文側に書かれた説明にすぎません。モデルによっては、内部の推論を取り出そうとする指示自体が断られる場合もあります。

深さはパラメータ、確認項目はプロンプトという役割分担の作り方

では推論モデルでCoTプロンプトは全部不要かというと、そうではありません。設定が制御するのは「どれだけ考えるか」であって、「何を確認しながら考えるか」は依然として指示側の担当です。業務固有の例外条件、社内規程で定めた判定順序、過去の誤答から拾った落とし穴は、モデルが自力で推測できるものではありません。

実装としては、CoT指示を「考えろ」から「この順に確認しろ」へ書き換えます。段階的に考えるよう促す一文は削り、代わりに確認項目を箇条で渡す。これだけで、既存のCoTプロンプトは推論モデルでもそのまま働く形になります。深さが足りないと感じたときはプロンプトに文を足すのではなく、深さの段階値を上げてから測り直すほうが、原因の切り分けが効きます。

なお、思考の深さと並んで扱われがちなtemperatureやtop_pは、推論モデル系では受け付けられない場合があります。この差はモデル世代ごとに動くため、推論パラメータとは？temperatureとtop_pの決め方・推論モデルでの非対応で現状を確認したうえで、リクエストの構築コードを見直してください。

思考トークンの課金と、応答上限まわりで実装が詰まりやすい箇所

費用と上限の扱いは、移行時に最も事故が起きる場所です。思考トークンは出力トークンとして課金対象になり、応答の上限値は思考と本文の合計に対して適用されます。

ここから何が起きるか。単発回答を前提に上限を切り詰めていた処理を、思考ありのモデルへそのまま載せ替えると、思考で枠を使い切り、本文が途中で切れて返ります。エラーにはならず短い応答が返るだけなので、監視していないと気づきません。移行時は上限を先に広げ、実測の出力トークン数を見てから絞り込む順番にしてください。

加えて、few-shot型の例示は入力トークン、思考と本文は出力トークンという分かれ方も押さえておきます。例示を厚くする改善と思考を深くする改善では、効いてくる単価の側が違うためです。1件あたりの追加トークンから月次費用を出す実測手順はマルチステップ推論の採用判断にまとめてあるため、そちらの4手を流用してください。

CoT特有の3つの失敗と、出力を検証可能にする書式設計の要点

CoTを入れると誤りの総量は減る一方、誤りの現れ方が変わります。運用に載せる前に、変わり方を知っておく必要があります。

例示への過適合・段の水増し・自己整合的な誤答という3つの失敗

1つめは例示への過適合です。few-shot型で見せた解き筋を、当てはまらない入力にも当てにいきます。例示の型が偏っているほど強く出て、しかも出力の見た目は例示どおりに整っているため、目視では通ってしまいます。

2つめは段の水増しです。求めた粒度より細かい段を並べ、正答率は動かないままトークンと待ち時間だけが増える現象です。指示文で段を促しすぎたときと、推論モデルにCoT指示を重ねたときの両方で出ます。出力トークン中央値を継続して見ていれば検知できるため、監視項目に入れておきます。

3つめが最も厄介で、自己整合的な誤答です。第2段で単位を取り違えると、第3段以降はその誤った値を正しい前提として扱い、結論まで一貫した誤答が出てきます。文章としては筋が通っているため、レビューをすり抜けやすい性質があるでしょう。誤りが増えるのではなく、見つけにくい誤りに変わる、という理解が正確です。

推論文を証跡にしない前提で、構造化出力と突き合わせる検証設計

3つめへの対処が、そのまま検証設計になります。出発点は、モデルが出力する中間ステップが内部処理の忠実な記録ではないという事実です。生成された文章である以上、結論に至った実際の経路と食い違うことがあり、結論が正しくても説明が後付けの場合、その逆で説明が妥当でも結論が誤っている場合の両方が起こります。

したがって、規程上の説明責任や監査証跡として推論文をそのまま採用する設計は避けます。求められるのが「なぜその結論になったか」の説明責任であれば、モデルの推論文ではなく、判断に使った入力データ・適用した規則・照合結果を構造化して残す形へ切り替えます。

実装の置き方は3つです。第1に、途中で確定した数値や条件を、文章とは別に型のある形でも出させ、結論と機械的に突き合わせること。第2に、検算できる部分をコード側へ移すこと。第3に、突き合わせが合わなかった入力だけを人のレビューへ回すこと。推論文は開発時に当たりを付ける材料、構造化した記録は運用の証跡、と用途を分けておけば、後から監査要件が付いても作り直しになりません。

CoTプロンプトを採用する条件と、あえて書き足さない場面の判断

ここまでを踏まえて、条件を付けて言い切ります。

CoTプロンプトを採用してよい課題の見分け方と実測手順の要点

次の3点のうち2つ以上に当てはまるなら、CoT指示を試す価値があります。

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

当てはまったら、感覚ではなく実測が判断材料です。代表30件から50件を用意し、CoT指示なしとありの両方を流して、正答率と出力トークン中央値を記録対象にします。差分のトークン数に単価と月間件数を掛ければ追加費用が出るので、正答率の差分を誤答1件あたりの手戻り工数に換算し、同じ表に並べる比較です。この4手の詳細と、レイテンシ側の測り方は前掲の記事に譲ります。判断の分かれ目は同じで、費用増より損失減が小さければ入れません。

CoT指示を書き足さないと決めるべき3つの処理と、その判断理由

逆に、次のいずれかに当てはまる処理には書き足しません。

第1に、思考機構を備えた推論モデルで、既定のまま業務要件の正答率を満たしている処理です。ここへCoT指示を重ねても、増えるのは待ち時間と費用だけになります。まず既定のまま測り、足りなければ深さの段階値を上げる。プロンプトに文を足すのはその後です。

第2に、一手で答えが決まる処理です。感情の分類、固有名詞の抽出、決まった形式への変換が該当します。この型で正答率が足りないときは、段数ではなく指示の曖昧さか参照情報の欠落を疑うほうが、はるかに早く解決します。

第3に、同じ入力に対して同じ出力を返すことが要件になっている処理です。中間ステップは経路の揺れがそのまま出力の揺れになるため、再現性を求める処理はルールベースか、判断そのものを人の側に残す形で設計してください。

この3条件に当たらず、前節の基準に2つ以上該当するなら、進め方は明快です。zero-shot型で当たりを取り、書式が揺れるならfew-shot型の例示を足し、それでも足りなければ方式そのものを上げる。方式を上げる段の選び方は前掲の総称記事の担当範囲です。判断の前提となる指示文の基礎から押さえたい場合は、プロンプトとは？生成AIへの指示文の意味と書き方もあわせて参照してください。なお、どの段で外れたかを測るデータセットづくりや、業務側の損失を金額に置く作業は、社内に担当を立てにくい部分でもあります。生成AI開発・AI受託開発では、プロンプト方式の切り分けから評価データの整備までを実装と一体で扱っており、既存業務のどこにCoTを載せるかという段階からの相談にも対応しています。

よくある質問

CoTプロンプトの導入検討で挙がりやすい論点を、実装判断に直結する5つに絞って回答します。

Chain of Thoughtとマルチステップ推論は同じものですか？

両者は包含関係です。マルチステップ推論は中間ステップを挟む推論のやり方の総称で、Chain of Thoughtはその中で、プロンプトによって中間ステップを促す技法です。総称にはモデル側の思考設定を使う方式や、複数経路を突き合わせる方式も含まれます。会話の中では両者がほぼ同義で使われる場面も多いため、プロンプトの話をしているのか方式選定の話をしているのかを確認すると、認識のずれを防げます。

推論モデルを使うならCoTプロンプトは不要になりますか？

「段階的に考えて」という促しは、ほぼ不要になります。中間ステップの生成は既定動作であり、指示は言い直しにしかなりません。一方で、業務固有の例外条件や社内規程の判定順序といった確認項目を渡す用途は残ります。深さは設定で、確認項目はプロンプトで、と分けて考えてください。

「Let’s think step by step」は今も効きますか？

思考機構を持たないモデルには、まだ効く余地があります。ただし原典の数字は2022年のモデルでの実測であり、その伸び幅を現在の推論モデルで再現できるという意味ではありません。推論モデルでは既定動作と重複するため、入れる前に、入れない状態での正答率を必ず測ってください。

CoTの出力をそのままユーザーに見せてよいですか？

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

小さいモデルでもCoTプロンプトは効きますか？

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

関連記事

• マルチステップ推論とは？多段推論の仕組みと実装3方式・採用判断を実装目線で解説【2026年版】：プロンプト誘導・思考設定・複数経路という方式選定と、費用の実測手順
• 推論パラメータとは？temperatureとtop_pの決め方・推論モデルでの非対応を実装目線で解説【2026年版】：思考の深さと並ぶ設定側の扱い
• LLM構造化出力とは？JSON Schemaで出力形式を保証する仕組みと実装・見送り条件を解説【2026年版】：検討過程と結論を分けて機械的に受け取る方法
• ReActパターンとは？思考と行動を交互に回す仕組みと採用判断を実装目線で解説：外部の観測を挟んで推論を回す形の設計
• タスク分解とは？AIエージェントの分解粒度・3手法・妥当性検証を実装目線で解説：1回の生成の外側で手順を組み立てる層の担当範囲
• セルフコンシステンシーとは？複数サンプリングと多数決の実装・費用設計を実装目線で解説【2026年版】：CoT出力を複数本作って答えを突き合わせる呼び出し方の設計