AIエージェントからWordPressの記事を作成・更新できるようになると、「もう管理者アカウントを渡して全部やってもらえばいいのでは」と考えたくなります。
ただ、記事制作を自動化するだけなら、AIへAdministrator権限を常時渡す必要はほとんどありません。むしろ、AI専用ユーザーを作り、記事制作に必要なCapabilityだけを与え、さらにAI側でも使える操作を絞る方が安全です。
この記事では、WordPressのApplication Password、Role・Capability、REST APIに加えて、2026年時点で利用できるAbilities APIやMCP Adapterも踏まえながら、「何を自動化するなら、どこまで権限を渡すべきか」を整理します。
- 記事の下書きだけなら、公開・削除・サイト設定の権限は不要
- Application Passwordは認証情報を分離できるが、それ自体が権限を弱くする仕組みではない
- 既存記事の更新では、記事の所有者によって必要なCapabilityが増えることがある
- WordPress側だけでなく、AIエージェントが呼び出せるツールや対象記事も制限する
- AIエージェントにWordPress管理者権限は必要？結論は「常用しない」
- Application Passwordは「認証」を安全にするが「権限」を小さくしない
- WordPress記事自動化で必要なCapabilityを分解する
- 記事制作AIは3段階で権限を増やす
- WordPress側とAI側の二重の最小権限にする
- WordPress 6.9以降はAbilities APIとMCP Adapterも選択肢
- AIエージェントをWordPressにつなぐ実務手順
- こんな構成は避けたい
- まとめ：AIには「できるだけ少なく、必要なときだけ」権限を渡す
- AIエージェントとWordPress権限のよくある質問
- 参考にした公式・セキュリティ資料
AIエージェントにWordPress管理者権限は必要？結論は「常用しない」
WordPressのAdministratorは、単に「記事を自由に書けるユーザー」ではありません。単一サイトでは、投稿だけでなく、ユーザー、プラグイン、テーマ、サイト設定など広い管理機能へアクセスできるRoleです。
WordPress公式のRoles and Capabilitiesでも、Administratorは単一サイトの管理機能へアクセスできるRoleとして整理されています。記事を1本更新するAIに、この範囲をそのまま渡すのは「できること」が多すぎます。
従来の自動化スクリプトと比べてAIエージェントで意識したいのは、外部の文章やWebページもコンテキストとして読みながら、自分でツールを選んで実行することです。OWASPのAI Agent Security Cheat Sheetでは、プロンプトインジェクション、過剰なツール権限、データ流出、過剰な自律性などが主要リスクとして挙げられています。
つまり「普段は良い指示に従ってくれるから大丈夫」ではなく、誤判断や悪意ある外部入力があっても被害を限定できる権限設計にしておくことが重要です。
Application Passwordは「認証」を安全にするが「権限」を小さくしない
WordPressのApplication Passwordは、外部アプリやスクリプトがWordPressユーザーとしてAPI認証するための専用資格情報です。通常のログインパスワードを外部ツールへ渡さずに済み、アプリごとに発行・失効できます。
WordPress公式ドキュメントでは、Application Passwordは特定のWordPressユーザーに紐づき、REST APIなどのプログラムアクセス向けで、wp-login.phpからの対話的ログインには使わない仕組みと説明されています。
ここで混同したくないのが「認証」と「認可」です。Application Passwordは「どのWordPressユーザーとして接続するか」を安全に分ける仕組みで、接続後に何ができるかは、そのユーザーに割り当てられたRole・Capabilityの影響を受けます。
そのため、AdministratorユーザーからApplication Passwordを発行してAIへ渡しても、「管理者権限を最小化した」ことにはなりません。通常パスワードを共有しない点では改善しますが、記事制作AIなら先に専用ユーザーの権限を小さくしておく方が重要です。
Application Passwordは秘密情報として扱い、AI連携ごとに別々に発行し、不要になったものは失効させます。WordPress公式でも、連携ごとに使い回さず発行すること、不要な資格情報の失効、漏えいが疑われる場合のローテーション、HTTPSの利用が案内されています。
WordPress記事自動化で必要なCapabilityを分解する
最小権限を考えるときは、「AIにWordPressを触らせる」という大きな単位ではなく、実際に任せたい操作へ分解します。
| AIに任せたい操作 | 主に関係するCapability | 考え方 |
|---|---|---|
| 新規記事を作成する | create_posts / 標準投稿では通常edit_postsに対応 | 下書き作成の基本 |
| 画像をアップロードする | upload_files | 画像自動化するときだけ追加 |
| 自分の公開済み記事を編集する | edit_published_posts | 公開済み記事の更新時に検討 |
| 他ユーザーの記事を編集する | edit_others_posts | 既存記事更新で要注意 |
| 記事を公開する | publish_posts | 人間承認を残すなら付けない |
| カテゴリーを作成・管理する | manage_categories | 既存カテゴリーだけ使う運用なら不要にできる |
| 記事を削除する | delete_posts系 | 自動化では原則外したい |
WordPress REST APIの投稿作成でも、対象の投稿タイプに設定されたcreate_postsなどのCapabilityが確認されます。標準投稿ではcreate_postsは通常edit_postsへ対応しますが、カスタム投稿タイプでは独自のCapability構成になっている場合があります。
また、WordPressのedit_postは、対象記事の所有者や公開状態に応じてedit_posts、edit_others_posts、edit_published_postsなどへマッピングされます。つまり「記事を編集できる権限」だけを雑に考えると、既存記事の更新で想定以上に広い権限が必要になることがあります。
特に、普段の記事を人間のアカウントで公開していて、AI専用ユーザーから過去記事を更新する場合は注意が必要です。公開済み・他ユーザー所有の記事では、状況に応じてedit_others_postsとedit_published_postsが関係します。
記事制作AIは3段階で権限を増やす
最初から「完全自動」を目指すより、自動化する範囲に合わせて権限を段階的に増やす方が運用しやすくなります。
段階1：下書き作成まで
もっとも始めやすいのは、AIに新規記事の作成と必要なら画像アップロードまで任せ、公開は人間が行う構成です。publish_postsを与えなければ、AIが記事を作れても公開操作までは進めません。
新規記事中心なら、AI専用ユーザーが自分で作った下書きを扱う構成にしやすく、edit_others_postsも避けやすくなります。
段階2：自分が作成した公開記事の更新まで
AI専用ユーザーが作成した記事を、その後もAIが更新するなら、公開済み投稿を編集する権限を追加する構成が考えられます。公開操作そのものを人間に残すか、AIまで許可するかは別に判断します。
段階3：人間が作成した既存記事も更新する
ここから権限が一段広がります。AI専用ユーザーが他ユーザー所有の記事を編集するにはedit_others_postsが関係するため、「この10記事だけ更新してほしい」のにWordPress側ではより広い編集権限を持つ構成になりやすいからです。
この段階では、WordPressのRoleだけに頼らず、AIや中継API側で「更新してよい投稿ID」「許可する投稿タイプ」「利用できる操作」をallowlist化する価値が高くなります。
WordPress側とAI側の二重の最小権限にする
AIエージェントの安全性は、WordPressユーザーを弱いRoleにしただけでは完成しません。WordPressで許可された範囲の中でも、AIに見せるツールをさらに絞ります。
たとえば記事更新エージェントなら、get_post、create_draft、update_allowed_post、upload_mediaのような用途別ツールだけを用意し、汎用的な「任意のREST APIを呼ぶ」「任意のURLへPOSTする」「任意のPHPやシェルを実行する」といった強力なツールは与えない方が管理しやすくなります。
OWASPもAIエージェントに対して、必要最小限のツールだけを与え、読み取り・書き込みや対象リソース単位で権限を分け、重要な操作には明示的な承認を要求することを推奨しています。
- 更新できる投稿IDや投稿タイプをallowlistで制限する
- 削除、ユーザー管理、プラグイン変更、サイト設定のツールは記事制作AIから外す
- 公開・削除・大量更新など影響の大きい操作は人間承認を挟む
- 更新前後の差分、実行ユーザー、対象記事、時刻をログへ残す
- WordPressのリビジョンやバックアップで戻せる状態を維持する
さらに、Webページ、メール、PDF、他サイトの記事などをAIが読むワークフローでは、それらを「命令」ではなく「信頼できない外部データ」として扱う設計も必要です。間接的なプロンプトインジェクションを完全に予測するのは難しいため、最終的には「だまされても危険な操作ができない」構成が効きます。
WordPress 6.9以降はAbilities APIとMCP Adapterも選択肢
2026年8月時点では、WordPress側にもAIエージェントとの連携を意識した仕組みが増えています。WordPress 6.9以降で利用できるAbilities APIは、WordPressやプラグインが提供する機能を「Ability」という単位で登録し、入力・出力・権限を明示できる仕組みです。
Abilities APIの公式ドキュメントでは、Abilityごとに入力・出力のスキーマやPermission Callbackを持たせられ、AIや自動化ツールから利用できることが説明されています。
さらに、WordPress公式のMCP Adapterを使うと、AbilitiesをAIエージェントからMCPツールとして利用できます。公式のデフォルトMCPサーバーでは、AbilityをMCPへ公開するには明示的な設定が必要になっています。
これは「MCPを使えば自動的に安全」という意味ではありません。MCPでも、どのAbilityを公開するか、各Abilityで誰の実行を許可するか、接続ユーザーにどのWordPress権限を持たせるかを設計する必要があります。
ただし、「WordPress全体を自由に操作できる一本の万能ツール」をAIへ渡すより、「記事を取得する」「許可された記事を更新する」といった小さな機能へ分割する設計とは相性が良いと考えられます。
AIエージェントをWordPressにつなぐ実務手順
実際に導入するときは、AIサービスから先に設定するのではなく、次の順序で権限を決めると整理しやすくなります。
- 自動化したい操作を書き出す。 新規下書き、既存記事更新、画像アップロード、公開などを分けます。
- AI専用のWordPressユーザーを作る。 日常的に使うAdministratorアカウントと資格情報を共有しません。
- 必要なCapabilityだけを与える。 標準Roleで過不足があるなら、カスタムRoleを検討します。
- 専用のApplication Passwordを発行する。 連携ごとに分け、HTTPSで接続し、秘密情報として保管します。
- AI側のツールと対象リソースを絞る。 投稿ID、投稿タイプ、操作種別をallowlist化し、不要な管理操作を見せません。
- まず下書き運用でテストする。 更新差分、画像、カテゴリー、メタデータなどが想定どおりか確認します。
- 必要な操作だけ段階的に自動化する。 公開や大量更新は、必要性と復旧手段を確認してから広げます。
標準のAuthorやEditorをそのまま使う方法もありますが、目的に対して不要な権限まで含まれたり、逆に必要な操作が足りなかったりします。長期運用するなら「AI記事制作用Role」として必要なCapabilityを明示した方が、あとから監査しやすくなります。
こんな構成は避けたい
次のような構成は、動作確認では手軽でも、本番運用では権限が広がりすぎやすくなります。
- 普段使っているAdministratorのApplication PasswordをそのままAIへ登録する
- 複数のAIサービスやMCPサーバーで同じ資格情報を使い回す
- 記事更新AIにプラグイン、テーマ、ユーザー、設定変更までできるツールを渡す
- 外部Webページを大量に読むエージェントへ無承認の公開・削除権限を与える
- 更新ログ、リビジョン、バックアップなしで大量更新を自動実行する
一時的に管理系の操作が必要な場合でも、記事制作エージェントへ常時持たせる必要はありません。管理操作専用の別ワークフローに分け、必要なときだけ権限を付与・承認する方が、事故時の影響範囲を狭くできます。
まとめ：AIには「できるだけ少なく、必要なときだけ」権限を渡す
AIエージェントにWordPressを操作させること自体が危険なのではなく、一つの資格情報、一つのユーザー、一つの万能ツールへ権限を集めすぎることが問題です。
記事制作であれば、まずAI専用ユーザーを作り、必要なCapabilityだけを与えます。API接続には専用Application Passwordを使い、AI側でも操作と対象記事をallowlist化します。公開・削除・サイト設定のような影響が大きい操作は、人間承認や別ワークフローへ切り分けます。
最初は「下書きまで」、問題なければ「自分の記事更新」、必要になったら「既存記事更新」という順に広げれば、便利さと安全性のバランスを取りやすくなります。
AIエージェントとWordPress権限のよくある質問
- QApplication PasswordならAdministratorで使っても安全ですか？
- A
通常のログインパスワードを外部ツールへ共有しない点では有効ですが、Application PasswordそのものがWordPressユーザーの権限を小さくするわけではありません。記事制作だけなら、Administratorではなく専用ユーザーへ必要最小限のCapabilityを与える構成を優先します。
- QAuthorやEditorの標準RoleをAI専用ユーザーに使えば十分ですか？
- A
小規模なテストなら選択肢ですが、標準RoleはAI自動化専用に設計されたものではありません。必要な操作より権限が広かったり、逆に画像アップロードや他ユーザーの記事更新などで不足したりするため、長期運用では必要なCapabilityを確認したカスタムRoleの方が設計を明確にできます。
- QAIに既存記事を更新させるときはedit_others_postsが必要ですか？
- A
AI専用ユーザーとは別のユーザーが所有する投稿を編集する場合は、対象投稿タイプの
edit_others_postsが関係します。公開状態などによってedit_published_postsも必要になるため、実際の投稿タイプと所有者を確認してください。
- QMCP Adapterを使えばREST APIより安全になりますか？
- A
接続方式だけで安全性が決まるわけではありません。Abilities APIとMCP Adapterは機能を小さなAbility単位で公開しやすい仕組みですが、Permission Callback、接続ユーザーの権限、公開するAbility、AI側の承認やallowlistも含めて設計する必要があります。
コメント