WordPressには以前からREST API、hooks、PHP関数、WP-CLIなど多くの拡張手段があります。問題は、外部ツールから見たとき「このサイトで何ができるのか」を統一的に発見しにくいことでした。Abilities APIは、その機能をAbilityという単位で登録し、機械が意味を理解できる形へ寄せる基盤です。
AIとの関係が注目されやすいのは、MCP AdapterやAIエージェントがAbilityを発見・利用できるためです。ただし、AIがなくてもAbilitiesは使えます。PHP内で呼ぶ、RESTから実行する、管理画面のJavaScriptから利用するといった複数のcontextで共通の機能定義を使える点が本質です。
Abilityを構成する要素を理解するとREST APIとの違いが見える
| 要素 | 役割 |
|---|---|
| name | namespace/ability形式の一意な識別子 |
| label / description | 人間・クライアントが用途を理解する説明 |
| input_schema | 受け取る値・型・必須条件 |
| output_schema | 返す値の構造 |
| execute_callback | 実際の処理 |
| permission_callback | 実行してよいかの認可 |
| meta / annotations | public、readonly、destructive等の追加情報 |
REST APIはURLでresourceへアクセスする仕組み、Abilityは「何をする機能か」を中心に定義する仕組み、と考えると分かりやすくなります。たとえば「記事一覧を返す」という機能をAbilityとして定義し、その同じ機能をPHP、REST、MCPなど複数経路から利用できます。
WordPress 6.9→7.0→7.1で何が変わったか
| バージョン | Abilities周辺の要点 |
|---|---|
| 6.9 | Abilities APIがCoreへ入り、機能の登録・発見・実行の基盤ができた |
| 7.0 | クライアント側から扱う仕組みが広がり、AI ClientもCoreへ導入 |
| 7.1 | filtering、validation拡張、execution lifecycle hooks、public flag、JSON Schema互換性などを改善 |
7.1は単に関数が増えたのではなく、外部クライアントへ見せることと、実行を安全に制御することの境界が明確になった更新です。AI/MCPのように「機械がAbilityを選ぶ」利用を考えると、説明・schema・権限・監査が揃っていることが重要になります。
WordPress 7.1で重要な安全・実行制御
public=trueは「誰でも実行できる」という意味ではない
WordPress 7.1ではAbilityのmetaにpublicという高水準の公開意図を持たせられます。RESTの場合、明示的なshow_in_restがなければpublicの値が既定値として使われます。ただしpublicは「外部クライアントへ公開候補にするか」を示すもので、認可そのものではありません。
実行時にはpermission_callbackが引き続き重要です。public=trueでも、current_user_can等で必要権限を満たさなければ実行を拒否できます。逆に「非公開だからpermissionは雑でよい」と考えるのも危険です。将来別の経路から呼ばれる可能性を考え、Ability自身が実行条件を持つ方が安全です。
7.1のvalidation強化はAI連携で特に効く
AIや外部クライアントは、人がフォームへ入力するより幅広い値を送ってくる可能性があります。Abilities APIはinput/output schemaで型や構造を定義し、7.1では独自のvalidation filterも追加されました。さらにREST経由のrunでは、schemaに合わせた型変換も改善されています。
たとえばlimitを整数、featuredをboolean、idsを整数配列として定義していれば、受け取った値を各実装が毎回独自に解釈する負担を減らせます。ただしschemaがあるだけで業務ルールまで守られるわけではありません。「最大100件」「自サイトの記事IDだけ」といった条件は別途validation/permissionで実装します。
execution lifecycle hookで監査・ポリシーを挟みやすくなった
WordPress 7.1ではAbility実行の前後に介入できるfilterが追加されました。`wp_pre_execute_ability`、入力正規化、permission結果、execute結果などへ共通ポリシーを挟めるため、独自プラグインごとにバラバラの監査処理を持つ必要を減らせます。
複数AbilityをAIから使わせる場合、全実行をログへ残す、特定環境ではwrite系を拒否する、出力から秘密情報を除く、といった横断ルールを置きやすくなります。個々のAbilityの処理と、サイト全体の安全ポリシーを分離できるのが実運用上の利点です。
read Abilityとwrite Abilityを分ける
「投稿情報を取得し、必要なら更新する」を1つのAbilityにまとめるより、`get-post-status`と`update-post-draft`のようにread/writeを分ける方が権限と監査を設計しやすくなります。AI側へreadだけ公開し、writeは承認済みの別経路に限定する構成もできます。
Abilityの粒度は細かすぎてもtoolが増え、粗すぎても1回の実行で何が変わるか分かりにくくなります。僕なら「1 Ability = 1つの明確な業務結果」に寄せ、入力・出力・副作用を説明文だけでなくschema/annotationにも反映します。
schema変更は後方互換性まで考える
Abilityを複数clientから使うようになると、schema変更自体がAPI契約になります。既存clientが使う必須fieldを突然削除したり、同じfield名の意味を変えたりすると、discoveryできても実行時にworkflowが壊れます。新しい入力は任意fieldとして追加し、破壊的変更が必要ならAbility名やversionを分ける方が安全です。
Core Abilityは「WordPressの状態を知る入口」になる
WordPress 7.1ではcore/get-site-info、core/get-user-info、core/get-environment-infoなどのCore Abilityが外部クライアントから扱いやすい形に整理されています。必要なfieldだけ要求できる仕組みもあり、クライアントが固定のレスポンス形を思い込むよりschemaを見て利用する設計が推奨されます。
運用自動化では、最初から投稿更新Abilityを作るより、サイト情報・環境情報・現在ユーザーなどread-only情報を取得して接続状態を確認する方が安全です。接続とpermissionが安定してから、独自の業務Abilityを追加します。
独自プラグインでAbilities APIを使うべきケース
| ケース | 向き/不向き |
|---|---|
| 同じ機能をPHP/REST/MCPから使いたい | 向く |
| AI Agentに安全に機能を発見させたい | 向く |
| 入力/出力schemaを共通化したい | 向く |
| 単発の固定REST endpointだけで十分 | 無理に置き換える必要はない |
| WordPress 6.8以前を広く支援するplugin | 互換性設計を先に確認 |
Abilities APIは新しいから全REST APIを置き換えるものではありません。既存endpointが安定している処理を急いで移すより、新しく外部クライアントやAIから利用したい機能をAbilityとして定義するところから始める方が現実的です。
公式情報・参考資料
仕様確認日：2026年9月30日。実装時はリンク先の最新版も確認してください。
- https://developer.wordpress.org/apis/abilities-api/
- https://make.wordpress.org/core/2026/07/31/abilities-api-improvements-in-wordpress-7-1/
- https://make.wordpress.org/core/2026/08/04/a-unified-public-exposure-flag-for-abilities-in-wordpress-7-1/
- https://make.wordpress.org/core/2026/08/05/wordpress-7-1-field-guide/
コメント