ChatGPTやClaudeなどのAI、外部の業務ツール、スマホアプリから、WordPressに記事を投稿したり情報を取り出したりする機会が増えています。そのとき設定画面で求められることが多いのが、「アプリケーションパスワード」です。「普段のパスワードとは違うの?」「発行して大丈夫?」と迷った方も多いのではないでしょうか。
結論から言うと、アプリケーションパスワードは、外部のプログラムからWordPressを操作するための「専用の合鍵」です。普段のログインには使えず、いつでも取り消せるので、ログインパスワードを渡すより安全です。ただし、発行したユーザーと同じ権限で何でもできてしまう点には注意が必要です。管理者で発行すると、外部のツールが管理者として動けることになります。
この記事では、当社の検証環境で実際に発行して使ってみた結果と、記事投稿の自動化に使っている当社の運用で見つかった反省点をもとに、使い方と注意点を解説します。WordPress 7.2で予定されている改善にも触れます。
この記事は2026年10月4日時点の情報です(検証はWordPress 7.1.2)。
WordPressのアプリケーションパスワードとは?
アプリケーションパスワードは、WordPress 5.6(2020年)から標準で入っている機能です。ユーザーのプロフィール画面で発行でき、REST APIやXML-RPCといった「プログラム向けの窓口」からの操作だけに使えます。
| 普段のログインパスワード | アプリケーションパスワード | |
|---|---|---|
| 使う場面 | 人が管理画面にログインする | 外部のツールやAIが、プログラム経由で操作する |
| 管理画面へのログイン | できる | できない |
| いくつ作れるか | 1つ | 用途ごとに何個でも |
| 取り消し | 変更すると全部に影響 | 1つずつ取り消せる。普段のログインには影響しない |
| できる操作 | そのユーザーの権限の範囲 | 同じく、そのユーザーの権限の範囲すべて |
外部のツールに普段のパスワードを教える代わりに、用途ごとに合鍵を作って渡すイメージです。合鍵なので、不要になったらその1本だけ無効にできます。
アプリケーションパスワードの使い方
発行の手順は次のとおりです。
- 管理画面の「ユーザー」→「プロフィール」(他のユーザーの場合は「ユーザー一覧」から編集)を開く
- 下の方にある「アプリケーションパスワード」の欄で、用途が分かる名前(例:記事の自動投稿)を入力する
- 「アプリケーションパスワードを追加」を押す
- 表示されたパスワードをコピーし、使うツールの設定画面に貼り付ける

発行したパスワードはこの画面で一度だけ表示され、あとから見ることはできません。控え忘れたら、取り消して作り直します。ツールに設定するときは、ユーザー名とこのパスワードの組み合わせを使います。
発行済みのパスワードは一覧で確認できます。「最終使用日」と「最後のIP」が出るので、使われていないものや、心当たりのない場所から使われているものを見つける手がかりになります。

なお、WordPress本体のプログラムを読むと、最終使用日の記録は1日に1回だけ更新される作りになっています。正確なアクセス記録ではなく、「最近使われているか」の目安として見てください。
表示されないときは、HTTPSを確認
アプリケーションパスワードは、サイトがHTTPS(鍵マークのついたアドレス)で動いていることが前提です。HTTPSでないサイトでは、欄はあっても発行できず、次のように表示されます。

例外は、開発用のサイトです。wp-config.phpで環境タイプを「local」にすると、HTTPSでなくても使えます。画面には「開発用サイトであれば環境タイプを設定して」と案内が出ますが、実際に条件を満たすのは「local」だけで、「development」では使えません。この案内のずれは、WordPress 7.2で直す候補のチケット(#57388)にもなっています。
アプリケーションパスワードでできること|検証環境で試した結果
「合鍵」でどこまでできるのかを、検証環境(WordPress 7.1.2)で確かめました。管理者のユーザーでアプリケーションパスワードを発行し、REST APIから操作した結果です。
| 試したこと | 結果 |
|---|---|
| パスワードなしで下書きを作る | 拒否された(401) |
| アプリケーションパスワードで下書きを作る | 作成できた |
| プラグインの一覧を取得する | 取得できた(管理者だけができる操作) |
| 新しい管理者ユーザーを作る | 作成できた |
| 管理画面のログイン画面でログインする | ログインできなかった |
| 発行したときにメールで知らせが来るか | 来なかった |
つまり、管理者で発行したアプリケーションパスワードがあれば、管理画面に入らなくても、新しい管理者を作るような操作までできてしまいます。アプリケーションパスワードには「この操作だけ許可する」という範囲の指定がなく、発行したユーザーの権限がそのまま使えるからです。
ここまでのまとめ
- アプリケーションパスワードは、外部のプログラム専用の合鍵。管理画面にはログインできない
- 用途ごとに作り、1つずつ取り消せる。最終使用日と最後のIPで使われ方を確認できる
- ただし、発行したユーザーの権限がそのまま使える。管理者で発行すれば管理者と同じことができる
管理者で発行しないほうがいい理由|当社の反省
当社では、記事の下書き作成、画像の登録、予約投稿といった作業を、REST APIとアプリケーションパスワードで自動化しています。先日、この運用を点検したところ、自動化に使っていたのが管理者アカウントのアプリケーションパスワードだったことに気づきました。さらに、8月から使っていないアプリケーションパスワードが1つ残っていました。
自動化でやっている作業は、どれも「編集者」の権限で足ります。動いているから気づかない、というのが一番の落とし穴でした。もし管理者のアプリケーションパスワードが漏れれば、上の検証のとおり、管理者ユーザーの追加まで外部からできてしまいます。この点検の経緯はAIにWordPressを操作させる前に決める5つのことで詳しく書いています。
この反省から、アプリケーションパスワードは次のように使うのが安全だと考えています。
- 専用のユーザーを作り、必要な一番低い権限(記事の投稿なら「投稿者」か「編集者」)にしてから発行する
- 名前は「何に使うか」が分かるように付ける(例:記事の自動投稿、在庫連携)
- 使うツールごとに別のパスワードを発行し、使い回さない
- 使わなくなったら、その日のうちに取り消す
- 月に1回、一覧の「最終使用日」を見て、使われていないものを取り消す
- パスワードはツールの設定画面か、パスワード管理ツールにだけ保存する(メールやチャットに貼らない)
WordPress 7.2で予定されている改善
WordPress 7.2のロードマップでは、セキュリティの取り組みの1つとして、アプリケーションパスワードの改善が挙げられています。2026年10月4日時点では、どれも「7.2に向けて優先して取り組む」とされている段階で、正式版に入るかは決まっていません。
| チケット | 内容 | 運営者にとっての意味 |
|---|---|---|
| #66009 | アプリケーションパスワードの画面の使いやすさの改善 | 発行・管理が分かりやすくなる |
| #63927 | アプリケーションパスワードが追加されたら、メールで知らせる | 知らないうちに合鍵を作られても気づける。今回の検証でも、今は通知が来なかった |
| #57388 | HTTPSでないサイトでの案内文の修正(「開発用」と案内しているが、実際は「local」が必要) | 開発環境での設定の迷いが減る |
| #46744 | 新規ユーザーの初期権限に危険な値を設定できないようにする | 設定ミスや乗っ取りによる被害を防ぐ |
| #37000 | ログインのCookieにSameSite属性を付ける | なりすましの操作を受けにくくなる |
同じロードマップには、外部サービスのAPIキーを安全に保存するSecrets APIや、ログイン中でも特に重要な管理操作の前にもう一度本人確認を求める「sudo mode」の構想も載っています。sudo modeは、10月4日時点では「導入の可能性について初期の作業が始まった」段階で、どの操作が対象になるかなどの詳しい提案はまだ公開されていません。7.2全体の予定はWordPress 7.2の新機能まとめで追っています。
技術者向け:使える条件と、権限を絞る方法
WordPress本体のプログラムでは、アプリケーションパスワードを使える条件は「HTTPSであること」または「環境タイプがlocalであること」です。サイト全体やユーザーごとに使えなくしたい場合は、フィルターで切り替えられます。
|
1 2 3 4 5 6 7 8 9 10 11 |
<?php // サイト全体でアプリケーションパスワードを使えなくする add_filter( 'wp_is_application_passwords_available', '__return_false' ); // 管理者には発行させない(管理者以外だけ使えるようにする) add_filter( 'wp_is_application_passwords_available_for_user', function ( $available, $user ) { if ( user_can( $user, 'manage_options' ) ) { return false; } return $available; }, 10, 2 ); |
2つ目の例は、「管理者のアプリケーションパスワードは発行させない」というルールを仕組みで強制するものです。ただし、すでに連携に使っている管理者のアプリケーションパスワードも使えなくなるので、専用ユーザーへの切り替えを済ませてから入れてください。
開発者向けの詳しい仕様は、WordPress公式の「Application Passwords: Integration Guide」で確認できます。「WordPress application passwords integration guide」で検索してみてください。
よくある質問
Q. アプリケーションパスワードは危険ですか?
普段のパスワードを外部のツールに教えるより安全です。管理画面にはログインできず、1つずつ取り消せるからです。ただし、発行したユーザーの権限がそのまま使えるので、権限の低い専用ユーザーで発行し、使わなくなったら取り消すことが大切です。
Q. 発行したパスワードを忘れました。もう一度見られますか?
見られません。発行直後に一度だけ表示される仕組みです。一覧から取り消して、新しく発行し直してください。
Q. プロフィール画面にアプリケーションパスワードの欄が出ません。
サイトがHTTPSでない場合は発行できません。また、セキュリティ系のプラグインや、テーマ・プラグインの設定で無効にされている場合もあります。
Q. 使っていないアプリケーションパスワードは消したほうがいいですか?
はい。使っていない合鍵は、漏れても気づきにくいからです。一覧の最終使用日を見て、心当たりのないものや長く使われていないものは取り消してください。
外部ツールやAIとの連携を、安全に任せたい方へ
アプリケーションパスワードは、AIや業務ツールとWordPressをつなぐ便利な入口です。一方で、どのユーザーで発行するか、どこまでの操作を許すかの設計を誤ると、管理者の権限を外に渡すことになります。当社はWordPress専門のエンジニアとして、REST APIを使った連携や業務の自動化を、権限の設計から実装しています。「この連携は安全に作れているか」の点検だけのご相談も歓迎です。
更新履歴
- 2026年10月4日:作成(WordPress 7.1.2の検証環境で発行・使用を確認)