AI を使った WordPress テスト計画の作成方法

AI は WordPress のテストケースの列挙に役立ちますが、計画は一般的なベストプラクティスの一覧ではなく、要件、コードパス、サポート対象バージョン、ユーザー状態、既知のリスクから導き出す必要があります。

AI は、証拠の整理役、比較エンジン、草案作成アシスタントとして最も有用です。複雑な WordPress タスクを調査しやすくできますが、欠落した権限を作り出したり、観察していない事実を認定したり、推奨を行動の許可へと暗黙に変換したりはできません。

一文で言うと： AI は WordPress のテストケースの列挙に役立ちますが、計画は一般的なベストプラクティスの一覧ではなく、要件、コードパス、サポート対象バージョン、ユーザー状態、既知のリスクから導き出す必要があります。

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

すべての重要な挙動とリスクを、fixture、手順、期待結果、環境、証拠に結び付ける追跡可能なテスト計画を作成します。

• 要件からテストへのトレーサビリティマトリクス。
• ユニット、統合、API、ブラウザー、アクセシビリティ、アップグレード、ロールバックのカバレッジ。
• サポート対象バージョンと環境のマトリクス。
• 開始、終了、失敗、証拠保持の基準。

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

準備する証拠と入力

• 承認済みの要件と受け入れ基準。
• アーキテクチャ、コードパス、権限、データへの影響。
• サポート対象の WordPress、PHP、ブラウザー、依存関係のバージョン。
• 既知のインシデント、リグレッション、リリースリスク。
• 既存の自動および手動テストスイート。

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

「これをレビューして」「これを修正して」「もっと良くして」といった広範な依頼から始めないでください。作業が支えるべき意思決定、含まれる対象集団、各フィールドで権威を持つ情報源、許可される操作、禁止されたままの操作を定義してください。計画または調査の段階では、ローカルリポジトリ、隔離した fixture、またはエクスポートした証拠を使用し、本番 WordPress へのアクセスは不要です。

テスト数はカバレッジではない

多くの反復的なケースがあっても、重要な権限、移行、失敗、ユーザー状態が未テストのままになる可能性があります。カバレッジは要件とリスクに対応付ける必要があります。

期待結果は観察可能でなければならない

「正しく動作する」と記すテストでは、防御可能な合格または失敗を出せません。期待する WordPress オブジェクト、応答、レンダリング状態、または拒否を明記してください。

ネガティブテストは境界を証明する

制御された AI ワークフローでは、許可された操作と、それに対応する禁止操作の両方に証拠が必要です。

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

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

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

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

安全なワークフロー

1. 要件、バージョン、リリースのスコープを確定する。
2. ユーザージャーニー、入口、権限、データ書き込み、失敗状態をマッピングする。
3. AI に特定の要件とリスクに紐付くテストの提案を依頼する。
4. 各テストを、レイヤー、fixture、環境、自動化の適性で分類する。
5. 開発者、プロダクトオーナー、アクセシビリティレビュー担当者とともに、欠けているエッジケースをレビューする。
6. 別の承認済みブランチでテストを実装または更新する。
7. サポート対象マトリクスで計画を実行し、生の証拠を保持する。
8. 失敗、判断、再実行、最終的なリリース決定を記録する。

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

プロンプトのレシピ

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

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

目的：
すべての重要な挙動とリスクを、fixture、手順、期待結果、環境、証拠に結び付ける追跡可能なテスト計画を作成してください。

次のフィールドを返してください：
- 要件 ID
- リスク
- テスト ID
- レイヤー
- Fixture
- 前提条件
- 手順
- 期待結果
- 禁止結果
- 環境
- 証拠
- 所有者

ルール：
1. 各テストを要件、リスク、または再現された欠陥に結び付ける。
2. 正確なバージョンと fixture 識別子を保持する。
3. 権限拒否と失敗からの回復を含める。
4. 実行可能なカバレッジが存在するまで、テストを自動化済みとマークしない。
5. 本番環境に対して破壊的テストを実行しない。

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

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

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

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

推奨アクセス境界

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

このタスクの対象外でなければならないこと

• 本番環境での破壊的テスト
• 捏造された合格結果
• 非サポートバージョンに関する主張
• 自動的なリリース承認
• スイートをグリーンにするためのテスト削除

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

WP Agent Control の位置付け

これはWordPressの一般的な作業手順であり、Agent Controlがここで扱うすべての対象や連携機能を編集できるという意味ではありません。ガイド付き手順では、まず公開ページから始めます。プラグイン、テーマ、ユーザー、設定、ファイル、削除、WooCommerce、ACF、ページビルダーの操作は、標準のガイド付きタスクではありません。必要に応じて、別途検証されたツールと権限を使ってください。

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

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

検証チェックリスト

• ☐ タスク、対象集団、期間、環境、意思決定が明示されている。
• ☐ すべての重要な観察は正確な証拠に結び付けられているか、仮説としてラベル付けされている。
• ☐ 安定した ID、URL、バージョン、日付、単位、ロケール、分母が保持されている。
• ☐ 不足している証拠とカバレッジの制限が可視のままである。
• ☐ 分析または調査用アイデンティティが禁止された変更を実行していない。
• ☐ 該当する場合、資格を持つ所有者がセキュリティ、アクセシビリティ、法務、コマース、リリースへの影響をレビューした。
• ☐ すべての実装には、別個の委任、アクセスレベル、バックアップ、検証計画がある。
• ☐ 一時的なアイデンティティ、fixture、機微な証拠は、タスク完了後に失効、リセット、または廃棄される。

一般的な失敗モード

• 一般的なチェックリスト生成： 計画は包括的に見えるものの、実際の製品挙動に結び付いていない。
• ハッピーパスの優位： 成功した許可済みリクエストのみがテストされ、拒否、部分的な失敗、ロールバックがない。
• マトリクスの圧縮： 一つの環境が、サポート対象のすべての WordPress および PHP バージョンを代表するものとして扱われる。
• 証拠の喪失： レビュー可能なログ、スクリーンショット、アサーション、成果物なしに合格が記録される。

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

高度な注記

成熟したテストシステムは、要件、テスト、fixture、実行、証拠を、別個にバージョン管理されたオブジェクトとして扱います。AI は見落とされた境界の特定に役立ちますが、テストを提案済みから合格済みに変えられるのは、実行された成果物だけです。

関連ガイド

• AI エージェント向け WordPress 権限テストマトリクスの作成方法
• AI で WordPress リリースパッケージをレビューする方法
• ステージングまたは Playground で WordPress AI ワークフローをテストする方法
• AI を使ってロールバック可能な WordPress 変更計画を準備する方法

次のステップ

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