WordPressの「/wp-json/wp/v2/users」でIDが見える？公開情報と確認ポイント

自社サイトのURLに「/wp-json/wp/v2/users」を付けると、ユーザーらしい情報が表示されることがあります。
「IDが丸見えで大丈夫？」と気になりますが、表示された項目を見分けることが第一歩です。
今回は、WordPress標準の仕組みと、安全に確認する手順を整理します。

何が公開されているのか

WordPressの公式説明では、ユーザー名や数値のIDを秘密情報とは扱っておらず、Users APIの公開は意図された設計です。表示だけを根拠に、不正アクセスやパスワード漏えいが起きたとは判断できません。［1］

標準の未認証リクエストでは、REST APIに公開される投稿タイプで公開済みの投稿を持つユーザーが一覧の対象になります。
全登録ユーザーや管理者だけの一覧ではありません。［2］

項目の意味にも違いがあります。
idはユーザーを識別する数値、nameは表示名、slugはURLなどで使う識別子です。
ログイン名を表すusernameとは別項目ですが、slugはログイン名をもとに作られる場合があり、同じ文字列になることもあります。
表示名だけを変えても、slugまで変わったとは限りません。［3］［4］

標準仕様ではusernameやemailは編集用のcontextに属し、一覧を編集用の情報で取得するには権限確認があります。
パスワードは応答に含まれません。
ただし、プラグインや独自コードで応答は変わるため、実際の公開内容も確認しましょう。［3］［5］

自社サイトをログアウト状態で確認する

確認対象は、自分が管理するサイトか、点検の許可を得たサイトだけにします。シークレットウィンドウなどの未ログイン状態で、サイトのURLに「/wp-json/wp/v2/users」を付けて開きます。
WordPressをサブディレクトリに設置している場合などは、APIのURLが異なることがあります。
閲覧用のGETリクエストだけで十分です。

返ってきた内容で、id・name・slug・descriptionなどを確認します。
本名や社内用の説明が意図せず載っていないかが、実務上の点検ポイントです。
URL、確認日時、気になった項目を記録し、個人情報を含む画面をそのまま外部に共有しないようにします。

結果を見て対応の優先順位を決める

公開用の著者情報が返った場合は、まずサイトの運用方針に合っているかを確認します。
未ログインなのにemailや想定外の個人情報が返る場合は、標準仕様との差を保守担当者に調べてもらいましょう。
追加プラグインや独自コードも調査対象です。

空の配列や403・404などが返っても、それだけでサイト全体が安全とは判断できません。
対象ユーザーの有無やアクセス制限、URLの違いなどを確認します。
また、この一覧を非公開にしても、著者ページなど別の場所に公開情報が残る可能性があります。［6］

優先したいのは、強く使い回さないパスワード、二要素認証、本体・テーマ・プラグインの更新、復元できるバックアップです。
IDを隠すことだけで、これらの対策を置き換えることはできません。［7］

APIを止める前に動作確認を

WordPress公式は、管理画面の機能が動かなくなるため、REST API全体の無効化を勧めていません。公開範囲を制限する必要があるなら、利用中の機能を確認し、必要な範囲に絞って検討します。［8］

設定やコードを変更する前にバックアップを取り、検証環境でブロックエディターの保存、著者選択、関連プラグインや外部連携を確認しましょう。
ネット上のPHPを本番環境へそのまま貼り付けず、変更の影響と元に戻す方法を確認してから進めることが大切です。

参考資料

1. WordPress Core Handbook：ユーザー名・IDの公開に関する設計方針
2. WordPress Code Reference：get_items()
3. WordPress REST API Handbook：Usersの項目とcontext
4. WordPress Code Reference：wp_insert_user()
5. WordPress Code Reference：get_items_permissions_check()
6. WordPress Core Trac #43359：公開済み著者情報について
7. WordPress Advanced Administration Handbook：Hardening WordPress
8. WordPress REST API Handbook：FAQ

公開内容で気になる項目があれば、URLと確認日時を控えておくと調査の手掛かりになります。
未ログインで想定外の個人情報が返った場合は、保守担当者に標準仕様との差を調べてもらう際に使えます。

公式資料の確認日：2026年10月10日（日本時間）。
本記事は一般的な点検手順であり、個別サイトの安全性を保証するものではありません。