カスタマイズ

実行前に、以下の場所でユーザーカスタマイズを確認してください: ~/.pai/PAI/USER/SKILLCUSTOMIZATIONS/Evals/

このディレクトリが存在する場合、そこで見つかった PREFERENCES.md、設定、またはリソースを読み込んで適用してください。これらはデフォルト動作をオーバーライドします。ディレクトリが存在しない場合は、スキルのデフォルト設定で処理を続行してください。

🚨 必須: 音声通知 (アクション実行前に必須)

このスキルが呼び出された時、他のことをする前にこの通知を送信する必要があります。

1. 音声通知を送信:

   curl -s -X POST http://localhost:8888/notify \
     -H "Content-Type: application/json" \
     -d '{"message": "Running the WORKFLOWNAME workflow in the Evals skill to ACTION"}' \
     > /dev/null 2>&1 &
   

2. テキスト通知を出力:

   Running the **WorkflowName** workflow in the **Evals** skill to ACTION...
   

これはオプションではありません。スキルが呼び出されたらこの curl コマンドを即座に実行してください。

Evals - AIエージェント評価フレームワーク

Anthropic の「Demystifying Evals for AI Agents」(2026年1月)に基づいた包括的なエージェント評価システムです。

主な特徴: 単一の出力ではなく、エージェントワークフロー(トランスクリプト、ツール呼び出し、マルチターン会話)を評価します。

---

発動タイミング

• 「evals を実行」「このエージェントをテスト」「評価」「品質確認」「ベンチマーク」
• 「リグレッションテスト」「機能テスト」
• 変更を通じたエージェントの動作比較
• デプロイ前のエージェントワークフロー検証
• ALGORITHM ISC 行の確認
• 失敗から新しい評価タスクを作成

---

核心的な概念

3つの評価者タイプ

タイプ	長所	短所	用途
コードベース	高速、低コスト、決定論的、再現可能	脆弱、微妙なニュアンスに欠ける	テスト、状態確認、ツール検証
モデルベース	柔軟、ニュアンスを捉える、スケーラブル	非決定論的、高コスト	品質ルーブリック、アサーション、比較
人間	ゴールドスタンダード、主観性に対応	高コスト、低速	キャリブレーション、スポット確認、A/B テスト

評価タイプ

タイプ	合格目標	目的
能力	約70%	ストレッチゴール、改善の可能性測定
リグレッション	約99%	品質ゲート、後退の検出

主要メトリクス

• pass@k: k回のトライアル中、少なくとも1回成功する確率(能力を測定)
• pass^k: k回のトライアル全て成功する確率(一貫性/信頼性を測定)

---

ワークフロー ルーティング

リクエストパターン	ルート先
評価実行、スイート実行、テスト実行、ベンチマーク	Workflows/RunEval.md
モデル比較、A/B テスト	Workflows/CompareModels.md
プロンプト比較、プロンプト検証	Workflows/ComparePrompts.md
評価者作成、モデル評価者	Workflows/CreateJudge.md
ユースケース作成、新規評価、テストケース作成	Workflows/CreateUseCase.md
結果表示、評価結果、スコア、合格率	Workflows/ViewResults.md

CLI クイックリファレンス

トリガー	ツール
スイート実行	Tools/AlgorithmBridge.ts
失敗をログ	Tools/FailureToTask.ts log
失敗を変換	Tools/FailureToTask.ts convert-all
スイート作成	Tools/SuiteManager.ts create
飽和確認	Tools/SuiteManager.ts check-saturation

---

クイックリファレンス

CLI コマンド

# 評価スイートを実行
bun run ~/.pai/skills/Utilities/Evals/Tools/AlgorithmBridge.ts -s <suite>

# 後で変換するために失敗をログ
bun run ~/.pai/skills/Utilities/Evals/Tools/FailureToTask.ts log "description" -c category -s severity

# 失敗をテストタスクに変換
bun run ~/.pai/skills/Utilities/Evals/Tools/FailureToTask.ts convert-all

# スイートを管理
bun run ~/.pai/skills/Utilities/Evals/Tools/SuiteManager.ts create <name> -t capability -d "description"
bun run ~/.pai/skills/Utilities/Evals/Tools/SuiteManager.ts list
bun run ~/.pai/skills/Utilities/Evals/Tools/SuiteManager.ts check-saturation <name>
bun run ~/.pai/skills/Utilities/Evals/Tools/SuiteManager.ts graduate <name>

ALGORITHM 統合

Evals は ALGORITHM ISC 行の検証方法です:

# 評価を実行して ISC 行を更新
bun run ~/.pai/skills/Utilities/Evals/Tools/AlgorithmBridge.ts -s regression-core -r 3 -u

ISC 行は評価検証を指定できます:

| # | 理想的な状態 | 検証 |
|---|---------|------|
| 1 | 認証バイパスが修正済み | eval:auth-security |
| 2 | すべてのテストが合格 | eval:regression |

---

利用可能な評価者

コードベース(高速、決定論的)

評価者	用途
string_match	完全な部分文字列マッチング
regex_match	パターンマッチング
binary_tests	テストファイルを実行
static_analysis	リント、型チェック、セキュリティスキャン
state_check	実行後のシステム状態を確認
tool_calls	特定のツールが呼び出されたことを確認

モデルベース(ニュアンス重視)

評価者	用途
llm_rubric	詳細なルーブリックに対してスコアリング
natural_language_assert	アサーションの確認
pairwise_comparison	リファレンスとの比較(位置スワップ含む)

---

ドメインパターン

一般的なエージェントタイプに対する事前設定された評価者スタック:

ドメイン	主要評価者
coding	binary_tests + static_analysis + tool_calls + llm_rubric
conversational	llm_rubric + natural_language_assert + state_check
research	llm_rubric + natural_language_assert + tool_calls
computer_use	state_check + tool_calls + llm_rubric

完全な設定については Data/DomainPatterns.yaml を参照してください。

---

タスクスキーマ (YAML)

task:
  id: "fix-auth-bypass_1"
  description: "パスワードが空の場合の認証バイパスを修正"
  type: regression  # または capability
  domain: coding

  graders:
    - type: binary_tests
      required: [test_empty_pw.py]
      weight: 0.30

    - type: tool_calls
      weight: 0.20
      params:
        sequence: [read_file, edit_file, run_tests]

    - type: llm_rubric
      weight: 0.50
      params:
        rubric: prompts/security_review.md

  trials: 3
  pass_threshold: 0.75

---

リソース インデックス

リソース	目的
Types/index.ts	コア型定義
Graders/CodeBased/	決定論的評価者
Graders/ModelBased/	LLMベースの評価者
Tools/TranscriptCapture.ts	エージェント軌跡をキャプチャ
Tools/TrialRunner.ts	pass@k を使用したマルチトライアル実行
Tools/SuiteManager.ts	スイート管理と飽和度管理
Tools/FailureToTask.ts	失敗をテストタスクに変換
Tools/AlgorithmBridge.ts	ALGORITHM 統合
Data/DomainPatterns.yaml	ドメイン固有の評価者設定

---

主要原則 (Anthropic より)

1. 実際の失敗20〜50件から開始 - 過度に考えず、実際に発生したものを取得
2. 曖昧でないタスク - 2人の専門家が同じ判定に達するべき
3. バランスの取れた問題セット - 「すべき」と「すべきでない」の両方をテスト
4. 出力を採点、パスは採点しない - 有効で創造的なソリューションにペナルティを与えない
5. LLM 評価者をキャリブレーション - 人間の専門家の判定に対して
6. 定期的にトランスクリプトをチェック - 評価者が正しく機能しているか確認
7. 飽和度を監視 - 95%以上に達したらリグレッションに段階を上げる
8. インフラを早期に構築 - 評価は新しいモデルの導入速度を形作ります

---

関連項目

• ALGORITHM: Evals は検証方法です
• Science: Evals は科学的方法を実装
• Browser: ビジュアル検証評価者向け