2026年4月19日

Claude Server Tools — API側で実行されるツールがエージェント開発を変える

AnthropicのTool Useは、AIエージェント開発の基盤として広く使われている。しかし2026年4月現在、この仕組みに大きな変化が起きつつある。Server Tools — ツールの実行をAnthropic側で行う新しいアプローチだ。開発者がツール実行をハンドリングする必要がなくなり、エージェント構築が劇的にシンプルになる。今回はこの仕組みを整理してみたい。

従来のTool Use（Client Tools）のおさらい

これまでのTool Useは、こういう流れだった：

Claudeがtool_useブロックを返す（「このツールを使いたい」）
開発者が自分のコードでツールを実行する
実行結果をtool_resultとして返す
Claudeが結果を受け取って次のアクションを決める

このループ — tool_use → tool_result → tool_use → ... — がいわゆる「agentic loop」だ。開発者はツールの実行ロジック、エラーハンドリング、タイムアウト管理などをすべて自分で書く必要があった。

これは柔軟性が高い反面、本番環境のエージェントを作るにはそれなりの実装コストがかかる。特に、ツールが増えれば増えるほど、ハンドリングのコードも膨らんでいく。

Server Tools — 発想の転換

Server Toolsは、このループのうち「ツールの実行」部分をAnthropic側でやってしまう仕組みだ。

開発者がやることは、APIリクエストでServer Toolsを有効にすることだけ。あとはAnthropicのインフラ上でツールが実行され、結果が同じassistant turn内に返ってくる。tool_resultを開発者が返す必要がない。

つまり、従来の4ステップがこうなる：

APIリクエストでServer Toolsを指定
→ Anthropic側でツール実行
→ 結果が同じレスポンスに含まれて返ってくる

開発者のコードでツール実行のハンドリングが不要になる。これが一番のポイントだ。

利用可能なServer Tools

2026年4月時点で提供されているServer Toolsは以下の4つ：

web_search — Web検索。最新情報へのアクセスが可能。ニュース、技術ドキュメント、価格情報など、学習データに含まれない最新の情報を取得できる。
code_execution — コードの実行。サンドボックス環境で安全に動く。データ処理、計算、ファイル操作などをClaude自身が実行できる。
web_fetch — Webページの取得。URLを指定してページの内容を取得・解析する。
tool_search — ツールの検索。利用可能なツールの中から適切なものを見つける。

特にweb_searchとcode_executionの組み合わせは強力だ。「最新の情報を検索して、そのデータを元に計算して、結果をまとめる」という一連の流れが、開発者の追加コードなしで完結する。

内部的な仕組み — server_tool_useブロック

Server Toolsは、従来のtool_useブロックとは別のserver_tool_useブロックとして扱われる。

重要な違い：

IDプレフィックスがsrvtoolu_（Client Toolsのtoolu_と区別される）
APIが内部でツールを実行する
実行結果は同じassistant turn内に返ってくる
tool_resultの返信が不要

開発者から見ると、リクエストを投げたら、ツール実行済みのレスポンスが返ってくるというシンプルな体験になる。

pause_turn — 長時間実行のハンドリング

Server Toolsで独特なのがpause_turnという概念だ。

ツールの実行に時間がかかる場合（大量のWeb検索や複雑なコード実行など）、APIはstop_reason: "pause_turn"でレスポンスを一時停止することがある。

この時の開発者の対応は非常にシンプル：

前回のassistant contentをそのまま送り返す
→ 実行が再開される
→ 完了した結果が返ってくる

つまり、特別なステート管理は不要。前回のレスポンスをそのまま投げ直すだけでいい。ただし、このpause_turnのパターンは従来のTool Useには存在しなかったものなので、エージェントを実装する際はハンドリングを忘れないようにしたい。

ZDR（Zero Data Retention）との関係

Server ToolsはAnthropicのインフラ上で実行されるため、データが一時的にAnthropic側を通ることになる。ZDR（Zero Data Retention）環境 — つまり「データを一切保持しない」という厳格なセキュリティ要件がある環境 — では、Server Toolsが制限される場合がある。

これはトレードオフの関係だ。便利さと引き換えに、データが追加のインフラを経由する。金融機関や医療機関など、極めて厳しいデータポリシーを持つ組織では、この点を慎重に評価する必要があるだろう。

実際のインパクト — エージェント開発がどう変わるか

個人的に一番感じるのは、「本番環境のエージェント構築がシンプルになる」ということだ。

これまでは、エージェントにWeb検索をさせたければ、検索APIのキーを取得して、API呼び出しのコードを書いて、エラーハンドリングして、レートリミットを管理して…という作業が必要だった。Server Toolsなら、これがすべてAnthropic側で完結する。

また、従来のagentic loopは本番環境で落とし穴が多かった。ツール実行のタイムアウト、ネットワークエラー、予期しないレスポンス形式…こうした「地味に辛い」実装作業が大幅に減る。

小規模チームや個人開発者にとっては特に大きい。インフラエンジニアリングのリソースを、本来のサービス開発に回せるようになるからだ。

まとめ

Server Toolsは、Tool Useの進化としてシンプルだが強力な方向性を示している。

「開発者がツール実行をハンドリング不要」という一点だけでも画期的だが、実際にはこれによってエージェント開発の設計パターン自体が変わってくる。従来のagentic loopの実装コストが、Server Toolsの導入でゼロに近づく。

従来のTool Use → 柔軟性が高いが実装コストも高い
Server Tools → 実装コストほぼゼロ、Anthropic提供のツールに限定

どちらを使うかは要件次第だが、Server Toolsがカバーする範囲は日々広がっている。まずはServer Toolsで十分か検討し、不足分をClient Toolsで補う — というハイブリッドなアプローチが、これからのスタンダードになるかもしれない。