Chain-of-Thought(思考の連鎖)とは｜CoTプロンプトの基本と推論モデル時代の使いどころ

「答えだけ出して」と頼むと間違えるのに、「順を追って考えてから答えて」と一言添えると正解率が上がる。この現象を体系立てて示したのがChain-of-Thought(思考の連鎖、CoT)プロンプトです。最終回答だけでなく、そこに至る途中の推論ステップをモデルに言語化させる、というシンプルな手法ですが、多段の計算や論理を要するタスクで効果が確認され、プロンプト設計の基礎知識として定着しました。一方で、内部で長く思考する推論(reasoning)モデルが広まった今、「そもそもCoTを明示する必要はあるのか」という新しい論点も生まれています。この記事では、CoTの原典が主張したこと、few-shotとzero-shotの違い、self-consistencyなどの発展、実務での効果と限界、そして推論モデル時代の使い分けまでを、冷静に整理します。

Chain-of-Thought(CoT)とは何か#

CoTは、モデルに最終回答だけを出させるのではなく、そこに至る中間的な推論のステップを順に書き出させてから答えを述べさせる、というプロンプトの与え方です。日本語では「思考の連鎖」と訳されます。人間が難しい計算問題を暗算で一気に答えず、途中式を書きながら解くのに近い発想です。

この手法を体系的に示したのが、Wei et al.による2022年の論文「Chain-of-Thought Prompting Elicits Reasoning in Large Language Models」(arXiv 2201.11903)です。同論文は、いくつかの例題に対して答えだけでなく推論の道筋(chain of thought)を添えて提示すると、算術・常識・記号推論といった多段の推論を要するタスクで、大規模言語モデルの性能が向上することを報告しました。加えて、こうした効果は十分に大きなモデルで顕在化しやすく、小さいモデルでは必ずしも現れない、という趣旨の観察も示しています。

なぜ途中を書かせると精度が上がるのか、厳密な機序はまだ研究の対象ですが、直感的には、答えを一気に確定させる前に問題を小さなステップへ分解させることで、各ステップの負荷が下がり、後段の判断が前段の中間結果を参照できるようになる、と説明されることが多いです。重要なのは、CoTが「モデルに考える余地(中間トークンを生成する場)を与える」手法だという点です。

few-shot CoTとzero-shot CoTの違い#

CoTには、代表的な引き出し方が2つあります。

few-shot CoT(例示に推論過程を含める)#

原典が用いたのがこの形です。プロンプトの中に解答例をいくつか置き、その各例で「問題->途中の推論->答え」という並びを見せます。モデルは提示された例の書きぶりに倣い、本番の問題でも推論ステップを書いてから答えるようになります。推論の粒度や書式を例で誘導できるため、出力を型にはめやすいのが利点ですが、質の高い例を用意する手間と、例のぶんだけプロンプトが長くなるコストがかかります。

zero-shot CoT(指示だけで引き出す)#

例を用意せず、指示の一文だけで推論を引き出す方法です。Kojima et al.による2022年の論文「Large Language Models are Zero-Shot Reasoners」(arXiv 2205.11916)は、質問のあとに「Let's think step by step(順を追って考えましょう)」という汎用的な一文を加えるだけで、例示なしでも複数の推論ベンチマークで性能が向上することを示しました。例を作らなくてよい手軽さが魅力で、日本語なら「順番に考えてから答えてください」のような一文が同じ役割を果たします。

self-consistencyなどの発展#

CoTを土台にした改良もいくつか提案されています。実務で名前を聞く機会が多いのがself-consistency(自己整合性)です。

Wang et al.による2022年の論文「Self-Consistency Improves Chain of Thought Reasoning in Language Models」(arXiv 2203.11171)は、CoTで一本の推論だけを取るのではなく、温度を上げて複数の異なる推論経路をサンプリングし、最も多く一致した最終回答を選ぶ(多数決に近い)という復号戦略を示しました。同じ問題でも正しい答えへ至る道筋は複数あり得る、という直感を利用したもので、算術・常識推論のベンチマークでCoT単独より精度が上がることが報告されています。ただし複数回サンプリングするぶん、推論回数とコストは増えます。

このほか、複数の思考経路を木構造で探索する手法など、CoTを起点とした発展はいくつもありますが、共通するのは「中間推論を明示的に扱う」という発想です。実務でまず押さえるべきは、基本のCoTと、精度を底上げしたいときの選択肢としてのself-consistencyの2つで十分なことが多いです。

実務上の効果と限界#

CoTは便利ですが、どんな場面でも得になるわけではありません。導入前に効果と限界の両方を押さえておきます。

効果の側では、多段の計算・論理・分類の根拠が要るタスクで正答率が上がりやすいこと、そして途中の推論が可視化されるため、なぜその結論に至ったかを人が追える点が挙げられます。監査可能性や、誤りの原因究明(どのステップで間違えたか)という観点で、この可読性は実務上ありがたい性質です。

一方で、限界も明確です。

• 冗長になりコストが増える: 単純な問い合わせに毎回途中式を書かせると、出力トークンが膨らみ、料金とレイテンシが増えます。難易度に見合わないCoTは無駄が多くなります。
• 推論の正しさは保証されない: これが最も注意すべき点です。途中の説明がもっともらしく整っていても、結論が誤っていることはあります。さらに、書かれた推論が本当にモデルの内部処理を忠実に反映しているとは限らず、後付けの説明になっている場合もあります。「途中式が丁寧だから答えも正しい」とは考えないでください。
• タスクを選ぶ: 事実の単純な検索や短い変換のように、そもそも多段の推論が要らないタスクでは、CoTを足しても伸びしろは小さく、冗長さだけが残ります。

可読性を活かすなら、CoTと構造化出力を組み合わせて、推論部分と最終回答をフィールドで分けて受け取る設計が有効です。推論を人が確認しつつ、後工程ではパースしやすい最終回答だけを使う、という切り分けができます。

推論モデル時代の位置づけ#

CoTを語るうえで、今いちばん大事な現代的論点がこれです。近年は、応答を返す前に内部で長い思考(reasoning)を行うタイプのモデル、いわゆる推論モデルが各社から提供されています。こうしたモデルでは、かつてユーザーが手でプロンプトに書いていた「順を追って考える」処理を、モデルが内部で自動的に行います。すると、ユーザーが明示的にCoTを指示する必要性は薄れ、むしろ二重指示が逆効果になり得る、という注意が生まれます。

各社の公式ガイダンスでも、この方向の記述が確認できます(内容や表現は更新され得るため、実装前に最新のドキュメントを確認してください)。

• OpenAIの推論モデル向けガイド(Reasoning best practices)は、推論モデルは内部で推論を行うため「think step by step」や「explain your reasoning」といった指示は不要だとし、chain-of-thoughtプロンプトを避けるよう案内しています。あわせて、まずzero-shotで試し、必要なら少数の例を足す、という順序を推奨しています。
• Anthropicの拡張思考(Extended thinking)のドキュメントは、数学・コーディング・分析のような段階的推論が効く複雑なタスクに拡張思考が向く一方、深い推論を要さないタスクでは有効化しないことを検討するよう述べています。つまり、思考させるかどうかをタスクの性質で選ぶ考え方です。
• GoogleのGemini thinkingのドキュメントも、thinking系モデルが応答前に内部で推論すること、そして思考の深さ(thinking levelやthinking budget)を制御でき、必要に応じて思考をオフにできることを説明しています。

ただし断定は禁物です。推論モデルであっても、出力の構造や着目してほしい観点を指示すること自体は有効ですし、モデルや世代によって最適な促し方は変わります。ベンダーの推奨はモデルごとに更新されるため、手元のモデルの公式ドキュメントで現行の案内を確認するのが確実です。

使いどころの指針#

どういうときにCoTを明示的に使い、どういうときに使わない・別の手段に任せるか。判断の軸を整理します。

向かない・効きにくい場面#

CoTは万能ではありません。次のような場面では、付けても効きにくい、あるいは割に合わないことがあります。

単純なタスクでは冗長さだけが増えます。短い変換、定型の抽出、事実の単純な参照のように多段の推論が要らない処理では、途中式を書かせても精度は伸びず、トークンとレイテンシだけが増えます。

低レイテンシが最優先の用途にも不向きです。中間推論を生成するぶん応答は遅く長くなるため、リアルタイム性が体験を左右する場面では、速さを優先してCoTを外す判断もあり得ます。

推論モデルで既に内部思考している場合は、手書きのCoTが二重指示になりがちです。前述のとおり、ベンダーは推論モデルへの明示的なstep-by-step指示を避けるよう案内しています。この場合は思考の深さの指定に任せるのが基本です。

そして繰り返しになりますが、CoTは正しさを保証しません。誤答が許されない領域では、CoTで読みやすくするだけでなく、根拠の突き合わせや外部ツールでの検算、答えられないときは答えない設計といった、別の担保とあわせて運用してください。

CoTの原典はWei et al., 2022(arXiv 2201.11903)、zero-shot CoTはKojima et al., 2022(arXiv 2205.11916)、self-consistencyはWang et al., 2022(arXiv 2203.11171)に基づきます。推論モデルへの推奨(明示的CoTの要否、思考の深さの制御方法)は各社ドキュメントの記述で、モデルや世代により変わり得ます。実装前に対象モデルの公式ドキュメントで現行の案内を確認してください。

よくある質問#

まとめ#

Chain-of-Thoughtは、途中の推論を言語化させるだけで多段タスクの精度を底上げしうる、プロンプト設計の基礎技術です。原典が示したように効果は確かにありますが、単純タスクでは冗長で、途中式が整っていても結論の正しさは保証されません。そして推論モデルの普及で、「CoTを手で書く」から「どれだけ思考させるかを指定する」へと、使いどころは移りつつあります。手法の名前を覚えることより、対象モデルの性質を見極め、効果を数字で確かめて使い分ける姿勢が、遠回りに見えて確実です。プロンプト設計全体の基本や、生成のランダム性を左右する温度の話とあわせて押さえると、どこを調整すれば安定するかの見通しが良くなります。