【2026年版】401エラー（Unauthorized）の原因と解決方法｜ウェブサイト・API・WordPress完全ガイド

公開日：2024/09/17　更新日：2026/03/16　

※本ページにはプロモーション(広告)が含まれています

ウェブサイトを開こうとしたら突然「401 Unauthorized」と表示された――そんな経験をしたことがある方は多いはずです。

この記事では、401エラーが発生する原因と状況別の解決方法を、一般ユーザーからAPI開発者・WordPressサイト管理者まで、それぞれの視点でわかりやすく解説します。

この記事でわかること

401エラーの意味と仕組み（403エラーとの違いも解説）
一般ユーザーがすぐできる対処法（キャッシュ・ログイン・パスワードリセット）
WordPressで401エラーが出るときの原因と修正手順
API開発者向け：認証ヘッダー・トークン・OAuth の確認ポイント
.htaccess・Nginx の設定で401が出るケースの対処法
よくある質問10問への回答

401エラー（Unauthorized）とは何か

HTTPステータスコードとは

ウェブサイトにアクセスするとき、ブラウザ（クライアント）とウェブサーバーは「HTTP」というプロトコルで通信しています。サーバーはリクエストを受けると、処理結果を示す3桁の数字（HTTPステータスコード）とともに応答を返します。

コード帯	意味	代表例
200番台	成功	200 OK（正常表示）
300番台	リダイレクト	301 Moved Permanently
400番台	クライアントエラー	401・403・404
500番台	サーバーエラー	500・503

401エラーの意味

401 Unauthorized は「認証が必要（または認証に失敗した）」ことを示すステータスコードです。日本語に直訳すると「無許可」ですが、正確には「正しい認証情報が提供されなかったため、アクセスを拒否した」という意味です。

サーバーは401を返す際に WWW-Authenticate ヘッダーも送信し、どのような認証方式が必要かをブラウザに伝えます。ブラウザはその情報を元に認証ダイアログを表示したり、ログインページにリダイレクトしたりします。

401エラーと403エラーの違い

似ているようで本質的に異なります。混同しやすいので以下の表で整理します。

項目	401 Unauthorized	403 Forbidden
意味	認証されていない（誰かわからない）	認証済みだがアクセス権がない
認証の状態	未認証または認証失敗	認証済み（ログイン済み）
再認証の効果	正しい認証情報を提供すれば解決する可能性あり	再認証しても解決しない
典型的なケース	ログインページ未通過・トークン期限切れ	管理者ページへの一般ユーザーアクセス

覚え方：401は「まだ名乗っていない（または間違えた）」、403は「名乗ったけど入れない（権限なし）」です。

どんな画面が表示されるか

401エラーの見え方はサーバーやサービスによって異なります。

ブラウザの認証ダイアログ（ポップアップ）：Basic認証を設定しているサイトでユーザー名とパスワードを求める
サービス独自のエラーページ：「401 Unauthorized」「ログインが必要です」などのメッセージ
JSONレスポンス（API利用時）：{"error": "Unauthorized", "message": "Invalid token"} など

【一般ユーザー向け】401エラーの原因と対処法

日常的にウェブサービスを使っていて401エラーに遭遇した場合、以下の手順を順番に試してください。

対処法1：正しいID・パスワードでログインする

最もよくある原因は、ログイン情報の入力ミスです。メールアドレス・ユーザー名・パスワードを再確認してください。

ログインページを開く
メールアドレス（またはユーザー名）とパスワードを再入力する
Caps Lock（大文字ロック）がオフになっているか確認する
パスワードに半角・全角のスペースが混入していないか確認する

パスワードを忘れた場合は「パスワードを忘れた場合」リンクからリセットメールを送信してください。

対処法2：ブラウザのキャッシュ・Cookieをクリアする

古い認証情報がキャッシュやCookieに残っていると、ログイン状態の不整合が起きて401エラーが発生することがあります。

Google Chrome でキャッシュをクリアする手順

Chrome を開き、右上の「︙」→「設定」をクリック
「プライバシーとセキュリティ」→「閲覧履歴データを削除」を選択
「期間」を「全期間」に変更
「キャッシュされた画像とファイル」と「Cookie と他のサイトデータ」にチェック
「データを削除」をクリック
ページを再読み込みしてログインし直す

Safari でキャッシュをクリアする手順

メニューバーの「Safari」→「設定（環境設定）」を開く
「プライバシー」タブ →「ウェブサイトデータを管理」をクリック
対象サイトを選択して「削除」または「すべてを削除」
Safari を再起動してログインし直す

Firefox でキャッシュをクリアする手順

右上の「≡」メニュー→「設定」を開く
「プライバシーとセキュリティ」→「Cookieとサイトデータ」→「データを消去」
「Cookieとサイトデータ」と「ウェブコンテンツのキャッシュ」にチェックして「消去」
ページを再読み込みしてログインし直す

対処法3：シークレット（プライベート）モードで試す

拡張機能やキャッシュが影響していないかを切り分けるために、シークレットモードでアクセスしてみましょう。

Chrome：Ctrl+Shift+N（Mac は ⌘+Shift+N）
Safari：⌘+Shift+N
Firefox：Ctrl+Shift+P（Mac は ⌘+Shift+P）

シークレットモードでは正常にアクセスできる場合、通常モードに保存されているCookieまたは拡張機能が原因です。

対処法4：別のブラウザを試す

特定のブラウザのバグや拡張機能が原因の場合があります。Chrome・Firefox・Edge・Safari など、普段使っていないブラウザでアクセスしてみてください。

対処法5：時間を置いて再アクセス

サービス側のサーバー障害や認証システムのトラブルが原因の場合は、ユーザー側での対処が困難です。X（旧Twitter）やサービスの公式サポートページで同様のトラブル報告がないか確認し、復旧を待ちましょう。

【WordPress管理者向け】WordPressで401エラーが出る原因と対処法

WordPressサイトを運営していると、REST APIのアクセスや管理画面ログイン時に401エラーが発生するケースがあります。主な原因と対処法を解説します。

原因1：.htaccessによるBasic認証が干渉している

ステージング環境や非公開サイトでよくある設定です。.htaccess に Basic認証を設定している場合、WordPress REST APIのリクエストにも認証が要求されてしまい、プラグインや外部ツールが401エラーになります。

確認方法：.htaccess に以下のような記述がないか確認してください。

AuthType Basic
AuthName "Restricted"
AuthUserFile /path/to/.htpasswd
Require valid-user

対処法：REST APIへのアクセスだけBasic認証を除外するには、以下を .htaccess に追記します。

# WordPressのREST APIをBasic認証から除外
<If "%{REQUEST_URI} =~ m|^/wp-json/|">
  Satisfy Any
  Allow from all
</If>

原因2：アプリケーションパスワードが設定されていないまたは誤っている

WordPress 5.6以降は「アプリケーションパスワード」機能が標準搭載されています。REST APIに外部からアクセスする場合はアプリケーションパスワードを使います。

アプリケーションパスワードの設定手順：

WordPress管理画面にログイン
「ユーザー」→「プロフィール」を開く
下部の「アプリケーションパスワード」セクションで名前を入力して「新しいアプリケーションパスワードを追加」
生成されたパスワード（スペース区切りの文字列）をコピーして保管

REST API リクエスト時は Authorization: Basic base64(username:app_password) ヘッダーを付与します。

原因3：セキュリティプラグインがREST APIをブロックしている

Wordfence・iThemes Security・All In One WP Security などのセキュリティプラグインが REST API へのアクセスを制限している場合があります。

確認・対処手順：

管理画面でセキュリティプラグインの設定を開く
REST APIへのアクセス制限設定を探し、「ログインユーザーのみ許可」から「すべて許可」または「認証済みリクエストを許可」に変更する
プラグインを一時的に無効化して問題が再現しないか確認する

原因4：SSL証明書の問題（Mixed Content）

サイトがHTTPSなのに一部リソースがHTTPで読み込まれている場合、認証Cookieが正しく送信されず401エラーになることがあります。ブラウザの開発者ツール（F12）の「コンソール」タブでMixed Contentエラーが出ていないか確認してください。

原因5：wp-config.phpでREST APIが無効化されている

古いチュートリアルでは、セキュリティ対策として REST APIを無効化するコードを wp-config.php や functions.php に追加する方法が紹介されていました。以下のようなコードが含まれていないか確認してください。

// REST APIを無効化するコード（これが原因の場合は削除または条件変更）
add_filter('rest_authentication_errors', function($result) {
  if (!is_user_logged_in()) {
    return new WP_Error('rest_not_logged_in', '…', ['status' => 401]);
  }
  return $result;
});

【API開発者向け】APIで401エラーが出る原因と解決方法

REST APIやWeb APIを開発・利用していて401エラーが発生した場合、認証まわりのどこかで問題が起きています。チェックリスト形式で確認してください。

認証方式ごとの確認ポイント

認証方式	よくある原因	確認ポイント
APIキー	キーの打ち間違い・有効期限切れ	管理画面で再発行・コピペを確認
Bearer Token（JWT）	トークン期限切れ・署名エラー	jwt.io でデコードして exp を確認
Basic認証	Base64エンコードのミス	`user:password` をBase64変換して確認
OAuth 2.0	アクセストークン期限切れ・スコープ不足	リフレッシュトークンで再取得・スコープ見直し

Authorizationヘッダーの確認

最もよくある間違いは、Authorizationヘッダーの書式ミスです。

# 正しい例（Bearer認証）
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9…

# よくある間違い（Bearerのスペルミス、スペースなし）
Authorization: bearer TOKEN   # ← "bearer" は小文字でも多くは動くが規格外
Authorization: BearerTOKEN   # ← スペースが抜けている → 401になる

Bearer Token（JWT）の期限切れ確認

JWTトークンには有効期限（exp クレーム）が設定されています。期限が切れると自動的に401が返ります。

jwt.io にアクセス
JWTトークン文字列を貼り付け
右側の「Payload」に表示される exp の値（Unix タイムスタンプ）を確認
現在時刻より過去なら期限切れ → トークンを再発行する

OAuth 2.0 で401が出るときの対処

OAuthフローで401が出る場合は以下を順番に確認します。

アクセストークンの有効期限を確認：多くのサービスで1時間程度で失効する
リフレッシュトークンを使って再取得する：grant_type=refresh_token でトークンエンドポイントをたたく
スコープを確認する：要求しているリソースにアクセスできるスコープが付与されているか
クライアントID・シークレットを確認する：開発環境と本番環境で設定が混在していないか
リダイレクトURIの一致を確認する：認可サーバーに登録したURIとリクエストのURIが完全一致しているか

curl でデバッグする方法

APIのデバッグには curl -v（詳細出力）が便利です。リクエストヘッダーとレスポンスヘッダーを両方確認できます。

# Authorizationヘッダーを付けてAPIにアクセス（-v でヘッダーを表示）
curl -v -H "Authorization: Bearer YOUR_TOKEN" https://api.example.com/endpoint

# レスポンスヘッダーの確認ポイント：
# < HTTP/1.1 401 Unauthorized
# < WWW-Authenticate: Bearer realm="example", error="invalid_token"
#                          ↑ ここのerrorメッセージで原因が分かる

WWW-Authenticate レスポンスヘッダーの error 値の意味：

invalid_token：トークンが無効（期限切れ・署名エラー）
expired_token：トークンの有効期限切れ
invalid_request：リクエスト形式が不正

【サーバー管理者向け】.htaccessとNginxで401エラーを設定・修正する

Apacheの.htaccessでBasic認証を設定する

特定のディレクトリにBasic認証を設定すると、認証なしのアクセスに対して401が返ります。正しい設定方法と、よくある設定ミスを解説します。

基本的な.htaccess設定例（Apacheの場合）：

AuthType Basic
AuthName "Members Only"
AuthUserFile /home/username/.htpasswd
Require valid-user

よくある設定ミスと修正方法：

ミスの内容	症状	修正方法
`AuthUserFile` のパスが間違っている	常に401が返る（正しいパスワードでも通らない）	絶対パスを使い、`.htpasswd` の実際のパスを指定
`.htpasswd` の文字コードが誤っている	認証ダイアログは出るが通らない	`htpasswd` コマンドで正しく生成し直す
`AllowOverride` が `None` になっている	.htaccess が無視されて設定が効かない	`httpd.conf` で `AllowOverride AuthConfig` に変更

.htpasswdファイルの正しい生成方法（コマンドライン）：

# 新規作成（-c オプション）
htpasswd -c /home/username/.htpasswd username

# ユーザー追加（-c なし）
htpasswd /home/username/.htpasswd newuser

NginxでBasic認証を設定・修正する

Nginxの場合、auth_basic ディレクティブで認証を設定します。

Nginx設定例（nginx.conf またはサイト設定ファイル）：

server {
  listen 443 ssl;
  server_name example.com;

  location / {
    auth_basic "Members Only";
    auth_basic_user_file /etc/nginx/.htpasswd;
    # 認証が不要なパスは除外する
    # location /api/ { auth_basic off; }
  }
}

Nginxで401が出るときのチェック項目：

auth_basic_user_file のパスが正しいか：nginx -t で設定ファイルの構文チェック
.htpasswdファイルのパーミッションを確認：Nginxのワーカープロセスが読み取れるか（nginx ユーザーがreadableか確認）
設定変更後にリロードしているか：sudo nginx -s reload または sudo systemctl reload nginx
エラーログを確認する：/var/log/nginx/error.log に詳細なエラーメッセージが記録されている

カスタム401エラーページを設定する

デフォルトのブラウザ認証ダイアログではなく、独自のエラーページを表示することでユーザー体験を改善できます。

Apache（.htaccess）の場合：

ErrorDocument 401 /401.html

Nginxの場合：

error_page 401 /401.html;

【状況別まとめ】401エラーの原因と対処法一覧

状況	主な原因	まず試すこと
ウェブサイト閲覧中に突然401	セッション切れ・Cookie破損	キャッシュ削除 → ログインし直す
ログインしても401が続く	パスワード間違い・アカウント無効化	パスワードリセット・サポートに問い合わせ
WordPressのREST APIで401	アプリケーションパスワード未設定・Basic認証干渉	アプリパスワード再設定・.htaccess確認
APIリクエストで401	トークン期限切れ・ヘッダー書式ミス	トークン再発行・curl -v でヘッダー確認
.htaccessのBasic認証で401	`AuthUserFile` パス誤り・.htpasswd書式エラー	絶対パス確認・`htpasswd` コマンドで再生成
Nginxで401が返る	auth_basic_user_fileのパス誤り・権限不足	`nginx -t` でテスト・エラーログ確認

よくある質問（FAQ）

Q1. 401エラーと403エラーはどう違うのですか？

401は「誰であるかが確認できない（認証されていない）」ため弾かれているエラー、403は「誰であるかは確認できているが（認証済み）、そのリソースへのアクセス権限がない」ために弾かれているエラーです。401は正しい認証情報を提供することで解決できる可能性がありますが、403は認証をやり直しても通常は解決しません。

Q2. 401エラーが出てもサイト自体は生きていますか？

はい。401はサーバーが正常に動作していてリクエストを処理できているからこそ返ってくるレスポンスです。サーバーダウンの場合は500番台や接続エラーになります。

Q3. VPNを使うと401エラーが解決することがありますか？

IPアドレスによるアクセス制限（特定の国・地域からのアクセスをブロックする設定）が原因の場合、VPNで別の地域のIPに変更することで解決することがあります。ただし、通常の認証エラーはVPNでは解決しません。

Q4. パスワードが正しいはずなのに毎回401が返ります。

以下の点を確認してください。（1）Caps Lockがオフになっているか、（2）パスワードに全角スペースが混入していないか、（3）ブラウザのパスワードマネージャーが古いパスワードを自動入力していないか、（4）アカウントが一時停止またはロックされていないか（運営者に確認が必要です）。

Q5. APIで401が出たり出なかったりと不安定です。

トークンの有効期限が近い場合にこのような現象が起きやすいです。アクセストークンの exp（有効期限）を確認し、期限切れ前に自動でリフレッシュするロジックを実装してください。また、サーバー側の時刻ずれ（NTPの問題）でJWTの有効期限判定がおかしくなるケースもあります。

Q6. WordPressでプラグインをインストールしたら401が出るようになりました。

セキュリティ系プラグインやキャッシュプラグインが認証フローを妨げている可能性があります。プラグインを1つずつ無効化して再現するプラグインを特定してください。プラグイン管理画面にアクセスできない場合は、FTPまたはSSHでサーバーにアクセスし、wp-content/plugins/ 内の問題のあるプラグインのフォルダ名を変更（例：problematic-plugin.disabled）することで強制無効化できます。

Q7. CORSと401エラーは関係ありますか？

直接の原因ではありませんが、CORSの設定が不適切な場合、認証ヘッダーを含む OPTIONS プリフライトリクエストが401を返すことがあります。サーバー側で Access-Control-Allow-Headers: Authorization および Access-Control-Allow-Credentials: true が設定されているか確認してください。

Q8. OAuth 2.0 で認証したのにAPIが401を返します。

以下を確認してください。（1）アクセストークンが有効期限内か（exp を確認）、（2）スコープが十分か（要求しているリソースへのアクセスが含まれているか）、（3）Authorization: Bearer TOKEN ヘッダーの書式が正しいか、（4）本番環境と開発環境でクライアントIDまたはシークレットが混在していないか。

Q9. 自分のサイトで401ページをカスタマイズできますか？

Apache では .htaccess に ErrorDocument 401 /your-custom-401.html を追記することでカスタムページを表示できます。Nginx では nginx.conf に error_page 401 /your-custom-401.html; を設定します。ただし、Basic認証のダイアログ（ブラウザネイティブのポップアップ）はこの方法ではカスタマイズできません。

Q10. 401エラーはSEOに影響しますか？

Googlebot がクロールしようとしたページで401が返ると、そのページはインデックスされません。意図的に認証をかけているページであれば問題ありませんが、公開したいページが誤って401を返している場合はSEOに悪影響があります。Google Search Console の「カバレッジ」レポートで401エラーのページを確認できます。