WordPressのログイン有効期限（セッションタイムアウト）を延長・短縮する設定方法

WordPress のログイン状態がどれだけ続くかは、auth_cookie_expiration フィルターで延ばすことも縮めることもできます。標準では「ログイン状態を保存する」にチェックなしで2日、チェックありで14日です。この記事では、その仕組みを押さえたうえで、権限ごとに有効期限を変えるコード、変更後に既存のログインへ反映させる方法、「操作がない時間」で切りたい場合の考え方までを説明します。

標準の有効期限はどう決まっているか

WordPress は PHP のセッション機能を使わず、ログイン用の Cookie と、ユーザーごとに保存される「セッショントークン」でログイン状態を管理しています。そのため、php.ini の session.gc_maxlifetime を変えてもログインの長さは変わりません。ここを最初に誤解しやすいので注意してください。

ログイン時に wp_set_auth_cookie() が呼ばれ、有効期限が決まります。

• 「ログイン状態を保存する」にチェックなし：サーバー側の有効期限は2日。Cookie 自体はブラウザを閉じると消える「セッション Cookie」として発行される
• チェックあり：サーバー側の有効期限は14日。Cookie はブラウザを閉じても残る

ここでの有効期限は「ログインした時刻から数えた長さ」です。操作を続けていても延長されません。たとえば2日の設定なら、毎日使っていてもログインから2日経てば再ログインを求められます。

有効期限は Cookie の中に書き込まれ、サーバー側のセッショントークン（ユーザーメタの session_tokens）にも記録されます。ブラウザ側の Cookie を書き換えても延ばせないのはこのためです。

auth_cookie_expiration フィルターで期限を変える

有効期限を変えるのは auth_cookie_expiration フィルターです。引数は3つで、標準の長さ（秒）、ユーザーID、「ログイン状態を保存する」の有無が渡されます。戻り値の秒数がそのまま有効期限になります。

コードはテーマの functions.php ではなく、mu-plugin に置くのがおすすめです。テーマを切り替えても設定が残り、管理画面から誤って無効化されることもありません。wp-content/mu-plugins/ フォルダ（なければ作成）に PHP ファイルを1つ置くだけで読み込まれます。

<?php
/**
 * Plugin Name: ログイン有効期限の調整
 * 配置先: wp-content/mu-plugins/login-expiration.php
 */
add_filter( 'auth_cookie_expiration', function ( $length, $user_id, $remember ) {
    $user = get_userdata( $user_id );

    // 管理者は短めにする（チェックなし8時間 / チェックあり2日）
    if ( $user && user_can( $user, 'manage_options' ) ) {
        return $remember ? 2 * DAY_IN_SECONDS : 8 * HOUR_IN_SECONDS;
    }

    // それ以外のユーザーは長めにする（チェックなし2日 / チェックあり30日）
    return $remember ? 30 * DAY_IN_SECONDS : 2 * DAY_IN_SECONDS;
}, 10, 3 );

DAY_IN_SECONDS や HOUR_IN_SECONDS は WordPress が用意している時間の定数です。秒数を直接書くよりも読み間違いが減ります。

長さを決めるときの目安

延長は便利ですが、Cookie が盗まれたときに悪用できる期間も延びます。次のように役割で分けて考えると決めやすくなります。

• 管理者・編集者：サイト全体を変更できるため短めに。共用 PC で作業する人がいるなら、チェックなしの長さを数時間にする
• 購読者・会員：再ログインの手間が離脱につながるため長めでもよい。ただし個人情報を扱う会員サイトでは長くしすぎない
• 非常に長い値は避ける：数年単位の値は管理上の意味が薄く、古い32ビット環境では時刻計算のあふれを起こすおそれもあります

短縮する場合は、二段階認証の導入やログイン試行回数の制限とあわせて検討すると、利便性を大きく落とさずに安全性を上げられます。

変更を既存のログインに反映させる

このフィルターが効くのは「次にログインしたとき」からです。すでに発行された Cookie とセッショントークンは、ログイン時に決まった期限まで有効なままです。短縮した設定をすぐに全員へ適用したい場合は、既存のセッションを終了させます。

• 自分だけ：管理画面の「プロフィール」にある、他のすべての場所からログアウトするボタンを使う（表記はバージョンにより異なる場合があります）
• 特定ユーザー：WP-CLI の wp user session コマンドで一覧・削除する
• 全ユーザー：wp-config.php の認証用キー（ソルト）を新しい値に入れ替える。全員が一斉にログアウトされるので、作業時間帯に注意する

# ユーザー「editor01」のセッションを確認してから、すべて終了させる
wp user session list editor01
wp user session destroy editor01 --all

ソルトを入れ替える前には wp-config.php のバックアップを取ってください。書き間違えるとサイト全体が表示できなくなります。

反映されたかを確かめる

ログインし直したあと、ブラウザの開発者ツールで Cookie を確認します。wordpress_logged_in_ で始まる Cookie の有効期限が、チェックなしなら「セッション」、チェックありなら設定した長さ（実際には少し余裕を持たせた時刻）になっていれば反映されています。

「操作がない時間」でログアウトさせたい場合

金融・医療系の会員サイトや、共用端末での利用が多い社内サイトでは、「30分操作がなければログアウト」のような無操作タイムアウトが求められることがあります。前述のとおり WordPress 標準の有効期限はログイン時刻から数える方式なので、この要件は標準機能だけでは満たせません。

選択肢は次のとおりです。

• 専用プラグインを使う：無操作時間を検知してログアウトさせるプラグインがあります（例: Inactive Logout）。管理画面の操作中に警告を出すかどうかなどの設定項目はバージョンで変わるため、導入前にステージング環境で動作を確かめてください
• セキュリティプラグインの機能を使う：一部のセキュリティプラグインには、無操作ログアウトや同時ログイン数の制限が含まれています

自作する場合、ブラウザ側の JavaScript だけで「時間が経ったらログアウト画面へ移動」させても、Cookie 自体はサーバー側で有効なままです。サーバー側でも最終操作時刻を記録して判定する必要があり、実装と検証の負担が大きいため、保守されているプラグインの利用を優先するのが無難です。

変更前後の注意点

• 作業前にバックアップを取る：mu-plugin の構文エラーはサイト全体を止めます。FTP やファイルマネージャーで該当ファイルを削除・リネームすれば元に戻せるよう、接続手段を確認しておきます
• ステージングで試す：会員プラグインや EC プラグインの中には独自のログイン処理を持つものがあり、期待どおりに効くかは組み合わせ次第です
• WooCommerce のカート保持とは別物：WooCommerce の顧客セッション（カートの保持期間）はログイン Cookie とは別の仕組みで管理されています。カートが消える問題はこのフィルターでは直りません
• ほかのプラグインとの重複：セキュリティプラグインが同じフィルターで期限を変えていることがあります。優先度の高い方が勝つため、思った長さにならないときは有効なプラグインを確認してください

有効期限の標準値や関連する画面の表記は、WordPress 6.x 系（2026年10月現在）の挙動にもとづいています。

まとめ

• WordPress のログイン有効期限は標準で2日（保存なし）と14日（保存あり）。PHP のセッション設定は関係しない
• 変更は auth_cookie_expiration フィルターで行い、mu-plugin に置くと管理しやすい
• 有効期限はログイン時刻から数える方式。変更は次回ログインから効くため、すぐ反映するにはセッションを終了させる
• 無操作タイムアウトは標準機能にないので、保守されているプラグインで実現する
• 管理者は短め、会員は長めのように権限で分け、二段階認証などと組み合わせる

• WordPressのSameSite属性でCookieを守りCSRFを防ぐ方法
• WordPressでログイン失敗ログを記録するプラグインの使い方と読み方