Claudeツールを組み合わせるパターン — 公式が示す6つの型

Claudeツールの組み合わせとは — 集める役と動かす役を1つの配列に並べる

ツールの組み合わせとは、役割の異なる2つ以上のツールを同じtools配列に並べ、1回のリクエストの中でClaudeに使い分けさせる設計です。公式docsの「Tool combinations」ページは、Anthropic提供のツールを6つの型にまとめています。共通の発想は、一方が情報を集める・見つける役、もう一方が処理する・動かす役を担うことです。

6つの型は「開始点であって処方箋ではない」とされ、タスクに合わせて混ぜてよい設計です。小さなツールを組み合わせる利点は、リクエストごとにツールを出し入れできる点にあります。ある呼び出しではWeb検索だけ、別の呼び出しではコード実行も足す、といった切り替えが配列の増減で済みます。

組み合わせの設計で最初に押さえたいのは、各ツールがどこで動くかです。サーバー側とクライアント側では、状態の持ち方も責任の範囲も変わります。

この分類はツールリファレンスの一覧にある「Server / Client」の列に基づきます。以降の6つの型は、この2種類をどう混ぜるかの違いとして読めます。

目的から型を選ぶ — 6型の判断順と早見表

判断の起点は「集める作業と処理する作業のどちらが重いか」です。次の順に絞ると、型が決まりやすくなります。

リサーチ型 — Web検索とコード実行

Web検索が情報源を見つけ、コード実行がその情報を分析・集計・可視化します。「今四半期の決算を主要クラウド5社で比較して」のように、最新情報の取得と非自明な計算の両方が要る質問に向く組み合わせです。

{
  "tools": [
    { "type": "web_search_20260209", "name": "web_search" },
    { "type": "code_execution_20260521", "name": "code_execution" }
  ]
}

流れは、検索してから実行し、最初の検索で足りない部分が見つかったら再度検索する、というものです。コード実行はサーバー側で走るので、クライアント側にサンドボックスを用意する必要はありません。nameにはweb_searchのように小文字の名前を指定します。

押さえておきたい点が3つあります。

• コード実行のコンテナにはインターネット接続がありません。実行時にパッケージをダウンロードできず、使えるのはプリインストールされたライブラリだけです。外部データはWeb検索の結果として取り込む必要があります。
• 各リクエストは新しいコンテナで始まります。前のレスポンスのコンテナIDを渡すと、同じコンテナを使い続けられます。コンテナは作成から30日で失効し、約5分使わないとチェックポイントされます。30日以内ならIDを渡して復元できます。レスポンスのexpires_atはそれより短い更新される値で、30日の期限は示しません。期限切れのコンテナを指定するとエラーになります。
• web_search_20260209以降では、検索結果をコンテキストに入れる前にコードで絞り込む動的フィルタリングが働きます。この絞り込みに必要なコード実行は、APIが自動で用意します。フィルタが目的ならcode_executionをtoolsに足す必要はなく、追加の課金もトークン費用だけです。

スニペットのcode_execution_20260521はcode_execution_20260120と同じ実行環境です。プログラマティックツール呼び出しではPythonの1セルに90秒の実時間制限があり、ツールの説明がそれをClaudeに伝えます。

2つ目のツールを明示的に足す意味は、検索結果とは別に集計・可視化のコードを走らせたいときにあります。動的フィルタリングはClaude 4.6以降のモデルで使えます。それ以外のモデルではallowed_callers: ["direct"]の指定が要り、省くと400エラーで指定を促されます。

Web検索の有効化手順や、claude.aiとClaude Codeでの挙動の違いはClaude Web検索の使い方にあります。

コーディング型 — テキストエディタとBash

テキストエディタがファイルを読み書きし、Bashがテストとビルドコマンドを実行します。コードを見る、編集する、テストを走らせる、また見る。開発の定型ループそのものです。

{
  "tools": [
    { "type": "text_editor_20250728", "name": "str_replace_based_edit_tool" },
    { "type": "bash_20250124", "name": "bash" }
  ]
}

両ツールともクライアント側で実行されるため、どのファイル・どのコマンドに触れるかはアプリ側が握ります。信頼できないコードの上で動かすなら、作業ディレクトリを絞り、実行コマンドのallowlistを添えるのが公式の案内です。

text_editor_20250728はClaude 4以降のモデル向けで、それ以前のモデルにはtext_editor_20250124を使います。モデルによってtypeが変わる点は、他の型にない注意点です。

自前でツールの実行を実装せずに済ませたい場合は、組み込みツールを備えたClaude Agent SDK入門が先の選択肢になります。同種のファイル編集とコマンド実行を行う完成品としてはClaude Codeがあります。

引用取得型 — Web検索とWeb Fetch

Web検索が候補URLを見つけ、Web Fetchが関連するページの全文を取得します。Claudeは検索結果のスニペットを見て、本当に関連する2〜3件だけをfetchします。仕様書のようにスニペットでは全体像が掴めない長文に答えがあるとき、ページ全体を取り込んだ上で具体的な箇所を引用できます。

{
  "tools": [
    { "type": "web_search_20260209", "name": "web_search" },
    { "type": "web_fetch_20260209", "name": "web_fetch" }
  ]
}

この型には、構成を左右する制約が2つあります。

• Web Fetchが取得できるのは、会話の中に既に現れたURLだけです。ユーザーメッセージ内のURL、クライアント側ツールの結果、過去のWeb検索・Web Fetchの結果は対象になります。Claude自身の出力にだけ現れたURLと、システムプロンプトにだけ書いたURLは対象外です。システムプロンプトのURLを取得させたいときは、ユーザーメッセージにも書きます。
• コード実行・MCPコネクタ・ツール検索の結果に含まれるURLも、取得元として認められません。リサーチ型のようにコード実行でURLを組み立ててから取得させる設計は成立しないので、URLはWeb検索かクライアント側で渡します。

取得できるコンテンツの種類も限られ、テキスト・HTML・PDFだけです。それ以外はunsupported_content_typeのエラーになります。

長時間稼働型 — メモリーと任意のツール

メモリーが会話をまたいで状態を保持し、他のツールが作業をこなします。顧客の過去の問い合わせを思い出すサポートエージェントや、先週決めたことを引き継ぐプロジェクトアシスタントが典型例です。

{
  "tools": [{ "type": "memory_20250818", "name": "memory" }]
}

メモリーは他のツールの挙動を変えません。コンテキストウィンドウがリセットされたときに失われる事実を、Claudeが書き留めて後から読み出せる置き場所を用意するだけです。他のツールと同じ配列に並べて組み合わせます。

保存先はアプリ側で用意します。Claudeが/memories配下へのファイル操作を依頼し、アプリがそれを実際のストレージ(ユーザーごとのディレクトリやデータベースのキー)に対応づけて実行します。ハンドラーは/memoriesの外へのパスを拒否する必要があり、実装前にパストラバーサル対策の節を読むよう案内されています。

メモリーはジャストインタイム取得を支えます。必要な情報を先に全部読み込まず、Claudeが学んだことをメモリーファイルに記録し、必要になったときに読み返します。作業中のコンテキストが目の前のタスクに絞られるので、放っておくとコンテキストウィンドウを圧迫する長時間のセッションで効きます。メモリーを有効にすると、Claudeは作業を始める前に自分でメモリーディレクトリを確認します。長い会話の管理では、コンテキスト編集(クライアント側で古いツール結果を消す)やコンパクション(サーバー側で会話全体を要約する)と併用できます。コンパクションで要約されても残したい情報の置き場所として、メモリーが働きます。

画面操作型とブラウザ型 — Computer UseとBrowser Use

Computer Useは、デスクトップ全体を操作して他のほとんどのツールを一括で代替します。Claudeはスクリーンショットを見てマウスとキーボードの操作を発行するので、人間が操作できるアプリなら何でも動かせます。APIの無いレガシーソフト、目視確認が要る検証、複数のデスクトップアプリをまたぐ作業が対象です。

{
  "tools": [{ "type": "computer_toolset_20260801" }]
}

Computer Useは最も汎用的な一方で、最も遅い選択肢です。操作のまとまりごとに新しいスクリーンショットが要るためです。他のツールで足りるならそちらを使い、何も当てはまらないときに選ぶ位置づけになります。

作業の全体がWebページの中で完結するなら、Browser Useの方が合います。アプリ側が制御するブラウザがスクリーンショットやページ状態を返します。Claudeは、クリックや入力と並べてread_page・find・form_input・get_page_textを呼べます。ページを認識するためのツールです。ピクセル座標だけでなく、要素の参照でも操作できます。

{
  "tools": [{ "type": "browser_toolset_20260801" }]
}

この2つは、1つのtoolsエントリが複数のメンバーツールをまとめて宣言する「クライアントツールセット」です。通常のツールと扱いが違う点を、ツールリファレンスの記述から挙げます。

• nameを取りません。日付付きのtypeがメンバー名を決めるためです。
• 個々のメンバーはconfigsで無効にできます。ただし全メンバーを無効にする指定は拒否されるので、使わないならエントリごと外します。
• allowed_callersは["direct"]だけを受け付けます。コード実行から呼ぶプログラマティックツール呼び出しには対応しません。
• strict: trueとinput_examplesは使えず、tool_choiceでtype: "tool"を指定してツールセットやメンバーを名指しすることもできません。
• 同じツールセットを2つ並べることや、computerという名前の別ツールをcomputer_toolset_20260801と並べることは拒否されます。Computer UseとBrowser Useのツールセットを同じリクエストで併用することは可能です。
• 無効にしたメンバーをClaudeが呼んだ場合は、エラーのtool_resultを返します。

Claude Managed Agentsのエージェントツールとしては、このツールセットは使えません。Messages APIのツールです。

実行環境が2つに分かれる罠 — コード実行とクライアントのBash

コード実行と、Bashのようなクライアント提供の実行ツールを同時に渡すと、Claudeは2つの独立した実行環境を扱うことになります。

Claudeが両者を混同し、片方にあるファイルをもう片方から参照しようとすることがあります。対策として、システムプロンプトに次の文面を入れるよう案内されています。

When multiple code execution environments are available, be aware that:
- Variables, files, and state do NOT persist between different execution environments
- Use the code_execution tool for general-purpose computation in Anthropic's sandboxed environment
- Use client-provided execution tools (e.g., bash) when you need access to the user's local system, files, or data
- If you need to pass results between environments, explicitly include outputs in subsequent tool calls rather than assuming shared state

要点は、環境間で状態が共有されないこと、用途で使い分けること、結果を渡すなら次のツール呼び出しに明示的に含めることの3つです。

もう1つ、リクエストの往復に表れる挙動があります。Claudeがクライアントのツールをコード実行と一緒に呼ぶと、APIはコード実行の呼び出しだけを結果なしで返します。結果は、クライアントツールのtool_resultを送り返した後の次のレスポンスで届きます。1回のレスポンスにコード実行の結果が入っていなくても、異常ではありません。

使えない環境がある — Web検索・Web Fetch・コード実行の提供面

サーバー側ツールの型は、動かす場所によって組めないことがあります。

コード実行は、FoundryではHosted on Anthropicのデプロイが必要です。Azureホストのデプロイでは使えません。

リサーチ型はWeb検索とコード実行の両方を使うので、Google Cloud・Amazon Bedrock・AzureホストのFoundryでは成立しません。引用取得型もBedrockとGoogle Cloudでは組めません。基本版には動的フィルタリングが無いので、Azureホストで検索と取得だけを組むときは、検索結果の絞り込みをアプリ側で用意することになります。

ページごとにバージョンが違う

6つの型のスニペットはweb_search_20260209とweb_fetch_20260209を使っています。一方、Web検索・Web Fetchの各ツールのページは、動的フィルタリングの例に20260318を使っています。ツールリファレンスは、新旧どちらも現行版で、必要な機能で選ぶ扱いです。20260318はresponse_inclusionによるレスポンス内容の制御を加えた版で、web_fetch_20260309はキャッシュ回避オプションを加えた版です。型のスニペットをそのままコピーする場合も、必要な機能に合わせて版を選べます。

まとめ

型を選ぶ前に、どの環境で動かすか(提供面)と、どのツールがどちらの実行環境にあるか(サーバー側かクライアント側か)を決めておくと、後から組み直す手間が減ります。ツールの定義や個数を絞りたいときは、Anthropic Advanced Tool UseのTool Search Toolが参考になります。往復のコードを自動化したいなら、Tool Runnerでツール呼び出しループを自動化するを見てください。