ChatGPTで記事を企画し、構成を考え、本文を書いて、推敲や校閲まで行う。記事制作にChatGPTを活用していると、こうした作業は一つの会話の中で進められるようになります。ところが、記事が完成した後には、WordPressの管理画面を開いて本文を貼り付け、タイトルやSEO関連の項目を設定するという作業が残ります。既存記事の改善も同様で、ChatGPTと相談しながら修正内容を決めても、実際にWordPressへ反映するには別の操作が必要です。

できれば「じゃあ、この記事を公開しておいて」と指示するだけで、完成した記事をWordPressに反映できるようにしたい。そこで今回、ChatGPTから自社WordPressを操作するための専用MCPを開発しました。完成した仕組みでは、普段利用しているChatGPT Plusの通常チャットから記事を取得し、変更内容を確認したうえで、必要な操作を実行できます。実際に既存記事の内部リンク改善にも活用し、PCブラウザ、デスクトップアプリ、iPhoneから利用できる環境を整えました。

ただし、開発にあたって最も重視したのは、ChatGPTが操作できる機能を増やすことではありません。むしろ、ChatGPTに任せる仕事を、必要な範囲に制限することでした。今回は、既存のWordPress連携サービスではなく専用MCPを開発した理由と、実際の構築・運用でわかったことを紹介します。

ChatGPTとWordPressを連携する方法は、すでにある

ChatGPTからWordPressを操作するために、必ずしも専用のシステムを開発する必要はありません。例えば、WPWriterは、ChatGPTなどからWordPressのコンテンツを管理するためのサービスです。記事の作成・編集に加えて、AIによる文章や画像の生成、SEO関連の設定、投稿管理など、幅広い機能を提供しています。自社サーバーで運用するWordPressにも対応しており、記事制作から運用までをまとめて効率化したい場合には有力な選択肢です。

また、WordPress.comもChatGPT向けの公式プラグインを提供しています。ChatGPTとの会話から記事の作成・編集やコメント管理などを行うことができ、操作機能の選択や変更前の承認といった仕組みも備えています。こうした既存サービスを利用すれば、自分でMCPを開発する手間を省ける場合があります。特に、記事の作成や投稿を効率化することが主な目的なら、既存のサービスを利用する方が合理的かもしれません。

私も当初、WPWriterの利用を検討しました。しかし、今回は専用のMCPを作ることにしました。その理由は、既存サービスの機能が不足していたからではなく、自分が求める権限設計と役割分担を実現したかったからです。

独自MCPを作った最大の理由は、セキュリティ

今回、最も重視したのはセキュリティです。私がChatGPTに任せたいのは、記事の執筆や編集、そして完成した記事をWordPressに反映する作業です。一方、固定ページの変更、サイト設定の修正、テーマやプラグインの操作などを任せるつもりはありませんでした。特に意識していたのが、ChatGPTのWorkのように、複数の作業を自律的に進められる環境での利用です。

例えば「新しい記事を作成して」と依頼した場合、接続先のツールに固定ページの編集やサイト設定の変更機能まで備わっていると、操作対象の取り違えなどによって、意図しない変更が行われるリスクを考慮する必要があります。もちろん、これはWorkや既存のWordPress連携サービスが勝手にサイトを書き換えるという意味ではありません。既存サービスにも権限管理や承認の仕組みがあり、実際に何を操作できるかは設定によって異なります。ただ、そもそも記事の編集しか任せないのであれば、固定ページを編集できる機能まで提供する必要はないのではないかと考えました。

そこで今回のWordPress Managerでは、操作対象を自社サイトの知見記事に限定しました。固定ページやサイト設定を変更する機能は用意せず、WordPress側にも専用ユーザーを設けて、編集できる記事を制限しています。さらに、記事の読み取りと更新・公開では必要な認証権限を分け、実際の変更には人間による承認を必要とする設計にしました。ChatGPTへ「固定ページは変更しないで」と指示するだけではなく、MCPを通じて実行できる操作そのものを制限していることが重要です。

情報セキュリティには「最小権限の原則」という考え方があります。必要な仕事をするために、必要な範囲の権限だけを与えるというものです。操作機能を限定するだけですべてのリスクがなくなるわけではありませんが、不要な操作を最初から提供しなければ、意図しない変更が及ぶ範囲を小さくできます。私が作りたかったのは、ChatGPTをWordPressの管理者にする仕組みではなく、記事を書くWriterであり、内容を整える編集部として働いてもらうための仕組みだったのです。

WordPress操作用のプラグインに、AI機能はいらなかった

独自MCPを選んだ理由は、もう一つあります。それは、WordPressを操作するプラグイン自体には、AIによる文章生成機能を必要としていなかったことです。私は今回の開発以前に、Google Analytics 4（GA4）、Google Search Console、Google広告のKeyword PlannerなどをChatGPTから利用できる、マーケティング分析用の独自プラグインを開発していました。そのため、Webサイトのアクセス状況や検索パフォーマンスの分析、キーワードの検索需要調査などは、すでにChatGPT上で実施できます。

記事制作についても、検索結果や競合コンテンツを調査し、構成を考え、本文を執筆するところまで、ChatGPTと一緒に進めています。完成した文章は、推敲や校閲、ファクトチェックを行いながら修正を重ねます。実際に今回の記事も、Marketing MCPでキーワード調査を行い、検索結果を確認したうえで構成を検討しました。その後、ChatGPTにブランドマネージャー、UXライター、ウェブライター、コンテンツマーケターという4つの専門的な視点から原稿を評価させ、指摘を踏まえて修正しています。

つまり、私の場合、記事が完成するところまでは、すでにChatGPTの中で作業できる環境が整っていたのです。この状態でWordPress ManagerにもAIによる文章生成機能を追加すると、似た役割を持つ仕組みが重複します。生成モデルやプロンプトの管理、品質評価など、新たな保守対象も増えることになるでしょう。それよりも、分析や調査はMarketing MCP、記事の執筆や校閲はChatGPT、WordPressへの反映はWordPress Managerというように、役割を明確に分ける方がシンプルだと考えました。

WordPress Managerに求めていたのは、高度な文章生成ではありません。ChatGPTで完成させた記事について、対象と内容を確認し、承認したものをWordPressへ反映できれば十分でした。すでにあるAIの機能を別のツールに重複して実装するのではなく、必要な操作をつなぐことに開発の範囲を絞ったのです。

ChatGPT PlusとWordPressをどう接続したのか

今回の仕組みには、MCP（Model Context Protocol）という技術を利用しています。MCPは、AIが外部のデータやシステムを利用するための共通の接続方法です。ChatGPTは記事の執筆や分析ができますが、それだけでは自社WordPressの記事を直接取得・更新できません。そこで、ChatGPTからの操作要求をWordPressへ受け渡すために、WordPress Managerという専用MCPを作成しました。

構成は「ChatGPT Plus → WordPress Manager（MCP） → WordPress REST API → 自社WordPress」というものです。WordPress REST APIは、WordPressが標準で備えている外部連携機能で、管理画面を開かずに記事の取得や更新などを行えます。WordPress ManagerはChatGPTから受け取った操作要求を、このREST APIにつなぐ役割を担います。なお、ここでいう「プラグイン」は、WordPressにインストールする一般的なプラグインとは異なり、ChatGPTから呼び出すための独立した接続サービスを指しています。

WordPress Managerの稼働環境には、Google CloudのCloud Runを採用しました。Cloud Runはクラウド上でプログラムを実行できるサービスで、自分のパソコンを常時起動しておく必要がありません。開発には自宅のMac miniをメインマシンとして使用していましたが、完成後のWordPress ManagerはCloud Run上で動作するため、開発用パソコンの稼働に依存しない構成になっています。

ただし、ChatGPT Plusの契約だけで、この環境を自動的に構築できるわけではありません。MCPのプログラムやCloud Runの設定、認証の仕組み、WordPress側のユーザー権限などは別途用意する必要があります。今回実現したのは、それらを組み合わせることで、普段利用しているChatGPT Plusの通常チャットからWordPressを操作できる環境を整えたことです。

記事の取得・確認・変更を分けて、安全性を確保する

WordPress Managerには、全部で8つの操作機能を実装しました。記事の検索と取得、下書き作成・記事更新・公開の各プレビュー、そして下書き作成・記事更新・承認済み下書きの公開という構成です。大きく分けると、読み取り、変更内容のプレビュー、実際の書き込みという3種類の役割があります。

特に重視したのが、プレビューと実行を分けることです。例えば、既存記事に内部リンクを追加する場合、ChatGPTが修正内容を考えた段階ではWordPressを変更しません。まず変更前後の差分を確認し、問題がなければ対象記事を指定して実行します。記事の公開も同様で、公開対象と内容を確認したうえで、明示的な承認を受けてから処理する設計にしています。

また、更新前には記事のバージョンを照合する仕組みも設けています。プレビュー後に別の操作で記事が変更されていた場合などに、古い内容を前提とした更新を防ぐためです。こうした操作対象の制限、認証権限、変更前の確認、人間による承認という複数の対策を組み合わせることで、意図しない変更のリスクを低減しています。

これらは、AIの判断が常に正しいことを前提にしないための設計です。もっとも、安全対策のすべてを本番環境のあらゆる操作で検証できたわけではありません。特に、新規記事の作成から公開までの一連の操作については、今後の実運用を通じて確認する必要があります。

実際の開発で苦労したのは、認証と権限管理だった

今回の開発で、最も時間がかかったのは認証の問題でした。WordPressの記事を取得するところまでは正常に動作していましたが、記事の更新や公開をプレビューしようとすると、エラーが発生することがありました。そこで必要な権限をまとめて要求する方法を試したところ、今度はChatGPTの再認証が繰り返される問題が起きました。操作が成功しないからといって、単純に権限を増やせば解決するわけではなかったのです。

原因を切り分ける過程では、ユーザー自身が持っている権限と、実際の接続時に要求する権限を区別する必要がありました。最終的には、接続時に必要な権限と、記事の更新・公開に必要な権限を分ける形へ修正しました。修正後は、ChatGPTの通常チャットから記事の取得、更新プレビュー、公開プレビューを正常に実行できることを確認しています。ただし、追加権限が必要になった場合の再認証フローについては、すべての挙動を検証できたわけではありません。

もう一つ対応が必要だったのが、WordPress側の投稿者権限です。今回のWordPress Managerでは、専用ユーザーが編集できる記事に操作対象を制限しています。ところが、既存の知見記事は別のユーザーが投稿していたため、そのままでは編集できませんでした。そこで、対象記事の投稿者を専用ユーザーへ変更することで対応しました。この方法は今回の自社サイトでは採用できましたが、WordPressの投稿者情報を変更すると、著者表示や構造化データなどに影響する場合があります。

こうした経験から、AIとWordPressを接続できることと、実際の業務で安全に利用できることは、別の課題だと実感しました。APIが正常に動くだけでなく、認証や権限管理、変更内容の確認まで含めて設計する必要があります。

PC・デスクトップ・iPhoneで動作を確認。実際の記事改善にも活用

2026年10月15日、WordPress Managerの基本的な動作検証を完了しました。今回の開発では、自宅で作業するPCブラウザ、普段利用するChatGPTのデスクトップアプリ、外出先でも使えるiPhoneアプリの3つの利用環境を想定していました。検証の結果、いずれの環境でもWordPress Managerの8つの機能が認識され、記事を正常に取得できることを確認しました。また、ChatGPTの通常チャットから、記事の更新プレビューと公開プレビューも正常に実行できています。ただし、これらはすべての端末で検証したわけではなく、実際の公開操作を含む全機能の動作を保証するものではありません。

さらに、開発用のローカル環境に依存せず利用できることを確かめるため、開発に使用していたMac miniを完全にシャットダウンした状態でも接続を検証しました。その結果、ChatGPTからWordPressの記事を正常に取得できました。別途実施したiPhoneアプリからの接続検証にも成功しており、開発用パソコンを常時稼働させる必要がなく、利用する端末も固定されない構成になっていることを確認できました。

開発後には、以前から保留していた既存記事の内部リンク改善にも活用しています。Marketing MCPでサイトの状況を分析し、ChatGPTで改善方針を検討したうえで、WordPress Managerから変更を反映しました。今回の更新では、既存の知見記事3本に内部リンクを1件ずつ追加しています。更新後にはリンクの追加と記事の公開状態が維持されていることを確認しており、分析から実装までを一連の業務として進められるようになりました。

現在は基本的な開発を終え、実際の業務で利用しながら必要な部分を改善していく段階です。新規記事の作成から公開まで、すべての操作を一通り検証したわけではありませんが、今回の仕組みを使うことで、これまで手作業で行っていた記事更新の一部をChatGPT上から実行できるようになりました。

独自MCPが、すべての人に必要なわけではない

ここまで独自MCPについて紹介してきましたが、すべてのWordPress運用者に自作をおすすめするわけではありません。例えば、ChatGPTで作成した記事をWordPressへ保存したいだけなら、WPWriterなどの既存サービスを利用する方が手軽でしょう。記事制作や画像生成、SEO関連の機能まで一つのサービスにまとめたい場合にも、汎用ツールは有力な選択肢です。

また、GoogleスプレッドシートとGoogle Apps Script（GAS）を組み合わせる方法もあります。スプレッドシートに記事のタイトルや本文、公開設定などをまとめ、GASからWordPress REST APIを呼び出せば、比較的シンプルな構成でも記事投稿を自動化できます。実現したい業務が明確で、定型的な処理が中心であれば、無理にMCPを開発する必要はありません。

一方、ChatGPTを中心とする業務環境に独自の権限制御や承認ルールを組み込みたい場合には、専用MCPという選択肢があります。ただし、独自開発には保守の責任が伴います。認証方式やAPIの仕様変更への対応、クラウド環境の管理など、使い続けるために必要な作業も発生するため、既存サービスを利用する場合と比較して検討する必要があります。

私が普段のマーケティング支援で大切にしているのは、企業の規模や体制、予算に合った「等身大」の仕組みを考えることです。高度な技術を使うこと自体が目的ではありません。必要なことを実現するために既存のツールをどう組み合わせるか、どこまでを仕組み化し、どこからを人間が担当するか。そうした判断こそが、実際の業務改善につながると考えています。

AIに何を任せるかを、先に決める

今回、ChatGPTからWordPressを操作するための専用MCPを開発しました。しかし、その出発点は、AIにできることを増やしたいというものではありませんでした。すでにChatGPT上で分析や記事制作ができていたからこそ、最後に残るWordPressへの反映作業を効率化したかったのです。その一方で、固定ページやサイト設定まで操作させる必要はありませんでした。

そこで、分析や記事制作はChatGPTを中心に進め、WordPress Managerには必要な操作だけを任せる構成にしました。AIの機能を増やしたのではなく、業務に合わせて役割を整理した結果です。今回の経験を通じて感じたのは、AIの活用を考えるとき、最初からすべてを自動化しようとする必要はないということです。人間が判断すること、ChatGPTと一緒に考えること、仕組みに任せることを整理するだけでも、業務を改善できる余地があります。

AIに何ができるかではなく、AIに何を任せるか。 今回のWordPress Managerは、その考え方を具体的な仕組みにした一例です。これからも、新しい技術を導入すること自体を目的にせず、目の前の仕事に合った使い方を考えていきたいと思います。