WordPressがAIエージェント連携を提案、OAuthとMCPを7.3で目指す

ニュース

WordPressのAIコントリビューターチームが2026年10月28日、「WordPress for the Agentic Web」という提案記事を公開しました。ユーザーが選んだAIエージェントから、WordPressサイトを安全に操作できるようにするための4つの取り組みを、WordPress 7.2で土台を作り、7.3でのコア統合を目指す形でまとめています。プラグインやテーマを作る開発者にとっては、Abilities（機能の公開）やOAuth認証の今後の方向を知る手がかりになります。

エージェントを外からつなぐ、という前提

記事の著者はJason Adams氏で、元記事はmake.wordpress.org/ai、コアチームのブログにはX-post（転載の告知）として載っています。提案が目指すのは、WordPress本体にエージェントを組み込むことではなく、ユーザーが選んだエージェントとつなげられるようWordPressを整えることです。

想定する流れはこうです。ユーザーが自分のエージェントに「このサイトを操作して」と頼むと、エージェントがWordPressだと認識して認可用のリンクを示し、ユーザーがサインインすれば作業を始められます。

いまもWP-CLIやREST APIならエージェントは操作できますが、ローカルでのアクセスや高度な設定が必要になることが多いと、記事は課題を挙げています。既存のMCP Adapterについても、インストールと設定が必要で、有用なAbilitiesを使える状態にする作業があり、Application Passwordを手動で管理する必要があるため、広く使うには向かないとしています。

4つの取り組みと、7.2・7.3の割り振り

提案は次の4つの柱で構成されています。7.2は基盤づくり、7.3はコアへの組み込みを目標にしています。

  • MCP Adapter：信頼性、セキュリティ、使いやすさを高めながら素早く改良し、7.3でコアに取り込む形（直接マージか、バンドルか）を探る
  • Abilities：サイト管理の一般的な作業に必要な基本のAbilitiesを洗い出し、7.2のベータ期間中に一部の基盤的なものを入れられないか検討する。7.3では有用なネイティブAbilitiesをコアに載せることを目指す
  • OAuth認証：Application Passwordを手作業で発行・共有せずに済むよう、7.2でフローと設計、セキュリティ上の考慮点を整理し、7.3での実装を目指す。MCPだけでなくREST APIにも役立つとされる
  • エンドツーエンドの体験：エージェントがサイトを見つけ、アクセスを求め、作業し、権限を管理・取り消すまでの全体を設計する。7.2でプロトタイプを試し、7.3で複雑な設定や技術的な知識なしに好みのエージェントをつなげられる体験を目指す

OAuthの項目では、7.2で予定されているSecrets APIが、トークンを安全に扱う機会になるとも書かれています。ただし、7.3への取り込みは目標であり、技術的な準備、セキュリティ、通常のコアレビューの結果しだいだと、記事は断っています。

コメント欄で出た「REST APIで足りるのでは」

コメント欄では、Adrian Mörchen氏が、多くのAIは既存のREST APIで十分動くはずで、REST APIの不足を埋めることや、より細かい権限管理を優先すべきだと指摘しました。中途半端なAPIが増えるリスクへの懸念も添えています。一方、Tammie Lister氏はUX分野への参加を表明し、Nick Diego氏は方向性に賛同しています。

著者のJason Adams氏は、AbilitiesはREST APIからも使えるので、REST中心の進め方にも役立つと答えています。MCPは事実上のプロトコルになりつつあり、プロバイダーのマーケットプレイスや、skills over MCP・MCP Appsといった拡張が出てきている、という説明です。

別の質問者（Job氏）が、プラグイン作者が自分のAbilityをMCPで公開するにはどうすればよいかと尋ねたところ、Abilityの登録時にメタプロパティを指定すればよいと案内されています（具体例はMCP Adapterのドキュメントを参照）。

提案が引用する数字

背景として、記事はGoogleのAI利用者を10億人超、OpenAIを約12億人と報告されている数字として挙げ、Adobeのデータとして、AI経由のトラフィックは非AI経由より60%コンバージョンしやすく、売上は53%多いと紹介しています。これらは記事が引用している数字で、本記事では原典を確認していません。提案の背景として受け止めるのがよさそうです。

参加の窓口と、プラグイン側で見直しておくこと

4分野それぞれにフォーカスリード（担当リーダー）と貢献者を募集しており、各リーダーには、コアコミッターがペアとして付く予定です。リーダーは週次のミーティングで進捗を共有します。連絡先は、Slackの#core-aiチャンネルか、週次のAIコントリビューターミーティングです。セキュリティについては、専門のセキュリティ向けAIモデルの活用を含むレビューや監査を行うとされています。

  1. 自分のプラグインの機能のうち、エージェントに操作させたい処理を洗い出す：Abilityとして登録する候補になります。
  2. 認証の前提を見直す：Application Passwordを配る前提の設計を、OAuthに移っても困らない形にしておけるか確認します。
  3. 7.2のベータで、どのAbilitiesが入るかを追う：提案では、一部の基盤的なAbilitiesをベータ終了までに入れられないか検討するとしています。

この記事は提案の段階であり、実装の仕様や提供時期が確定したものではありません。

OAuthへの移行が示すもの

筆者が注目しているのは、新しい機能そのものより、エージェントに権限を渡す手順が整理されようとしている点です。Application Passwordを発行して渡す運用は、どの権限をどこまで渡したかが見えにくく、OAuthで認可と取り消しの流れがそろえば、サイト管理者の判断材料は増えると考えます。一方で、コメント欄にあったように、REST APIの権限を細かくするほうが先だという見方にも一理あり、AbilitiesをREST APIとMCPの両方から呼べる設計は、その折り合いとして読めます。プラグイン側は、処理をAbilityとして切り出しておけば、どちらの経路が主流になっても対応しやすいでしょう。ただし7.3はあくまで目標とされているため、7.2のベータで何が入るかを見てから設計を固めても遅くはないと思います。これは私見であり、公式の見解ではありません。

参考にした情報

2026年11月1日時点の情報です。

コメント

タイトルとURLをコピーしました