WordPress自動投稿はREST APIとMCPどちら？認証・詰まりどころを比較

WordPress自動投稿はREST APIとMCPどちらを使うべきか徹底比較

【概　要】

「WordPressの自動投稿はMCPでやるのが今風で、REST APIはもう古いのでは」——最近、こうした質問をいただくことが増えました。MCP（Model Context Protocol）は、AIエージェントが外部ツールを呼び出すための共通規格です。WordPressでも公式のMCP Adapterプラグインが登場したことで、「AIにそのまま投稿させる」構成が現実的な選択肢になってきました。

一方、当サイトの記事は今でもREST API経由で投稿しています。Claude Codeに原稿を書かせ、自作のPythonスクリプトでGutenbergブロックに変換してから、REST APIで下書き保存する流れです。この仕組みを作る過程では、認証エラーやサーバーのWAFでかなり遠回りしました。

この記事では、現暗号資産ニュースメディア編集長として、そして自分のブログでAIアフィリエイトを実践している立場から、REST APIとMCPを「認証方式」「詰まりどころ」「向いているケース」の3つの観点で比べます。結論を先に言うと、この2つは対立するものではありません。何を自動化したいかで選ぶものです。MCPについては2026年10月時点の公式情報をもとに整理しているので、これから自動投稿を組む方の判断材料になれば幸いです。

【目　次】

1. そもそもREST APIとMCPは「どちらか一方」の関係ではない
2. 比較早見表：認証・準備・自由度・向いている人
3. REST APIで自動投稿する仕組み（当サイトの構成）
4. MCPで自動投稿する仕組み（2026年10月時点の状況）
5. 認証方式の比較：どちらも中身はアプリケーションパスワード
6. 詰まりどころの比較と、私が実際につまずいたこと
7. 結局どちらを選ぶべきか：ケース別のおすすめ
8. まとめ：REST APIとMCPを選ぶためのチェックリスト

1. そもそもREST APIとMCPは「どちらか一方」の関係ではない

最初に誤解を解いておくと、WordPressのMCPは、REST APIに取って代わる新しい通信経路ではありません。

WordPress公式のMCP Adapterは、サイト上に `/wp-json/mcp/mcp-adapter-default-server` というエンドポイントを追加します。URLを見ると分かるとおり、これはREST APIの仕組みの上に作られたMCP用の入り口です。違いは「誰が、どんな形で呼び出すか」にあります。

REST API：プログラム（PythonやNode.jsなど）が、決まったURLに決まった形式のデータを送る。動作は人間が書いたコードどおりに決まる
MCP：AIエージェント（Claude Desktop、Claude Codeなど）が、サイト側に用意された「できること（ability）」の一覧を見て、どれを呼ぶかを自分で判断する

つまり、REST APIは「決めた処理を毎回同じように実行する」道具で、MCPは「AIに判断をまかせて操作させる」道具です。自動投稿で大事なのが再現性なのか柔軟性なのかで、向き不向きが分かれます。

2. 比較早見表：認証・準備・自由度・向いている人

まずは全体像を表にまとめます。

比較項目	REST API（自作スクリプト）	MCP（MCP Adapter）
主な認証方式	アプリケーションパスワード（Basic認証）	HTTP接続はアプリケーションパスワード／ローカルはWP-CLI経由のユーザー指定
サイト側の準備	基本的に不要（標準機能）	プラグイン導入＋公開するabilityの設定
必要なWordPressバージョン	4.7以降（REST APIの標準搭載）	6.9以上（Abilities APIがコアに入ったバージョン）
処理の再現性	高い（毎回同じコードが動く）	AIの判断を挟むため、指示の書き方次第でぶれる
柔軟性	低い（想定外の操作は書き足しが必要）	高い（会話で「この記事のタグを直して」などができる）
成熟度	長く使われてきた標準機能	プラグインは0.x系（執筆時点で0.7.1）
向いているケース	記事の量産、毎回同じフォーマットでの投稿	既存記事の確認・修正、サイト運営の対話的な補助

なお、Automatticが公開していた旧「wordpress-mcp」プラグインは、GitHub上で非推奨・アーカイブ済みと明記されており、後継としてWordPress公式のMCP Adapterが案内されています。古い解説記事を参考にする場合は、どちらのプラグインの話なのかを確認してください。

3. REST APIで自動投稿する仕組み（当サイトの構成）

投稿までの流れ

当サイトの自動投稿は、次のような流れになっています。

Claude Codeが記事原稿をMarkdownで書き、作業フォルダに保存する
自作のPythonスクリプトが、Markdownを段落・見出しごとのGutenbergブロックに変換する
目次やアフィリエイトバナーなど、毎回入れるパーツをスクリプト側で自動で差し込む
REST APIの `/wp-json/wp/v2/posts` に下書きとして送る
管理画面で私が目を通してから公開する

Claude Codeを使って非エンジニアがこの仕組みを作った経緯は、Claude Codeで非エンジニアがWordPress自動投稿に挑む【前編】で詳しく書いています。

REST APIの強みは「毎回同じ」であること

この構成で一番ありがたいのは、同じ原稿を渡せば、毎回まったく同じブロック構成で投稿されることです。目次の位置、バナーの位置、FAQの書式など、サイトのルールをすべてコードに固定できます。記事を量産するときに、AIの気まぐれで体裁が崩れる心配がありません。

画像も同じ考え方で扱えます。アイキャッチ画像をメディアAPIにアップロードし、記事の `featured_media` に紐付ける処理もスクリプトに組み込みました（アイキャッチ画像の自動生成と投稿の手順）。

4. MCPで自動投稿する仕組み（2026年10月時点の状況）

MCP Adapterの基本構造

WordPress.orgのプラグインディレクトリによると、MCP Adapterは執筆時点でバージョン0.7.1です（2026年10月15日リリース）。動作要件はWordPress 6.9以上、PHP 7.4以上です。役割をひと言でいうと、WordPressのAbilities APIに登録された「ability（できること）」を、MCPのツールとしてAIに見せる変換器です。

公式リポジトリによると、標準のMCPサーバーでAIに公開されるのは次の3つのメタツールです。

`mcp-adapter/discover-abilities`：使えるabilityの一覧を探す
`mcp-adapter/get-ability-info`：個々のabilityの詳細を調べる
`mcp-adapter/execute-ability`：abilityを実行する

AIはまず一覧を調べ、「記事を作成する」に当たるabilityを見つけて実行する、という手順で動きます。

プラグインを入れただけでは投稿できない

ここが一番の落とし穴です。abilityはデフォルトで非公開になっていて、公開設定（`meta.public` など）をしたものしかAIからは見えません。

さらに、コアに標準で登録されているabilityは多くありません。Kinstaの解説によると、WordPress 7.0を新規インストールした状態で登録されているのは `core/get-site-info`、`core/get-user-info`、`core/get-environment-info` の3つです。いずれも情報を取得するためのもので、記事を作成するabilityが標準で用意されていることは、執筆時点で確認できていません。

つまり、MCPで投稿までさせたい場合は、投稿用のabilityを提供するプラグインを入れるか、自分でPHPコードを書いてabilityを登録する必要があります。「プラグインを入れればAIがすぐ記事を投稿してくれる」と期待していると、最初の段階で止まってしまいます。

ここまで読んで、ちょっと難しいなと感じた方は、DMM 生成AI CAMP 学び放題のようなスクールで学ぶのもひとつの方法です。独学だと実践で使えるまでにかなり時間がかかりがちですし、AIの進化は早く、学ぶべきことも加速度的に増えています。体系立てて学べる環境があると、遠回りを減らしやすくなります。

5. 認証方式の比較：どちらも中身はアプリケーションパスワード

REST APIの認証

REST APIでは、WordPressのユーザープロフィール画面から発行するアプリケーションパスワードを使い、Basic認証でリクエストを送ります。当サイトでは、URL・ユーザー名・アプリケーションパスワードを `.env` ファイルにまとめ、スクリプトから読み込む形にしています。発行の手順と `.env` の作り方は中編の環境構築編にまとめました。

MCPの認証は2通り

MCP Adapterの公式ガイドでは、MCPクライアントとの接続方法が2つ紹介されています。

HTTPプロキシ方式：`npx` で `@automattic/mcp-wordpress-remote` を起動し、環境変数 `WP_API_URL`・`WP_API_USERNAME`・`WP_API_PASSWORD` を設定する。`WP_API_PASSWORD` に入れるのは、通常のログインパスワードではなくアプリケーションパスワード
STDIO方式：WP-CLIの `wp mcp-adapter serve` コマンドを使い、`–user=` で実行ユーザーを指定する。WordPressと同じマシン上で動かす前提なので、主にローカル開発環境向け

レンタルサーバー上の本番サイトにつなぐなら、現実的なのはHTTPプロキシ方式です。つまり、認証に使う情報はREST APIとほぼ同じで、セキュリティ面の考え方も変わりません。アプリケーションパスワードを発行したユーザーの権限がそのままAIの権限になるので、管理者ではなく、投稿者・編集者クラスの専用ユーザーを作っておくのが安全です。

6. 詰まりどころの比較と、私が実際につまずいたこと

REST APIで詰まりやすい3点

REST API側でつまずきやすい点は、私自身がすべて経験しています。

本文がClassicブロック1個になる：MarkdownやHTMLをそのまま `content` に送ると、Gutenberg上では1つの大きなClassicブロックとして扱われる。投稿はできても、あとから画像を差し込むなどの編集が極端にしづらくなる
401エラー：アプリケーションパスワードの貼り付けミスや、ユーザー名の取り違え
403エラー：レンタルサーバーのWAF（Webアプリケーションファイアウォール）が、REST APIへのリクエストを攻撃と判断して止めてしまう

特に1つ目は厄介でした。最初は「投稿できた」こと自体に満足していて、管理画面で記事を開くまでClassicブロック化に気づきませんでした。結局、変換スクリプトを作り直し、段落・見出し・表をそれぞれ独立したブロックとして送る形に変えました。この経験から、当サイトでは「REST APIに生のMarkdownやHTMLを直接送らない」ことを絶対ルールにしています。

3つ目のWAFについては、エックスサーバーやConoHa WINGのような国内の主要レンタルサーバーはどこもWAFを備えているため、自動投稿を組むなら一度は確認が必要です。WAFはMCPのHTTPエンドポイントにも同じように効くので、MCPに乗り換えればこの問題がなくなるわけではありません。

MCPで詰まりやすい3点

MCP Adapterのドキュメントを読み込んでいて、つまずきそうだと感じた点は次の3つです。

abilityが見えない：前述のとおり、公開設定をしていないとAIからは何も見えない。「接続はできたのに何もできない」状態になりやすい
0.x系ゆえの仕様変更：変更履歴を見ると、公開設定の仕組みがバージョンアップで変わっている。古い手順のままだと動かないことがある
体裁の再現性：AIが投稿内容を組み立てるため、目次やFAQの書式といったサイト固有のルールを毎回守らせるのが難しい

3つ目は、記事を量産する立場からすると大きな問題です。以前、AIへの指示だけでフォーマットを統一しようとしてうまくいかなかったことがありました（AI記事の量産で3ヶ月やって失敗したこと5つ）。その経験からも、体裁のルールはプロンプトではなくコード側に持たせるべきだと考えています。

7. 結局どちらを選ぶべきか：ケース別のおすすめ

REST APIが向いているケース

AIで書いた記事を、毎回同じフォーマットで量産・投稿したい
目次、バナー、FAQなど、サイト固有の決まりごとを確実に反映させたい
WordPressのバージョンが6.9未満、またはプラグインを増やしたくない
投稿処理をcronやコマンド1つで回したい

MCPが向いているケース

「先月の記事でアクセスの少ないものを一覧にして」「この記事のタグを整理して」など、会話しながらサイトを操作したい
決まった処理より、その場の判断が必要な作業が多い
PHPでabilityを書ける、またはabilityを提供するプラグインを使える

当サイトの結論

当サイトでは、新規記事の投稿は今後もREST API（自作スクリプト）で続けます。アフィリエイト記事は量と体裁の安定が収益に直結するからです。MCPについては、既存記事の確認や修正といった対話的な作業に向いていると考えていて、MCP Adapterが1.0に近づき、投稿系のabilityが整ってきた段階で試す予定です。

これから自動投稿を始める方には、まずREST APIで「下書き保存まで」を確実に動かすことをおすすめします。REST APIで認証やWAFの問題を一度解決しておけば、同じアプリケーションパスワードの知識がMCPでもそのまま役立ちます。順番としてもREST APIから入るほうが遠回りになりにくい、というのが実感です。

なお、どちらの方式でもClaude Codeのような実行環境が必要です。当サイトではClaude Proのプランで、原稿の執筆から投稿スクリプトの実行までをまとめて任せています。

8. まとめ：REST APIとMCPを選ぶためのチェックリスト

関係性：MCP AdapterはREST APIの上に作られたAI向けの入り口。対立する技術ではない
認証：どちらもアプリケーションパスワードが基本。AI専用に、権限を絞ったユーザーを作る
REST APIの注意点：生のMarkdownやHTMLを送るとClassicブロック化する。WAFによる403にも注意
MCPの注意点：WordPress 6.9以上が必要。abilityはデフォルト非公開で、投稿用のabilityは別途用意が必要
量産するならREST API：体裁をコードで固定できるので、記事が増えても品質がぶれない
対話的な運用ならMCP：既存記事の確認や修正など、判断が必要な作業に向く
始める順番：まずREST APIで下書き保存まで動かし、そのあとMCPを補助として足す

流行っているかどうかより、「自動化したい作業が毎回同じ処理なのか、その場の判断が必要なのか」で選ぶ。これが、両方を調べ、REST APIで実際に運用してきた私の結論です。

FAQ

MCP Adapterを入れれば、AIがすぐにWordPressへ記事を投稿してくれますか？

プラグインを入れただけでは投稿できません。MCP AdapterはWordPressに登録されたabilityをAIに見せる仕組みで、abilityはデフォルトで非公開になっています。また、コアに標準で登録されているabilityは情報取得用のものが中心で、記事を作成するabilityは別途プラグインを入れるか、自分で登録する必要があります。

REST APIとMCPで、認証の安全性に違いはありますか？

本番サイトにHTTPで接続する場合、どちらもアプリケーションパスワードを使うため、考え方は基本的に同じです。発行したユーザーの権限がそのまま自動処理の権限になるので、管理者アカウントではなく、投稿に必要な権限だけを持つ専用ユーザーを作ることをおすすめします。

REST APIで投稿すると記事がClassicブロックになってしまいます。どうすればいいですか？

MarkdownやHTMLをそのままcontentに送っていることが原因です。段落・見出し・リストなどを、ブロックコメント付きのGutenberg形式に変換してから送ると、管理画面でそれぞれが独立したブロックとして扱われます。当サイトでは、変換処理を自作スクリプトに組み込んで解決しました。

レンタルサーバーで403エラーが出るのはなぜですか？

多くの場合、サーバーのWAFがREST APIへのリクエストを不正アクセスと判断して止めています。WAFの設定画面で該当する項目を確認するか、一時的にWAFを無効にして切り分けてみてください。MCPのHTTPエンドポイントもREST APIの仕組みの上で動くため、同じ影響を受けます。

非エンジニアでもMCPで自動投稿を組めますか？

接続の設定自体は公式ガイドの設定例をなぞれば可能ですが、投稿用のabilityを用意する段階でPHPの知識や対応プラグインが必要になります。非エンジニアの方は、まずClaude CodeなどにREST API用のスクリプトを書いてもらい、下書き保存まで動かすところから始めるほうがつまずきにくいと思います。