今回は、新しいChatGPTデスクトップアプリ内のCodex(旧称:Codexアプリ)とWordPressを、Model Context Protocol(MCP)で接続しました。サイト情報の確認や下書きの作成・更新を、デスクトップ画面から依頼できます。OpenAIのApplication Programming Interface(API)キーは使わず、ChatGPTの対象プランに含まれるCodex利用枠を使っています。
この記事では、全体の構成、独自プラグインの役割、ブロックエディターへの対応、安全のために設けた制限をまとめます。
今回作ったもの
CodexからWordPressに対して、次の操作を行えるようにしました。
- サイトの基本情報を読み取る
- 新しい記事を「下書き」として作る
- 既存の下書きを更新する
- 見出し、段落、表、コードなどをWordPressのブロックとして保存する
一方で、公開済み記事の書き換えや、記事の公開・削除は、この連携機能からは実行できません。便利な操作だけを選んで許可する設計です。
この構成のメリット
ChatGPTのサブスクリプション内で利用できる
ChatGPTアカウントでサインインすると、対象プランに含まれるCodexの利用枠を使えます。この構成ではOpenAI APIキーを用意しないため、通常のAPI従量課金を別に発生させずにWordPress連携を利用できます。
ただし、無制限という意味ではありません。利用できる量は、契約しているChatGPTプランの上限やクレジットの条件に従います。APIキーでサインインした場合はサブスクリプション利用ではなく、APIの標準料金が適用されます。
デスクトップアプリのGUIから操作できる
GUIはGraphical User Interfaceの略称で、ボタン、メニュー、チャット画面などを見ながら操作する方式です。ターミナルへコマンドを入力し続けなくても、ChatGPTデスクトップアプリで「この記事を下書きにして」のように依頼し、結果や変更内容を同じ画面で確認できます。
現在の正式名称は「ChatGPTデスクトップアプリ」です。以前の「Codexアプリ」はこの新しいアプリへ統合され、現在は画面左上からCodexを選んで利用します。この記事では、過去の情報を探す人にも分かるように「ChatGPTデスクトップアプリ内のCodex(旧称:Codexアプリ)」と表記します。
アプリ名称の変更については、OpenAIの案内で確認できます。Codexの利用枠については、Codexのプラン案内を参照してください。
全体の構成
Codexから下書き保存まで
1.人がCodexへ依頼
「この記事の下書きを更新して」のように、日本語で作業内容を伝える
↓
Codexが使うMCP機能を選ぶ
2.ChatGPTデスクトップアプリ内のCodex
GUI上のチャットで文章を作り、WordPressへ送る内容と操作を組み立てる
↓
MCPの接続ツールがHTTPS通信を橋渡しする
3.公式MCP Adapter
WordPressの機能を、MCPから呼び出せる共通形式で受け付ける
↓
登録済みのAbilityを呼び出す
4.DotMargin MCP Abilities
権限、記事の種類、下書き状態、許可されたブロックを確認する
↓
すべての条件を満たした処理だけを実行する
5.WordPress
サイト情報を返す、または記事を下書きのまま保存する
| 役割 | 使っているもの | 何をするか |
|---|---|---|
| 操作の依頼 | ChatGPTデスクトップアプリ内のCodex | 人が画面上のチャットから日本語で作業内容を伝える |
| 通信の橋渡し | MCPの接続ツール | CodexとWordPressの間で要求と結果を受け渡す |
| 機能の公開 | 公式MCP Adapter | WordPressの機能をMCPから利用できる形にする |
| 操作の制限 | DotMargin MCP Abilities | 許可する操作と、実行前のチェックを定義する |
| 保存 | WordPress | 確認済みの内容を下書きとして保存する |
MCPはModel Context Protocolの略称で、AIアプリと外部サービスをつなぐための共通ルールです。AIがWordPressの内部を自由に操作するのではなく、WordPress側が用意した機能を、決められた形式で呼び出します。
人のアカウント権限と、MCPから実行できる操作は別に管理できます。管理者アカウントで接続していても、独自プラグインが公開していない操作はMCPから実行できません。
独自プラグインを入れた理由
公式MCP Adapterは、WordPressとMCPをつなぐ土台です。ただし、「このサイトでは何を許可するか」は、サイトごとに決める必要があります。そのため、DotMargin専用の小さなプラグインを追加しました。
| 機能名 | できること | 主な制限 |
|---|---|---|
| get-site-summary | サイト名やWordPressの世代などを確認する | 読み取り専用 |
| create-draft-post | 新しい記事を作成する | 必ず下書きで保存 |
| update-draft-post | 既存の記事を更新する | 通常の投稿で、下書きのものだけ |
この仕組みにより、「管理画面でできること」と「Codexに任せること」を分けています。将来、カテゴリ設定や画像設定をMCPに任せる場合も、必要な機能だけを追加し、その機能の中で条件を確認します。
プラグインの中では何をしているか
独自プラグインの中心となるファイルは、WordPress内の次の場所にあります。
wp-content/plugins/dotmargin-mcp-abilities/dotmargin-mcp-abilities.php
まず、MCPから呼び出せる機能をWordPressに登録します。次の例では、下書き更新の処理と、実行してよいユーザーかを確認する処理を指定しています。
wp_register_ability(
'dotmargin/update-draft-post',
array(
'execute_callback' => 'dotmargin_mcp_update_draft_post',
'permission_callback' => 'dotmargin_mcp_user_can_update_draft_post',
)
);
permission_callbackで権限を確認し、問題がなければexecute_callbackが実際の更新を行います。登録されていない機能は、Codexから呼び出せません。
更新処理では、対象の記事が本当に下書きかを確認します。さらに、保存時の状態も下書きに固定します。
if ( 'draft' !== $post->post_status ) {
return new WP_Error( 'not_draft', '下書きだけを更新できます。' );
}
$result = wp_update_post(
array(
'ID' => $post_id,
'post_content' => $content,
'post_status' => 'draft',
),
true
);
そのため、間違った記事番号を指定しても、公開済みの記事をそのまま上書きすることはありません。
ブロックエディターへの対応
現在の記事本文は、クラシック形式の大きなHTMLではなく、WordPressの標準ブロックとして保存しています。段落や見出しの前後には、WordPressがブロックを識別するためのコメントが入ります。
<!-- wp:paragraph -->
<p>ここに本文が入ります。</p>
<!-- /wp:paragraph -->
独自プラグインでは、更新時にcontent_formatとしてblocksを指定できます。その場合は、WordPress標準の関数で内容を解析してから保存します。
$blocks = parse_blocks( $content );
dotmargin_mcp_validate_blocks( $blocks );
$content = serialize_blocks( $blocks );
許可しているのは、段落、見出し、リスト、コード、表、画像、基本的なレイアウトなどです。自由なHTMLを貼り付けるカスタムHTMLブロックや、許可していない動的ブロックが含まれていれば、記事全体の更新を中止します。
この確認があることで、Codexが作った本文をブロックエディターで編集しやすくしながら、意図しないHTMLやスクリプトが入り込む可能性を下げています。
WordPress側の環境と認証
- WordPress 7系
- PHP 8系
- 公式MCP Adapter
- 独自プラグイン「DotMargin MCP Abilities」
接続にはMCP専用のWordPressユーザーとApplication Passwordを使っています。Application Passwordは、通常のログインパスワードとは別に発行でき、不要になったらWordPress側で取り消せます。
認証情報はWindowsの環境変数に置き、記事本文、チャット、Google Drive内の資料には書きません。Codexの設定にも、認証情報そのものではなく環境変数の参照だけを登録しています。
ChatGPTデスクトップアプリ内のCodexへのログイン方法についてはOpenAIの認証ドキュメント、MCPの設定についてはOpenAIのMCPドキュメントで確認できます。
実際に確認したこと
- WordPressからサイト概要を読み取れることを確認した
- 「Hello world!」というテスト記事を下書きで作成した
- テスト記事を、現在の技術記事へ書き換えた
- カテゴリ、タグ、アイキャッチ画像を設定した
- 本文をWordPressの標準ブロックへ変換した
- MCP経由で再保存し、下書き状態とブロック構造が保たれることを確認した
カテゴリやタグ、アイキャッチ画像は、現時点では専用のMCP機能を作っていないため、WordPressの管理画面から設定しています。
安全に運用するためのルール
- 公開、削除、設定変更、プラグインやテーマの変更は、内容を確認してから行う
- MCPには必要な機能だけを追加し、任意のPHPやコマンドを実行する機能は作らない
- 保存後は、記事の状態と更新内容をもう一度読み取って確認する
- プラグインを変更する前に、元へ戻せるソースや記事のリビジョンを残す
- 認証情報やサーバー内部の絶対パスは、記事や作業記録へ載せない
WordPressのAbilities APIについては公式ドキュメント、MCP Adapterについては公式リポジトリ、ブロックの保存形式についてはブロックマークアップの解説が参考になります。
まとめ
今回の連携で重要なのは、Codexに強い権限を渡すことではなく、必要な操作を小さく定義し、WordPress側でも条件を確認することです。
Codexは文章作成や繰り返し作業を担当し、人は公開判断や新しい権限の追加を確認します。この役割分担なら、作業を効率化しながら、WordPressを管理する上で必要な安全性も保ちやすくなります。
