結論から書きます。
WordPress MCP（mcp-wordpress）で、ブログの立ち上げはおおむね自動化できます。
ただし「全部できる」は事実と違います。
パーマリンク、スラッグ、テーマ、プラグイン、メニューはMCPから触れません。

この記事は、筆者が実際にClaude Codeへブログを丸ごと立ち上げさせ、詰まった箇所を発生した順に記録したものです。
同じ構成を組む人が同じ場所で詰まらないよう、エラーの内容と回避策までそのまま書きます。

先に7つの答えだけ

パーマリンク構造は変えられない。管理画面必須で、記事公開前にやる
スラッグは指定できない。回避策あり（英語タイトルで公開作成→改題）
privacy-policyのスラッグは初期下書きが確保している。下書きを再利用する
カテゴリのスラッグも変えられない。クイック編集で手動
テーマ・プラグイン・メニューは操作できない。メニューはテーマ側で回避可
コメント設定とサイトアドレスは対象外
メディアのアップロードは認証エラーで失敗する

それぞれの実際の挙動を、検証環境から順に説明します。

検証環境（2026年8月6日時点）

WordPress 6.8 ／ Xserver スタンダードプラン
mcp-wordpress（npm。アプリケーションパスワード認証）
クライアント：Claude Code
作業範囲：初期設定、固定ページ3本の作成と公開、カテゴリ6件の設計、不要コンテンツ削除、記事の下書き入稿

接続設定は次の1行です。
値は自分の環境に置き換えてください。

claude mcp add wordpress \
  -e WORDPRESS_SITE_URL=https://example.com \
  -e WORDPRESS_USERNAME=ユーザー名 \
  -e WORDPRESS_APP_PASSWORD=アプリケーションパスワード \
  -- npx -y mcp-wordpress

アプリケーションパスワードは、WordPress管理画面のユーザー→プロフィール→「アプリケーションパスワード」で発行します。
表示は一度きりです。
通常のログインパスワードを渡す方式ではないので、万一漏れてもそのパスワード単体を失効させられます。

できたこと

投稿と固定ページの作成、更新、削除。下書きと公開の切り替えも含む
カテゴリとタグの作成、名前変更
サイトタイトルとキャッチフレーズの変更
サンプル投稿「Hello world!」とサンプルページの削除
メディアの一覧取得、コメント操作、ユーザー確認、キャッシュ操作

会話で指示するだけで、固定ページ3本の執筆から公開まで完了しました。
プライバシーポリシー、運営者情報、お問い合わせの3本です。
体感では、初期設定作業の7割はMCP経由で終わります。
問題は残りの3割です。

図1｜MCP経由で操作できる範囲（2026.08.06 検証）

初期設定の7割はできる。残り3割が管理画面行き

できた

投稿・固定ページの作成/更新/削除
カテゴリ・タグの作成/名前変更
サイトタイトル/キャッチフレーズ
サンプルコンテンツの削除
メディア一覧/コメント/ユーザー

できない（管理画面で操作）

パーマリンク構造の変更
スラッグの指定
テーマ/プラグインの操作
メニュー作成
コメント設定・サイトアドレス
メディアのアップロード

できないこと1：パーマリンク構造の変更

MCPのツール一覧に、パーマリンク設定に触れるものがありません。
原因はMCP側ではありません。
WordPressのREST APIそのものが、パーマリンク構造の変更を公開していないためです。
どのMCP実装を使っても同じ壁に当たります。

これが最初の落とし穴です。
WordPressの初期状態はパーマリンクが「基本」、つまり ?p=123 形式になっています。
SEO上は「投稿名」に変える必要があります。
ここだけは必ず管理画面で操作することになります。
設定→パーマリンク→「投稿名」を選択→変更を保存、の順です。

順番も重要です。
記事を公開した後に変えると全記事のURLが変わります。
共有済みのリンクも被リンクも無効になります。
必ず1本目の記事を書く前に済ませてください。

できないこと2：スラッグの指定

これが最大の罠でした。
投稿作成にも固定ページ作成にも、スラッグを指定するパラメータがありません。
スラッグはタイトルから自動生成されます。

日本語タイトルで「運営者情報」という固定ページを作ると、URLはこうなります。

https://chocho-g.com/%e9%81%8b%e5%96%b6%e8%80%85%e6%83%85%e5%a0%b1/

日本語がパーセントエンコードされた状態です。
ブラウザのアドレスバーでは日本語に見えます。
しかしコピーして共有するとこの文字列になります。
SNSで崩れやすく、被リンクの正規化でも不利です。

回避策を見つけるまでに3回失敗しました。
動いた手順だけ書きます。

図2｜スラッグが確定するタイミング

下書き経由はNG。公開状態で作ってから改題する

失敗ルート

日本語タイトルで下書き

公開

改題

/%e9%81%8b%e5%96%b6… 公開の瞬間に日本語から再生成される

成功ルート

英語タイトルで公開作成

/about/ で確定

タイトルだけ日本語へ

スラッグは確定後、タイトルを変えても維持される

手順は2つです。

英語タイトル（例：about）で、最初から「公開」状態でページを作成する。スラッグ /about/ がこの瞬間に確定する
作成直後に、タイトルだけ日本語（運営者情報）へ変更する。スラッグは /about/ のまま維持される

重要なのは「下書きで作ってはいけない」ことです。
下書きの間はスラッグが確定していません。
公開した瞬間に、その時点のタイトルから再生成されます。
筆者は「英語タイトルで下書き→日本語に改題→公開」の順で試しました。
結果、日本語スラッグに戻る現象を確認しています。

できないこと3：privacy-policyのスラッグは最初から埋まっている

スラッグ問題を回避して、プライバシーポリシーを英語タイトル「privacy-policy」で公開作成しました。
今度はスラッグが privacy-policy-2 になりました。

原因は、WordPressがインストール時に自動生成する「プライバシーポリシー」の下書きページです。
この下書きが privacy-policy を先に確保しています。
下書きなのに、です。
スラッグの予約はページの公開状態と無関係に効いていました。

正解は、新規作成をやめることです。
この初期下書き、多くの環境でページID 3 の中身を書き換えて公開します。
副産物として、設定→プライバシーで指定する「プライバシーポリシーページ」との紐付けもそのまま維持されます。

できないこと4：カテゴリのスラッグ変更

カテゴリ更新のツールが受け付けるのは名前だけです。
初期カテゴリ「未分類」を「AIツール」にリネームしても、スラッグは uncategorized のまま残ります。
名前とURLが食い違った状態です。

日本語名でカテゴリを新規作成した場合も同じです。
スラッグが日本語になり、カテゴリページのURLがパーセントエンコードされます。
筆者のサイトでは6カテゴリすべてが対象でした。

修正は管理画面で行います。
投稿→カテゴリー→各行の「クイック編集」→スラッグ欄を英数字に書き換えます。
1件あたり10秒程度です。
カテゴリページのURLも記事公開後に変えると変わってしまいます。
これも記事を書く前に済ませる作業です。

できないこと5：テーマ、プラグイン、メニューの操作

テーマの有効化、プラグインの追加や削除、ナビゲーションメニューの作成。
いずれもツールがありません。
テーマのzipアップロードと有効化、不要プラグインの削除は管理画面で行いました。

メニューだけは回避できました。
テーマのfunctions.phpにフォールバックを書く方法です。
「メニューが未設定のとき、指定した順でカテゴリと固定ページを出力する」という処理を入れます。

// メニュー未設定時に意図した順でナビを出す（考え方の骨子）
function my_fallback_nav() {
    $slugs = array( 'ai-tools', 'saas', 'server', 'nocode' );
    echo '<ul>';
    foreach ( $slugs as $slug ) {
        $term = get_category_by_slug( $slug );
        if ( $term ) {
            printf( '<li><a href="%s">%s</a></li>',
                esc_url( get_category_link( $term->term_id ) ),
                esc_html( $term->name ) );
        }
    }
    echo '</ul>';
}

テーマを自作またはカスタマイズできる場合に限ります。
ただし「管理画面でメニューを組む」作業そのものを消せます。
AIがテーマファイルを書けるなら、この方法のほうがメニュー画面の操作説明より確実でした。

できないこと6：ディスカッション設定とサイトアドレス

コメントの受付停止と、サイトアドレスのhttps化。
どちらもサイト設定ツールの対象外です。
変更できるのはタイトル、キャッチフレーズ、タイムゾーンなど一部だけでした。
管理画面の設定→ディスカッション、設定→一般で変更します。

補足すると、コメント欄はテーマ側で閉じる方法もあります。

add_filter( 'comments_open', '__return_false', 20 );
add_filter( 'pings_open', '__return_false', 20 );

設定とテーマのどちらで対応するかは運用方針次第です。
テーマ側で閉じておくと設定の戻し忘れが起きません。

できないこと7：メディアのアップロードが認証エラーになる

記事用の画像をアップロードしようとしたところ、「Authentication failed」が返りました。
投稿の作成や削除は同じ認証情報で通っています。
メディアアップロードだけ失敗します。

ファイル送信、つまりmultipartの処理が他のAPI呼び出しと別実装になっていることが原因とみられます。
認証自体は生きています。
そのため接続テストでは「成功」と表示されるのが厄介な点です。

回避策は2つあります。
1つは、画像だけ管理画面のメディアライブラリへ手動でアップロードする方法。
もう1つは、そもそも画像を使わずCSSで図版を作る方法です。

筆者は後者を選びました。
この記事の図1から図3は、すべてHTMLとCSSだけで作られています。
画像ファイルは1枚も使っていません。
利点は3つあります。
アップロード作業が不要になること。
図の中の文字が検索エンジンに読まれること。
スマホでは自動的に縦積みになり、ダークモードにも追従することです。

追加の注意：MCPのキャッシュは古い値を返す

サイトタイトルを変更した直後に設定を取得しました。
変更前の値が返ってきました。
mcp-wordpressは応答をキャッシュしています。

変更してから確認する流れで検証するときは、対策が要ります。
キャッシュ削除のツールを挟むか、WordPressが標準で公開しているREST APIを直接見るかです。

curl -s https://example.com/wp-json/wp/v2/pages?per_page=10

筆者は途中から後者に切り替えました。
キャッシュ経由の「変更を確認しました」は信用できません。
これはAIに作業させる場合に特に重要です。
AI自身が古いキャッシュを見て「完了しました」と報告してくる可能性があるからです。
検証は必ずキャッシュを迂回した経路で行うべきです。

運用してわかったコツ3つ

確認は公開RESTで行う。MCPの読み取り結果はキャッシュの可能性を常に疑う
スラッグは最初から英語で統一するルールにする。作成後の修正はどれも一手間かかる
削除が「存在しないか権限が無い」エラーで失敗したら、ゴミ箱経由をやめて完全削除を試す

3つ目は筆者の環境で実際に起きました。
サンプル投稿の削除がこのパターンです。
force オプションを付けたら一発で通りました。

まとめ：役割分担の実測値

今回の立ち上げで、人間が手を動かした作業は5つでした。

図3｜今回の立ち上げの役割分担（実測）

人間の作業は合計およそ15分

人間

15分

契約と支払い
アプリパスワード発行
パーマリンク/https/コメント
スラッグ修正/テーマ有効化
公開ボタン

残り全部

サイト初期設定、カテゴリ設計、不要コンテンツ削除
固定ページ3本の執筆と公開
テーマ制作、記事執筆、下書き入稿、表示検証

合計でおよそ15分です。
残りはすべてClaude Code側で完了しました。
固定ページ3本の執筆と公開、カテゴリ設計、初期コンテンツ削除、設定変更、記事下書きの入稿、表示検証です。

「AIに任せればブログが全自動で立ち上がる」は、2026年8月時点では誇張です。
ただし「人間の作業を15分まで圧縮できる」は実測値です。
そしてその15分の大半は、この記事に書いた7つの制約に由来します。
どこで詰まるかが事前にわかっていれば、迷う時間はゼロにできます。

FAQ

Q. WordPress MCPはどれを使えばいいですか。
A. 筆者が使ったのはnpmのmcp-wordpressです。
WordPress公式のMCPではなくコミュニティ実装のため、この記事の制約は実装によって差がある可能性があります。
ツール数は約60個で、投稿・ページ・カテゴリ・メディア・SEO系まで揃っています。

Q. スラッグ問題はプラグインで解決できませんか。
A. スラッグを自動でローマ字化するプラグインは存在します。
ただし今回は「MCPだけでどこまでできるか」の検証のため試していません。
未検証です。

Q. アプリケーションパスワードをAIに渡して安全ですか。
A. 通常のログインパスワードとは別に発行される専用パスワードで、単体で失効できます。
権限はそのユーザーと同じになります。
心配なら編集者権限のユーザーを別に作って渡す方法があります。
筆者は管理者権限で運用していますが、失効手順を確認したうえで使っています。

Q. REST APIを無効化しているサイトでは使えますか。
A. 使えません。
mcp-wordpressはREST API経由で動きます。
セキュリティプラグイン等でRESTを止めている場合は、許可リストへの追加が必要です。

Q. 記事の公開までAIに任せて大丈夫ですか。
A. 技術的には可能です。
ただし筆者は公開ボタンだけ人間が押す運用にしています。
検索エンジンが問題視するのは「人間の監修が無いAI量産」であって、AI執筆そのものではないためです。
公開前の最終確認が、その監修にあたります。

検証環境について

この検証はXserver、スタンダードプラン上のWordPressで行いました。
サーバー側で詰まった点は1つだけです。
旧サイトのキャッシュが残って新サイトが表示されない現象でした。
サーバーパネルの「サーバーキャッシュ設定」からの削除で解決しています。
サーバー選びとドメイン取得を含めた立ち上げ全体の手順は、別記事にまとめる予定です。

WordPress MCPでできないこと7つ。Claude Codeにブログを立ち上げさせて詰まった全記録