CoT・ToT・GoTとは?今でも使える理由と使い分け【テンプレ付き】
以前、思考プロセスについて3本の記事を書きました。
Chain of Thought(CoT)、Tree of Thoughts(ToT)、Graph of Thoughts(GoT)。
3つの整理の仕方で、それぞれ別の場面で使えるものです。
あれから時間が経って、モデルは賢くなりました。
GPT-5.2が出て、Gemini 3が出て、AIは内部で推論を行うようになりました。
難しさに応じて思考量を調整するようにもなりました。
そうなると、「わざわざ型を指定しなくても、勝手に考えてくれるのでは?」という疑問が出てきます。
実際に試してみると、返ってくるのは結論だけ、ということがありました。
比較が欲しかったのに、「これがいいと思います」で終わる。
手順を踏んでほしかったのに、途中が省略されている。
モデルが賢くなったから、もう型は要らない。
そう思っていたのですが、逆でした。
モデルが賢くなったからこそ、型を指定しないとズレる。
この記事では、3つの思考プロセスをまとめ直して、「今でも効く使い分け」として整理します。
※この記事は過去の3つの記事を統合したリメイク記事になります。
🧭 3つの位置づけ
まず、3つの違いを整理します。
CoT(Chain of Thought) は、一本道を進む方法です。
手順を順番に進めて、抜けや飛ばしをなくします。
ToT(Tree of Thoughts) は、分岐して選ぶ方法です。
候補をいくつか出して、比較して、一番良いものを選びます。
GoT(Graph of Thoughts) は、ネットワークで考える方法です。
複数の条件や観点を同時に持って、つなぎ直しながら統合判断します。
この3つは、「何を優先するか」で使い分けられます。
抜けや飛ばしをなくしたいなら CoT。
比較して選びたいなら ToT。
条件が多くて整理したいなら GoT。
全部を同時に使う必要はありません。
場面によって、どれか1つを選べば大丈夫です。
それぞれの使い方を、もう少し詳しく見ていきます。
🔗 CoT:まず抜けなくする → Chain-of-Thought(CoT)の使い方
CoT は、手順を順番に進める方法です。
「何を書けばいいかわからない」ときに、手順を明示すると進みやすくなります。
たとえば、noteの導入3行が書けないとき。
何を書けばいいかわからなくて、何度も消して、また書いて、また消して。
結局、手が止まります。
そういうときに、手順を明示してみる。
具体的には、こんな感じです。
ステップ1
↓
ステップ2
↓
ステップ3
↓
チェック
- すべてのステップが含まれているか
- 抜けや飛ばしがないか手順を明示すると、何を書けばいいかが見えてきます。
ただ、手順を出しても、途中で飛ばされることがあります。
モデルが賢いと、勝手に近道を作ります。
「このステップは省略できるかな」と判断して、飛ばすことがあります。
だから、最後にチェック項目を入れておくと、飛ばされにくくなります。
CoT が使えそうなのは、「順番に進めないと抜けが出そうな場面」です。
記事の構成を考えるとき。
依頼文を書くとき。
何かを整理するとき。
手順を明示して、最後にチェックを入れる。
それだけで、抜けや飛ばしが減ります。
チェック項目は、具体的に書いた方が効きます。

🌿 ToT:枝を生やして選ぶ → Tree of Thoughts(ToT)の使い方
ToT は、候補を複数出して、比較して、選ぶ方法です。
「1つに決めると後悔しそう」なときに、候補を並べて比較すると後悔が減ります。
たとえば、記事のタイトルが決まらないとき。
1つ考えて、「これでいいかな」と思って進めます。
でも、あとで読み返すと、何か違和感があります。
「もっと良いタイトルがあったかもしれない」と思うけど、もう一度考え直す気力がありません。
そのまま公開して、後悔します。
そういうことが、あるかもしれません。
ToT を使うと、最初から候補を並べて比較できます。
具体的には、こんな感じです。
候補1 → 評価 → 3点
候補2 → 評価 → 5点 ★
開始 → 候補3 → 評価 → 4点
...
候補10
↓
上位3つ微調整
↓
最終案 + 次点候補を10個出して、評価軸で採点して、上位3つを選んで、微調整して、最終案を1つ出す。
それだけで、後悔が減るかもしれません。
ただ、評価軸が曖昧だと、評価がテキトーになることがあります。
候補が10個出たのに、「全部いいと思います」で終わる、みたいなことです。
モデルが優しすぎるのか、手を抜いているのか、よくわかりません。
評価軸が曖昧だと、何を基準にすればいいかわかりません。
モデルは、「まあ、どれも良さそうだから、全部いいかな」と判断してしまいます。
そういうときは、評価軸を具体的にしてみる。
評価軸を具体的にすると、評価も具体的になります。
点数もついて、比較しやすくなります。
ToT が使えそうなのは、「1つに決めると後悔しそうな場面」です。
タイトルを決めるとき。
構成案を比較するとき。
言い回しを選ぶとき。
候補を並べて、評価軸で採点して、上位を選ぶ。
それだけで、後悔が減るかもしれません。
あと、次点を残しておくと、あとで見比べられます。
最終案を見て、「やっぱりこっちの方がいいかも」と思ったとき、すぐに戻れます。
次点があると、安心します。

🕸️ GoT:条件を同時に持って統合判断 → Graph of Thoughts(GoT)の使い方
GoT は、複数の条件や観点を同時に持って、統合判断する方法です。
「条件が多くて、何を優先すればいいかわからない」ときに、条件と観点を整理するとトレードオフを判断しやすくなります。
たとえば、記事の構成が散らかるとき。
書きたいことが多すぎて、どこに何を置けばいいかわかりません。
とりあえず思いついた順に書いて、あとで読み返すと、話が飛んでいます。
直そうとすると、どこから直せばいいかわからなくなります。
条件が多すぎて、どれを優先すればいいかわかりません。
そういうことが、あるかもしれません。
GoT を使うと、条件と観点を整理してから構成を決められます。
具体的には、こんな感じです。
条件1
条件2 ┐
条件3 ├→ 統合判断 → 最終案
観点1 │ ↓
観点2 │ 再評価ルール
観点3 ┘条件と観点を整理して、優先順位を明示する。
それだけで、トレードオフを判断しやすくなります。
優先順位を明示すると、条件同士がぶつかったときに判断できます。
ただ、優先順位がないと、無難な案になることがあります。
条件を全部満たそうとして、「まあまあいい感じ」の構成になる。
でも、「まあまあいい感じ」は、「特徴がない」ということでもあります。
そういうときは、「これだけは譲れない」を1つ決めてみる。
1つ決まると、他の条件とぶつかったときに判断できます。
GoT が使えそうなのは、「条件が多くて、トレードオフがある場面」です。
構成を決めるとき。
複数の制約を満たす案を出すとき。
何を優先するか迷うとき。
条件と観点を整理して、優先順位を明示する。
それだけで、トレードオフを判断しやすくなるかもしれません。

🤖 モデルが賢くなったから、型が要る
モデルは賢くなったけど、「何を正解とするか」「どこまで探索するか」は指定しないとズレます。
だから、「思考を見せろ」ではなく「検討の型を指定する」のがコツです。
ここまで、CoT/ToT/GoT の3つを見てきました。
最初に書いたように、モデルは賢くなりました。
内部で推論を行い、難しさに応じて思考量を調整します。
でも、それは「何を正解とするか」「どこまで探索するか」までは固定してくれません。
最新モデルほど「勝手に最短化」します。
比較が欲しいのに、モデルが結論だけ出して終わる。
条件が多いのに、重要な制約が無視される。
探索が必要なのに、一本筋の回答で打ち切られる。
だから、最近のコツは「思考を見せろ」ではなく、「検討の型を指定する」です。
「考え方(内部ログ)」ではなく、「成果物のフォーマット」を指定します。
手順+チェックリスト
候補N+評価軸+採点+最終案+次点
条件・観点の表→統合結論→覆る条件(再評価ルール)
💭 Thinkingモードがあるのに、明示する必要はある?
この疑問、たぶん一度は思います。
最近のモデルには「Thinking」みたいなモードがあって、内部で推論する量を増やせます。だから――
「CoT / ToT / GoTなんて言わなくても、勝手にやってくれるのでは?」
結論から言うと、ラベル(CoT/ToT/GoT)は省いてもいいです。
ただし、型(成果物の形)は省かない方がいいです。
Thinkingが”勝手にやってくれる”こと
Thinkingが強いモデルは、文章が自然にまとまり、破綻しにくいです。
結論までの到達も速いです。
昔より「それっぽい答え」を作るのは得意になっています。
Thinkingが”勝手に固定してくれない”こと
一方で、本当に欲しいのは結論そのものより、決められる状態です。
比較の材料(候補、採点、次点)
決めるための道具(評価軸、チェック、制約の扱い)
作業に落ちる形(テンプレ、手順、短い版)
モデルは賢くなるほど「近道」もしやすいです。
つまり、勝手に最短化して結論だけ返すことがあります。
比較が欲しいのに結論だけで終わる
条件が多いのに重要な制約が落ちる
探索が必要なのに一本道で打ち切られる
必要なのはラベルではなく「成果物の型」
ここで大事なのは、CoT/ToT/GoTという単語を覚えることではありません。
欲しいのは、次の3つの型を「成果物として指定する」ことです。
1) 手順で抜けなく進めたい(CoT相当)
手順(1〜7など)
各ステップの完了条件
最後に抜け漏れチェック
2) 候補を並べて比較して決めたい(ToT相当)
候補10
評価軸で採点
上位3を微修正して最終案
次点も残す
3) 条件が絡むので統合して決めたい(GoT相当)
条件(複数)
観点(複数)
統合して最終案
情報が増えた時の追加ルール(再評価ルール)
思考ログについての短い注意
思考を長く見せてもらうこと自体は、必ずしも信頼性の保証にならない場合があります。
なので「思考を見せろ」より「検証できる形(チェック、比較、条件と観点、再評価ルール)」を求めた方が実務的です。
まとめ
モデルは賢くなりました。
でも、型を指定しないと、勝手に最短化します。
必要なのは思考の中身ではなく、出力の形です。

📝 使える例を3つ置きます
ここからは、実際に使える例を3つ置きます。
コピペして使えるように書いているので、よければ試してみてください。
📌 事例1:タイトルが決まらない(ToTが映える)
状況:
記事は書けたけど、タイトルが決まらない。
1つ考えて、「これでいいかな」と進めたけど、あとで読み返すと違和感がある。
依頼の型:
この記事のタイトルを決めてください。
手順:
1. 候補を10個出す
2. 以下の評価軸で各候補を採点する(5点満点)
- [評価軸1]
- [評価軸2]
- [評価軸3]
3. 上位3つを選ぶ
4. 上位3つを微調整して、最終案を1つ提示する
5. 次点も残す(あとで見比べたい)
記事の内容:[ここに記事の要約を貼る]返ってくるもの:
候補10個
評価軸ごとの採点
上位3つの微調整案
最終案1つ+次点
ありがちなズレ:
候補が10個出たのに、評価がテキトー。「全部いいと思います」で終わる。
直し方:
評価軸を具体的にする。曖昧な基準だと、モデルも困って適当になります。
📌 事例2:導入3行が書けない(CoTが効く)
状況:
何を書けばいいかわからなくて、何度も消して、結局手が止まる。
依頼の型:
この記事の導入3行を書いてください。
手順:
1. [ステップ1]
2. [ステップ2]
3. [ステップ3]
最後に以下を確認してください:
- すべてのステップが含まれているか
- [チェック項目1]
- [チェック項目2]
記事の内容:[ここに記事の要約を貼る]返ってくるもの:
導入3行
チェック結果
ありがちなズレ:
手順を出したのに、途中で飛ばされる。
直し方:
最後にチェック項目を追加する。「すべてのステップが含まれているか」を明示すると、飛ばされにくくなる。
📌 事例3:構成が散らかる(GoTが効く)
状況:
書きたいことが多すぎて、どこに何を置けばいいかわからない。
依頼の型:
この記事の構成を決めてください。
条件:
- [条件1:例:長さの目安]
- [条件2:例:含めたい要素]
- [条件3:例:避けたいこと]
観点:
- [観点1]
- [観点2]
- [観点3]
手順:
1. 条件と観点を表にして整理する
2. 条件を満たしながら、観点のバランスを取った構成案を出す
3. 「情報が増えた場合の追加ルール」を書く(再評価の基準)
条件の優先順位:
1. [最優先の条件]
2. [次点の条件]
3. [その次の条件]
記事の内容:[ここに記事の要約を貼る]返ってくるもの:
条件・観点の整理表
構成案
再評価ルール
ありがちなズレ:
条件を全部満たそうとして、無難な案になる。特徴のない構成が出てくる。
直し方:
優先順位を明示する。「これだけは譲れない」を1つ決めると、トレードオフを判断しやすくなる。
📋 おまけ:コピペ用テンプレ
最後に、3つの型を短くまとめます。
CoT(手順で抜けなくする)
[タスク内容] を実行してください。
手順:
1. [ステップ1]
2. [ステップ2]
3. [ステップ3]
最後に以下を確認してください:
- すべてのステップが含まれているか
- [チェック項目1]
- [チェック項目2]ToT(候補を比較して選ぶ)
[タスク内容] を実行してください。
手順:
1. 候補を10個出す
2. 以下の評価軸で各候補を採点する(5点満点)
- [評価軸1]
- [評価軸2]
- [評価軸3]
3. 上位3つを選ぶ
4. 上位3つを微調整して、最終案を1つ提示する
5. 次点も残すGoT(条件を統合して判断)
[タスク内容] を実行してください。
条件:
- [条件1]
- [条件2]
- [条件3]
観点:
- [観点1]
- [観点2]
- [観点3]
手順:
1. 条件と観点を表にして整理する
2. 条件を満たしながら、観点のバランスを取った案を出す
3. [再評価の条件] が発生した場合の追加ルールを書く
条件の優先順位:
1. [最優先]
2. [次点]
3. [その次]
頭の中で考えていると、どこかで省略します。
順番を飛ばしたり、比較せずに決めたり、条件を忘れたり。
それが、自然なことです。
型を使うと、それが外に出ます。
手順が見えて、候補が並んで、条件が整理されて、抜けや省略に気づけるようになります。
型があると、見えなかったものが見えてきます。
賢いモデルほど、近道を作ります。
型は、その近道を防ぐ道具です。
ただ、型は道具です。
使うかどうかは、自分で決められます。
「今日はタイトルで迷いそうだから、ToT を使ってみようかな」
「導入が書けないから、CoT で手順を出してみようかな」
「条件が多いから、GoT で整理してみようかな」
場面によって、選べます。
知っていると、楽になることがあります。
あとがき
ここまで読んでくださり、ありがとうございます。
過去に調べたAI思考プロセスは、今のThinkingモードがあるモデルでも使えるのか?
という疑問から今回の記事を書いてみました。
普段はもうあまり使うこともなくなったんですけどねw
他にも過去の記事で気になっていることはあるので、またちょいちょいリメイクするかもです。
ちょっと長くなってしまいましたが、よければご活用ください〜。
「フォロー」や「スキ」をしていただけると励みになります!
今後ともよろしくお願いします!

参考文献・リンク
思考プロセス(研究一次ソース)
Chain-of-Thought Prompting Elicits Reasoning in Large Language Models(CoT)
https://arxiv.org/abs/2201.11903Large Language Models are Zero-Shot Reasoners(Zero-shot CoT)
https://arxiv.org/abs/2205.11916Tree of Thoughts: Deliberate Problem Solving with Large Language Models(ToT)
https://arxiv.org/abs/2305.10601Graph of Thoughts: Solving Elaborate Problems with Large Language Models(GoT)
https://arxiv.org/abs/2308.09687
「長い思考ログをそのまま信頼しすぎない」注意点の根拠
Reasoning models don’t always say what they think(Anthropic)
https://www.anthropic.com/research/reasoning-models-dont-say-think
OpenAI(手順/評価軸/制約の指定が効く実務背景)
Prompt engineering guide
https://platform.openai.com/docs/guides/prompt-engineeringReasoning best practices
https://platform.openai.com/docs/guides/reasoning-best-practicesGPT-4.1 Prompting Guide(Cookbook)
https://developers.openai.com/cookbook/examples/gpt4-1_prompting_guide/GPT-5 Prompting Guide(Cookbook)
https://developers.openai.com/cookbook/examples/gpt-5/gpt-5_prompting_guide/
OpenAI(GPT-5.2の背景・裏取り)
Introducing GPT-5.2
https://openai.com/index/introducing-gpt-5-2/GPT-5.2 モデル概要(API / 仕様)
https://platform.openai.com/docs/models/gpt-5.2Model Release Notes
https://help.openai.com/en/articles/9624314-model-release-notes
Google(Geminiの最新版・更新履歴)
Gemini API: Models
https://ai.google.dev/gemini-api/docs/modelsGemini API: Changelog
https://ai.google.dev/gemini-api/docs/changelogThinking(推論・思考量の説明)
https://ai.google.dev/gemini-api/docs/thinkingVertex AI release notes
https://docs.cloud.google.com/vertex-ai/docs/release-notesGemini 2.5 Pro(Vertex AIモデル詳細)
https://docs.cloud.google.com/vertex-ai/generative-ai/docs/models/gemini/2-5-proModel versions and lifecycle
https://docs.cloud.google.com/vertex-ai/generative-ai/docs/learn/model-versionsGemini Apps release notes
https://gemini.google/release-notes/
ハッシュタグ
#CoT #ToT #GoT #プロンプト #プロンプト設計 #プロンプトエンジニアリング #推論 #思考法 #思考整理 #テンプレート #仕事術 #文章術 #学び #比較 #意思決定 #チェックリスト #効率化 #整理 #note #生成AI
いいなと思ったら応援しよう!
気に入っていただけたら、チップで応援してもらえると嬉しいです。
いただいた応援は、今後の記事作りの励みになります!