Architect Professional ドメイン4: 評価・テスト・最適化（16%）
この章で学ぶこと: 評価の指標（正確さ・遅延・コスト・安全性・セキュリティ）、評価データセットと採点のしかたの組み合わせ、能力の評価と回帰の評価、pass@k と pass^k、A/B テストと反復の改善、問題の診断（プロンプトの失敗・ハルシネーション・モデルのミスマッチ）、コストと性能の最適化、ログとオブザーバビリティでの監視。
| タスク（試験ガイド） | この章の節 |
|---|---|
| 評価指標を定義する（正確さ、レイテンシ、コスト、安全性、セキュリティ） | 第1節 |
| 複数の手法を組み合わせて評価データセットとテストの枠組みを設計する | 第2節 |
| A/Bテストと反復的な改善を行う | 第3節 |
| システムの問題を診断する（プロンプトの失敗、ハルシネーション、モデルのミスマッチ） | 第4節 |
| トークン使用量、レイテンシ、コストと性能のトレードオフを最適化する | 第5節 |
| ログとオブザーバビリティのツールでシステム性能を監視する | 第6節 |
本番の63問のうち約10問です。Developer F では評価はほとんど出ませんでしたが、Professional では大きな範囲です。
基礎はここで復習してください:
- エラーの種類、
stop_reason、回復のしかた、ハルシネーション対策 → Developer F ドメイン4 - 成功の基準の決め方 → Developer F ドメイン2 第1.2節
- コストとトークンの管理、使用量の追い方 → Developer F ドメイン5 第4節
1. 評価の指標を決める
1.1 良い成功の基準（公式）
公式の「Define success criteria and build evaluations」によると、良い成功の基準は次の4つを満たします。
| 性質 | 意味 | 例 |
|---|---|---|
| 具体的（Specific） | 何を達成したいかをはっきり | 「良い性能」ではなく「感情分類の正確さ」 |
| 測れる（Measurable） | 数字、または一貫して使える質的な尺度 | 安全性も数字にできる: 「1万回の試行で、有害と判定された出力が0.1%未満」 |
| 達成できる（Achievable） | 業界の基準、過去の実験、専門家の知識にもとづく | 今の最先端モデルの能力を超えた目標にしない |
| 関係がある（Relevant） | アプリの目的と利用者に合う | 医療アプリでは引用の正確さが重要。雑談ではそれほどでもない |
公式は、多くの用途で「複数の基準での評価」が必要だとしています。
1.2 5つの指標の種類（試験ガイド）
| 種類 | 指標の例 | 測り方 |
|---|---|---|
| 正確さ（accuracy） | 正答率、F1、事実の一致率、引用の正確さ、RAG の recall@K | 正解との比較、LLM の採点者 |
| 遅延（latency） | TTFT、全体の時間の p50 / p95 / p99 | 本番とテストのログ |
| コスト | 1件あたりのトークンと料金、キャッシュのヒット率 | 応答の usage、Usage and Cost API |
| 安全性（safety） | 有害な出力の割合、正しく断った割合、必要なのに断った割合（過剰な拒否） | 分類器、LLM の採点者、人 |
| セキュリティ | プロンプトインジェクションの成功率、個人情報の漏れ、許可されないツール呼び出しの数 | 攻撃のテストセット（レッドチーム）、ログ |
ポイント: 平均だけでなく p95 などの「遅い側」を見る。SLA はふつう p95 や p99 で約束します（ドメイン6）。
2. 評価データセットとテストの枠組み
2.1 公式の評価の設計の原則
| 原則 | 内容 |
|---|---|
| 仕事に合わせる | 本番の仕事の分布に近づける。端の例（edge case）も入れる |
| できるだけ自動に | 選択式、文字列の一致、コードでの採点、LLM での採点など、自動で採点できる形にする |
| 質より量 | 少し信号の弱い自動採点の問題をたくさん持つほうが、人が丁寧に採点する少しの問題より良い |
2.2 採点のしかた（3種類を組み合わせる）
| 採点のしかた | 公式の評価 | 向いている |
|---|---|---|
| コードでの採点 | いちばん速く確実で、大規模にできる。ただし複雑な判断の細かさはない | 完全一致、文字列の一致、JSON の形、テストが通るか、データベースの最終状態 |
| LLM での採点 | 速く柔軟で、大規模にでき、複雑な判断に向く。まず信頼できるか確かめてから広げる | 口調、要約の質、根拠に合っているか |
| 人の採点 | いちばん柔軟で質が高いが、遅く高い。できれば避ける | LLM の採点者の調整（calibration）、主観的な出力の基準づくり |
LLM の採点者のこつ（公式）:
- はっきりした詳しい採点基準（ルーブリック）を書く
- 「正しい / 正しくない」や1〜5点など、決まった形で出させる
- 採点者のモデルに thinking を使わせ、採点の前に考えさせる
Anthropic のエージェントの評価の記事は、さらに次を勧めています。
- LLM の採点者は、人の専門家の採点と照らして調整する
- 観点ごとにルーブリックを作り、観点ごとに別の LLM の採点者で採点する（1つで全部を採点しない）
注意: Research の記事では逆に、1回の呼び出しで全観点を 0.0〜1.0 で採点するほうが一貫し、人の判断に近かった、と書いています。どちらが良いかは、人の採点と照らして自分の用途で確かめます。
2.3 データセットの作り方（混ぜる方法）
| 出どころ | 長所 | 注意 |
|---|---|---|
| 本番の実際の失敗 | 本当に起きる問題。記事は「実際の失敗から20〜50件の簡単なタスクで始めるのが良い」 | 個人情報を消してから使う |
| 専門家が作る例 | 正解が確か | 少ない、偏りうる |
| Claude に作らせる例 | たくさん作れる | 人が確かめる。本番の分布とずれやすい |
| 攻撃・端の例 | 安全とセキュリティを測れる | 定期的に足す |
データセットの決まり（記事）:
- 釣り合いをとる: ある振る舞いが「起きるべき場合」と「起きるべきでない場合」の両方をテストする（例: 検索すべき質問と、検索すべきでない質問）
- 各タスクに参照解（正解の例）を作る: タスクが解けることと、採点者の設定が正しいことを確かめる
- 試行ごとにきれいな環境から始める（前の試行の影響を残さない）
- 開発に使う例と、最後に確かめる例（held-out）を分ける（公式の評価のサイクルの図）
2.4 能力の評価と回帰の評価
| 能力の評価（capability / quality eval） | 回帰の評価（regression eval） | |
|---|---|---|
| 問い | このエージェントは何がうまくできるか | 前にできていたことが、今もできるか |
| 合格率 | 低いところから始め、上げていく | ほぼ100%であるべき |
| 使い方 | 改善の目標 | 変更のたびに回し、壊れていないか確かめる |
記事: 合格率が高くなった能力の評価は、回帰の評価に「卒業」させて、ずっと回し続けます。評価が100%になる（飽和する）と、改善の信号が出なくなるので、新しい難しいタスクを足します。
2.5 エージェントの評価: 結果と過程
| 見るもの | 内容 | 例 |
|---|---|---|
| 結果（outcome） | 最後の環境の状態 | 「予約しました」と言ったかではなく、データベースに予約があるか |
| 過程（transcript / trace） | ツールの呼び出し、推論、途中の結果のすべての記録 | 不要なツールを何十回も呼んでいないか、ターン数が上限以内か |
採点のまとめ方（記事）: 重み付け（合計がしきい値を超える）、すべて合格が必要（binary）、その組み合わせ。
2.6 pass@k と pass^k
| 指標 | 意味 | k を増やすと | 向いている |
|---|---|---|---|
| pass@k | k 回試して、少なくとも1回成功する確率 | 上がる | 1回でも成功すればよい道具（候補を複数出して選ぶ） |
| pass^k | k 回試して、全部成功する確率 | 下がる | 毎回成功が必要なエージェント（顧客対応など一貫性が大事） |
記事: 何百回試しても0%（0% pass@100）なら、たいていエージェントの能力ではなく、タスクか採点者が壊れている合図です。
3. A/B テストと反復の改善
3.1 オフラインの評価とオンラインの評価
| オフライン（本番の前） | オンライン（本番） | |
|---|---|---|
| 何か | 評価データセットで変更を比べる | 本番の利用者の一部に新しい版を出して比べる |
| 速さ | 速い。何回でも | 遅い。十分な量の利用が要る |
| わかること | 決めた基準での品質 | 本当の利用者の反応（採用率、修正率、満足度） |
記事: A/B テストは、十分な量の利用があるときに、大きな変更を確かめるためのもの。自動の評価は速い反復に、本番の監視は本当の姿の把握に、定期的な人のレビューは採点者の調整に使い、組み合わせます。
3.2 A/B テストの進め方（一般的な実践）
この節は公式の手順ではなく、一般的な実験の進め方です。
| 段階 | やること |
|---|---|
| 1. 仮説 | 「例を3つ足すと、修正率が下がる」 |
| 2. 主な指標とガードレールの指標 | 主: 修正率。ガードレール: 遅延 p95、コスト、安全性の指標が悪くならないこと |
| 3. 1つずつ変える | プロンプトとモデルを同時に変えると、どちらが効いたかわからない |
| 4. 振り分け | 利用者をランダムに分ける（同じ利用者はいつも同じ版） |
| 5. 量と期間 | 偶然の差と区別できるだけの件数を集める。曜日などの影響を考える |
| 6. 判断 | 主な指標が良くなり、ガードレールが守られたら広げる。段階的に（例: 5% → 25% → 100%） |
| 7. 戻せるように | 悪いときはすぐ前の版に戻す（プロンプトとモデルの版を固定して管理） |
3.3 反復の改善のループ
公式の評価のサイクル: テストケースを作る（端の例も）→ 最初のプロンプトを作る → テストする → プロンプトを直す → 何回もくり返す → 残しておいた（held-out）評価で確かめる → 出す。
記事: 「トランスクリプトを読む」。多くの試行の記録と採点を読まないと、採点者がうまく働いているかわかりません。
4. 問題を診断する
4.1 症状から原因を見分ける
| 症状 | 疑う原因 | 確かめ方 | 打ち手 |
|---|---|---|---|
| 形式が崩れる、指示を無視する | プロンプトの失敗 | 同じ入力を何回か試す。指示があいまいでないか | 指示をはっきり、例を足す、構造化出力 |
| 根拠のないことを自信ありげに言う | ハルシネーション | 答えの根拠が文脈にあるか照らす | 「わからない」を許す、引用させる、根拠を確かめる段を足す |
| RAG で古い・関係ない答え | 検索・インデックス | 取ってきたチャンクを見る。recall@K を測る | 再インデックス、ハイブリッド検索、リランク、メタデータの絞り込み（ドメイン3） |
| 難しい推論でだけ失敗、簡単なものはできる | モデルのミスマッチ（能力不足） | 上位モデル・高い effort で同じ評価を回す | 上位モデル、effort、ルーティング |
| 簡単な仕事なのに遅くて高い | モデルのミスマッチ（過剰） | 小さいモデルで同じ評価を回す | 小さいモデル、低い effort |
| モデルを移したら壊れた | 破壊的な変化 | 400 エラー、トークン数の変化 | Developer F ドメイン5 第3.3節の対応表 |
| 途中で切れる | max_tokens |
stop_reason を見る |
上限を上げる、出力を分ける |
| 遅延が急に増えた、中身は同じ | キャッシュが効いていない | cache_read_input_tokens が 0 か |
先頭の変わる値を外す |
4.2 切り分けの順番
- 応答の形（HTTP の状態、
stop_reason）を見る → 統合の問題か、モデルの出力の問題か - モデルに渡したもの（プロンプト、検索結果、ツールの結果）を見る → 入力が悪ければ、モデルを変えても直らない
- 同じ入力で何回か試す → 毎回か、ときどきか
- 別のモデルや effort で同じ入力を試す → モデルの能力の問題か
- 直したら、評価で確かめ、その例を回帰の評価に足す
試験のサンプル問題3: 文書の更新のあとに自信ありげな誤答、遅延とモデルの版は同じ → モデルの重みや temperature ではなく、検索・インデックスをまず疑う。
5. コストと性能の最適化
| 打ち手 | 効果 | 失うもの | 確かめ方 |
|---|---|---|---|
| プロンプトキャッシュ | コスト（読み込み0.1倍）と TTFT | なし（設計の手間） | キャッシュのヒット率 |
| 小さいモデル / ルーティング | コストと遅延 | 難しい依頼の品質 | 評価で品質の差を確かめる |
| effort を下げる | コストと遅延 | 推論の深さ | 評価 |
| バッチ API | コスト50% | 即時性（結果まで最大24時間） | 即時性が要らない仕事か |
| 入力を削る（検索で絞る、ツールの出力を削る） | コストと遅延、気が散るのを防ぐ | 必要な情報まで削る危険 | 評価 |
| 出力を短くする | 出力のトークン（入力より高い） | 説明の量 | 利用者の満足 |
| ストリーミング | 体感の遅延 | なし | TTFT |
| fast mode | 出力の速さ（最大2.5倍） | 料金が高い | 必要な場面だけ |
最適化の順番の考え方（この教材の整理）: 品質を落とさない打ち手（キャッシュ、ストリーミング、入力の整理）から先に。品質を落としうる打ち手（小さいモデル、effort）は評価で確かめてから。
6. ログとオブザーバビリティで監視する
| 何を記録するか | 使い道 |
|---|---|
request-id、モデルの ID、プロンプトの版 |
問題の再現、どの版で起きたか |
usage（入力・出力・キャッシュのトークン） |
コストの追跡、キャッシュの確認 |
stop_reason の分布 |
途中切れや拒否の増加の検知 |
| 遅延（TTFT、全体） | SLA の確認 |
| ツールの呼び出しと結果（エラー） | エージェントの失敗の場所 |
| 利用者の反応（採用・修正・評価） | 品質の変化 |
監視の運用:
- ダッシュボードとアラート: 指標がしきい値を超えたら知らせる（例: p95 が SLA を超えた、エラー率が増えた）
- 本番のサンプルを採点する: 一部を LLM の採点者で採点し、品質の変化（drift）を見る
- 記事: 公開後の本番の監視は、分布の変化（distribution drift）と予想外の失敗を見つけるため
- 道具: Agent SDK・Claude Code の OpenTelemetry（ドメイン3 第4節）、Claude Console の Usage / Cost、Usage and Cost API
7. 試験に向けたまとめ
- 成功の基準は具体的・測れる・達成できる・関係がある。複数の基準で測る
- 採点はコード（速く確実）→ LLM（柔軟、まず確かめる）→ 人（調整用、できれば避ける）
- データセットは本番の失敗から20〜50件で始める。起きるべき・起きるべきでない例の両方
- 能力の評価は低い合格率から、回帰の評価はほぼ100%
- pass@k は「1回でも」、pass^k は「毎回」
- A/B テストは1つずつ変え、ガードレールの指標も見て、段階的に広げる
- 診断は「何をモデルに渡したか」から。RAG の誤答はまず検索
- 最適化は品質を落とさない打ち手から
8. 用語集
| 用語 | 意味 |
|---|---|
| eval（評価） | 決めた基準でシステムを測るテスト |
| ルーブリック | 採点基準 |
| LLM-as-judge | LLM を採点者として使うこと |
| calibration（調整） | LLM の採点者の判断を人の判断に近づけること |
| held-out | 開発に使わず、最後の確認のために残しておく例 |
| regression eval | 前にできたことが壊れていないかの評価 |
| saturation（飽和） | 評価がほぼ100%になり、改善の信号が出なくなること |
| pass@k / pass^k | k 回のうち1回以上成功 / k 回すべて成功の確率 |
| A/B テスト | 利用者を分けて2つの版を比べる実験 |
| guardrail metric | 悪くなってはいけない指標 |
| drift | 入力や品質が時間とともに変わること |
出典
- Define success criteria and build evaluations（Claude Platform Docs）: 4つの性質、0.1%の例、評価の設計の原則、3つの採点のしかた、LLM の採点者のこつ、評価のサイクル
- Demystifying evals for AI agents（Anthropic Engineering）: 採点者の種類、結果と過程、能力と回帰の評価、飽和、pass@k と pass^k、20〜50件、釣り合い、参照解、きれいな環境、トランスクリプトを読む、A/B テストと本番の監視
- How we built our multi-agent research system（Anthropic Engineering）: 小さく始める（約20件）、LLM の採点者のルーブリック、人の評価
- 試験ガイド サンプル問題3
注意: 第1.2節の指標の例、第3.2節の A/B テストの手順、第4.1節の症状の表、第5節の最適化の順番は、この教材の整理です（一般的な実践）。