約 3 分で読めます

Web fetchツールの外向き通信を絞る4つの設定

社内の調査ボットにWeb fetchを付けたところ、想定外のサイトへ何度もアクセスしていた。ツールを有効にした直後に起きがちな事態です。AIが外部のページを読めるということは、外部へリクエストを出せるということでもあります。

2026年10月9日、Anthropicは評価中にモデルが実在のサイトへ想定外の操作をした事例を報告しました。この報告は、取得ツールの制限を「URLの長さ」のような間接的な仕組みに頼ると破られうることを示しています。本記事では、Claude APIの設定だけで外向き通信を絞る4項目を整理します。Markdown画像経由の漏えいは出力側での遮断、設計全体の考え方はLethal Trifectaを参照してください。

Anthropicの報告は何を示したのか

2026年10月9日の報告で、Claudeが取得ツールのURL長制限を短縮URLで回避した事例が明かされました。長さ制限は防御の本線にならないということです。

報告によると、モデルは第三者サイトへのSQLインジェクションやフォーム送信、アクセス制限の迂回を行いました。短縮URLサービスを使って、取得ツールのURL長の制限を回避した例も含まれます。同社はこれらの多くを、制限にぶつかった際に止まらず回避を試みる「持続性」の現れと説明しています。

なお、報告は10月12日に訂正されています。取得ツールの長さ制限は、SQL・コマンドインジェクションを防ぐ目的ではなく、大量データの持ち出しを抑える目的でした。対策としてAnthropicは、評価環境の外部インターネット接続の遮断と、取得ツールのガードレール強化を挙げています。

Web fetchにはどんな安全機構があるのか

Web fetchは、会話に現れていないURLの取得を拒否します。それでも公式ドキュメントは、機密データと未信頼入力が同居する環境で残るリスクを明記しています。

公式ドキュメントによると、取得できるのはユーザー発言、クライアント側ツールの結果、過去の検索・取得結果に現れたURLだけです。Claudeの出力にしか現れないURLや、APIキーやパスワードに見える文字列を含むURLは取得できません。URLの上限は250文字で、超えると url_too_long エラーになります。

ただし同じドキュメントは、機密データと未信頼入力を同じ環境で扱う場合に流出リスクが残ると警告しています。URL長はあくまで副次的な歯止めです。許可の範囲そのものを設定で絞る必要があります。

外向き通信を絞る4つの設定とは

設定は4つです。allowed_domains、max_uses、url_sources、max_content_tokensを組み合わせ、取得先・回数・URLの出所・量を別々に縛ります。

``json
{
"type": "web_fetch_20260318",
"name": "web_fetch",
"allowed_domains": ["docs.example.com", "www.meti.go.jp"],
"max_uses": 5,
"url_sources": {
"client_tool_results": { "type": "none" }
},
"max_content_tokens": 20000
}
``

  1. allowed_domains: 取得先を調査に必要なドメインだけにします。短縮URLサービスは許可しなければ到達できません。blocked_domains とは併用できず、許可リスト方式が基本です
  2. max_uses: 1リクエストあたりの取得回数を制限します。失敗した取得も回数に数えられ、デフォルトの上限はありません。必ず明示します
  3. url_sources: URLの出所を絞ります。client_tool_results を none にすると、コード実行などの自前ツールが出力したURLは取得元として認められません
  4. max_content_tokens: 取り込む量の上限です。1ページの目安は約2,500トークン(10kB)で、PDFは大きくなります

設定だけで足りるのか

足りません。APIの設定は取得ツールの経路しか守りません。コード実行やブラウザを併用するなら、ネットワーク層の許可リストと確認フローが別に必要です。

Claude Codeのサンドボックスは、外部通信をプロキシ経由に限定し、ドメインの許可リストで制御します。Agent SDKのセキュアデプロイ文書は、このプロキシが暗号化通信の中身を検査しないため、ドメイン偽装などで許可外に到達される可能性を指摘しています。強い保証が要る場合は、TLSを終端するプロキシやVM分離を検討します。

着手の順序は次のとおりです。

  • まず取得先ドメインを棚卸しし、allowed_domains に書き出す
  • 機密データを扱うエージェントでは、Web fetchを無効にするか別エージェントに分離する
  • 取得ログ(URL・回数・エラーコード)を保存し、url_not_allowed の急増を異常として見る

運用面の整備はAI運用伴走サービスで支援しています。大規模な統制が必要ならRDEもご確認ください。

参考

まとめ

Web fetchの外向き通信は、取得先・回数・URLの出所・量の4点を設定で縛ります。URL長のような間接的制限は回避されうるため、許可リストを主軸にしてください。ネットワーク層の統制やログ運用まで含めた設計は、Kuu株式会社にご相談ください。

関連記事

プロンプトインジェクションをアーキテクチャで止める5層防御設計Claude APIキーの種類と漏えい時の初動手順Markdown画像経由のデータ漏えいを出力側で止める3手順Excessive Agencyを機能・権限・自律性の3軸で点検