WordPress Abilities API とは ? Ability の役割と仕組みをやさしく解説

投稿日：

2026年8月18日

カテゴリー：AI WordPress

タグ：Abilities API MCP

Facebook

LINE

B! ブックマーク

WordPress と AI の連携について調べていると、Abilities API という言葉を見かけるようになりました。

名前に「AI」と入っているわけではありませんし、WordPress には以前から API やユーザー権限の仕組みがあります。「新しく何ができるようになったのか、いまひとつ分からない」と感じる方もいるのではないでしょうか。

Abilities API は、WordPress 内のひとまとまりの処理を、ほかのプログラムから見つけて利用できる形で登録する仕組みです。

たとえば、「サイト名を取得する」「最近公開した記事を取得する」「記事を下書きとして保存する」といった処理を、目的、受け取る情報、返す情報、実行条件と一緒に登録できます。

この記事では、Ability と WordPress のユーザー権限で使われる Capability の違い、Ability を形づくる基本要素、MCP Adapter との関係を順番に整理します。最後に、WordPress Playground の使い捨て環境で、読み取り専用の Ability を動かしてみましょう。

この記事は2026年8月10日時点の公式情報をもとにしています。Abilities API は開発が続いているため、実際に導入するときは最新の公式資料もご確認ください。

Abilities API は WordPress の処理を共通の形で登録する

最初に「API」という言葉を整理しておきます。

API は、異なるプログラム同士が、決められた方法で機能やデータを利用するための窓口です。Abilities API の場合は、WordPress 本体、プラグイン、テーマなどが持つ処理を共通の形式で登録し、必要なプログラムから見つけられるようにします。

通常の PHP 関数にも処理の名前や引数はあります。しかし、その関数が何のためにあり、どのような情報を受け取り、何を返し、誰が実行できるのかは、実装ごとに確認しなければなりません。

Ability として登録すると、処理と一緒に「取扱説明書」にあたる情報も用意できます。別のプラグインや外部システムが、その Ability の目的と使い方を機械的に確認しやすくなるわけです。

Abilities API の公式ハンドブックでは、Ability を、入力、出力、権限、実行内容が明確に定義された個別の機能として説明しています。

Abilities API が自動的に機能を増やすわけではない

ここは少し注意が必要です。

Abilities API を利用できる WordPress であっても、任意の記事作成や更新作業が自動的に Ability になるわけではありません。WordPress 本体やプラグインなどが、利用したい処理を Ability として登録する必要があります。

また、Ability を登録しただけで、AI が自動的にサイトへ接続するわけでもありません。外部から利用するには、REST API や MCP Adapter など、目的に合った接続方法と認証が別途必要になります。

Abilities API は処理を整理して利用可能にする土台であり、AI そのものでも、接続方法そのものでもありません。

Abilities API は WordPress 6.9から利用できる

サーバー側の Abilities API は、WordPress 6.9 で本体へ導入されました。ここでいう「サーバー側」は、主に PHP で Ability を登録・実行する仕組みを指します。

WordPress 6.9には、次の3つの Ability も用意されています。

core/get-site-info: サイト名、URL、WordPress のバージョンなどを取得する
core/get-user-info: 現在ログインしているユーザーの基本情報を取得する
core/get-environment-info: PHP やデータベースなど、実行環境の情報を取得する

WordPress 7.0では、管理画面などの JavaScript から Ability を扱うためのクライアント側 API も追加されました。この記事では範囲を広げすぎないよう、WordPress 6.9から利用できる PHP 側の基本を中心に説明します。

WordPress 6.8以前にも対応するプラグインやテーマを作る場合は、wp_register_ability() が存在するか確認してから処理を登録するなど、バージョンへの配慮が必要です。

Ability と Capability は役割が違う

WordPress に慣れている方ほど、Ability と Capability という似た言葉に戸惑うかもしれません。

Capability は、WordPress のユーザーが「何をしてよいか」を表す個別の権限です。たとえば、edit_posts は記事を編集する権限、manage_options はサイトの設定を管理する権限を表します。管理者や編集者といった「権限グループ」に、複数の Capability が割り当てられています。

一方の Ability は、「何をする処理なのか」を表します。

用語	表すもの	例
Ability	WordPress で実行できる、ひとまとまりの処理	サイト名を取得する、記事を下書きとして保存する
Capability	現在のユーザーが、その種類の操作をしてよいかを表す権限	`manage_options`、`edit_posts`

2つは別々の仕組みですが、実際には組み合わせて使います。

たとえば、「サイト情報を取得する」という Ability の権限確認で、現在のユーザーが manage_options という Capability を持っているか調べます。持っていれば実行を許可し、持っていなければ処理を止める、という関係です。

Ability は「何をするか」、Capability は「誰が実行してよいか」と分けると、理解しやすくなると思います。

Ability を形づくる7つの基本要素

Ability の登録には、処理の名前だけでなく、目的や入出力、権限確認などを含めます。ここでは、WordPress 本体に用意されている core/get-site-info を例に、必要な要素を見ていきます。

1. ID

Ability には、ほかの Ability と区別するための固有の ID が必要です。

core/get-site-info

スラッシュより前の core が名前空間、後ろの get-site-info が処理名です。名前空間は、どのプラグインや仕組みが登録した Ability なのかを区別するために使われます。

独自の Ability を作る場合は、my-plugin/get-site-info のように、プラグインの識別名を名前空間に使います。

2. 名前と説明

label には人が読める短い名前、description には処理の目的や内容を登録します。

ID だけを見ても、どのような場面で使う処理なのかまでは分かりません。名前と説明があることで、人だけでなく AI や自動化ツールも、目的に合う Ability を選びやすくなります。

説明は飾りではありません。「サイト情報を取得する」のか、「サイト設定を変更する」のかが曖昧では、安全に使い分けられないためです。

3. カテゴリー

各 Ability は、必ず1つのカテゴリーに所属します。

core/get-site-info は、サイトに関する処理をまとめた site カテゴリーに登録されています。Ability が増えたときに、目的別に探しやすくするための分類です。

独自カテゴリーを使う場合は、Ability より先にカテゴリーを登録します。

4. 入力

input_schema は、Ability が受け取る情報の形を定義します。

ここでいう「スキーマ」は、データの項目や種類を決める設計書のようなものです。Abilities API では JSON Schema という共通の書式を利用し、文字列、数値、配列、必須項目などを定義します。

core/get-site-info には、取得したい項目を fields として渡せます。サイト名だけが必要なら、次のような入力になります。

{
  "fields": ["name"]
}

入力を必要としない Ability では、input_schema を省略できる場合もあります。

5. 出力

output_schema は、処理が返す情報の形を定義します。

サイト名だけを取得した場合の出力は、次のような形です。

{
  "name": "オレインデザイン"
}

入力と出力の形が決まっていることで、文字列を期待していたのに配列が返る、といった食い違いを検出できます。外部のプログラム側も、どの項目を受け取れるのか事前に確認できます。

6. 実行する処理

execute_callback には、Ability が呼び出されたときに動かす PHP の関数やメソッドを指定します。

コールバックは、「必要なタイミングで呼び出される処理」を意味します。core/get-site-info では、指定された項目に応じて WordPress のサイト情報を取得し、出力スキーマに合う形で返します。

7. 権限確認

permission_callback には、現在のユーザーが Ability を実行してよいか確認する処理を指定します。

先ほど説明した Capability を確認するのは、主にこの部分です。core/get-site-info の場合は、サイト設定を管理できる manage_options を持っているか確認します。

読み取り専用であっても、サイト URL、管理者メールアドレス、環境情報など、誰にでも見せてよいとは限らない情報があります。データを書き換えないことと、誰でも実行できることは別の話です。

読み取り専用かどうかも情報として登録できる

Ability の meta には、処理の性質を伝える補助情報を登録できます。

代表的なものが、次の3つのアノテーションです。アノテーションは、処理の動き方について機械に伝える注記と考えてください。

readonly: 情報を読むだけで、サイトの状態を変更しないか
destructive: 削除など、元に戻しにくい変更を行う可能性があるか
idempotent: 同じ入力で繰り返し実行しても、追加の変化が起きないか

core/get-site-info は、読み取り専用で、破壊的な変更を行わず、同じ条件なら繰り返し実行してもサイトを変更しない Ability として登録されています。

ただし、これらは処理の性質を伝える情報です。readonly を true に設定するだけで、実行処理が自動的に読み取り専用へ変わるわけではありません。実際の PHP コードも、その説明どおりに実装する必要があります。

Ability が実行されるまでの流れ

ここまでの内容を、実行の順番に並べてみます。

利用するプログラムが、登録済みの Ability を探す
ID、説明、入力、出力などを確認する
Ability へ入力を渡す
入力がスキーマに合っているか検証する
現在のユーザーに実行権限があるか確認する
execute_callback に登録された処理を実行する
出力を検証し、結果またはエラーを返す

普通の PHP 関数を直接呼び出す場合と比べて手順が多く見えるかもしれません。しかし、この共通部分があるからこそ、呼び出す側は Ability ごとに異なる使い方を推測せずに済みます。

個人的には、Abilities API の価値は、単に AI から WordPress を操作できることではなく、処理の目的、データの形、権限を一緒に設計するきっかけを作れることにあると考えています。

Abilities API と MCP Adapter の関係

MCP は、AI アプリと外部の機能が共通の形式でやり取りするための規約です。WordPress の MCP Adapter は、Abilities API に登録された Ability と MCP の間を橋渡しします。

役割を短く並べると、次のようになります。

WordPress の処理
  ↓ Ability として登録する
Abilities API
  ↓ MCP から扱える形へ橋渡しする
MCP Adapter
  ↓ 共通の形式で依頼と結果を運ぶ
AI アプリ

Abilities API は MCP 専用ではありません。PHP や REST API、WordPress の管理画面で動く JavaScript などからも利用できます。反対に、MCP Adapter を導入しても、目的に合う Ability が登録されていなければ、その処理を AI から実行することはできません。

REST API から Ability を利用する場合は、登録時に show_in_rest を true に設定する必要があります。初期値は false なので、登録した Ability がすべて外部へ公開されるわけではありません。また、REST API の一覧取得や実行には認証が必要で、各 Ability の permission_callback による権限確認も行われます。

最初は読み取り専用の小さな処理から考える

Abilities API を知ると、記事作成や更新作業をすぐに自動化したくなるかもしれません。しかし、書き込みを伴う処理では、誤った入力、二重実行、権限設定、記録、失敗時の復旧まで考える必要があります。

最初に試すなら、次のような読み取り専用の処理が向いています。

サイト名や URL を取得する
公開済みの記事を指定件数だけ取得する
有効化されているテーマやプラグインを確認する
サイトヘルスに必要な環境情報を取得する

読み取り専用であっても、返す情報と実行できる人は絞る必要があります。個人情報、下書き、管理者メールアドレス、サーバー構成などを含む場合は、外部へ公開する範囲を慎重に確認したいところです。

自分で確認できることと相談した方がよいこと

Abilities API の導入を検討する前に、次の点は自分たちでも整理できます。

WordPress のバージョンが6.9以上か
AI や外部ツールへ依頼したい作業は何か
その作業は情報の取得か、サイトの変更か
処理に必要な入力と、受け取りたい結果は何か
誰の権限で実行するのか
失敗した場合に、どのように気づいて戻せるか

一方、次のような場合は、WordPress や認証の仕組みに詳しい制作者へ相談した方が安全です。

独自の Ability をプラグインとして実装したい
REST API や MCP Adapter から外部へ公開したい
記事、ユーザー、注文、サイト設定などを書き換えたい
複数の利用者や AI アプリごとに権限を分けたい
実行履歴や失敗時の復旧方法も含めて運用を設計したい

相談するときは、サイトの URL、WordPress のバージョン、実現したい作業、入力する情報、返してほしい結果、実行する利用者を整理しておくと、必要な仕組みを検討しやすくなります。

オレインデザインでは、AI 連携を前提に機能を増やすのではなく、現在の WordPress 運用と実現したい作業を確認したうえで、Ability の設計や権限、外部接続の必要性を整理しています。Abilities API を使うべきか、従来の方法で十分なのか判断できない場合は、お問い合わせからご相談ください。