実験の問い — 考えるツールはエージェントを本当に賢くするのか
第1回では、deep_thinkというアイデアから「AIエージェントに考える場所を与えたらどうなるか」を考えた。第2回では、plan・deep_think・verifyという3つの処理をOpenClawへ追加する設計をまとめた。
ただし、ここまですべて仮説だ。肝心なことがまだ分かっていない。「それ、本当に意味あるの?」という問いに、今回から取り組む。
本記事で設計するのは、効果を主観ではなく数字で確認するための実験だ。この時点では性能改善を確認したものではなく、実測結果が得られた段階で追記か続編として公開する予定である。
[画像挿入：A/Bテストの全体構成が分かる画像]
「賢くなった気がする」を禁止にする — 評価の基本原則
AIの評価で一番危険なのは「前より賢い気がする」という感想だ。何件か試して「おお、ちゃんと考えてる」となっても、それだけでは何も証明されていない。
deep_thinkを入れれば、当然ログ上ではたくさん考えているように見える。しかし、長く考えていることと、正しいことは別だ。
AnthropicによるCoT研究でも、モデルが書き出すreasoningが実際の判断要因を完全に忠実に表すわけではないことが示されている。だから今回は、過程の見た目ではなく最終結果だけを見る。これを実験の基本原則とする。
AとBを作る — 比較対象の構成と守るべき条件
比較するのは2パターンから始める。
Aは通常版、現在のOpenClawだ。
ニュース発見
↓
取得
↓
評価
↓
記事生成
BはThinking Tools版で、deep_thinkとverifyを挟む。
ニュース発見
↓
取得
↓
必要ならdeep_think
↓
追加調査
↓
verify
↓
評価
↓
記事生成
重要なのは、使うモデルを同じにすることだ。モデルまで変えてしまったら、結果が「deep_thinkが効いた」のか「モデルが強くなった」のかの区別がつかなくなる。比較実験では変数を1つに絞るのが鉄則だ。
同じ50件を処理させる — テストデータの偏らせ方
まずニュース候補を50件用意し、AとBの両方に同じ50件を渡す。
このとき、できるだけ次のような難易度の混ざった構成にしたい。
明らかに簡単なニュース
一次情報があるニュース
複数サイトで内容が違うニュース
発表日が曖昧なニュース
似た記事が大量に出ているニュース
重要度判定が難しいニュース
理由は単純で、簡単な問題しか入れていなければdeep_thinkを追加しても差が出ないからだ。差が出る場所を意図的に含めることも、実験設計の一部だ。
測定する7つの項目
今回測るのは次の7項目だ。重要度順に並べ、それぞれ見方を整理する。
1. 事実誤認率
2. 一次情報到達率
3. 重複率
4. 重要ニュースの取りこぼし
5. 検索回数
6. トークン・コスト
7. 処理時間
各項目の定義と判断基準を以下に示す。
[画像挿入：測定7項目の一覧と見方が分かる画像]
1. 事実誤認率 — 最重要の品質指標
最重要項目。日時・製品名・会社名・価格・対応モデル・仕様などに誤りがないかを確認する。たとえば50件中5件に誤りがあれば事実誤認率は10%だ。deep_thinkの有無でこの数字がどう動くかが、実験の中心になる。
2. 一次情報到達率 — verifyの効き目を見る
ニュース記事だけを読んで終わったのか、公式ブログ・公式ドキュメント・GitHub・論文・企業発表まで到達したのかを測る。verifyを入れることでこの到達率が改善するなら、ツール化の意味は大きい。
3. 重複率 — 同一イベントの重複採用を数える
AIニュースでは重複が問題になりやすい。「OpenAIが新機能発表」「GPTに新機能」「ChatGPTアップデート」「OpenAI rolls out new feature」が全部同じニュースという場合がある。これを4件として扱えば重複だ。deep_thinkによる「これは既存ニュースと同じイベントでは?」のチェックが機能するかを見る。
4. 重要ニュースの取りこぼし — 誤採用との両輪
精度ばかり狙って「怪しいから捨てる」を繰り返しても意味がない。本来採用すべきニュースを何件落としたかも測る。誤採用と取りこぼしの両方を見て、初めてバランスの取れた評価になる。
5. 検索回数 — 考えすぎのコストを測る
deep_thinkが「もう十分調べた」と判断できれば検索回数は減る可能性がある。逆に「念のためもう一件」を繰り返せば増える。たとえばAが平均4.2検索、Bが平均6.8検索なら、精度改善と引き換えにかなりのコストを払っていることになる。
6. トークンとコスト — 取得できる範囲で全記録
Input tokens、Output tokens、Reasoning、Tool callなど、取得できる範囲で記録する。Aを100としたときBが112なら12%増だ。それで誤情報が大幅に減るなら許容できるかもしれないが、「コスト+60%・精度+2%」なら採用は微妙になる。
7. 処理時間 — 往復が増える影響
deep_thinkを挟むたびにLLMとツールの往復が増える。ニュース50件なら大した差ではなくても、1日数百件になれば無視できない数字になる。エージェントでは意外と重要な指標だ。
deep_thinkの使用率も見る — 条件設定の妥当性チェック
Bではもうひとつ、deep_think_usage_rate（使用率）を記録する。
たとえば50件中8件だけ使われたなら使用率は16%だ。もし精度が上がっているなら、「難しい16%だけ追加で考えればいい」非常に効率的な仕組みだと言える。
逆に50件中50件すべてで使われていたら、第2回で設計した発動条件が緩すぎる可能性がある。使用率は、ツールの設計そのものの健全性を教えてくれる指標だ。
confidenceは信用できるのか — 自己申告の校正
deep_thinkにはconfidence_beforeとconfidence_afterを記録させる。
たとえば「before 0.55 → 追加検索 → after 0.92」となったとする。本当にその案件の正解率も高くなっていれば、confidenceは運用上の判断材料として使える。
しかし「confidence 0.95 → 間違い」が頻発するなら、confidenceそのものに意味がない。モデルの自己評価が実際の正誤とどれだけ一致するかは、実際の運用でもかなり重要な発見になるはずだ。
「成功」と呼ぶラインを先に決める
結果を見てから「これは成功!」と言うと、自分に都合よく評価してしまう。そこで基準を実験の前に決めておく。
僕ならひとつの目安として次を設定する。
事実誤認: 20%以上改善
重複: 20%以上改善
重要ニュース取りこぼし: 悪化しない
追加コスト: 20%以内
すべてを満たす必要はないが、品質向上とコスト増のバランスで判断する。先に線引をしておくことが、後からのこじつけを防ぐ一番簡単な方法だ。
C（プロンプト強化版）も比較する — ツール化の意味を試す
余裕があれば、3つ目の比較対象も作れる。ツールを追加せず、システムプロンプトに次のように書くだけのCだ。
重要な判断では
十分に検討し、
事実確認をしてから進んでください
これでA（通常）・B（deep_think + verify）・C（プロンプトだけ強化）を比較できる。
この比較はかなり重要だ。BとCがほぼ同じなら、わざわざツールを実装する意味は薄い。一方でBがCを大きく上回るなら、「考えろ」と言うだけではなく、考える工程をツールとして分離すること自体に意味がある、という可能性が出てくる。
弱いモデル＋良いワークフローは、強いモデルに迫れるのか
実は今回、単純な精度向上以上に知りたいことがある。「弱いモデルでもワークフローを良くすれば、強いモデルに近づけるのか?」という問いだ。
たとえば「強いモデル＋単純なAgent」と「少し弱いモデル＋plan＋deep_think＋verify」を比較する。
もし後者が近い性能を出せるなら面白い。APIコストを抑えながら、エージェント全体の品質を上げられる可能性がある。
tool-augmented reasoningによってモデルの能力を補助する方向は以前から研究されており、ARTでは固定されたLLMにreasoningとtool useを組み合わせることで複数タスクの性能向上が報告されている。最近のエージェント研究でも、情報の不足を判断して自律的に追加ツールを利用する設計が研究されている。この実験は、その問いの個人運用版と言える。
モデル競争の次は「エージェント設計競争」かもしれない
AI界隈では毎週のように新モデル・新ベンチマーク・新しいreasoning性能が話題になる。もちろんモデル性能は重要だ。
しかしAIを実際の仕事で使うと、それだけではないことが分かってくる。次の要素もすべて結果に影響する。
検索能力
コンテキスト
メモリ
ツール
検証
リトライ
権限管理
ログ
停止条件
モデルが「脳」なら、エージェント設計は仕事場そのものと言ってもいいかもしれない。仕事場の設計を競う時代が来る、というのがこの連載を通しての仮説だ。
効果が出た場合の展開 — 他のエージェントへの応用
もし効果が確認できたら、ニュース収集だけではなく別のエージェントにも使える。
商品データ収集なら、「複数サイトで重量が違う」「発売年が違う」「同名モデルが存在する」「公式スペックが見つからない」というときだけdeep_thinkを呼ぶ。
コーディングエージェントなら、「修正方法が複数ある」「影響範囲が大きい」「テストが失敗した」「既存設計と矛盾する」というときだけ考えさせる。
つまりdeep_thinkというツールそのものより、「いつ深く考えるべきか」をエージェント自身が判断する仕組みのほうが重要になるのかもしれない。
まとめ: 試して、測って、分かったことを残す
この3話は、1つのXポストから始まった。最初は「隠されたAIの思考が見える?」という話だった。そこから「考える場所を外部ツールとして用意できるのでは?」と考え、plan・deep_think・verifyというエージェント設計へ発展した。
そして最後に辿り着いたのは、「本当に効果があるなら、数字で確認しよう」という当たり前のところだ。
現時点での答えは「分からない」。それが正しいと思う。面白いアイデアであり、理屈も通り、類似研究も存在する。でも、自分のOpenClawに効果があるかは別問題だ。だから実際に測る。
結果が「効果なし」でも十分面白い。「AIに考えるツールを与えれば賢くなると思ったけど、実際はほとんど変わらなかった」という結果も立派なラボノートになる。ラボなので、成功する必要はない。試して、測って、分かったことを残す。
参考：Can Bölük氏による元ポスト（https://x.com/_can1357/status/2090837707069014224）、morluto/internalcot、ART: Automatic multi-step reasoning and tool-use for large language models、RecThinker: An Agentic Framework for Tool-Augmented Reasoning in Recommendation、Reasoning Models Don't Always Say What They Think
なお本記事は実験前の設計段階であり、性能改善を確認したものではない。実測結果が得られた段階で追記、または続編として公開する予定だ。