CodexとWordPressをMCPでつなぐと何ができる？記事作成・AIとの共同編集・バックアップまで考えてみた（ChatGPT-5.6 Sol版）

2026年8月11日

本記事は、下記記事のChatGPT-5.6 Sol版であり、ChatGPT-5.6 Solに同様の質問をしてそれらの回答をまとめてもらったものです。

はじめに

AIを使ってブログ記事を書くこと自体は、いまでは珍しくありません。

私自身も、AIと何度も質疑応答を繰り返しながら内容を掘り下げ、その会話をまとめてWordPressの記事にすることがあります。

ただ、実際にやってみると、

AIとの質疑応答を記事としてまとめる
WordPressへコピーする
見出しや装飾を整える
図解を作る
画像をアップロードする
アイキャッチを設定する
公開後にバックアップする

といった作業が残ります。

そこで今回、

CodexとWordPressをMCPで直接接続したら、記事制作のかなりの部分を一続きの作業にできるのではないか

と考え、実際に接続を試してみました。

調べていくうちに、単なる「AIからWordPressへ投稿する仕組み」ではなく、

AIとの質疑応答 → 記事化 → 人間による修正 → AIへの追加質問 → 図解作成 → WordPressへの下書き保存 → 記事単位バックアップ

まで含めた、かなり面白いブログ制作環境を作れそうだと分かってきました。

この記事では、その構想と実際に試した内容をまとめます。

CodexとWordPressをMCPでつなぐとは

まず基本的な構成です。

CodexはMCPを使って、外部のサービスやツールを利用できます。

一方WordPressには、MCP Adapterという仕組みがあります。

これらを組み合わせることで、

Codex
   ↓
MCP
   ↓
WordPress MCP Adapter
   ↓
WordPressの機能

という経路ができます。

たとえば将来的にはCodexに、

「Home Assistantについて書いた記事を探して」

「この記事の本文を取得して」

「この原稿をWordPressへ下書きとして登録して」

と指示すると、WordPress管理画面を人間が操作しなくても処理できるようにできます。

Abilityとは何か

今回MCP Adapterについて調べていると、頻繁に出てきたのが Ability という言葉です。

最初は少し分かりにくかったのですが、簡単に言えば、

WordPressが外部へ提供する「1つひとつの操作機能」

と考えると分かりやすくなります。

例えば、

記事一覧を取得する
記事本文を取得する
記事を作成する
記事を更新する
画像を登録する

といった機能を、それぞれAbilityとして定義できます。

CodexはMCP Adapterを通して、利用可能なAbilityを調べ、必要なものを実行します。

AbilityとCapabilityは違う

WordPressには以前から「Capability」という仕組みがあります。

例えば、

edit_posts
publish_posts
delete_posts

などです。

こちらは、

このユーザーが何をしてよいか

という権限を表します。

一方Abilityは、

WordPressがどんな操作機能を提供するか

を表します。

したがって、

Ability
「記事を更新できます」
        ↓
Capability
「このユーザーは記事を編集してよい？」
        ↓
YESなら実行

という関係になります。

WordPress MCP Adapterを実際に導入してみた

今回はWordPressに MCP Adapter をインストールしました。

GitHubで配布されているZIPファイルをダウンロードし、

WordPress管理画面の、

プラグイン → 新規プラグインを追加 → プラグインのアップロード

からインストールします。

その後、「有効化」を実行しました。

ところが有効化しても、特に新しい設定画面は表示されません。

最初は「何か失敗したのでは？」と思いましたが、これは正常でした。

MCP Adapterは一般的なプラグインのように専用設定画面を追加するものではなく、有効化するとバックグラウンドでMCPサーバーを登録します。

また、今回導入したMCP Adapterでは、プラグイン一覧にも「自動更新を有効化する」という表示がありませんでした。

GitHub経由で導入しているプラグインなので、この点も通常のWordPress.org配布プラグインとは少し異なります。

Application Passwordを作る

次に必要になったのが、WordPressの Application Password です。

これは通常のWordPressログインパスワードとは別に、外部アプリケーションからWordPressへアクセスするための専用パスワードです。

Codex専用のApplication Passwordを作成しておけば、必要になったときにそのパスワードだけを無効化できます。

通常のログインパスワードをCodexへ渡す必要はありません。

Node.jsが古かったので更新

CodexとWordPressの間には、

@automattic/mcp-wordpress-remote

を使用します。

ところがMac miniで、

node -v

を実行すると、

v16.3.0

でした。

今回使う仕組みには新しいNode.jsが必要だったため、Node.jsを更新しました。

更新後は、

node v24.19.0
npm  11.17.0
npx  11.17.0

となり、準備が整いました。

こうした点は、実際に設定してみないとなかなか気付きません。

CodexデスクトップアプリからMCPを登録

最初は config.toml を直接編集する方法を考えていました。

しかしCodexデスクトップアプリにはMCPサーバーを追加する設定画面があり、今回はそこから設定しました。

設定内容は概ね次のようになります。

名前
wordpress

タイプ
STDIO

起動コマンド
npx

引数1
-y

引数2
@automattic/mcp-wordpress-remote@latest

さらに環境変数として、

WP_API_URL
https://自分のサイト/wp-json/mcp/mcp-adapter-default-server

WP_API_USERNAME
WordPressのユーザー名

WP_API_PASSWORD
Application Password

OAUTH_ENABLED
false

を設定します。

ここで一つ注意したのが、npx の引数です。

-y @automattic/mcp-wordpress-remote

を1つの引数として入力するのではなく、

-y

と

@automattic/mcp-wordpress-remote

を別々の引数として設定します。

ついにCodexからWordPressへ接続できた

設定後、Codexから、

「WordPress MCPへ接続して、利用可能なAbilityを確認してください」

と指示しました。

すると、WordPressへの接続に成功しました。

Codexが発見したAbilityは5件でした。

backwpup/list-jobs
backwpup/get-backup-history
backwpup/get-backup-logs
backwpup/run-job
backwpup/cancel-job

ここで少し意外だったのは、WordPressの記事を読むAbilityではなく、（プラグインである）BackWPupのバックアップ関連Abilityだけが見えたことです。

BackWPupのAbilityとは

今回WordPressには、以前からバックアッププラグイン BackWPup が入っています。

BackWPupが自身の機能をAbilityとしてMCPへ公開していたため、Codexが発見したわけです。

例えば、

backwpup/list-jobs

は、

BackWPupに登録されているバックアップジョブの一覧を取得する

Abilityです。

ここでいう「バックアップ」はCodexやMCPのバックアップではありません。

WordPressサイトの、

WordPressファイル
プラグイン
テーマ
アップロード画像
データベース

などのバックアップです。

その他、

get-backup-history
過去のバックアップ履歴

get-backup-logs
バックアップ実行ログ

run-job
バックアップ開始

cancel-job
バックアップ停止

といったAbilityがあります。

これはAbilityの仕組みを理解するうえで非常に分かりやすい実例でした。

記事を操作するAbilityは自分で追加できる

今回確認できたのはBackWPupのAbilityだけでした。

しかしAbilityは自作できます。

今回の用途なら、例えば、

roompine/list-posts
roompine/get-post
roompine/create-draft
roompine/update-draft
roompine/upload-media

といったAbilityを追加できます。

自作AbilityはMCP Adapter本体へ書き込むのではなく、

Roompine Abilities

のような専用WordPressプラグインとして作成するのがよさそうです。

MCP Adapterが更新されても、自作Abilityが消えないからです。

WordPress側では、

wp_register_ability()

を使ってAbilityを登録し、

Ability名
説明
入力
出力
実行処理
実行権限

などを定義します。

また、Codexから利用するAbilityについては、MCPへ公開する指定も必要になります。

最初は読み取り専用Abilityから始める

いきなりCodexから記事を書き換えられるようにするのは少し不安です。

そこで最初は、

roompine/list-posts
roompine/get-post

だけを作る予定です。

この2つならWordPressの内容を書き換えません。

例えば、

「Home Assistantについて書いた過去記事を探して」

「この記事の本文を取得して」

といった用途に使えます。

動作確認後、

roompine/create-draft
roompine/update-draft

を追加します。

さらに安定すれば、

roompine/upload-media
roompine/set-featured-image
roompine/set-categories
roompine/set-tags

へ広げられます。

WordPress 7.1を待つことにした

今回、WordPress 7.1でAbilities API周辺の改善が予定されていることも分かりました。

7.1を待たなければAbilityを作れないわけではありません。

現在の環境でも自作Abilityは可能です。

ただ今回は急いでいないため、

WordPress 7.1正式リリース後に、最新仕様を確認してから自作Abilityを作る

ことにしました。

まず読み取り専用Abilityを作り、問題がなければ書き込み系へ進める予定です。

WordPress 7.1の正式リリース予定日は2026年8月19日です。
WordPress公式のリリーススケジュールでも、General Releaseが8月19日とされています。(Make WordPress)
現在の予定では、
・8月12日：RC2
・8月18日：Dry Run / 24時間コードフリーズ
・8月19日：正式リリース
です。(Make WordPress)

今回の自作Ability作成は、予定どおり7.1正式版が出てから最新仕様を確認して進めるのがよいと思います。

本当にやりたいのは「記事投稿」だけではない

ここから今回の検討が面白くなってきました。

単にCodexからWordPressへ記事を送るだけなら、それほど複雑な仕組みは必要ありません。

しかし私がやりたいのは、

AIとの質疑応答そのものを記事制作の素材として活用すること

です。

普段は、あるテーマについてAIへ何度も質問します。

例えば、

MCPとは何ですか？

Abilityとは何ですか？

MCP Adapterはどう導入しますか？

この設定で合っていますか？

このエラーはなぜ発生しますか？

という具合です。

この会話には、最初から完成原稿を書くよりも、実際に疑問を持った順番や試行錯誤が含まれています。

それを記事制作に活かしたいと考えました。

複数の質疑応答からブログ記事を作る

理想的なのは、

「これまでのこのセッションの質疑応答をまとめてブログ記事にしてください」

と指示する方法です。

ただし、長い会話を一度に要約すると、途中の重要な内容が薄くなる可能性があります。

そこで、記事作成は次の順番にします。

質疑応答
   ↓
論点を網羅的に抽出
   ↓
重複を整理
   ↓
記事へ再構成
   ↓
元の論点一覧と完成記事を照合

先に「何を記事へ入れるのか」を一覧化するわけです。

これなら、文章を読みやすく整理しながら、重要な論点が抜ける可能性を減らせます。

ChatGPTの「プロジェクト」単位でもできる

対象は1つのチャットだけとは限りません。

例えば1つのテーマについて、

チャットA
基本調査

チャットB
実際の設定

チャットC
トラブル対応

チャットD
追加調査

PDF
参考資料

がある場合、これらを同じChatGPTプロジェクトにまとめておけば、

このプロジェクト内の関連する質疑応答と資料を使ってブログ記事を作成してください

という依頼もできます。

ただし、この場合も「いきなり本文を書く」のではなく、

プロジェクト内から論点を抽出
論点一覧を確認
記事化
論点一覧と記事を照合

という流れにした方がよさそうです。

記事作成ルールをSkillにする

この処理は毎回ほぼ同じです。

そこでCodex側に、

blog-draft-from-context

のようなSkillとして登録できます。

Skillには、

1. 対象となる質疑応答を読む
2. 論点を網羅的に抽出
3. 重複を整理
4. 読み物として再構成
5. 見出しを作成
6. 図解が必要な箇所を判定
7. 図解生成用の仕様を書く
8. 最後に論点一覧と記事を照合

といったルールを定義します。

これなら毎回長い指示を書かなくても、

「このプロジェクトをブログ記事にまとめて」

という程度の指示から、決められた手順で処理できます。

下書きは人間とAIで共同編集する

AIが作った下書きをそのままWordPressへ送るのではありません。

一度下書きを画面に表示し、人間が読みながら修正します。

その途中で新しい疑問を思いつくこともあります。

例えば本文中に、

【質問】GTFS Realtimeとは何ですか？

と書いておきます。

その後、

「記事中の【質問】を処理してください」

と指示すると、AIが前後の文章を読み、回答をその場所へ自然な本文として挿入します。

処理済みの【質問】は削除します。

【質問】以外のマーカーも使える

例えば次のように分けられます。

【質問】
基本的な疑問に回答

【調査】
最新情報を調べて追記

【補足】
説明を追加

【確認】
記述が正しいか検証

【図解】
この部分を図で説明

例えば、

【調査】
現在のCarPlay版Googleマップで利用できるAI機能を確認して追記

としておけば、AIに単なる文章生成ではなく「調査が必要」と伝えられます。

背景色付きの補足欄も簡単な記法にする

WordPressの記事では、補足や注意事項を背景色付きのボックスに入れたいことがあります。

しかし編集途中からWordPressの複雑なブロックHTMLを書くのは大変です。

そこで原稿では、

:::補足
ここは補足説明です。
:::

や、

:::注意
この操作をする前にバックアップしてください。
:::

と書くだけにします。

WordPressへ送る直前に、

:::補足

を背景色付きのWordPress標準ブロックへ変換します。

例えば、

補足 → 青系
注意 → 黄系
重要 → 赤系
ポイント → 緑系
メモ → グレー系

などです。

SWELL独自ブロックへ変換することもできますが、最初はWordPress標準ブロック＋CSSの方が、テーマ更新の影響を受けにくそうです。

図解は記事作成時には「説明文」だけ入れておく

記事を書いている途中で毎回図を作ると、文章を修正した際に作り直しが発生します。

そこで記事作成段階では画像そのものを作らず、

【図解3 挿入】

タイトル：
AbilityとMCP Adapterの関係

目的：
初心者に両者の違いを説明する

構成：
左にCodex
中央にMCP Adapter
右にWordPress

表示要素：
Codex
MCP
MCP Adapter
Ability
WordPress

画像仕様：
横長16:9
日本語
技術ブログ向け

のような画像生成仕様だけを書き込んでおきます。

本文が完成した段階で、記事中のすべての【図解】をまとめて処理します。

この部分は、

blog-diagram-generator

という別のSkillにすることができます。

SkillとAbilityは役割が違う

ここまで来ると、SkillとAbilityが混同しそうになります。

整理すると、

SkillはCodex側の作業手順

です。

例えば、

質疑応答を整理する
記事を書く
図解仕様を書く
質問マーカーを処理する

といった「どう仕事をするか」を定義します。

一方、

AbilityはWordPress側で実際に何をできるか

です。

例えば、

記事を取得する
下書きを作る
記事を更新する
画像を登録する

です。

最終的なブログ記事制作フロー

ここまでをつなぐと、最終的には次のようになります。

複数の質疑応答・調査・資料
        ↓
対象を指定
        ↓
論点抽出
        ↓
ブログ記事へ再構成
        ↓
図解仕様を挿入
        ↓
人間が下書きを読む
        ↓
【質問】【調査】【補足】を追記
        ↓
AIが処理
        ↓
人間が確認
        ↓
図解を一括生成
        ↓
装飾マーカーをWPブロックへ変換
        ↓
Codex
        ↓
MCP
        ↓
WordPress Ability
        ↓
WordPressへ下書き保存
        ↓
人間が最終確認
        ↓
公開

重要なのは、最後まで公開だけは人間が行うことです。

少なくとも仕組みが十分安定するまでは、Codexへ publish や delete のAbilityを与えない方が安心です。

公開した記事を1記事単位でバックアップしたい

ここでもう一つ考えました。

WordPressにはBackWPupなどのバックアッププラグインがあります。

しかし、サイト全体のバックアップは復元手順が少し難しく感じます。

そこで、

公開した記事を1本ずつ、人間が直接中身を確認できるZIPファイルとして保存したい

と考えました。

例えば記事IDが12345なら、

12345_記事タイトル.zip

として外付けSSDへ保存します。

タイトルだけでも構いませんが、記事IDを付けた方がWordPress上の記事と確実に対応できます。

ZIPには何を入れるか

おすすめは、

12345_記事タイトル.zip

├── post-content.html
├── rendered.html
├── metadata.json
├── README_restore.txt
│
└── images/
    ├── image01.jpg
    ├── image02.png
    └── featured-image.jpg

という構成です。

post-content.html

WordPressデータベースに保存されている元の本文です。

Gutenbergのブロック情報もできるだけ保持します。

rendered.html

実際にWebページとして表示された状態に近いHTMLです。

metadata.json

例えば、

記事ID
タイトル
スラッグ
公開日時
カテゴリー
タグ
アイキャッチ
元画像URL

などを保存します。

README_restore.txt

人間が復元するときの手順を書いておきます。

images

記事で使用している画像とアイキャッチ画像を保存します。

なぜMac mini側でZIPを作るのか

WordPressはXserver上にあります。

一方、外付けSSDはMac miniにつながっています。

そのためWordPressから直接MacのSSDへ書き込むことはできません。

そこで、

WordPress
   ↓
export-post Ability
   ↓
MCP
   ↓
Codex / Mac mini
   ↓
HTML・画像を取得
   ↓
ZIP化
   ↓
外付けSSD

という構成にします。

WordPress側には例えば、

roompine/export-post

というAbilityを作ります。

入力は記事IDです。

出力として、

記事ID
タイトル
スラッグ
post_content
rendered HTML
カテゴリー
タグ
アイキャッチ
記事中の画像URL

などを返します。

Mac側で画像をダウンロードし、ZIPへまとめます。

復元はあえて人間ができる形にする

今回考えているバックアップは、WordPressサイトを完全自動復元するためのものではありません。

目的は、

WordPressが壊れても、記事本文と画像だけは人間が簡単に取り出せるようにする

ことです。

復元する場合は、

ZIPを解凍
WordPressで新規記事を作成
post-content.html を開く
コードエディターへ貼り付け
imagesフォルダの画像をアップロード
必要に応じて画像URLを差し替える
metadata.jsonを見ながらカテゴリー、タグ、スラッグを設定
内容を確認して公開

という方法を想定しています。

手間はかかりますが、特定のバックアッププラグインの復元機能に依存しません。

サイト全体バックアップとは役割が違う

この仕組みはBackWPupなどを置き換えるものではありません。

役割が違います。

BackWPup

WordPressサイト全体を復旧するためのバックアップ

に対して、

記事単位ZIP

1記事を人間が読める状態で長期保存し、
必要なら手作業で再構築するためのバックアップ

です。

両方残しておけば安心です。

これからの実装順序

今回の検討で、最終形はかなり明確になりました。

ただし一度に全部作るつもりはありません。

まず、現在すでにできているのは、

Codex
↓
MCP
↓
WordPress MCP Adapter

の接続です。

BackWPupのAbilityをCodexから発見できたため、接続経路そのものは正常に動作しています。

次にWordPress 7.1正式版への更新後、最新仕様を確認して、

第1段階

roompine/list-posts
roompine/get-post

を作ります。

読み取り専用です。

第2段階

roompine/create-draft
roompine/update-draft

を追加します。

公開機能はまだ追加しません。

第3段階

roompine/upload-media
roompine/set-featured-image
roompine/set-categories
roompine/set-tags

を追加します。

第4段階

roompine/export-post

を追加し、記事単位ZIPバックアップを実現します。

一方、WordPressのバージョンアップを待たなくても作れるものがあります。

それがCodex側のSkillです。

blog-draft-from-context

と、

blog-diagram-generator

さらにバックアップ用の、

backup-wordpress-post

といったSkillを先に準備できます。

まとめ

今回の検討を始めたときは、

CodexとWordPressをMCPでつなぐと何ができるのか

という単純な疑問でした。

実際にMCP Adapterを導入し、Application Passwordを作り、Node.jsを更新し、Codexデスクトップアプリから設定したところ、CodexからWordPressへ正常に接続できました。

最初に見つかったのはBackWPupの5つのAbilityでした。

その結果、

WordPressのプラグインが自身の機能をAbilityとして公開し、CodexがそれをMCP経由で利用する

という仕組みを実際に確認できました。

そして、自作Abilityを追加すれば、

記事を探す
記事を読む
下書きを作る
下書きを更新する
画像を登録する
アイキャッチを設定する
記事をバックアップする

といったことも可能になります。

さらにCodex側のSkillを組み合わせれば、

AIとの複数の質疑応答を記事へまとめ、人間が下書きを読みながら【質問】や【調査】を書き込み、AIがその場所へ回答を追加し、最後に図解をまとめて作成してWordPressへ下書き保存する

というところまで発展させられそうです。

そして公開後には、記事IDを基準にHTML・画像・メタ情報をまとめたZIPファイルを外付けSSDへ保存する。

最終的には、

AIとの質疑応答
        ↓
記事作成
        ↓
人間とAIで共同編集
        ↓
図解一括生成
        ↓
WordPressへ下書き
        ↓
人間が確認して公開
        ↓
記事単位ZIPバックアップ

という一連のブログ制作環境を目指しています。

MCPは単に「AIからWordPressを操作するための接続方法」と考えていましたが、今回実際に試してみると、AIとWordPressの間に自分専用の制作ワークフローを作るための土台として使えることが分かりました。

まだ自作Abilityの実装はこれからです。

WordPress 7.1正式版への更新後、まず読み取り専用Abilityから少しずつ実装し、実際にどこまで実用的なブログ制作環境にできるのか試していきたいと思います。

前回はClaude Opus 5に同テーマを相談した記録をブログ記事として公開した。本記事は、同様の質問応答をChatGPT-5.6 Solに対して行い、セッション全体の内容を記事にまとめてもらったものである。

予想していた通り、ChatGPT-5.6 Solとの質疑応答を記事化した「下書き」の方が私のスタイルに合っていると感じた。ChatGPT-5.6 Solの回答は長いが、不要と思われる部分を削除する方向で修正することができ、記事全体の言い回しを修正したり、不足している言葉を補ったりする必要がなかった。

また、ChatGPT-5.6 Solとの質疑応答を進めていくと、MCPを実際に導入するように誘導され、MCPを使って5つのAbilityを確認するところまで実施できた。これは、各回答の最後に、次の1ステップは何をすべきかを明確に示してくれているからだと思われる。

それぞれのAIの提案内容の違いも見られ、セッション圧縮の影響を抑制するために、Opus 5はセッション内容をファイルに書き出して内容を固定化する方法を提案したのに対し、ChatGPT-5.6 Solは、論点を網羅的に抽出しておき、元の論点一覧と完成記事を照合するという方法を提案してきた。どちらの方法を採用するかも今後の課題である。

Opus 5は、記事の編集作業を、Claudeを拡張機能として導入したVS Codeで行うことを提案した。VS Codeで行う方が、より高機能な編集機能が使えるように思われるので、これらの点は導入を検討したい。

CodexとWordPressをMCPでつなぐと何ができる？ 記事作成・AIとの共同編集・バックアップまで考えてみた（ChatGPT-5.6 Sol版）

はじめに

CodexとWordPressをMCPでつなぐとは

Abilityとは何か

AbilityとCapabilityは違う

WordPress MCP Adapterを実際に導入してみた

Application Passwordを作る

Node.jsが古かったので更新

CodexデスクトップアプリからMCPを登録

ついにCodexからWordPressへ接続できた

BackWPupのAbilityとは

記事を操作するAbilityは自分で追加できる

最初は読み取り専用Abilityから始める

WordPress 7.1を待つことにした

本当にやりたいのは「記事投稿」だけではない

複数の質疑応答からブログ記事を作る

ChatGPTの「プロジェクト」単位でもできる

記事作成ルールをSkillにする

下書きは人間とAIで共同編集する

【質問】以外のマーカーも使える

背景色付きの補足欄も簡単な記法にする

図解は記事作成時には「説明文」だけ入れておく

SkillとAbilityは役割が違う

最終的なブログ記事制作フロー

公開した記事を1記事単位でバックアップしたい

ZIPには何を入れるか

post-content.html

rendered.html

metadata.json

README_restore.txt

images

なぜMac mini側でZIPを作るのか

復元はあえて人間ができる形にする

サイト全体バックアップとは役割が違う

これからの実装順序

第1段階

第2段階

第3段階

第4段階

まとめ

CodexとWordPressをMCPでつなぐと何ができる？記事作成・AIとの共同編集・バックアップまで考えてみた（ChatGPT-5.6 Sol版）