deep_think実装の前提 — 目的はCoTの取得ではなく意思決定の整理
結論から言うと、OpenClawに追加するdeep_thinkは「AIの隠されたChain of Thoughtを取り出す装置」ではなく、意思決定用のscratchpadとして設計する。これが最初に決めた大前提だ。
目的は実用的なほうにある。OpenClawが難しい判断をするときに、次の4点を一度整理させることだ。
現在分かっていること
不確かなこと
追加調査すべきこと
次に取るべき行動
前回の記事で考えたアイデアを、今回は自分のニュース収集エージェントへ落とし込む。この記事は実装前の設計段階であり、動作検証は次回以降に行う。
[画像挿入：deep_thinkの設計方針が分かる画像]
ニュース収集フローのどこに思考工程を入れるか
現在のOpenClawのニュース収集は、基本的に次の流れだ。
ニュース候補発見
↓
記事取得
↓
内容を評価
↓
採用 / 不採用
↓
記事生成
ここへ、deep_thinkとverifyを挟み込む。
ニュース候補発見
↓
記事取得
↓
deep_think
↓
追加調査
↓
verify
↓
採用 / 不採用
↓
記事生成
ポイントは、毎回deep_thinkを実行しないことだ。すべてのニュースで考えさせていたら、単純な記事にまで思考コストがかかり、処理時間とトークンが膨らむ。発動条件を絞るのが設計の要になる。
deep_thinkを使う条件・使わない条件
deep_thinkを発動するのは、たとえば次の場合だけだ。
複数の情報源で内容が食い違う
一次情報が見つからない
confidenceが低い
発表日が分からない
同じニュースか別ニュースか判断できない
次に取れる行動が複数ある
重要度判定が微妙
外部へ変更を加える直前
逆に、次の状態が揃っているならdeep_thinkは呼ばずにそのまま進む。
公式発表あり
内容が明確
日付確認済み
複数ソース一致
要するに「難しい仕事にだけ追加の思考コストを使う」のが狙いだ。この条件設計が緩すぎると全件で発動し、厳しすぎると何のために入れたのか分からなくなる。後述するが、実際に運用したら使用率そのものをログで確認する。
出力は自由文章にしない — 構造化したフィールドで書かせる
deep_thinkに「よく考えてください」とだけ渡すのは避けたい。長い独り言が出てきても、次の処理で機械的に扱いにくいからだ。
そこで出力を構造化する。たとえば次の形だ。
deep_think({
"current_assessment": "",
"confirmed_facts": [],
"uncertainties": [],
"conflicting_evidence": [],
"missing_information": [],
"options": [],
"recommended_next_action": "",
"confidence": 0.0
})
特に重要なのはrecommended_next_actionだ。deep_thinkは考えて終わりではない。次に何をするのかまで決めさせて、ワークフローを前に進める。
[画像挿入：deep_thinkの構造化出力の構成が分かる画像]
具体的な動き — 発表日が食い違うニュースの処理例
「OpenAIが新モデルを発表した」というニュースを見つけたとする。ある記事では「8月21日に発表」、別の記事では「8月22日に公開」と書いていた。この場合、deep_thinkを呼ぶ。
結果として、次のような判断を返させる。
confirmed_facts:
- 新モデルが公開された
uncertainties:
- 正式な発表日時
conflicting_evidence:
- Source A: Aug 21
- Source B: Aug 22
missing_information:
- OpenAI公式発表
recommended_next_action:
- 公式サイトを確認する
confidence:
- 0.62
すると次の行動は「OpenAI公式サイトを検索」に明確に決まる。判断が曖昧なまま次の工程へ流れるのを防げるのが、この構造の利点だ。
verifyは別ツールにする — 考えることと検証することは目的が違う
最初はdeep_thinkですべてやらせてもいいと考えていた。しかし整理してみると、「考える」と「検証する」は目的が異なる。そこでverifyを独立させる。
ニュースの検証でverifyが見るのは、たとえば次の項目だ。
一次情報は確認したか
発表日は確認したか
記事公開日とイベント発生日を混同していないか
数字は一致しているか
引用元は実際にその内容を言っているか
古い情報を最新情報として扱っていないか
出力はこの程度で十分だ。
verify({
"primary_source_found": true,
"date_verified": true,
"factual_conflicts": [],
"unsupported_claims": [],
"status": "PASS"
})
statusはPASS・RESEARCH_MORE・REJECTの3値くらいに絞る。判定結果が単純なほど、後の集計やログ分析が楽になる。
planは3ステップ以上の複雑なタスクにだけ使う
planについても考えたが、これはすべてのタスクに使う必要はなさそうだ。3ステップ以上の複雑な仕事に限定する。
たとえば「このAIサービスについて機能・価格・対応モデル・API・競合を調べる」というタスクなら、次の流れにする。
plan
↓
公式サイト
↓
料金
↓
ドキュメント
↓
競合
↓
deep_think
↓
verify
一方、単純なニュース記事1件の処理ならplanは飛ばす。道具は目的に合わせて使うのが前提で、すべての工程にツールを押し込むとワークフローが重くなるだけだ。
PoCの最終構成 — 3つのツールに絞る理由
最初のPoCでは、次の3つだけで十分だと判断した。
plan()
deep_think()
verify()
役割は次のように分ける。
plan → どう調べるか
deep_think → どう判断するか
verify → 判断は正しいか
final_reviewなどは、必要になってから追加する。最初からツールを増やしすぎると、エージェントを賢くするための仕組みが、逆にエージェントを複雑にする、という本末転倒が起きそうだからだ。
[画像挿入：plan・deep_think・verifyの3ツール構成が分かる画像]
判断履歴をログに残す — 「なんとなく良くなった」を排除する
この実験では、ログ設計も重要だ。たとえばニュース1件ごとに、次のようなデータを残しておく。
{
"deep_think_used": true,
"reason": "source_conflict",
"additional_searches": 2,
"confidence_before": 0.58,
"confidence_after": 0.91,
"verify": "PASS"
}
なぜここまでやるのかと言うと、「なんとなく良くなった気がする」では意味がないからだ。効果を数字で語るには、比較できる形で記録を残す必要がある。
僕が欲しいのは大量の長文reasoningではない。何が不確かだったか、何を追加調査したか、何を根拠に採用したか、最終confidenceはいくつだったか、という判断履歴のほうだ。internalcotのような実装も、nativeなhidden reasoningを直接取得するのではなく、エージェント自身に明示的な可視メモを書かせる仕組みであり、この考え方とは相性がいい。
なぜシステムプロンプトの「もっと考えて」では不十分なのか
deep_thinkのようなツールを作らず、システムプロンプトに「常に深く考えてから回答してください」と書くだけでも、一見同じことができるように見える。
しかし、それでは次の情報がワークフローから分離できてしまう。
いつ追加検索したのか
なぜ追加検索したのか
何に不確実性を感じたのか
ツールにすると、行動の記録として残る。
Search
↓
Think
↓
Search
↓
Verify
この「考える」も1つの行動として履歴に載るのが大きい。AIエージェントをデバッグするとき、どのタイミングで何を判断したかを追えるのはかなりの利点だ。
エージェントの失敗箇所を特定できる — ログから原因を読む例
この設計の副次的な効果として、失敗の原因特定が楽になる。たとえば誤った記事を生成してしまったとする。
従来なら「なぜ間違えた?」と後から推測するしかなかった。しかしログに次の記録が残っていたらどうだろう。
confidence: 0.91
primary_source_found: false
verify: PASS
一次情報が見つかっていないのにverifyがPASSになっている。つまり問題は検索の工程ではなく、verifyの判断基準にある可能性が高い。
これは大きい。AIエージェントの失敗箇所を、感覚ではなく記録から特定しやすくなる。ツール化の価値は、考える場所を作ることだけではなく、考えた結果を観測可能にすることにもある。
この発想はHarness Engineeringとつながっている
最近のAI開発では、モデルそのものより、モデルを取り囲む仕組みを改善するという考え方が重要になっている。いわゆるHarness Engineeringの視点だ。
設計対象を挙げてみるだけでも、次の項目がある。
どんなツールを与えるか
どの情報をコンテキストに入れるか
いつ検索するか
どこで検証するか
どうログを残すか
同じモデルでも、この設計次第で結果は変わる。ARTのような以前からの研究でも、reasoningとtool useを組み合わせることで固定されたLLMの能力を引き出す方向が示されており、今回の実験はその延長線上にあると考えている。
最初のPoC — 50件でA/B比較する計画
最初から本番環境へ入れるつもりはない。まずはニュース50件程度を対象にする。同じモデル、同じニュース候補を使って、次の2系統を走らせる。
A: 現在のOpenClaw
B: deep_think + verify版
比較する項目は次のとおりだ。
正確性
重複
取りこぼし
検索回数
処理時間
トークン
コスト
ここまでやって初めて、deep_thinkは本当に意味があるのかを判断できる。工具を作って満足するのではなく、結果で判断する。
まとめ: ツールを作ることではなく、結果が良くなるかどうかが本質
この段階で決めたのは、plan・deep_think・verifyという3つの役割分担と、発動条件、構造化出力、判断履歴のログ設計だ。
ただし重要なのは、ツールを作ること自体ではない。それによって結果が良くなるかどうかだ。
もし精度がほとんど変わらず「トークン+40%・処理時間+35%」なら、採用する価値は薄い。逆に「誤情報-30%・重複-40%・コスト+8%」ならかなり魅力的だ。
次回は、どういう条件なら「効果があった」と判断するのか、実験方法そのものを設計する。
参考：morluto/internalcot、ART: Automatic multi-step reasoning and tool-use for large language models、RecThinker