WordPress管理画面のAIに「投稿の更新」を任せてみた(MCP接続を実際に動かす)

このシリーズでは、本番公開を終えたあと、「WordPressの管理画面に備わったAIの仕組みを使って、サイトの更新をAIに直接任せられないか」を検証しています。前々回までに、AIとの接続を一元管理する「コネクタ」の中身や、編集画面での執筆アシストがどこまで実用になるかを見てきました。

今回はもう一段先へ進みます。編集画面のお手伝い機能ではなく、外部のAIエージェントをWordPressに接続し、AIの側から「投稿を1件更新する」という操作を実際にやらせてみた記録です。少し技術寄りの話になりますが、「AIにサイトを触らせる」ことの現実的な姿が見えてくる回です。

そもそも、AIはどうやってWordPressを操作するのか

これまで私たちは、いわば「開発者の道具」を使って本番サイトを操作してきました。サーバーに直接ログインし、コマンドでファイルやデータベースを書き換えるやり方です。これはとても強力で、サイトのどこにでも手が届きます。裏を返せば、鍵を渡した相手はサーバーの全部に手が届いてしまう、ということでもあります。

一方でWordPressは今、別の道を用意しつつあります。「サイトができること」を、AIが発見して実行できる標準化された形(これを“アビリティ”と呼びます)で公開する仕組みが、WordPress本体に組み込まれました。そして、それを外部のAIエージェントとつなぐのが「MCP」という共通の接続規格です。今回検証したのは、この橋渡しをする公式プラグイン「MCP Adapter」です。

やってみたこと

検証はすべて、本番とは切り離した手元の検証環境(WordPress 7.0.2)で行いました。本番サイトには一切触れていません。

手順はシンプルで、公式のMCP Adapterプラグインを入れて有効化するだけ。すると、AIが接続するための窓口(サーバー)が自動でひとつ立ち上がります。ここに、AIクライアントの役を担うプログラムから接続し、やり取りをしてみました。

気づき その1:入れただけでは、AIは何もできない

まず驚いたのは、プラグインを入れて接続しただけの状態では、AIは投稿の一覧を見ることすらできない、ということでした。

これは不具合ではなく、安全のためのわざとの設計です。WordPressには「サイト情報を取得する」といった標準の機能がいくつか用意されていますが、そのどれも、初期状態では外部のAIに公開されていません。「この操作はAIに触らせてよい」と、ひとつずつ明示的に許可を与えて初めて、AIの目に見えるようになります。

つまりMCP Adapterは、「鍵を挿せば何でもできる」のではなく、「許可した操作しかできない」という発想で作られています。ここは、サーバーに直接ログインするやり方(鍵があれば全部できる)とは正反対の考え方です。

気づき その2:許可した操作は、ちゃんとAI経由で実行できた

そこで今回は検証のために、「指定した投稿のタイトルと本文を更新する」という操作をひとつ用意し、これをAIに公開しました。

その上で、AIクライアントから「この投稿を、このタイトルと本文に書き換えて」と指示を送ったところ——投稿は実際に書き換わりました。念のため、まったく別の経路(従来のコマンド)でデータベースを直接読みに行って確認しても、たしかに内容が更新されています。サーバーに直接ログインすることなく、AIとの標準的なやり取りだけで、サイトのコンテンツを1件更新できたわけです。

小さな一件ではありますが、「管理画面側の仕組みを使って、AIにサイトを直接更新させる」というこのシリーズの当初の問いに、ひとつ具体的な“できた”を積めた瞬間でした。

気づき その3:権限を「操作ごと」に絞れる

いちばん価値を感じたのは、次の検証です。

今度は、記事を編集する権限を持たない“見るだけ”の利用者としてログインし、同じ「投稿を更新して」という指示を送ってみました。結果は——きっぱり拒否されました。投稿は書き換わりません。一方で、「どんな操作が公開されているか一覧を見る」ことは許されました。

これはつまり、「誰が」「どの操作を」できるかを、WordPressの権限のしくみで細かく制御できるということです。サーバーの鍵はいわば“マスターキー”で、渡した相手は何でもできてしまいます。それに対してこの方式なら、「この担当者用のAIには、投稿の更新だけ許して、設定変更や削除は許さない」といった線引きが、あらかじめ設計としてできます。AIに任せる範囲を、コードとして固定し、後から見直せる。ここが、従来のやり方にはなかった安心感でした。

で、乗り換えるべきなのか?

正直な結論を言うと、今すぐ全部を乗り換える必要はない、けれど使いどころははっきりある、というものです。

サーバーに直接ログインするやり方は、これからも「サイトの土台に関わる大きな作業」——デザインの構造変更、引っ越し、トラブル対応など——には欠かせません。権限の広さがそのまま頼もしさになる場面です。

一方でMCP Adapterは、「投稿や固定ページの文章を更新する」といった、毎回発生する定型的な作業を、権限を絞って安全にAIに任せるのに向いています。ただし、そのためには「AIに許す操作」を自分たちで設計して用意する手間が先に必要です。ここが導入の本当のコストで、逆に言えば、その一手間をかけるだけの定型作業が積み上がってきたときが、導入を見極めるタイミングだと考えています。

私たちは今回、この方式が「使える」ことと「どう安全に絞れるか」を実際に確かめられました。本番への導入は今の時点では見送りますが、任せられる定型作業がたまってきたら、あらためて公開する操作を設計して試していくつもりです。新しい仕組みほど、こうして小さく動かして手触りを確かめておくことが、後の判断を確かにしてくれます。