🔌 WordPressがMCPに対応したって？

WordPress.comが公式に MCP（Model Context Protocol）の サポートを開始しました。 Claude Codeから直接投稿を作成したり、 カテゴリを管理したり、 サイト設定まで操作できるということです。 私たちのblog-agentは REST API + Bearerトークン + Playwrightの 組み合わせでWordPressを扱ってきましたが、 WordPress MCP連携に切り替えたら どうなるか試してみました。

結論から言うと、v0.8.0で適用完了です。 ただし、すべてをMCPに置き換えることは できなかったため、 ハイブリッドアーキテクチャになりました。 そのプロセスを整理していきます。

😤 従来方式の問題点

blog-agent v0.7.xまでの WordPress連携構造はこのような形でした。

# 従来のフロー（v0.7.x）
1. ConfluenceからBearerトークンを読み取り
2. URLデコード（トークンがエンコード済み）
3. REST APIでメディアアップロード
4. REST APIで投稿作成
5. PlaywrightでPolylang言語連結
6. PlaywrightでGutenbergエディタ操作

いくつか問題がありました。

• トークンの有効期限切れ — Bearerトークンは定期的に期限切れになります。 403が出たらConfluenceで更新する 必要がありました。
• URLデコード地獄 — Confluenceに保存されたトークンが HTMLエンティティでエンコードされていたため、 デコードロジックが必要でした。
• Playwrightの不安定さ — Polylangの言語連結はREST APIでは できないため、ブラウザ自動化に 依存していましたが、 UIが変わるとすぐに壊れました。

🔍 WordPress MCPの発見と調査

WordPress Developer Blogで Abilities APIとMCP adapterの ニュースを知りました。 2つのバージョンがあります。

wpcom-mcp vs mcp-adapter

項目	wpcom-mcp	WordPress/mcp-adapter
対象	WordPress.com	セルフホスティングWordPress
転送方式	Streamable HTTP	stdio
インストール	不要（ホスティング提供）	サーバーに直接インストール
認証	OAuth 2.1（自動）	Application Password
ツール数	30+	プラグイン依存

ai-girls.orgはWordPress.comホスティングなので、 wpcom-mcpを選択しました。 核心的な違いは転送方式です。

stdio vs Streamable HTTP

これまで使ってきたMCPサーバー （nanobanana、terry-xai、mcp-atlassianなど）は すべてstdio方式です。 ローカルでプロセスを起動し、 stdin/stdoutで通信する構造です。

WordPress MCPは異なります。 type: "http"で宣言し、 WordPress.comがホスティングする エンドポイントにHTTPリクエストを送ります。 最大のメリットは サーバーのインストールが不要な点です。

⚙️ 設定と実装

.mcp.json設定

既存の.mcp.jsonに わずか4行追加しただけです。

{
  "mcpServers": {
    "wpcom-mcp": {
      "type": "http",
      "url": "https://public-api.wordpress.com/wpcom/v2/mcp/v1"
    }
  }
}

config.yamlの変更

# config.yaml (v0.8.0)
wordpress:
  site_url: "https://ai-girls.org"
  site_id: 252529337
  mcp_enabled: true
  mcp_site: "ai-girls.org"
  # Bearerトークン — RESTフォールバック用に維持
  token_confluence_page_id: "108790117"

mcp_enabled: trueがポイントです。 このフラグでMCP-first / REST-fallback 戦略をランタイムで切り替えられます。

MCP-first / REST-fallback戦略

publisher.mdをリファクタリングして、 以下の優先順位を定義しました。

# Publisher戦略 (v0.8.0)

## 投稿の作成/更新
第1: wpcom-mcp-content-authoring
第2: REST API（Bearerトークン）

## メディアアップロード
常時: REST API（MCP非対応）

## Polylang言語連結
常時: REST + Playwright（MCP非対応）

MCPツール呼び出しの例

実際の投稿作成時のMCP呼び出しは このようになります。

wpcom-mcp-content-authoring:
  action: execute
  wpcom_site: ai-girls.org
  operation: posts.create
  params:
    title: "投稿タイトル"
    content: "<HTMLコンテンツ>"
    slug: "post-slug-ko"
    categories: [3111150]
    featured_media: 12345
    status: draft
    meta:
      rank_math_title: "SEOタイトル"
      rank_math_description: "説明"
      rank_math_focus_keyword: "KW"
    user_confirmed:
      "Pipeline auto-approved"

wordpress_tools.pyの変更

MCP呼び出しパラメータを構築する ヘルパー関数を追加しました。

# wordpress_tools.py (v0.8.0)

def mcp_create_post(
    title: str,
    content: str,
    slug: str,
    categories: list[int],
    featured_media: int | None = None,
    status: str = "draft",
    meta: dict | None = None,
) -> dict[str, Any]:
    """
    posts.create用のMCPツール呼び出し
    パラメータを構築します。
    """
    params: dict[str, Any] = {
        "title": title,
        "content": content,
        "slug": slug,
        "categories": categories,
        "status": status,
    }
    if featured_media:
        params["featured_media"] = (
            featured_media
        )
    if meta:
        params["meta"] = meta
    return params

この関数がAPIを直接呼び出すわけではありません。 Claude CodeがMCPツールを呼び出す際に 必要なパラメータ辞書を構築する役割です。 実際の通信はClaude Codeの MCPランタイムが処理します。

🚧 制限事項 — ハイブリッドになった理由

すべてをMCPに切り替えたかったのですが、 2つの点が対応していませんでした。

1. メディアアップロード非対応

WordPress MCPはメディアの メタデータ編集には対応していますが、 ファイルのアップロードには 対応していません。 画像をアップロードするには、 引き続きREST APIが必要です。

# メディアアップロード — REST API継続
python tools_runner.py \
  wp_upload_media \
  --image-path "featured_image.jpg" \
  --token "$TOKEN"

MCPのStreamable HTTPトランスポートは バイナリファイル転送に最適化されていません。 将来的にサポートされる可能性はありますが、 現時点ではRESTが唯一の方法です。

2. Polylang多言語非対応

ai-girls.orgはPolylangで 韓国語・英語・日本語の3言語を運営しています。 Polylangはサードパーティプラグインのため、 WordPress MCPのツール範囲に 含まれていません。

言語連結作業は引き続き REST API + Playwrightの組み合わせで 処理しています。 PolylangがMCPを独自に提供するか、 WordPress MCPがプラグイン拡張に対応するまで 変わらないでしょう。

✅ 適用結果

OAuth 2.1の威力

最も体感の大きい変化は認証です。 従来のREST APIフローと比較してみます。

項目	REST API（従来）	MCP（v0.8.0）
認証	Bearerトークン手動管理	OAuth 2.1自動
トークン期限切れ	定期的な403エラー	自動更新
設定の複雑さ	Confluenceトークン + URLデコード	.mcp.json 4行
投稿作成	curl + JSONシリアライゼーション	MCPツール呼び出し
エラー処理	HTTPステータスコード解析	MCPランタイムに委任

Confluenceからトークンを読み取り、 URLデコードし、 403が出たら更新するルーチンが まるごと消えました。 .mcp.jsonにURLを1つ追加するだけです。

30以上のMCPツール

WordPress MCPが提供するツールを カテゴリ別に整理するとこうなります。

• Content Authoring — posts、pages、media（メタデータのみ）、 comments、categories、tags、patterns
• Site Editor Context — theme、blocks
• Site Management — settings、statistics、plugins、users
• User Account — profile、achievements、notifications
• Domain Purchase — ドメイン検索と購入

blog-agentが実際に使用しているのは Content Authoringのposts関連ツールが ほとんどです。 しかし、statisticsツールで トラフィック分析を自動化したり、 pluginsツールでプラグインの状態を モニタリングすることも可能です。

📐 Before / After比較

投稿作成コードの比較

# Before（REST API）
token = read_confluence_token()
token = urllib.parse.unquote(token)
resp = curl_json(
    "POST",
    f"{API_BASE}/posts",
    token,
    data={
        "title": title,
        "content": html,
        "status": "draft",
    },
)
post_id = resp["id"]

# After（MCP）
# トークン管理不要、OAuth自動処理
params = mcp_create_post(
    title=title,
    content=html,
    slug=slug,
    categories=[3111150],
    status="draft",
    meta={
        "rank_math_title": seo_title,
        "rank_math_description": desc,
    },
)
# Claude Code MCPランタイムが実行

トークン関連のコードが 完全に消えているのがわかりますか。 read_confluence_token()も、 urllib.parse.unquote()もありません。

🔮 今後の展望

WordPress 7.0とAbilities API

2026年4月9日リリース予定の WordPress 7.0は Abilities APIをコアに統合する予定です。 セルフホスティングのWordPressでも プラグインなしでMCP adapterを 使えるようになります。

現在のセルフホスティング用 WordPress/mcp-adapterは 別途インストールが必要ですが、 7.0以降はコア機能になります。

MCPエコシステムの現状

WordPress MCPを適用して感じたことがあります。 MCPエコシステムはまだ 「すべてが動く」段階ではありません。 メディアアップロードのように 欠けている機能があり、 サードパーティプラグイン（Polylangなど）は まだサポート外です。

しかし、MCP-first戦略は 正しい方向性です。理由は3つあります。

1. 認証の簡素化 — OAuth 2.1の自動処理により、 トークン管理が不要になります。
2. ツールの拡張性 — 30以上のツールがすでに存在し、 今後も増え続けています。
3. 標準化 — MCPはAnthropicが主導する オープンプロトコルです。 WordPressだけでなく、 Slack、GitHub、Jiraなど 多くのサービスがMCPを採用しています。

対応していない部分だけRESTで残し、 対応している部分からMCPに切り替える。 これが現時点で最も現実的な戦略です。

💡 学んだこと

学び	内容
MCP != 万能	メディアアップロードやサードパーティ プラグインにはまだRESTが必要
HTTPトランスポートが鍵	stdioと違いサーバーインストール不要、 4行の設定で完了
OAuth 2.1 = ゲームチェンジャー	トークン管理ルーチンがまるごと削除
user_confirmed必須	自動化パイプラインで忘れると 書き込み操作が失敗する
ハイブリッドが現実的	MCP-first + REST-fallbackが 現時点で最善のアーキテクチャ

この記事もblog-agent v0.8.0が MCP-first戦略で公開した最初の投稿です。 WordPress MCP連携に興味があれば、 まず.mcp.jsonに4行追加するところから 始めてみてください。それだけで十分です。

📚 References

• WordPress Developer Blog — From Abilities to AI Agents: Introducing the WordPress MCP Adapter
• WordPress.com MCP Support — MCP Settings
• WordPress.com Developer Docs — MCP
• WordPress/mcp-adapter — GitHub
• WooCommerce MCP Documentation