公式 WordPress MCP アダプターの仕組み

公式 WordPress MCP アダプターは、WordPress Abilities を、互換性のある AI クライアントが検出できる MCP ツールまたはリソースへ変換します。Ability は、名前付きの機能単位であり、型付きの入力、出力、実行 callback、権限 callback を定義します。アダプターがすべての WordPress アクションを自動的に公開するわけではありません。

実際に利用できるツールは、登録済み Abilities とアダプターの設定に依存します。権限 callback と認証済み WordPress ユーザーは引き続き不可欠です。

一文で言うと: このアダプターは、明示的に登録された WordPress Abilities を MCP プリミティブに変換しつつ、WordPress 側の権限チェックを維持します。

このガイドで達成できること

このガイドは、WordPress コアが現在公開している内容を過大に主張せず、上級読者が公式アダプターを評価またはテストできるようにします。また、統合チュートリアルを公開する前にサイトが収集すべき証拠も定義します。

有用な AI ワークフローは、回答の品質だけで決まるものではありません。アシスタントが到達できるデータ、実行を許可された操作、その後に確認できる証拠、アクセスを容易に取り消せることによっても決まります。

重要な理由

Abilities API は、検出可能な操作の標準化されたレジストリを WordPress に提供します。その後、MCP アダプターがそれらの操作をエージェントクライアントに公開できます。このアーキテクチャは、プラグインの機能ごとに個別で文書化されていないツールを発明するより堅牢です。

ただし、アダプターが存在するからといって、サイトに完全な AI 管理 API があることにはなりません。表示されるのは登録・設定済みの Abilities だけであり、その成熟度は WordPress のバージョンごとに変わります。

期待される出力

正常な実行では、次の結果が得られるはずです。

  • 登録済み WordPress Abilities の一覧。
  • Abilities から公開済み MCP ツールまたはリソースへの対応表。
  • 権限 callback と認証済み ID の記録。
  • クライアント側の検出および実行テスト。
  • 希望するタスクと利用可能な Abilities の差分一覧。

ソースレイヤーとしての Abilities

各 Ability には、一意の識別子、説明的なメタデータ、入力・出力スキーマ、実行 callback、権限 callback があります。WordPress は設定時に、選択した Abilities を REST 経由で公開できます。アダプターは任意の関数をスクレイピングするのではなく、これらの宣言済み単位を MCP にマッピングします。

アダプターの既定の動作

公式ドキュメントでは、Abilities を検出し、Ability 情報を取得し、Ability を実行するための既定サーバーとツールが説明されています。Abilities はアダプターで明示的に利用可能にする必要があります。公開にあたって、登録済みのすべての Ability が公開されると想定してはなりません。

既定値は変化する可能性があるため、

権限と ID

Ability の権限 callback は、認証済みユーザーと関連するコンテキストを評価する必要があります。MCP レイヤーがそのチェックを回避してはなりません。有用なテストでは、異なる機能を持つ二つの ID で認証し、同じツール呼び出しで異なる認可結果になることを確認します。

開発とデバッグ

WP-CLI Ability コマンドまたは REST インターフェースを使い、MCP クライアントから独立して Abilities の一覧表示、調査、検証、実行を行います。これにより、障害が Ability 登録、WordPress 認可、アダプターのマッピング、トランスポート、クライアント動作のどこに属するかを切り分けられます。

安全なワークフロー

  1. サポート対象バージョンを実行する使い捨ての WordPress 環境を作成します。
  2. 現在の公式 MCP アダプターを、その一次リリースソースからインストールします。
  3. 登録済み Abilities を一覧表示し、スキーマと権限 callback を記録します。
  4. テストサーバーに必要な Abilities だけを設定します。
  5. 専用かつ制限された WordPress ID で認証します。
  6. サポート対象のクライアントを一つ接続し、検出されたツールを調査します。
  7. 既知の読み取り専用 Ability と、拒否される Ability を実行します。
  8. すべてのバージョン、スキーマ、結果、クリーンアップ手順を記録します。

推奨アクセス境界

適切なレベルは要求された操作に依存します。接続なしまたは Read Only から始め、下位レベルで安全に完了できない場合にのみ Draft または Content Editor へ進みます。

このワークフローは編集上の判断に影響したり、未公開の変更を作成したりする可能性があります。対象範囲を狭く保ち、提案された変更をすべてレビューしてください。

アクセスレベルは出発点となる推奨であり、普遍的な権利ではありません。ID に利用可能な正確な WordPress 機能は、この記事だけではなく、インストール済み製品バージョンと公開されているカバレッジに基づく必要があります。

タスクの対象外にすべきこと

  • テストしたバージョンが実際にそうしていない限り、WordPress コアが広範なコンテンツ管理 Abilities を公開すると示唆しないでください。
  • 意味のある権限 callback なしに Ability を登録しないでください。
  • 最初の統合テスト中に、破壊的なカスタム Abilities を公開しないでください。
  • 古いリリースからコピーしたコマンドを、再現なしに公開しないでください。

WP Agent Control の位置付け

接続後は、サイトの構造化情報を取得し、選択した公開ページを調べられます。この公開情報の読み取りに一時タスクは不要です。公開ページはプラグインなしでも閲覧できます。Agent Control は構造化されたアクセスと、その先の許可された WordPress 作業への流れを提供します。

下書きタスクを許可し、必要な参照コンテンツを選択します。アシスタントが作成・修正できるのは、そのタスクで新しく作った下書きです。既存の参照資料は、それ自体が下書きでも読み取り専用のままです。結果を WordPress で確認してください。

Solo、Pro、Agency で、対象コンテンツとフィールドを選んだ提案タスクを許可します。WordPress で完全な差分を確認し、承認する提案を選択してください。承認は対象、フィールド、現在の内容に結び付いており、元データやタスクが変わると無効になる場合があります。 内容の変更を承認しても、公開の許可にはなりません。Solo、Pro、Agency で、有効な承認を対象とする公開タスクも必要です。公開された結果はご自身で確認してください。

AI を接続する: docs first profile · 機能と対応環境を見る: coverage

検証チェックリスト

  • WordPress、アダプター、クライアントのバージョンを記録しています。
  • 登録済みと公開済みの Abilities を個別に棚卸ししています。
  • 権限 callback を調査しています。
  • 制限された ID を使用しています。
  • Ability の直接実行と MCP 実行の両方をテストしています。
  • ガイドが、利用不可または実験的な動作を特定しています。

よくある失敗モード

  • コアのカバレッジを前提にする: インフラの利用可能性を、本番対応 Abilities の幅広いライブラリと混同します。
  • エージェント経由だけでデバッグする: 障害を WordPress、アダプター、クライアントの各レイヤー間で特定できません。
  • 弱い権限 callback: Ability スキーマは正確でも、権限が正確ではありません。
  • 変動する対象を公開する: 実験的またはバージョン固有の動作を、普遍的なものとして提示します。

上級者向けの注記

将来の最も強力な統合では、Abilities を意味論的識別子、スキーマ互換性チェック、テストフィクスチャを備えた、ガバナンスされたバージョン管理インターフェースとして扱います。その場合 MCP は、独立した真実のソースではなく、その権限レイヤーの投影になります。

関連ガイド

続ける

次の手順: AIにどのWordPressアクセスレベルを与えるべきですか? を開き、適切な最小のアクセスレベルを選び、関連する接続ガイドに従ってください。個別で取り消し可能な ID を作成する準備ができたら、製品 を確認するか、7 日間の Solo トライアルを開始してください。

情報源と検証

このページは、以下の一次情報源に基づいて確認されています。 情報源の最終確認日: .