AIが受け取る「OK」なウェブ応答の20％は、実際にはOKではない

AIを活用したウェブスクレイピングを最近いくつか試したことで、ウェブがますます「閉鎖的」になっていることを、あらためて実感した。こうした後退を招いているのは、もちろん、AIによるウェブスクレイピングの驚異的な拡大だ。新たなデータを容赦なく求めるその動きは、ドメインをオフラインに追い込むことさえある。

これは、多くのドメインが以前から望んでいたこと、つまり、ユーザーがログインしている場合にのみコンテンツにアクセスできるようにすることを実行する、よい口実になる（もっとも、通常、Googlebotは例外としてアクセスを認められる）。Facebookはこの方針を段階的に導入し、2023年に完了した。Twitter/Xも同じ年に同様の対応を取った。Redditも今月中に導入する予定だ。

こうすれば、ユーザーはすでに登録済みなので、ドメイン側は国ごとに異なる年齢制限の適用にも多少対応しやすくなる。さらに重要なのは、ユーザーデータを保存し、地域ごとの分析に利用し、現地の法律が認める場合にはデータブローカーやAI企業に販売できることだ。

一方、ユーザー登録ではなく、ボット対策を明確に目的とする措置は、前年比で58％を超える増加となったとCloudflareは述べている。ボットの活動がこうして拡大すれば、ウェブサイトが精査するVPNやプロキシのIPアドレスも増え、悪意のあるトラフィックとともに、正当なユーザーまでアクセスを拒否されるおそれがある。

個人的な経験としては、「ブロック」応答や認証チャレンジに遭遇することがますます増えており、読み込みが始まったサイトを途中で離れることさえある。CAPTCHAの壁はユーザーや見込み客を遠ざけることが分かっているのだから、そうしたデメリットがあってもドメイン所有者が導入に踏み切る背景に、どれほどの圧力があるのかは想像に難くない。

過剰な自動リクエスト（人間によるものではないリクエスト）への対応として認証チャレンジを導入している多くのサイトの一つ、archive.isのCAPTCHA。

こうした新たな、そして増大する障壁は、一部はロジスティクス上の事情によるものだ（すべてのドメインが殺到するアクセスに耐えられるわけではない）。しかし、多くの場合、AI企業が、長い間無料で利用されてきた、切望してやまないデータの対価として、個別または一括で報酬を支払うかどうかを探る交渉手段でもある。

AIクローラーは大規模に稼働する必要があるため、Playwrightフレームワーク上でChromeの「ヘッドレス」インスタンスを使う傾向があります。近年、こうしたアクセスを拒むドメインが増えており、アクセスすると403（「アクセス禁止」）エラーが返されます（つまり、ホスト側が自動化された通信だと見抜き、「もう来るな」と追い払うのです）:

changedetection.ioをローカルにインストールしてサイトの定期確認を試みているが、サイト側はフレームワークが使用する検出済みブラウザーを受け入れず、403（「Forbidden」）応答を返している。

求められているのは「200」（「OK」）というクライアント応答だ。それを得るために、ほかのさまざまな人間以外の巧妙な手段と併せて、一般家庭のIPアドレスを提供するプロキシ業者に大金を払わなければならないとしても、だ。

200応答に勝るものはない。つまり、これ以上に肯定的な意味合いを持つクライアント応答コードは存在しない。また、曖昧な応答でもない。「ほぼOK」でも、「後でOKになる」でも、「だんだんOKになっている」でもなく、「OK！」なのだ。OKでなければ、200応答ではない。

こんにちは！お引き取りください

ところが、新たな論文によると、この粒度の粗さがAIデータセットや統計的推定を大きく歪め、実際にはそうでない場合にも「良好」と報告させている可能性がある。

この研究*は、200に分類される応答の約5分の1が、利用可能なページコンテンツをまったく含んでいないと推定している。代わりに返されるのは、空のウェブサイトの殻、CAPTCHAチャレンジ、アクセス制限、または代替ページだ。

論文には次のように記されている。

「静的クライアントがステータス200で受信するページの20.9％には、ページの主要コンテンツが含まれていない。アプリのシェル、ボットチャレンジ、ブロックページ、エラーページやプレースホルダーページ、部分的なコンテンツなどがこれに当たる。」

この点では、せっかちな自動システムは、自らの単純さゆえにつまずいている。「200」応答は取得の成功と同一視されるため、実際にはCAPTCHAの壁や有料アクセスの壁、その他の障害が返されている場合でも、成功とみなされてしまうのだ。

論文では、200応答を頻繁に複雑にするコンテンツを7種類に分類している。

200応答で「OK」とは到底言えないコンテンツの7つのカテゴリー。 出典

この調査では3日間にわたり、10,307件のウェブアドレスを、基本的なウェブ取得プログラムとJavaScriptを読み込めるブラウザーの両方でテストし、HTTPステータスコードではなく、取得したコンテンツに基づいて応答を分類した。

「利用できない」202応答のうち、最も多かったのは空のウェブサイトの殻とエラーページまたは代替ページで、これらを合わせると失敗の3分の2を超えた。

空のサイトの殻の場合、ウェブサイトにはメニューやナビゲーションが表示されていても、要求された記事や商品一覧が空白のままになっていることがある。後者では、要求したコンテンツの代わりに無関係なページやホームページが表示されることもあるが、どちらも、利用可能で有用なコンテンツを取得できた場合と同じHTTP 200ステータスが返される可能性がある。

解決策として、この論文は、HTTPステータスコードに頼るのではなく、実際に何が取得されたのかをウェブ取得ツールが報告することを推奨している。異常に短いページ、不審なリダイレクト、存在しないページに似たコンテンツを簡単に確認するだけでも、失敗の大半を検出できるためだ。

そのうえで、ページが正しく読み込まれなかったように見える場合に限り、より多くのリソースを要するブラウザーツールを使えばよい。さらに、AIの評価では、HTTP 200応答があればコンテンツを正常に取得できたとみなすのではなく、引用元が実際に想定された情報を含んでいるかを確認できる。

新たな研究の著者はまた、ページの長さ、リダイレクト、存在しないページとの類似性を基本的な方法で確認する「簡易的なヒューリスティック」により、利用できない応答の約86%を容易に特定できると指摘している。

ウェブ取得方法の比較：不審と判定されたページのみをレンダリングすると、すべてのページをレンダリングする場合（80.3%）より、利用可能なコンテンツをわずかに多く取得できた（81.4%）。一方、ページあたりの平均取得時間は20.6秒から5.8秒に短縮された。 

誤った200応答はなぜこれほど多いのか？

開発者コミュニティでは長年、ある程度の議論が続いており、202（「受理」）エラー（「要求は受理されたが、まだ完了していない」）を使えば、こうした「失敗した」200ステータスのリクエストを区別できるのではないかとされてきた。しかし実際には、202では新しい論文で挙げられたすべてのケースに対応できず、既存のコードにもそれを可能にするものはない。

この論文ではこの問題を深く掘り下げていないものの、ドメインの所有者が200エラーを許容する理由については、今後の関連研究でさらに調査する価値があるかもしれない。

理由の一つとして、200以外の応答は、最も一般的な404（「見つからない」）エラーを含め、基本的に何らかのエラーページや障害を意味することが考えられる。404エラーでは、目的のコンテンツが単に存在しない。こうしたエラーが過剰にあるとSEO（そしておそらくGEO）でペナルティを受けると考えるユーザーもいるが、Googleはその見方を否定している。

実際、Googleは誤った200エラーを「ソフト404」として扱っており、通常の404エラーよりも問題視する可能性が高い。意図的かどうかにかかわらず、実質的に「誤解を招く」結果だからだ。

引用のずれ

これらすべてが細かいことのように思えるなら、AIの学習を目的として日常的に収集（または収集が試みられる）されている、ペタバイト規模のデータについて考える必要がある。そのデータの5分の1が信頼できない、あるいは明らかに誤解を招くものだとすれば、その後に生じる影響を単なる「付随的な不正確さ」として片付けることは難しい。こうした誤った応答は、データセット内の分布や、そのデータをAIモデルに学習させた際の結果に、重大かつ悪影響を及ぼす可能性がある。

たとえば、誤った200応答をめぐる注目すべき問題の一つに、「引用のずれ」がある。これは、AIが生成した回答を、証拠として当初引用されたウェブページがもはや裏付けていない状態を指す。つまり、ページが変更された、該当する文章が削除された、あるいはリンク先が別の場所に変わった可能性がある。

新たな研究では、HTTP 200応答をすべて成功した取得として受け入れた場合、見かけ上の引用のずれが5.8%から21.9%に上昇することが分かった。応答に何が含まれているかにかかわらずである。

つまり、元の資料の代わりにCAPTCHA、空のページ、その他の障害が取得されたというだけで、情報源が変更された、消失した、またはAI生成の主張を裏付けなくなったと誤って判断される可能性がある。

そうだと言えば、そうなる！

意図的に存在しないウェブアドレスを使ったテストでも、この問題が示された。ウェブサイトにランダムに作成したパスを要求したところ、応答したサイトの13.1%が200（「OK」）ステータスを返したが、要求されたページは存在しなかった^†。

「ランダムなパスを使った調査に応答したサイトの13.1%が200を返した（S1 10.5%、S2 13.3%、S3 17.3%、S4 13.7%、S5 13.1%）。このような応答はすべて、定義上ソフト404にあたるが、すべてがそうだと示すわけではない。

「172件のソフト404応答を試験的に分類したところ、ラベラーは98件をエラーまたは代替ページ、32件をシェル、28件をコンテンツと判定した。ランダムなパスでホームページや一覧ページが表示されると、通常のページのように見える。」

結論

問題がより上位のレベルで認識されれば、IANA が、たとえば新たに、より適切なHTTPステータスコードを設けることも考えられる。 [X] （「リクエストは成功したが、要求されたコンテンツは配信されなかった」）。これは実際に起きていることを表すものの、当然ながら、ホスト側が取引内容をかなり詳しく把握している必要があり、その可能性は低い。

似たコードはすでに存在するものの、どれも本当に適切とはいえない。451（「法的な理由により利用不可」）は意味が曖昧で、かなり不穏な印象を与える。206（「部分的なコンテンツ」）は技術的には適切だが、不完全なデータ（フェッチ）を対象としている。また、意外にも存在する203（「信頼できない情報」）は、1997年に作られたもので、今回のユースケースとの関連はわずかにとどまる。

おそらく最も近い候補は、直感に反する名称の103（「早期ヒント」）だろう。このコードは、URLのリソースがまだすべて読み込まれていないことを示す（ただし、これは明らかにコードの意図を大きく誤解した解釈となる）。

* 論文のタイトルは「200 OKは答えではない場合：エージェント型ウェブコンテンツ取得におけるサイレントなフェッチ失敗」。なお、この論文は、どうやら主に機械可読を目的として書かれており、おそらくAIによる検索を想定しているため、それ自体が読みやすいものではありません。

^†機械的な引用で恐縮ですが、前述のとおり、論文全体が人間に解釈されることよりも「機械可読」であることを目的にこのように書かれています。ただし、JSON形式で提示するには至っていません。

初出：2026年11月4日（水）