AIワークフローのためのWordPress Abilities APIガイド

WordPress Abilities APIは、検出可能で型付けされた機能を公開できますが、各abilityには依然として正確なメタデータ、権限コールバック、入力検証、出力処理、実行が公開済み契約と一致するという証拠が必要です。

ここでAIが最も役立つのは、証拠の整理者、比較エンジン、下書きアシスタントとしてです。複雑なWordPressタスクを検査しやすくできますが、不足している権限を作り出したり、観測していない事実を証明したり、推奨を黙って実行許可に変換したりはできません。

一文で言うと: WordPress Abilities APIは、検出可能で型付けされた機能を公開できますが、各abilityには依然として正確なメタデータ、権限コールバック、入力検証、出力処理、実行が公開済み契約と一致するという証拠が必要です。

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

WordPressのabilitiesをAIクライアントやリモート実行レイヤーに公開する前に、登録、検出、テストを安全に行うための経路を説明し文書化します。

• ability定義、その実行コールバック、認可ロジックの明確な区別。
• メタデータ、スキーマ、注釈、REST公開のための登録チェックリスト。
• 権限とネガティブテストのマトリクス。
• クライアントとメンテナーのためのバージョン管理された契約。

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

準備する証拠と入力

• 現在のWordPress Abilities APIドキュメントと対象バージョン。
• ビジネスアクションと権威ある権限ルール。
• 安全なフィクスチャを伴う入力および出力スキーマ。
• 予想される副作用、失敗モード、可観測性要件。
• abilityを検出または実行するクライアントまたはアダプター。

アシスタントに証拠を渡す前に、認証情報、秘密値、関係のない個人情報を除去してください。残った情報を解釈するために必要な識別子、バージョン、タイムスタンプ、ロケール、単位、ソースラベルは保持します。URL、状態、日付のないスクリーンショットは有用な文脈になり得ますが、本番判断に十分な権限となることはほとんどありません。

「これをレビューして」「これを修正して」「もっと良くして」のような広範な依頼から始めないでください。作業が支えるべき判断、含まれる母集団、各フィールドの権威あるソース、許可された操作、禁止のままとする操作を定義します。計画または調査段階では、ローカルリポジトリ、隔離されたフィクスチャ、またはエクスポート済み証拠を使用する必要があり、本番WordPressアクセスは不要です。

abilityは契約であり、プロンプトではありません

その名前、説明、スキーマ、注釈、コールバックは、機械から呼び出し可能な操作を定義します。自然言語の明確さは重要ですが、実行可能な検証と権限チェックは引き続き権威を持ちます。

検出可能であっても、誰でも実行できるわけではありません

メタデータを一覧表示することとabilityを実行することは別の操作です。認可は実行境界で強制する必要があります。

注釈は過度に約束してはなりません

読み取り専用の動作、破壊的な影響、冪等性に関する主張は、意図だけでなくテスト済みの実装を反映する必要があります。

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

管理されたレビューでは、少なくとも次の四つの状態を区別する必要があります。

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

AIの出力は通常、最初の三つの状態で始まります。詳細であり、内部的に整合し、技術的に説得力があるというだけで承認済みにはなりません。この区別を表、レポート、チケット、公開ケーススタディで保持してください。

安全なワークフロー

1. 狭いビジネス機能とその説明責任を負う所有者を定義します。
2. 安定した命名、説明、入力スキーマ、出力スキーマ、副作用を指定します。
3. 明示的な権限コールバックと検証コールバックを実装します。
4. サポートされるライフサイクルと環境でabilityを登録します。
5. 検出、有効な実行、無効な入力、未認可の実行をテストします。
6. RESTまたはMCP公開が適切でサポートされているかをレビューします。
7. バージョン管理、エラー、可観測性、ロールバック動作を文書化します。
8. 契約とネガティブテストに合格してからのみabilityを公開します。

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

プロンプトのレシピ

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

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

目的:
WordPressのabilitiesをAIクライアントやリモート実行レイヤーに公開する前に、登録、検出、テストを安全に行うための経路を説明し文書化してください。

次のフィールドを返してください:
- ability名
- 目的
- 入力スキーマ
- 出力スキーマ
- 権限コールバック
- 副作用
- 注釈
- 有効なフィクスチャ
- 無効なフィクスチャ
- 未認可のフィクスチャ
- バージョン
- 所有者

ルール:
1. 現在の公式API名とシグネチャを使用してください。
2. 広範なキャッチオールabilityを登録しないでください。
3. 明示的な権限コールバックと入力検証を要求してください。
4. 実際の動作に対して説明と注釈をテストしてください。
5. 仮定によってabilityをRESTまたはMCPに公開しないでください。

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

このプロンプトがこのように構造化されている理由

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

本番実装では、JSON schema、型付きツール入力、自動検証を追加する場合があります。これらの仕組みは一貫性を高めますが、ソース証拠が真実で完全かつ最新であることを確定するものではありません。人間によるレビューとシステム固有の検証は引き続き必要です。

推奨アクセス境界

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

このタスクの外に置くべきもの

• 本番でのability登録
• 広範な管理機能
• 権限のバイパス
• 未検証のスキーマ変更
• 普遍的なクライアント互換性の主張

拒否されたアクションは、制御境界が機能している有用な証拠になり得ます。予期された拒否に対し、広範な管理者アカウントやFull Powerを付与して応答しないでください。まず、そのアクションが現在の委任範囲にそもそも属するかどうかを判断します。属する場合は、必要最小限の機能を備えた、個別に承認された段階を作成してください。

WP Agent Controlの位置付け

Claude Code や Codex 向けのガイド付きプライベートフォルダーは、WordPress REST、アプリケーションパスワード、専用の読み取り専用プロファイルを使用します。既存の Read Only、Draft、Content Editor、Publisher は高度な設定に残ります。OAuth に自動変換されず、リモート接続の一時タスクや厳密な承認モデルも引き継ぎません。

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

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

検証チェックリスト

• ☐ タスク、母集団、期間、環境、判断が明示されています。
• ☐ 重要な各観測は正確な証拠にリンクされているか、仮説としてラベル付けされています。
• ☐ 安定ID、URL、バージョン、日付、単位、ロケール、分母が保持されています。
• ☐ 不足している証拠とカバレッジの限界が可視のままです。
• ☐ 分析または調査用IDは、禁止された変更を実行していません。
• ☐ 該当する場合、資格を持つ所有者がセキュリティ、アクセシビリティ、法務、コマース、リリースへの影響をレビューしました。
• ☐ どの実装にも、別個の委任、アクセスレベル、バックアップ、検証計画があります。
• ☐ 一時ID、フィクスチャ、機密証拠は、タスク後に取り消し、リセット、または廃棄されます。

よくある失敗モード

• プロンプト形状のability: 一つの広範な操作が任意の指示を受け入れ、明示的な機能設計を回避します。
• メタデータによる認可: abilityの説明は制限付きとしていますが、実行コールバックがその制限を強制しません。
• スキーマドリフト: 実装が、公開済み契約に記載されていないフィールドを受け入れるか返します。
• 読み取り専用ラベルの誤り: 読み取り専用と注釈されたabilityが、隠れた書き込み、キャッシュ、メール、外部呼び出しを引き起こします。

繰り返し発生する横断的な失敗は 権限ドリフト です。初期タスクが制限に遭遇し、オペレーターが不足している操作が必要、サポート済み、安全かを判断する前にアクセスを拡大します。これにより拒否の証拠価値が失われ、後の結果の帰属が困難になります。

高度な注記

管理されたアーキテクチャでは、abilitiesは、メタデータ、権限、副作用がトランスポートから独立してバージョン管理される許容可能な操作です。RESTまたはMCPは同じabilityを投影できますが、どちらのトランスポートもその権限を拡大できません。

関連ガイド

• カスタムWordPress AbilityをMCP経由で公開する方法
• AI エージェント向け WordPress 権限テストマトリクスの作成方法
• AIでWordPress REST APIを文書化する方法
• AI を使った WordPress テスト計画の作成方法

次のステップ

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