Think Tool とは何か — Extended Thinking との決定的な違い
Claude API を使ったエージェント開発で、ツール呼び出しの精度を劇的に向上させる手法として注目されているのが Think Tool パターン です。Anthropic のエンジニアリングチームが公開したこの手法は、エージェントが複数のツールを連続して使用する際に「立ち止まって考える」ステップを挟むことで、判断精度を大幅に改善します。
「Extended Thinking と何が違うのか?」という疑問を持つ方は多いでしょう。両者は名前こそ似ていますが、動作するタイミングが根本的に異なります。
Extended Thinking は、Claude がレスポンスを生成する前に 行われる深い推論プロセスです。thinking パラメータで有効にすると、Claude は回答を出す前に内部で思考チェーンを展開します。
Think Tool は、Claude がレスポンスを生成する途中で 使用するツールです。複数のツール呼び出しの合間に「今の状況を整理し、次に何をすべきか」を明示的に推論するステップとして機能します。
// Think Tool の定義 — シンプルながら強力
const thinkTool = {
name: "think" ,
description:
"Use this tool to think about the information you have gathered " +
"and plan your next steps. Use it when you need to analyze data, " +
"consider multiple options, or reflect on tool results before proceeding." ,
input_schema: {
type: "object" as const ,
properties: {
thought: {
type: "string" ,
description: "Your detailed reasoning and analysis" ,
},
},
required: [ "thought" ],
},
};
このツールが呼び出されても、実際にはサーバー側で何も処理を行いません。Claude が自分自身の思考をテキストとして出力し、それをコンテキストに残すことで、後続の判断に活用する仕組みです。
なぜ Think Tool が必要なのか — エージェントの判断精度の壁
複雑なエージェントワークフローでは、Claude が複数のツールを連鎖的に呼び出すことがよくあります。例えば、カスタマーサポートエージェントが「顧客情報を取得 → 注文履歴を確認 → ポリシーを参照 → 返金を実行」という一連の処理を行う場合です。
ここで問題になるのが、ツール呼び出しの連鎖が長くなるほど、各ステップでの判断精度が低下する ことです。これは人間でも同じで、複数の情報を同時に処理しながら次の行動を決めると、見落としや判断ミスが起きやすくなります。
Anthropic のエンジニアリングブログ The "think" tool: Enabling Claude to stop and think in complex tool use situations に、τ-bench を用いた検証データが公開されています。
航空会社カスタマーサービス : pass^1 メトリクスが 0.370 → 0.570 に向上(54% の相対改善 )
小売カスタマーサービス : pass^1 メトリクスが 0.783 → 0.812 に向上(約 3.7% の相対改善)
この 2 つの数字の差が、そのまま Think Tool の適用条件を表しています。54% という値が独り歩きしがちですが、これはドメイン固有の思考例をシステムプロンプトに埋め込んだ場合の測定値です。ツール定義を追加しただけでは、ここまでの改善には届きません。小売ドメインの伸びが 3.7% に留まったのは、返品可否の判断が航空会社の運賃規則ほど多段階ではないからだと読み取れます。
つまり Think Tool が効くのは、判断が多段階で、かつ誤ると取り返しがつかない領域 です。検索と要約を繰り返すだけのエージェントに入れてみたことがありますが、レイテンシとトークン消費が増えた実感だけが残り、出力の質が変わった手応えはありませんでした。導入前に「このエージェントの判断は何段階あるか」を数えておくと、期待値を見誤らずに済みます。
航空会社のようにポリシー判断が複雑なドメインで効果が顕著なのは、Think Tool によって Claude が「この顧客は返金ポリシーのどの条件に該当するか」を明示的に推論してから行動に移せるためです。
Think Tool のサーバー側実装
Think Tool の最大の特徴は、サーバー側の処理が極めてシンプルなことです。ツールが呼び出されたら、思考内容をそのまま返すだけで完了します。
import Anthropic from "@anthropic-ai/sdk" ;
// Anthropic クライアント初期化
const client = new Anthropic ();
// エージェントループの実装
async function runAgentLoop (
userMessage : string ,
tools : Anthropic . Tool []
) : Promise < string > {
const messages : Anthropic . MessageParam [] = [
{ role: "user" , content: userMessage },
];
while ( true ) {
const response = await client.messages. create ({
model: "claude-opus-4-6" ,
max_tokens: 8096 ,
tools: tools,
messages: messages,
});
// レスポンスをメッセージ履歴に追加
messages. push ({ role: "assistant" , content: response.content });
// stop_reason が "end_turn" ならループ終了
if (response.stop_reason === "end_turn" ) {
const textBlock = response.content. find (
( block ) => block.type === "text"
);
return textBlock?.text ?? "" ;
}
// ツール呼び出しの処理
const toolResults : Anthropic . ToolResultBlockParam [] = [];
for ( const block of response.content) {
if (block.type === "tool_use" ) {
if (block.name === "think" ) {
// Think Tool: 思考をそのまま結果として返す
// サーバー側では何も処理しない
toolResults. push ({
type: "tool_result" ,
tool_use_id: block.id,
content: `Thought recorded: ${ ( block . input as { thought : string }). thought }` ,
});
} else {
// 通常のツール: 実際の処理を実行
const result = await executeExternalTool (block.name, block.input);
toolResults. push ({
type: "tool_result" ,
tool_use_id: block.id,
content: result,
});
}
}
}
// ツール結果をメッセージ履歴に追加
messages. push ({ role: "user" , content: toolResults });
}
}
重要なポイントは、Think Tool の結果をコンテキストに残すことです。Claude は次のツール呼び出しを決定する際に、過去の Think Tool の出力を参照できるため、より文脈に即した判断が可能になります。
効果的なシステムプロンプト設計
Think Tool の精度を最大化するには、システムプロンプトで Claude に「いつ、どのように think ツールを使うか」を明確に指示する点が肝心です。
const systemPrompt = `あなたはカスタマーサポートエージェントです。
## Think Tool の使用ガイドライン
以下の状況では、必ず think ツールを使用してから行動してください:
1. **ツール結果の分析時**: ツールから返されたデータを解釈する必要がある場合
2. **ポリシー判断の前**: 返金・キャンセル・例外処理などのポリシーを適用する前
3. **複数の選択肢がある場合**: 次のアクションに複数の候補がある場合
4. **矛盾する情報がある場合**: 顧客の申告とシステムデータが一致しない場合
5. **最終回答の直前**: 顧客への回答を生成する前に、全体を振り返る
## Think Tool の使い方
think ツールを呼び出す際は、以下の構造で思考を整理してください:
- 現在わかっていること
- まだ不明なこと
- 次に取るべきアクションとその理由
- リスクや注意点` ;
このように構造化された指示を与えることで、Claude は適切なタイミングで Think Tool を使用し、思考の質も向上します。
Think Tool を使わないほうがよい場面
システムプロンプトに「使うべき場面」だけを書くと、Claude はあらゆるツール呼び出しの前に think を挟むようになります。レイテンシとトークンだけが増えて、判断の質は変わりません。「使わない場面」を明示する数行が、実は同じくらい効きます。
const systemPrompt = `(前略)
## Think Tool を使わない場面
次に取るべき行動が自明な単純ステップでは、think ツールを使わないでください。
たとえば顧客が注文状況を尋ねただけで get_order を呼べば済む場合は、
思考を挟まずそのまま get_order を呼び出してください。` ;
一歩進んだやり方として、受け取ったリクエストの複雑さに応じてシステムプロンプトを差し替える方法があります。注文状況の照会のような単純な問い合わせには think の使用を抑制する軽量プロンプトを、欠航補償のように複数のポリシーが絡む問い合わせには各判断点での推論を促す詳細プロンプトを与えます。
個人開発の規模でエージェントを回していると、think の呼び出し回数はそのまま月末の請求額に跳ね返ります。「使わない場面」を書くのはコスト対策でもあり、判断の質を守る手立てでもある。両方の目的が同じ数行に収まっているわけです。
分岐の判定材料は、最初のユーザー発話に含まれる語で足ります。厳密な分類器を用意するより、「補償」「例外」「キャンセル」といった語の有無で 2 系統に分けるところから始めるほうが、運用の手応えを早く掴めます。誤分類が起きても、軽量側に落ちた重い問い合わせは Claude が自発的に think を呼ぶことが多く、実害は思ったより小さいというのが私の感触です。
本番環境での設計パターン — 3つのアーキテクチャ
パターン1: ステートフルエージェントパターン
最も基本的なパターンです。エージェントの状態を明示的に管理し、Think Tool の出力をステートの一部として保持します。
interface AgentState {
conversationHistory : Anthropic . MessageParam [];
thinkingLog : Array <{
timestamp : number ;
thought : string ;
context : string ;
}>;
toolCallCount : number ;
maxToolCalls : number ;
}
async function statefulAgentLoop (
state : AgentState ,
tools : Anthropic . Tool []
) : Promise <{ response : string ; state : AgentState }> {
while (state.toolCallCount < state.maxToolCalls) {
const response = await client.messages. create ({
model: "claude-opus-4-6" ,
max_tokens: 8096 ,
tools: tools,
messages: state.conversationHistory,
});
state.conversationHistory. push ({
role: "assistant" ,
content: response.content,
});
if (response.stop_reason === "end_turn" ) {
const text = response.content. find (( b ) => b.type === "text" );
return { response: text?.text ?? "" , state };
}
const toolResults : Anthropic . ToolResultBlockParam [] = [];
for ( const block of response.content) {
if (block.type === "tool_use" ) {
state.toolCallCount ++ ;
if (block.name === "think" ) {
const thought = (block.input as { thought : string }).thought;
// 思考ログを記録(デバッグ・監視用)
state.thinkingLog. push ({
timestamp: Date. now (),
thought,
context: `tool_call_${ state . toolCallCount }` ,
});
toolResults. push ({
type: "tool_result" ,
tool_use_id: block.id,
content: thought,
});
} else {
const result = await executeExternalTool (block.name, block.input);
toolResults. push ({
type: "tool_result" ,
tool_use_id: block.id,
content: result,
});
}
}
}
state.conversationHistory. push ({ role: "user" , content: toolResults });
}
return { response: "ツール呼び出し上限に達しました。" , state };
}
パターン2: パイプラインゲートパターン
Think Tool の出力を分析し、特定の条件を満たさない場合はパイプラインを中断する安全設計です。
interface ThinkAnalysis {
confidence : "high" | "medium" | "low" ;
risks : string [];
shouldProceed : boolean ;
}
function analyzeThought ( thought : string ) : ThinkAnalysis {
// 思考内容からリスクや不確実性を検出
const lowConfidenceSignals = [
"確信が持てない" ,
"不明" ,
"推測" ,
"not sure" ,
"uncertain" ,
"might be" ,
];
const riskSignals = [
"返金" ,
"削除" ,
"キャンセル" ,
"refund" ,
"delete" ,
"cancel" ,
];
const hasLowConfidence = lowConfidenceSignals. some (( s ) =>
thought. toLowerCase (). includes (s)
);
const hasRisk = riskSignals. some (( s ) =>
thought. toLowerCase (). includes (s)
);
return {
confidence: hasLowConfidence ? "low" : hasRisk ? "medium" : "high" ,
risks: riskSignals. filter (( s ) =>
thought. toLowerCase (). includes (s)
),
shouldProceed: ! (hasLowConfidence && hasRisk),
};
}
このパターンにより、エージェントが自信のない状態で破壊的な操作を実行することを防げます。
パターン3: マルチエージェント Think 共有パターン
複数のエージェントが協調して動作する場合、Think Tool の出力を共有することで、エージェント間の整合性を保ちます。
class SharedThinkingContext {
private thoughts : Map < string , string []> = new Map ();
addThought ( agentId : string , thought : string ) : void {
const existing = this .thoughts. get (agentId) ?? [];
existing. push (thought);
this .thoughts. set (agentId, existing);
}
getSummary () : string {
let summary = "=== エージェント間の思考共有 === \n " ;
for ( const [ agentId , thoughts ] of this .thoughts) {
summary += ` \n [${ agentId }]: \n ` ;
thoughts. forEach (( t , i ) => {
summary += ` ${ i + 1 }. ${ t . substring ( 0 , 200 ) } \n ` ;
});
}
return summary;
}
}
Extended Thinking + Think Tool の併用戦略
Extended Thinking と Think Tool は排他的ではなく、併用することで最大の効果を発揮します。
// Extended Thinking + Think Tool の併用
const response = await client.messages. create ({
model: "claude-opus-4-6" ,
max_tokens: 16000 ,
thinking: {
type: "enabled" ,
budget_tokens: 5000 , // 初期推論に予算を割り当て
},
tools: [thinkTool, ... businessTools],
messages: messages,
});
使い分けの指針は以下の通りです。
Extended Thinking : タスク全体の計画立案、複雑な問題の初期分析に使用。レスポンス生成前の「大きな思考」
Think Tool : ツール呼び出しの合間の状況整理、中間結果の分析に使用。レスポンス生成中の「小さな思考」
例えるなら、Extended Thinking は旅行の計画を立てる段階、Think Tool は旅行中に地図を確認して次の目的地を決める段階に相当します。
パフォーマンス最適化とコスト管理
Think Tool はトークンを消費するため、コスト管理が重要です。
// Think Tool のコスト制御
function createCostAwareThinkTool ( maxThinkTokens : number = 500 ) {
return {
name: "think" ,
description:
"Use this tool to analyze the current situation and plan next steps. " +
`Keep your thinking concise (under ${ maxThinkTokens } tokens). ` +
"Focus on: what you know, what you need, and your next action." ,
input_schema: {
type: "object" as const ,
properties: {
thought: {
type: "string" ,
description: `Concise reasoning (max ~${ maxThinkTokens } tokens)` ,
},
},
required: [ "thought" ],
},
};
}
// トークン使用量の監視
interface TokenUsageTracker {
thinkTokens : number ;
toolTokens : number ;
totalTokens : number ;
}
function trackThinkToolUsage (
response : Anthropic . Message ,
tracker : TokenUsageTracker
) : void {
for ( const block of response.content) {
if (block.type === "tool_use" && block.name === "think" ) {
const thought = (block.input as { thought : string }).thought;
// 概算: 日本語1文字≒1.5トークン、英語1単語≒1.3トークン
const estimatedTokens = Math. ceil (thought. length * 1.5 );
tracker.thinkTokens += estimatedTokens;
}
}
tracker.totalTokens =
(response.usage?.input_tokens ?? 0 ) +
(response.usage?.output_tokens ?? 0 );
}
コスト最適化のベストプラクティスとして、Think Tool の使用頻度をシステムプロンプトで制御します。「すべてのツール呼び出しの前に think する」のではなく、「判断が必要な重要なステップでのみ think する」よう指示することで、品質を維持しながらコストを抑えられます。
実例:欠航の返金対応で判断がどう変わるか
パターンの説明だけでは掴みにくいので、実際のカスタマーサポート場面に当てはめてみます。「予約した便が欠航になったので返金してほしい」という問い合わせを想定します。
Think Tool がない場合、エージェントは予約を取得し、欠航の記録を見つけ、そのまま全額返金を実行しかねません。顧客がすでに後続便へ振替済みであること、欠航理由が天候であり航空会社都合とは補償規定が異なること。そのどちらも見落とした状態での実行です。
Think Tool を挟むと流れが変わります。予約詳細を取得した直後に Claude は think を呼び出し、「元の便 UA234 が欠航。UA567 への振替記録がある。返金処理の前に確認すべきは、(1) 欠航理由が天候か航空会社都合か、(2) 振替が顧客に受諾されているか、(3) 運賃差額がいくらか」と整理します。取り返しのつかない操作へ進む前に、確認すべき項目が言語化されます。
ポリシーを参照したあと、Claude はもう一度 think します。「欠航理由は天候。ポリシー 4.2 により天候欠航は自動返金の対象外だが、旅行バウチャーの発行対象になる。振替は受諾済みなので旅程放棄には当たらない。返金ではなくバウチャーを案内し、天候時の規定を説明する」。この 2 回目の思考が、ポリシー違反を防ぎながら、顧客が受け取れる補償を取りこぼさずに済ませています。
航空ドメインで 54% という数字が出た理由は、この一場面に凝縮されています。think を挟むたびに、後から訂正・エスカレーション・苦情を生んでいたはずの誤りが 1 つ消えているのです。逆に言えば、判断を 1 回しか行わないエージェントでは消せる誤りがそもそも存在しません。数字の大小ではなく、自分のエージェントに「消せる誤り」が何箇所あるかで導入判断をするのが確実です。
デバッグとオブザーバビリティ
Think Tool の大きな副次的効果は、エージェントの意思決定プロセスが可視化されることです。
// Think Tool ログの構造化出力
interface ThinkLog {
id : string ;
timestamp : string ;
agentStep : number ;
thought : string ;
precedingTool : string | null ;
followingTool : string | null ;
confidence : string ;
}
function formatThinkLogs ( logs : ThinkLog []) : string {
return logs
. map (
( log ) =>
`[Step ${ log . agentStep }] ${ log . timestamp } \n ` +
` After: ${ log . precedingTool ?? "initial"} \n ` +
` Thought: ${ log . thought } \n ` +
` Then: ${ log . followingTool ?? "final_response"} \n ` +
` Confidence: ${ log . confidence }`
)
. join ( " \n --- \n " );
}
本番環境では、Think Tool のログを以下の目的で活用できます。
プロンプト改善 : Claude がどのような推論で誤った判断を下したかを分析し、システムプロンプトを改善
品質監視 : 思考の「confidence」を監視し、低信頼度が頻発する場合にアラートを発火
コンプライアンス : 金融・医療などの規制領域で、AIの意思決定根拠を記録・監査
全体を振り返って
Think Tool パターンは、エージェントワークフローにおける判断精度を劇的に向上させるシンプルかつ強力な手法です。Extended Thinking が「事前の深い思考」であるのに対し、Think Tool は「行動の合間の状況確認」として機能し、両者を組み合わせることでエージェントの信頼性を最大化できます。
特に、複数のツールを連鎖的に使用するエージェントや、ポリシー判断を伴うカスタマーサービスエージェントでは、Think Tool の導入効果が顕著です。サーバー側の実装コストはほぼゼロでありながら、Anthropic の τ-bench 検証では航空ドメインで 54% の相対改善が報告されています。ただしこの値はドメイン固有の思考例を組み込んだ場合のものであり、ツール定義を足しただけでは再現しない点は、あらためて押さえておきたいところです。
本記事で紹介したステートフルパターン、パイプラインゲートパターン、マルチエージェント共有パターンを参考に、自身のエージェントに Think Tool を統合してみてください。Claude API のツール使用についてより深く学びたい方には「Claude API 高度なツール使用完全ガイド 」、Extended Thinking との併用戦略については「「考えながら調べる」AIエージェントの作り方 」、思考トークンの費用対効果については「Claude API 拡張思考を本番導入して見えたコストの現実 」も参考になります。また、ストリーミング環境での実装については「Claude API ストリーミング・ツール使用本番運用ガイド 」で詳しく解説しています。
まず試していただきたいのは、いま運用しているエージェントのログを開き、判断を誤った 1 件を選んで「どの時点で立ち止まれば防げたか」を書き出すことです。その 1 箇所に think を差し込むだけで、Think Tool の効き方が手元の数字として見えてきます。
私自身、この 1 箇所からしか始められませんでした。同じ道を辿る方の役に立てば嬉しく思います。