WordPress│AIと接続する方法まとめ｜アプリケーションパスワード・MCP・SSHの違い

2026.09.102026.10.23

WordPressをAIから操作する方法は、いまいくつもあります。

どれを選ぶかで触れる範囲がまったく違います。

記事は書き換えられるのにプラグインは更新できない、ファイルは置けるのに記事は作れない、といったことが起きます。

この記事では、WordPressとAIをつなぐ手段を一通り並べて、手段ごとにいじれる範囲を表で比べます。

最後に、用途から選べる早見表も付けています。

接続手段でいじれる範囲の比較

標準REST API、通常のファイル転送、各ツールの提供機能を比べた表です。○にも利用者権限・接続設定・書込み権限の条件があります。AIプラグインは製品差が大きいため一律には判断できません。

スクロールできます

接続手段	記事・固定ページ	メディア	サイト設定	プラグインの導入・有効化	テーマ／プラグインのファイル	データベース	サーバー
アプリケーションパスワード＋REST API	○	○	△	○	×	×	×
MCP（MCP Adapter /コネクタ）	△	△	△	△	△	△	△
SSH＋WP-CLI	○	○	○	○	○	○	△
SFTP・FTP	×	△	×	△	○	×	×
サイト内のAIプラグイン	△	△	△	△	△	△	△

○ 標準的に対応／△ 実装・条件による／× 当該方式の標準操作では非対応（主要項目を2026年10月23日再照合）

△ の中身は、手段ごとに事情が違います。

REST APIのサイト設定：/wp/v2/settings にある項目だけ。サイト名・キャッチフレーズ・表示設定・タイムゾーンなど
MCP：サーバーが公開し、利用者に許可した操作だけ。WordPress MCP Adapterでは公開設定されたabilityを使います。別実装のMCPが同じAbilities APIを使うとは限りません。
SSHのサーバー設定：契約と権限による。共用サーバーでは触れない範囲が多い
SFTPのメディア：ファイルは置けるが、メディアライブラリには登録されない
SFTPのプラグイン：ファイルを置けば導入はできるが、有効化は管理画面かWP-CLIが要る
AIプラグイン：本文・画像生成、外部API、MCPなど対応範囲は製品・版・設定による

以下、それぞれを順に見ていきます。

アプリケーションパスワード＋REST API

投稿やメディアを扱う処理では、標準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を使用します。コアの既定ではSSL接続またはローカル環境で利用できますが、利用者やサイトの設定で無効化される場合もあります。
管理画面へのログインには使えない。プログラムからの接続専用
用途ごとに発行して、個別に失効できる
権限はそのユーザーの権限がそのまま乗る

最後の点が大事です。

管理者で発行した認証情報は、対応API上で管理者の権限を使えます。管理画面の全操作が自動的にAPI化されるわけではありません。

AIに渡す用のユーザーを別に作り、必要な権限だけ与えるのが安全です。

触れるもの・触れないもの

REST APIの標準エンドポイントで扱えるのは次の範囲です。

対象	できること
投稿・固定ページ	取得・作成・更新・削除
メディア	新規アップロード・タイトルやaltなどの更新（既存IDのファイル本体を置き換える標準操作ではない）
カテゴリ・タグ	取得・作成・更新
カスタムフィールド	△ `show_in_rest` を有効にしたものだけ
サイト設定	△ `/wp/v2/settings` にある項目だけ
プラグイン	一覧・導入・有効化・無効化（権限とファイル書き込みの可否による）
テーマ	△ 一覧の取得のみ。切り替えはできない
テーマやプラグインのファイル	×
データベース	×

任意のファイル編集やSQL実行を行う標準エンドポイントはありません。

ただし、投稿更新はデータベースを書き換え、メディアの削除やプラグインの導入はファイルにも影響するため、REST APIでもバックアップと権限の確認が必要です。

発行手順と、つまずきやすいところは別の記事にまとめています。

あわせて読みたい

WordPress REST APIとは？できること・エンドポイント一覧・構築方法を実例つきで解説 WordPress REST APIで投稿や画像を扱う基本手順。認証・権限・本文の取得と更新、カスタム投稿やメタの登録、エラーと更新結果の確認方法を整理します。

メタディスクリプションやカスタムフィールドを扱う場合は、こちらもあわせてご覧ください。

あわせて読みたい

SEO SIMPLE PACK│メタ情報をREST APIから設定する方法 SEO SIMPLE PACKの投稿別タイトルとディスクリプションを、対象投稿の編集権限のあるREST APIクライアントから更新する例です。メタ情報はeditコンテキストで読み取りま…

MCP（コネクタとしてつなぐ）

いま動きがいちばん速いのがここです。

MCPは、AIツールが外部の機能を呼び出すための共通の決まりごとです。

WordPressのMCP Adapterによる構成では、主に次の2つを使います。他のMCP実装もあります。

部品	役割	状況
Abilities API	プラグインやテーマが「できること」を機械が読める形で登録する仕組み	WordPress 6.9からコアに入っている
MCP Adapter	登録された ability を、MCPのツールとして外に出す橋渡し	WordPressプロジェクトのパッケージ。配布版・移行手順を公式で確認

プラグインが wp_register_ability() で機能を登録し、MCP Adapterの公開設定と権限チェックに従ってツールとして提供する、という流れです。

利用するAIクライアントが接続方式と認証に対応している必要があります。サーバーURLを登録するだけで、権限のない操作が使えるようにはなりません。

HTTPとSTDIOのどちらのつなぎ方にも対応しています。

REST APIと何が違うか

REST APIでは、エンドポイントとHTTPメソッドでデータや操作を扱います。独自の処理をエンドポイントとして追加することもできます。

MCPでは、対応クライアントがツールの説明や入力形式を取得し、公開された処理を呼び出せます。背後でREST APIを使う構成もあります。

違いが出るのは、次のようなところです。

ツールの説明と入力スキーマを機械的に取得できる。ただし、説明の品質や処理結果の検証は別途必要
サーバー側の認証・権限チェックと公開ツールの選択で操作を制限できる。MCP接続だけで自動的に制限されるわけではない
プラグインが独自の機能を ability として出していれば、そのプラグイン固有の操作もAIから呼べる
MCP Adapterでは、公開対象にしたabilityと利用者の権限の範囲で操作する

制約は、選んだサーバーが何を公開しているかで決まります。

なんでも触れるわけではなく、公開されているものだけが使える形です。

情報が古くなりやすい領域です

この分野は名前も置き場所もよく変わります。

Automatticの「WordPress MCP」は2026年9月17日にアーカイブされ、継続開発先としてWordPressのmcp-adapterを案内しています。旧リポジトリとMCP Adapterの導入・移行資料を確認してください。

GitHub – WordPress/mcp-adapter: An MCP adapter that bridges the Abilities API to the Model Context P…

更新日だけで対応可否を判断せず、配布版、必要環境、移行手順、公開される操作と権限を確認してください。

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.sql

REST APIでは届かないところに手が入ります。

プラグインとテーマの更新
WordPress本体の更新
データベースの一括置換（サイト移転のURL置換など）
データベースのバックアップ
テーマやプラグインのファイルの直接編集

強い代わりに、事故も大きい

削除や上書きによって情報を失う可能性があります。復元には事前のバックアップなどが必要です。

REST APIもシェルも、許可された更新や削除は実行するため、接続方式だけで事故を防げるわけではありません。

AIに任せる場合は、次のように区切っておくのが現実的です。

まず --dry-run の付くコマンドで確認する（search-replace など）
実行前にDBと対象ファイルをバックアップする。wp db exportはDBだけで、テーマ・プラグイン・アップロード画像は含まない
本番ではなく、ステージング環境で先に試す
削除系のコマンドは、人が見てから実行する

レンタルサーバーによってはSSHが使えません。

使えるかどうかは、契約しているサーバーの仕様をご確認ください。

SFTP・FTP

通常の用途はファイル転送です。SFTPと平文FTPは別の方式で、本番の認証情報やファイルを扱う接続ではSFTPなど暗号化された方式を選びます。

テーマの functions.php やスタイルシートを直したいときに使います。

できることとできないことがはっきり分かれます。

対象	扱えるか
テーマ・プラグインのファイル	○
アップロードフォルダのファイル	○
記事・固定ページ	× データベースの中にあるため
サイト設定	× 同上
プラグインの有効化	× ファイルは置けるが有効化は別

記事に関わる作業には向きません。

表は通常のファイル転送操作を比較しています。実行可能なPHPの書込みを許すと、DBやサイト全体への影響もあり得るため、権限がファイルだけに限定されるとは考えないでください。

SSHのシェル権限とSFTP専用アカウントの許可範囲は契約・設定で異なります。

サイト内のAIプラグイン

ここまでは外のAIからWordPressを操作する方法でした。

主な用途の一つは、WordPressの中からAIのAPIを呼び出すことです。外部向けのREST APIやMCPを提供する製品もあります。

管理画面の中で記事の下書きを作ったり、サイトにチャットボットを置いたりできます。

編集画面から本文の下書きを作る
見出しや要約を作る
サイトにチャットボットを置く
対応しているものは画像も生成できる

代表例のAI Engineは、本文・画像生成だけでなくREST APIやMCPも案内しています。製品の版・プラン・設定によって使える機能を確認してください。

外部からの処理に対応するかは製品ごとに異なります。一括処理に向かないと一律には判断できません。

記事をまとめて処理する場合は、標準REST API、WP-CLI、プラグインのAPI等から、対象項目・権限・ログ・再開方法を満たすものを選びます。

編集を助けてほしいのか、まとめて処理したいのかで選び分けます。

XML-RPCという古い方法もあります

アプリケーションパスワードが入る前は、xmlrpc.php を使うのが一般的でした。

いまも本体には残っています。

新規の連携ではまずREST APIを検討し、既存クライアントがXML-RPCを必要とする場合は対応操作と認証設定を確認します。

公開された認証経路の一つになるため、利用状況とセキュリティ設定を確認する。REST APIでも認証情報の管理は必要
REST APIのほうが扱える範囲が広い
XML-RPCでもアプリケーションパスワードを利用でき、発行したパスワードを個別に失効できる

古い記事の手順がXML-RPCだった場合は、REST APIに置き換えられないか先に検討してください。

用途からどれを選ぶか

やりたいこと	向いている手段
記事をまとめて作る・直す	アプリケーションパスワード＋REST API
メタ情報やカスタムフィールドを一括で入れる	アプリケーションパスワード＋REST API
AIと会話しながらサイトを操作する	MCP
プラグイン固有の機能をAIから呼ぶ	MCP（対応ツール・権限がある場合）
プラグインや本体をまとめて更新する	SSH＋WP-CLI
サイト移転でURLを一括置換する	SSH＋WP-CLI
テーマのファイルを直す	SSH または SFTP
編集画面で下書きを作る	サイト内のAIプラグイン
決まった処理を定期実行する	REST API＋スクリプト

定期実行の作り方は、Google Apps Scriptを使った例を別記事にまとめています。

あわせて読みたい

WordPress│WP REST APIとGASを使った投稿・更新方法 GASからWordPressのREST APIを呼び、下書きの作成、投稿の読み取りと更新、専用メタ項目の更新を行います。旧記事の任意キーを書き込むpost_metaフィールドは使いませ…

AIにつなぐ前に決めておくこと

どの手段を選んでも、共通で効く決めごとがあります。

権限を絞る

AI用のユーザーを別に作る。管理者アカウントをそのまま渡さない
自分が所有する投稿の作成・更新なら投稿者権限が候補ですが、他のユーザーの投稿や固定ページには別の権限が必要です
用途ごとにアプリケーションパスワードを分けて発行する。問題が起きたらその1本だけ止められる

アプリケーションパスワードは管理画面のログインとは別の経路を通ります。

2段階認証を設定していても、この経路では求められません。

そのぶん、発行したパスワードの管理が効いてきます。

認証情報を書き込まない

.env等の安全な設定を使い、公開ディレクトリ外に保存する。.gitignoreはGit追跡を防ぐだけで、ファイルの公開や読み取りを防ぐものではない
スクリプトやプロンプトに直接書かない
使わなくなったらその場で失効させる

戻せるようにしておく

まとめて処理する前にバックアップを取る
書き込む前に、変更内容を出力するだけの下見を挟む
本番の前にステージング環境で試す
削除系の操作は最初から渡さない

変更差分の確認に加えて、更新直前の競合確認と復元手順も用意してください。

なお、REST APIでの接続がセキュリティプラグインに止められることがあります。

401エラーが出た場合の見方は、別記事にまとめています。

あわせて読みたい

SWELL│REST API 401エラー「swell-ct-pv」の原因と解決方法 SWELLの swell-ct-pv へのPOSTが401になると、PV計測に失敗している可能性があります。ただし401だけでは原因のプラグインを特定できません。リクエスト先、送信方法、…

まとめ

記事まわりを触るなら、アプリケーションパスワード＋REST API。操作範囲とユーザー権限を確認する
AIと会話しながら操作するならMCP。Abilities APIがWordPress 6.9でコアに入り、MCP Adapterが橋渡しする
MCPで使える操作は、選んだサーバーが公開したツールと利用者の権限で決まる
プラグイン更新やDB操作にはSSH＋WP-CLIも候補。DBとファイルのバックアップ・復元手順を用意する
SFTPは通常のファイル転送用。実行可能ファイルを書ける権限の影響にも注意する
AIプラグインは編集支援に加え、製品によって外部APIやMCPにも対応する
XML-RPCは既存連携の必要性を確認し、新規ではREST APIも検討する

どの手段でも、AI用のユーザーを分けて権限を絞るところから始めてください。

2026年10月23日に公式資料で接続方式と主要な機能範囲を再照合しました。すべての接続・権限・画面操作を実機検証した比較ではありません。

MCPまわりは動きが速いので、導入前に公式リポジトリの更新状況もあわせてご覧ください。

この記事で紹介しているコードは、GitHubのMOTOKI-LLC/WAZA-codeにもまとめています。

XML-RPCとREST APIのアプリケーションパスワード認証については、WordPress公式資料を参照してください。

よくある質問：WordPressとAIを接続する方法

WordPressをAIから操作するには、どんな方法がありますか？

標準REST API、MCP、SSH＋WP-CLI、SFTP、サイト内のAIプラグインなどがあります。対応操作は実装・設定・権限で異なり、方式を選ぶだけで全機能が使えるわけではありません。

記事を書き換えるだけなら、どの方法ですか？

記事の早見表では、記事まわりを触るなら、アプリケーションパスワード＋REST APIを選び、操作範囲とユーザー権限を確認します。AIと会話しながら操作するならMCP、プラグインや本体をまとめて更新するならSSH＋WP-CLI、テーマのファイルを直すならSSHまたはSFTP、編集画面で下書きを作るならサイト内のAIプラグインが挙げられています。

MCPでは、何でも操作できますか？

いいえ。選んだMCPサーバーの公開ツールと利用者の権限の範囲に限られます。WordPress MCP Adapterは公開対象のabilityを橋渡ししますが、別のMCP実装が同じ仕組みを使うとは限りません。

SSH＋WP-CLIは、何が強くて、何が危ないですか？

WordPress本体・テーマ・プラグインの更新やDB操作などを行えます。誤った上書きや削除は復元が必要になるため、変更前のDBとファイルを保存し、対応コマンドのdry-runや検証環境で確認してください。SSHの利用可否と権限は契約に依存します。

AIにつなぐ前に、何を決めておけばよいですか？

記事では、権限を絞る（AI用のユーザーを別に作り、管理者アカウントをそのまま渡さない。用途ごとにアプリケーションパスワードを分けて発行する）、認証情報をスクリプトやプロンプトに直接書かない、使わなくなったらその場で失効させる、戻せるようにしておく（バックアップ、書き込む前の下見、ステージングで試す、削除系は最初から渡さない）、の4点を挙げています。

アプリケーションパスワードは、2段階認証をしていても使えますか？

記事によると、アプリケーションパスワードは管理画面のログインとは別の経路を通るため、2段階認証を設定していても、この経路では求められません。そのぶん、発行したパスワードの管理が効いてきます。REST APIでの接続がセキュリティプラグインに止められることもあり、401エラーが出た場合の見方は記事内で案内している別記事にまとめられています。