見出し画像

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

他にも過去の記事で気になっていることはあるので、またちょいちょいリメイクするかもです。

ちょっと長くなってしまいましたが、よければご活用ください〜。

「フォロー」や「スキ」をしていただけると励みになります!
今後ともよろしくお願いします!



参考文献・リンク

思考プロセス(研究一次ソース)

「長い思考ログをそのまま信頼しすぎない」注意点の根拠

OpenAI(手順/評価軸/制約の指定が効く実務背景)

OpenAI(GPT-5.2の背景・裏取り)

Google(Geminiの最新版・更新履歴)


ハッシュタグ

#CoT #ToT #GoT #プロンプト #プロンプト設計 #プロンプトエンジニアリング #推論 #思考法 #思考整理 #テンプレート #仕事術 #文章術 #学び #比較 #意思決定 #チェックリスト #効率化 #整理 #note #生成AI

いいなと思ったら応援しよう!

緑どんぐり 気に入っていただけたら、チップで応援してもらえると嬉しいです。 いただいた応援は、今後の記事作りの励みになります!

この記事が参加している募集