【ITニュース解説】You got a 403. It probably isn't about the page.

Webサイトにアクセスしようとした際、「403 Forbidden」のようなエラーメッセージに遭遇することがある。多くの人は、これは「ページが存在しない」あるいは「一般公開されていない」といった、アクセス先のページそのものに原因があると考えがちだ。しかし、このニュース記事が指摘するのは、そのエラーの原因のほとんどが「アクセスしようとしているあなたのコンピューターやプログラムのアクセス方法」にある可能性が高い、という非常に重要な視点である。

本記事の筆者は、Webサイトがアクセスを拒否する際に、その拒否がページ自体にあるのか、それともアクセス元にあるのかという疑問から、この検証を始めた。この疑問を解決するため、様々な「ノッカー」、つまり異なるアクセス方法を試行し、その応答を詳しく調査している。

具体的に試されたアクセス方法には、主に三つの種類がある。一つ目は「生身のサンドボックス（Raw sandbox）」と呼ばれる方法だ。これは、Webサーバーに対して、特別な設定や追加機能なしに、プログラムが直接HTTPリクエストを送信するような、非常にシンプルで素朴なアクセスを指す。まるで直接ドアを叩くような行為に例えられるだろう。二つ目は「公共の読者サービス（Public reader service）」だ。これは、Webページの内容を整形して読みやすく提供するサービスや、特定の目的のためにWebサイトにアクセスするプログラムを指す。人間が見るための情報を提供することが多いが、一般的なWebブラウザとは異なる振る舞いをすることがある。三つ目は「クラウドブラウザ（Cloud browser）」だ。これは、Google ChromeやFirefoxといった一般的なWebブラウザが持つ機能（JavaScriptの実行、Cookieの管理、ユーザーエージェントの送信など）をクラウド上で再現した環境を指す。これは、あたかも人間が通常のブラウザを使っているかのように振る舞うため、「より人間らしい」アクセス方法であると言える。

これらの異なるノッカーを用いて、筆者は複数の主要なWebサイトへのアクセスを試み、その結果を報告している。

まず、reddit.comへのアクセスでは、生身のサンドボックスや公共の読者サービスを用いると、どちらも「403 Forbidden」というアクセス拒否のエラーが発生した。しかし、クラウドブラウザでアクセスすると、最初は正常にページが表示されたものの、その後「人類であることを証明しろ」という認証を求められ、最終的には短時間での多数のリクエストが原因で「429 Too Many Requests」というエラーになった。この結果は、Redditが単純にページ全体をブロックしているわけではなく、アクセスしてくるクライアントが「ブラウザらしい振る舞いをしているか」を厳しくチェックしていることを示している。

次に、wsj.com（The Wall Street Journal）へのアクセスでは、生身のサンドボックスからは「401 Unauthorized」という認証を求めるエラーが返され、同時に「DataDome」というセキュリティシステムによるブロックが確認された。公共の読者サービスからは「CAPTCHA（キャプチャ）」認証が求められた。しかし、クラウドブラウザからアクセスすると、問題なくホームページ全体が表示され、株価のリアルタイム表示なども確認できた。ここでもDataDomeのようなセキュリティシステムが、プログラムによる自動アクセスと人間によるアクセスを高い精度で見分けていることがわかる。

nytimes.comの検索ページへのアクセスも同様の傾向を示している。生身のサンドボックスからは「403 Forbidden」エラーが返され、その応答ヘッダーにはDataDomeによって「ボットである可能性が0.954（ほぼ確実）」という判定結果が記録されていた。しかし、公共の読者サービスやクラウドブラウザからは、問題なく検索結果が表示された。この事例も、アクセス方法によってWebサイト側の判断が変化するというパターンを裏付けている。

bloomberg.comへのアクセスでも、生身のサンドボックスからは「403 Forbidden」エラー（Varnishというキャッシュシステムによるもの）が発生したが、公共の読者サービスからはコンテンツが正常に表示された。これも、クライアントの特性がアクセス可否の鍵を握っている事例である。

ただし、ticketmaster.comのケースは例外的な振る舞いを示している。生身のサンドボックスからは「403 Forbidden」、公共の読者サービスからは「429 Browsing Activity Paused」というエラーが発生した。この事例では、複数の異なるアクセス方法を試してもブロックされたため、アクセス先の「ページそのもの」または「そのページへのアクセス数」に起因するブロックの可能性が示された。これは、すべての「ノー」がクライアント依存ではないことを示す貴重な反例である。

これらの検証結果から得られる結論は、システムエンジニアを目指す初心者にとって非常に重要だ。Webサイトから「403 Forbidden」のようなエラーが返ってきた場合、それは自分のコンピューターやプログラムのアクセス方法に問題がある可能性が高いと理解すべきである。安易に「そのページはもうない」「誰もアクセスできない」と判断する前に、まずは一般的なWebブラウザを使ってアクセスを試してみるべきだ。もしブラウザでアクセスが成功するならば、問題は「あなたのアクセス方法」にあったことになる。

また、Webサーバーからの応答に含まれる「レスポンスヘッダー」という技術的な情報には、「DataDome」「CloudFront」「Varnish」「snooserv」といったセキュリティシステムやネットワークサービスの名前が含まれていることがある。これらの情報を見ることで、どのシステムがアクセス可否を判断しているのか、ブロックの理由に関するヒントを得ることができる。

「私はブロックされている」という個人的な状況と、「誰もそのページにアクセスできない」という普遍的な状況は全く異なる主張である。まずは前者の可能性を検証し、それでもアクセスできない場合に初めて後者の可能性を検討するという習慣を持つことが重要だ。本記事の筆者はAIエージェントであるため、人間による直接のアクセス検証ができていないとし、読者に協力を呼びかけている。システムエンジニアとしてWebサービス開発や利用に携わる際には、このようなWebサイトのセキュリティ機構やアクセス制御の仕組みを理解しておくことが、問題解決において非常に役立つだろう。