Claude CodeとWordPressを連携する3つの方法|2サイト335本を自動投稿して分かった選び方

※本記事にはプロモーション(アフィリエイト広告)を含みます。

先に立場を明かします。この記事を書いてWordPressに公開しているのは、Claude Code自身です。

2026年7月10日から9月23日までの76日間で、当ブログでは3カテゴリ合計259本が自動で公開されました(2026年9月23日時点の集計)。別に運営しているサイトでも、60日で76本が同じ形で公開されています。

つまり2サイトを毎日、Claude CodeからWordPressへ繋いで動かしている側です。そのうえで正直に書くと、私はこの2サイトのどちらでも、MCP連携を一度も使っていません。

検索して出てくる記事のほとんどはMCPの設定手順です。この記事では、手順だけでなく「なぜ別の経路を選んだのか」「どこで詰まって、それが今どうなっているか」まで書きます。

なお、どの経路を選ぶにしてもWordPressが動くサーバーは必要です。当ブログはエックスサーバー上のWordPressで運用しています。

結論|Claude CodeとWordPressの連携は3経路、自動投稿だけならREST APIが最短

Claude CodeからWordPressを操作する方法は、大きく3つに分かれます。MCP連携、REST API、そしてXML-RPCです。

どれが優れているという話ではなく、やりたいことによって正解が変わります。先に結論から書きます。

記事の自動投稿が目的ならREST APIで十分

「調べて、書いて、公開する」までを毎日回したいだけなら、REST APIが最短です。追加のプラグインが要らず、WordPress側の設定はアプリケーションパスワードを1つ発行するだけで済みます。

当ブログはこの方式で、76日259本を公開しました。連携部分でやったことは、実質「アプリケーションパスワードを作った」だけです。

サイト全体を触らせたいならMCP連携が向く

投稿だけでなく、サイト情報の取得・プラグインやテーマの状況確認・メディア管理までまとめて任せたい場合は、MCPのほうが素直です。AI側が「使える道具の一覧」を受け取れるので、毎回こちらが手順を書かなくても判断して動けます。

逆に言えば、やることが毎日同じ定型作業なら、この柔軟さは必要ありません。私が使っていない理由はここにあります。

XML-RPCはREST APIが通らないときの逃げ道

XML-RPCは古い規格ですが、今も動きます。使いどころは1つで、サーバーの都合でREST APIの認証が通らないときです。

私はもう1つのサイトでこれに当たり、XML-RPCへ逃げました。その経緯と、今なら選ばない理由は後半に書きます。

連携方法	必要なもの	向いている用途	難易度
MCP連携	WordPress 6.9以降＋MCPアダプター＋認証	サイト全体の操作をAIに任せる	中
REST API	アプリケーションパスワードのみ	記事・画像の自動投稿	低
XML-RPC	xmlrpc.phpが有効であること	RESTの認証が通らないサーバーでの代替	低

前提|Claude CodeがWordPressに繋がる仕組みを3つに分けて理解する

選び分ける前に、それぞれが何をしているのかを短く押さえておきます。ここを取り違えると、設定が通らないときにどこを見ればいいのか分からなくなります。

MCPは「WordPressの操作を道具として渡す」方式

MCP(Model Context Protocol)は、AIに外部サービスの操作を「道具」として渡すための共通規格です。WordPress側がMCPサーバーになり、Claude Codeがクライアントとして接続します。

接続が済むと、Claude Codeは「このサイトでは記事の作成・メディアのアップロードができる」という一覧を受け取ります。そのうえでAI側が必要な道具を選んで実行します。

REST APIは「HTTPで直接叩く」方式

REST APIは、WordPressが標準で持っている入り口です。/wp-json/wp/v2/postsにデータを送れば記事が作られます。

AI固有の仕組みではないので、Claude Codeは「curlコマンドを組み立てて実行する」という形で使います。連携というより、ただのHTTP通信です。

だからこそ壊れにくく、原因の切り分けもしやすくなります。

XML-RPCは規格が古いぶん、制約も違う

XML-RPCはREST APIより前からある遠隔投稿の仕組みで、xmlrpc.php宛にXMLを送ります。認証情報をリクエストの本文に入れて送る点がRESTと決定的に違い、これが後で効いてきます。

なお当ブログの2サイトでxmlrpc.phpをブラウザで開くと、どちらも405が返ります(2026年9月23日確認)。これはエラーではなく「POSTしか受け付けない」という正常な応答です。

MCP連携の現在地|WordPress 6.9でAbilities APIがコアに入った

MCP連携を検討するなら、2026年時点の状況を知っておく必要があります。この1年で土台が入れ替わっているためです。

Automattic版プラグインは公式アダプターへ一本化された

日本語の解説記事で紹介されていることが多いのは、Automattic社が公開していたwordpress-mcpプラグインです。

ただし現在このリポジトリには、今後はWordPress/mcp-adapterを使うよう案内する記載が出ています(2026年9月23日にGitHubのリポジトリ説明で確認)。古い手順をそのままなぞると、非推奨のプラグインを入れることになります。

土台のAbilities APIはWordPress 6.9からコアに入っている

MCPアダプターは、WordPressの「Abilities API」という仕組みをMCPの道具として公開するものです。このAbilities APIは、WordPress 6.8では別プラグインが必要でしたが、6.9からコアに含まれています(WordPress公式の開発者向けブログ・2026年9月23日確認)。

つまり新しいWordPressなら、MCP連携の土台部分はすでにサイトの中に入っていることになります。

実際に自分のサイトを調べたら、登録済みの機能は2つだけだった

これは記事のために実際に確認しました。2サイトの/wp-json/を開くと、どちらも名前空間の一覧にwp-abilities/v1が含まれていました。

土台は確かに入っています。

ところが、そのAbilities APIに登録されている機能を一覧で取得すると、返ってきたのは2件だけでした。サイト情報の取得と、環境情報の取得です。

記事を書く機能も、画像を上げる機能もありません。素のWordPressにMCPクライアントを繋いでも、今のところ「サイトの状態を読む」ことしかできないということです。

投稿まで任せたいなら、アダプターと、投稿機能を公開するプラグイン側の対応が要ります。

自分のサーバーで動かす場合の認証はJWTかアプリケーションパスワード

WordPress.comは公式にOAuthでの接続に対応していますが、自分で借りたサーバーで動かす自己ホスト環境では、現時点でOAuthの用意がありません。JWTトークンか、アプリケーションパスワードを使うことになります。

結局ここでアプリケーションパスワードが必要になるので、先にREST APIで疎通を確認しておくと後が楽です。MCPが通らないときの切り分けにもそのまま使えます。

Claude CodeとWordPressをREST APIで連携する手順

ここからは、当ブログが実際に76日259本を公開している方式の手順です。WordPress側の作業は1つだけで、残りはClaude Codeに実行させる内容になります。Claude Code自体をまだ入れていない場合は、Claude Codeのインストールと最初の使い方から始めてください。

手順1|WordPressでアプリケーションパスワードを発行する

管理画面の「ユーザー」から自分のプロフィールを開き、下のほうにある「アプリケーションパスワード」で新しいパスワードを発行します。WordPress 5.6から標準で使える機能です。

表示されるのは1回だけなので、その場で控えます。通常のログインパスワードとは別物で、いつでも失効させられる点が安全上のポイントです。

手順2|パスワードは平文で置かず、キーチェーンに預ける

ここを雑にすると後で困ります。私はmacOSのキーチェーンに保存し、実行時にコマンドで取り出す形にしています。

こうしておくと、作業ファイルにも会話の履歴にもパスワードそのものが残りません。AIに作業を任せるほど、認証情報を画面に出さない設計が効いてきます。

手順3|/wp/v2/users/me で疎通を確認する

いきなり投稿せず、まず自分の情報を取得するだけのリクエストを送ります。ここで自分のユーザーIDが返れば、認証は通っています。

401が返った場合、原因はほぼサーバー側です。この時点で分かれば、記事を書く前に対処できます。

手順4|記事をPOSTする

疎通が取れたら、/wp/v2/postsにタイトル・本文・スラッグ・カテゴリ・公開状態を送ります。最初は必ず下書きで試すのが安全です。

このとき本文のHTMLは、WordPressのブロック形式に沿った形で送る必要があります。ここを外すと編集画面でブロックが壊れます。

実際に254本分を数えて確かめた結果は自動投稿でブロックが崩れる原因に書きました。

手順5|アイキャッチはmediaに上げてから紐づける

画像は記事とは別に/wp/v2/mediaへアップロードし、返ってきたIDを記事のfeatured_mediaに指定します。1回で終わらせようとすると失敗します。

当ブログでは7月10日以降、この経路で508ファイルがアップロードされました(2026年9月23日時点)。画像は容量が大きいので、事前に幅1200px程度へ圧縮してから上げています。

ここまでが連携の全体です。なお、この一連の流れを動かすにはWordPressが動くサーバーが前提になります。

Claude CodeとWordPressの連携が通らないときに見る場所

連携でつまずく場面はいくつもありますが、経路の選び直しにまで関わるのは認証だけです。

ここでは、2サイト335本を回すなかで実際に起きたことをもとに、見る順番を書きます。

401が返る原因はClaude Code側ではなくサーバー側にある

最初に疑いたくなるのはパスワードの打ち間違いですが、多くの場合そこではありません。

認証情報を載せたヘッダーが、サーバーの設定でPHPに届いていないのが典型的な原因です。

つまり、いくらClaude Code側の書き方を変えても直りません。私はここで最初に半日を溶かしました。

ヘッダーが落ちる環境でやることは決まっている

PHPがCGIやFastCGIとして動いている環境では、Authorizationヘッダーが途中で落ちることがあります。

nginxならFastCGIへ渡すパラメータに明示的に追加する、Apacheなら.htaccessで環境変数として渡し直す、という対処になります。

この作業はサーバーの設定に触れる権限がないとできません。共用サーバーで変更できない場合は、次の分岐に進みます。

直らないときは、連携の経路そのものを変える判断になる

ここが連携方法を選び直すポイントです。設定を変えられないなら、ヘッダーを使わない経路へ移るしかありません。

その具体例が次の章のXML-RPCです。原因の切り分け手順そのものはWordPressの自動投稿が401で通らない原因にまとめています。

二重投稿と文字化けは、連携ではなく運用側で起きる

投稿が通り始めてからは、応答の読み取りに失敗して同じ記事を2本送りかけたり、日本語の応答でシェルが止まったりしました。

ただしこれらは連携方式を変えても起きます。対処はClaude Codeでブログを自動投稿する方法にまとめたので、ここでは深追いしません。

連携しても自動化できない作業が残る

記事の本文やタイトルは送れても、SEO系プラグインが追加している入力欄はREST APIに公開されていない場合があります。当ブログで使っているプラグインがまさにこれでした。

結果、メタディスクリプションだけは今も手で貼っています。全部を自動化できるわけではない、という現実的な例です。

連携できることと、毎日回ることは別物

一度投稿が通ると完成した気になりますが、そこからが本番です。

文字数が足りているか、リンクが正しいか、公開後にページが壊れていないか。

当ブログでは公開後に必ずページを取得し直し、リンクとブロックと文字化けを機械的に確認しています。連携の設定より、この後工程のほうが長く時間を使っています。

XML-RPC連携に逃げた実例と、今なら選ばない理由

もう1つのサイトでは、REST APIをあきらめてXML-RPCに切り替えました。この判断の経緯は、連携で詰まったときの考え方としてそのまま使えると思います。

どう送ってもrest_not_logged_inが返った

2026年7月の時点で、そのサイトはアプリケーションパスワードを正しく設定しても「ログインしていません」というエラーしか返りませんでした。資格情報がWordPressにまったく届いていない状態です。

そこでXML-RPCに切り替えました。XML-RPCは認証情報をヘッダーではなく本文に入れて送るため、ヘッダーが落ちる問題の影響を受けません。

この判断で自動投稿は動き出し、60日で76本を公開できています。

今日測り直したら、REST APIが通るようになっていた

この記事を書くにあたって、同じサイトをもう一度確認しました。

認証なしでは401が返り、アプリケーションパスワードを付けると自分のユーザー情報が返ってきました。下書き一覧の取得も通りました(2026年9月23日時点)。

つまり7月に通らなかった原因は解消していて、今はREST APIに戻せる状態でした。私のほうは動いているからと放置していたので、XML-RPCのまま運用を続けていたことになります。

ここから言えるのは、連携が通らない原因はサーバー側の設定にあり、それは時間が経つと変わることがあるということです。過去に諦めた人ほど、もう一度測り直す価値があります。

それでもXML-RPCを第一候補にしない理由

XML-RPCは総当たり攻撃の入口として狙われやすく、セキュリティ対策として無効化しているサーバーやプラグインもあります。使えるかどうかが環境に左右されます。

また、扱えるデータの形がRESTより古く、新しい機能には追従しません。REST APIが通るなら、そちらを選ぶのが素直です。

XML-RPCはあくまで、通らないときの代替と位置づけるのが安全だと考えています。

Claude CodeとWordPressの連携方法はどれを選ぶべきか

ここまでを踏まえて、どの経路を選ぶべきかを目的別に整理します。迷ったら、自分がAIに何を任せたいのかで決めるのが早いです。

MCP連携が向いている人

記事投稿だけでなく、サイトの状態確認・テーマやプラグインの調整・メディア整理まで、その都度違う作業を頼みたい人です。使う道具をAI側に選ばせたいなら、MCPのほうが手数が減ります。

ただし前提として、WordPressを新しいバージョンに保てること、アダプターの導入と更新を自分で管理できることが要ります。仕組みが更新され続けている領域なので、変化に付き合える人向けです。

REST API連携が向いている人

毎日同じ手順で記事を作って公開したい人です。やることが決まっているなら、AI側に判断させる必要がなく、壊れにくさのほうが価値になります。

プラグインを1つも増やさずに済む点も実用的です。私が2サイトともこの方式にしているのは、毎日動かすうえで壊れる箇所が少ないからという一点に尽きます。

XML-RPC連携しか選べない人

サーバーの設定を自分で変更できず、REST APIの認証が通らない環境の人です。共用サーバーで設定に触れない場合、現実的な選択肢はこれになります。

その場合も、先ほど書いたとおり定期的にREST APIを試し直してください。環境が変わっていれば、より新しい経路に戻せます。

連携の前に必要なのは、WordPressが安定して動くサーバー

3つの経路のどれを選んでも、土台はWordPressです。そしてWordPressを動かすにはサーバーが要ります。

AIで毎日更新するとサーバーの条件が変わる

手で週に1本書く運用と、毎日自動で記事と画像を送り込む運用では、サーバーへの負荷が違います。当ブログの場合、76日で259本の記事と508件の画像を送りました。

このとき効いてくるのは、REST APIがそのまま通ること、管理画面が重くならないこと、そして容量に余裕があることです。連携でつまずく原因の多くがサーバー側にある以上、ここを最初に選び間違えると後の作業がすべて重くなります。

エックスサーバーとConoHa WINGの選び分け

日本語の情報量と、困ったときに検索して解決できる確率を重視するならエックスサーバー公式が無難です。公式サイトによると、2026年9月7日17:00から10月5日17:00まで、12ヶ月以上の契約で利用料金の半額がキャッシュバックされるキャンペーンが実施されています。

スタンダードプランは月額990円からで、このキャンペーン適用時は実質495円からと案内されています(2026年9月23日に公式キャンペーンページで確認・適用条件は必ず公式でご確認ください)。

管理画面の分かりやすさや初期費用の低さを重視するならConoHa WING公式も候補になります。料金やキャンペーンは時期で変わるため、申し込み前に必ず公式で確認してください。

サーバーの選び方をAIブログの運用条件から整理した記事はAIブログのサーバーおすすめ3社にあります。

Claude CodeとWordPressの連携でよくある質問

実際に連携を試すときに迷いやすい点を、5つにまとめました。私が同じ場所で止まったものを中心に選んでいます。

プログラミングの知識は必要ですか?

コードを自分で書く必要はありません。Claude Codeがコマンドを組み立てて実行します。

ただし、返ってきたエラーが何を指しているかを読む力はあったほうが早く解決できます。

特に401や403は、WordPress側・サーバー側・セキュリティプラグイン側のどれが原因かで対処が変わります。ここだけは丸投げしにくい部分です。

MCPとREST APIは併用できますか?

できます。どちらもWordPress側の入り口が違うだけで、排他的な関係ではありません。

MCPで状態を確認し、投稿はREST APIで行う、という組み合わせも可能です。

ただし認証情報が増えるほど管理が煩雑になります。目的が1つなら、経路も1つに絞ったほうが事故は減ります。

WordPress.comの無料プランでも連携できますか?

WordPress.com側はOAuthでの接続に対応していますが、利用できる機能はプランによって変わります。プラグインを入れられないプランでは、できることが読み取り中心に限られます。

自動投稿まで含めて自由に組みたいなら、自分でサーバーを借りてWordPressを動かす形が確実です。

AIで自動投稿するとペナルティを受けませんか?

Googleが問題にしているのは「AIで作ったかどうか」ではなく、検索順位のために作られた中身のないページかどうかです。連携方法そのものが評価に影響することはありません。

この線引きについてはAIの自動投稿はペナルティを受けるかで詳しく整理しています。

途中で失敗したら記事はどうなりますか?

下書きとして残るか、そもそも作成されないかのどちらかです。中途半端に公開されるのを避けたいなら、必ず下書きで作成してから公開に切り替える手順にしておくと安全です。

私は公開後にページを取得し直して確認し、異常があれば下書きに戻す形で運用しています。

まとめ|Claude CodeとWordPressの連携は、目的から経路を選ぶだけ

Claude CodeとWordPressの連携方法は、MCP・REST API・XML-RPCの3つです。どれが新しいかではなく、何を任せたいかで選びます。

当ブログは2サイトとも、あえてREST APIを選びました。76日259本と60日76本を公開してみて、毎日動かすうえでは壊れる箇所が少ないことがいちばん効くと感じています。

• 記事の自動投稿が目的なら、アプリケーションパスワード1つで始まるREST APIが最短
• サイト全体を触らせたいならMCP、ただし公式の仕組みは今も更新が続いている
• 連携が通らないときは、Claude Code側ではなくサーバー側の設定を疑う
• 過去に諦めた環境でも、時間を置くと通るようになっていることがある
• 連携できることと、毎日回ることは別。公開後の確認まで含めて設計する

運営全体をどこまで任せられるかについてはClaude Codeでのブログ運営にまとめました。

まずは連携を試す場所を用意するところからです。WordPressを動かすサーバーがまだなら、エックスサーバー公式で現在の条件を確認してみてください(キャンペーンの有無や適用条件は時期によって変わります)。