WordPressのアプリケーションパスワードとは？作り方と外部連携の注意点

外部ツールとWordPressをつなごうとして、「アプリケーションパスワードを発行してください」と言われ、手が止まったことはないでしょうか。

名前にパスワードと付いていますが、管理画面へ入るときのパスワードとは別物です。

通常のログインパスワードとの違い、作り方、発行した後の管理と失効まで、順を追って整理しました。

アプリケーションパスワードは外部連携専用の認証情報

WordPressと外部ツールを連携するとき、「アプリケーションパスワードを作成してください」と案内されることがあります。

名前にパスワードと付くため、管理画面へ入るときのパスワードをそのまま渡すものだと誤解しやすい機能です。

結論から言うと、アプリケーションパスワードは、外部アプリや連携サービス、スクリプトがWordPressのAPIへ接続するための認証情報です。

特定のWordPressユーザーに紐づきますが、ブラウザからの通常ログインには使えません。WordPress 5.6（2020年12月）から標準機能として入っています。

一番の利点は、メインのアカウントパスワードを外部ツールへ渡さずに済むことでしょう。連携ごとに別の認証情報を作れるので、使わなくなった連携の分だけを失効できます。

ほかの連携や通常のログインを巻き込まずに、その接続だけを止められるわけです。

ただ、発行しただけで安全になるわけではありません。アプリケーションパスワードも、漏れれば悪用され得る認証情報の一つです。

HTTPSで接続し、接続先を確かめ、連携ごとに分けて発行し、不要になったら失効する。ここまでを一つの運用として考えるのがポイントです。

通常のログインパスワードとの違い

用途、表示のされ方、失効の単位。この3点で比べると違いがはっきりします。

項目	通常のログインパスワード	アプリケーションパスワード
用途	人がログイン画面から管理画面へ入る	プログラムがAPI経由で認証する
表示	本人が決めて入力する	発行時に一度だけ表示される
失効	変更すると利用全体に影響する	連携ごとに1つずつ失効できる

通常のログインパスワードは、人が wp-login.php などのログイン画面からWordPress管理画面へ入るためのものです。

一方のアプリケーションパスワードは、REST APIなどを通じてプログラムが認証するために使います。wp-login.php からのログインには使えません。

REST APIという言葉に馴染みがなければ、「外部のプログラムがWordPressの投稿やメディアを読み書きするための窓口」と考えると分かりやすいです。

人が画面を操作する代わりに、プログラムがこの窓口へ要求を送ります。

失効の単位も大きな違いです。通常のログインパスワードを変えると、そのパスワードを前提にしていたものすべてに影響します。

アプリケーションパスワードなら1つずつ失効できるのが強みです。

「会計連携」「記事管理ツール」「保守用スクリプト」のように用途ごとに分けておけば、使わなくなった連携だけを止められます。

作成した文字列は発行時に一度だけ表示され、WordPress側にはハッシュ化された形で保存されます。ハッシュ化とは、元の文字列へ戻せない形に変換して保存する方法です。

後から同じ文字列を画面で確認する運用ではないため、紛失したら既存のものを失効して新しく発行する流れになります。

表示時には、読みやすいように空白で区切られています。利用時は空白があってもなくても検証されるので、どちらで入力しても構いません。

ただ、連携先の入力欄や保存形式はサービスごとに違うため、実際に使う連携先の公式手順も合わせて確認しておきましょう。

発行前に確認すること

求められたらすぐ発行、ではなく、先に4つを決めておくと後の管理が楽になります。接続先、HTTPS、紐づけるユーザー、保管と失効の4点です。

どれも発行画面には出てこない項目ですが、ここを飛ばすと「何のために作ったか分からない認証情報」が増えていきます。

1. 何と接続するのか

連携先の正式名称、提供元、公式マニュアル、接続の目的を確かめます。

「投稿を作成する」「メディアをアップロードする」「情報を読み取るだけ」など、やらせたい作業を具体的に言えるかどうかが目安です。

用途が説明されていないサービスや、提供元を確認できないツールには、認証情報を入力しないのが基本ですね。

2. HTTPSで接続するか

アプリケーションパスワードを使う通信は、HTTPSが前提です。

HTTP Basic認証は、ユーザー名とパスワードをリクエストに載せて送る方式なので、通信が暗号化されていないと途中で盗み見られるおそれがあります。

サイトのURLだけでなく、連携先が呼び出すREST APIのURLも https:// になっているか見ておきましょう。

WordPressがサイトをHTTPSとして正しく認識していないと、そもそもプロフィール画面に項目が表示されないこともあります。

3. どのユーザーに紐づけるか

アプリケーションパスワードは特定のユーザーに紐づき、そのユーザーの権限で動きます。どのユーザーで発行するかは、連携に必要な作業とサイトの運用方針に合わせて決めるものです。

管理者アカウントで発行するのを当然にしないでください。連携に必要な操作、使うREST APIのエンドポイント、WordPress側のユーザー権限を突き合わせてから決めます。

※実際に必要な権限は連携先と操作内容によって異なるため、連携サービスの公式マニュアルとテスト環境で確認が必要です。

4. 誰が保管し、いつ失効するか

保存場所、利用担当者、確認日、終了時に失効する担当を発行前に決めておきます。

チャットやメール、共同メモへ平文で貼り付ける運用は避けたいところです。パスワード管理ツールか、連携先が指定する安全な保存方法を使いましょう。

WordPressでアプリケーションパスワードを作成する流れ

作成そのものは、管理画面のプロフィールから数分で終わります。迷いやすいのは操作よりも、名前の付け方と生成直後の保管です。

名前に用途を入れておく理由は、後で一覧を見たときに、まだ使っているものかどうかを判断しやすくするためです。

半年後の自分が見ても分かる名前、と考えるとちょうどよいでしょう。

※WordPressのバージョン、管理画面の翻訳、セキュリティプラグイン、ホスティング環境によって表示が異なる可能性があります。

REST APIで使う仕組み

アプリケーションパスワードは、REST APIへのHTTPSリクエストでHTTP Basic認証として使います。

クライアント側は、WordPressのユーザー名と生成したアプリケーションパスワードを組にして、Authorization ヘッダーに載せて送る仕組みです。

cURLで試す場合は、次のような形になります。ユーザー名と認証情報の部分は、実際の値ではなくプレースホルダーのままにしてあります。

curl --user "USERNAME:APPLICATION_PASSWORD" \
  https://example.com/wp-json/wp/v2/users/me

ここで使うのは、通常のログインパスワードではなく、発行したアプリケーションパスワードです。URLも自分のサイトに合わせ、HTTPSになっていることを確かめてください。

コマンドラインに認証情報を直接書くと、シェル履歴やプロセス情報に残る可能性があります。

仕組みを理解するための例としては十分ですが、本番運用でそのまま採用するかは、利用するOSや実行環境、連携ツール側の安全な保存方法を見て判断したいところです。

外部サービスの連携画面では、この仕組みをサービス側が代行している場合があります。

サイトURL、ユーザー名、アプリケーションパスワードを求められたら、すぐには入力しないでください。入力先が提供元の正規画面か、通信先は正しいか、どの操作を行う連携かを先に確かめましょう。

安全に管理するための運用ルール

アプリケーションパスワードは、作成時より運用中と終了時の管理が重要です。発行前に決めた保管と失効の担当を、実際に回す段階がここに当たります。

最低限、次の4つを決めておくと整理しやすいでしょう。

連携ごとに別々に発行する

1つのアプリケーションパスワードを複数ツールで使い回すと、一覧を見ても利用先が分からなくなります。問題が起きたときに、どの連携を止めるべきかも切り分けにくいですよね。

連携やアプリごとに1つ作り、複数ツールで再利用しないのが基本です。

名前に用途を入れたうえで、発行日と管理担当は別の運用台帳へ記録しておきます。

台帳には認証文字列そのものを書かず、用途、対象サイト、発行ユーザー、確認日、失効日などを残すだけで十分です。

最終利用の情報を確認する

プロフィールのアプリケーションパスワード一覧では、名前に加えて最終利用日時やIPアドレスなどの利用情報を見られます。

ただし、この記録は利用のたびに毎回更新されるものではないため、細かな監視には向きません。

利用情報だけで不正利用を断定するのではなく、不要な項目、用途を説明できない項目、利用終了後も残っている項目を見つける手がかりとして使うのがよいでしょう。

不要になったら個別に失効する

連携の解約、担当者の変更、ツールの入れ替え、漏えいの疑いがあったときは、対象のアプリケーションパスワードを失効します。

通常のログインパスワードを変えなくても、その連携用の認証情報だけを止められます。

失効後は、連携先で認証が通らなくなったことと、公開ページや必要な機能に予期しない影響が出ていないことを見ておきましょう。

継続利用する連携で再発行した場合は、古いものを残したままにせず、切り替えを確認してから失効します。

漏えいが疑われたら再利用しない

認証情報を誤ってチャットや公開リポジトリへ貼ってしまった場合は、文字列を削除するだけで終わらせず、対象のアプリケーションパスワードを失効します。

必要なら新しく発行し、保存場所と共有方法も見直してください。定期的な、あるいは漏えいが疑われたときのローテーションは、WordPress公式も運用上の基本として案内しています。

表示されない・認証できないときの確認点

プロフィールに項目が出てこない、または接続時に401や403が返る。この2つは原因が重なることもあれば、まったく別のこともあります。

認証情報を何度も作り直す前に、原因を分けて確かめる方が結局は早いです。

プロフィールに項目が表示されない

最初に見るのは、サイトとREST APIがHTTPSで提供され、WordPressがHTTPSとして認識しているかどうかです。

アプリケーションパスワードは、標準ではHTTPS環境で利用できる仕組みになっています。

次に見るのは、セキュリティプラグイン、MUプラグイン、テーマや独自コードが機能を無効化していないかどうかです。

WordPressには、サイト全体またはユーザー単位で利用可否を変えるフィルターが用意されているため、管理方針として意図的に止めている可能性もあります。

コードを変更する前に、保守担当者へ確認してください。

401や403で認証できない

次の順で1つずつ切り分けていきます。

見落としやすいのが Authorization ヘッダーです。一部のHTTPクライアントやプロキシは、明示的に設定しない限りこのヘッダーを除去することがあります。

ユーザー名やパスワードを何度変えても解決しないときは、リクエストがWordPressまで届く経路を疑ってみてください。

本番サイトで試行錯誤する前に、連携先の公式マニュアル、WordPressのログ、ホスティング会社の仕様を照らし合わせておきましょう。

※エラー原因はサイト構成によって異なるため、401を認証情報、403を権限と一律に断定せず、実際のレスポンスとサーバー設定を確認してください。

向いているケースと別の方法を検討したいケース

アプリケーションパスワードが向いているのは、プログラムから継続して認証する場面です。REST APIを使う外部アプリ、保守スクリプト、デスクトップやモバイルのクライアントなどが典型ですね。

通常のログインパスワードを渡さず、連携ごとに個別管理したいときに使うものと考えると分かりやすいでしょう。

逆に、次のような場面では別の方法を検討します。

人がブラウザから管理画面へログインする

通常の強いパスワードを使い、必要に応じて二段階認証を検討します。

WordPress内部のプラグインやテーマからREST APIを使う

ログイン済みユーザーのCookie認証とnonceを使う、標準的な方法が用意されています。

外部サービスがOAuthなど別の認証方式を公式に指定している

そのサービスとWordPress側の公式手順を優先します。

連携先の提供元や用途を確認できない

認証情報は発行せず、その接続が本当に必要かどうかから見直したいところです。

必要な操作や権限を説明できない

本番サイトへ接続する前に、担当者または開発者へ確認します。

アプリケーションパスワードは外部連携用の便利な標準機能ですが、すべてのログインや認証を置き換えるものではありません。

誰が操作するのか、WordPressの内部か外部か、継続的なAPI接続が必要か。この3つで認証方法を分けると迷いにくくなります。

まとめ

WordPressのアプリケーションパスワードは、外部アプリやスクリプトがAPIへ接続するための、特定ユーザーに紐づく認証情報です。

通常の管理画面ログインには使えず、発行時に一度だけ表示され、連携ごとに個別に失効できます。

作成前に、接続先と目的、HTTPS、発行するユーザー、安全な保存方法を決める。発行後は連携ごとに分け、利用状況を見て、不要になった時点で失効する。この流れを1セットとして扱うのが、外部連携を安全に続けるコツです。

まずは「どのツールが、WordPressで何をするために必要としているか」を一文で説明できるか試してみてください。

説明できない連携は発行を止め、説明できる連携は名前、管理担当、失効条件まで決めてから作る。この線引きだけで、認証情報の管理はかなり楽になります。

参考：Application Passwords – Advanced Administration Handbook（WordPress公式）