think toolとは — Claudeに考える間を与える設計とextended thinkingの使い分け

Anthropicのengineeringブログが2025年3月20日に公開した「The 'think' tool: Enabling Claude to stop and think in complex tool use situations」は、Claudeに応答生成の途中で立ち止まって考えるための専用領域を持たせる設計を提示した記事です。ツール呼び出しの連鎖が長い、ポリシー遵守が重い、過去のツール出力を踏まえた逐次判断が必要、といった状況が対象です。think toolと最適化プロンプトを足すと、τ-bench(エージェント評価ベンチマーク)のairline domainスコアが0.332から0.584まで上がった、というのが中核メッセージです。

本記事では、think toolが何を解いているのか、extended thinkingと何が違うのか、どう実装するのかを、原典の数値と実装パターンに沿って読み解きます。あわせて、2025年12月の更新と現行のthinking仕様を踏まえて、いまどこまで使える設計なのかも扱います。Claude / Agent SDK / MCP(モデルコンテキストプロトコル、外部サービスをClaudeに繋ぐ標準仕様)経由でツール駆動のエージェントを組んでいる読者が主な対象です。

背景 — 「考える間」を切り出すという発想

LLMエージェントが複雑な業務を扱うと、決まって同じ症状が出ます。ツール呼び出しが3回4回と続くにつれて、過去のツール出力を踏まえた判断がブレる。ポリシーで禁じられているはずの操作を選んでしまう。複合条件を満たすかの照合を雑に済ませてしまう。いずれも思考の浅さに由来する失敗です。

think toolは、この症状に「Claudeに『考える』というツールそのものを与える」という形で応えます。実体は特別な計算を一切しないno-op(何もしない)ツールで、思考内容をログに付け加えるだけです。応答の本文ではなくツール呼び出しの引数として思考を書かせることで、行動を選ぶ前に一拍置く場ができます。

面白いのは、推論の引き上げをモデルの改造ではなくツールという外形の追加で実現している点です。chain-of-thought(思考の連鎖、応答前に推論手順を書き出させる手法)が応答テキストの前段に推論を置くのに対し、think toolはツール呼び出しの連鎖の途中に推論ステップを差し込みます。

think toolの仕様 — 何もしないツールが効く理由

発表記事に載っているのは、τ-benchの標準環境で使われているJSON Schema形式の定義です。

{
  "name": "think",
  "description": "Use the tool to think about something. It will not obtain new information or change the database, but just append the thought to the log. Use it when complex reasoning or some cache memory is needed.",
  "input_schema": {
    "type": "object",
    "properties": {
      "thought": {
        "type": "string",
        "description": "A thought to think about."
      }
    },
    "required": ["thought"]
  }
}

入力は thought という文字列1つだけで、アプリ側がやるのはその文字列を会話ログに追加することだけです。データベースを変更せず、外部APIも呼ばず、新しい情報も取得しないと説明文に明記されています。

SWE-bench(ソフトウェア工学タスクのベンチマーク)の評価では、同じ形のツールが別の説明文で使われています。「リポジトリを調べてバグの原因を見つけたら、このツールで修正案を複数ブレインストームし、最も単純で効果的なものを評価する」「テスト結果を受け取ったら、失敗の直し方を考える」という使いどころが、descriptionに具体例として書き込まれています。入力の構造は同じで、thought のdescriptionが「Your thoughts.」に変わるだけです。ドメインごとにdescriptionで「いつ何を書くか」を教える作りだと分かります。

ベンチマーク数値 — どのドメインでどれだけ効いたか

τ-bench(論文はarXiv 2406.12045)は、シミュレートされたユーザーと対話し、長いポリシー文書に従い、データベースを操作するツールを使うカスタマーサービスの評価です。airline(航空会社)とretail(小売)の2ドメインがあります。指標のpass^kは「同じタスクをk回試行して、すべて成功する確率」で、1回でも当たればよいpass@kと違い、一貫性を測ります。

retail domainではthink tool単体が0.812で、ベースラインの0.783、extended thinkingの0.770を上回りました。

54%という改善率の読み方

発表記事の本文は「airlineで0.570、ベースラインは0.370、相対54%の改善」と書いています。一方、同じ記事の表に載る値は0.584と0.332で、この2つから計算すると相対改善は約76%になります。本文と表で数字が一致していないので、「54%」を引用するときは本文の0.570 / 0.370の組とセットで書くのが安全です。この記事では表の値を使います。

試行回数を増やすと何が起きるか

pass^kは、kを増やすほど厳しい指標になります。airline domainのk=1からk=5までの値を並べると、構成ごとの差の質が見えてきます。

プロンプトを付けた構成は、5回すべて成功する率でも0.340を保ちました。ベースラインの0.100の3倍を超えます。対して、think tool単体はk=1で0.404あっても、k=5ではベースラインと同じ0.100まで落ちます。ツールを置いただけでは、1回あたりの成功率が上がっても毎回安定して成功する状態にはならない、ということです。原典も、改善がk=5まで維持されたことをプロンプト併用構成の特徴として挙げています。

retailのk=5は、think tool 0.626、ベースライン0.583、extended thinking 0.548でした。差はairlineより小さい一方、think toolが最上位という並びはk=1から変わりません。

SWE-benchでの効果

SWE-benchでは、think toolを含む設定でClaude 3.7 Sonnetが0.623の最高スコアを出しました。think toolだけを切り出した実験では、サンプルがthink toolあり30件・なし144件で、平均1.6%の改善、Welchのt検定でt(38.89) = 6.71、p < .001、d = 1.47と報告されています。

数値はどのモデルの話か

ここまでの数値はすべて、発表時点のClaude 3.7 Sonnetでの結果です。原典の脚注は、Claude 3.5 Sonnet(New)でも同じ構成で改善が出たと書いています。現行のモデルでthink toolが同じ幅で効くかどうかは、この数値からは言えません。次節以降で見るとおり、Anthropic自身が現在はextended thinkingを勧めています。

think toolが効く場面と効かない場面

原典が効くと挙げているのは3つの場面です。ツール出力を慎重に読み、方針を引き返す可能性があるとき。詳細なガイドラインへの準拠を確かめるとき。各行動が前の行動の上に積み上がり、ミスが高くつく逐次判断のときです。効かないと挙げているのは、単発または並列のツール呼び出しと、制約の少ない単純な指示追従です。

airlineでスコアが大きく動いた理由について、原典は「airlineのポリシーが複雑で、考え方の例を与えられたことが最も効いたと思われる」と述べています。プロンプトの例に出てくる規則は具体的です。予約から24時間以内ならキャンセルできる。そうでなければ運賃クラスと保険を確認する。支払い手段は旅行券1枚・クレジットカード1枚・ギフトカード3枚までで、すべてプロフィールに登録済みのものに限る。こうした条文を1つずつ検算する場面で、考える場が効いたということです。retailの改善幅が小さい(0.783 → 0.812)のは、原典の言葉では「ポリシーがより容易で、追加の指示なしでも考える場を持つだけで改善できた」ためです。

プロンプト設計 — どこに書くかで結果が変わる

発表記事のもう1つの論点は、think toolの使い方をどこに書くかです。原典は、指示が長いまたは複雑な場合、tool descriptionよりsystem promptに書いた方が効果的だったと述べています。理由として原典が挙げているのは、システムプロンプトの方が広い文脈を与え、思考過程をモデルの振る舞い全体に組み込みやすいという点です。

最適化プロンプトの骨格は、ツール結果を受け取ったあと、行動やユーザーへの返答の前にthink toolをスクラッチパッドとして使い、次の4点を書かせる形です。

## Using the think tool
Before taking any action or responding to the user after receiving tool results,
use the think tool as a scratchpad to:
- List the specific rules that apply to the current request
- Check if all required information is collected
- Verify that the planned action complies with all policies
- Iterate over tool results for correctness

この骨格のあとに、2つの作業例が <think_tool_example_1> のようなタグで続きます。1つはフライトのキャンセル依頼で、必要な情報(ユーザーID・予約ID・理由)とキャンセル規則を箇条書きにし、最後に計画を立てる例です。もう1つは3人分の航空券と各2個の預け荷物の予約で、会員ランクごとの無料手荷物枠から超過料金を計算し、支払い規則を確かめる例です。ルールの列挙、情報の過不足確認、方針との照合、前のツール結果の再点検という手順が、実際の依頼に即した書き方で見えるようになっています。

原典はドメイン固有の例に含める要素として、思考の詳細さ、複雑な指示を実行可能な手順に分解する方法、よくある場面の判断木、必要情報が揃ったかの確かめ方の4つを挙げています。

extended thinkingとの違い — 「前」か「途中」か

発表記事は、think toolとextended thinking(拡張思考、応答前に長い推論を書き出させる機能)を別物として区別しています。

つまり、最初の計画立案が難所ならextended thinking、計画は単純でも実行中に未知の情報が次々入る処理ならthink tool、という棲み分けでした。ただしこの区別は、現行の仕様では前提が変わっています。

いまのextended thinkingは「応答の前」だけではない

現行のthinking仕様では、ツール呼び出しの間にも思考を挟めます。interleaved thinking(ツール呼び出しの間の思考)といい、ツール結果を踏まえて次の行動を決める前に推論したり、複数のツール呼び出しを推論でつないだりできます。adaptive thinking(Claudeが思考の要否と深さを判断する方式)では自動で有効になり、ベータヘッダーは要りません。Claude Opus 5.5・Opus 5・Sonnet 5.5・Fable 5.1・Opus 4.8・Opus 4.7などでは、ツール間の推論が常にthinkingブロックとして現れます。Claude Haiku 4.5はinterleaved thinkingに対応していません。

発表時の「extended thinkingは応答の前、think toolは途中」という対比のうち、「途中」の役割は、いまではモデル側の機能がかなり引き受けています。2025年12月の更新注記は、この変化の反映です。

手動のextended thinkingは新しいモデルでは使えない

用語の整理も必要です。thinking: {type: "enabled", budget_tokens: N} で予算を指定する手動のextended thinkingは、Claude 4.6系では非推奨で、Opus 4.7・4.8、Opus 5以降などの新しいモデルではこの指定が400エラーになります。これらのモデルでは、thinking: {type: "adaptive"} で思考の深さを effort で調整する方式が前提です。Claude Opus 4.8・4.7・4.6とSonnet 4.6ではadaptiveを明示するまで思考がオフで、Opus 5.5・Opus 5・Sonnet 5.5・Fable 5.1などでは最初から有効です。

effortの出発点はモデルごとに異なります。Claude Opus 4.7と4.8はコーディングやエージェント用途で xhigh から、Claude Opus 5とFable 5.1は既定の high から始める案内です。effortは、extended thinkingの上限を引き上げる設定ではなく、知能・遅延・コストのバランスを決める別のパラメーターです。xhighの詳細はClaude Opus 4.7のxhigh設定、computer useでの設定の違いはComputer Useのeffort推奨値にあります。

2025年末の更新 — 「extended thinkingを使ってください」

発表記事には、2025年12月15日付けのupdate noteが追記されています。原文は次のとおりです。

Extended thinking capabilities have improved since its initial release, such that we recommend using that feature instead of a dedicated think tool in most cases.

意訳すると、extended thinkingの能力は初回リリース以降に改善されており、ほとんどの場面で専用のthink toolではなくextended thinkingを使うことを推奨する、となります。続けて、extended thinkingは同様の利点を、より良い統合と性能で提供するとも書かれています。

この更新は、think tool自体の否定ではありません。extended thinkingがthink toolの主な利点を吸収する形で進化した、という整理です。no-opツールを別に定義し、プロンプトで使い方を仕込む手間を考えれば、モデル側で同等のことができるならそちらが単純です。

それでもthink toolの構造が残す利点はあります。現行のモデルでは、思考テキストの扱いが display の設定で変わります。Claude Opus 5.5・Opus 4.8・Opus 4.7・Fable 5.1などは既定が "omitted" で、thinkingブロックの thinking フィールドが空で返ります。"summarized" にしても返るのは要約で、生の思考ではありません。一方、think toolの thought は通常のツール呼び出しの引数としてアプリ側に届くため、ログや監査にそのまま残せます。思考の内容を後から追いたい要件があるなら、これが選ぶ理由になります。

extended thinkingを使う場合は tool_choice の指定にも注意が要ります。手動のextended thinkingでは auto と none しか使えず、any や特定ツールの指定はエラーです。adaptive thinkingでは強制的なツール使用も使えますが、Opus 5.5・Sonnet 5.5・Fable 5.1・Mythos 5.1は例外です。原因と代替手段は「tool_choice: any」と拡張思考が同時に使えない理由に書いています。

編集視点 — think toolが残したもの

think toolは、ツールの形がモデルの推論の使われ方を変える、という発想を具体的な数値で示した事例です。ここから読み取れる設計原理は3つあります。

1. モデル本体を変えずにツールの外形を足すだけで、推論の挙動が変わる
2. no-opでも、ツールとして呼び出す形をとることで思考が構造化される
3. ツール定義とプロンプトはセットで設計する。単体のthink toolは0.404、プロンプト併用は0.584だった

この発想は、Anthropicが続けて公開しているエージェント向けツール設計の原則、Advanced Tool Use、効果的なコンテキストエンジニアリングと同じ方向にあります。Agent Skillsやmanaged agentsのように、ツール・プロンプト・モデルを組み合わせて挙動を作る設計手法も、同じ流れの先にあります。

まとめ

新しくツール駆動のエージェントを組むなら、まずextended thinking(新しいモデルではadaptive thinkingとeffort)で試し、それで足りない逐次判断の場面にだけthink toolを足す、という順序が原典の更新注記と整合します。すでにthink toolで運用している場合は、思考の記録をアプリ側のログに残したいという理由があるうちは、そのまま使い続けられます。いずれの場合も、効果を左右したのはツールの有無より、system promptに書いた考え方の例でした。