管理画面から入れられる、AIとの接続部品
WordPressの「MCP Adapter」が公式プラグインディレクトリに掲載され、管理画面から検索して導入できるようになった。AIクライアントとサイトをつなぐ入口が、普段のプラグイン導入と同じ場所に来たことが変化だ。ただし、このプラグインを有効にしただけで、AIが記事を書いたり自動公開したりするわけではない。
公式ページは、MCP Adapterをサーバーと通信の層と説明している。サイト側に登録された操作を、Model Context Protocol（MCP）に対応するクライアントへ公開し、認証、権限確認、通信上の取り決めを処理する。AI機能そのものを提供する部品ではないという点を、最初に押さえたい。
AIができることは、サイトに登録した操作で決まる
WordPressのAbilities APIでは、コアやプラグインが持つ個々の操作を「アビリティ」として登録する。入力の形式、出力の形式、実行する処理、必要な権限などが、その操作の定義になる。MCP Adapterは、その定義をMCPのツール、リソース、プロンプトとして外部へ届ける。
たとえばサイトに公開された操作が投稿の検索だけなら、その接続から直ちに公開済みの記事を削除できるわけではない。逆に、更新や削除の操作を公開し、接続ユーザーにも実行権限を与えていれば、影響は大きくなる。接続できることと、どんな操作を渡すかは別の判断だ。
公式FAQでは、登録されたすべてのアビリティを自動で公開するわけではないと説明する。MCPへ公開する指定が必要で、実行時には接続しているユーザーに対する権限確認も走る。もっとも、その確認が適切かどうかは、個々のアビリティの実装にも依存する。接続部品を公式のものにしただけで、自作の操作の権限漏れまで解消するわけではない。
接続ユーザーは、任せたい仕事に合わせて選ぶ
接続するAIクライアントは、WordPressユーザーとして認証する。編集部の考察では、日常の下書き作成用に管理者の資格情報を渡すより、必要な操作だけを認めた専用ユーザーを用意するほうが、影響範囲を把握しやすい。
公開と下書き保存も分けたい。AIに文章を作らせることは承認済みでも、その文章を読者へ出すことまでは承認していない場合がある。人が確認する工程を残すなら、公開権限を持たない接続ユーザーや、下書き専用のアビリティで境界を作る。自然言語の指示だけに頼らず、サイト側でも実行可能な範囲を狭められる。
資格情報は、接続をやめたときに回収できることも重要だ。共有の管理者アカウントを使い回すと、どの処理が何を行ったかを追いにくい。テスト用、日常運用用、管理作業用を分け、誰がどの接続を止められるかを決めておくと、事故や担当変更への対応も容易になる。
0.7.0では、同梱から共有プラグインへ方針が動いた
イノベトピアの記事が取り上げた0.7.0は、10月2日付の更新だ。二つのMCP仕様リビジョン、2025-11-25と2026-07-28への対応に加え、ほかのプラグインへライブラリとして同梱する利用を非推奨にした。
開発者向けには、プラグインの依存先としてMCP Adapterを宣言する方法が示される。各プラグインが別々のコピーを持つと、どの版が読み込まれるかが複雑になる。共有の接続層へ寄せることで、仕様更新や不具合修正の入口をそろえようとする方向だ。
ただし、単に同梱ファイルを消せば移行が終わるとは限らない。公式の移行ガイドは、スキーマや通信処理、内部クラスを直接使う実装について変更点を説明する。アビリティの登録だけをしている場合と、通信の内部へ踏み込んだ独自実装では、確認する範囲が違う。
10月15日には0.7.1が公開されている
10月17日の確認では、公式ディレクトリの更新履歴に0.7.1が掲載されていた。保存するセッション初期化情報を4KiBに制限し、大きすぎるデータから回復する処理、同梱コピーとインストール済み版の読み込み順、存在しないアビリティ名の扱いなどを修正している。影響するクライアントは一度再接続する必要があるという。
このため、これから導入する読者へ0.7.0だけを最新版として案内するのは適切ではない。元記事が説明した配布方法の変更を押さえつつ、導入時には現在の配布版と変更履歴を確認したい。まだ0.xであり、互換性に関わる更新もある。
特に既存の接続があるサイトでは、更新前の構成と認証方法、公開しているアビリティを控え、検証環境で接続し直す。成功した処理だけでなく、権限がない操作や、公開していない操作が拒否されるかも確かめる。エラー文が変わった場合には、監視側の条件が影響を受けるかも見ておくとよい。
サイト内の機能と、ホスティング管理を分ける
WordPressを扱うMCPサービスには、サーバーの作成、バックアップ、契約管理などを対象にするものもある。MCP Adapterがつなぐのは、WordPressのAbilities APIに登録された機能であり、ホスティング会社の管理機能と同一ではない。
同じMCPという規格を使っていても、接続先が扱う資産は違う。記事の下書きを作るつもりで、サーバー全体を変更できる接続まで渡してしまえば、許可する範囲が過大になる。どのサーバーが何を公開し、どの資格情報で動くかを、名前ではなく機能の一覧で把握する必要がある。
編集部としては、導入の第一歩を、使いたい操作を一つに絞ることから始めるのがよいと考える。投稿を検索し、指定した記事の内容を取得するところまで確認する。その後、下書き保存、更新などを順に加える。操作を増やすたびに、成功条件と拒否条件を対で試せば、権限の広がりを追いやすい。
AI対応の価値は、操作の説明と制約の明確さにある
MCPで標準化された接続口ができれば、クライアントごとに独自の連携を作る負担を減らせる。一方、AIへ伝える操作名や説明が曖昧なら、適切なツールを選ぶのが難しくなる。入力項目の意味や、実行時に変更される範囲を明確にすることも、サイト側の仕事になる。
たとえば「記事を更新する」という一つの操作へ、本文の修正、公開日の変更、カテゴリの変更、公開までをまとめると、依頼の小さな違いが大きな影響へつながる。必要に応じて操作を分け、何が変わったかを結果として返す設計なら、人の確認もしやすい。
公式ディレクトリへの掲載は、導入の手間を下げる重要な一歩だ。その先で運用の品質を決めるのは、どんなアビリティを用意し、誰の権限で公開し、変更をどう確かめるかになる。プラグインを入れる作業を、AIに任せる範囲を決める作業と組み合わせたい。
確認日：2026年10月17日。技術資料はWordPressの公式リポジトリを参照。運営会社：RO合同会社の公式HP。
PR
ElevenLabs →
