AIがサイトを読めないとき

1. 起きたこと

2026年9月、AIを補助に使ってデバッグをしていたとき、公開されているWebサイトをAIのWeb取得機能から参照できないことがありました。

同じサイトをブラウザや通常のHTTPクライアントから開くと問題なく表示されます。対象を変えて試しても同様のケースがあり、一方でAIから普通に取得できるサイトもありました。

最初に疑ったのはサイト側です。

DNS、IPv4 / IPv6、HTTPS、robots.txt、Webサーバーなど、取得できない理由はいくつも考えられます。そこで原因を決め打ちせず、自分で観測できるところから順に切り分けました。

結論から言えば、今回の直接の原因までは特定できていません。

ただし、AIが取得できないという理由だけで、サイト側を延々と調べ続ける必要はないと判断するための材料は得られました。

今回は、DNS、IPv4 / IPv6、GET、外部ネットワーク、robots.txt、access logまで順に確認しました。
そこまで正常なら、AIが取得できないという理由だけでサイト側を深掘りし続ける必要はありません。
AI側の取得制御を含む、別の可能性も切り分け候補に残せます。

2. サイト側を切り分ける

以下では実際のドメイン名やサーバー固有のパスを伏せ、確認に使った方法だけを示します。

DNS

まずAレコードとAAAAレコードを調べました。

dig A <target-domain>
dig AAAA <target-domain>

IPv4、IPv6ともに名前解決できました。

この時点で、単純なDNS障害を主因と考える材料はありませんでした。

IPv4とIPv6を分ける

次に、IPv4かIPv6のどちらか一方だけに問題がないかを調べます。

curl -4 -I https://<target-domain>/
curl -6 -I https://<target-domain>/

どちらも正常なHTTPレスポンスを返しました。

通常のアクセスが成功していても、IPv6側だけ壊れているといったケースはあります。そのため、アドレスファミリーを分けて試しておくと切り分けやすくなります。

HEADだけでなくGETも試す

到達性の確認ではHEADだけで済ませることがありますが、実際にページを取得するときに使われるのはGETです。

そこで両方を試しました。

curl -I https://<target-domain>/

curl -sS -o /dev/null \
  -w '%{http_code}\n' \
  https://<target-domain>/

HEAD、GETともに200で、GETではコンテンツも取得できました。

HEADが通っただけで「Webサイトは正常」とせず、GETまで試したのはこのためです。

別のネットワークから試す

サーバー自身や同じネットワークからアクセスできても、それだけでは外部公開が正常とは言い切れません。

そこで、サーバーとは別の一般的な外部ネットワークにある端末からもHEADとGETを実行しました。

こちらも正常に応答しました。

少なくとも、サーバー内部からだけ到達できる状態ではありませんでした。

robots.txt

次にrobots.txtを調べました。

curl -fsS https://<target-domain>/robots.txt

robots.txtが存在する対象では、一般的なクローラーを明示的に拒否する設定は見当たりませんでした。

例えば、次のような内容です。

User-agent: *
Allow: /

別の対象ではrobots.txt自体が存在せず、404が返りました。

robots.txtが404だからといって、それだけでWeb取得を拒否していることにはなりません。今回調べた範囲では、robots.txtで取得失敗を説明できる材料は見つかりませんでした。

3. access logで到達を調べる

今回の切り分けで特に参考になったのが、Webサーバーのaccess logでした。

ログをリアルタイムで監視します。

sudo tail -F <web-server-access-log>

まず、別ネットワークの端末からHEADとGETを送ります。

通常の外部アクセスはログに記録されました。

"HEAD / HTTP/1.1" 200 ... "curl/..."
"GET / HTTP/1.1"  200 ... "curl/..."

これで、少なくとも監視しているaccess log上で、通常の外部HTTPアクセスを観測できることが分かります。

その状態で、AIのWeb取得機能から同じサイトを取得させました。

AI側では取得できませんでしたが、ログを確認できる対象については、その時刻に対応すると判断できるHTTPリクエストを通常のaccess log上で見つけられませんでした。

ここは少し注意が必要です。

access logに記録がないことから、「AIからの通信は絶対にサーバーまで来ていない」とまでは言えません。

今回観測できたのは、通常の外部アクセスなら記録されるaccess logに、AIの取得試行に対応するリクエストが見当たらなかったというところまでです。

4. 調査結果

今回の切り分けをまとめると、次のようになりました。

確認項目	結果
DNS（A / AAAA）	正常に解決
IPv4でのHTTPS接続	200
IPv6でのHTTPS接続	200
HEAD	200
GET	200、コンテンツ取得可
別ネットワークからのHEAD / GET	200
robots.txtによる明示的な拒否	見当たらず
通常の外部アクセス	access logに記録
AI取得試行	対応するHTTPリクエストを通常のaccess logで確認できず

調査時点では、DNS、IPv4 / IPv6、HTTPS、通常のGETといった基本的な経路に、AIからの取得失敗を説明できる明確な異常は見つかりませんでした。

ここまで調べると、少なくとも「サイトそのものが普通に外部公開できていない」という方向をさらに深く追う優先度は下がります。

5. AIのWeb取得はブラウザと同じとは限らない

ここで参考になるのが、AI事業者が公開しているWebアクセスの安全対策です。

AIエージェントは単にページを表示するだけではありません。会話中の情報やほかのツールにアクセスできる状態で外部URLを取得することもあるため、外部アクセスそのものが情報流出の経路になる可能性があります。

OpenAIは2026年1月、URLを利用したデータ流出への対策を公開しています。

その説明では、エージェントがURLを自動取得する際、そのURLがユーザーの会話とは独立したWebインデックスで以前から観測されているかを照合します。既知のURLと一致しなければ、すぐには信頼せず、別のWebサイトを使わせたり、ユーザーによる明示的な操作を求めたりする場合があります。

ここで見ているのは「そのドメインが有名かどうか」ではなく、個々のURLが独立したWebインデックスですでに観測されているかです。「検索結果に出ないマイナーなドメインは取得しない」という単純な仕組みとして説明されているわけではありません。

GoogleもGeminiのprompt injection対策として多層防御を公開しており、その中にはGoogle Safe Browsingを利用した疑わしいURLの検出などが含まれています。ただし、これはOpenAIが説明しているURLの既知性確認と同じ仕組みではありません。

Anthropicも、Webを操作するAIエージェントについて、訪問するWebページそのものがprompt injectionの攻撃経路になり得ると説明し、モデルの耐性強化、分類器、レッドチーミングなどを組み合わせています。

各社の方式は異なります。

それでも、AIによるWebアクセスが通常のブラウザとまったく同じ条件で行われるとは限らず、安全上の制御が途中に入ることがあるという点は、デバッグするときに知っておいてよさそうです。

6. 今回の原因は分からない

今回の調査だけでは、AIがサイトを取得できなかった直接の原因は特定できませんでした。

通常の外部アクセスは成功し、基本的なサイト側の異常も見つからず、ログを確認できた対象ではAIの取得試行に対応するHTTPリクエストも通常のaccess logで観測できませんでした。

この状況では、サイト側の障害だけでなく、AI側の取得前制御を含む、Webサーバーへ到達する前の処理も候補に残ります。

ただし、OpenAIなどが公開している安全機構が今回の事象を引き起こした、と証明したわけではありません。

公開情報は、あくまで「こうした安全制御が実際に存在する」という参考材料です。

7. どこで調査を切り上げるか

今回役に立ったのは、原因そのものより、サイト側の調査をどこで一区切りにするかという判断でした。

DNSが引ける。IPv4とIPv6の両方でHTTPS接続できる。GETでコンテンツを取得できる。別ネットワークからもアクセスできる。robots.txtにも明示的な拒否がない。

さらに、通常の外部アクセスはWebサーバーのログに残るのに、AIからの取得試行に対応するHTTPリクエストは見当たらない。

ここまで揃ったら、AIが読めないという理由だけでサイト側を掘り続ける優先度は下げてよいと考えます。

もちろん、CDN、WAF、ネットワークACL、TLSなど、構成によって追加調査が必要な場合はあります。

それでも、「AIが取得できない。だからサイトのどこかがおかしいはずだ」という前提だけで調査を続ける必要はありません。

AIを補助に使った開発やデバッグでは、Web取得機能そのものにも制約や安全境界がある可能性を、切り分けの候補に入れておく。

今回の調査では、それが深追いを避けるためのひとつの判断材料になりました。

References

8. 参考資料

OpenAI, Keeping your data safe when an AI agent clicks a link, 2026-01-28
https://openai.com/index/ai-agent-link-safety/
OpenAI, Preventing URL-Based Data Exfiltration in Language-Model Agents
https://cdn.openai.com/pdf/dd8e7875-e606-42b4-80a1-f824e4e11cf4/prevent-url-data-exfil.pdf
Google, Mitigating prompt injection attacks with a layered defense strategy, 2025-06-13
https://blog.google/security/mitigating-prompt-injection-attacks/
Anthropic, Mitigating the risk of prompt injections in browser use, 2025-11-24
https://www.anthropic.com/research/prompt-injection-defenses