deep_thinkとは何か — AIに「考える場所」をツールとして与えるアイデア
結論から言うと、deep_thinkとは「モデル標準のthinkingとは別に、考えるための専用ツールをAIに渡す」というエージェント設計のアイデアだ。セキュリティ研究者のCan Bölük氏がXで投稿したものが発端で、難しい判断が必要な場面でだけ、モデルにこのツールを呼び出させる。
最初に見たとき、僕は「AIの隠されたChain of Thoughtを表に出すテクニックなのか」と思った。しかし少し考えるうちに、それとは別の使い方が見えてきた。隠れた思考を覗く装置としてではなく、AIエージェントに「考える場所」を明示的に与える仕組みとして使えるのではないか、ということだ。
[画像挿入：deep_thinkの位置づけが分かる画像]
元ポストはこちら。https://x.com/_can1357/status/2090837707069014224
本記事では、このアイデアの本質を整理したうえで、チャットではなく「エージェント」で使うときに特に面白い理由、さらにplan・verifyといった役割分担への発展までを順に考えていく。
reasoningモデルは答える前に何をしているのか
最近のreasoningモデルは、最終回答を生成するまでに内部で複数段階の処理を行っている。イメージとしては次のような流れだ。
問題を確認
↓
条件を整理
↓
候補を考える
↓
矛盾を確認
↓
回答
ただし、この内部処理がすべてユーザーに表示されるわけではない。そして重要なのは、表示されたChain of Thoughtがモデル内部の判断過程を完全に忠実に表しているとも限らない、という点だ。
Anthropicの研究（Reasoning Models Don't Always Say What They Think）でも、モデルが判断に利用した情報をCoT上で必ずしも説明しないことが報告されている。つまり「モデルが書いた思考」と「モデルが実際に判断に使ったもの」を完全に同一視するのは危険だ。
この性質は、このあと説明するdeep_thinkの捉え方を決めるうえで重要な前提になる。
deep_thinkの使い方 — ツール呼び出しの中で判断を整理する
具体的には、モデルにdeep_thinkというツールを渡し、「難しい判断をする必要がある場合はdeep_thinkを使用してください」と教えるだけだ。
deep_think({
"assessment": "...",
"uncertainty": "...",
"next_action": "..."
})
するとモデルは、最終回答を書くのとは別に、ツール呼び出しの引数という形で判断を整理できる。assessment（現状の評価）、uncertainty（不確かな点）、next_action（次の行動）といった項目へ、考えている内容を分解して書き出すイメージだ。
ここで強調しておきたいのは、これを「AIの本当の脳内を覗く装置」と決めつけないことだ。前節で見たとおり、書き出された思考が実際の判断過程と完全に一致する保証はない。むしろ「モデル自身が利用できる外部scratchpadを用意する」と考えたほうが、設計としても分かりやすい。
internalcotなど、似た発想の実装はすでに登場している
このアイデアを発展させたinternalcotというオープンソース実装も公開されている。CodexやClaude Codeに対し、問題分解・中間判断・選択肢・根拠・不確実性・確認事項などを、通常のツールトランスクリプトへ書き出すためのワークスペースを追加するものだ。
ただしREADMEにも重要な説明がある。この実装はホスト側のnative reasoning（モデル内部の推論）を直接読み取っているわけではない。エージェント自身に「visible working notes（可視の作業メモ）」を書かせる仕組みだ。
つまり位置づけとしては、「隠された思考を盗む」テクニックではなく、「考えるための場所をエージェントのワークフロー上に作る」工夫と言える。僕が興味を持ったのはまさに後者の側面だ。
AIエージェントで特に面白い理由 — 「何を考えるか」より「いつ考えるか」
普通のAIチャットなら「質問→回答」で終わる。しかしAIエージェントは、複数の行動を連続して実行する。たとえばニュースを調べて記事にするなら、次のような流れになる。
検索
↓
ページ取得
↓
内容を読む
↓
別の情報源を検索
↓
比較
↓
重要度を判断
↓
記事を作る
このとき効いてくるのが「何を考えるか」だけではなく「いつ考えるか」だ。たとえば検索結果を3件取得した時点で、次のような判断が発生する。
情報は十分なのか？
一次情報はあるのか？
記事同士で内容が矛盾していないか？
別の検索をするべきなのか？
こうした「立ち止まって判断するタイミング」に、明示的なdeep_thinkを挟めるのがエージェントならではの面白さだ。チャットには存在しない、行動と行動の間に考える場所を作れる。
[画像挿入：deep_thinkの有無で処理フローがどう変わるかが分かる画像]
ニュース調査エージェントに入れるとこう変わる（具体例）
通常のエージェントが次のような流れだとする。
Search
↓
Fetch
↓
Search
↓
Fetch
↓
Answer
これを、次のように変える。
Search
↓
Fetch
↓
deep_think
↓
必要なら追加Search
↓
verify
↓
Answer
deep_thinkで整理させる内容は、次の5点だけに絞る。
現在確認できている事実
まだ確認できていないこと
情報源同士の矛盾
追加調査が必要か
次に取るべき行動
注目してほしいのは、モデルそのものは一切変えていないという点だ。それでも、行動の間に判断を整理する場所ができるだけで、エージェントの動きはかなり変わる可能性がある。
先行研究から見る「考える工程と行動する工程を分ける」考え方
「考えるツール」は全新的な発想なのかというと、そうではない。reasoningとtool useを組み合わせる研究自体は以前からある。
ART（Automatic multi-step reasoning and tool-use）では、モデルが複数ステップのreasoningと外部ツール利用を交互に行うことで、未知のタスクでも性能向上を狙う仕組みが研究されている。また最近のRecThinkerでも、次のような流れで情報不足を判断し、必要なツールを自律的に呼び出す設計が使われている。
Analyze
↓
Plan
↓
Act
つまり「考える工程」と「行動する工程」を分けるという考え方そのものには、すでに一定の裏付けがある。deep_thinkが面白いのは、それを非常に単純な形——ツールを1つ渡すだけ——でエージェントに持ち込めそうなところだ。
役割を分けたらどうなるか — plan・deep_think・verify・final_review【仮説】
ここからは僕の仮説になる。deep_thinkひとつだけではなく、役割を分けたツール群にしてもいい。たとえば次の4つだ。
plan()
deep_think()
verify()
final_review()
それぞれの役割を整理する。
[画像挿入：4つの思考ツールの役割分担が分かる画像]
planは「どう調べるか」を決める
planが決めるのは、目的・必要な情報・使用するツール・処理順序だ。着手前に調査設計を一枚書かせるイメージで、単純なタスクでは必須ではない。
deep_thinkは「どう判断するか」を整理する
deep_thinkが扱うのは、判断候補・根拠・不足情報・不確実性・次の行動。行動の合間に挟み、今どの選択肢を取るべきかを構造化して書き出す。
verifyは「判断は正しいか」を確認する
verifyは一次情報があるか、情報は最新か、矛盾はないか、根拠は十分かを確認する。考えることと検証することは目的が違うため、deep_thinkとは分ける。
final_reviewは外部へ影響を与える直前だけ使う
final_reviewは、DB更新・記事公開・メール送信・ファイル削除など、外部へ影響を与える操作の直前にだけ使用する。取り返しのつかない行動の前で最後にもう一度立ち止まるためのゲートだ。
モデルを賢くするのではなく、仕事の仕方を変える
ここが今回一番面白いと思ったところだ。AIの性能を上げようとすると、普通は次の3つを考えがちだ。
もっと強いモデルを使う
thinkingをHighにする
プロンプトを長くする
しかし別の方法がある。モデルは同じままで、そのモデルが働く環境を変える、というやり方だ。
人間でも同じことが起きる。「もっと頭が良くなれ」と言われるより、次のように工程を整理されたほうが仕事の品質が上がることがある。
まず調査してください
次に候補を比較してください
最後に確認してください
AIエージェントでも同じことが言えるのかもしれない。与えるツールと、考えるタイミングの設計次第で、同じモデルでも成果物の品質は変わる可能性がある。
OpenClawで試す — まずは思考工程だけ追加する
僕はOpenClawを使って、AI・テックニュースを収集して記事化する仕組みを運用している。このアイデアを実際に試してみることにした。
現在の処理が次の流れなら、
ニュース発見
↓
情報取得
↓
重要度判定
↓
記事生成
次のように変える。
ニュース発見
↓
情報取得
↓
deep_think
↓
必要なら追加調査
↓
verify
↓
重要度判定
↓
記事生成
モデルは変えない。まずは思考工程だけを追加する。変数を1つに絞ることで、効果の原因を見誤らないようにするためだ。
ただし、本当に良くなるとは限らない
当然だが、deep_thinkを入れれば必ず性能が上がるという話ではない。むしろ次のような悪化の経路も考えられる。
考える回数が増える
↓
処理時間が増える
↓
トークンが増える
↓
コストが増える
さらに、モデルが必要以上に考えて判断を悪化させる可能性もある。考えすぎは人間と同じで毒だ。
だから重要なのは、実際に比較することだ。次回は、OpenClawにdeep_thinkを追加するとしたらどういう設計にするのかを具体的に考えていく。
まとめ: 思考環境の設計という新しい設計軸
Can Bölük氏の投稿を「AIの秘密の思考を取り出せる裏技」としてだけ見るのは、少しもったいない。僕が興味を持ったのはむしろ、AIに「考えるための場所」をツールとして与える、という部分だ。
モデルの性能だけではなく、次の4点まで設計対象になる。
いつ考えるか
何について考えるか
いつ調べ直すか
いつ検証するか
これからAIエージェントを作るうえで、この「思考環境の設計」はかなり重要になってくる気がしている。次回はOpenClawへの組み込み方を具体的に設計する。
参考：Can Bölük氏による元ポスト（https://x.com/_can1357/status/2090837707069014224）、morluto/internalcot、ART: Automatic multi-step reasoning and tool-use for large language models、Reasoning Models Don't Always Say What They Think
なお、本記事後半の「deep_thinkをエージェント設計へ応用する」という部分は、元ポストが実証した内容ではなく、投稿をきっかけに考えた仮説である。