AIを使ってWordPress向けWCAG改善ブリーフを準備する方法

AIはアクセシビリティに関する所見をWordPress改善ブリーフに整理できますが、適合を認定したり、有資格のレビュー担当者や障害のある人によるテストを代替したりすることはできません。

ここでAIが最も役立つのは、証拠の整理役、比較エンジン、下書き支援です。複雑なWordPressタスクを調査しやすくできますが、欠けている権限を生み出したり、観察していない事実を認定したり、推奨を黙って実行許可に変えたりすることはできません。

一文で言うと: AIはアクセシビリティに関する所見をWordPress改善ブリーフに整理できますが、適合を認定したり、有資格のレビュー担当者や障害のある人によるテストを代替したりすることはできません。

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

検証済みのアクセシビリティ所見を、範囲、基準、証拠、影響を受けるテンプレート、受け入れテスト、責任あるレビューを備えた実装可能なブリーフに変換します。

  • 正確なURL、コンポーネント、WCAG基準に結び付いた所見レジスター。
  • 自動化シグナル、手動による所見、未解決の質問の区別。
  • テンプレートレベルの改善要件と再現可能な受け入れテスト。
  • 認定を主張しない検証およびリグレッション計画。

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

準備する証拠と入力

  • 定義された代表サンプルと評価範囲。
  • 自動テストのエクスポート、手動キーボード結果、支援技術の観察。
  • スクリーンショット、DOMスニペット、コンポーネント識別子。
  • 該当するWCAG目標、組織方針、必要に応じた法的助言。

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

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

ツールの結果は適合判定ではない

自動ツールが対象にするのはWCAGの一部だけであり、偽陽性を生んだり、文脈依存の失敗を見逃したりすることがあります。すべての所見について、テスト方法と確信度を保持してください。

改善は適切な層に属する

テーマコンポーネントで繰り返される問題を、数十のページで個別にパッチしてはいけません。ブリーフでは、所有するテンプレートまたはコンポーネントを特定する必要があります。

受け入れ基準は観察可能でなければならない

「これをアクセシブルにする」のような要求は実装できません。必要な動作、テスト手順、期待される読み上げまたは視覚的結果、対応する状態を記載します。

観察、推論、権限を分ける

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

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

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

安全なワークフロー

  1. 評価範囲、対象WCAGバージョン、代表サンプルを定義する。
  2. 正確な証拠とテスト方法を含む所見を収集する。
  3. 各影響対象URLとコンポーネント状態を保持しながら、重複を正規化する。
  4. AIに、根本原因、所有者、改善層ごとに所見をグループ化するよう依頼する。
  5. 有資格のアクセシビリティレビュー担当者に、重大度と提案された動作を検証してもらう。
  6. コードを変更せずに、実装要件と受け入れテストを書く。
  7. 管理された開発ワークフローで、承認済みの修正を実装する。
  8. サンプルと影響を受けるコンポーネントのバリエーションを再テストし、残る制約を文書化する。

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

プロンプトのレシピ

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

You are reviewing [TASK SCOPE] for [SITE, REPOSITORY OR DATASET] using only the supplied evidence.

目的:
検証済みのアクセシビリティ所見を、範囲、基準、証拠、影響を受けるテンプレート、受け入れテスト、責任あるレビューを備えた実装可能なブリーフに変換する。

次のフィールドを返す:
- 所見ID
- URL
- コンポーネント
- 状態
- WCAG基準
- 証拠
- テスト方法
- 影響
- 根本原因
- 改善要件
- 受け入れテスト
- 所有者

ルール:
1. 適合または法令順守を主張しない。
2. 自動ツールが検出しなかったという理由で所見を格下げしない。
3. 正確なキーボード、スクリーンリーダー、視覚テストの証拠を保持する。
4. コンテンツ修正を、コードおよびデザインシステムの修正から分離する。
5. 分析段階でWordPressを編集しない。

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

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

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

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

推奨アクセス境界

このガイドで説明する段階には Read Only を使用してください。IDで利用可能な正確な能力は、インストール済み製品バージョン、公開済みの対象範囲契約、実際に使用している接続方法に基づく必要があります。

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

  • 自動認定
  • 基準の推測
  • スクリーンショットのみの証拠
  • コンポーネント欠陥をページごとにパッチすること
  • リグレッションテストなし

拒否された操作は、制御境界が機能している証拠として役立つことがあります。想定される拒否に対して、広範な管理者アカウントやFull Powerを付与して対応しないでください。まず、その操作が現在の委任範囲に属するかどうかを判断します。属する場合は、必要な能力を最も狭くした別途承認済みの段階を作成してください。

WP Agent Controlの位置付け

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

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

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

検証チェックリスト

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

よくある失敗モード

  • 頻度による重大度: まれなブロッカーは、頻繁な見た目上の問題より深刻な場合があります。
  • 達成基準の言い換えによる損失: ブリーフが要件を単純化しすぎ、実装が文章上の条件を満たしても意図された動作に失敗する。
  • 状態の欠落: デフォルトのコンポーネント状態だけをテストし、エラー、メニュー、ダイアログ、モバイル状態が壊れたままになる。
  • 人への影響の消去: 技術的な所見を、困難または不可能になるユーザータスクの説明なしに列挙する。

繰り返し現れる横断的な失敗は 権限ドリフト です。初期タスクが制限に遭遇すると、運用者は欠けている操作が必要、対応済み、安全のいずれであるかを判断する前にアクセスを広げます。これにより拒否が持つ証拠価値が失われ、後の結果の帰属が困難になります。

詳細な注記

再利用可能な改善システムでは、所見、コンポーネント、基準、テストを別個のオブジェクトとしてモデル化します。これにより、根本原因への一つの修正を、元の証拠経路を失わずに、影響を受けるすべての状態に対して検証できます。

関連ガイド

次のステップ

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

情報源と検証

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