2026年のWordPressは、REST APIだけを知っていればAI連携の全体像が分かる状態ではなくなりました。Abilities API、AI Client、MCP Adapterが加わり、「外部からWordPressを操作する」「WordPress内からAIを呼ぶ」「AI AgentへWordPress機能を渡す」が別の仕組みとして整理されています。
このページでは各技術を深掘りしすぎず、何を実現したいときにどの仕組みを見るべきかを整理します。個別実装や安全設計は121〜130の子記事へ分け、Hub自体が同じ説明を重複しない構成にしています。
目的から選ぶ：WordPress×AI/API連携マップ
| やりたいこと | 最初に見る仕組み | 詳しい記事 |
|---|---|---|
| 投稿を取得・draft作成・更新したい | REST API | 122 |
| 外部API認証を分離したい | Application Password | 123 |
| WordPress機能を標準化して公開したい | Abilities API | 125 |
| AI AgentからWordPress toolを使いたい | MCP Adapter + Abilities | 124 / 129 |
| WordPress内部からAI modelを呼びたい | AI Client | 126 |
| 安全に自動化範囲を広げたい | QA / rollback / permission | 127 / 130 |
| 複数サイトを横断管理したい | REST/管理台帳/監視 | 128 |
技術別：WordPressとAI/APIをつなぐ5つの基盤
REST API：外部システムからWordPressのresourceを扱う
REST APIは投稿、メディア、taxonomyなどをHTTPで扱う既存の標準経路です。AIがなくても利用でき、n8nや独自scriptから投稿を取得・作成・更新するときの基本になります。
「毎日記事一覧を取る」「完成済みHTMLをdraftへ入れる」のように処理が決まっているなら、REST APIの方がMCPより単純なことがあります。認証はApplication Password等を使い、対象post ID・status・rollbackを別途設計します。
Application Password：外部連携用の認証を通常ログインから分離する
WordPressの通常パスワードをworkflow toolへ保存する代わりに、連携専用のApplication Passwordを発行できます。1連携1credentialで作れば、不要な連携だけ個別に失効できます。
Application Passwordそのものが権限を決めるわけではなく、紐づくWordPressユーザーのcapabilityにも依存します。HTTPS、secret保管、last used/IP、rotationまで含めて運用します。
Abilities API：WordPressの「できること」をmachine-readableにする
Abilities APIは、機能をname、description、input/output schema、permission付きで登録する共通基盤です。6.9でCoreへ入り、7.1ではpublic flag、validation、execution lifecycleなどが強化されました。
REST APIがresourceへのHTTP accessを中心にするのに対し、Abilitiesは「機能」を中心に定義します。AI/MCPに限らず、同じ機能をPHPやREST等から再利用したい場合にも意味があります。
MCP Adapter：AbilitiesをAI Agentへ橋渡しする
MCP AdapterはWordPressのAbilityをMCP tool/resource/promptとしてAIクライアントへ見せる接続層です。Agentが利用可能なtoolを発見し、状況に応じて呼び分ける用途に向きます。
MCPを使えば安全になるわけではありません。公開対象、transport認証、WordPress認証、Ability permissionを分けて設計し、read-onlyから始めます。
AI Client：WordPress内部からprovider非依存でAIを呼ぶ
AI ClientはWordPress 7.0でCoreへ入ったprovider-agnosticなAI APIです。plugin側がproviderごとのcredential処理やSDK差分を直接抱えず、WordPressの共通層からAI機能を作るための基盤です。
AI Clientは標準チャットUIではなく開発基盤です。7.1ではすべての計画機能が入ったわけではなく、embeddings等は後続へ持ち越されたため、Roadmapとrelease後の実装状態を分けて確認します。
2026年のWordPress AI連携を1枚で整理
| 方向 | 入口 | WordPress側 | 外部/AI側 |
|---|---|---|---|
| 外部 → WordPress | REST API | posts/media等 | n8n、script、アプリ |
| 外部 → WordPress機能 | Abilities REST/MCP | Ability + permission | Agent/MCP client |
| WordPress → AI | AI Client | prompt builder + Connectors | AI provider/model |
| Agent → WordPress → AI | MCP + Ability + AI Client | tool実行とAI呼出を組合せ | AI Agent |
同じ「AI連携」でも方向が違えば必要な仕組みも変わります。WordPressへ完成記事を入れるだけなのにAI Clientを導入する、固定バッチなのにMCPを導入する、といった過剰構成を避けるために、まず矢印の向きを決めます。
検索目的別：121〜130の読み分け
- 121：WordPress運営全体でAI/APIへ任せる範囲を決めたい
- 122：REST APIで投稿取得・draft・更新を実装したい
- 123：Application Passwordの発行・失効・rotationを知りたい
- 124：WordPressとMCP/AI Agentを接続したい
- 125：Abilities APIとREST/MCPの違いを理解したい
- 126：WordPress AI Clientの現在地を知りたい
- 127：誤公開・二重投稿・credential漏えいを防ぎたい
- 128：複数WordPressをまとめて管理したい
- 129：Agentへ任せる仕事と人が残る仕事を決めたい
- 130：何から自動化するか導入順を決めたい
既存TameshiTech記事との役割分担
TameshiTechには既に「AIブログ自動化」「n8n×WordPress」「WordPress連携AIライティング」「AIエージェント基礎」があります。これらは記事制作ツール・workflow・Agentの一般理解が中心です。121〜130では、WordPress本体のAPI/AI基盤と安全な運用設計に検索意図を限定しています。
同じ「自動化」語を含む記事でも、AIブログ自動化は記事制作の工程、n8n記事はworkflow tool、121はWordPress運営全体の境界設計、130は導入順という役割です。内部リンクで補完し、同じ説明を複数記事へコピーしないことでカニバリを抑えます。
迷ったらREST APIのread-onlyから始める
目的がまだ曖昧なら、最初にWordPressの状態をread-onlyで取得するところから始めると失敗しにくくなります。記事一覧や更新日を取るだけなら、公開物へ影響しません。必要なデータと手作業が見えてから、AIやwriteを追加できます。
AI連携は技術を全部入れることがゴールではありません。サイト運営で減らしたい手数、必要な安全性、保守できる複雑さの範囲から逆算し、不要な層は使わない方が長く運用できます。
公式情報・参考資料
仕様確認日：2026年9月30日。実装時はリンク先の最新版も確認してください。
- https://developer.wordpress.org/rest-api/
- https://developer.wordpress.org/apis/abilities-api/
- https://developer.wordpress.org/news/2026/02/from-abilities-to-ai-agents-introducing-the-wordpress-mcp-adapter/
- https://make.wordpress.org/core/2026/03/24/introducing-the-ai-client-in-wordpress-7-0/
- https://make.wordpress.org/core/2026/08/05/wordpress-7-1-field-guide/
コメント