社内向けのAIツールが、利用者の貼ったURLを読みにいく機能を持っている。情報システムの担当者からは「社外のページを読ませるのは止めたい」「読み先を決めたい」と求められ、開発側は「止められたら機能が落ちる」と心配する。Claude APIのweb fetch（指定したURLの内容を取りに行くツール）では、この調整を組織の設定で行えるようになりました。
Claude Platformのリリースノートによると、2026年10月20日から、組織の管理者がClaude Consoleの「Capabilities」のページでweb fetchを止められるようになりました。web fetchを有効にしたままなら、同じページで許可・拒否するドメインも決められます。この記事では、止めたときにAPIがどう振る舞うか、リクエストで指定する許可リストとどう組み合わさるかを、公式のドキュメントから整理します。
止めたときの挙動は、APIの種類で違う
同じ「止める」設定でも、呼び出し方によって結果が違います。
| 呼び出し方 | web fetchを止めたとき | 許可されないURLのとき |
|---|---|---|
| Messages API | web fetchのツールを含むリクエスト全体が400（invalid_request_error、web fetchが有効でないという内容）で失敗する | ツールの結果が url_not_allowed のエラーになり、Claudeは続きを生成する |
| Managed Agents | web_fetch の呼び出しがエラーの結果を返し、セッションは続く | 同じくエラーの結果。リダイレクト先のURLも組織とエージェントの両方のリストを通る必要がある |
Messages APIの「リクエスト全体が失敗する」点が、組み込む側にとって最も影響の大きい違いです。web fetchのツールをいつも付けてリクエストを送っている作りだと、管理者がweb fetchを止めると、URLを読む必要のない質問まで含めて、すべてのリクエストが失敗します。
許可リストは「組織」と「リクエスト」の両方を通る
web fetchを有効にしたまま、組織でドメインを絞った場合の決まりは次のとおりです。ドキュメントの「Domain filtering」の節から抜き出します。
- リクエストで指定する
allowed_domainsは、組織の許可リストの範囲内でなければならない。範囲外の項目があると検証のエラーになる - リクエストの許可リストに、組織が拒否しているドメインが含まれていると、400のエラーになり、ぶつかった項目が示される
- ドメインはスキーム（
https://）を付けずに書き、サブドメインは自動で含まれる（example.comはdocs.example.comも対象） - web fetchはドメインだけで判定し、パスを含む項目はweb fetchのURLに一致しない
- 1つのリクエストで
allowed_domainsとblocked_domainsは同時に使えない
パスを含む項目の扱いは、web search（検索のツール）と違うので注意が必要です。検索では example.com/blog のようなパスでの絞り込みが使えますが、同じ項目をweb fetchに書いても一致しません。組織の許可リストを決める担当者と、リクエストを組み立てる開発者が別の場合は、この違いを両者で共有しておきます。
ドキュメントは、国際化ドメイン名の見た目の似た文字（例: キリル文字の「а」を使った аmazon.com）でフィルターを回避される恐れがあるとして、許可・拒否のリストにはASCIIのドメイン名を使い、既存の項目に非ASCIIの文字がないか確かめるよう勧めています。
管理者がweb fetchを絞りたい理由
web fetchのドキュメントは、信頼できない入力と機密のデータを同じ環境でClaudeに扱わせながらweb fetchを有効にすると、データを外へ持ち出される危険があると警告しています。対策として、Claudeは自分の出力にだけ現れたURLは取りに行けず、会話にすでに出てきたURL（利用者のメッセージ、クライアント側のツールの結果、以前の検索や取得の結果）だけを取りに行けます。APIキーやパスワードのような資格情報を含むように見えるURLも、その資格情報がシステムプロンプトか利用者のメッセージにない限り取りに行きません。
それでも残る危険はあるとして、ドキュメントはweb fetchを完全に止める、max_uses で回数を絞る、allowed_domains で安全なドメインに限る、url_sources でクライアント側のツールの結果をURLの出どころから外す、といった方法を挙げています。今回の組織の設定は、このうち「止める」と「ドメインを絞る」を、個々のリクエストに頼らず管理者が組織全体に適用できるようにしたものです。
Managed Agentsのweb fetchが会話に出てきたURLしか取りに行かない仕組みと、そのときのエラーの直し方は、Managed Agentsのweb_fetch制限と直し方で整理しました。limited のネットワーク設定の環境で allowed_hosts もweb fetchに効く点も、同じ記事で扱っています。
組み込む側で用意しておくこと
ここからは編集部の提案です。管理者が設定を変えると、利用者からは「AIが答えない」「URLを読めない」という症状だけが見えることがあります。組み込む側で次の備えをしておくと、原因の切り分けが早くなります。
- web fetchが要らないリクエストにはツールを付けない: URLを含まない質問にまでweb fetchを付けて送らないようにすれば、組織で止めたときに影響を受けるのは、URLを読む機能だけに限られます
- 400の応答の内容を見て、web fetchが原因かを区別する: web fetchが有効でないという内容の400を受けたら、ツールを外して送り直す、または「この機能は組織の設定で止められています」と利用者に伝えるなど、ほかの400と分けて扱います
url_not_allowedを記録する: ツールの結果のエラーは200の応答の中に入るため、HTTPの状態だけを見ていると気づけません。ドキュメントによると、このコードは組織やリクエストのリストのほか、Anthropic側の制限（プライベートアドレス、robots.txt、渡していない資格情報を含むように見えるURL）でも返ります。どのURLが拒否されたかを記録しておくと、許可リストの不足か、意図した拒否か、それ以外の制限かを見分ける手がかりになります- リクエスト側の許可リストを、組織の許可リストの内側に保つ: 組織の許可リストが変わると、リクエストに書いたドメインが範囲外になり、検証のエラーになることがあります。組織の設定を変える担当者に、システムが使っているドメインの一覧を渡しておきます
APIのバージョンやSDKの更新とあわせて、エラーの扱いを見直す場合は、Claude API 2026-10-21とSDK新メジャー版の記事も確認してください。
確認した範囲
2026年10月31日に、Claude Platformのリリースノート（2026年10月20日の項）と、ドキュメントの「Web fetch tool」「Server tools」（Domain filtering）、「Restrict web search and web fetch domains」（Managed Agents）をplatform.claude.comで直接開いて確認しました（資料調査）。2026年11月6日に同じ資料を確かめ直し、本文の記述と一致することと、10月20日より後のリリースノートにweb fetchの組織の設定の変更がないことを確認しました。Claude ConsoleのCapabilitiesのページの画面、変更できる役割、実際の400の応答の文面、設定を変えてから反映されるまでの時間、Claude Platform on AWSなどの提供先で同じ設定が効くかは確かめていません。組み込む側の備えは、ドキュメントの記述から編集部が整理した提案です。
社内のAIツールに外部のWebの取得を組み込むときの権限と通信の設計、既存の組み込みの点検は、開発・AI・自動化のご相談からお問い合わせください。
