WordPressのユーザー名（ログインID）を隠す完全ガイド｜露出する原因とプラグイン・コードによる漏洩防止手順

WordPressでWebサイトやブログを運営している方の多くが、「ログインID（ユーザー名）は自分しか知らない秘密の情報」だと考えています。しかし、実は**WordPressの標準仕様のままでは、誰でも簡単な操作を行うだけでサイト管理者のユーザー名（ログインID）を外部から丸見えの状態で取得できてしまう**ことをご存じでしょうか？

ログインIDが第三者に知られてしまうと、Webサイトの防壁は「パスワード」というたった1枚の盾だけになってしまいます。攻撃者は特定したユーザー名を使って、何万通りものパスワードを高速で試行する「ブルートフォース攻撃（総当たり攻撃）」を仕掛け、サイトの乗っ取りやマルウェアの埋め込み、個人情報の抜き取りなどを狙います。

本記事では、**WordPressのユーザー名（ログインID）が外部から特定されてしまう5つの原因と仕組み、自サイトの露出状況を確かめるセルフチェック手順、プラグインを用いた初心者向けの確実な隠蔽設定、そしてfunctions.phpやmu-pluginsを用いた開発者向けのコード実装手順まで**を徹底的に分かりやすく解説します。

—

—

1. なぜWordPressのユーザー名（ログインID）はバレるのか？放置する危険性と攻撃リスク

WordPressにおけるセキュリティ対策の第一歩は、「どのようなリスクが存在し、放置すると何が起きるのか」を正しく理解することです。

WordPressのログインID＝ユーザー名という仕様の落とし穴

一般的なWebサービス（ネットバンキングやECサイトなど）では、公開される「アカウント表示名（ニックネーム）」と、ログインに使用する「ログインID（またはメールアドレス）」が厳格に分離されています。

しかし、WordPressはもともと「ブログ・出版プラットフォーム」として設計された歴史があり、**「記事を書いた投稿者情報（ユーザー名）」と「管理画面にログインするためのユーザー名（ログインID）」が初期状態では同一のものとして扱われる設計**になっています。

この仕様により、適切な対策を講じていないWordPressサイトでは、読者や外部の第三者に対して「ログインIDそのもの」が公開状態になってしまいます。

ユーザー名が特定されるとブルートフォース攻撃（総当たり攻撃）の標的に

Webサイトの認証（ログイン）は、「ユーザー名（ID）」と「パスワード」という**2つの鍵**が揃って初めて突破できる仕組みになっています。

状態	ユーザー名（ID）	パスワード	攻撃者の突破難易度
対策済み（隠蔽）	非公開（推測不能）	強固な文字列	極めて強固（2重の壁）
未対策（露出状態）	特定済み（漏洩）	総当たり試行される	危険（盾が1枚のみ）

ユーザー名が特定されてしまうと、攻撃者はユーザー名を推測する労力をゼロにでき、**パスワードの解読だけにリソースを100%集中**できます。専用の攻撃ボット（プログラム）を使用すれば、毎秒数十〜数百回ものログイン試行を行う「ブルートフォース攻撃（総当たり攻撃）」や、過去の流出パスワード一覧を試す「辞書攻撃・リスト型攻撃」を仕掛けられます。

アカウント乗っ取り・不正アクセスに繋がる深刻な被害

もし管理者のログイン情報が突破されてアカウントが乗っ取られた場合、以下のような壊滅的な被害が発生します。

* **サイト改ざんとバックドアの設置**: 既存のファイルに悪意あるPHPコードを埋め込まれ、何度修復しても自動で復活するバックドア（裏口）を作られる。
* **不審なサイトへの強制リダイレクト**: 訪問者がサイトにアクセスした際、詐欺サイトやアダルトサイト、不正アプリのダウンロードページへ自動転送される（リダイレクトハッキング）。
* **スパム送信やDDoS攻撃の踏み台化**: サーバーが遠隔操作され、大量の迷惑メール送信や他社サーバーへのサイバー攻撃の加害者に仕立て上げられる。
* **顧客データ・個人情報の漏洩**: お問い合わせフォームの送信履歴、会員情報、顧客のメールアドレスなどが盗み出される。
* **検索エンジンからのペナルティ**: Googleから「セキュリティ上の問題」「偽装サイト」として警告を受け、検索順位が急落・インデックス削除される。

ユーザー名を隠す対策は、こうした深刻なインシデントを未然に防ぐための**「最も基本的かつ効果の高いセキュリティ対策」**の1つです。

—

2. あなたのサイトは大丈夫？ユーザー名の露出状況をセルフチェックする3つの確認方法

まずは、ご自身のWordPressサイトで現在ユーザー名が外部から見えてしまっているかどうかを確認してみましょう。ブラウザだけで数分で確認できます。

チェック1：URL末尾に「/?author=1」を入力してアクセスしてみる

最も代表的なユーザー名確認方法です。ブラウザのアドレスバーに以下のURLを入力してアクセス（Enter）してください。

https://あなたのサイトのドメイン/?author=1

※「1」はWordPressで最初に作成された管理者ユーザーのID番号です。

もし `author/` の後ろにログイン時に使用している文字列が表示された場合、第三者にもユーザー名が完全に把握されている状態です。

チェック2：REST APIエンドポイント「/wp-json/wp/v2/users」を確認する

次に、WordPressの標準API（REST API）経由での露出を確認します。ブラウザで以下のURLを開いてください。

https://あなたのサイトのドメイン/wp-json/wp/v2/users

チェック3：記事の著者名表示とXMLサイトマップ（wp-sitemap-users-1.xml）を確認する

記事の執筆者情報や標準サイトマップも確認します。

1. **記事の著者リンク**: 投稿記事のタイトル下やフッターにある「投稿者名」にマウスカーソルを合わせ、リンク先URLを確認します。`https://ドメイン/author/ログインID/` になっていませんか？
2. **標準XMLサイトマップ**: `https://あなたのサイトのドメイン/wp-sitemap-users-1.xml` にアクセスし、投稿者一覧とスラッグがリストアップされていないか確認します。

いずれかのチェックでユーザー名が表示されてしまった場合は、以下の対策を順に実施してください。

—

3. 【原因別】WordPressでユーザー名が外部に露出する5つのルート

WordPressにおいてログインID（ユーザー名）が露出する経路は、主に以下の5つに分類されます。それぞれの原因と仕組みを理解することで、漏れのない確実な対策が可能になります。

[WordPress ユーザー名露出の5大ルート]
  │
  ├─► 1. 投稿者アーカイブ (/?author=1) ──────► URLにスラッグ(ユーザー名)が自動展開
  ├─► 2. WP REST API (/wp-json/wp/v2/users) ─► JSON形式で全ユーザーのスラッグを返却
  ├─► 3. 記事上の「ブログ上の表示名」 ───────► 初期設定のままだとユーザー名がそのまま表示
  ├─► 4. 標準XMLサイトマップ ────────────────► wp-sitemap-users-1.xml にURL一覧が出力
  └─► 5. ログイン画面のエラーメッセージ ─────► 「ユーザー名が無効」等で存在有無が判明

ルート1：投稿者アーカイブページへの自動リダイレクト（/?author=1）

WordPressは、`/?author=ユーザーID番号` というURLにリクエストが来ると、「ユーザーフレンドリーなURL（パーマリンク）」へ自動的に301リダイレクトを行う親切な機能を備えています。このとき、リダイレクト先のURLにユーザー名（スラッグ）がそのまま埋め込まれるため、外部からユーザー名が丸見えになります。

ルート2：WP REST APIによるユーザー一覧のJSON出力（/wp-json/wp/v2/users）

WordPress 4.7以降、外部アプリケーションやモダンフロントエンドとの連携のために標準搭載された「WP REST API」。認証なし（未ログイン状態）でも、`/wp-json/wp/v2/users` にGETリクエストを送るだけで、記事を執筆した全ユーザーのID・表示名・スラッグ（初期値はログインID）が取得できてしまいます。

ルート3：記事本文・メタ情報に表示される「投稿者名・表示名」の初期設定

WordPressのアカウント新規作成時、「ニックネーム」や「ブログ上の表示名」のデフォルト値はユーザー名と同じになっています。これを変更せずに記事を公開すると、記事冒頭の「著者：admin」のように画面上にユーザー名がそのまま露出します。

ルート4：WordPress標準XMLサイトマップ（wp-sitemap-users-1.xml）

WordPress 5.5以降、SEO対策としてXMLサイトマップ生成機能がコアに組み込まれました。このサイトマップには「投稿」「固定ページ」だけでなく「投稿者（users）」のURLも含まれており、検索エンジンだけでなく攻撃者ボットにも投稿者URL一覧を提供してしまう原因となります。

ルート5：ログイン画面のエラーメッセージによるユーザー名存在確認

WordPressのログイン画面（`/wp-login.php`）で誤った情報を入力した際、初期設定では以下のようにエラーメッセージが分かれています。
* 存在しないユーザー名を入力した場合：「**無効なユーザー名です。**」
* 実在するユーザー名で誤ったパスワードを入力した場合：「**ユーザー名 ○○ のパスワードが正しくありません。**」

この差分を利用することで、攻撃者は「そのユーザー名がシステム内に実在するかどうか」を簡単に判別（ユーザー列挙攻撃）できてしまいます。

—

4. 【対策1：基本設定】プロフィールから「ブログ上の表示名」を変更する（必須の初歩設定）

まずは、プラグインをインストールすることなく管理画面から今すぐ実施できる**「ブログ上の表示名」の変更**です。これはすべてのWordPressユーザーが最初に行うべき必須設定です。

ステップ1：管理画面「ユーザー」→「プロフィール」を開く

1. WordPress管理画面にログインします。
2. 左側メニューの「**ユーザー**」＞「**プロフィール**」（または「ユーザー一覧」から対象ユーザーを編集）をクリックします。

ステップ2：「ニックネーム」を入力し「ブログ上の表示名」を切り替える

1. 「名前」セクションまでスクロールします。
2. 「**ニックネーム (必須)**」の欄に、ログイン用ユーザー名とは**全く異なる任意の名前**（例: `Web担当者T`, `MozCheck編集部`, `サトウ` など）を入力します。
3. その下にある「**ブログ上の表示名**」のプルダウンをクリックし、先ほど入力したニックネームを選択します。
4. ページ最下部の「**プロフィールを更新**」ボタンをクリックします。

これで、記事の執筆者欄やコメント欄に表示される名前がニックネームに置き換わり、ログインIDが直接画面に表示されるのを防ぐことができます。

—

5. 【対策2：プラグイン導入】初心者でも簡単・確実にユーザー名を隠す2大プラグイン

プログラミングコードの編集に不安がある方や、手軽かつ安全に対策を完了させたい方には、専用プラグインの利用を推奨します。

方法A：「Edit Author Slug」で投稿者スラッグを安全な別名に変更する

「**Edit Author Slug**」は、投稿者アーカイブのURLスラッグ（`/author/ユーザー名/` の部分）を自由な文字列に変更できる定番プラグインです。

設定後、`/?author=1` にアクセスすると、`https://ドメイン/author/writer-staff-01/` にリダイレクトされるようになり、ログインIDの露出が完全に防げます。

方法B：「SiteGuard WP Plugin」のユーザー名漏えい防御機能で完全遮断する

国内で圧倒的な利用実績を誇るセキュリティプラグイン「**SiteGuard WP Plugin**」を利用すると、投稿者アーカイブへのアクセスそのものを遮断できます。

この機能をONにすると、`/?author=1` へのアクセスが遮断（404 Not Foundまたはトップページ転送）されます。また、SiteGuardの「**ログインページ変更**」や「**画像認証（キャプチャ）**」も同時に利用することで、サイト全体の防御力を劇的に向上させることができます。

【比較】どちらを選ぶべき？サイト運用に合わせた使い分け

プラグイン名	特徴・動作	おすすめのサイトタイプ
Edit Author Slug	スラッグを別の安全な文字列に置換（投稿者一覧ページ自体は維持）	複数ライターが所属し、ライター別記事一覧ページを活用したいオウンドメディア・ブログ
SiteGuard WP Plugin	/?author=N のアクセス自体を無効化＋ログインURL変更などの総合セキュリティ	投稿者アーカイブページが不要な企業サイト・コーポレートサイト・個人ブログ

—

6. 【対策3：functions.phpコード】プラグインなしでユーザー名漏洩を完全ブロックする実践スニペット

「プラグインの数を増やしたくない」「テーマのコードで軽量かつ完全に制御したい」という開発者・中上級者向けに、`functions.php`（または `mu-plugins`）に追記するだけで全露出ルートを遮断できるPHPスニペットをご紹介します。

コード1：/?author=N へのアクセスをトップページへリダイレクト（または404化）

URLパラメータに `author=` が含まれるリクエストを検知し、安全にトップページへ転送（301リダイレクト）するコードです。

/**
 * 投稿者アーカイブ（/?author=N）へのアクセスをトップページへリダイレクト
 */
function mozcheck_disable_author_archive_query() {
    if ( is_admin() ) {
        return;
    }
    
    // クエリパラメータに author が含まれている、または投稿者アーカイブページの場合
    if ( isset( $_GET['author'] ) || is_author() ) {
        wp_safe_redirect( home_url(), 301 );
        exit;
    }
}
add_action( 'template_redirect', 'mozcheck_disable_author_archive_query' );

※「リダイレクトではなく404 Not Found（ページが存在しないエラー）を返したい」場合は、以下のコードを使用します。

/**
 * 投稿者アーカイブへのアクセス時に404エラーを返す
 */
function mozcheck_author_archive_404( $query ) {
    if ( ! is_admin() && $query->is_main_query() && ( $query->is_author() || isset( $_GET['author'] ) ) ) {
        $query->set_404();
        status_header( 404 );
        nocache_headers();
    }
}
add_action( 'parse_query', 'mozcheck_author_archive_404' );

コード2：未認証ユーザーからのREST APIユーザーエンドポイント（/wp/v2/users）を遮断

REST API全体を完全に停止してしまうと、Gutenbergブロックエディタやお問い合わせプラグインの動作に支障が出る場合があります。以下のコードは、**「未ログインの第三者からのユーザー一覧リクエスト（`/wp/v2/users`）のみを安全に遮断」**する洗練された実装です。

/**
 * 未ログインユーザーに対する REST API のユーザー情報エンドポイントを無効化
 */
function mozcheck_restrict_rest_user_endpoints( $endpoints ) {
    if ( ! is_user_logged_in() ) {
        if ( isset( $endpoints['/wp/v2/users'] ) ) {
            unset( $endpoints['/wp/v2/users'] );
        }
        if ( isset( $endpoints['/wp/v2/users/(?P<id>[\\d]+)'] ) ) {
            unset( $endpoints['/wp/v2/users/(?P<id>[\\d]+)'] );
        }
    }
    return $endpoints;
}
add_filter( 'rest_endpoints', 'mozcheck_restrict_rest_user_endpoints' );

このコードを適用すると、ログイン済みの管理者には影響を与えず、外部の攻撃者が `/wp-json/wp/v2/users` にアクセスした際には `404 Not Found` が返却されるようになります。

コード3：XMLサイトマップから投稿者（users）プロバイダーを除外

WordPress標準のXMLサイトマップから、投稿者情報（`wp-sitemap-users-1.xml`）を非公開にするフィルターフックです。

/**
 * WordPress標準XMLサイトマップからユーザー（投稿者）一覧を除外
 */
function mozcheck_remove_users_from_wp_sitemaps( $provider, $name ) {
    if ( 'users' === $name ) {
        return false;
    }
    return $provider;
}
add_filter( 'wp_sitemaps_add_provider', 'mozcheck_remove_users_from_wp_sitemaps', 10, 2 );

コード4：ログインエラーメッセージを統一してユーザー名の有無を推測させない

ログイン失敗時に「ユーザー名が違うのか、パスワードが違うのか」を判別させず、常に同一のエラーメッセージを返すようにカスタマイズします。

/**
 * ログイン画面のエラーメッセージを汎用的な文言に統一
 */
function mozcheck_generic_login_errors() {
    return '<strong>エラー:</strong> ユーザー名またはパスワードが正しくありません。';
}
add_filter( 'login_errors', 'mozcheck_generic_login_errors' );

【ベストプラクティス】コードは「mu-plugins」への配置が最も安全

`functions.php` にコードを記述する場合、テーマを更新（アップデート）したり別のテーマに切り替えた際にコードが消えてしまうリスクがあります。

サイト全体のセキュリティに関わるコードは、`/wp-content/mu-plugins/` ディレクトリ内に配置する**「Must-Use プラグイン（mu-plugins）」**として管理することを強くおすすめします。

—

7. 【多層防御】ユーザー名を隠すだけでは不十分！サイトを守る4つのセキュリティ強化策

セキュリティの世界には**「多層防御（Defense in Depth）」**という大原則があります。どれか1つの対策が突破されても、次の壁で確実に攻撃を食い止める仕組みを作ることが重要です。

ユーザー名の隠蔽とセットで必ず導入すべき4大セキュリティ対策をご紹介します。

[WordPress ログイン多層防御の構造]
┌─────────────────────────────────────────────────────────────┐
│ 1. ユーザー名隠蔽       : ログインIDを外部から特定不能にする  │
├─────────────────────────────────────────────────────────────┤
│ 2. ログインURL変更      : /wp-login.php を推測不能なURLに変更 │
├─────────────────────────────────────────────────────────────┤
│ 3. ログイン試行制限     : 5回連続失敗でIPアドレスを一時遮断  │
├─────────────────────────────────────────────────────────────┤
│ 4. 二要素認証 (2FA)    : パスワード突破時もスマホ認証で防御   │
└─────────────────────────────────────────────────────────────┘

1. ログインページURLの変更（/wp-login.php の隠蔽）

WordPressのログインURLはデフォルトで `https://ドメイン/wp-login.php` や `/wp-admin/` に設定されています。攻撃ボットはこの標準URLを狙って自動攻撃を仕掛けてきます。「**WPS Hide Login**」や「**SiteGuard WP Plugin**」などのプラグインを使って、ログインURLを自分しか知らないランダムなURL（例: `/my-secret-login-77/`）に変更しましょう。

2. 二要素認証（2FA / パスキー）の導入

万が一ユーザー名とパスワードの両方が漏洩した場合でも、ログインを防ぐ最強の盾が「**二要素認証（2FA）**」です。スマートフォンアプリ（Google Authenticator等）に届くワンタイムパスワードや、生体認証（パスキー）を必須にすることで、不正ログインをほぼ100%遮断できます。「**Two-Factor**」や「**Wordfence Security**」などのプラグインで簡単に導入可能です。

3. ログイン試行回数の制限（ブルートフォース攻撃の完全遮断）

「5回連続でログインに失敗したIPアドレスからのアクセスを30分間ブロックする」といった試行回数制限を設けることで、総当たり攻撃を完全に無力化できます。「**Limit Login Attempts Reloaded**」や「**XO Security**」を導入することで実現できます。

4. MozCheck無料診断による定期的なセキュリティ設定・脆弱性スキャン

あなたのWordPressサイトのセキュリティ設定が万全かどうか、不安な点はありませんか？

—

8. WordPressのユーザー名隠しに関するよくある質問（FAQ）

Q1. ユーザー名を隠すとSEOやGoogle検索順位に悪影響はありますか？

**A. 検索順位への悪影響はありません。**
個人の投稿者アーカイブページ（`/author/xxx/`）は、通常の検索流入の主軸ではなく、むしろ記事数が多いサイトでは「低品質な重複コンテンツ」とみなされるリスクすらあります。投稿者アーカイブをトップページにリダイレクトするか、noindex/404化することは、SEO観点からも推奨される運用です。

Q2. 「Edit Author Slug」でスラッグを変更すると過去記事へのリンクが切れますか？

**A. 記事自体のURLには一切影響しません。**
記事のパーマリンクは投稿スラッグ（post_name）で管理されているため、投稿者スラッグを変更しても記事URLが変わったりリンク切れを起こすことはありません。変わるのは「投稿者別の一覧アーカイブページのURL」のみです。

Q3. REST APIのユーザーエンドポイントを制限すると他のプラグインやブロックエディタに影響しますか？

**A. 本記事で紹介したコードであれば影響ありません。**
本記事のPHPコードは「未ログインの第三者からのリクエストのみ」を制限し、ログイン中の管理者やエディタの正当なREST API通信は一切妨げない設計になっています。そのため、GutenbergブロックエディタやContact Form 7などのプラグインも通常通り動作します。

Q4. ユーザー名（ログインID）そのものを後から変更することはできますか？

**A. 管理画面から新規ユーザーを作成するか、phpMyAdmin/WP-CLIで変更可能です。**
WordPress管理画面のプロフィールからはユーザー名自体を変更できませんが、以下の手順で安全に変更できます。
1. 「ユーザー」＞「新規追加」で新しい管理者ユーザー（推測されにくいユーザー名）を作成する。
2. 一度ログアウトし、新ユーザーでログインし直す。
3. 古い管理者ユーザーを削除する（削除時に「すべてのコンテンツを新しいユーザーにアサイン」を選択）。

—

9. まとめ：WordPressのユーザー名を隠して不正ログインを未然に防ごう

WordPressのユーザー名（ログインID）は、初期状態のまま運用していると `/?author=1` や REST API などを通じて第三者に簡単に特定されてしまいます。

不正アクセスやアカウント乗っ取りの被害を未然に防ぐため、以下のチェックリストに沿って今すぐ対策を実施しましょう。

Webサイトのセキュリティ対策は、「被害に遭う前」の迅速な初動が命です。大切なサイトと訪問者の信頼を守るために、ぜひ本記事の手順に沿って安全な運用環境を整えてください。

—

あわせて読みたい関連記事

* WordPressのXML-RPC（xmlrpc.php）を停止・無効化する完全ガイド｜攻撃リスクと.htaccess・プラグイン・コードによる安全な遮断手順
* WordPress乗っ取り被害からの緊急復旧マニュアル｜管理者権限の奪還・バックドア駆除・再発防止策
* WordPressの403 Forbiddenエラー原因と直し方完全ガイド｜管理画面・記事保存時のWAF解除から.htaccess・パーミッション復旧まで
* WordPressセキュリティ診断ツールおすすめ比較｜無料・オンライン・プラグインの選び方