この記事の目次
Claude CodeでWordPress自動投稿は何ができて、何ができないのか？
Claude Codeを使えば記事の投稿・更新・カテゴリやタグの付与・アイキャッチ画像のアップロードまでは実現できるが、予約投稿の細かな挙動やプラグインとの組み合わせ次第で動作が変わる領域も残っており、着手前に「できること」と「要検証な領域」を分けて把握しておく必要がある。
できることの中心は、記事本文の生成からWordPress REST API経由での投稿・更新までを一連の流れとして扱える点にある。カテゴリやタグの付与、抜粋文の設定、アイキャッチ画像のアップロードも対象になる。一方で、予約投稿時刻の指定がどこまで正確に反映されるか、特定のページビルダー系プラグインと組み合わせた際に本文構造がどう扱われるかといった点は、環境によって挙動が変わりやすい。こうした未確認の領域は、記事の指示を鵜呑みにせず、まず自分のサイトで下書き投稿を1件試して挙動を確認しておきたい。
前提としてClaude Code自体の操作に不慣れな場合は、先に基本的な使い方を押さえておくと以降の工程を進めやすい。Claude Codeとは何かや基本操作の進め方を先に確認しておくとよい。
どの連携方式を選ぶべきか？MCP・REST API直接連携・プラグイン経由の判断軸
連携方式は「技術知識レベル」「カスタマイズ性」「保守のしやすさ」「セキュリティ管理のしやすさ」という4つの軸で比較すると選びやすい。技術に不慣れならプラグイン経由、自由度を重視するならREST API直接連携、その中間を狙うならMCP経由が目安になる。
3つの方式にはそれぞれ得意分野と負担のかかり方があり、どれか一つが万能というわけではない。判断軸を先に固定してから比較すると、自分の状況に合う方式が見えてくる。
| 判断軸 | MCP経由連携 | REST API直接連携 | プラグイン経由連携 |
|---|---|---|---|
| 技術知識レベル | 中程度。MCPサーバーの設定を理解する必要がある | 高い。認証方式やエンドポイント設計を自分で組む | 低い。プラグインの管理画面に沿って設定できる |
| カスタマイズ性 | 高い。Claude Codeとの会話の流れに投稿処理を組み込める | 最も高い。任意の処理を自由に実装できる | プラグインが用意した機能範囲に限られる |
| 保守のしやすさ | Claude Code本体やMCPサーバーの更新に追従する必要がある | 自作コードのため、長期的な保守は自分の責任範囲になる | プラグイン開発元の更新頻度に運用が左右される |
| セキュリティ管理のしやすさ | Application Passwordなど個別の認証情報を自分で管理する | 認証情報や通信経路を自分で設計する分、責任範囲が広い | プラグイン側の実装に依存するため、事前の仕様確認が欠かせない |
MCPの仕組みそのものをもう少し詳しく知りたい場合は、MCPの基本ガイドにまとめてある。ここではWordPress自動投稿という用途に絞って、方式選定の判断材料を示すことを目的にしている。
セットアップの全体像とつまずきやすいポイントは？
Application Passwordの発行と接続設定さえ確実に済ませておけば、疎通確認まで大きくつまずくことは少ない。ただし細部の設定ミスは起こりやすく、セットアップ全体でどこに注意すべきかを把握しておくと進めやすい。
詳細な手順そのものは各方式の公式ドキュメントに譲り、ここではWordPress自動投稿の文脈で特につまずきやすい3点を整理する。
Application Passwordの発行と管理（有効期限・権限範囲の考え方）
WordPress管理画面の「ユーザー」>「プロフィール」から発行できるApplication Passwordは、投稿専用のアカウントに対して発行し、管理者権限そのものは付与しない運用が安全側に振れる。用途が終わった認証情報は都度失効させ、常時有効なパスワードを放置しないよう運用したい。
MCP/REST API接続の疎通確認でつまずきやすい箇所
接続がうまくいかない場合、まずはブラウザで自サイトのhttps://example.com/wp-json/にアクセスし、REST APIそのものが有効になっているかを確認する切り分け方が手早い。認証ヘッダーの形式違いやエンドポイントURLの記述ミス、HTTPS証明書の設定不備が原因になっているケースが多く、この段階でエラーが出る場合はセキュリティプラグインによる制限も疑う必要がある(詳しくは次の見出しで扱う)。
Claude Code自体のインストール・基本操作でつまずいたら
WordPress連携以前の、インストールや基本コマンドの段階でつまずく場合は、インストール手順ガイドや非エンジニアがつまずきやすい点のまとめを先に確認しておくと、原因がWordPress側にあるのかClaude Code側にあるのかを切り分けやすい。
セキュリティ・プラグイン/テーマ由来の制限で確認すべき論点は？
自動投稿がうまく動かないとき、原因は大きく三つのカテゴリに分けて考えられる。「セキュリティ系プラグインによる認証干渉」「SEO系プラグインとの機能面での干渉」「テーマ由来の制限」であり、どこに原因があるかを切り分けて確認する必要がある。
セキュリティ系プラグインがREST API認証をブロックするケース
SiteGuard WP Pluginなどのセキュリティ系プラグインは、REST APIへのアクセス自体を制限する設定を持つ場合がある。これは仕様として組み込まれている機能なので、まずは該当プラグインの設定画面や公式ドキュメントでREST APIの許可設定を確認するところから始めたい。制限を一時的に解除して疎通を確認し、問題が解消すればプラグイン側の設定が原因だったと判断できる。
SEO系プラグインとの干渉可能性について
AIOSEOのようなSEO系プラグインは、投稿時にメタデータを自動生成・上書きする機能を持つ場合がある。これは自動投稿の内容と競合する可能性がある論点だが、実際にどう干渉するかはプラグインのバージョンやサイトの設定に左右されるため、ここでは仮説として提示するにとどめる。導入前に自サイトの環境で1件テスト投稿を行い、意図しないメタデータの上書きが起きていないかを確認しておくと安心できる。
テーマ(Cocoon等)のfunctions.phpによる制限
セキュリティ系プラグインやSEO系プラグインとは別に、使用しているテーマのfunctions.phpでREST APIの一部機能が制限されている場合もある。Cocoonのような高機能テーマではカスタマイズの過程でこうした制限が追加されていることがあるため、プラグインを疑って解決しない場合はテーマ側のfunctions.phpも確認対象に含めるとよい。
認証情報の管理と権限最小化の考え方
複数人や複数サイトで運用に関わる場合は、担当者ごと・サイトごとに認証情報を分けて発行し、誰がどの権限を持っているかを一覧で把握できる状態にしておきたい。担当者が異動・退職した際に認証情報を放置すると、意図しないアクセスが残るリスクにつながるため、権限の棚卸しと失効のタイミングをあわせて決めておく必要がある。法人サイトで複数人が運用に関わる場合は特に、この管理体制の有無が事故防止を左右する。運用ルール全般についてはClaude Codeの運用ルールガイドも参考になる。企業でのセキュリティ体制をより広く検討したい場合はエンタープライズ向けセキュリティガイドも参照するとよい。
自動投稿は無レビューで回して良いのか？リスクと品質担保の設計
公開前の内容確認をまったく挟まない運用には、事実誤りや不適切な表現の混入といったリスクが伴う。コンテンツの性質に応じてレビューを挟むかどうかを分けて設計するのが現実的だ。
無レビュー運用で起こりうる具体的リスク
生成AIが作成した文章には、事実関係の誤りや、意図しない断定表現が含まれる可能性がある。自動投稿によってこうした内容がそのまま公開されると、読者の誤解を招いたり、サイトの信頼性を損ねたりする結果につながりかねない。特に商品説明や医療・法律に関わる内容など、誤りの影響が大きい分野では注意したい。
レビュー工程を挟むべきケース／自動公開してよいケースの分岐基準
社外に向けた告知や商用性の高い記事は、公開前に人による確認を挟む前提で設計しておきたい。一方、社内向けのメモや下書きの蓄積目的であれば、レビューを省いて自動公開する運用でも実害は小さい。この線引きを事前に決めておくことで、都度判断する手間を減らせる。
ファクトチェック・品質管理のルールをCLAUDE.md等に明文化する方法
チェックすべき項目(事実確認の要否、避けるべき表現、公開前の確認者など)は、口頭やその場の判断に任せずCLAUDE.mdのようなプロジェクト設定ファイルに明文化しておくと、運用が属人化しにくい。書き方の具体例はCLAUDE.md作成ガイドにまとめてある。
障害・誤投稿からどう復旧するか？バックアップとロールバックの考え方
誤投稿や意図しない上書きが起きても、WordPressの投稿リビジョン機能とサイト全体のバックアップを組み合わせておけば、多くの場合は元の状態に戻せる。復旧の仕組みは事前に用意しておくものであり、事故が起きてから探すものではない。
WordPressには投稿ごとにリビジョンを自動保存する機能があり、管理画面の「リビジョンを表示」から過去のバージョンに戻せる。ただし保存されるリビジョンの数には上限があるため、頻繁に自動投稿・更新を行う運用では、別途データベースのバックアップも用意しておくほうが安全だ。加えて、本番環境にいきなり反映するのではなく、ステージング環境で自動投稿の挙動を先に確認してから本番に適用する進め方も、事故を未然に防ぐうえで有効な手段だ。こうした「本番から切り離した環境で先に試す」という考え方は、Dockerで隔離実行する設計の発想とも通じる部分がある。
自動投稿を始める前に、以下のチェックリストで復旧手段が用意できているかを確認しておくとよい。
- サイト全体のバックアップ(データベース＋ファイル)を定期的に取得する仕組みがある
- 投稿のリビジョン保存数が運用頻度に対して十分か確認した
- ステージング環境など、本番以外で挙動を検証できる場所がある
- 誤って削除した投稿をゴミ箱から復元できる期間を確認した
- 復旧手順(誰が、どの操作で、どこまで戻すか)を事前に文書化した
継続運用のコスト(トークン消費・料金)はどれくらい見ておくべきか?
自動投稿にかかるコストを記事1本あたりの固定額として断定することはできない。生成する文章量・アイキャッチ画像の処理有無・修正のためのやり取り回数によってトークン消費が変動する点を理解しておきたい。
具体的な料金プランや金額の詳細は変動するため、この記事では断定しない。要因として押さえておくべきは、生成する文章の長さと頻度、画像の生成や最適化処理を伴うかどうか、そして品質確認のために生成をやり直す回数の3点だ。特に品質担保のために何度もやり取りを重ねる運用では、その分トークン消費が増える点を見込んでおくとよい。プランごとの料金体系や選び方については料金プランの比較ガイドで詳しく扱っている。
複数サイト運用や、より高度な自動化に発展させるには?
1サイトでの自動投稿が安定してきたら、複数のWordPressサイトを横断管理する設計や、週次での記事生成・SNS連携といった発展形に進む余地がある。ただしこれらは運用の複雑さも増すため、まずは1サイトでの基本運用を固めてから段階的に広げる方が無理がない。
複数サイトを並行して運用する企業では、サイトごとに認証情報やレビュー基準を分けて管理する設計が欠かせない。また、定型的な作業を複数のサブエージェントに分担させる考え方や、特定のタイミングで処理を自動実行する仕組みを組み合わせると、より高度な自動化につながりやすい。それぞれの詳細はサブエージェント活用ガイドとフック機能のガイドで扱っているので、興味があれば参照してほしい。
まとめ
Claude CodeでWordPress自動投稿を実現する道筋は、連携方式(MCP・REST API直接・プラグイン経由)を自分の技術レベルに照らして選び、セキュリティとプラグイン・テーマ由来の制限を切り分けて確認し、品質担保のルールとバックアップ体制を先に整えておくという流れでまとめられる。コストについても、記事1本あたりの固定額ではなく、生成量や修正回数に応じて変動する要因として見積もっておくと現実的な計画が立てられる。
ここまでの内容は自分で検証を進められる範囲だが、実際に手を動かすと、想定していなかった認証エラーやプラグイン同士の予期しない競合、品質管理ルールの細部設計など、記事だけでは解決しづらい壁に当たることもある。そうした個別の壁で時間を溶かしそうになったときは、独学を続ける前に伴走支援を検討する選択肢もある。