WordPressをAIから操作する方法は、いまいくつもあります。
どれを選ぶかで触れる範囲がまったく違います。
記事は書き換えられるのにプラグインは更新できない、ファイルは置けるのに記事は作れない、といったことが起きます。
この記事では、WordPressとAIをつなぐ手段を一通り並べて、手段ごとにいじれる範囲を表で比べます。
最後に、用途から選べる早見表も付けています。
接続手段でいじれる範囲の比較
先に結論の表です。
| 接続手段 | 記事・固定ページ | メディア | サイト設定 | プラグインの導入・有効化 | テーマ／プラグインのファイル | データベース | サーバー |
|---|---|---|---|---|---|---|---|
| アプリケーションパスワード＋REST API | ○ | ○ | △ | ○ | × | × | × |
| MCP（MCP Adapter /コネクタ） | △ | △ | △ | × | × | × | × |
| SSH＋WP-CLI | ○ | ○ | ○ | ○ | ○ | ○ | △ |
| SFTP・FTP | × | △ | × | △ | ○ | × | × |
| サイト内のAIプラグイン | ○ | △ | × | × | × | × | × |
△ の中身は、手段ごとに事情が違います。
- REST APIのサイト設定：
/wp/v2/settingsにある項目だけ。サイト名・キャッチフレーズ・表示設定・タイムゾーンなど - MCP：ability として公開された操作だけ。用意されていない操作はできない
- SSHのサーバー設定：契約と権限による。共用サーバーでは触れない範囲が多い
- SFTPのメディア：ファイルは置けるが、メディアライブラリには登録されない
- SFTPのプラグイン：ファイルを置けば導入はできるが、有効化は管理画面かWP-CLIが要る
- AIプラグインのメディア：画像生成に対応したものだけ
以下、それぞれを順に見ていきます。
アプリケーションパスワード＋REST API
いちばん手堅く、最初に試すべき方法です。
WordPress 5.6から標準で入っている機能で、プラグインは要りません。
管理画面のユーザー編集画面で発行し、REST APIにBasic認証で渡します。
WORDPRESS_URL=https://example.com
WORDPRESS_USERNAME=your-name
WORDPRESS_APP_PASSWORD=xxxx xxxx xxxx xxxx xxxx xxxxこの方法の性格
- 既定ではHTTPSが必須。HTTPのサイトでは発行欄が出ない（フィルターで強制はできる）
- 管理画面へのログインには使えない。プログラムからの接続専用
- 用途ごとに発行して、個別に失効できる
- 権限はそのユーザーの権限がそのまま乗る
最後の点が大事です。
管理者アカウントで発行すると、AIにも管理者と同じことができる状態になります。
AIに渡す用のユーザーを別に作り、必要な権限だけ与えるのが安全です。
触れるもの・触れないもの
REST APIの標準エンドポイントで扱えるのは次の範囲です。
| 対象 | できること |
|---|---|
| 投稿・固定ページ | 取得・作成・更新・削除 |
| メディア | アップロード・差し替え |
| カテゴリ・タグ | 取得・作成・更新 |
| カスタムフィールド | △ show_in_rest を有効にしたものだけ |
| サイト設定 | △ /wp/v2/settings にある項目だけ |
| プラグイン | 一覧・導入・有効化・無効化（権限とファイル書き込みの可否による） |
| テーマ | △ 一覧の取得のみ。切り替えはできない |
| テーマやプラグインのファイル | × |
| データベース | × |
ファイルとデータベースには一切触れません。
裏を返すと、事故ってもファイルは壊れないということでもあります。
発行手順と、つまずきやすいところは別の記事にまとめています。
メタディスクリプションやカスタムフィールドを扱う場合は、こちらもあわせてご覧ください。
MCP（コネクタとしてつなぐ）
いま動きがいちばん速いのがここです。
MCPは、AIツールが外部の機能を呼び出すための共通の決まりごとです。
WordPress側は、次の2つの部品でこれに対応しています。
| 部品 | 役割 | 状況 |
|---|---|---|
| Abilities API | プラグインやテーマが「できること」を機械が読める形で登録する仕組み | WordPress 6.9からコアに入っている |
| MCP Adapter | 登録された ability を、MCPのツールとして外に出す橋渡し | WordPress公式のパッケージとして開発中 |
プラグインが wp_register_ability() で機能を登録し、MCP Adapterがそれをそのままツールとして公開する、という流れです。
AI側は、コネクタの設定にそのMCPサーバーを登録すればつながります。
HTTPとSTDIOのどちらのつなぎ方にも対応しています。
REST APIと何が違うか
REST APIはデータの入れ物を触ります。
MCPは操作そのものを渡します。
違いが出るのは、次のようなところです。
- AIが自分で「何ができるか」を読み取れる。エンドポイントの仕様を教え込まなくてよい
- 操作の単位で権限を絞れる。削除系を最初から渡さない、といったことができる
- プラグインが独自の機能を ability として出していれば、そのプラグイン固有の操作もAIから呼べる
- 逆に、ability が用意されていない操作はできない
最後の点が、いまのMCPのいちばんの制約です。
なんでも触れるわけではなく、公開されているものだけが使える形です。
情報が古くなりやすい領域です
この分野は名前も置き場所もよく変わります。
以前よく紹介されていた Automattic の「WordPress MCP」はすでにアーカイブされており、WordPress公式の mcp-adapter に引き継がれています。
SSH＋WP-CLI
できることがいちばん広い方法です。
サーバーにSSHで入り、WP-CLIというコマンドでWordPressを操作します。
AIにシェルを使わせられる環境なら、そのまま実行させることもできます。
wp post list --post_type=post --format=csv
wp post update 123 --post_status=draft
wp plugin update --all
wp search-replace 'http://example.com' 'https://example.com' --dry-run
wp db export backup.sqlREST APIでは届かないところに手が入ります。
- プラグインとテーマの更新
- WordPress本体の更新
- データベースの一括置換（サイト移転のURL置換など）
- データベースのバックアップ
- テーマやプラグインのファイルの直接編集
強い代わりに、事故も大きい
戻せない操作がそのまま通ります。
REST APIならエラーで止まるところが、シェルでは実行されてしまいます。
AIに任せる場合は、次のように区切っておくのが現実的です。
- まず
--dry-runの付くコマンドで確認する（search-replaceなど） - 実行前に
wp db exportでバックアップを取る - 本番ではなく、ステージング環境で先に試す
- 削除系のコマンドは、人が見てから実行する
レンタルサーバーによってはSSHが使えません。
使えるかどうかは、契約しているサーバーの仕様をご確認ください。
SFTP・FTP
ファイルだけを扱う方法です。
テーマの functions.php やスタイルシートを直したいときに使います。
できることとできないことがはっきり分かれます。
| 対象 | 扱えるか |
|---|---|
| テーマ・プラグインのファイル | ○ |
| アップロードフォルダのファイル | ○ |
| 記事・固定ページ | × データベースの中にあるため |
| サイト設定 | × 同上 |
| プラグインの有効化 | × ファイルは置けるが有効化は別 |
記事に関わる作業には向きません。
ファイルを直すときだけの手段と考えてください。
SSHが使えるなら、SFTPでできることはSSHでもできます。
サイト内のAIプラグイン（向きが逆の方法）
ここまでは外のAIからWordPressを操作する方法でした。
これは逆で、WordPressの中からAIのAPIを呼ぶ方法です。
管理画面の中で記事の下書きを作ったり、サイトにチャットボットを置いたりできます。
- 編集画面から本文の下書きを作る
- 見出しや要約を作る
- サイトにチャットボットを置く
- 対応しているものは画像も生成できる
代表的なものに AI Engine があります（10万サイト以上で有効・2026年9月8日更新）。
外からの一括処理には向きません。
記事を100本まとめて直したい、といった用途ならREST APIかWP-CLIを使ってください。
編集を助けてほしいのか、まとめて処理したいのかで選び分けます。
XML-RPCという古い方法もあります
アプリケーションパスワードが入る前は、xmlrpc.php を使うのが一般的でした。
いまも本体には残っています。
ただしこれから選ぶ理由はありません。
- 総当たり攻撃の入口になりやすく、セキュリティプラグインで塞がれていることが多い
- REST APIのほうが扱える範囲が広い
- アプリケーションパスワードのように、用途ごとに失効させられない
古い記事の手順がXML-RPCだった場合は、REST APIに置き換えられないか先に検討してください。
用途からどれを選ぶか
| やりたいこと | 向いている手段 |
|---|---|
| 記事をまとめて作る・直す | アプリケーションパスワード＋REST API |
| メタ情報やカスタムフィールドを一括で入れる | アプリケーションパスワード＋REST API |
| AIと会話しながらサイトを操作する | MCP |
| プラグイン固有の機能をAIから呼ぶ | MCP（abilityが用意されていれば） |
| プラグインや本体をまとめて更新する | SSH＋WP-CLI |
| サイト移転でURLを一括置換する | SSH＋WP-CLI |
| テーマのファイルを直す | SSH または SFTP |
| 編集画面で下書きを作る | サイト内のAIプラグイン |
| 決まった処理を定期実行する | REST API＋スクリプト |
定期実行の作り方は、Google Apps Scriptを使った例を別記事にまとめています。
AIにつなぐ前に決めておくこと
どの手段を選んでも、共通で効く決めごとがあります。
権限を絞る
- AI用のユーザーを別に作る。管理者アカウントをそのまま渡さない
- 投稿だけ触らせたいなら投稿者権限で足りることが多い
- 用途ごとにアプリケーションパスワードを分けて発行する。問題が起きたらその1本だけ止められる
アプリケーションパスワードは管理画面のログインとは別の経路を通ります。
2段階認証を設定していても、この経路では求められません。
そのぶん、発行したパスワードの管理が効いてきます。
認証情報を書き込まない
.envに入れて、.gitignoreに.envを追加する- スクリプトやプロンプトに直接書かない
- 使わなくなったらその場で失効させる
戻せるようにしておく
- まとめて処理する前にバックアップを取る
- 書き込む前に、変更内容を出力するだけの下見を挟む
- 本番の前にステージング環境で試す
- 削除系の操作は最初から渡さない
「下見してから書き込む」を型にしておくと、事故がほぼ起きなくなります。
なお、REST APIでの接続がセキュリティプラグインに止められることがあります。
401エラーが出た場合の見方は、別記事にまとめています。
まとめ
- 記事まわりを触るなら、アプリケーションパスワード＋REST API。ファイルとDBには届かないぶん安全
- AIと会話しながら操作するならMCP。Abilities APIがWordPress 6.9でコアに入り、MCP Adapterが橋渡しする
- MCPで使えるのは、abilityとして公開された操作だけ
- プラグイン更新やDB操作はSSH＋WP-CLI。できることが広い代わりに戻せない
- SFTPはファイル専用。記事には触れない
- サイト内のAIプラグインは向きが逆。編集を助けるもので、一括処理には向かない
- XML-RPCはこれから選ぶ理由がない
どの手段でも、AI用のユーザーを分けて権限を絞るところから始めてください。
この記事の内容は2026年9月10日時点で確認したものです。
MCPまわりは動きが速いので、導入前に公式リポジトリの更新状況もあわせてご覧ください。
