WordPressタスクのREST対MCP：統制されたベンチマーク・プロトコル

REST対MCPのベンチマークでは、移送の利便性を権限、正確性、製品カバレッジと混同せず、対応するIDとタスクの下で等価なWordPress機能を比較する必要があります。

ここでAIは、証拠の整理者、比較エンジン、草案作成支援として最も有用です。複雑なWordPressタスクを検査しやすくできますが、欠けた権限を作り出したり、観測していない事実を証明したり、推奨を黙って実行権限に変換したりはできません。

要約： REST対MCPのベンチマークでは、移送の利便性を権限、正確性、製品カバレッジと混同せず、対応するIDとタスクの下で等価なWordPress機能を比較する必要があります。

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

基礎となるWordPress権限を一定に保ちながら、直接RESTとMCP仲介ワークフローが、発見、設定、実行、証拠、エラー処理、人の労力でどのように異なるかを測定します。

• RESTエンドポイントと、MCPが公開するAbilitiesまたはツールの等価性マップ。
• 同一のWordPress IDとfixtureを使用する対応タスク群。
• 設定、発見、実行、正確性、拒否、可観測性の指標。
• 移送に関する所見を、クライアントとAbilityの実装効果から分離するレポート。

完成物は、意思決定の責任者が理解でき、元のプロンプトに参加していない人が再現できなければなりません。流暢な回答だけでは不十分です。重要な結論には、ソース、範囲、検証経路が必要です。証拠で何かを確立できないとき、正しい出力は明示的な未知または検証可能な仮説です。

準備する証拠と入力

• 正確なRESTルート、Abilities、アダプター、クライアントのバージョン。
• 対応する認証および権限プロファイル。
• 安定したオブジェクトを備えたリセット可能なWordPress fixture。
• タスクブリーフと期待する状態遷移。
• リクエスト、ツール呼び出し、WordPress差分を取得する仕組み。

アシスタントに証拠を渡す前に、資格情報、秘密値、無関係な個人情報を除去します。残った情報を解釈するために必要なID、バージョン、タイムスタンプ、ロケール、単位、ソースラベルは保持します。URL、状態、日付のないスクリーンショットは有用な文脈になることがありますが、本番の意思決定に十分な根拠となることはまれです。

「これをレビューして」「これを直して」「もっと良くして」のような広い依頼から始めないでください。作業が支えるべき意思決定、対象集団、各フィールドの権威あるソース、許可される操作、禁止されたままのアクションを定義します。計画または調査段階では、ローカルリポジトリ、分離されたfixture、またはエクスポート済み証拠を使用し、本番WordPressへのアクセスを必要としません。

RESTとMCPは競合する権限ではない

どちらの経路も、最終的にはWordPressの認可と公開された操作に依存します。基礎となる操作が異なる場合、ベンチマークは能力差を移送に帰属させてはなりません。

発見は実際の成果である

MCPはクライアントによるツールとスキーマの発見を助けられますが、RESTでは明示的なエンドポイント知識が必要になることがあります。これを実行の正確性と分けて測定します。

エラーには意味的マッピングが必要

HTTP状態、ツールエラー、クライアント要約は、同じ基礎的な拒否を異なる形で表すことがあります。使いやすさを比較する前に生の証拠を保存します。

観測、推論、権限を分けて保持する

統制されたレビューでは、少なくとも次の状態を区別します。

1. 観測済み： 名前付きレコード、ファイル、応答、レンダリング済みページ、実行済みテストに直接存在するもの。
2. 推論： 証拠で支持されるが、直接確立されていないもっともらしい解釈。
3. 推奨： 提案された人間の意思決定または次のアクション。
4. 承認済みかつ検証済み： 個別に承認され、実行後に受入基準で確認された変更。

AIの出力は通常、最初の状態群で始まります。詳細で、内部的に一貫し、技術的に説得力があるだけで承認済みになるわけではありません。この区別を表、レポート、チケット、公開事例で維持します。

安全なワークフロー

1. 等価な操作を定義し、テスト前に非等価性を記録します。
2. 対応するID、データfixture、リセット手順を設定します。
3. タスク、指標、反復、許可された介入を事前登録します。
4. RESTとMCPの条件をランダムな順序で実行します。
5. 設定アクション、発見、リクエスト、ツール呼び出し、応答、WordPress状態、拒否を取得します。
6. 移送に依存しないassertionで結果を検証します。
7. 差異を移送、クライアント、Ability、権限、実装の効果として分類します。
8. プロトコル、サニタイズ済みの生アーティファクト、制約、バージョン範囲を公開します。

この順序は、分析と実装の間に意図的に説明責任を伴うレビューを置きます。後段でより広いアクセスが必要なら、新しいタスク、新しいID、または明示的な権限変更を作成してください。正しい境界に達したからといって、分析用IDを密かに昇格させてはなりません。

プロンプトの書式

プロンプトを使用する前に、角括弧内のすべての値を置き換えます。パスワード、APIキー、認証cookie、非公開の顧客レコード、無関係な個人情報を貼り付けないでください。

提供された証拠のみを用いて、[SITE, REPOSITORY OR DATASET] の [TASK SCOPE] をレビューしています。

目的：
基礎となるWordPress権限を一定に保ちながら、直接RESTとMCP仲介ワークフローが、発見、設定、実行、証拠、エラー処理、人の労力でどのように異なるかを測定します。

次のフィールドを返してください：
- 実行ID
- 移送
- クライアント
- 操作
- ID
- 設定アクション
- 発見結果
- 実行結果
- 生エラー
- 状態差分
- 検証
- 人の介入
- 時間
- 失敗クラス

ルール：
1. 等価な操作と同一のIDを使用します。
2. サニタイズ後も生のHTTPまたはツール証拠を保持します。
3. クライアントの表現を基礎的な権限結果として扱いません。
4. 非等価なカバレッジを明示的に報告します。
5. テストしたバージョンとタスクを超えて一般化しません。

各所見について：
- 正確なソース、レコード、URL、ファイル、行、オブジェクトID、状態、データセット行を特定します；
- 日付、バージョン、単位、ロケール、ID、分母を保持します；
- 観測、推論、推奨、未知を分離します；
- 利用できなかった証拠を示します；
- WordPress、ソースコード、コマースデータ、分析、外部システム、公開済みコンテンツを変更しません。

このプロンプトをこの構造にした理由

このプロンプトは、推奨を求める前に証拠契約を作成します。不足データを可視化し、モデルが不完全なレコードをもっともらしい文章で補完する可能性を減らし、体系的にレビューできる出力を生成します。構造化フィールドにより、反復実行の比較や、承認済み部分を後続の実装ワークフローへ渡すことも容易になります。

本番実装ではJSON schema、型付けされたツール入力、自動検証を追加できます。これらは一貫性を改善しますが、ソース証拠が真実、完全、最新であることを確立しません。人によるレビューとシステム固有の検証は引き続き必要です。

推奨アクセス境界

このガイドで説明する段階では、計画または調査段階の間はWordPressにアクセスしないでください。IDで利用できる正確な能力は、インストール済み製品バージョン、公開済みカバレッジ契約、実際に使われる接続方法に基づく必要があります。

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

• 捏造された結果
• 移送のためのより広いID
• 異なるタスク定義
• 本番テスト
• ある移送が普遍的に安全だという主張

拒否されたアクションは、制御境界が機能している有用な証拠になり得ます。予想される拒否に対して、広い管理者アカウントやFull Powerを与えて応答してはいけません。まず、そのアクションが現在の委任範囲に属するかを判断します。属するなら、必要最小の能力を持つ個別承認の段階を作成します。

WP Agent Controlの位置付け

WP Agent Controlは、インストール済みバージョンが実際にサポートする段階のために、専用WordPress IDと限定された権限プロファイルを提供できます。

WP Agent Controlは、統制されたWordPress IDと権限のレイヤーです。AIモデルでも、汎用MCPサーバーでも、すべてのアシスタント、クライアント、移送がすべてのWordPress表面に到達できる証拠でもありません。アシスタント、クライアント、移送、WordPress ID、タスク権限、人間の承認は別々のレイヤーです。

Full Powerは個別の管理例外です。Read Only、Draft、Content Editor、Publisherの通常の継続として提示してはならず、正しい拒否の後で例、ベンチマーク、ワークフローを成功させるためだけに使用してはなりません。

検証チェックリスト

• ☐ タスク、母集団、期間、環境、意思決定が明示されている。
• ☐ 重要な観測はすべて正確な証拠に結び付くか、仮説としてラベル付けされている。
• ☐ 安定したID、URL、バージョン、日付、単位、ロケール、分母が保持されている。
• ☐ 不足する証拠とカバレッジの限界が見えるままである。
• ☐ 分析または調査用IDは、禁止された変更を行っていない。
• ☐ 該当する場合、適格な責任者がセキュリティ、アクセシビリティ、法務、コマース、リリースへの影響をレビューした。
• ☐ あらゆる実装には、別の委任、アクセスレベル、バックアップ、検証計画がある。
• ☐ 一時ID、fixture、機密証拠はタスク後に取り消し、リセット、または廃棄される。

よくある失敗モード

• 能力の不一致： MCPは厳選されたAbilityを公開する一方、RESTはより広い、または異なるエンドポイントを使用する。
• クライアントの交絡： 移送がモデルまたはクライアントUIと同時に変更される。
• 設定時間の省略： 実行レイテンシだけを比較し、発見や設定の負担が消える。
• エラーの平坦化： 異なる認証、認可、検証の失敗が失敗種別としてまとめて採点される。

繰り返される横断的失敗は、権限のドリフトです。初期タスクが制限に達すると、オペレーターが、欠けた操作が必要、サポート済み、安全かを判断する前にアクセスを広げます。これにより拒否の証拠価値が破壊され、後の結果の帰属が困難になります。

研究状況と公開ゲート

このページはプロトコルを定義しており、完了した研究ではありません。ベンチマーク値、プロバイダー順位、成功率、実証的結論を含みません。リポジトリに対応するバージョン付き実行アーティファクトもある場合を除き、Codexは提案指標を所見へ変換したり、グラフを合成値で埋めたり、名前付きアシスタント、移送、製品バージョンがテストされたと示唆したりしてはなりません。

公開前に、この研究には事前登録プロトコル、固定fixture、承認済み予算、反復実行、決定論的検証、レビュー担当者規則、サニタイズ済み証拠パッケージが必要です。あらゆる結果は、分子、分母、欠けた実行、正確なバージョンセット、不確実性を述べなければなりません。後のモデル、クライアント、WordPressリリース、権限プロファイルは別の処置であり、以前の結論を自動継承すべきではありません。

上級者向けの注記

最も有用な出力は勝者ではなく意思決定マトリックスかもしれません。移送の選択は、発見ニーズ、クライアント互換性、操作設計、監査証拠、組織上の制約に依存し得ます。

関連ガイド

• WordPress REST APIとMCP: どちらを使うべきか
• カスタムWordPress AbilityをMCP経由で公開する方法
• AI エージェント向け WordPress 権限テストマトリクスの作成方法
• WordPress AIタスクのカバレッジマトリクスを構築する方法

次のステップ

認証済みタスクの前に、最も関連性の高い補助ガイドへ進み、アクセスレベルガイドを使用してください。一時的なWordPressアクセスが不要になったら、IDを取り消して完了します。