WordPress で数分〜数時間おきにログアウトされる場合、原因の多くは「URL の不一致による Cookie のずれ」「プロキシや CDN 経由での HTTPS 判定の失敗」「ページキャッシュ」「プラグインによる有効期限の短縮」のいずれかです。この記事では、まず症状と Cookie の状態から原因を絞り込み、起きやすい順に確認方法と直し方を説明します。有効期限そのものを変えたい場合ではなく、「設定した覚えがないのにログアウトされる」場合の切り分けに絞った内容です。
まず症状を整理する
同じ「ログアウトされる」でも、起き方で疑う場所が変わります。どれに近いかを先に確かめてください。
- 管理画面に入ろうとするとログイン画面に戻される（ログインしても繰り返す）：URL の不一致、または HTTPS 判定の問題
- 管理画面ではログイン中なのに、サイト表示側ではログアウトしているように見える：ページキャッシュや CDN
- 数時間など、ほぼ一定の間隔でログアウトされる：プラグインやテーマによる有効期限の変更、無操作ログアウト機能
- ある時点で全員が一斉にログアウトされた：認証用キー（ソルト）の変更やセッション情報の消失
- スマートフォンの回線や移動中に多い：IP アドレスの変化を見ているセキュリティ機能
なお、WordPress は PHP のセッション機能を使っていません。php.ini の session.gc_maxlifetime を延ばしても、この問題は直りません。
Cookie の状態を見る
原因を絞るために、ブラウザの開発者ツールで Cookie を確認します。Chrome や Edge なら「アプリケーション」タブ、Firefox なら「ストレージ」タブから、サイトの Cookie を開きます。
wordpress_logged_in_で始まる Cookie があるか- その Cookie の「ドメイン」が、いま開いている URL のホスト名と一致しているか（
wwwの有無も含む） - 有効期限が「セッション」または想定どおりの日時になっているか
- HTTPS のサイトなら
wordpress_sec_で始まる Cookie もあるか
ログイン直後にこれらがあるのに、少し後に消える、または別のホスト名に付いている、といった違いが手がかりになります。Cookie の値は他人に見せてはいけない情報なので、相談の際にも値は伏せてください。
原因1：サイトの URL が一致していない
もっとも多い原因です。「設定」→「一般」の「WordPress アドレス」と「サイトアドレス」で、www の有無や http と https が食い違っていると、ログイン Cookie が片方のホストにしか付かず、もう一方へ移動したときにログアウト扱いになります。
確認：2つのアドレスを見比べます。wp-config.php に WP_HOME や WP_SITEURL が定義されている場合は、そちらが優先されるので、あわせて確認します。COOKIE_DOMAIN を定義している場合は、その値が実際のホスト名と合っているかも見ます。
対処：両方を同じホスト名・同じ https にそろえ、もう一方の URL はサーバー側で301リダイレクトします。管理画面に入れない場合は wp-config.php に正しい値を定義して直せます。変更前には wp-config.php とデータベースのバックアップを取ってください。
原因2：プロキシや CDN の後ろで HTTPS と判定されていない
ロードバランサーや CDN が HTTPS を受け、WordPress には HTTP で中継している構成では、WordPress が「HTTP で接続されている」と判断します。すると HTTPS 用の Cookie を正しく扱えず、管理画面へのアクセスでログイン画面に戻される状態が続きます。
確認：サーバー構成でプロキシや CDN を使っているか、ホスティング会社のマニュアルで HTTPS の扱いを確認します。
対処：プロキシが付ける X-Forwarded-Proto ヘッダーを見て、HTTPS として扱うよう wp-config.php に追記します。/* That's all, stop editing! */ の行より上に書いてください。
// 信頼できるプロキシ・CDN の後ろにいる場合のみ使う
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
$_SERVER['HTTPS'] = 'on';
}このヘッダーは利用者側から偽装できるため、プロキシを通らずに直接サーバーへ接続できる構成では使い方に注意が必要です。ホスティング会社が独自の設定方法を案内している場合は、そちらを優先します。
原因3：ページキャッシュや CDN がログイン状態を壊している
ページキャッシュや CDN が、ログイン中のページを保存して他の人に配ったり、Set-Cookie を含む応答をキャッシュしたりすると、ログイン状態が正しく反映されません。「フロント側だけログアウトに見える」「管理バーが出たり消えたりする」症状が典型です。
確認：ページの応答ヘッダーに、キャッシュヒットを示す値（X-Cache や CDN 独自のヘッダーなど）が出ていないか確認します。キャッシュを一時的に無効にして症状が消えるかも試します。
対処：キャッシュプラグインや CDN の設定で、wordpress_logged_in_ の Cookie があるリクエストをキャッシュしないようにします。主要なキャッシュプラグインは標準でこの除外をしていますが、サーバー側のキャッシュや CDN を別途使っている場合は、そちらの設定も必要です。/wp-admin/ と wp-login.php もキャッシュ対象から外します。
原因4：プラグインやテーマが有効期限を変えている
一定間隔でログアウトされる場合は、auth_cookie_expiration フィルターで有効期限を短くしているプラグインやテーマ、またはセキュリティプラグインの無操作ログアウト・同時ログイン数制限の機能を疑います。
確認：ステージング環境でプラグインを1つずつ無効化して症状が変わるか確かめます。テーマや mu-plugin のコードに auth_cookie_expiration の記述がないかも検索します。セキュリティプラグインの設定画面で、ログイン時間やセッションに関する項目を探します（項目名はプラグインとバージョンで異なります）。
対処：意図しない設定なら外すか、値を見直します。標準の有効期限は「ログイン状態を保存する」にチェックなしで2日、ありで14日で、ログイン時刻から数える方式です。
原因5：認証用キーやセッション情報が変わった
全員が同時にログアウトされた場合、wp-config.php の認証用キー（ソルト）が変わった可能性があります。セキュリティプラグインの機能や、デプロイ時に wp-config.php が上書きされることで起きます。定期的にキーを入れ替える設定があれば、その間隔でログアウトが起きます。
確認：wp-config.php の更新日時と、ログアウトが起きた時刻を照らし合わせます。ログイン情報（セッショントークン）はユーザーメタに保存されているため、データベースの復元やユーザーデータの同期処理でも消えることがあります。
対処：キーが意図せず変わる仕組みを止めます。デプロイで上書きしている場合は、wp-config.php を配布対象から外します。
原因6：IP アドレスの変化を見ている機能
WordPress 本体はログイン状態を IP アドレスに結び付けていません。しかし、一部のセキュリティプラグインやサーバーの WAF は、ログイン時と異なる IP からのアクセスを不正とみなします。モバイル回線や VPN では IP が頻繁に変わるため、ログアウトが多発します。該当する機能があれば、管理者のみ対象から外すなどの調整を検討します。
原因が分からないときはログで確かめる
ここまでで絞り込めない場合は、WordPress が Cookie を拒否した理由をログに残すと手がかりになります。wp_validate_auth_cookie() は、拒否の理由ごとに異なるアクションを実行します。デバッグログを有効にしたステージング環境で、一時的に次の mu-plugin を置きます。
<?php
/**
* Plugin Name: ログイン Cookie 拒否理由の記録（調査用・調査後に削除）
* 配置先: wp-content/mu-plugins/auth-cookie-debug.php
*/
$auth_debug_hooks = array(
'auth_cookie_expired', // 有効期限切れ
'auth_cookie_bad_username', // ユーザーが見つからない
'auth_cookie_bad_hash', // 署名が合わない（キー変更など）
'auth_cookie_bad_session_token', // セッション情報がない
);
foreach ( $auth_debug_hooks as $auth_debug_hook ) {
add_action( $auth_debug_hook, function ( $cookie_elements ) use ( $auth_debug_hook ) {
if ( ! defined( 'WP_DEBUG_LOG' ) || ! WP_DEBUG_LOG ) {
return;
}
// Cookie の値やトークンは記録しない。理由とユーザー名だけ残す
$username = ( is_array( $cookie_elements ) && isset( $cookie_elements['username'] ) )
? sanitize_user( $cookie_elements['username'] )
: '-';
error_log( sprintf( '[auth-debug] %s user=%s', $auth_debug_hook, $username ) );
} );
}auth_cookie_bad_hash が多いなら認証用キーの変更、auth_cookie_bad_session_token ならセッション情報の消失、auth_cookie_expired なら有効期限の設定を疑います。Cookie がない訪問者でも実行される auth_cookie_malformed は、ログが膨大になるため対象から外しています。どの理由も記録されないのにログアウトされる場合は、Cookie 自体がブラウザに届いていない（URL の不一致やキャッシュ）可能性が高いと考えられます。調査が終わったらファイルとログを削除してください。ログにはユーザー名が含まれるため、取り扱いに注意します。
WP-CLI が使えるなら、wp user session list ユーザー名 でそのユーザーの有効なセッションと有効期限を一覧できます。
記事中の標準値やフック名は、WordPress 6.x 系（2026年10月現在）の実装にもとづいています。
まとめ
- まず症状（ループ・フロントだけ・一定間隔・全員同時・回線依存）と Cookie の状態で原因を絞る
- 多いのは URL の不一致と、プロキシ経由の HTTPS 判定。次にページキャッシュとプラグインによる期限変更
- 全員同時なら認証用キーの変更、モバイル回線で多いなら IP を見ている機能を疑う
- 分からなければ
auth_cookie_*アクションで拒否理由を記録する。Cookie の値は記録しない - 設定変更の前にはバックアップを取り、ステージングで確かめる