サーバーログを見ても何も出てこない。しかしChatGPTのエージェントは、自社サイトを開けない。そんな「見えない門前払い」が起きていると、Search Engine Journalに寄稿したDan Taylor氏が報告している。原因として挙げられているのが、OpenAI側の安全確認の仕組み(同氏は内部的に「Aura」と呼ばれていると説明)だ。ただし、この話の中核は一人の実務者の観察であり、OpenAIが仕組みを公式に説明したわけではない。事実と推測を分けて整理する。
何が報告されているのか
同記事によれば、ChatGPTのライブ検索やCodexのブラウザ操作などは、サイトを開く前に中央のサイト安全確認を通る。そこで「不許可」と判定されると、エージェントはサイトへリクエストを送らずに拒否される。そのため、サイト側のサーバーログ、WAF、CDNには何も残らない。判定は端末側に24時間キャッシュされるという。
筆者が確認できた一次情報は、OpenAIのクローラー公式ドキュメントまでだ。そこでは、GPTBot(学習用)、OAI-SearchBot(ChatGPT検索への表示用)、ChatGPT-User(ユーザー操作に基づくアクセス)の3種が別々の設定を持つこと、ChatGPT-Userのユーザー起点の動作はrobots.txtの対象にならない場合があることが書かれている。「サイト安全確認」という仕組みそのものを裏づける公式の記述は、本稿の執筆時点で確認できなかった。同氏の説明する内部エンドポイントや挙動は、本人の観察に基づく解釈だ。
同氏が示した事例と、その限界
同氏が助言した国際的なメディア企業では、2026年5月からメインサイトがChatGPTのエージェントで開けなくなった。競合サイトは同じセッションで開け、同じ技術を使う別ドメインのページも問題なかった。ブラウザ側の許可設定を変えても改善せず、数週間後も検証した5つのURLはすべてブロックされたという。OpenAIのサポートは最終的に、安全ブロックが有効で、想定どおりかを見直していると書面で回答した。
重要なのは、これが1社の事例である点だ。広範囲のサイトに起きている現象かどうかは、現時点では分からない。OpenAIは分類基準も公表していない。同氏自身も、危険なサイトを遮断すること自体は妥当だとしたうえで、正規の事業者が巻き込まれる場合のレビュー手続きと明確なエラー表示が必要だと主張している。
考察:GEOの「見えない前提」が一つ増えた
最近のGEO(生成AI向け最適化)は、引用されるコンテンツの書き方に議論が集中している。AI検索の引用とブランド言及の測り方のように、可視性を測る手法も整いつつある。しかしそれは、AIがサイトに到達できることが前提だ。到達できなければ、どれだけ良い記事を書いても検討対象にすら入らない。
筆者はこれを、検索エンジンに対するnoindexの事故に近い構造だと見る。違いは、Search Consoleのような診断画面がないことだ。同氏も、利用者が「コンテンツやGEOの問題」と誤解しやすい点を指摘している。日本のサイトでも、AIエージェント経由の予約や比較が増えるほど、この種の取りこぼしが売上に響く可能性がある。ただし、現時点で国内の発生例は確認できていない。
日本の運用者が今できる確認
同氏が示した切り分け手順から、実務で使いやすいものを挙げる。
- 自社の主要URLを、ChatGPTのライブ検索とブラウザ系エージェントで開けるか試す。競合サイトも同じ条件で試し、一般的な障害と区別する
- サーバー・CDN・WAFのログで、OpenAIのクローラーが正常応答を得ているか確認する。クローラーは通るのにエージェントだけ拒否されるなら、サイト側の設定以外を疑う
- エラー文言と時刻を記録する。問い合わせる場合に証跡になる
- 自社のrobots.txt、WAF、ボット対策、地域制限を先に潰す
回避策は取らないほうがよい。同氏は、OpenAIの利用規約が安全対策の回避を禁じていると指摘している。いまのところ公式の異議申し立て窓口は示されていないため、サポートへの問い合わせ記録を残すことが現実的な備えになる。