AIを業務に入れた直後は、たいていうまく動きます。メールの下書き、議事録の整理、問い合わせの一次返答。どれも「いい感じ」に返ってきて、これは行けるという手応えがあります。
半年後、現場から声が漏れ始めます。「最近、返答がズレてない？」「前はもっと良かった気がする」。この「気がする」で運用してきた会社が、ここで止まります。反論もできず、対策も決まらない。Anthropicの記事にある評価設計（Evals）は、この行き止まりへの正面からの答えでした。
先にまとめ
評価設計とは、AIに入力を渡して、出てきた答えに採点を当てる仕組みです。目的は1つ、「気がする」を「測れる」に変えること。採点役は、機械・AI・人の3種類を役割分担させます。始め方は、過去の失敗を20件集めて、月1回同じ入力を投げ直すだけ。Excelと30分で足ります。
AIを業務に入れ始めた、または検討している経営者・担当者に向けた内容です。機械学習の評価指標の解説を求める方には向きません。
「気がする」運用が詰む理由
測る仕組みがない運用は、事故が起きてから動くループに入ります。クレームが来て、状況を再現して、原因を手作業で探して、直したつもりで他が壊れていないことを祈る。そして次のクレームを待つ。
このループの何がつらいかというと、いつ何が悪化したのかが分からないことです。悪くなった瞬間を特定できないので、戻すこともできません。3か月、半年と経つうちに、最初の「いい感じ」と現場の体感がじわじわ離れていきます。
しかも、悪化の原因は1つとは限りません。プロンプトを少し変えた。参照する資料が増えた。担当者が交代した。モデルが更新された。どれも単体では小さな変更です。測っていなければ、どれが効いたのかを後から切り分ける手段がありません。
そのうち、経営側は「AIの効果がよく分からない」と言い始め、現場は「言うほど使えない」と諦め始めます。どちらも間違っていません。判断する材料が無いだけです。
評価とは、要するに何をすることか
定義は驚くほど単純です。AIに入力を与え、出てきた答えに採点のルールを当てて、どれくらいうまくいったかを測る。これだけです。
身近なものに置き換えると、いくつも思い当たります。表計算の関数を直したあと、いつものサンプル20件で同じ結果が出るか確かめる作業。採点者によってぶれないように、合格の条件を先に文書化しておく入社試験。レシピを変えたあと、味見係が「前と同じ味か、良くなったか」を判定する飲食店。
どれも、やっていることは同じです。「気がする」を「測れる」に変えている。AIの業務にこれを持ち込むのが、評価設計です。
数値になると、議論が対策に変わる
「最近、AIのメール返信が雑になった気がする」。これは個人の感覚なので、「いや、自分は十分だと思う」と返された時点で議論が止まります。誰も悪くないのに、何も進みません。
「先月は平均4.2点だったのが、今月は3.6点に下がっている」。こうなると、そもそも議論になりません。すぐ対策の話に移れます。この一段の差が、評価設計の本体です。精度を上げる技術というより、話を前に進めるための道具だと考えたほうが近い。
採点役は3種類ある
誰が採点するか。公式では3種類に分けられています。どれか1つを選ぶ話ではありません。
| 採点役 | 得意なこと | 注意点 |
|---|---|---|
| 機械（プログラム） | 速い、客観的、何度でも無料で回せる | 想定外の正解に弱い |
| AI | ニュアンスを汲める、柔軟 | 採点役そのものの調整が要る |
| 人 | いちばん確か。基準づくりの土台になる | 数をこなせない、費用がかかる |
効きどころは、3つを組み合わせることです。機械で毎日の自動チェック、AIで週に1回のニュアンス確認、人で月に1回の抜き取り。役割を分ければ、費用を抑えたまま品質を見張れます。
よくある失敗は4つ
1つめは、仕様が曖昧なこと。専門家でも合否を判定できないテストは、測るほどノイズが増えます。2つめは、逆に手順を縛りすぎること。「この順番で進めよ」と決めると、AIが別のやり方で成功しても失敗と判定されます。
3つめは、片側だけを見ること。「やるべき場面」ばかり試して、「やってはいけない場面」を見落とす。事故はたいてい後者で起きます。
4つめ：点数だけ見て、中身を読まない
いちばん多い落とし穴です。スコアが80点で安定していても、実際のやり取りを10件読むと「全部、同じ間違い方をしている」と気づくことがあります。数値と中身を両方見る。これは鉄則です。
読むのは全件でなくて構いません。合格したもの3件と、落ちたもの3件。それだけでも、採点の基準がずれていないかは見えてきます。
4つとも、技術の失敗ではありません。測り方の設計の失敗です。だから、専門知識がなくても避けられます。
今日から始める「20件サンプル」
公式が強調しているのは、20〜50件の実際の失敗事例から始めることです。立派なベンチマークを探すより、自社で本当に起きた失敗を集めたほうが、はるかに使える評価セットになります。
- 過去3か月で、AIが間違えた事例を20件集める。
想定外の出力もここに入れます。 - 各事例に「あるべき出力」を1行で書く。
長く書く必要はありません。 - 月に1回、同じ20件をAIに投げ直す。
いまの出力と「あるべき」を見比べます。 - 合格率が下がっていたら、手を入れる。
下がった月に気づける。これが目的です。
集めるときのコツが1つあります。「うまくいかなかった」ではなく、「何がどう違ったか」を書くことです。返答が長すぎた。敬語が固すぎた。金額を勝手に補った。存在しない機能を案内した。粒度が細かいほど、あとで採点に使えます。
大がかりなツールも、機械学習の知識も要りません。表計算と、月1回の30分。それだけで「気がする」運用から抜けられます。
まとめ：測り方の準備は、導入と同じ日に
i-Styleでは、評価設計を「導入と同時に始める前提作業」と捉えています。完璧な評価セットは要りません。20件でも、無いよりはるかに効きます。
もう1つ、地味な効き目があります。評価セットを持っている会社は、道具の乗り換えに強い。「うちの20件で測ったら、新しいAIのほうが高い」と言えれば、流行りに振り回されずに選べます。逆に持っていなければ、毎回宣伝文句を信じるしかありません。
冒頭の「前はもっと良かった気がする」。半年後にこの言葉が出たとき、頷くしかない会社と、数字を出せる会社に分かれます。分かれ道は、導入した日にありました。
参考: Demystifying evals for AI agents（Anthropic Engineering Blog）
AI 評価設計の社内導入、設計から伴走します
「20 件サンプルを集める」「採点基準を作る」── ここを自社だけでやろうとすると、最初の設計で躓きがちです。i-Style は、評価セットの初期構築から月次運用の習慣化まで、現場感のある手順で伴走します。
お問い合わせページへ arrow_forward
関連記事
