学習目標:
- 「正しい手順を記録して1つずつ突き合わせる」方式がエージェントを必ず誤判定する理由を理解し、終状態評価に切り替える
- 複雑なワークフローでは、すべてのステップを検証するのではなく「期待した状態変化が起きたか」を確認する少数の個別チェックポイントを特定する
- 曖昧な要件を、測定可能で達成可能な多次元の成功基準に変え、軌跡アサーションをどこまで使ってよいかを把握する
前提: レッスン1を完了し、実行できる検査がないときは自分自身が検証ループになることを理解していること | 前: レッスン1 << | 次: レッスン3 >>
エージェントに検証を追加しようと決めます。最初の衝動はほぼ全員に共通しています。「標準的なやり方」を記録するのです。タスクを一度手作業で通し、すべてのステップを書き留める——ステップ1では search を呼ぶはず、ステップ2では fetch_page、ステップ3では write_note——それを解答例として保存します。以後、エージェントが実行するたびに、呼び出し列をこの解答と1ステップずつ突き合わせる。1つでも食い違えば不合格。
3回実行しました。3回とも不合格でした。
出力を確認します。3本の要約はいずれも事実が正しく、出典も信頼でき、求めた観点をすべて押さえています。違ったのは経路だけでした——1回目は3つのソースを検索してそれで十分だった。2回目は10検索した。3回目は検索の前にまず用語の定義を調べた。これはまさに Anthropic が自社のマルチエージェント調査システムで観測したことです。出発点が同一でも、エージェントは目標に到達するまでにまったく異なる、しかし有効な経路を取りうる。あるエージェントは3つのソースを検索し、別のエージェントは10検索する。あるいは同じ答えを見つけるのに異なるツールを使う1。
失敗したのはエージェントではありません。あなたの検証方法です。
従来の評価には、深いところに埋め込まれた既定の前提があります。入力Xが与えられたら、システムは経路Yをたどって出力Zを生成するはずだ——毎回同じ手順で1。この前提は決定的システムではあまりに自然に成り立つため、それが前提であることに気づかないまま過ごす人がほとんどです。エージェントはそれを一瞬でひっくり返します。
本当に居心地が悪いのは「経路が変わる」だけではありません。次の一文です。
"Because we don’t always know what the right steps are, we usually can't just check if agents followed the “correct” steps we prescribed in advance. Instead, we need flexible evaluation methods that judge whether agents achieved the right outcomes while also following a reasonable process."1
（正しい手順が何かを常に把握しているわけではないため、あらかじめ規定した「正しい」手順にエージェントが従ったかどうかを確認するだけでは、たいてい済みません。代わりに、妥当なプロセスを踏みつつ正しい結果に到達したかどうかを判定する、柔軟な評価手法が必要です）
「正しい手順が何かを常に把握しているわけではない」——これが肝です。あなたが記録した経路は、唯一の正しい経路ではありません。それはその時たまたま自分が通った経路にすぎません。それを解答例に格上げしたので、他のすべてのやり方が誤りになってしまったのです。
後半にも注目してください。「妥当なプロセスを踏みつつ」。これはプロセスを完全に無視しろという意味ではありません。1つの固定された経路をものさしにするな、という意味です。
Anthropic のアプローチは直接的です。ターンごとの分析ではなく終状態の評価に集中する——特定のプロセスに従ったかを判定するのではなく、正しい最終状態に到達したかを判定する1。この方法は、エージェントが同じ目標に別の経路で到達しうることを認めたうえで、意図した結果を届けることは保証します1。
まず「終状態」を平たく定義しておきます。タスク完了後に環境で観測でき、事後に検証できる状態のことです。ファイルシステムにどのファイルが現れたか、あのデータベースレコードのフィールドが今どんな値か、チケットにどのラベルが付いているか、返ってきたJSONに status: "resolved" があるか。
便利なリトマス試験があります。終状態は名詞であって動詞ではない、というものです。「rename_file を呼んだ」は動詞、「すべてのファイル名がある形式に一致している」は名詞です。検証が受け付けるのは名詞だけです。
左の列は、結果が同一であっても、エージェントが個別の4回の読み取りの代わりに一括読み取りを1回使った瞬間に不合格になります。右の列はどう読んだかを気にしません——「downloads/ が今どうなっているか」を記述しているだけで、そこに至った経緯とは無関係だからです。
終状態のアサーションを書くときに見落としやすい箇所があります。変わってはいけないものも書き留めることです。上の「ファイル数が実行前と一致」がそれにあたります。エージェントが2つのファイルを同じ名前にリネームして2つ目が1つ目を上書きした場合でも、「すべてのファイル名が妥当」という検査は完璧に通ってしまいます。終状態のアサーションは「期待した変化が起きた」と「期待しない変化が起きていない」の両方を守らなければなりません。
終状態評価は「プロセスを完全に無視する」ことではありません。出典の次の一文が逃げ道を示しています。複雑なワークフローでは、すべての中間ステップを検証しようとするのではなく、特定の状態変化が起きているはずの個別のチェックポイントに評価を分割する1。
言い回しに注目してください——「特定の状態変化が起きているはず」、やはり状態であり、名詞です。観測点を「ゴール地点」から「途中の数箇所」に移しただけです。
用語衝突の注意: 本シリーズのコース9で言う「チェックポイント」はコンテキストの保存を指します。エージェントの実行中の状態をディスクに書き出し、クラッシュ後にそこから再開できるようにするもので、目的はリカバリーです。本レッスンで言う「チェックポイント」は状態の検証を指します。フローのある地点で期待した状態変化が起きたことを確認するもので、目的は妥当性の確認です。位置はしばしば重なりますが（チェックポイントを打つ場所で検証も行うのは自然です）、解こうとしている問題が違います。議論で混ぜると混乱するので、以下では前者を「リカバリーチェックポイント」、本レッスンのものを「検証チェックポイント」と呼び分けます。
検証チェックポイントを追加する価値があるかは、3つを見て判断します。
どれにも当てはまらないなら、追加しないでください。
どこに置くか。状態が実質的に変化する地点であって、ツール呼び出しのたびではありません。
チェックポイント2つ、終状態1つ。3つのアサーションが移行全体を統治します。「すべての中間ステップを検証する」方式を採っていたら、このワークフローは何十ものアサーションを生み、その大半は正当な実装差を罰するだけのものになったでしょう。
「正しい終状態」というひと言は、具体的な数値か明確な判定に着地させないと、結局「正しそうに見える」に逆戻りします。公式ドキュメントは成功基準に2つの必須要件を課しています。
そしてもう1つ。ほとんどのユースケースは、複数の成功基準にまたがる多次元の評価を必要とします2。
公式ドキュメントの完全な例は一文です（括弧内の注記は原文のものです）。
"The sentiment analysis model should achieve an F1 score of at least 0.85 (Measurable, Specific) on a held-out test set* of 10,000 diverse Twitter posts (Relevant), which is a 5% improvement over the current baseline (Achievable)."2
（感情分析モデルは、多様な10,000件のTwitter投稿からなるホールドアウトのテストセット上で、少なくとも0.85のF1スコアを達成すべきである。これは現在のベースラインから5%の改善にあたる）
この一文は分解する価値があります。各構成要素が、それぞれ特定の失敗モードを封じているからです。
最後の行が「達成可能」の具体的なやり方です。閾値は願望から逆算するものではなく、現状から小さく一歩進めたものです。ベースラインがないなら、最も素朴な実装を1バージョン走らせて、そのスコアをベースラインにします。ベースラインすら走らせられないうちは、急いで数値を決めないでください。
もっと手前の問いもあります。Anthropic はエージェントが向くシナリオをこう記述しています。エージェントが最も価値を発揮するのは、会話と行動の両方を必要とし、明確な成功基準があり、フィードバックループを可能にし、意味のある人間の監督を組み込めるタスクである3。これを逆から読んでください——どうやってもこのタスクの成功基準が書けないなら、問題は検証のステップにあるのではなく、そのタスクは丸ごとエージェントに単独で走らせるべきではなかったのです。基準が書けないなら、最初から最後まで見ているしかありません——レッスン1で述べたとおり、その時点であなた自身が検証ループになります。
終状態評価は「結果が正しいか」を捕まえますが、1種類の問題を取り逃がします。渡した新しいツールを、エージェントが本当に認識しているかどうかです。
公式ドキュメントは任意の追加要素を提示しています。プロンプトと応答のペアごとに、そのタスクを解く際にエージェントが呼ぶと期待するツールを任意で指定でき、評価の中で各ツールの目的をエージェントが把握できているかを測れる4。これが軌跡アサーションです——順序を判定せず、回数も判定せず、あるツールが軌跡に現れたかどうかだけを判定します。
役に立つ場面はこうです。search_internal_docs ツールを追加したばかりで、社内プロセスに関する質問ではそれを使ってほしい。ところがエージェントは公開ウェブを検索し、十分似た答えを見つけてしまい、終状態の検証は通ってしまいます。その違いが見えるのは軌跡だけです。
限界はすぐ次の一文に書かれています。タスクを正しく解く有効な経路は複数ありうるため、過剰な指定や特定の戦略への過剰適合は避けるようにする4。
具体的な境界線はこうです。
評価を1回まわして合格率しか手に入らなければ、あなたは何も言えなくなります——78%とは何を意味するのか。次に調整すべきはプロンプトなのかツールなのか。
公式ドキュメントは、トップレベルの正確度に加えてこれらの指標を集めることを推奨しています。個々のツール呼び出しとタスクの総実行時間、ツール呼び出しの総回数、トークンの総消費量、ツールのエラー4。これらの指標は判定には参加しません。診断に参加します。
公式ドキュメントは2つの読み取り方を示しています。
この2つに共通しているのは、指を向ける先がツールの設計であって、モデルではないことです。冗長な呼び出しが多いのは、たいてい一度に20件しか取れないので10ページめくらざるをえないからです。パラメータエラーが多いのは、たいていツールの説明がそのフィールドにどんな形式が必要かを説明していないからです。これらの問題はツール側に根があります——システムプロンプトに「呼び出しを減らせ」「パラメータを丁寧に書け」と足すだけではたいてい効きません。ツールのパラメータ設計と説明を直す必要があります。
この筋をたどるとさらにいくつか出てきます（以下は公式のお墨付きではなく、上の2つから外挿した工学的判断です。自分のデータで確かめてください）。合格率は変わらないのにトークン消費が倍になったなら、その変更は無料ではありません。あるカテゴリのタスクだけ所要時間のばらつきが大きいなら、リトライや堂々巡りが隠れている可能性が高い。エラーが1つのツールに集中しているなら、まずそのツールを見るべきで、プロンプトを疑うのは後です。
評価の1回の実行は、少なくとも次の列を落とすべきです。レッスン6で評価ハーネスを組むときにそのまま使います（列幅を節約するため、入出力トークンは1列にまとめます）。
その1: すべての中間ステップを検証しようとしないこと1。本レッスンで最も破られやすい境界線です。「多く検証するほど安全」という直感があまりに強いからです。実際の結果は逆になります。アサーションが細かいほど正当な差異が罰され、評価はノイズだらけになり、やがて赤を無視し始めます——その時点で完全に無価値です。
その2: 軌跡アサーションを既定にしないこと。軌跡アサーションの追加はあまりに安価で、expectedTools にもう1エントリ書くのは何の労力もいりません。10エントリ目にはもう実質的に戦略を規定しており、形式上「アサーション」と呼んでいるだけになります。追加するたびに自分に問うてください。このツールが呼ばれなかったら、出力は本当に壊れるのか。答えが「必ずしもそうではない」なら、追加しないことです。
その3: 実行後に閾値を決めないこと。0.82というスコアを見て「0.8で十分だろう」と言うのも、0.86を見て「0.85は必要だ」と言うのも、同じ自己欺瞞です。閾値は実行前に決め、その根拠を書き留めてください。
>> レッスン3: 決定的な検証器: pass/fail を出せる検査だけが有効
How we built our multi-agent research system — Anthropic Engineering — https://www.anthropic.com/engineering/multi-agent-research-system ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12
Define success criteria and build evaluations — Claude API documentation — https://platform.claude.com/docs/en/test-and-evaluate/develop-tests ↩ ↩2 ↩3 ↩4 ↩5
Building Effective AI Agents — Anthropic Engineering — https://www.anthropic.com/engineering/building-effective-agents ↩ ↩2
Writing effective tools for agents — with agents — Anthropic Engineering — https://www.anthropic.com/engineering/writing-tools-for-agents ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7
invoices/ にある200件のPDFを "YYYYMMDD_取引先.pdf" にリネームするuser.spec.ts の should reject expired token テストが失敗している。エージェントに直させるこれを測定可能な多次元の成功基準に書き直してください。各次元について4項目すべてを書きます。指標の名前、どう測るか、閾値はいくつか、なぜその閾値が現実的に達成可能なのか。そのうえで、どの次元が終状態を検証し、どの次元が中間チェックポイントを設けるかを、理由とともに決めてください。次元は3つ以上。コードは不要です。
タスク: downloads/ の請求書PDFを "日付_取引先.pdf" にリネームする
ステップ基準の検証（脆い） 終状態基準の検証（安定）1. list_files を呼ぶ downloads/ に元のファイル名が残っていない2. 各ファイルで read_pdf を呼ぶ 各ファイル名が ^\d{8}_[a-z0-9-]+\.pdf$ に一致する3. extract_date を呼ぶ ファイル数が実行前と一致し、消失も増加もない4. 各ファイルで rename_file を呼ぶ ファイル名の日付がPDF内容の請求日と一致するタスク: ユーザーテーブルを旧スキーマから新スキーマへ移行する
検証チェックポイント1（テーブル作成後）: new_users テーブルが存在し、カラムが目標スキーマと完全に一致する検証チェックポイント2（データ投入後）: new_users の行数 == old_users の行数、主キーの重複がない終状態: アプリが新テーブルを読んでスモークテスト（最も基本的な「動くか」の確認）に合格し、old_users が old_users_backup にリネームされている
検証しないもの: CREATE TABLE を書いたのかテンプレートから複製したのか、一括で投入したのかバッチに分けたのか、何バッチか、1バッチ何行か。// 評価ケース1件の形: 終状態の判定は必須、軌跡アサーションは任意
const evalCase = {
id: 'invoice-rename-003',
prompt: 'downloads/ の今月分の請求書を date_vendor.pdf にリネームして',
// 必須: 実行後に環境がどうなったかを確認する（書き方はレッスン3で）
checkEndState: async (env) => { /* ... */ },
// 任意: 順序や呼び出し回数を問わず、少なくともこれらのツールに触れたことを期待する
expectedTools: ['read_pdf', 'rename_file'],
};
case_id | passed | duration_ms | tool_calls | tokens_in | tokens_out | tool_errors