こんにちは。KUSANAGI 開発チーム、プロダクトマネジャーの相原です。
2026年2月20日、WordPress 7.0 Beta 1 がリリースされました。今回注目したのは AI 関連の新機能です。6.9 から積み上げてきた設計思想がいよいよ形になりつつあり、実際に試さずにはいられませんでした。beta1 環境でプロトタイプを作った過程とともに、WordPress の AI に対する考え方をお伝えします。
「AI Building Blocks」という構想
WordPress AI チームは、2025年5月に正式発足しました。チームが掲げる「AI Building Blocks」という構想は、WordPress が AI と連携するための基盤を3つのコンポーネントで構成するというものです。
Abilities API は、プラグイン・テーマ・コアが自分の機能を「Ability（能力）」として登録する仕組みです。それぞれの Ability には名前・説明・入出力の定義・権限チェックが含まれ、機械にも人間にも読める形で一元管理されます。
MCP Adapter は、登録された Ability を MCP（Model Context Protocol）を通じて外部 AI ツールに公開するコンポーネントです。MCP は Anthropic が2024年11月に公開した、AI と外部ツールをつなぐ標準プロトコルで、Claude や ChatGPT、Gemini といった AI アシスタントがこの仕組みを通じて WordPress の機能を理解・操作できるようになります。
WP AI Client は、WordPress の中から AI プロバイダーを呼び出すレイヤーです。Google Gemini、OpenAI、Anthropic など複数のプロバイダーに対して共通の方法でアクセスでき、どのプロバイダーを使うかはサイト管理者の設定に委ねられる、プロバイダー非依存の設計になっています。
この3点セットを「外から AI に WordPress を理解させる仕組み」と「中から AI を動かす仕組み」として整理すると、6.9 から 7.0 への流れが見えてきます。
WordPress 6.9：基盤の登場
実はこの構想の始まりは、MCP の WordPress 実装を開発しようとしたことでした。「WordPress を MCP サーバにしよう」という動きが生まれたとき、根本的な問題が露呈します。WordPress には、プラグインやテーマが持つ機能を一元的・標準的に登録する土台となる仕組みがなかったのです。
この問題を解決するために生まれたのが Abilities API です。WordPress 6.9（2025年12月）でコアにマージされ、あわせて WP AI Client SDK の初期リリース（v0.1.0）も公開されました。Ability の登録は、フックに名前・説明・コールバックを渡すだけです。プラグインやテーマが自分の機能を「AI に使ってもらえる形」で公開できる、シンプルな仕組みになっています。
6.9 の段階では、外部の AI ツールが MCP Adapter を通じて WordPress の機能を発見・操作できる「外から AI に見せる」基盤が整いました。
WordPress 7.0：「中から AI を動かす」仕組みが加わる
7.0 beta1 で新たに加わったのが、WP AI Client のコアへのマージです。公式リリースノートでは「Web Client AI API」として紹介されており、WordPress の内部から直接 AI プロバイダーを呼び出し、登録済みの Abilities をツールとして渡して動作させることができます。
さらに 7.0 では Client Side Abilities API も導入されています。これまでサーバー側（PHP）だけだった Abilities API がブラウザ側（JavaScript）でも動作するようになり、ブロックエディタなどフロントエンドの文脈でも AI 連携が可能になりました。
6.9 で「外から AI に見せる」基盤が整い、7.0 で「中から AI を動かす」仕組みが加わった。この2段階の進化によって、AI Building Blocks の全体像がようやく形になりつつあるように感じました。
実際に試してみた
私たちは昨年10月、Gemini CLI をベースにした「KUSANAGI AI アシスト」のベータ版を提供開始しています。ターミナルで AI と対話しながらサーバを操作できる仕組みですが、「管理画面という UI から使えるようにしたい」「MCP でさらに知識を拡充したい」というロードマップがあります。これらが WordPress の提供する機能で実現できるのであれば素晴らしいことです。そこで、調査も兼ねてプロトタイプを作ってみることにしました。
最初に壁になったのは AI との連携です。WP AI Client は枠組みのみなので、実際のプロバイダーとの接続は別途必要になります。開発チャットをたどっていくと、コミュニティの方がプロバイダープラグインを公開してくれていたので、ありがたく活用させていただきました。ただ、自分が使えるモデルを動かすまでのモデル指定まわりには、少し時間を取られました。
一方で、KUSANAGI 固有の機能を Ability として登録する部分は、思ったよりスムーズでした。サービスの稼働状態・Nginx ログ・プロファイル一覧の3つを登録し、管理画面から「サーバの状態を教えて」と入力すると、AI が nginx・PHP-FPM・MariaDB の稼働状況を確認して自然な日本語で説明してくれます。「wp70 のアクセスログを見せて」と聞けば、そのプロファイルのログが要約されて返ってきます。
この結果から改善提案などをしてくれたら素敵ですよね。夢が広がります。
コマンドを覚えなくても、WordPress の管理画面から日本語でサーバに「話しかける」感覚で情報が取れる。KUSANAGI AI アシストで目指していた体験が、WordPress のエコシステムの中で形になった瞬間でした。
ホスティング側から見ると、自社のサーバ構成や管理コマンドを Ability として提供することで、AI がその環境を「知っている」状態を作れます。汎用的な AI にホスティング固有の文脈を持たせる方法として、この仕組みには可能性を感じています。
「インフラより体験」という問いかけ
この機能がコアにマージされる過程では、開発コミュニティでさまざまな議論がありました。その中で印象に残っているのが、Matt Mullenweg のこの言葉です。
“We can build all the things, but if we don’t tell people or teach them or show them or bring them along, it doesn’t matter.”
どんなに優れたインフラを作っても、ユーザーが「すぐに何かできる」と感じられなければ意味がない、という問いかけです。
KUSANAGI が目指すユーザー体験
体験を届けることの大切さは、私たちが KUSANAGI を開発する中でも強く感じていることです。KUSANAGI はもともとコマンドラインでコントロールするという思想でしたが、時代の変化に合わせて新しいユーザー体験が必要だと考えています。
おわりに
WordPress 7.0 は 2026年4月9日の正式リリースに向けて、まだ変わり続けています。Beta 2 では API キーを一元管理できる「Connectors」画面の搭載も予定されており、AI 機能としても重要な一歩になりそうです。
Gemini CLI でターミナル越しに体験した「サーバと会話する感覚」が、WordPress の管理画面の中に入ってくる。そんな未来が、だいぶ近づいてきた気がしています。WordPress の未来とともに、引き続き追っていきたいと思います。
参考：
