ai-feature-testing

AI 機能のテスト

使用するタイミング

• 製品の AI 機能について、品質、安全性、公平性、フォールバック動作、ユーザーエクスペリエンスを検証する必要がある場合に、このスキルを使用します。
• 既存の計画、結果、または証拠一式をレビューし、実行可能な改善案を作成する場合に使用します。
• コンテキストが不完全でも、範囲を限定した初回レビューに価値がある場合に使用します。

出力形式のオプション

• レビュー、実行、段階的な改善には、Markdown を既定で使用します。
• ユーザーが表、CSV、JSON、またはチケットのフィールドを指定した場合は、リスク、証拠、優先度、境界に関する情報を維持します。
• 機械処理される出力では、まずスキーマ、列挙値、必須フィールドを確認します。

使用方法

1. 入力契約、実行ルール、最低限のカバレッジ、出力順序を含め、prompts/ai-feature-testing.md を読み、その指示に従います。
2. スコープ、環境、バージョン、制約、証拠、成功基準など、判断に影響するコンテキストのみ追加します。
3. 入力を監査し、確認済みの事実、作業上の仮定、未解決の質問を分けます。
4. リスクと証拠の強さに基づいて優先順位を付け、すぐに実行またはレビューできる成果物を作成します。
5. 情報が不足している場合は、範囲を限定した初回レビューを提示し、どの結論が裏付けられていないかを明記します。

参考ファイル

• ドメインの結果、妥当な対照条件、証拠の不足を評価する際は、サニタイズ済み入力、項目ごとのオラクル、再現可能な計算が記載された references/domain-decision-example.md を読みます。

• 必ず prompts/ai-feature-testing.md を読みます。これはこのスキルの完全な実行仕様です。

• 評価またはリグレッションテストでは、evals/eval.yaml と evals/cases/ 内の関連ケースを読みます。

• references/、examples/、scripts/、output-formats.md は、それらのディレクトリが存在し、タスクで必要な場合にのみ読み込みます。

ドメイン実行の要点

1. モデル、プロンプト、ナレッジ／評価データ、製品、環境のバージョンを固定します。製品タスク×言語×ユーザーグループ×リスクごとに分類し、サンプルの出所と件数を記録します。集計によって少数グループが見えなくならないようにします。
2. 人手によるルーブリックの各評価軸に、観察可能な基準、評価者、不一致の処理方法、参照情報の出所を定めます。プロジェクトで定義したスコアや重みを使用する前に、例を使って調整します。スコア定義がない場合は未解決のままにします。
3. タスク品質、安全性／プライバシー、拒否が必要なケースと回答可能な対照ケース、フォールバックのゲートを分けます。各ゲートについて、出所、分母、バージョンを記録します。拒否が多いことが必ずしも安全性の向上を意味するわけではありません。
4. 分類ごとのサンプルまたはしきい値がない場合は、UNKNOWN／未解決の質問として扱います。リリースの推奨には、未解決のゲートと人による判断を含めます。静的な計画だけでは、実行に合格したことを証明できません。

主な制約

• 理想的な入力だけをテストしないでください。
• モデルの制限と統合上の不具合を区別してください。
• 高リスクの出力には、拒否または人へのフォールバックを必須とします。
• 証拠にないシステムの動作、フィールド、データ、指標、根本原因を決して作り上げないでください。
• 重要な結論は証拠に結び付けます。裏付けのない結論は仮説として示し、検証方法を記載します。
• ビジネスへの影響、発生可能性、または検出可能性を使って優先度を説明します。

提出チェックリスト

• タスク品質、事実性、一貫性、安全性、公平性、プライバシー、レイテンシとコスト、フォールバックと人への引き継ぎを網羅した。
• 事実、仮定、不足情報、推奨事項を分けた。
• 高リスク項目に、優先度、証拠の根拠、担当者または次のアクションを設定した。
• 一般論ではなく、検証可能な判断基準を定義した。
• 許可されていない本番環境への書き込みや破壊的な操作を行わなかった。

よくある落とし穴

• 前提条件、期待される結果、証拠を示さずに確認項目を列挙する。
• すべてを高優先度とし、トレードオフを避ける。
• ドメインに基づく推論の代わりに、ツール名や一般論を用いる。
• 入力が不完全だからと拒否する、または不完全な証拠が確実性を裏付けているかのように装う。

ベストプラクティス

• ビジネス上の損失、安全上の問題、リリースの阻害につながる可能性が最も高いパスから着手します。
• 最小限の検証可能な実験で不確実性を減らし、再現条件を記録します。
• 成果物を実行可能にし、別のエンジニアが独立してレビューできるようにします。