403 Forbiddenとは、Webサーバーがリクエストの内容を理解したものの、対象リソースへのアクセスを拒否したことを示すHTTPステータスコードです。URLが存在しないことを表す404とは異なり、403エラーではサーバー側が意図的に処理を拒否しています。
原因は、ログインや閲覧権限の不足、Webサーバーの設定ミス、WAFによる遮断、IP・地域制限、短時間の過剰アクセスなどさまざまです。Webスクレイピング中に403 Forbiddenが返った場合も、すぐにUser-AgentやIPを変更するのではなく、誰が、どの環境から、どの操作をしたときに拒否されたかを切り分ける必要があります。
この記事では、一般の閲覧者、Webサイト管理者、スクレイピング担当者の立場別に、403エラーの原因と解決方法を整理します。後半では、Octoparse(オクトパース・オクトパス)で確認する実行モード、待機時間、再試行の設定も解説します。
| 確認した状況 | 考えられる原因 | 最初に行うこと |
|---|---|---|
| 普通のブラウザでも403になる | ログイン・権限・地域・サイト全体のアクセス制限 | URL、ログイン状態、利用ネットワークを確認する |
| 自分の端末だけ403になる | Cookie、VPN、IP、社内ネットワークなどの違い | 別端末・別ネットワークとの違いを切り分ける |
| ブラウザでは開けるが収集ツールでは403になる | Cookie、JavaScript、実行環境、アクセス頻度の違い | ブラウザとツールの実行条件を比較する |
| 最初は取得できるが途中から403になる | 短時間の連続アクセス、IP単位の制限、WAF | 処理を止め、ログと実行間隔を確認する |
403 Forbiddenとは？エラーの意味をわかりやすく解説
403 Forbiddenは、HTTPの4xx系に分類されるクライアントエラーです。サーバーはリクエストを受け取り、内容も理解していますが、アクセス権限やセキュリティポリシーなどの理由で処理を拒否します。HTTP仕様では、認証情報を追加しても拒否が変わらない場合に403を返すことが想定されています。詳細はMDNの403 Forbidden解説でも確認できます。
ただし、実際のWebサイトでは、WAFやCDN、アプリケーションが独自の判断で403を返すこともあります。そのため、ステータスコードだけで原因を断定せず、レスポンス本文、HTTPヘッダー、サーバーログ、直前の操作を合わせて確認することが重要です。
403と401・404・429の違いは？
| ステータスコード | 意味 | よくある原因 | 再試行の考え方 |
|---|---|---|---|
| 401 Unauthorized | 有効な認証情報が不足している | 未ログイン、期限切れトークン、認証ヘッダー不足 | 正しい認証後に再試行する |
| 403 Forbidden | サーバーがアクセスを拒否した | 権限不足、アクセス制御、WAF、IP・地域制限 | 拒否理由を確認してから判断する |
| 404 Not Found | 要求したリソースが見つからない | URL間違い、ページ削除、リンク切れ | URLや公開状態を確認する |
| 429 Too Many Requests | 一定時間内のリクエストが多すぎる | API制限、短時間の連続アクセス | 指定された時間待ち、頻度を下げる |
403が表示されてもサイト障害とは限らない
403エラーは、サーバーが正常にアクセス制御を行った結果として返される場合があります。管理画面、会員限定ページ、社内ネットワーク専用ページなどで、権限を持たない利用者を拒否するのは想定どおりの動作です。
一方、公開ページで本来閲覧できる利用者まで拒否されている場合は、設定ミスやWAFの誤検知が疑われます。「403＝サーバーが壊れた」と判断するのではなく、そのアクセスが許可されるべきものかを最初に確認してください。
403エラーはなぜ発生する？主な原因を確認
このエラーの原因は、大きく「利用者の権限」「Webサーバーの設定」「アクセス元の制限」「リクエストの挙動」に分けられます。原因と担当者を混同すると、Cookieを削除しても直らない問題に時間を使ったり、管理者が必要な問題を利用者側だけで解決しようとしたりすることになります。
閲覧権限やログイン状態に問題がある
ログインしていても、そのアカウントに対象ページの閲覧権限がなければ403が返ることがあります。セッションの期限切れ、権限変更、契約範囲外のページ、社内ネットワーク限定ページなどが代表例です。
- 一度ログアウトし、正しいアカウントでログインし直す
- URLが管理者用・社内用ではないか確認する
- 必要なロールや契約権限が付与されているか管理者へ確認する
- Cookieを削除する前に、保存済みの認証情報への影響を確認する
WebサーバーやWordPressの設定に問題がある
公開する予定のページで403が発生する場合は、サーバー設定やCMSのセキュリティ設定を確認します。ファイル・ディレクトリのパーミッション、所有者、.htaccess、WAF、WordPressのセキュリティプラグインなどが原因になり得ます。
ディレクトリURLへ直接アクセスした場合、DirectoryIndexに指定されたファイルがなく、ディレクトリ一覧も禁止されていると403が返ることがあります。ただし、すべてのWebサイトのトップページが必ずindex.htmlまたはindex.phpでなければならないわけではありません。サーバーやフレームワークの構成に合わせて確認してください。
IP・地域・ネットワークが制限されている
特定のIPアドレス、国・地域、VPN、クラウド環境からのアクセスを拒否する設定でも403 Forbiddenが発生します。自宅のWi-Fiでは開けるが会社のネットワークでは開けない、またはその逆の場合は、アクセス元の違いを確認します。
ネットワークを変更すると表示できる場合でも、それだけで「IPを変え続ければよい」と判断してはいけません。会員・社内限定のページや地域制限など、アクセス権そのものがない場合は、許可された経路や公式な利用方法を管理者へ確認します。
短時間にアクセスしすぎている
同じアクセス元から短時間に多数のリクエストが送られると、WAFやアクセス制御が403を返すことがあります。頻度制限には429が使われるのが分かりやすい実装ですが、実際には403や独自のブロックページを返すサイトもあります。
この場合は連続して再試行せず、処理を止めて、実行間隔、同時実行数、対象URL数を確認します。レスポンスにRetry-Afterが含まれている場合は、その指示に従ってください。
自動アクセスとして判定されている
ブラウザと自動収集ツールで挙動が異なる場合は、リクエストの内容や実行環境の差が判定材料になっている可能性があります。User-Agentだけでなく、Cookie、JavaScriptの実行、リクエストヘッダー、アクセス間隔、ブラウザの挙動など、複数の要素が使われます。
User-Agentを一つ変更しただけで403が解決するとは限りません。スクレイピングが途中で止まる原因と安全な設定全体は、アクセス負荷を抑えるスクレイピングのブロック対策で詳しく解説しています。
403 Forbiddenが出たときは立場別にどう対処する？
403エラーの解決方法は、一般の閲覧者、Webサイト管理者、スクレイピング担当者で異なります。自分が変更できる範囲を確認し、影響の小さい方法から順番に試してください。
一般の閲覧者が確認すること
- URLを確認する：管理画面や会員専用URLを開いていないか確認します。
- ログインし直す：セッション期限切れや別アカウントでのログインを解消します。
- 時間をおいて再確認する：一時的なアクセス制限の場合がありますが、短時間に更新を繰り返さないようにします。
- 許可されたネットワークを使う：社内ページなら社内ネットワークや指定VPNなど、管理者が案内する方法を使います。
- 対象サイトのCookieを確認する：認証状態が壊れている場合は、影響範囲を確認してから対象サイトのCookieを削除します。
- 管理者へ問い合わせる：表示時刻、URL、利用端末、画面のメッセージを伝えると原因を調べやすくなります。
セキュリティソフトやファイアウォールを一時的に無効化する方法は、端末の安全性を下げるため推奨しません。必要な場合は管理者や提供元の案内に従い、対象サイトだけを適切に許可できるか確認してください。
Webサイト管理者が確認すること
- 再現条件を整理する：全利用者か、一部IP・アカウント・URLだけかを確認します。
- アクセスログとWAFログを確認する：403を返したコンポーネントとルールを特定します。
- 権限と所有者を確認する：デプロイ後にパーミッションや所有者が変わっていないか調べます。
.htaccessやWebサーバー設定を確認する：変更前の設定と比較し、バックアップを取ってから修正します。- WordPressのプラグインを確認する：セキュリティ、ログイン制限、IP制限のログと設定を確認します。
- CDN・キャッシュを確認する：オリジンサーバーとCDNのどちらが403を返しているか切り分けます。
WAFを無効にしたまま運用するのではなく、まず検知ログを確認し、必要最小限の除外ルールを検討します。公開ページが検索エンジンにも403を返している場合は、クロールやインデックスへ影響する可能性があるため、Google Search ConsoleのURL検査とサーバーログも確認してください。
スクレイピング担当者が最初に確認すること
スクレイピング中の403 Forbiddenは、同じURLを通常のブラウザで開いた結果と比較すると切り分けやすくなります。次の順番で確認してください。
| 確認結果 | 可能性が高い原因 | 次の対応 |
|---|---|---|
| 通常ブラウザでも403 | ログイン、権限、地域、利用条件による制限 | アクセス権を確認し、許可がなければ収集を止める |
| 通常ブラウザは正常、ツールだけ403 | Cookie、JavaScript、実行環境、アクセス頻度の差 | 少量テストで条件を一つずつ比較する |
| 開始直後から全URLが403 | 実行環境やアクセス元が拒否されている | ローカル実行との違いとサイトのルールを確認する |
| 一定件数後に403 | 頻度制限、同時実行、IP単位の制限 | 停止して間隔・同時実行数・対象件数を見直す |
| ログイン後のURLだけ403 | セッションや権限の不一致 | ログインフローとCookie保持を確認する |
Pythonのrequestsやスクレイピングツールを使っている場合でも、403はHTML解析処理の失敗とは限りません。たとえばBeautiful Soupは受け取ったHTMLを解析するライブラリであり、その前段のHTTPリクエストが403を受けていれば、解析方法を変えても目的のHTMLは取得できません。
スクレイピングの403エラーで避けるべき対応は？
403 Forbiddenは「何度も試せば通るエラー」ではなく、まずアクセス条件を確認すべきシグナルです。明確な拒否に対して無制限に再試行すると、サイトへの負荷を高め、より長いアクセス制限につながる可能性があります。
- 短時間に再読込を繰り返す：原因確認より先に高頻度で再試行しない。
- すぐにIPを次々と変更する：権限や利用条件の問題はIPを変えても解決しない。
- Googlebotなど第三者を名乗る：検索エンジンを装うUser-Agentを利用しない。
- ログイン・有料ページの制限を回避する：付与されていない権限を技術的に取得しようとしない。
- 利用規約を確認しない：自動取得の可否、API、robots.txt、問い合わせ窓口を確認する。
- すべての403をUser-Agentの問題と決めつける：ログ、Cookie、実行環境、頻度を含めて診断する。
robots.txtは法的な許可書ではありませんが、運営者が示すクロール方針を確認する材料になります。自動取得の可否を判断する手順は、スクレイピング可能なサイトを見分ける確認項目も参照してください。
Octoparseで403エラーを診断する7つの手順
Octoparseで403エラーが発生した場合も、最初から複数のブロック対策を同時に有効化するのではなく、条件を一つずつ比較します。どの変更で結果が変わったか分からなくなるのを防ぐため、少量のURLでテストしてください。
ステップ1｜通常のブラウザとOctoparseの表示結果を比較する
同じURLを通常のブラウザとOctoparseの内蔵ブラウザで開きます。両方で403が表示される場合は、ツール設定より先に、ログイン、権限、対象サイトの利用条件を確認します。
ブラウザでは正常でもOctoparseだけ403になる場合は、実行モード、Cookie、JavaScript、待機時間、アクセス頻度などの違いを確認します。
ステップ2｜ローカルの実行モードを比較する
Octoparseのローカル実行では、通常モード、バックグラウンドモード、Chromeモードを選択できます。ChromeモードはローカルのGoogle Chromeを使い、手動ログインや複雑な操作が必要なページの確認に向いています。バックグラウンドモードは画面を表示せずに実行でき、ログイン不要で比較的単純なページに向いています。
実行モードを変えれば必ず403が解決するわけではありません。公式ヘルプのChromeモードとバックグラウンドモードの違いを確認し、対象ページの要件に合うモードを選びます。
ステップ3｜ログインとCookieの状態を確認する
会員ページでは、ログインに成功した画面だけでなく、実行中もセッションが維持されているかを確認します。編集画面でログインできても、本実行時に別の環境や期限切れCookieを使えば403になることがあります。
ログインページ、二要素認証、利用者ごとの権限がある場合は、許可されたアカウントと手順を使用してください。Chromeモードで手動ログインした場合も、対象サービスの規約と社内の認証情報管理ルールに従います。
ステップ4｜実行間隔と待機時間を見直す
一定件数の取得後に403が出る場合は、アクセス間隔と同時実行数を見直します。まず処理件数を減らし、ページが読み込まれる前に次の操作へ進んでいないか、短時間に同じドメインへアクセスしていないかを確認してください。
待機時間は、単に長くすればよいわけではありません。対象サイトのレスポンス時間と許容されるアクセス頻度に合わせて設定し、必要以上の並列処理を避けます。
ステップ5｜失敗条件と再試行回数を設定する
Octoparseの再試行機能では、ページ内の文字列、URL、要素の有無などを条件にして再読込できます。403のメッセージだけでなく、正常時に存在する要素が表示されない場合を失敗条件にする方法もあります。
最大回数と実行間隔を必ず設定し、403が続く状態で無制限に再試行しないでください。設定方法はOctoparse公式ヘルプの再試行ガイドで確認できます。
ステップ6｜ローカル実行とクラウド実行の差を確認する
ローカル実行では開けるのにクラウド実行で403になる場合は、アクセス元のIP、地域、Cookie、ログイン状態、実行速度などの環境差が関係している可能性があります。逆の場合も同様です。
クラウド実行やプロキシを「403を突破する手段」として先に選ぶのではなく、なぜ環境によって結果が変わるかを確認します。IP制限と運用方法の詳細は、スクレイピングにおけるIPローテーションの仕組みと注意点へ分けています。
ステップ7｜データ取得を継続してよいか判断する
設定を変える前に、対象情報が公開情報か、利用規約で自動取得が許可されているか、公式APIやデータダウンロードがないかを確認します。ログイン権限がない、アクセス禁止が明示されている、CAPTCHAが繰り返し表示されるといった場合は、収集を止めて運営者へ確認してください。
Octoparseの機能はどの403原因を確認できる？
Octoparseの各機能は、403 Forbiddenの原因を比較・診断するために使えます。ただし、アクセス権のないページを閲覧可能にする機能ではありません。原因と対応する設定を次の表で確認してください。
| 403の原因候補 | 確認に使えるOctoparse機能 | 確認できること | 注意点 |
|---|---|---|---|
| ログイン・セッション | Chromeモード、ローカル実行 | 手動ログインを含むブラウザ環境との差 | 権限のないページにはアクセスできない |
| JavaScript・Cookie | 通常モード、Chromeモード | ブラウザ実行環境による表示差 | サイト側のアクセス条件を優先する |
| アクセス頻度 | 操作前後の待機、実行間隔 | 連続アクセスを抑えたときの結果 | 許容頻度は対象サイトごとに異なる |
| 一時的な読込失敗 | 条件付き再試行 | 正常要素やエラーメッセージによる判定 | 最大回数を設定し、無限再試行を避ける |
| 実行環境の差 | ローカル実行、クラウド実行 | IP・地域・セッションなどの違い | クラウド機能はプランにより異なる |
| User-Agent | プリセット・カスタムUA | 端末・ブラウザ情報による表示差 | 変更しても403が解決するとは限らない |
User-Agentの仕組みと詳細設定を確認したい場合は、スクレイピング用User-Agentの設定ガイドを参照してください。UAだけを変更するのではなく、対象デバイス、Cookie、HTTPヘッダー、アクセス間隔の整合性を確認する必要があります。
まず1～3件のURLで、通常ブラウザとOctoparseのどこから結果が変わるかを確認しましょう。無料アカウントを作成し、ローカル実行で少量テストすると、対象ページと実行環境の相性を判断できます。
競合情報も営業リストも、ウェブデータをそのままExcel・CSV・Google Sheetsに出力
コード不要、誰でも今日から。クリック操作だけで必要な項目を自動抽出
Google Maps・食べログ・iタウンページ向けテンプレートで、リード獲得をすぐに開始
クラウドで毎日・毎週自動実行。大量取得でも安定して、競合動向を常に把握
MCP対応でAIエージェントと連携。収集データをAIに渡して分析・活用まで一気通貫
クレジットカード不要で無料スタート。世界600万人以上が選んだ信頼のツール
403エラーが解決しない場合はどうする？
403 Forbiddenが解決しない場合は、技術的な設定変更を増やす前に、別の正規な取得方法を検討します。
- 公式APIを確認する：仕様、認証、レート制限に従って取得します。
- CSVやオープンデータを確認する：サイトが提供するダウンロード機能を優先します。
- 運営者へ許可を求める：用途、対象データ、件数、頻度を伝えて相談します。
- 正規のデータ提供サービスを利用する：利用条件とデータの出所を確認します。
- 対象サイトからの取得を中止する：許可を確認できない場合は無理に継続しません。
Webスクレイピングは公開情報の収集を効率化できる一方、技術的に取得できることと、取得・利用してよいことは同じではありません。利用規約、個人情報、著作権、データベースの権利、サーバー負荷を確認し、必要に応じて専門家へ相談してください。
まとめ｜403は原因を特定してから対処しよう
403 Forbiddenは、サーバーがリクエストを理解しながら、対象リソースへのアクセスを拒否したことを表します。ログインや権限、Webサーバー設定、WAF、IP・地域制限、アクセス頻度など原因が幅広いため、一般閲覧者、管理者、スクレイピング担当者の立場を分けて診断することが重要です。
スクレイピング中に403エラーが出た場合は、通常ブラウザとの違いを確認し、少量テストで実行モード、Cookie、待機時間、再試行条件を比較します。アクセス禁止が明示されている場合や権限を確認できない場合は、無理に設定を変え続けず、公式APIや運営者への確認など別の方法を選んでください。
Octoparseを試す場合も、まず少数のURLをローカルで実行し、対象サイトへ過度な負荷をかけない設定から始めましょう。
403 Forbiddenについてよくある質問
Q1. 403 Forbiddenは自分だけに表示されることがありますか？
あります。IPアドレス、利用ネットワーク、ログイン状態、アカウント権限、Cookie、VPNなどが他の利用者と異なる場合、自分の環境だけ403エラーになることがあります。別端末・別ネットワークとの違いを比較し、アクセス権があるか確認してください。
Q2. 403と401の違いは何ですか？
401は、主に有効な認証情報が不足している状態です。403は、サーバーがリクエストを理解したうえでアクセスを拒否している状態です。ただし、実際のサービスではセキュリティ上の理由から厳密に使い分けない場合もあります。
Q3. キャッシュやCookieを削除すれば403は直りますか？
認証Cookieの破損や期限切れが原因なら直る可能性があります。しかし、権限不足、WAF、IP・地域制限が原因の場合は解決しません。Cookieを削除するとログイン情報が消えるため、対象サイトと影響範囲を確認してから実行してください。
Q4. スクレイピングでUser-Agentを変えれば403は解決しますか？
必ず解決するわけではありません。現代のアクセス制御はUser-Agentだけでなく、Cookie、JavaScript、IP、リクエストヘッダー、操作パターンなど複数の情報を確認します。まず通常ブラウザとの違いとサイトの利用条件を確認してください。
Q5. プロキシやIPローテーションを使えば必ず取得できますか？
取得できる保証はありません。ログイン権限や利用条件による拒否はIPを変更しても解決しません。また、拒否を受けたままアクセス元だけを変更し続ける行為は推奨できません。アクセス頻度、許可、公式APIの有無を先に確認します。
Q6. Octoparseで403が出たら最初に何を確認すべきですか？
Octoparse(オクトパース・オクトパス)で403が出た場合は、同じURLを通常のブラウザで開き、両方で拒否されるかを最初に確認します。ブラウザだけ正常なら、少量のURLで実行モード、ログイン・Cookie、待機時間、再試行条件を一つずつ比較してください。
競合情報も営業リストも、ウェブデータをそのままExcel・CSV・Google Sheetsに出力
コード不要、誰でも今日から。クリック操作だけで必要な項目を自動抽出
Google Maps・食べログ・iタウンページ向けテンプレートで、リード獲得をすぐに開始
クラウドで毎日・毎週自動実行。大量取得でも安定して、競合動向を常に把握
MCP対応でAIエージェントと連携。収集データをAIに渡して分析・活用まで一気通貫
クレジットカード不要で無料スタート。世界600万人以上が選んだ信頼のツール
