毎朝、競合のお知らせページと業界団体の告知ページを読み、変化があれば要約して報告する。社内のチケット管理ツールから参照先の URL を受け取り、その資料を読んで回答案を作る。Claude Managed Agents でこうしたエージェントを動かしている場合、10月7日以降に Web ページの取得が急に失敗し始めていないか確認が必要です。
2026年10月7日の Claude Platform のリリースノートには、Managed Agents の web_fetch（Web ページを取得するツール）と web_search（Web 検索）に関わる変更が3つ載りました。目的は、エージェントを通じて社内のデータが外へ送られる危険（データの持ち出し）を減らすことです。一方で、これまで動いていた構成がエラーになる場合があります。本記事では、リリースノートと公式ドキュメントの記述をもとに、影響を受ける構成と直し方を整理します。
変更1：会話に出てきたURLしか取得しない
リリースノートは、web_fetch が「fetches only URLs that have already appeared in the session」（セッションにすでに出てきた URL だけを取得する）ようになったとしています。取得できる URL と、できない URL は次のとおりです。
| 取得できる | 取得できない |
|---|---|
ユーザーのメッセージ（user.message）の本文に書かれた URL | Claude 自身の出力にだけ出てきた URL |
web_search の結果に出てきた URL | エージェントのシステムプロンプトにだけ書かれた URL |
前に web_fetch で取得したページに出てきた URL | 添付した文書、bash・read・MCP ツールの出力にだけ出てきた URL |
取得できない URL を指定すると、エージェントには url_not_in_prior_context のエラー結果が返ります。リリースノートの直し方は1つで、「To let the agent fetch a URL, send it in the text of a user.message event」（取得させたい URL は user.message の本文で送る）です。
Messages APIのweb fetchとは扱いが違う
Messages API（通常の API）の web fetch ツールにも、同じ趣旨の確認があります。ドキュメント（Web fetch tool の URL validation）によると、Messages API では、アプリ側で実行したツール（クライアント側ツール）の結果に出てきた URL は取得できます。システムプロンプトにだけ書かれた URL や、コード実行・MCP コネクターなどサーバー側のツールの結果に出てきた URL は取得できません。
Managed Agents では、bash や read、MCP ツールの出力に出てきた URL も取得できない側に入ります。Messages API で動いていた作りを Managed Agents に移すと、ここで動かなくなる可能性があります。
動かなくなる構成の例
上の表から、次のような作りは見直しが必要だと読めます（編集部の整理）。
- システムプロンプトに監視先の URL を並べている。 「次の3つのページを毎朝確認する」と書いたエージェントは、ユーザーのメッセージに URL がなければ取得できない
- MCP ツールで URL の一覧を取ってきている。 チケットや CRM から資料の URL を受け取り、そのまま
web_fetchに渡す流れは、エラーになる bashで URL を作っている。 CSV を読んだり、日付を入れて URL を組み立てたりしたものは取得できない
いずれも、セッションを始めるときや次の指示を送るときに、取得させたい URL を user.message の本文に入れる形に変えます。定期実行（scheduled deployments）では、各セッションの作業を始める最初のイベント（user.message または user.define_outcome）を設定します（Scheduled deployments のドキュメント）。URL を取得させるなら user.message を使い、その本文に URL を入れます。
変更2：limitedの通信設定がWeb検索と取得にも効く
Managed Agents の環境（environment）には、サンドボックスの外向き通信の設定 networking があります。limited にすると、allowed_hosts に書いたホストにしか通信できません。
10月7日の変更で、この allowed_hosts が web_search と web_fetch にも効くようになりました。この2つのツールはサンドボックスではなく Anthropic のサーバーで動くため、これまでは別扱いでした。リリースノートとドキュメント（Environments の Networking）の記述は次のとおりです。
allowed_hostsに一致しないホストの URL をweb_fetchで取ると、url_not_allowedのエラー結果が返るweb_searchは、一致しないホストの結果を省くallowed_hostsが空なら、どちらのツールもページも検索結果も返さないallow_package_managersとallow_mcp_serversは、この2つのツールには何のホストも足さないunrestrictedの設定と、自前で用意した環境（self-hosted）では、この2つのツールは制限されない
Web 検索をさせるエージェントを limited で動かしていた場合、10月7日以降は、検索結果が空になったり、取得がすべて失敗したりすることがあります。読ませたいサイトを allowed_hosts に足すと解消しますが、ドキュメントは「A host that you add to allowed_hosts is also open to the sandbox」（足したホストはサンドボックスからも通信できるようになる）と注意しています。
変更3：ドメインの一覧が食い違うとセッションが作れない
web_search と web_fetch には、ツールごとに取得先を絞る allowed_domains も設定できます。リリースノートによると、limited の環境で、有効なツールの allowed_domains に allowed_hosts の範囲外の項目があると、セッションの作成と更新が400エラーで失敗します。
ここで注意したいのが、一致の判定です。allowed_hosts の項目は、*. で始まらない限り1つのホストにだけ一致します。リリースノートの例では、docs.example.com は ["example.com"] の範囲に入りません。サブドメインも含めたい場合は、*.example.com のように書くか、ホストを個別に並べます。ただし Environments のドキュメントによると、*.example.com は example.com 自体には一致しません。両方に通信させるなら、example.com と *.example.com を並べて書きます。
すでに受け付けられた設定が、ツールの初期化の時点で無効になっていた場合、セッションは session.error を出して、再試行せずに待機（idle）に戻るとドキュメントは書いています。直すには、セッションのツールの設定を更新し、エージェント本体の設定も直してから、新しいメッセージを送ります。
点検の順番
ここまでの内容を、編集部が点検の順番としてまとめると次のとおりです。
- 環境の
networkingを確かめる。 API で環境を作るときnetworkingを省くとunrestrictedになる、とドキュメントは書いています（Claude Console の作成画面はlimitedが初期値）。意図せずunrestrictedになっていないかを先に見ます limitedの環境では、Web 検索と取得の対象サイトをallowed_hostsに入れる。 サブドメインの書き方に注意し、allowed_domainsがその範囲に収まっているかも確かめる- URL の渡し方を確かめる。 システムプロンプト、MCP ツール、
bashから URL を受け取っている箇所を洗い出し、user.messageの本文で渡す形に変える - エラーを監視する。 イベントの中の
url_not_in_prior_context・url_not_allowedとsession.errorを数え、10月7日の前後で増えていないかを見る
unrestricted の環境について、ドキュメントは、エージェントが外部サイトで書き込みやフォームの送信までできること、既定の権限のポリシーでは bash が承認なしで動くこと、読み込んだ内容に書かれた指示で動きが変わりうることを挙げ、事前に列挙できるなら limited を使うよう勧めています。今回の変更は、制限を強める方向のものです。直すときに unrestricted へ戻すのではなく、URL の渡し方と allowed_hosts を直す方向で対応するのが、変更の趣旨に沿った対応だと編集部は考えます。
Managed Agents の全体像はClaude Managed Agents とは、ページに埋め込まれた指示でエージェントが外へデータを送る危険の考え方は間接プロンプトインジェクションの記事、エージェントに渡す権限の分け方はAIエージェントの権限設計で整理しています。
確認した範囲
2026年10月15日に、Claude Platform のリリースノート（2026年10月7日の項）と、ドキュメントの Environments・Restrict web search and web fetch domains・Tools（Managed Agents）・Web fetch tool を直接取得して確認しました（資料調査）。公開前の2026年10月16日に同じ資料を取得し直し、記述を照合しました。Managed Agents は API キーが必要なため、エージェント・環境・セッションを実際に作った確認は行っておらず、エラーの実際の表示、変更前に作ったエージェントへの影響の出方、定期実行での挙動は未確認です。動かなくなる構成の例と点検の順番は、ドキュメントの記述から編集部が整理したものです。
AI エージェントを業務に組み込むときの通信と権限の設計、既存のエージェントの点検は、開発・AI・自動化のご相談からお問い合わせください。
