Managed Agents の web_fetch が「セッションに既出の URL」限定へ — bash や MCP の出力に出た URL は取得できない
Claude Managed Agents の web_fetch ツールが、セッション中に既に出現した URL だけを取得する仕様になった。公式が挙げる「既出」の例はユーザーメッセージの本文、web_search の結果、web_fetch が以前返したページの中である。目的はデータ持ち出しリスクの低減と明記されている。該当しない経路も明示されており、Claude 自身の出力、エージェントのシステムプロンプト、添付文書、bash / read / MCP ツールの出力にだけ現れた URL は既出に数えない。これらへの web_fetch 呼び出しは url_not_in_prior_context エラーを返す。取得させたい URL は user.message イベントの本文として送る必要がある。同じ 2026-10-07 には allowed_hosts が web ツールへ適用される変更も入っており、web ツールの到達範囲が1日で2方向から絞られた。
ニュース原文を読む ↗要約
Claude Managed Agents の web_fetch ツールが、セッション中に既に出現した URL だけを取得する仕様になりました。目的はデータ持ち出し（exfiltration）のリスク低減と公式に明記されています。
本記事は追補です。 2026-10-08 の日次チェックで同じ日付の節から6件を記録しましたが、本件が漏れていました。allowed_hosts の web ツール適用は別エントリとして記録済みで、本件はそれとは別軸の制限です。
公式が挙げる「既出」の例は次の3つです。ユーザーメッセージの本文、web_search の結果、web_fetch が以前返したページの中。
そして、該当しない経路が明示されているのが本件の要点です。
Claude 自身の出力、エージェントのシステムプロンプト、添付文書、bash / read / MCP ツールの出力にだけ現れた URL は「既出」に数えません。 これらに対する web_fetch 呼び出しは、エージェントへ url_not_in_prior_context エラー結果を返します。
この除外リストの中身が、攻撃の形をそのまま示しています。
狙われるのは、エージェントが自分で読んだものの中に URL を仕込まれる経路です。 添付文書に https://attacker.example/?data= を埋めておく。MCP ツールの応答に紛れ込ませる。bash で読んだファイルに書いておく。エージェントがそれを素直に fetch すれば、クエリ文字列に乗せた社内情報が外へ出ます。 プロンプトインジェクションの出口として、これは最も直接的な形です。
今回の変更は、この出口を「URL の出自」で閉じました。 ホストで閉じるのではなく、誰が持ち込んだ URL かで閉じるという方向です。
だから allowed_hosts とは独立に効きます。 同じ 2026-10-07 には、limited ネットワークで allowed_hosts が web_search / web_fetch にも適用される変更も入りました。ホスト単位の許可リストを通っても、URL の出自が条件を満たさなければ取得できません。 逆も同じです。web ツールの到達範囲が、1日で2方向から絞られたことになります。
取得させたい URL がある場合は、user.message イベントの本文として URL を送る必要があります。
何が変わったか
web_fetchが「セッションに既出の URL」だけを取得する（2026-10-07）。目的は exfiltration リスクの低減（公式明記）- 「既出」に数えるもの: ユーザーメッセージの本文、
web_searchの結果、過去のweb_fetchが返したページの中 - 「既出」に数えないもの: Claude 自身の出力、エージェントのシステムプロンプト、添付文書、
bash/read/ MCP ツールの出力 - 該当しない URL への呼び出しは
url_not_in_prior_contextエラー結果をエージェントへ返す - 取得させたい URL は
user.messageイベントの本文で渡す - 同日の
allowed_hostsの web ツール適用とは独立に効く。ホストで許可されていても出自が条件を満たさなければ取得できない
業務インパクト（一般企業向け）
既存の Managed Agents が壊れる可能性があります。壊れ方は把握しやすい形です。
専用のエラーコードが用意されているのは親切な設計です。 url_not_in_prior_context が返るなら、原因の特定で迷いません。 黙って空を返されるのが最悪のパターンで、本件はそうなっていません。同日の allowed_hosts 側では web_search が黙って結果を除外するので、2つの変更は失敗の見え方が違います。 ログを見るときはこの違いを前提にしてください。
壊れる構成を先に洗い出せます。 パターンは3つです。(1) 社内のファイルやドキュメントから URL を抽出して fetch するエージェント。社内 Wiki のリンクを辿る、仕様書の参照先を読む、といった実装が該当します。(2) MCP ツールの応答に含まれる URL を fetch する構成。チケット管理や CRM の MCP サーバーから返ってきた URL を開く実装です。(3) システムプロンプトに固定の URL を書いて参照させる構成。「常にこの社内ポータルを確認してから回答する」という書き方です。
(3) が最も直しやすく、(2) が最も厄介です。
(3) はシステムプロンプトから user.message へ移すだけです。 セッション開始時に URL を含むユーザーメッセージを1本投げる形へ変えれば通ります。
(2) は設計の見直しが必要です。 MCP ツールが返した URL を開く流れは、エージェントの中だけで完結しているのが設計の前提でした。そこへ「ユーザーメッセージを経由させる」を挟むのは自然ではありません。現実的な対処は、MCP ツール側で中身を返すようにすることです。 URL を返して「あとは fetch して」とする実装から、ツール自身がコンテンツを取得して返す実装へ寄せる。これは手間ですが、セキュリティの観点でも筋が通っています。 社内システムの内容を取るなら、認証を持っている MCP サーバーが取るのが正しい形で、認証を持たない web_fetch に取らせる構成は元々きれいではありませんでした。
この変更をどう説明するかも考えておいてください。
制限が増える変更は、現場からは「使いにくくなった」と受け取られます。 説明の軸は**「エージェントが自分で読んだものに書かれた URL は信用しない」**です。添付された PDF に仕込まれた URL をエージェントが開く構成は、PDF を送れる人が社内情報を外へ出せる構成です。 この一文があれば、制限の理由は伝わります。
セキュリティ要件を書く立場なら、この設計自体を自社の基準へ取り込む価値があります。 「外部へのリクエストを許す URL は、人が明示的に渡したものに限る」。これは Claude に限らず、エージェントを作るときの一般的な防御です。 自社で LLM エージェントを実装している場合、同じ制限を入れているかを確認してください。
副業・個人活用視点
個人で Managed Agents を使っている場合も、同じ変更が当たります。
まず自分のエージェントが該当するかを確認してください。 判定は簡単です。**「エージェントが開く URL は、自分がメッセージに書いたものか」**を考えればよい。自分が毎回 URL を貼っているなら影響ありません。エージェントが読んだファイルや MCP の応答から URL を拾っているなら、該当します。
受託でエージェントを作っている場合、これは説明責任の話になります。
納品済みのエージェントが動かなくなると、連絡が来ます。 先に自分で気づいて連絡する方が、はるかに印象がよい。url_not_in_prior_context というエラーコードで検索すれば原因が分かる状態なので、クライアント側が先に調べて「仕様変更だった」と分かるのが最悪です。 心当たりがあるなら、今のうちに確認して先に伝えてください。
提案の材料としても使えます。 「プラットフォーム側が exfiltration 対策を入れた」という事実は、エージェント導入の審査で聞かれる「情報が外に出ないか」への回答材料になります。 自分で作り込んだ対策ではなくベンダーが構造として入れた制限なので、説明の重みが違います。審査資料に公式のエラーコードと除外リストを引用して載せるのが有効です。
学習の題材としては、プロンプトインジェクションの出口を塞ぐ設計の実例として優れています。
インジェクションの話は「悪い指示を入れられる」側に注目が集まりがちです。 しかし実際の被害は、情報が外へ出る出口があるかどうかで決まります。 悪い指示を入れられても、外へ送る手段がなければ被害は限定されます。本件は入口ではなく出口を絞った対策です。
自分でエージェントを設計するときの設問にしてください。 「このエージェントが外部へリクエストを送れる経路は何本あるか」「その URL はどこから来るのか」。web_fetch だけでなく、画像の読み込み、Webhook、メール送信も出口です。 出口を数える習慣は、入口を守る工夫より効きます。