ChatGPTからWordPressの記事を編集できるようになると、管理画面へ何度もログインする作業が減ります。一方、複数のサイトを接続する場合には、別の問題が生まれます。記事を書き換える前に「どのサイトに接続しているか」を確かめなければ、違うサイトに公開してしまう可能性があるということです。
2026年10月、ミロクAIを管理するWordPress MCPと、別プロジェクトで運用しているWordPress MCPを区別する運用を決めました。この記事は、その際に実際に確認したことと、以降のサイト改修で採用した手順を整理した記録です。もう一方のサイトの接続情報や認証情報は掲載しません。
なぜ2サイトを分ける必要があったのか
ChatGPTからWordPressに接続できても、会話の指示だけで必ず接続先が自動的に固定されるとは限りません。接続が複数あれば、それぞれ別のサイトへの操作権限を持ちます。記事の公開・変更・削除は、間違ったサイトで実行すれば実害があります。
私が区別することにしたのは、「ミロクAIの運用プロジェクトではmirokuai.netを操作する」というルールと、他のプロジェクトを操作するときにはそのプロジェクトの接続を使うというルールです。
これはWordPressに設定した「自動振り分け機能」ではありません。毎回、利用する接続先を確認してから操作するための運用上の決まりです。
実際に確認したこと①：接続ごとにサイト情報を読み取る
最初に行ったのは公開・削除のような書き込みではなく、読み取り専用のサイト情報取得でした。対象のMCP接続を指定してホームURLを問い合わせ、https://mirokuai.net が返ることを確認しました。もう一方の接続についても、別のサイトURLが返ることを確認しています。
この段階では記事の本文や公開状態は変更していません。接続の名前ではなく、実際にサーバーから返されたURLで判断することを重視しました。
実際に確認したこと②：接続先によって使える操作が異なる
二つのMCP接続では、利用できる機能名や操作範囲が同じとは限りません。そこで、更新を実行する前に対象接続で公開されている機能一覧を確認するようにしました。
例えば、記事情報の取得、下書き作成、画像のアップロード、記事の公開といった作業です。同じ「WordPressを操作する」という目的でも、使える機能と入力項目を確認してから実行する方が安全です。
私が採用した公開前の5段階
- プロジェクトを確定：今回はミロクAIの作業か、別プロジェクトの作業かを決める。
- URLを確認：操作する接続から返されたサイトURLが目的のドメインかを確かめる。
- 書き込み前に取得：記事ID、記事タイトル、現在の下書き・公開状態を取得する。
- 必要な操作だけ実行：本文更新、画像設定、カテゴリー変更、公開などを分け、対象記事に限定して実行する。
- 結果を再取得：「公開しました」という応答だけで終わらず、公開済み一覧や記事URLを確認する。
この方法は「事故が起きたあとに気づく」のではなく、「どの接続で何をしたか分かる状態を作る」ためのものです。
実際の運用例：ミロクAIの公開記事と画像
今回のAdSense再審査に向けた改修では、mirokuai.netの接続に限定して、固定ページの公開、既存記事のリライト、画像のメディアライブラリ登録、アイキャッチの設定、新規記事の公開を実行しました。
画像を付けた記事を公開するときも、本文への画像挿入とアイキャッチ設定は別の操作でした。画像IDと記事IDを確認し、変更後の本文・公開ステータスを再取得してチェックしました。
こうした操作を説明した記事は、ChatGPT＋WordPress MCPに任せる作業と人が判断する作業にもまとめています。
注意したい3つの失敗パターン
接続名だけで正しいサイトだと思い込む
接続の表示名は任意に設定されることがあります。名前が合っていても、対象URLを読み取り専用の操作で確認する方が確実です。
記事IDだけを見て更新する
WordPressの記事IDはサイトごとに管理されます。同じ数値のIDが別のサイトに存在する可能性もあります。サイトURL・記事ID・記事タイトルの組み合わせで対象を確かめます。
一回の応答を成功の証拠にしてしまう
操作要求が受け付けられても、表示内容や公開状態が想定どおりとは限りません。WordPressが返す公開状態、記事URL、必要に応じて実際の表示画面を確認します。
「全部自動」にしないことも自動化の設計
実際には、テーマのPHP変更が事前チェックでHTTP 429となり、公開を断念したケースもありました。そのときは無理に安全確認を回避せず、WordPress標準の固定ページと内部リンクを使う方法に変更しています。この判断はWordPress MCPのHTTP 429検証記録に残しています。
記事やサイトの更新をAIに任せても、対象の選択、検証できない内容の扱い、公開の可否は人が責任を持つべき部分です。
まとめ：接続を分けるのは、記事を正しく届けるため
今回確認できたのは、二つの接続がそれぞれ異なるサイトURLを返すこと、そしてミロクAIに限定した操作で記事や固定ページを更新できたことです。「誤操作が起こらない仕組みが完全に保証された」という意味ではありません。
今後も新しい記事を公開するときには、まず接続先URLを確認し、変更後に記事を再取得する。この手順を運用ルールとして続けます。
記録日：2026年10月。接続先URLの確認と、実際のWordPress MCP操作をもとに執筆しました。図は実際の管理画面ではなく、手順を示す説明図です。
コメント