Anthropicの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年末の更新で位置付けがどう変わったのか」を、原典の数値と実装パターンに沿って読み解いていきます。Claude / Agent SDK / MCP(モデルコンテキストプロトコル、外部サービスをClaudeに繋ぐ標準仕様)経由でツール駆動のエージェントを組んでいる読者を主な対象にします。

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

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

think toolは、この症状に対して「Claudeに『考える』というツールそのものを与える」という解き方を提案しています。実体は、特別な計算を一切しない、ただ思考内容をログに付け加えるだけのno-op(何もしない)ツールです。ところが、Claudeにとっては「このツールを呼び出すと、その引数として構造化された自分の考えを書き出してから次の行動に進める」という意味を持ちます。応答の本文ではなくツール呼び出しの引数として思考を書くことで、モデルは行動を選ぶ前に一拍置く挙動を獲得します。

このアプローチが面白いのは、推論能力の引き上げをモデル側の改造ではなく、ツールという「外形」の追加で実現しているところです。chain-of-thought(思考の連鎖、応答前に推論手順を書き出させる手法)が「応答テキストの前段に推論を埋め込む」発想だったのに対し、think toolは「ツール呼び出しの連鎖の途中に推論ステップを差し込む」発想と読めます。

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

think toolの定義は、驚くほどシンプルです。発表記事に掲載されている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を呼ばない、新しい情報を取得しない、と説明にも明記されています。

それでもこのツールが機能するのは、Claudeにとって「ツール呼び出しは行動である」という暗黙の認識があるためです。ツール呼び出しの引数を埋めるという行為自体が、応答テキストを生成するのとは別の経路で構造化された出力を強制します。thought フィールドに「いま自分が持っている情報」「適用すべきルール」「次に取るべき行動」を書き出すと、Claudeは行動を選ぶ前にそれらを点検する挙動に自然に切り替わります。

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

think toolの実効性を測ったのが、τ-bench(2406.12045として論文公開されているエージェント評価ベンチマーク)です。τ-benchは「ユーザー」「方針」「ツール」が組み合わさった現実的なシナリオでエージェントを評価する設計で、airline(航空券変更)とretail(小売返品)の2ドメインがあります。

airline domainで0.332 → 0.584は相対54%の改善幅に相当します。重要なのは、think toolを足すだけでは0.404にしか届かないという事実で、効果を最大化したのは**「think toolを使うべき場面と書くべき内容を指示した最適化プロンプト」を併用した条件**でした。ツールを置くだけでなく、ツールの使い方を教える側のプロンプト設計が大半を占める、というのが裏側のメッセージとして読めます。

SWE-bench(ソフトウェア工学タスクのベンチマーク)でもthink toolは効きました。Claude 3.7 Sonnetが達成した0.623という当時のstate-of-the-art(最高スコア)に対し、think toolの寄与は平均で1.6%の改善幅、サンプルサイズはthink toolあり30件 / なし144件、Welchのt検定でt(38.89) = 6.71, p < .001, d = 1.47 と報告されています。コード編集のような構造化されたタスクでも、効果サイズd=1.47は実務的に意味のある差分です。

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

think toolは万能ではなく、向き不向きがはっきりしています。発表記事の整理を元に、実務的な利用形態と影響度を早見表にまとめます。

特にairline domainでスコアが大きく動いたのは、航空券の変更ポリシー(変更可否、料金差額、上位クラス変更時の例外、未成年者の同伴規則など)が条文的に細かく、Claudeが一度立ち止まって「いま自分が選ぼうとしている行動が、本当に全部のルールに整合しているか」を検算する必要があったためと読めます。逆にretail domainの改善幅が小さい(0.783 → 0.812)のは、返品ロジックが相対的に単純で、もともとClaudeが安定して解けていたためと考えられます。

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

発表記事で目立つもう1つの論点が、think toolの使い方をどこに書くか です。原典は明確に、「指示が長く / 複雑な場合は、tool descriptionではなくsystem promptに書く方が効果的」と述べています。

理由は3つに整理できます。1つ目は、tool descriptionは「ツールの説明」として読まれる枠なので、長い手順や条件分岐を書くと不自然な情報密度になります。2つ目は、system promptは会話全体の方針として参照されるため、think toolを呼ぶたびに毎回再読される負荷が少なくなります。3つ目は、system promptには「ドメイン固有の例」を書きやすく、Claudeが「自分のドメインでthink toolをどう使うか」を学びやすくなります。

最適化プロンプトの典型構造として、発表記事では以下の4点を列挙することを推奨しています。

1. 適用すべきルールの明示 — いまのリクエストに関係する方針条文を、tool呼び出しの直前に列挙
2. 必要情報の収集確認 — 行動に必要な情報が全部揃っているかのチェックリスト
3. コンプライアンス検算 — 予定している行動が、すべての方針に整合するかの自己検証
4. ツール結果の反復確認 — 前のツール呼び出しの結果に対し、思い違いがないかを点検

この4点は、人間のシニアエンジニアが複雑な意思決定をする前に頭の中でやっている「自己レビュー」をそのまま明文化したものです。think toolはClaudeに、その手順を「考えるという行動」として実行させるための足場と読むことができます。

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

think toolとよく対比されるのが、Anthropicが2025年初頭から展開しているextended thinking(拡張思考、応答前に長い推論を書き出させる機能)です。両者は似て非なるもので、発表記事は使い分けを明示しています。

直感的には、「走り出す前に1回深く考える」のがextended thinking、「走りながら必要な箇所で立ち止まる」のがthink tool、と整理できます。最初の計画立案がボトルネックの問題(複雑なアルゴリズムの実装、長い数学証明など)ではextended thinking、計画自体は単純でも実行中に未知情報が次々入ってくる問題(エージェントによる業務処理など)ではthink toolが向いている、という棲み分けになります。

なお、Claude OpusのIntegrated thinking effortにはxhighという最大設定が用意されており、こちらはextended thinkingの出力上限を引き上げる方向の機能です。詳細はClaude Opus 4.7のxhigh設定で扱っています。

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

think toolにとって重要な事実として、発表記事には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を使うことを推奨します」となります。

この更新は、think tool自体を否定するものではなく、extended thinkingがthink toolの主な利点を吸収する形で進化したという整理と読めます。実装の手間(no-op toolを別定義する、prompt側で使い方を仕込む、両方ともコンテキストの一部としてトークンを消費する)を考えると、モデル側で同等のことができるならそちらの方が運用上は単純です。

ただし、すべてのユースケースがextended thinkingで代替できるわけではないと考えられます。たとえば、tool呼び出しの結果をログに残したい / 思考過程を後で監査したい / think tool呼び出しのタイミングをプロンプトで明示的に制御したい、といった運用要件がある場合は、think toolの構造の方が明示的でデバッグしやすい側面があります。発表記事の本文部分が引き続き残っているのも、こうした選択肢を読者に開いておく意図があるとも読めます。

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

think toolという発想そのものは、Anthropicのagent設計思想を象徴する事例だと考えられます。記事を全体として読むと、3つの設計原理が透けて見えます。

1. モデル能力の引き上げは、必ずしもモデル本体の改造では行わない — ツールという外形を変えるだけで、推論挙動が定性的に変わる
2. ツールはClaudeに対するUI — 同じno-opでも、呼び出すという行為が思考プロセスを構造化する効果を持つ
3. プロンプトとツール定義はセットで設計する — think toolを置くだけでは効かず、いつどう使うかを教えるプロンプトが本体

この思想は、Anthropicが続けて公開しているエージェント向けツール設計の原則やAdvanced Tool Use、効果的なコンテキストエンジニアリングとも一貫しています。ツールはモデルにとっての「能力拡張点」ではなく「思考の足場」として設計する、という見方は、think toolが2025年3月の時点で先取りしていたと言えそうです。

Agent Skillsやmanaged agentsのような、より構造化されたエージェント設計手法が登場した2025年後半の流れも、think toolが提示した「ツール定義 + プロンプト + モデルの3点セットで挙動を作る」という方向性の延長線上にあると読めます。

まとめ — いつthink toolを思い出すべきか

• 新規にツール駆動エージェントを組むなら、まずはextended thinkingを試して、それでも逐次判断の足りなさが残る場面でthink toolを足す、という順序が推奨されそうです
• すでにthink toolで本番運用している場合、無理に剥がす必要はなく、運用上のデバッグ性や監査性で利点があれば継続する選択肢があります
• ポリシー判定の厳密さが業務要件にある場合(航空 / 金融 / 医療など)、think tool型の「立ち止まって考える」構造は、extended thinkingでは代替しきれない場面が残ると考えられます
• think toolを実装する場合は、tool descriptionだけで済ませず、system promptに使い方を書くことを忘れずに。τ-benchの実験結果が示すように、プロンプト側の作り込みが結果を大きく左右します

think toolは、シンプルなno-opツールを足すだけで複雑なエージェントの挙動が一段安定する、という驚きを残した発表でした。2025年末のupdateで「extended thinkingで代替可能」と位置付けが整理されたいまも、ツール設計と推論挙動の関係を考える上での原点として読む価値が残っている記事です。