AIでWordPress REST APIを文書化する方法

AIは、登録済みのルート、スキーマ、テストからWordPress REST APIのドキュメントを下書きできます。ただし、実行中の実装に照らして検証されていないエンドポイント、権限、副作用、例を創作してはなりません。

ここでAIは、根拠の整理役、比較エンジン、執筆支援として最も有用です。複雑なWordPress作業を検査しやすくできますが、不足している権威を作り出したり、観測していない事実を認証したり、推奨を黙って行為の許可に変えたりはできません。

一文で言えば： AIは、登録済みのルート、スキーマ、テストからWordPress REST APIのドキュメントを下書きできます。ただし、実行中の実装に照らして検証されていないエンドポイント、権限、副作用、例を創作してはなりません。

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

ルート、メソッド、認証、権限コールバック、スキーマ、副作用、エラー、テスト済みの例を説明する、バージョン管理され根拠に裏付けられたAPIドキュメントを構築します。

• ソースと実行時の根拠に結び付いた、ルートとメソッドのインベントリ。
• 必須、条件付き、読み取り専用のフィールドを含む、リクエストとレスポンスのスキーマ。
• 予想される拒否を含む、認証と認可の挙動。
• テスト済みの例、エラーケース、バージョン注記、非推奨の状態。

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

準備する根拠と入力

• 意図した環境から得た、登録済みルートの出力。
• 正確なコミットにおけるコントローラーとコールバックのソース。
• スキーマ、権限コールバック、capability要件。
• 統合テストと、編集済みのリクエスト・レスポンスfixture。
• バージョニング、非推奨化、後方互換性に関する方針。

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

「これをレビューして」「これを修正して」「もっと良くして」といった広範な依頼から始めてはいけません。作業が支えるべき決定、含める母集団、各フィールドの権威ある情報源、許可された操作、禁止されたままの行為を定義してください。このタスクには、認証済みのWordPressアクセスまたは管理されたエクスポートが必要です。

発見と文書化は異なります

ルートは、完全なスキーマ、有用な例、明確な副作用の文書なしに登録される場合があります。実行時の発見は入力であり、完成したリファレンスではありません。

認証は認可ではありません

有効なアプリケーションパスワードはユーザーを識別しますが、各エンドポイントには依然として、行為とオブジェクトに適した権限判断が必要です。

例は実行可能な主張です

コピーされたリクエストは、メソッド、パス、フィールド、レスポンスが現行であることを意味します。例はテストから生成するか、テストによって検証する必要があります。

観測、推論、権威を分離する

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

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

AIの出力は通常、最初の状態群から始まります。詳細で、内部的に一貫し、技術的に説得力があるだけでは、許可済みにはなりません。この区別を表、レポート、チケット、公開ケーススタディで維持してください。

安全なワークフロー

1. プラグインまたはアプリケーションのバージョンと対象環境を固定します。
2. ルートの発見、ソース定義、スキーマ、テストを収集します。
3. 名前空間、パス、メソッド、バージョンごとにエンドポイントを正規化します。
4. 明示的な根拠参照と不明点を含めてドキュメントを下書きするようAIに依頼します。
5. 認証、権限、バリデーション、副作用に関するすべての記述を検証します。
6. 分離したfixtureに対して例を実行し、機微な値を編集します。
7. 開発者の使いやすさ、エラーガイダンス、後方互換性をレビューします。
8. バージョン管理されたリファレンスを公開し、リリースCIで再テストします。

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

プロンプトのレシピ

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

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

目的：
ルート、メソッド、認証、権限コールバック、スキーマ、副作用、エラー、テスト済みの例を説明する、バージョン管理され根拠に裏付けられたAPIドキュメントを構築します。

次のフィールドを返してください：
- 名前空間
- ルート
- メソッド
- 目的
- 認証
- 権限
- 引数
- スキーマ
- 副作用
- 成功レスポンス
- エラーレスポンス
- テストfixture
- バージョン

ルール：
1. ルート、フィールド、capability、ステータスコードを創作しないでください。
2. 認証とエンドポイントの認可を分離してください。
3. 名前空間、メソッド、フィールド、enumのトークンを正確に保持してください。
4. 安全なfixtureから生成された、編集済みの例を使用してください。
5. 本番の書き込みエンドポイントを呼び出さないでください。

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

このプロンプトがこの構造である理由

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

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

推奨アクセス境界

このガイドで説明する段階には Read Only を使用してください。IDに利用可能な正確なcapabilityは、インストール済み製品バージョン、公開済みカバレッジ契約、実際に使われる接続方法から得る必要があります。

このタスクの対象外にするもの

• 本番リクエスト
• 秘密情報の露出
• 捏造した例
• 権限の一般化
• 文書化されていない破壊的変更

拒否された行為は、制御境界が機能している有用な根拠になり得ます。予想された拒否に対し、広範な管理者アカウントやFull Powerを付与して対応してはいけません。まず、その行為が現在の委任に属するかを判断してください。属する場合は、必要最小限のcapabilityによる、別途承認済みの段階を作成します。

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、fixture、機微な根拠は、タスク後に取り消し、リセット、または廃棄されます。

よくある失敗モード

• ソースのみのドキュメント： 条件付き登録または実行時フィルターにより、デプロイ済みのルート集合がアシスタントが読んだコードと異なります。
• 成功時のみの例： 利用者はバリデーション、認可、競合のレスポンスについて何も学べません。
• 管理者イコール許可済み： リファレンスが実際の権限コールバックではなく、広範なロールの想定を記述します。
• 古い生成リファレンス： ドキュメントがCIと結び付いておらず、リリース済みパッケージから乖離します。

繰り返し起きる横断的な失敗は 権限ドリフト です。最初のタスクが制限に遭遇し、欠けている操作が必要、サポート済み、安全のいずれであるかを判断する前に、運用者がアクセスを広げます。これにより拒否の証拠価値が失われ、その後の結果を帰属させにくくなります。

発展的な注記

登録済みルート、スキーマ、実行済み契約テストを組み合わせた、バージョン管理された中間表現からドキュメントを生成してください。人間が作成した説明は、エンドポイントの事実に関する第二の権威になることなく、リファレンスを補強できます。

関連ガイド

• AI エージェント向け WordPress 権限テストマトリクスの作成方法
• AI で WordPress プラグインコードをレビューする方法
• AIワークフローのためのWordPress Abilities APIガイド
• カスタムWordPress AbilityをMCP経由で公開する方法

次の手順

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