前章までで、ツールを持ち、記憶を使い、複数体で分担するエージェントを設計してきました。ここで多くの開発者がぶつかる壁があります。「作ったはいいが、これが本当にちゃんと動いているのか分からない」という問題です。エージェントは確率的に動くため、同じ指示でも毎回まったく同じには動きません。だからこそ「測る仕組み（評価）」と「見える化する仕組み（可観測性）」が、実務投入の生命線になります。この章では、品質を数字でつかみ、失敗を再現し、改善を回し続けるための土台を作ります。
ゴールは「勘ではなく、測った数字でエージェントを良くする」
なぜ評価がいちばん重要なのか
普通のプログラムは、同じ入力を与えれば同じ結果が返ります。しかしエージェントの中心にいるのはLLMで、その出力は確率的です。同じ指示でも、選ぶツールや手順、言い回しが毎回わずかに変わります。つまり、一度うまく動いたからといって、次もうまくいく保証はどこにもありません。
ここに、エージェント開発ならではの落とし穴があります。デモでは見事に動いたのに、実際のユーザーが少し違う頼み方をした途端に破綻する――これは珍しいことではありません。原因は単純で、「動いた＝正しい」とは限らないからです。たまたま正解を引いただけかもしれず、10回中3回は間違えているかもしれません。それを知るには、数えるしかないのです。
💡 測れないものは改善できない。 「なんとなく良くなった気がする」は改善ではありません。プロンプトを変えたら、成功率は上がったのか下がったのか。ツールを1つ足したら、余計に遅くコストが増えていないか。数字で比べられて初めて、変更が前進か後退かを判断できます。評価は「作った後の宿題」ではなく、開発の土台です。
もう一つ大切なのは、評価を後回しにしないことです。最初から完璧な評価基盤は要りません。しかし「まず作って、動いたら評価を考える」と進めると、たいてい評価はいつまでも作られません。小さくてもいいので、最初の1体を作った直後から測り始めるのが、遠回りに見えていちばんの近道です。評価の全体像はAIエージェント評価の実践ガイド、そもそも何を指すかはエージェント評価（evals）とはが入口になります。
何を評価するのか ― 成果と軌跡
「評価する」と聞くと、多くの人は最終的な答えが合っているかだけを思い浮かべます。それは確かに出発点ですが、エージェントではそれだけでは足りません。エージェントは「途中で何をしたか」がとても重要だからです。正しい答えにたどり着いても、無駄なツールを10回呼び、時間とコストを浪費していたら、実務では使えません。逆に、答えは惜しくも間違ったが、途中の判断は正しかった――という場合もあります。
そこで、評価の対象を4つの側面に分けて考えます。この4つを頭に入れておくと、「何を測ればいいか分からない」という迷いが消えます。
与えた目的を達成できたか。答えは正確か、要件を満たしているか。最も基本の指標。
どのツールを、どんな順で、なぜ呼んだか。過程が妥当か。回り道や不要な手順がないか。
正しいツールを、正しい引数で呼べたか。存在しないツールを呼んだり、失敗を放置していないか。
1回の実行で消費したトークン量・料金・所要時間。品質と釣り合っているか。
📊 「軌跡」を測るのがエージェント評価の肝。 普通のAI出力の評価が「答え合わせ」なのに対し、エージェント評価は「答え＋そこに至る過程」を見ます。過程が汚いエージェントは、条件が少し変わると簡単に崩れます。逆に過程が筋の通ったエージェントは、多少ずれても立て直せます。過程を見るからこそ、改善の手がかりが見つかるのです。
評価の5つの手法
「では、どうやって測るのか」――ここが実務の中心です。評価の手法にはいくつか種類があり、それぞれ得意・不得意が違います。1つに頼るのではなく、測りたい対象に応じて組み合わせるのが定石です。代表的な5つを、長所と短所つきで見ていきましょう。
あらかじめ用意した「正解」と、エージェントの出力を突き合わせて一致を測る。分類・抽出・計算のように答えが1つに定まる課題に向く。
長所: 明快で自動化しやすく、ぶれない。
短所: 「正解が1つに決まらない」自由記述には使いにくい。
「必須の語が含まれているか」「JSONとして正しい形式か」「禁止語がないか」など、決まった条件で機械的に判定する。
長所: 高速・低コストで、形式や安全条件のチェックに強い。
短所: 「意味が合っているか」といった曖昧な品質は測れない。
別のLLMに採点基準を渡し、出力の良し悪しを評価させる。要約の質や回答の親切さなど、正解が1つに決まらない課題を測れる。
長所: 自由記述や主観的な品質を、大量に自動評価できる。
短所: 採点者自身がぶれる／偏る。基準の明文化と人手での抜き取り確認が要る。
代表的なタスクをテストセットにまとめ、変更のたびに一括で走らせる。「昨日まで通っていたものが、今日の修正で壊れていないか」を守る仕組み。
長所: 変更による劣化（デグレ）を早期に検知できる。
短所: テストセットの整備と維持に手間がかかる。
リリース後、実ユーザーの実行を継続的に観測する。成功率・コスト・遅延の推移や、ユーザーの評価（👍／👎）を集めて現実の性能を追う。
長所: 実環境でしか出ない問題や、想定外の使われ方を発見できる。
短所: 事後的。問題は「起きてから」しか分からない。事前評価と併用が前提。
⚠️ 組み合わせが基本。 形式や安全条件はルールベースで、答えが定まるものは正解照合で、自由記述はLLM-as-judgeで、変更のたびに回帰テストで、そしてリリース後は本番モニタリングで。1つの手法で全部を賄おうとしないこと。安く速い手法（①②）で大部分をふるいにかけ、高価な手法（③）は必要な部分にだけ使うと、コストを抑えつつ精度を保てます。より詳しくはLLM評価とはを参照してください。
評価データ（テストセット）の作り方
どんな手法を使うにも、土台になるのが「何を測るかの材料」＝評価データ（テストセット）です。これは要するに、「こういう入力に対して、こういう結果になってほしい」という代表的なタスクを集めたものです。ここが貧弱だと、どんなに立派な評価手法もあてになりません。逆に、良いテストセットさえあれば、評価の8割は成功したようなものです。
作り方はシンプルで、次の順に進めます。完璧を目指すより、まず小さく始めて育てるのが鉄則です。
エージェントに実際に頼まれそうな依頼を、典型・境界・失敗しやすい例を含めて集める。
各タスクの「こうなってほしい」を書く。正解でも、満たすべき条件でも、採点基準でもよい。
最初は10〜20件で十分。数より、現場の実態を映す「質」を優先する。
本番で見つかった失敗例をテストセットに追加していく。使うほど賢くなる資産になる。
✅ 「たった10件」を侮らない。 「サンプルが少なすぎて意味がない」と感じるかもしれません。しかし、丁寧に選んだ10件は、漫然と集めた1000件よりずっと役立ちます。実際に困っている代表的なケースを10件、まず測れるようにする。それだけで、プロンプトやツールの変更が良い方向か悪い方向かを、その場で判断できるようになります。テストセットは一度作って終わりではなく、失敗を見つけるたびに1件ずつ足して育てる、生き物のような資産です。
可観測性 ― 動きを見える化する
評価が「良し悪しを測る」ことなら、可観測性（オブザーバビリティ）は「なぜそうなったかを追える」ようにすることです。評価で「成功率が下がった」と分かっても、その中で何が起きていたかを見られなければ、直しようがありません。エージェントは複数のステップを内部で回すため、外から見ると「入力を入れたら、何かあって、結果が出た」というブラックボックスになりがちです。これを開けて中を見えるようにするのが可観測性です。
可観測性を支える要素は、大きく3つあります。
1回の実行を最初から最後まで通しで記録したもの。「入力→思考→ツール呼び出し→結果→次の判断」の一連の流れを、時系列でまるごと追える。
個々のステップで、どんなプロンプトを送り、どんな引数でツールを呼び、何が返ってきたか。トークン消費や所要時間もここに残す。
問題が起きた実行を、同じ入力・同じ状態でもう一度たどれること。再現できて初めて、原因の特定と修正の検証ができる。
これらを手作業でログに書き足していくこともできますが、実務ではトレーシングツールを使うのが一般的です。トレーシングツールは、エージェントの各ステップを自動で捕まえて、時系列のツリーとして見やすく可視化してくれます。「どのステップで時間がかかったか」「どこでツール呼び出しが失敗したか」「どの判断でおかしな方向へ逸れたか」が一目で分かるようになります。
📊 トレースは「デバッグの目」。 上の例では、④でツール呼び出しに失敗し、⑤でエージェント自身が立て直しています。結果だけ見れば「成功」ですが、トレースを見れば「列番号を間違えやすい」という弱点が見えます。この気づきが次の改善につながります。可観測性の考え方はAIの可観測性（オブザーバビリティ）とはで体系的に解説しています。
改善のループを回す
ここまでの道具立て――評価とテストセット、そして可観測性――は、それぞれ単体でも役立ちますが、真価が出るのは1つのループとして回したときです。エージェント開発は「一度作って完成」ではなく、測って、弱点を見つけて、直して、また測るという循環で少しずつ良くしていく営みです。
テストセットに対して評価を走らせ、成功率・コスト・遅延を数字で出す。
失敗した実行のトレースを読み、どこで・なぜ間違えたかを突き止める。
プロンプト・ツールの説明・手順・分担など、原因に当たる部分を1つ変える。
同じテストセットで再評価し、狙った改善が出たか・他が悪化していないかを確認する。
このループで大事なコツが1つあります。一度に変えるのは、できるだけ1つに絞ることです。プロンプトもツールも手順も同時に変えてしまうと、成功率が上がっても「どの変更が効いたのか」が分からなくなります。1つずつ変えて測るからこそ、変更と結果の因果がつながり、知見が蓄積されていきます。地味ですが、これが「なんとなくの改善」と「確実な改善」を分ける境目です。
✅ ループは速く、小さく回す。 大きな改修を1回どんと当てるより、小さな変更を素早く何度も回すほうが、結果的に速く良くなります。テストセットが10件あれば、変更してすぐ測れます。この「変えて→即測る」のリズムが身につくと、エージェント開発は勘の当てものではなく、着実に前進する工学作業に変わります。
- エージェントは確率的で「動いた＝正しい」とは限らない。測らなければ改善できない。
- 評価対象は4側面 ― 最終成果・途中の軌跡・ツール呼び出し・コストと遅延。特に「軌跡」がエージェント評価の肝。
- 手法は5つ ― 正解照合・ルールベース・LLM-as-judge・回帰テスト・本番モニタリングを、対象に応じて組み合わせる。
- 評価データは代表タスクを少数から。丁寧な10件は漫然とした1000件に勝る。失敗を足して育てる。
- 可観測性は実行トレース・各ステップのログ・失敗の再現。トレーシングツールで動きを見える化する。
- 改善は測る→弱点発見→直す→また測るのループ。変更は1つずつ、小さく速く回す。
品質を測り、動きを見えるようにできたら、次は「暴走・誤操作・悪用をどう防ぐか」です。前章の第4章「マルチエージェント設計」で増やした自律性を、安全に扱うための設計を学びましょう。次の第6章「ガードレールと安全」へ進みます。