mcpField
A
ai-agent-testing

ai-agent-testing

github.com/naodengテスト・品質28540 回インストール1 日前に更新
リポジトリ

ai-agent-testing について

AI エージェントを評価するチーム向けのテストスキルです。結果と実行トレースの両方を調べ、証拠、仮定、未解決事項を分けて、実行可能な所見をまとめます。

主な機能

  1. 01タスク完了度と計画の評価
  2. 02ツール使用とメモリ汚染の確認
  3. 03復旧と認可境界のテスト
  4. 04リスクと証拠に基づく優先順位付け
  5. 05実行可能なレビュー資料の作成

活用シーン

  1. 01リリース前のエージェント実行確認
  2. 02テスト結果のレビューと改善案の作成
  3. 03証拠が不十分な状況での限定評価

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/naodeng/awesome-qa-skills --skill ai-agent-testing

インストール後、Claude Code で/ai-agent-testingを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

agents/
openai.yaml
evals/
eval.yaml
evals/cases/
basic-success.yaml
domain-method-regression.yaml
edge-incomplete-input.yaml
edge-risk-priority.yaml
evals/fixtures/
check_domain_decisions.py
check-domain-decisions.sh
domain-oracle.json
prompts/
ai-agent-testing.md
references/
domain-decision-example.md

詳細

AI エージェントのテスト

使用する場面

  • エージェントの計画、メモリ、ツールの使用、復旧、安全境界、タスク完了の品質を体系的に検証する必要がある場合に、このスキルを使用します。
  • 既存の計画、結果、またはエビデンス一式をレビューし、実行可能な改善案を作成する場合に使用します。
  • コンテキストが不完全でも、範囲を限定した初回評価に価値がある場合に使用します。

出力形式の選択肢

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

使用方法

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

参考ファイル

  • ドメイン上の結果、妥当なコントロール、またはエビデンスの不足を調整する際は、サニタイズ済みの入力、項目ごとのオラクル、再現可能な計算について、references/domain-decision-example.md を読みます。

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

  • 評価または回帰テストでは、evals/eval.yaml と evals/cases/ 以下の該当するケースを読みます。

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

ドメイン実行の要点

  1. 入力サンプル ID、タスク成功のオラクル、許可されたツール/リソース、禁止された作用、停止条件を定義します。目標が不足している場合は未解決のままにします。
  2. 実行/ステップの順序、権限、冪等性、分離、復旧、予算の不変条件を確認します。結果の正しさとプロセスの遵守は個別に判定します。どちらか一方でも失敗した場合、全体の合格とはしません。
  3. 終了状態を、成功、目標未達、予算超過、キャンセル、安全上のブロック、環境エラーに分類します。終了イベントが欠落していても、完了した証拠にはなりません。
  4. モデル/プロンプト/ツール/データ/環境のバージョン、サンプル選定方法、プロジェクトで指定された反復回数を記録します。サンプルごとの合格/不合格数と、断続的な失敗を報告します。単一の試行では安定性を主張できません。

主な制約

  • 最終結果と実行トレースの両方を評価します。
  • 確率的な動作には、複数回の試行を使用します。
  • 1 回の成功を信頼性のエビデンスとして扱ってはいけません。
  • エビデンスにないシステムの動作、フィールド、データ、指標、根本原因を捏造してはいけません。
  • 重要な結論はエビデンスに結び付けます。裏付けのない結論は仮説として示し、検証方法を記載します。
  • ビジネスへの影響、発生可能性、または検出可能性を用いて優先度を説明します。

提出前チェックリスト

  • タスク完了、計画の品質、複数ステップの一貫性、ツールの使用、メモリの汚染、復旧、認可境界、コスト、レイテンシーを網羅している。
  • 事実、仮定、不足情報、推奨事項を分けている。
  • 高リスク項目に優先度、エビデンスの根拠、担当者または次のアクションを付けている。
  • 一般的な助言ではなく、検証可能な判断基準を定義している。
  • 許可されていない本番環境への書き込みや破壊的操作を行っていない。

よくある落とし穴

  • 前提条件、期待される結果、またはエビデンスを示さずにチェック項目を列挙する。
  • すべてを高優先度にして、トレードオフを避ける。
  • ドメインに基づく推論の代わりに、ツール名や一般論を使う。
  • 不完全な入力を理由に拒否する、または不完全なエビデンスから確実な結論が得られるかのように装う。

ベストプラクティス

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

コメント