AI を業務に入れた直後は、たいていうまく動きます。営業のメール作成、議事録の整理、問い合わせの一次返答── どれも「いい感じ」に動いて、「これは行ける」と感じる。
ところが半年後、現場から不満が漏れ始めます。「最近、AIの返答ズレてない?」「前はもっと精度良かった気がする」──。「気がする」で運用してきた会社は、ここで詰みます。
Anthropic の公式エンジニアリングブログに、この問題の正面突破口が書かれています。評価設計(Evals)。AI 業務に動作確認テストを書く仕組みです。本記事では、その内容を中小企業視点で噛み砕いて、実装の入口まで案内します。
この記事を読むとわかること
- check_circle『動いてる気がする』運用が半年後に詰む構造
- check_circle評価(Evals)とは何か、何をしているのか
- check_circle3 つの採点方式と、よくある失敗 4 パターン
- check_circle中小企業が今日から始められる「20 件サンプル」の作り方
この記事の読者層
- 向き：AI を業務に組み込み始めた、または導入を検討している中小企業の経営者 / 担当者
- 向かない：機械学習の評価指標(precision / recall 等)の専門解説を求めている方 ── 本記事は経営判断レイヤーの解説です
『動いてる気がする』運用がなぜ詰むのか
Anthropic の表現を借りると、評価設計のない運用は 「事故が起きてから動く」 ループに入ります。
- check_circleクレームが来てから状況を再現する
- check_circle手作業で原因を特定する
- check_circle修正したつもりで他の機能が壊れていないか祈る
- check_circleまた別のクレームを待つ
これだと、いつ何が悪化したか分からないまま品質が下がっていきます。3 ヶ月、半年と時間が経つと、最初の「いい感じ」と現場の体感はどんどんズレる。経営者は「AIの効果がよく分からない」と感じ始め、現場は「言うほど使えない」と諦め始めます。
評価(Evals)とは何か ── 噛み砕いて言うと
Anthropic の定義はシンプルです。「AIに入力を与え、出力に採点ロジックを当てて、成功度合いを測る」。これだけ。
身近なものに置き換えると、いくつか比喩があります。
- check_circleExcel の動作確認テスト ── 関数を直したあと、いつものサンプル 20 件で同じ結果が出るかチェック
- check_circle入社試験の採点基準 ── 採点者によってばらつかないように、合格条件を事前に文書化
- check_circle料理店の試食 ── レシピを変えたあと、味見係が「以前と同じ味か / 改善されたか」を判定
- check_circle監査(audit) ── 後から「なぜそう判断したか」を追える記録を残す
- check_circle回帰テスト ── 一度動いた機能が、修正後も同じように動くことを毎回確認
どれも、「気がする」を「測れる」に変える 仕組みです。AI業務にこれを持ち込む ── それが評価設計です。
メンタルモデル: 「『気がする』を『測れる』に変える」
この記事から 1 つだけ持ち帰っていただきたい概念がこれです。評価設計の目的は、品質判断を主観から数値に移すこと。
「最近 AI のメール返信が雑になった気がする」── これは個人の感覚なので、「いや、自分は十分だと思う」と返されたら議論が止まります。
対して、「先月は平均スコア 4.2/5 だったが、今月は 3.6/5 に下がっている」── これだと議論にならず、対策の話に進めます。この一段の差が、評価設計の本質 です。
3 つの採点方式
Anthropic 公式は、評価における採点者(Grader)を 3 種類に分類しています。
| 採点方式 | 特徴 | 注意点 |
|---|---|---|
| コードベース | 高速・客観的・無料で何度でも回せる | 想定外の正解パターンに弱い(脆い) |
| モデルベース(LLM 採点) | ニュアンスを汲める、柔軟 | 採点モデル自体の調整(較正)が必要 |
| 人間 | 最高品質の判定。基準を作る土台にも | スケールしない、コスト高 |
効きどころは 「3 つを組み合わせる」 こと。コードベースで日次の自動回帰、モデルベースで週次のニュアンス確認、人間で月次のサンプリングレビュー。役割分担すれば、コストを抑えつつ品質を見張れます。
よくある失敗 4 パターン
設計ミスでよく起きる 4 つ
- check_circle仕様があいまい ── 専門家でも合格判定できないテストはノイズが大きい
- check_circle手順を厳密に決めすぎる ── 「ツールAをこの順で呼べ」と縛ると、AI が別ルートで成功しても失敗判定になる
- check_circle片側だけのテスト ── 「やるべき場面」のみテストし、「やってはいけない場面」を見逃す
- check_circletranscript(やり取りの記録)を読まない ── スコア数値だけ見て、実際の入出力を見ないと評価自体が壊れていることに気づけない
とくに 4 つ目「transcript を読まない」は、肌感覚で 最も多くの会社がハマる落とし穴。スコアが 80% で安定していても、サンプルを 10 件読んだら「あ、これ全部 同じ間違い方をしてる」と気づくことがあります。数値と中身、両方見る のが鉄則です。
中小企業が今日から始められる「20 件サンプル」
Anthropic 公式が強調しているコツは、「20〜50 件の現実の失敗事例から始める」。理論的なベンチマークから始めるより、実務で実際に起きた失敗を集めるほうが、はるかに使える評価セットになります。
中小企業向けに翻訳すると、こうなります。
- 過去 3 ヶ月で AI が間違えた / 想定外の出力を出した事例を、Excel に 20 件 集める
- 各事例に「正解(あるべき出力)」を 1 行ずつ書く
- 月に 1 回、その 20 件を AI に再投入し、現在の出力と「正解」を比較する
- 合格率が下がっていれば、プロンプトや運用を見直す
これだけです。大げさなツールも、機械学習の知識も不要。Excel と月 1 回の手作業で、「気がする」運用から脱却できます。
30 分でできる実験
理屈より、手を動かすのが速いです。今すでに AI を業務で使っているなら、今日のうちに次の手順を試してみてください。
- AI が 最近 1 ヶ月で間違えた事例 を 5 件、思い出して書き出す
- それぞれに「あるべき出力」を 1 行で書く
- 同じ入力をいま AI に投げて、出力を比べる
- 5 件中、何件が「あるべき」に近いかを記録する
30 分で、自社の AI 品質の現在地が 数値として手に入ります。これは来月以降、改善の証拠になる起点です。
私たちは、評価設計を 「導入と同時にスタートさせる前提作業」 と捉えています。完璧な評価セットは要らない。20 件のサンプルでも、無いよりはるかに効きます。
逆に言えば、評価設計を持っている会社は AI ベンダーやプロンプトの乗り換えに強い。「うちの 20 件で測ったら、新しい AI のほうが 8% 高いスコア」という判断ができれば、流行りの技術にも振り回されずに済みます。これは半年後、3 年後にじわじわ効いてくる土台です。
まとめ
- check_circle評価設計のない AI 運用は、半年後に「気がする」議論で詰まる
- check_circle評価とは「気がする」を「測れる」に変える仕組み
- check_circle採点方式 3 種(コード / モデル / 人間)を役割分担で組み合わせる
- check_circleよくある失敗 4 つ(あいまい仕様 / 手順固定 / 片側テスト / transcript 未読)
- check_circle中小企業の入口は「Excel に 20 件、月 1 回の手作業評価」で十分
AI を業務に組み込むということは、「使えるかどうか」を 数値で語れる体制を作る こととセットです。導入と同じ日から、測り方の準備を始めるのが結局の近道です。
参考: Demystifying evals for AI agents(Anthropic Engineering Blog)
AI 評価設計の社内導入、設計から伴走します
「20 件サンプルを集める」「採点基準を作る」── ここを自社だけでやろうとすると、最初の設計で躓きがちです。i-Style は、評価セットの初期構築から月次運用の習慣化まで、現場感のある手順で伴走します。
お問い合わせページへ arrow_forwardまずはチャットボットで相談できます
記事の内容について「自社の場合はどう考えればいいか」を軽く確認したい方は、i-Styleサポートデスクbotもご利用ください。問い合わせ前の整理や、AI活用・Web活用の最初の相談窓口としてお使いいただけます。
i-Styleサポートデスクbotで相談する arrow_forward関連記事