Chain of Thoughtとは?CoTプロンプトの使い方と推論モデルでの判断基準

Chain of Thought(CoT)の仕組みと使い方を、在庫照合のプロンプト例で解説します。途中の計算を示す場面と、推論モデルのeffortを調整する場面を整理。OpenAI・Claude・Geminiの指針、根拠の求め方、応答時間や正確さの評価方法まで、業務で判断するための要点を紹介します。

公開日

Chain of Thoughtとは?CoTプロンプトの使い方と推論モデルでの判断基準

Chain of Thought(CoT、思考の連鎖)プロンプティングは、途中の計算や手順を明示することが役立つタスクで使います。ただし、推論モデルへの指示に「ステップごとに考えて」を毎回付け加える必要はありません。2022年に提案されたこの手法は、解き方を示す例を使ってモデルを答えへと導くものでした。現在の推論モデルは、その過程を出力せずに内部で推論できます。業務では、必要な根拠と成果物をまず指定し、タスクに応じて推論にかける労力を調整します。

Chain of Thought(チェーンオブソート)とは?仕組みと基本の考え方

Chain of Thoughtプロンプティングとは、最終的な答えだけを示すのではなく、途中の手順を言語モデルに与えたり、その手順の出力を求めたりする手法です。 大規模言語モデル(LLM)は、与えられた指示と文脈に基づいてテキストを生成します。CoTは、そのやり取りを組み立てる方法のひとつです。

この名称の手法を提案したのは、Jason Weiらの論文 Chain-of-Thought Prompting Elicits Reasoning in Large Language Models です。初回の投稿日は2022年1月28日でした。プロンプト内の例では、問題に短い説明と答えを添えています。モデルは新しい問題に対しても、その形式に続く形で回答します。既存のモデルへの指示の工夫であり、タスクごとにモデルを再学習させる方法ではありません。原論文。

在庫の照合方法を覚える担当者を想像するとわかりやすいでしょう。最終的な在庫数だけを見せても、求め方は伝わりません。期首在庫、出荷、入荷、そして計算結果を示せば、計算方法が伝わります。これが、当初の手法の基本的な発想です。

現在の推論モデルを使うときは、もうひとつ区別が必要です。担当者が計算に使うメモと、上司に提出する報告書は別物です。同じように、モデルの内部処理に余裕を与えながら、最終回答は短くするよう求められます。

Chain of Thoughtは何のために使うのですか?

目的は、答えに至る途中の処理が重要な問題を解きやすくすることです。具体的な手本が有効なモデルであれば、解法付きの例を示すことで、どの数値を組み合わせるか、どの規則を適用するかを伝えられます。

業務で見るべきなのは、結果がより正確になり、確認しやすくなるかどうかです。説明が長くなっただけでは、どちらも証明できません。プロンプトは改善案のひとつとして扱い、実際のタスクで評価します。

CoTプロンプティングの業務での使い方と具体例

方法を教えるには解法付きの例を使い、確認担当者に見せたい情報は出力要件で指定します。 両者が重なることはありますが、手順を求める目的はそれぞれ異なります。

在庫照合の例:答えだけを示す場合と、解き方も示す場合

ここでは、在庫照合を例にプロンプトの違いを見てみます。論文の例をそのまま転載したものではなく、業務向けに作った説明用の例です。計算結果も説明のために用意したもので、モデルをテストして得た出力ではありません。

変更前:答えだけを示す例

例題:最初の在庫は12個です。5個を出荷し、3個を入荷しました。残りは何個ですか?

解答例:10個です。

新しい問題:最初の在庫は18個です。7個を出荷し、4個を入荷しました。残りは何個ですか?

変更後:同じ例に途中の計算を加える

例題:最初の在庫は12個です。5個を出荷し、3個を入荷しました。残りは何個ですか?

解答例:残りの在庫 = 最初の在庫 − 出荷数 + 入荷数 = 12 − 5 + 3 = 10個です。

新しい問題:最初の在庫は18個です。7個を出荷し、4個を入荷しました。残りは何個ですか?

変えたのは、例の中で解き方を示した点です。新しい問題の正解は、どちらも15個です。このプロンプトだけでモデルが正しく答えると証明できるわけではありませんが、few-shot CoTの仕組みを示しています。「few-shot」とはプロンプトに例を含めることで、例をひとつだけ示す形がその最小構成です。

問題と答えだけを示す例と、その間に解き方を加えた例を建築的な構成で比較した図
当初の手法では、例の示し方を「問題、解き方、答え」に変えます。

情報抽出:項目の値と根拠を求めます

買掛金業務の担当者が請求書番号を抽出するなら、まずは直接的に指示します。

請求書番号を記載どおりに返し、その番号を含む原文の行も示してください。見つからない場合はnullを返してください。他の識別番号から推測しないでください。

モデルが見出しに気づいた経緯を長々と説明しても、あまり役には立ちません。該当する原文の行があれば、担当者は抽出結果を確認できます。内容の食い違う発注書と請求書の照合までタスクが広がるなら、推論にかける労力を増やすことを検討します。

判断:適用した規則を示してもらいます

サポート担当者が返金申請を確認する場合は、判断に必要な出力を指定します。

提供された返金ポリシーだけを適用してください。推奨する対応、該当するポリシーの条項、その判断を裏付ける顧客の事実関係、判断を妨げている不足情報を返してください。理由の説明は簡潔にしてください。

これなら、非公開の推論を逐一書き出すよう求めずに、役立つ根拠を指定できます。繰り返し使うポリシーと出力に関する指示はシステムプロンプトに置き、個別案件の資料とは明確に分けます。

ゼロショットCoTとは?例を使わずに手順を求める方法

ゼロショットCoTは、解法付きの例を与えずに、途中の推論を求める方法です。 Takeshi Kojimaらは、2022年5月24日に初めて投稿した論文 Large Language Models are Zero-Shot Reasoners で、「Let's think step by step.」(ステップごとに考えてみましょう)というフレーズを用いて、この方法を研究しました。ゼロショットCoTの論文。

在庫の問題に当てはめると、次のようなプロンプトになります。

最初の在庫は18個です。7個を出荷し、4個を入荷しました。残りは何個ですか? ステップごとに考えてみましょう。

このフレーズは、特定の解法を実演するのではなく、一般的な指示を与えます。手法の歴史を理解するうえでは有用ですが、現在のあらゆるモデルを改善する万能の合図ではありません。

派生手法も、それぞれ仕組みが異なります。Few-shot CoTは解法付きの例を与えます。Zero-shot CoTは例を与えずに指示します。Auto-CoTは多様な質問からモデルを使って例を作る方法で、推論モデルが内部で考えることの別名ではありません。Auto-CoTの論文。

業務では、まず明確なタスクを与え、うまくいかなかった箇所を確認します。足りないものが解き方、境界条件の例、求める出力形式であれば、例を追加します。

推論モデルでは何が変わるのですか?

推論機能を備えたモデルでは、タスク、制約、成果物を定義することが指示の中心になります。 推論設定で調整するのは、モデルが内部処理にかける労力です。最終的な説明への指示で決まるのは、ユーザーが受け取る内容です。

以下のガイダンスは、2026年10月18日にOpenAI、Anthropic、Googleの公開中の公式ドキュメントと照合して確認しました。設定はモデルとAPIによって異なるため、すべてのプロバイダーにそのまま使える共通の「思考予算」設定はありません。

OpenAI:推論モデルには直接的に指示します

OpenAIの推論モデル向けガイダンスでは、これらのモデルは内部で推論するため、ステップごとに考えさせるプロンプトは不要で、場合によっては性能を損なうとしています。まずは目的、関連する文脈、制約、明確な出力形式を示します。推論モデルのベストプラクティス。

この助言が、OpenAIのすべてのモデルに当てはまるわけではありません。GPT-4.1のプロンプティングガイドでは、同モデルを非推論モデルと位置づけ、明示的に段階を踏ませるプロンプトが役立つ可能性を説明しています。ただし、出力量と応答時間は増えます。実際に使うモデルに合わせて、指示の方法を選びます。GPT-4.1プロンプティングガイド。

推論モデルへのプロンプトの書き方を説明するOpenAIのドキュメント
OpenAIによる推論モデル向けプロンプティングのガイダンス

Anthropic:手順を細かく指定する前に、thinkingとeffortを調整します

AnthropicのClaudeプロンプティングガイドは、推論の手順をひとつずつ書き込むよりも、考え方の大きな方向性を示す方法を推奨しています。解法付きの例も、取り組み方を伝えるうえで引き続き有効です。手動のCoT指示は、対応モデルでthinkingをオフにしている場合の代替手段です。新しいモデルの一部は、内部推論を書き出すよう求めても応じないことがあります。Claudeプロンプティングのベストプラクティス。

実務では、処理する仕事に合ったeffortレベルを選び、それでもモデルの動作を調整する必要があれば、プロンプトに指示を加えます。単純な依頼にはそのまま回答する場合があり、effortを設定しても、画面にthinkingブロックが表示されるとは限りません。thinkingの制御。

Anthropicの現行のClaudeプロンプティングベストプラクティスのドキュメント
Anthropicは、モデルに備わるthinking機能と手動のCoT指示を区別しています

Google:内部で推論するなら、通常は計画の書き出しは不要です

GoogleのGeminiプロンプティングガイドでは、Gemini 2.5およびGemini 3シリーズは内部で思考を生成するため、概要や詳細な推論手順を回答に含める必要は通常ないとしています。一方、難しい問題では、より深く考えるよう簡潔に指示すると役立つこともあり、その場合は思考トークンが増えるとしています。タスクに応じた助言であり、その一言を加えればすべての回答が改善するという意味ではありません。Geminiのプロンプト設計戦略。

項目の値を調べるタスクでは、Googleのthinkingガイドは、対応していれば思考レベルを最小または低にすることを勧めています。より大きな労力は、複数の段階にわたる計画など、複雑なタスクに使います。Geminiのthinking。

推論と計画に関するガイダンスを掲載したGoogle Geminiのプロンプト設計ドキュメント
Googleは、内部の思考と回答として返す説明を分けて扱っています

推論のeffortレベルとトークン予算はどう違うのですか?

effortレベルは、モデルがどれだけ深く処理するかを調整します。トークン予算は、対応する構成で思考に割り当てるトークン量を指定します。どちらも、最終回答にどの根拠を含めるかを指示するものではありません。

プロバイダーとインターフェース確認する設定項目注意すべき制約
OpenAI Responses APIreasoning.effort対応するレベルと既定値はモデルによって異なります。
Anthropic Claude APIadaptive thinkingと組み合わせるoutput_config.effort対応する旧構成ではbudget_tokensを使いますが、すべての新しいモデルにこの項目を持ち込まないでください。
Google Gemini APIInteractionsではthinking_level、Generate ContentではthinkingLevelGemini 2.5向けのGenerate Content設定では、代わりにthinkingBudgetを使います。

これらは実装時に確認するフィールド名であり、共通の設定形式ではありません。変更前に、該当するOpenAIの推論リファレンス、Claudeのthinkingガイド、Gemini Generate Contentのリファレンスを確認してください。

課金: OpenAIは、推論トークンそのものをAPIで閲覧できなくても、出力トークンとして課金すると明記しています。プロバイダーによる課金の説明。

トークンは、モデルが処理・生成する際の単位です。見えるテキストとトークン使用量の違いは、AIにおけるトークンの意味で解説しています。短い回答でも、内部では多くの処理が行われている場合があります。

単純な検索は直接回答へ、複数段階のタスクはeffortの調整へと分岐する建築的な経路図
内部の推論にかける労力はタスクに合わせ、確認に必要な出力は別に指定します。

途中の手順を回答に含めてもらうべき場面

途中の手順そのものが成果物として役立つ場合は、回答に含めるよう求めます。 財務担当者には、式と代入した数値が必要かもしれません。サポートの確認担当者には、ポリシーの条項と、それに該当する事実が必要かもしれません。業務分析の担当者には、提案の前提、参照元、計算過程が必要になることがあります。

依頼は具体的にします。

推奨する対応、その根拠となる参照元、主な前提、簡潔な説明を返してください。結果を再現するために必要な計算を示し、不足している根拠があれば明記してください。

これは人が検証できる説明を求める指示です。内部の思考、うまくいかなかった試行、非公開の途中状態をすべて求めているわけではありません。

プロバイダーが提供する思考の要約は、また別の出力です。OpenAIは、生の推論トークンではなく、対応する推論要約を提供しています。Anthropicも、Claudeのthinkingテキストは生の思考の連鎖ではなく要約だと説明しています。これらは診断の参考情報として扱い、計算処理の全記録とはみなさないでください。OpenAIの要約、Claudeのthinking出力。

開発者は、アプリケーションが検証できるフィールドを定義します。業務担当者は、確認担当者が照合できる根拠を定義します。判断に現在の残高や注文状況が必要なら、ツールでその情報を取得してください。Function callingは、モデルをこうした外部処理につなぐ仕組みです。考える時間を増やしても、不足している記録は手に入りません。

Chain of Thoughtが逆効果になるのはどんなときですか?

単純な検索や定型の情報抽出では、凝った推論プロンプトは省きます。 既知のアカウントIDを返すだけなら、長い理由説明は必要ありません。余分な文章が増えるほど、アプリケーションが解析する量も、確認担当者が読む量も増えます。

次の制約は応答時間です。推論を文章で明示すれば出力量が増え、モデル内部のeffortを上げれば、必要な答えが返るまでに時間がかかることがあります。OpenAIはGPT-4.1について、出力量と応答時間のトレードオフを説明しています。Googleも、単純なタスクでは思考を軽くすることを勧めています。実務では、まず直接的なプロンプトを使い、評価結果が必要性を示した場合にだけ複雑さを増やします。GPT-4.1ガイド、Geminiのthinkingガイダンス。

情報不足は、これとは別の問題です。必要なポリシーをそもそも渡していないなら、長く考えるよう求めても解決にはなりません。ポリシーを取得し、バージョンを特定します。入力が大きすぎる場合は、思考量を増やす実験の前に、モデルが作業に使える領域であるコンテキストウィンドウへ入れる内容を見直します。

手順を固定しすぎると、タスクに合わなくなることもあります。入荷と出荷を扱う在庫の例だけでは、返品、破損、引当済み在庫の扱いはわかりません。実際のタスクを代表する例を用意し、不足している規則があればモデルが報告できるようにします。

原論文の数値からわかること、わからないこと

原論文のベンチマークが示すのは、特定のタスクで得られた当時の結果であり、業務での正解率向上を約束するものではありません。 WeiらのNeurIPS 2022論文では、数学の文章題ベンチマークGSM8KにおけるPaLM 540Bの正解率は、通常のプロンプティングで17.9%、Chain of Thoughtプロンプティングで**56.9%**と報告されています。この設定では、解法付きの例を8件使っています。数値は、2023年1月10日付の改訂版の表1に記載されたものです。論文と結果。

これらの数値から、請求書の情報抽出、返金対応の提案、現在の推論モデルでどれだけ改善するかは推定できません。モデル、ベンチマーク、プロンプトの設定がすべて関わります。この手法が注目された理由を理解する材料として使い、導入するタスクは別途測定してください。

Chain of Thoughtにはどんな過大評価がありますか?

もっともらしい説明は、完全な監査記録ではありません。 2025年4月3日に公開した研究で、Anthropicは、モデルが与えられたヒントを利用していながら、その影響を説明に含めない事例を確認しました。実験は、特定のモデルとタスクを使った条件を統制したシナリオで行われたもので、あらゆる業務ワークフローを測定した結果ではありません。それでも、理由の説明を、その答えがどう生成されたかの証拠として扱えない理由を示しています。Anthropicによる推論説明の忠実性の研究。

判断を監査できるようにするには、渡した資料、取得した記録、ツールの実行結果、適用した規則、最終出力を保存します。引用を原資料と照合し、可能なら計算もやり直してください。モデルが書いた説明は、確認担当者が提案を理解する助けにはなりますが、こうした記録の代わりにはなりません。

もうひとつの過大評価は、推論モデルがあればプロンプト設計は不要になるという見方です。変わるのは、指定すべき内容です。業務上の目的、使ってよい根拠の範囲、例外の扱い、出力形式は、引き続き利用者が決める必要があります。

今週、業務のプロンプトで見直すこと

すべての依頼に一律で「ステップごとに考えて」と付けているなら、見直しを始めましょう。 開発者は、日常的な情報抽出からこの指示を外すテストを行い、同じケースで直接的なタスク指示と比較します。業務担当者は、推論を余さず書き出す依頼をやめ、確認に必要な出力を具体化します。求めるのは、根拠、計算、前提、簡潔な提案です。

代わりのプロンプトをテストしている間は、機能している既存のプロンプトを残します。 有効な例を使っている非推論モデルが、自動的に時代遅れになるわけではありません。推論モデルへの移行は再評価のきっかけであり、既存のワークフローを削除すべき根拠ではありません。

  1. 正解を確認できるタスクを選びます

    請求書の項目抽出や在庫照合など、繰り返し発生する仕事を選びます。何を正解とするか、どの場合に情報不足を返すべきか、ソフトウェアが何を解析できる必要があるかを書き出します。

  2. 変更はひとつずつ比較します

    モデルと入力ケースを固定し、直接的なプロンプトと解法付きの例を含むプロンプトを比較します。次に推論モデルで、プロンプトを固定したまま、対応するeffortレベルを変えます。回答の正確さ、根拠が不足したときの動作、完了までの時間、トークン使用量を記録します。

  3. 複雑さに見合う効果がある変更だけを残します

    計算や完全一致が必要な項目は、決まった規則で機械的に検証する方法を優先します。判断が必要な部分には、評価基準と人による確認を使います。LLMを評価者として使う方法は評価の規模を広げる助けになりますが、その採点にも基準の調整が必要です。品質と応答時間の要件を満たす版を導入します。

週明けに取り組むなら、定例業務で使っているプロンプトをひとつ選び、確認担当者が必要とする根拠を指定して、上の比較を実施します。チェックを通過する最もシンプルな構成を残してください。

Chain of Thoughtプロンプティングのよくある質問

Chain of Thoughtプロンプティングとは何ですか?

最終的な答えに至る途中の手順や、解法付きの例を使って言語モデルに指示する方法です。当初のfew-shot手法は解き方を例で示し、zero-shot CoTは例を与えずに手順を求めます。

思考の連鎖にはどのような例がありますか?

AIへのプロンプトでは、途中の計算を示した在庫計算が一例です。最初の在庫から出荷数を引き、入荷数を足すと、残りの在庫が求められます。この計算を解答済みの例と一緒に示すことで、似た問題への取り組み方を伝えられます。

CoTプロンプトの具体例を教えてください

「最初の在庫は18個です。7個を出荷し、4個を入荷しました。残りは何個ですか? ステップごとに考えてみましょう。」がzero-shot CoTの例です。推論機能を備えたモデルなら、代わりに最終成果物として、残りの在庫数と再現可能な計算を求めることもできます。

Chain of Thoughtは今でも役立ちますか?

はい。特に、具体的な手本が有効なモデルや、解き方の説明が役立つタスクで有用です。ただし、推論モデルでは出発点が変わります。まず明確な指示とモデルの推論設定を使い、役立つ場面で例や説明の要件を追加します。

Chain of Thoughtプロンプティングは誰が考案したのですか?

Jason Weiらが、2022年の論文 Chain-of-Thought Prompting Elicits Reasoning in Large Language Models で、この名称の手法を提案しました。プロンプト内の例と、自然言語による途中の説明を組み合わせた研究で、理由説明やプロンプティングに関する先行研究を土台にしています。

Chain of Thoughtプロンプティングの主な利点は何ですか?

適したモデルであれば、答えへ直接飛ぶのではなく、途中の処理を通じて問題に取り組みやすくなります。業務の改善につながるかは、モデルとタスク次第です。説明の長さそのものは、品質の指標になりません。

プロンプトチェーンとChain of Thoughtの違いは何ですか?

プロンプトチェーンは、ワークフローを複数のモデル呼び出しに分け、ある呼び出しの結果を次へ渡す方法です。Chain of Thoughtプロンプティングが扱うのは、プロンプト内の例や回答に含まれる途中の手順です。両方を同じワークフローで使うことはできますが、別々の設計上の選択です。

実用的なAIワークフローを構築するためのガイドは、ニュースレターに登録してお読みください。

公開日
カテゴリー
Build
プロンプトチェーンの作り方:「抽出・検証・下書き」でAIの出力を確認する

プロンプトチェーンの作り方:「抽出・検証・下書き」でAIの出力を確認する

プロンプトチェーンの基本から、問い合わせ対応を「抽出・検証・下書き」に分ける具体例まで解説します。情報不足や根拠の矛盾を見つけたらどこで止め、どう再開するか。長いプロンプトやAIエージェントとの使い分け、最終出力の確認、n8n・Makeで実装する際の条件設計も押さえ、業務に合うワークフローを考えます。2026年10月18日Build
Claude Code auto modeと権限スキップ:確認を減らす設定と注意点

Claude Code auto modeと権限スキップ:確認を減らす設定と注意点

Claude Codeの権限確認を減らしたい方へ。dangerously-skip-permissionsで省略される承認と、残る制御を解説します。autoモードや権限ルール、planモード、フックの使い分けから、非rootの隔離コンテナで実行する手順、クラウド設定の注意点まで、用途に合う設定を選べます。2026年10月18日Build
Cursor VSCode比較:料金・AI機能と乗り換えの判断基準【2026年】

Cursor VSCode比較:料金・AI機能と乗り換えの判断基準【2026年】

CursorとVSCodeの違いを、Tab補完、AIエージェント、Copilot、拡張機能、料金、プライバシーから比較します。Claude CodeやCodexを今の環境で使う選択肢も整理。移行前に確かめたい互換性と設定、試すべき作業を押さえ、乗り換えが自分の開発に見合うか判断できます。2026年10月18日Build
n8nレビュー:料金・使い方と、導入前に知るべき運用の条件

n8nレビュー:料金・使い方と、導入前に知るべき運用の条件

n8nとは何ができる自動化ツールなのか。料金と使い方、Cloudとセルフホストの選び方、無料版の共同作業の制約を解説します。AIエージェントの権限管理や障害時の復旧まで、導入前に確認したい条件を整理。Zapier・Makeとの違いも踏まえ、技術担当者がいる企業に向く理由と、別の選択肢が適する場面を検討します。2026年10月18日Build
Railway 料金比較:Renderとの違いと選び方【2026年版】

Railway 料金比較:Renderとの違いと選び方【2026年版】

RailwayとRenderの料金を、Webアプリ・ワーカー・Postgresを動かす同じ条件で比較します。月額$15.11と$20の試算に加え、無料枠、データベースの復旧、cron、スケーリング、移行時の制約を解説。安さだけでは見えない運用の違いと、個人開発や小規模チームに合う選び方を整理します。2026年10月18日Build
Pydantic AIとは?Python向けAIエージェントフレームワークの使い方

Pydantic AIとは?Python向けAIエージェントフレームワークの使い方

Pydantic AIは、型付きツールと検証済みの構造化出力を扱うPython向けAIエージェントフレームワークです。問い合わせ分類の実装例を通じて、依存性注入、モデルの切り替え、MCP、永続実行、評価の役割を解説。LangGraphやLangChain、APIの直接呼び出しとの使い分けも整理します。2026年10月17日Build
AIガードレールの設計と実装:チェック箇所・主要ツール・最小構成

AIガードレールの設計と実装:チェック箇所・主要ツール・最小構成

AIガードレールを、入力・取得データ・モデルの提案・ツール実行・出力の5つの境界で整理。返金リクエストを例に、コンテンツフィルターと権限確認、人による承認の違いを解説します。主要ツールの対応範囲と制約、小規模チームが始める6つの制御、Promptfooで確かめるテストケースまで、実装の判断に必要な要点をまとめます。2026年10月17日Build
ハルシネーションとは?LLMが誤る原因と誤回答を減らす実装

ハルシネーションとは?LLMが誤る原因と誤回答を減らす実装

LLMのハルシネーションは、架空の事実だけでなく、誤った数値や引用、ツール引数にも現れます。原因と実例を整理し、RAGによる根拠の取得、引用や値の検証、根拠が足りない場合の回答保留、Pythonの検証コード、評価テストまで解説。顧客への誤回答や誤操作を減らすために、小規模チームが取り組める実装手順を紹介します。2026年10月17日Build
ニュースレター

毎週日曜、一通の手紙。動くシステムの話。感想戦ではなく。

週刊。スパムなし。いつでも解除できます。