is_admin と current_user_can の違い｜権限チェックに is_admin は使えない

結論

• is_admin() は「いま管理画面側のリクエストか」を返す関数で、ユーザーが管理者かどうかは判定しません。公式にも、ロールや権限の確認には current_user_can() を使うよう書かれています。
• 権限が必要な処理（保存・削除・設定変更）は、is_admin() ではなく current_user_can( 'manage_options' ) などのケイパビリティで守ります。
• ロール名（administrator）ではなくケイパビリティ名を渡すのが公式の推奨です。
• is_admin() は admin-ajax.php 経由のリクエストでも true になります。Ajaxの権限確認は特に current_user_can() が必須です。

原因・仕組み

名前が「admin」なので、「管理者かどうか」と誤解されやすい関数です。実際には、管理画面のスクリプト（wp-admin/ 配下）が実行されたことを示す WP_ADMIN 定数や、現在の画面情報を見ているだけです。ログインしているかどうかも見ていません。

current_user_can() は init フック以降で呼ぶのが安全です。それ以前（プラグイン読み込み直後など）では、ユーザー情報が未確定だったり、関連する関数（pluggable.php）がまだ読み込まれていなかったりすることがあります。

手順（サンプルコード）

管理画面のメニュー追加と、保存処理の両方で、権限を明示する例です。

// メニュー追加（権限のない人にはメニュー自体が出ない）
add_action( 'admin_menu', function () {
    add_menu_page( '売上レポート', '売上レポート', 'manage_options', 'myplug-report', 'myplug_render_report' );
} );

function myplug_render_report() {
    // 画面表示の関数でも権限を再確認する
    if ( ! current_user_can( 'manage_options' ) ) {
        wp_die( '権限がありません。' );
    }
    echo '<div class="wrap"><h1>' . esc_html( get_admin_page_title() ) . '</h1></div>';
}

// 悪い例: 管理画面なら誰でも通る
add_action( 'admin_init', function () {
    if ( is_admin() && isset( $_POST['myplug_reset'] ) ) {
        delete_option( 'myplug_data' ); // ← 購読者でも実行できてしまう
    }
} );

悪い例は、購読者（subscriber）などのログインユーザーが admin-post.php や admin-ajax.php に直接リクエストを送ると、通ってしまう構造です。次のように直します。

add_action( 'admin_init', function () {
    if ( isset( $_POST['myplug_reset'] ) ) {
        check_admin_referer( 'myplug_reset' );        // CSRF
        if ( ! current_user_can( 'manage_options' ) ) { // 認可
            wp_die( '権限がありません。' );
        }
        delete_option( 'myplug_data' );
    }
} );

なお add_menu_page() の capability 引数は、メニューを表示する権限です。メニューは admin_menu フックで追加します。それより早いフックで呼ぶと権限エラーになります（公式の記載）。上の add_menu_page の部分のコードは、構文は確認しましたが、画面の表示までは実行していません（未検証）。

動作確認（検証環境と結果）

WordPress 7.1.2（ja）、PHP 8.2.12 で php run.php is-admin-vs-current-user-can.php を実行しました。購読者（subscriber）のテストユーザーを作って切り替え、最後に削除しています。

is_admin() (CLI default): bool(false)
is_admin() after define(WP_ADMIN): bool(true)
admin manage_options: bool(true)
subscriber is_admin(): bool(true)       // 管理画面側という状態でも
subscriber manage_options: bool(false)  // 権限はなし
subscriber read: bool(true)
subscriber edit_post(1): bool(false)
role name as cap 'administrator' (admin user): bool(true)
logged-out manage_options: bool(false)

WP_ADMIN 定数を定義して管理画面側のリクエストを模擬すると、購読者でも is_admin() は true、manage_options は false でした。is_admin() が true でも、権限があるとは言えないことが確認できます。なお、ロール名 administrator を渡しても管理者では true になりましたが、公式はロール名での確認を推奨していません。

is_admin と current_user_can の違いの注意点

• is_admin() はテーマのカスタマイザーのプレビューでは false を返します。判定には is_customize_preview() を使います（公式の記載）。
• 管理画面専用の処理を読み込むかどうかの判定には、is_admin() が便利です。「読むかどうか」と「許可するかどうか」を分けて考えます。
• 投稿単位の権限は current_user_can( 'edit_post', $post_id ) のように、第2引数で対象IDを渡します（メタケイパビリティ）。
• スーパー管理者（マルチサイト）は、明示的に拒否されない限り true になります。

is_admin と current_user_can の違いでよくあるミス

• is_admin() を認可に使う。
• 画面を非表示にするだけで、リクエスト側の権限確認を省く（メニューを隠すのは認可ではありません）。
• Ajaxハンドラーで current_user_can() を書かない。
• ロール名で判定して、カスタムロールで挙動が変わる。

is_admin と current_user_can の違いのチェックリスト

• 保存・削除・設定変更の処理に current_user_can() があるか。
• 権限確認の前に副作用（DB書き込み）が走っていないか。
• Ajax・admin-post.php でも権限とnonceを確認しているか。
• 渡しているのはケイパビリティ名か（ロール名ではないか）。

is_admin と current_user_can の違いのFAQ（よくある質問）

Q. フロントエンドで is_admin() を使うことはありますか？
A. 「管理画面ではない」条件で読み込み分けをするときに ! is_admin() を使います。

Q. 一番よく使う権限は？
A. 設定画面なら manage_options、投稿編集なら edit_posts や edit_post です。

Q. ユーザーIDで判定してもよいですか？
A. 固定IDで判定すると保守しにくくなります。ケイパビリティで判定してください。

is_admin と current_user_can の違いの関連項目

• current_user_can() の使い方｜説明・引数・注意点
• user_can() の使い方｜説明・引数・注意点
• is_user_logged_in() の使い方｜説明・引数・注意点
• add_menu_page() の使い方｜説明・引数・注意点
• wp_verify_nonce() の使い方｜説明・引数・注意点