Managed Agents の web_fetch は、セッションに現れた URL だけを取得する

Claude Managed Agents で、これまで取得できていた URL が url_not_in_prior_context で失敗するようになった場合、設定の誤りとは限りません。2026 年 10 月 7 日のリリースノートで、web_fetch が取得できる URL の条件が変わっています。

本記事は、次の公式ドキュメント 3 本を 2026 年 10 月 11 日に確認した内容だけで構成しています。

リリースノートの該当項目は、見出しが「October 7, 2026」で、タイムゾーンの記載はありません。本記事でも公式の表記のまま 2026 年 10 月 7 日として扱います。「破壊的変更」という語や、適用が始まった時刻、実行中のセッションの扱いは、確認した範囲では記載がありません。

エージェントの設計全般は AI エージェントの設計パターン に譲り、本記事では web_fetch の URL の条件に絞ります。

取得できる URL と、できない URL

リリースノートによれば、web_fetch が取得できるのは、セッション内にすでに現れた URL です。出どころごとに整理すると次のとおりです。

URL の出どころ取得
user.message のテキストできる
web_search の結果できる
先に web_fetch で取得したページの中できる
Claude の出力にだけある URLできない
エージェントのシステムプロンプトできない
添付ドキュメントの中できない
bash・read・MCP ツールなどの出力できない

取得できない URL では、url_not_in_prior_context というエラーが返ります。

注意したいのは、システムプロンプトと添付ドキュメントが「できない」側に入っていることです。参照先の URL 一覧をシステムプロンプトに書いておく設計や、仕様書を添付してその中のリンクを読ませる設計は、そのままでは取得に失敗します。

リリースノートには、この変更の理由が書かれていません。一方、Messages API 側の web_fetch のドキュメントには、データの持ち出しを抑えるために、Claude の出力にだけある URL を取得できないようにしていると説明があります。同じ考え方の仕様と見るのは自然ですが、Managed Agents の変更の理由として公式が述べているわけではありません。

補足

リリースノートが挙げている「できない」出どころは、記載された範囲がすべてです。たとえば、Managed Agents に自前で定義したツールの結果にある URL が許可されるかは、確認した範囲では記載がありません。

直し方は、user.message のテキストで URL を送る

公式の回避策は、1 行です。取得させたい URL を、user.message イベントのテキストで送ります。

実装の手当ては、次の 2 つの形に分かれます。

  1. 最初から読ませたい URL が決まっているときは、セッションを始める user.message の本文に URL を書く
  2. 途中で見つかった URL を読ませたいときは、いったんエージェントの実行を区切り、人またはアプリ側が user.message でその URL を送る

たとえば、本文に次のように書きます。

次の仕様書を読んで、変更点を 3 点に要約してください。
https://example.com/spec/v2

システムプロンプトに URL 一覧を持たせている場合は、一覧そのものを消す必要はありません。ただし、実際に読ませる段階で、その URL を user.message の本文にも書いてください。

bash の実行結果や MCP のツールが返した URL を、そのままエージェントに取得させていた流れも同じです。たとえば、チケット管理の MCP が返した関連資料のリンクを、続けて web_fetch で読ませていた場合は、取得に失敗します。リンクを人やアプリ側で受け取り、user.message で渡し直す手順を挟みます。

FIXITFIXIT

システムプロンプトに URL を書いてあるのに、なんで読めないの？

DodaiDodai

出どころで判定されるからです。システムプロンプトにあるだけでは、セッションに現れた URL として数えられません。

FIXITFIXIT

じゃあ、どう直せばいいの？

DodaiDodai

読ませたい URL を user.message の本文に書きます。公式の回避策はこれだけです。

sandbox の中から bash で取得する方法も考えられます。ただし、これは公式の回避策ではありません。URL の出どころを絞る制限の趣旨をすり抜けることになるため、自社の統制ルールに照らして判断してください。

url_not_allowed との見分け方

同じ 2026 年 10 月 7 日のリリースノートには、もう 1 件、web_fetch のエラーに関わる変更があります。limited ネットワークの cloud 環境では、allowed_hosts が web_search と web_fetch にも適用されます。allowed_hosts に合わないホストへの web_fetch は、url_not_allowed を返します。unrestricted ネットワークと、セルフホスト環境は、この制限を受けません。

2 つのエラーは、原因が別です。

エラー原因見直す場所
url_not_in_prior_contextその URL がセッション内に現れていないURL をどの経路で渡しているか
url_not_allowedドメインの許可・拒否リスト、または allowed_hosts に合わないエージェントの設定と、環境の allowed_hosts

url_not_allowed の側は、Managed Agents のドキュメントに詳しい説明があります。エージェントの web_fetch に allowed_domains か blocked_domains を設定でき、許可されないホストへの取得は、agent.tool_result イベントの is_error: true として返り、内容に url_not_allowed が入ります。ドキュメントには、組織レベルの web_fetch 設定 (Claude Console) は Messages API に適用され、Managed Agents のセッションには適用されないという記載もあります。

確認できていないのは、url_not_in_prior_context がエージェント側にどう見えるかです。url_not_allowed は agent.tool_result イベントで見えると書かれていますが、url_not_in_prior_context の見え方は、確認した範囲では記載がありません。ログで原因を探すときは、エラーコードの文字列そのものを手がかりにしてください。

limited ネットワークでは、許可の書き方にも注意が必要です。ドキュメントによれば、ツール側の allowed_domains のエントリはサブドメインも含みますが、環境の allowed_hosts は、*. で始めない限り正確に 1 つのホストにだけ一致します。たとえば、docs.example.com は ["example.com"] の中には入らず、["docs.example.com"] か ["*.example.com"] の中に入ります。

Messages API の web_fetch との違い

Messages API の web_fetch のドキュメントにも、URL 検証の節があります。取得できる URL は、会話にすでに現れたものです。具体的には、user メッセージの本文、クライアント側ツールの結果、先の web_search や web_fetch の結果にある URL が許可されます。Claude の出力にだけある URL と、システムプロンプトにだけある URL は取得できません。

Managed Agents のリリースノートと見比べると、違いが 1 点あります。

出どころMessages API のドキュメントManaged Agents のリリースノート
クライアント側ツールの結果許可bash・read・MCP の出力は対象外
コード実行・MCP コネクタなどサーバーツール対象外記載なし

Messages API のドキュメントは、クライアント側ツールの結果を許可の出どころに入れています。Managed Agents のリリースノートは、bash・read・MCP ツールの出力を対象外としています。2 つの文書は別の API を説明しているため、Managed Agents の自前ツールの結果がどちらに近いかは、確認した範囲では書かれていません。

Messages API の web_fetch には、max_uses や citations といったオプションがありますが、Managed Agents のツールセットでは使えません。Messages API で組んだ処理を Managed Agents に移すときは、この差も含めて見直してください。

Amazon Bedrock と Google Cloud については、ドキュメントに「現時点で web_fetch は利用できない」と書かれています。今回の変更がこれらの基盤でどう扱われるかは、確認した範囲では記載がありません。

手元のエージェントを点検する順番

ここからは、上記の一次情報から導いた点検の提案です。Anthropic が保証している手順ではありません。

  1. 失敗しているエージェントの種類を確認する。Managed Agents なら今回の変更の対象で、Messages API のみなら対象外
  2. ログで url_not_in_prior_context の文字列を探す。url_not_allowed と混ざっていないかも見る
  3. 失敗した URL の出どころを特定する。システムプロンプト、添付文書、bash・read・MCP の出力のどれにあるか
  4. 取得させたい URL を、user.message の本文に書く形へ直す
  5. limited ネットワークを使っているなら、allowed_hosts と allowed_domains の書き方を確認する
  6. 直したあとに、同じ URL で取得できることを実機で確かめる

3 の特定が、いちばん手間がかかります。エージェントが自分で組み立てた URL は、Claude の出力にだけある URL に当たるため、出どころの記録が残っていないことがあります。URL を人が決めて渡す設計に寄せると、出どころを説明しやすくなります。

注意

回避策は、URL を渡す経路を人またはアプリ側に寄せるものです。エージェントが自分で見つけた URL を自由に取得させる運用は、できなくなったと読むのが安全です。業務の自動化の設計では、この前提で見直してください。

AI エージェントを業務に組み込むときの権限設計や、外部への接続の考え方は AI 駆動開発のセキュリティ にまとめています。エージェントが業務上の判断を拒否する場面の扱いは AI エージェントのタスク拒否とセキュリティ も参考になります。

FIXIT の運用 — エージェントの外部接続をどう決めるか

FIXIT は AI 駆動開発のクリエイティブスタジオとして、AI エージェントをクライアントワークの実務に組み込む設計を支援しています。外部のページを読ませる処理を設計するときは、エージェントが何を読めるかを機能の便利さより先に決めます。誰が URL を決め、どこまでを自動で読ませ、どこから人が確認するかを、運用の言葉で書き出しておくためです。

今回のような仕様の変更は、設計の前提が変わった合図でもあります。公式の変更履歴を定期的に読み、記載のある範囲だけを根拠に点検する、という手順を運用に入れておくと、突然の失敗に慌てずに済みます。

まとめ

論点結論
何が変わったか2026 年 10 月 7 日のリリースノートで、Managed Agents の web_fetch は、セッションに現れた URL のみ取得する
取得できる出どころuser.message の本文、web_search の結果、先に取得したページの中
取得できない出どころClaude の出力のみ、システムプロンプト、添付文書、bash・read・MCP の出力
失敗時のエラーurl_not_in_prior_context
公式の回避策取得させたい URL を user.message のテキストで送る
別のエラーurl_not_allowed は、ドメイン制限や limited ネットワークの allowed_hosts が原因
確認できなかったこと適用の時刻、実行中セッションの扱い、Bedrock などでの扱い、自前ツールの結果の扱い

次の一歩は、失敗している URL の出どころを 1 件特定することです。システムプロンプトや MCP の出力に由来するなら、user.message で渡し直す修正で解消するはずです。確認できなかった点は、Anthropic の公式ドキュメントとリリースノートを定期的に確かめてください。

AI エージェントの設計や外部接続の統制を、社内の運用に合わせて整えたい場合は、AI エージェント開発 で伴走しています。何から手を付けるか決まっていない段階でも、お問い合わせ から状況を教えていただければ、判断の材料を一緒に整理します。