AIエージェントの評価設計とは？Anthropicの考え方をCRM業務で理解する

答えは、報告の文章（記録）と保存先の状態（結果）を分け、後者だけを合否の根拠にすることである。

記録は原因を調べるときに読むもので、合否を決める材料ではない。合否は結果の列だけで決める。この区別は、エージェントの能力が上がるほど重要になる。報告の文章が上手になり、読んだだけでは失敗が見えなくなるからだ。

成功条件は、保存先を見れば真偽が決まる形で書く。「211件が有効応募として登録されている」「84件に担当者と段階が入っている」のように、件数と項目で書く。「概ね正しく更新された」は条件にならない。誰が見ても同じ判定になる書き方だけが、評価の条件として機能する。

同時に、何をしないことが正解かも決める。変更が不要なレコードには触れない、確信の無い項目は空のまま人に回す、といった正しい保留がそれにあたる。書き込み件数や埋めた項目数だけを評価すると、この保留が低く採点され、エージェントは埋めるほど良いと学ぶ。

答えは、投入前に期待値を書き、投入後に実物を取り、ずれを並べてから判定することである。

期待値表を投入前に書くことに意味がある。投入後に書くと、実物に合わせて期待値を都合よく変えてしまう。差異表を残すのは、次の評価で「前回はどこがずれたか」から始められるようにするためだ。

確かめ方は項目ごとに分ける。同記事も、コードで採点する方法、モデルに採点させる方法、人が採点する方法を、対象に応じて選ぶよう勧めている。件数、必須項目の空き、重複、参照先の形式はコマンドで確かめられる。列の中身が業務として正しいか、たとえば段階の定義に合っているか、除外すべき行が混ざっていないかは、サンプルを人が読む。すべてを人が読むと評価が回らず、すべてをコードに任せると業務の誤りを見逃す。

一度合格しただけでは足りない。同記事は同じタスクを複数回試行し、一度でも成功する確率と、全回成功する確率を分けて見ることを勧めている。業務に乗せるかどうかは後者で判断する。同じ入力で結果が揺れるなら、直すのは期待値ではなく、指示や手順の側である。

答えは、期待値表の数字と保存先の件数が一致したときにだけ、完了とすることである。

当社が支援した例を一つ挙げる。イベント運営会社（企業名非公開）のスタートアップ支援プログラムで、応募フォーム3種・472行を突合し、有効応募211件を確定し、CRMを84件更新した。完了の判定に使ったのは「処理が終わりました」という報告ではなく、CRMの行数が211件になったこと、書き込み84件の内訳が期待値と一致したことである。変更不要と判定した30件は書き込まないことを正解とし、書き込み件数の多さでは評価しなかった。件数は2026年8月の処理時点の実測で、件数や項目の構成が違う業務に同じ期待値をそのまま当てはめることはできない。

「処理しました」は記録であり、行数と内訳が合って初めて結果になる。

判定の後に行動が続く。合格なら次の投入へ進む。条件付きなら差異表を残して続行する。不合格なら再実行するが、上限を決めておき、上限を超えたら実行のやり直しではなく指示や定義の問題として人に戻す。削除すべきレコードを見つけても、削除は人が承認してから行う。判定を点数で終わらせず、次の行動につなげるところまでが評価設計に含まれる。

答えは、最初から大量のテストケースを用意せず、最近人が直した例を期待値表の最初の行にすることである。

任せたい仕事を一つ選び、直近で人が直した出力を集める。何が間違いで、正しくはどうあるべきで、誰が判定できるかを書けば、それが評価表の1行になる。同記事が勧める「実際の失敗から集めた20〜50件」も、理想の状態から作るのではなく、既に起きた失敗から作る発想だ。評価表は理想から書くのではなく、直した記録から書く。

明日からやることは3つで足りる。エージェントに任せている業務を一つ選び、完了の条件を件数と項目で書く。最近人が直した出力を5件集め、何が間違いだったかを1行ずつ書く。次の投入で、報告を読む前に保存先の件数を取り、期待値と並べる。評価の基準を誰が決め、実測と推定をどう区分するかはAI評価設計者とは何をする人かで、事例の処理手順はCRM一元管理の支援事例で扱っている。