WordPress 7.1の開発議論、AIが読むCMSに必要な権限と互換性

まず、能力を宣言するAPIの役割を押さえる

Abilities APIの公式資料は、WordPressが持つ操作を、入力、出力、権限確認、実行処理などとともに登録する仕組みを説明している。人間が管理画面を見て理解する操作を、外部の道具も機械的に調べやすい形へ整理する考え方だ。

ここで、APIがあることと、AIが自動的に利用を始めることは同じではない。サイトにどんな操作を登録し、どの経路へ公開し、誰の資格で呼ぶかによって、できる仕事は変わる。AIモデルそのものの提供や、全投稿の自動公開を意味する仕組みではない。

MCPも別の層である。MCPは外部のクライアントとツールをつなぐ仕様であり、Abilities APIはWordPress内の能力を表現するAPIである。両者をつなぐ実装があれば利用できるが、同じ名前の機能として扱わない方が、障害や権限の所在を追いやすい。

読み取り専用でも、公開する情報の範囲は重要になる

7月2日のCore abilities拡張提案では、core/read-settings、core/read-content、core/read-usersという三つの読み取り能力が示された。設定、コンテンツ、利用者情報を、一定の形で取得する方向である。管理や更新を行う能力は、別の段階の目標として整理されていた。

読み取りであっても、すべての情報を外へ渡してよいわけではない。公開済みの記事と未公開の原稿、一般公開のプロフィールと管理用の情報は、同じサイト内に共存する。呼び出すユーザーに何が見えるかを、個々のデータと権限で確認する必要がある。

提案は、WordPressへ登録したものを無条件ですべて公開する方向ではなく、対象を明示的に選ぶ考え方も含んでいる。既存のREST APIと似ている部分があっても、何を新しい能力として切り出すか、名前をどう揃えるかは、長期の互換性に関わる判断になる。

元報道は、コンポーネントのメンテナーから、実際の検証状況、命名、APIの形について異論が出たと紹介する。この点も、採用が決定した仕様と同じ調子で記すべきではない。公開の提案とコメントは、設計が固まるまでの過程を示している。

Knowledgeは、AIの知能ではなく情報を置く基盤として提案された

GuidelinesをKnowledge上に構築する提案は、wp_knowledgeという投稿タイプを使い、ガイドライン、記憶、メモなどを、権限とリビジョンを伴う情報として保存する構想だった。

例えば編集方針やブランドの文体を、担当者の手元の文書だけでなく、サイトに関連づけた管理対象にする発想である。ただし、保存の仕組みがあるだけで、AIが内容を正しく理解し、すべての出力に従うとは限らない。提案はモデルや検索アルゴリズム、自律的に記憶を更新する機能そのものを提供するものではないと説明している。

ここには実務上の違いがある。方針を置く場所、誰が変更できるか、いつの版かが分かれば、AIに渡した文脈の出所を追いやすくなる。一方、古いルールと新しいルールが競合した場合や、利用する道具が情報を取り込まなかった場合には、別の対応が必要になる。

元記事は、7月10日にKnowledge提案の7.1への採用を見送る判断が示されたと記している。動作する実装があることと、長期に支えるCoreへ採用することの間に、利用実績や継続的な需要を確認する段階があるということだ。提案の存在を、全サイトの正式な機能として紹介しないようにしたい。

Playgroundの試行と、本番サイトを分ける

公式の月次まとめは、Personal PlaygroundのMCP対応にも触れている。ブラウザー内で動くWordPressを、外部の道具から扱う実験の入口が増える。元報道は、登録された能力を列挙、検査、実行するメタツールの構成を説明している。

試せるものがあることは、利用方法を検証する上で役立つ。一方、Playground上で動作したことが、そのまま本番サーバーの認証、ネットワーク、データ保管、プラグインの組み合わせで同じように動くという保証にはならない。Coreの採用状況とも別の話である。

企業の試験では、公開して問題のないサンプルデータで、能力の一覧と権限を確かめるところから始めるとよい。読み取りの成功だけでなく、読めないはずの原稿が返らないか、権限のない操作が拒否されるかも確認対象になる。

AI関連の変更以外にも、互換性の確認が必要だった

7月の開発記録は、React 19、コンポーネントのサイズ、アイコンの色、レスポンシブなスタイルなども扱っている。AI関連の項目だけを見て更新の判断をすると、利用者が日々触る画面の変化を見落とす可能性がある。

React 19については、6月に互換性の問題から更新が一時的に戻され、検証を進める経緯があった。公式の差し戻し説明は、プラグインが依存する実行環境の変化を考える資料になる。7月時点の採用目標を、すべてのプラグインで問題がないという確認へ置き換えてはいけない。

また、コンポーネントの40pxサイズの扱いや、アイコンのcurrentColorへの移行は、小さく見えても表示へ影響する。既存のCSSや部品の前提が変われば、ボタン、入力欄、アイコンの大きさや色が変わることがある。管理画面を含め、実際に使う幅と操作で確認したい。

元記事にはGutenbergの最低要件、非推奨となったフック、WordPress StudioのLinuxベータ対応なども紹介されている。これらも、使う製品の版と対象環境に紐付いた変更である。開発のまとめを、そのまま現在の更新手順の代わりにはしない方がよい。

修正件数は、一次資料の集計に合わせる

7月9日の7.0.1については、月次まとめの内訳と、公式のリリース告知の総数に違いがあったと元報道は指摘する。WordPressの公式リリース告知では、Coreとブロックエディタ全体で31件のバグ修正としている。

こうした数値は、チケット、プルリクエスト、利用者が経験する不具合を何として数えるかでも変わり得る。別の集計を足し合わせて独自の確定値にするより、どの公式説明の数字かを添える方がよい。更新の価値も、件数の多さだけでなく、自分の環境に関わる修正で判断する必要がある。

既存の選択肢を残す判断も、開発の一部

7月7日のクラシックブロックに関する公式説明では、インサーターから隠す計画を撤回し、選択肢として残すことを示した。古い機能を使わなくさせることと、利用者が移行できる条件を整えることは別の仕事だと読める。

当サイトの考察として、AI向けの新しい操作口を追加する場合も、同じ視点が役立つ。新しい手段が使えるようになっただけで、人間の編集画面や既存の確認手順を急に外す必要はない。並行して使う期間に、どの作業が任せられ、どこで人の確認が必要かを確かめられる。

開発の日程は判断を促すが、公開APIはリリース後も使われ続ける。試作の便利さだけでなく、互換性、命名、権限、実績について議論することは、その後の利用者に影響する設計の仕事である。

市場シェアだけで、開発の目的を決めつけない

元記事は当時のWordPressの市場シェアも取り上げる。ただし、市場全体の比率が変わったことから、個々のサイトがどこへ移転したかは分からない。CMSを検出できないサイトの分類を、すべてAIで作られたサイトだと説明する根拠もない。

同様に、Abilities APIなどの取り組みを、WordPressが公式に市場シェア対策と位置づけたと断定するのも適切ではない。AIが扱えるCMSとしての価値を考えるのは分析であり、発表された目的や実装状況とは分けて示す必要がある。

実務で必要なのは、自社サイトのデータと操作を正確に整理することだ。下書き、公開、更新、削除、設定変更を一つの広い権限へまとめず、任せたい仕事と対応させる。呼び出しの記録や、変更後の確認も含めて設計する。

運営会社のRO合同会社の情報も参照し、CMSとAIの連携では、新機能の導入と、編集責任・アクセス権の確認を合わせて進めたい。参考資料：イノベトピア、WordPressの月次まとめ、Abilities API、各公式提案。本稿は7月の開発判断を振り返ったもので、未確定だった機能を現在の確定仕様と扱っていない。