AIに​「見ていい​サイト」を​指定できるようになった​ ──OpenAI・Anthropic・AWSの​3社を​比べて​分かった、​拒否の​され方の​違い

AIに調べ物を任せると、たまにまとめサイトや古い記事を根拠に、それらしい嘘を書いてくる。これは能力の問題というより、どこを読んだかの問題だ。そして今、その「どこを読むか」を発注する側が指定できるようになっている。

2026年8月19日、AnthropicとAWSが同じ日に、AIエージェントの検索先を絞る機能を出した^[1][2]。Anthropicは読んでいいドメインの許可リストと拒否リストを、AWSはドメインに加えて「公開日」での絞り込みを追加し、あわせて東京リージョンでも使えるようにした。OpenAIにも同じ性格の機能が先にある^[3]。

この記事で扱うのは4つ。①何ができるようになったのか ②3社で何が違うのか ③拒否されたとき何が返ってくるのか ④実際に決めるべきこと。③には、運用に効く非対称がひとつある。同じ「ブロック」でも、記録が残る場合と、何も残らない場合がある。

01 何が​できるようになったのか──読んでいい先を​リストで​渡す

やっていることは単純だ。エージェントに検索や取得をさせるとき、読んでよいドメインの一覧（許可リスト）か、読ませたくないドメインの一覧（拒否リスト）を一緒に渡す。3社とも指定したドメインはそのサブドメインまで含む扱いになる^[1][3]。

Anthropicの設定は、エージェントに与える道具の一覧の中に書く。次は、検索は2つのサイトだけに限り、取得のほうは1つのホストを禁じて、取り込む分量にも上限をかける例だ^[1]。

{"type": "web_search", "allowed_domains": ["docs.example.com", "arxiv.org"]}
{"type": "web_fetch", "blocked_domains": ["ads.example.com"], "max_content_tokens": 50000}

Anthropicの公式ドキュメントに載っている設定例（要点だけ抜粋）^[1]

ここで見落としたくないのが、検索（web_search）と取得（web_fetch）が別々のリストを持つことだ^[1]。「検索は社内の資料だけ、リンクを開くのは広告ドメイン以外なら何でも」といった非対称な運用ができる。

02 3社を​並べてみる​──設定する​場所が​違う

同じ「ドメインを絞る」でも、3社で作りが違う。公式ドキュメントから拾えるものを並べるとこうなる。

項目	OpenAI	Anthropic	AWS（Bedrock AgentCore）
書く場所	リクエストのツール定義 （filters）	エージェントの道具の設定 （作成時に決められる）	リクエストごとの 実行時フィルタ
許可／拒否	両方（allowed_domains blocked_domains）	両方（検索と取得で 別々のリスト）	両方（含める／除外する）
件数の上限	各100件まで	公表なし	各リスト100件まで
サブドメイン	含む	含む	—
公開日で絞る	—	—	できる（開始日と終了日）
その他の制御	参照した全URLを sources で取得	取り込み量の上限 検索結果の地域指定	東京・アイルランド リージョンに拡大

実務で効くのは「書く場所」の違いだ。OpenAIとAWSはリクエストごとに指定する形なので、呼び出す側のコードが正しく書かれていることが前提になる。対してAnthropicはエージェントを作るときの設定に置けるので、組織として先に決めておける。どちらが良いという話ではなく、「誰が守る決まりなのか」が変わる。

もうひとつ、OpenAI側の sources は覚えておきたい。本文の引用に出てこないものも含めて、参照した全URLを返す^[3]。フィルタが効いているかを後から確かめる手段になる。

03 拒否された​とき、​何が​返るのか──記録が​残る​側と​残らない​側

ここが今回いちばん実務に効く発見だった。Anthropicのドキュメントは、同じ設定でもツールによって拒否のされ方が違うと明記している^[1]。

ツール	許可されていない相手だったとき
取得 （web_fetch）	エラーとして返る。エージェント側にエラー結果が渡り、エラーコード url_not_allowed が付く
検索 （web_search）	該当する結果が黙って除かれる。エラーは発生せず、結果が少なくなるだけ

この差は、あとから「なぜこの答えになったのか」を追えるかどうかに直結する。取得を止めた場合は記録が残るので、リストが厳しすぎることに気づける。検索の場合は、結果が減っただけなのか、そもそも情報が無かったのかを区別できない。

許可リストを絞りすぎたまま運用すると、AIは「見つかりませんでした」と答え続ける——けれど本当は、見に行けないだけかもしれない。この形の失敗は、エラーが出ないぶん発見が遅れる。許可リスト型で始めるなら、最初は広めにして、参照元の実績を見ながら絞るのが安全な順番になる。

04 AWSだけが​「いつの​情報か」で​絞れる​──古い​記事を​掴ませない

AWSが8月19日に足したもうひとつの軸が公開日での絞り込みだ。開始日と終了日を指定して、その期間に公開されたものだけを検索結果に入れることができる^[2]。

これは地味に見えて、AIに調べ物をさせるときの失敗を1つ潰す。数年前の仕様や廃止された制度の解説が、今の話として混ざる——これは人間が検索していても起きるが、AIは古い記事も同じ確からしさで扱うので、そのまま結論に混ざりやすい。CAGでも記事を書くときは必ず一次情報の日付を確認する手順を挟んでいるが、その作業を検索の側で先に済ませられる意味は大きい。

そして日本の読者に効くのが、同じ更新で東京リージョンとアイルランドが対象に加わったことだ^[2]。これまでは米国東部だけだった。検索そのものを国内で動かせるかどうかは、データをどこで扱うかの話とつながる。

関連記事 ｜ どこで処理されるかの話AIの処理は国内に限定できるか ──OpenAIとAnthropicの地域指定を実測、日本は「保存だけ」で処理はできない →

05 決めて​おく​こと​──4項目

• 許可リスト型か、拒否リスト型か。 社内資料や公的機関だけを見せたいなら許可リスト、一般の検索は使わせつつ雑音を外したいなら拒否リスト。許可リストは絞りすぎると「見つかりません」に化けるので、広めに始めて実績で狭める。
• 検索と取得で分けるか。 Anthropicはツールごとに別のリストを持てる。「探すのは限定、開くのは緩め」といった組み方ができる^[1]。
• 100件の上限に収まるか。 OpenAIとAWSはリストあたり100件^[2][3]。サブドメインは自動で含まれるので、example.com と書けば配下はまとめて対象になる。
• ブロックを記録に残すか。 取得の拒否はエラーとして残るが、検索の除外は残らない^[1]。監査が必要なら、参照した全URLを取得できる仕組み（OpenAIの sources など）とセットで考える。

06 まとめ──出典の​質は、​出典の​範囲で​決まる

やりたいこと	これまで	これから
怪しい情報源を 読ませない	プロンプトで「信頼できるサイトを使って」と書く	拒否リストで機械的に外す
社内・公的資料だけで 答えさせる	できるかどうかは運任せ	許可リストで範囲を固定する
古い情報を 混ぜない	出てきた答えを人が確認する	AWSは公開日で絞れる
何を見たか あとで確かめる	本文の引用しか手がかりがない	参照URLの一覧を取得する（OpenAI）

プロンプトで「信頼できる情報源を使ってください」と頼むのは、結局のところお願いでしかなかった。今は設定として書ける。AIの答えの質を上げたいとき、モデルを乗り換える前に、読ませる範囲を決めるほうが早いことがある。