本番で動かすAIエージェントの成否は、モデルの賢さだけでは決まりません。応答・ツール呼び出し・検索を継続的に測る評価基盤、つまり評価ハーネスがあるかどうか。デモでは完璧に動いたエージェントが本番で崩れるとき、元記事（Towards Data Science）は、その原因をモデルの性能不足よりも「失敗を検知する仕組み（評価ハーネス）の欠如」に見ています。この記事を読めば、なぜ評価ハーネスが必要なのか、12の指標を検索・生成・エージェント挙動・本番健全性の4層でどう設計するのか、ハルシネーション率とツール選択精度を実際にどう計測し、どの閾値で回帰を弾くのかまで、本番運用に組み込める形で全部わかります。
評価ハーネスとは、AIエージェントの応答・ツール呼び出し・検索を継続測定する検証基盤。
- 同記事は、本番のAIエージェントが崩れる大きな原因のひとつを、モデル性能ではなく評価基盤の欠如にあると整理している
- 12指標のうち、特に事故につながりやすいのが「ハルシネーション率」と「ツール選択精度」
- 12指標を4カテゴリで整理。元記事では、運用上の閾値例としてハルシネーション率2%未満などが示されている
ここから先は、まず「なぜ崩れるのか」を2つの角度から見ます。ひとつは元記事が示す評価基盤の欠如、もうひとつはRedditの現場報告が示す実行層の脆さ。痛点を提示しきったうえで、12指標の全体像と、ハルシネーション検知・ツール選択精度という2大テーマへ進みます。
評価ハーネスが無いAIエージェントが本番で崩れる理由
AIエージェントの本番投入でつまずく構図には、はっきりした型があります。元記事（Towards Data Science）が紹介する匿名の事例では、ある医療領域のデプロイで、運用開始からしばらく後にコンプライアンス担当者から、エージェントが患者の症状を根拠なく生成していないことをどう示すのか、という趣旨の問いが投げられたとされています。
開発チームには単体テストがあり、結合テストもあり、デモ用データセットでは美しく動くモデルもありました。足りなかったのは、本番でハルシネーション率・文脈忠実度・ツール選択精度を測れる評価ハーネスです。このギャップがプロジェクトを瀕死に追い込みました。6週間後、すべての応答・すべてのツール呼び出し・すべての検索操作に対して走る12指標の評価フレームワークを組み上げ、ようやくコンプライアンス部門の署名（sign-off）を得てエージェントは出荷された——元記事はそう振り返っています。
この話の核は単純です。問題はモデルが馬鹿だったことではない。失敗を検知する基盤が無かったこと。賢さの問題ではなく、検証基盤の問題でした。本番のAIエージェントを語るとき、この一点を取り違えると、いくらモデルを差し替えても同じ場所で崩れ続けます。
デモは完璧、本番で崩れるという定番パターン
デモ環境のエージェントは、用意されたシナリオの上を走ります。入力は想定内、データは整っていて、評価する人間も「うまくいく流れ」を知っている。ここで完璧に見えるのは当然と言えるでしょう。
ところが本番は違います。ユーザーは想定外の質問を投げ、検索対象のドキュメントは更新され、外部APIは時々タイムアウトする。デモで一度も踏まなかった分岐を、本番は初日から踏み抜きます。そして崩れたとき、それを「崩れた」と判定する物差しが無ければ、エージェントは静かに間違った答えを返し続ける。誰も気づかないまま、です。
評価ハーネスの役割は、この「気づかない」をなくすことにあります。デモの成功は一回限りのスナップショット。本番の信頼性は、毎回の応答を測り続けることでしか担保できません。一度通ったテストは、明日も通る保証にはならないのです。
テストが通ってもハルシネーションは捕まえられない
従来のソフトウェアテストは、入力に対する出力が決まっています。2 + 2 は必ず 4 になる。だから期待値と実値を突き合わせれば合否が出ます。
LLMを核に持つエージェントは、この前提が崩れます。同じ質問でも応答の文面は毎回変わり、しかも「文面は違うが意味は正しい」場合と「もっともらしいが事実が間違っている」場合がある。単体テストや結合テストは、コードが落ちないこと・APIが繋がること・例外が出ないことは確かめられます。けれど、返ってきた文章が事実に忠実か、検索した文脈と矛盾していないかは、従来型テストの守備範囲の外。
ここに評価ハーネスが必要になる理由があります。ハルシネーション（モデルが事実に基づかない内容を生成する現象）は、コードのバグのように例外で表面化しません。正常に処理が完了し、整った日本語で、堂々と嘘をつく。だからこそ「事実との一致度」を専用の指標で測り、閾値を割ったら止める仕組みが要ります。テストの緑色は安心の証ではなかった、という話です。
実際に詰まるのは「実行層」だった
評価基盤の欠如が「失敗を見逃す」問題なら、もうひとつ別の角度から本番を崩す原因があります。エージェントが計画は立てられても、その計画を実環境で実行できないという問題。Reddit の r/automation などでは、この実行層（ツールに実際に接続して操作する層）の脆さを指摘する投稿が見られます（投稿者の経験談であり、業界全体の統計ではありません）。
ある投稿者の報告では、紙の上ではすべてが綺麗に見えたといいます。モデルはタスクを理解し、ステップに分解し、正しい計画を出す。ところが実際のツールに接続した瞬間、信頼性をもって動かなくなった。これがスタートアップの社内ツールでも、大企業のSaaSスタックでも、毎回同じ場所で詰まったと書かれています。
Reddit 上では、失敗点はいつも同じだという指摘が繰り返されます。エージェントは「考える」ことはできるが、実際のWeb環境では「何も実行できない」。強力なものを作ったのに、ゴール直前で毎回引っかかる感覚——投稿はそう表現していました。評価ハーネスを設計するなら、この実行層こそ、捕まえるべき現実の対象になります。
APIが無くUIしか無いツールの壁
実行層がもろくなる第一の理由は、業務ツールの多くがAPIを持たず、UI（画面操作）でしか触れないことにあります。Reddit の投稿が列挙していた破綻点を、帰属を保ったまま整理すると次のようになります。
– 重要なツールにAPIが存在せず、UIアクセスしか手段がない – SSO・MFAといったログインフローが自動化を即座に止める – セッションがタスクの途中で切れ、ワークフローがリセットされる – UIの変更がスクリプトやセレクタを静かに壊す – ダッシュボード内にしか存在せず、APIから呼べない操作がある – ボット検知が、本物のユーザーらしく振る舞わない動作をブロックする
これらはいずれも「ある投稿者の報告」であり、数値として一般化されているわけではありません。それでも、本番のエージェントが触る現実のツール群がこうした性質を持つこと自体は、評価設計の前提として押さえておく価値があります。賢いモデルを用意しても、触る相手がUIしか開いていなければ、信頼性のある実行は構造的に難しい。
認証・セッション・UI変更という保守地獄
仮にUIを自動操作する仕組みを組んだとしても、その先に保守コストの膨張が待ちます。投稿者の指摘を追うと、UIは予告なく変わり、変わるたびにセレクタが壊れ、書いたスクリプトが沈黙する。セッションは途中で失効し、ワークフローは最初からやり直しになる。
Reddit 上では、こうした企業ツールの作りは「人間の介在を前提に設計されている」ためだ、という見方も挙がっています。公開APIがない、または自動化対象として設計されていない画面では、UI変更・認証・セッション管理が信頼性のボトルネックになりやすい、という整理です。ここで効いてくるのが評価ハーネスです。ツール選択は合っていたのに実行層で破綻した、という失敗を分離して観測できれば、「モデルを直すべきか、接続層を直すべきか」の切り分けが効きます。崩れる場所を特定できることが、保守地獄から抜ける最初の一歩になります。
12指標フレームワークの全体像（4カテゴリ）
ここまでで「見逃す失敗」と「実行できない失敗」という2種類の崩れ方を見てきました。これらを継続的に捕まえるために、元記事は12の指標を4つのカテゴリに整理しています。検索（Retrieval）、生成（Generation）、エージェント挙動（Agent）、本番健全性（Production）の4層です。
全体像を俯瞰すると次の表になります（各カテゴリの指標は代表例で、12指標の正式名称はベース記事の原文を参照してください）。閾値の具体値は元記事が示す閾値例で、本文中ではこのうち代表値だけを扱います。
| カテゴリ | 代表的な指標 | 何を測るか | 位置づけ |
|---|---|---|---|
| 検索（Retrieval） | 文脈関連性・文脈再現率・文脈精度・検索レイテンシ | 必要な情報を正しく・速く拾えたか | 後段すべての土台 |
| 生成（Generation） | 回答忠実度・回答関連性・ハルシネーション率 | 拾った文脈に忠実で、質問に答えているか | 信頼性の第1痛点 |
| エージェント挙動（Agent） | ツール選択精度・ツール実行成功率・マルチステップ一貫性 | 正しいツールを選び、実行し、手順全体が破綻していないか | 信頼性の第2痛点 |
| 本番健全性（Production） | クエリあたりコスト・P99レイテンシ | 運用として速く・安く回るか | ビジネス継続性の担保 |
注意したいのは、この4分類が「指標を12個並べた一覧」ではない点です。検索が間違えば生成が汚染され、生成がハルシネーションを起こせばエージェントの行動が狂い、それらが積み重なって本番の健全性が落ちる。下の層の失敗が上の層へ伝播する因果の鎖になっています。だから測る順序にも意味があります。
なぜ4カテゴリに分けるのか
4つに割る理由は、失敗の発生源を切り分けるためです。エージェントが間違った最終回答を返したとき、原因が「検索が悪かった」のか「検索は正しいのに生成がハルシネーションした」のか「生成も正しいのにツール選択を誤った」のかで、打つ手はまったく変わります。
すべてを「正解率」のような単一の指標で測ると、この切り分けができません。スコアが下がったことはわかっても、どこを直せばいいのかが見えない。カテゴリを分けておくと、検索カテゴリの数値だけが落ちた、生成は健全だがエージェント挙動が荒れている、といった形で故障部位が浮かび上がります。
実運用では、この切り分けがそのままアラートの設計に直結します。検索レイテンシが悪化したらインフラ側、ハルシネーション率が跳ねたらプロンプトや検索品質側、ツール選択精度が落ちたらツール定義側、と通知の宛先を分けられる。4カテゴリは分類の美しさのためではなく、直す人にボールを渡すための区分けだと考えてください。RAG（検索拡張生成。外部知識を検索してから回答を生成する仕組み）を採用したエージェントでは、検索カテゴリの重みが特に大きくなります。
検索カテゴリ — 関連性と忠実度を測る
検索カテゴリは4層の最下層であり、ここが崩れると後段すべてが汚染されます。RAG構成のエージェントを思い浮かべるとわかりやすい。ユーザーの質問に対して、まず知識ベースから関連しそうな文章の断片（チャンク）を拾い、それを文脈としてモデルに渡して回答を作らせます。最初の「拾う」が外していたら、どんなに優秀なモデルでも正しく答えようがありません。
同記事は、この検索品質を複数の指標で多面的に測ります。文脈関連性は「拾ったチャンクが質問に関連しているか」、文脈再現率は「利用可能な関連情報を取りこぼさず拾えたか」、文脈精度は「上位にランクされたチャンクこそが最も関連が高いか」を見ます。さらに検索レイテンシで「どれだけ速く拾えたか」を測る。関連性・再現率・精度・速度の4つで検索の健全性を立体的に捉える設計です。
関連性と再現率はなぜ別々に測るのか
関連性と再現率は似ているようで役割が違います。関連性は「拾ったものが的外れでないか」、再現率は「拾うべきものを拾い逃していないか」。
たとえば知識ベースに、ある質問の答えに必要な文章が5つあるとします。エージェントが5つすべてを拾えば再現率は満点。けれど同時に無関係な文章を10個も巻き込んでいたら、関連性は低い。逆に、ど真ん中の1つだけを拾って残り4つを取りこぼせば、関連性は高いのに再現率は低くなる。片方だけでは検索の良し悪しが判定できないわけです。
実務では、この2つはトレードオフになりがちです。拾う件数を増やせば再現率は上がるが、ノイズが混じって関連性と精度が下がる。件数を絞れば関連性は上がるが、取りこぼしで再現率が落ちる。だから両方を同時に観測し、自分のユースケースでどちらをどこまで許容するかを決める必要があります。医療や法務のように取りこぼしが致命的な領域では再現率を厚く、回答の簡潔さが価値になる用途では関連性と精度を優先する、といった判断です。
拾った文脈と答えが矛盾していないか
検索カテゴリで見落とされがちなのが、拾った文脈と最終的な答えの整合です。これは次の生成カテゴリの「回答忠実度」と地続きの観点で、検索が正しくても、モデルがその文脈を無視して別の知識で答えてしまえば意味がありません。
運用視点では、「正しい文脈を渡したのに、答えがその文脈に書かれていないことを主張している」という状態を捕まえたい。検索は成功、生成は文脈無視、という分解ができて初めて、原因が検索側なのか生成側なのかが切り分けられます。RAGのハルシネーションをコードレベルで検証する手順は別記事で扱っていますが、その出発点はこの「文脈と答えの矛盾を測る」という発想にあります。検索カテゴリは単独で完結せず、生成カテゴリと組で評価して初めて機能する層だと捉えてください。
生成カテゴリ — ハルシネーション検知の閾値設計
生成カテゴリは、この記事の第1の痛点であるハルシネーション検知の中心です。検索で正しい文脈を渡せても、生成段階でモデルが事実を捏造すれば、エージェントの出力は信頼できません。ベース記事の冒頭で医療デプロイのコンプライアンス担当が突きつけた問い——「患者の症状をハルシネーションしていないと証明できるか」——に答える指標が、ここに集まっています。
生成カテゴリの代表指標は3つ。回答忠実度は「答えが、拾った文脈と一致しているか」、回答関連性は「答えがユーザーの質問にちゃんと向き合っているか」、そしてハルシネーション率は「モデルがどれだけの頻度で根拠のない内容を生成したか」を測ります。忠実度と関連性で「正しさ」を支え、ハルシネーション率で「危なさ」を直接監視する組み合わせです。
ハルシネーション率という指標の意味
ハルシネーション率は、エージェントの応答のうち、与えた文脈にも事実にも裏づけられない主張を含むものの割合を指します。整った文章で、自信たっぷりに、けれど根拠なく語る——この現象を数値として可視化するための指標です。なおこの指標が主に測るのは、回答が与えた文脈・参照データと矛盾していないかであって、外部世界の真偽そのものの証明には、別途、信頼できる正解データや専門家レビューが要ります。
ここで守るべき区別があります。測れる次元と、測りにくい次元を同じ強度で語らないこと。ハルシネーション率が捉えるのは「事実と整合しているか」という検証可能な軸であって、「読んでいて気持ちいいか」「説明がわかりやすいか」といった体感品質ではありません。体感品質も大事ですが、それは別の評価軸であり、ハルシネーション率の数値で代弁させてはいけない。事実整合の指標に体感の話を混ぜると、閾値の意味がぼやけます。
この指標が直接効くのは、ベース記事の医療事例のような高リスク領域です。事実に基づかない症状の言及が一定割合を超えるエージェントは、コンプライアンス部門の署名を得られない。逆に言えば、ハルシネーション率を測って閾値内に収めていることが、署名を引き出す客観的な根拠になります。「たぶん大丈夫」では通らない場所で、数字が交渉材料になるわけです。
閾値2%未満をどう運用に落とすか
元記事では一例として、ハルシネーション率2%未満が挙げられています（公式の共通基準ではありません）。100回の応答のうち、根拠なき主張を含むものを2回未満に抑える、という水準です。この数字をどう運用へ落とすかが実装の勘所になります。
まず、閾値は「割ったら気づける」状態と組で初めて意味を持ちます。全応答に対してハルシネーション率を継続計測し、2%を超えた瞬間にアラートを上げ、原因の切り分け（検索が劣化したのか、プロンプトが変わったのか、モデルを更新したのか）へ進む。計測だけして閾値を監視していなければ、数字はダッシュボードの飾りで終わります。
次に、2%という値はそのまま自分のユースケースに適用するものではない点に注意してください。これは元記事が示す一例であり、公式の共通基準ではありません。医療のような領域ではより厳しく、社内向けの下書き補助のような低リスク用途ではもう少し緩めても運用が成り立つ場合があります。閾値は「守るべき固定値」ではなく「ビジネスの許容度から逆算する出発点」。この逆算の手順は後半の閾値設計のセクションで詳しく扱います。ここでは、ハルシネーション率という指標を全応答に走らせ、領域に応じた閾値で監視する、という骨格を押さえておけば十分です。
エージェント行動カテゴリ — ツール選択精度を測る
エージェント挙動カテゴリは、この記事の第2の痛点であるツール選択精度の中心です。検索が正しく、生成が忠実でも、エージェントが「どのツールを・どんな引数で呼ぶか」を誤れば、行動の結果は崩れます。チャットボットと違い、実際に外部を操作するエージェントでは、この選択の正しさが信頼性を直接左右する。
ここで測るのは、正しいツールを、正しい引数で、正しいタイミングで呼べたか。たとえば「在庫を確認して」という指示に対して、在庫照会のツールを選ぶべきところで発注ツールを呼んでしまえば、選択精度の失敗です。引数の取り違え——商品IDと数量を逆に渡す、といったミスも同じカテゴリで捕まえます。
正しいツールを正しく呼べたか
ツール選択精度は、エージェントが利用可能なツール群の中から、タスクに最適なものを選び、適切な引数を組み立てられた割合を測ります。判定には、想定される正解のツール呼び出し（どのツールを・どんな引数で呼ぶべきか）を用意しておき、エージェントの実際の呼び出しと突き合わせる方法が基本になります。
注意したいのは、選択と実行を分けて評価することです。前半で見たReddit の実行層の話を思い出してください。エージェントが正しいツールを正しい引数で選んだ（選択は成功）のに、そのツールがUIしか持たず、SSOで弾かれて実行できなかった（実行層で破綻）、というケースがあります。この2つを混ぜて「失敗」と一括りにすると、直すべき場所を見失う。
ツール選択精度の指標は、あくまで「選択」の正しさを測ります。選択は正しかったと確認できれば、残る不具合は実行層の問題だと切り分けられる。逆に選択精度そのものが低ければ、ツールの定義文や説明が曖昧でモデルが選べていない、といったプロンプト・設計側の課題が疑われます。崩れた場所を選択と実行に分解できることが、このカテゴリの実務的な価値です。
ツール選択の失敗はなぜ気づきにくいか
ツール選択の誤りが厄介なのは、サイレントに失敗するからです。コードのバグなら例外が飛んで処理が止まりますが、誤ったツール選択は「正常に完了」してしまうことが多い。間違ったツールが、間違った相手に対して、しれっと成功を返す。
たとえば本来は読み取り専用の照会ツールを呼ぶべき場面で、状態を変更する更新系ツールを呼んだとします。処理自体はエラーなく完了し、ログにも「成功」と記録される。けれど実際にはデータが書き換わっていて、被害は後から表面化します。例外も出ず、ステータスも緑のまま進むため、従来の監視では捕捉できません。
だからこそ、ツール呼び出しの一つひとつを評価対象として記録し、想定との一致を測る必要があります。「どのツールを・どんな引数で・どの順序で呼んだか」を残しておけば、サイレントな失敗を後から検知し、再発を防げる。なぜこうした各ステップを測定点として取り出せるのか——その仕組み的な根拠は、次に見るReActループの構造にあります。
ReActループが評価対象を生む（思考・行動・観察）
ツール呼び出しの一つひとつを測定点として取り出せる。その根拠は、いま広く使われるエージェントの動作構造そのものにあります。ReAct（リアクト）と呼ばれる枠組みが、その代表格。ReActは「Reasoning and Acting（推論と行動）」の略で、モデルに考えるだけでなく実際に行動させ、その結果を観察させるプロンプティング手法であり設計パターンでもあります。
なぜこの構造が評価と相性がいいのか。鍵は、エージェントの内部処理が「思考→行動→観察」という明確なステップに分かれている点にあります。思考のステップでモデルが次にやることを言語化し、行動のステップで外部ツールを呼び出し、観察のステップでその結果を受け取る。このサイクルが何度も回って、最終的な答えにたどり着く。各ステップが区切られているからこそ、どこで何が起きたかを記録でき、測定の対象になります。
Zapierの解説によれば、ReActが解こうとしている問題は明快です。素のLLMは仮定にもとづいて推論するため、現実のデータを一度も確認しないまま、構造だけは整った完全に誤った答えを自信満々に返してしまう。マルチステップのタスクを推論し、行動し、それらしい結果を出したのに、中身が丸ごと間違っていた——そういう破綻を防ぐために、ReActはモデルに「実際に確かめてから次に進む」ことを強制します。
思考→行動→観察のどこを測るか
3つのステップは、それぞれ別の指標に対応します。整理すると次の通り。
| ステップ | 何が起きるか | 評価で見る点 |
|---|---|---|
| 思考 | 次の行動を言語化する | 推論の筋道が破綻していないか |
| 行動 | 外部ツールを呼び出す | 正しいツールを正しい引数で選んだか |
| 観察 | ツールの結果を受け取る | 結果を正しく解釈して次に活かせたか |
行動のステップが、前のセクションで扱った「ツール選択精度」の計測点です。モデルが検索エンジン・API・データベースといった外部ツールのどれを呼び、どんな引数を渡したかが、このタイミングで記録されます。観察のステップは、取得した実データをモデルが正しく読み取れたかを見る場所。ここで誤読が起きると、せっかく正しいデータを取得しても結論を誤ります。
ReActが「思考→行動→観察」を繰り返す構造を持つことは、評価する側にとって都合がいい。仮定だけで突っ走る素のLLMは、内部がブラックボックスで、どこで間違えたかを後から追えません。ReActなら各サイクルをログに残す実装にすれば、どのステップで筋が狂ったかを特定できる（ツール実行結果や各ステップを評価対象にするには、アプリ側でトレースやログを明示的に保存する必要があります）。エージェントの推論過程を分解して観測できることが、ReActループが評価ハーネスと噛み合う理由です。ReActそのものの仕組みは別記事でも掘り下げていますが、ここでは「測れる構造を持つ」という一点を押さえてください。
本番運用カテゴリ — コストとレイテンシの監視
検索・生成・エージェント行動の3カテゴリは「正しく動くか」を測ってきました。4つめの本番運用カテゴリが見るのは「現実的なコストで動き続けられるか」。どれだけ精度が高くても、応答が遅すぎたり料金がかさみすぎたりすれば、本番では使い物になりません。
ここで中心になるのが、レイテンシ（応答にかかる時間）の監視です。元記事では一例として、本番運用でP99レイテンシ3秒未満が挙げられています（公式の共通基準ではなく、処理種別や非同期化で変わります）。P99とは99パーセンタイル、つまりリクエストの99%がその値以下に収まる時間のこと。「100回に99回は3秒以内に返る」という基準で、たまに混じる極端に遅い応答を見逃さないための見方です。平均値だけを見ていると、一部のユーザーが10秒待たされている実態が平均に埋もれて見えなくなる。だからこそ、平均ではなくP99のような上側のパーセンタイルで管理します。
検索や個別ステップにはサブ秒のレイテンシ目標を置くのが一般的ですが、エージェント全体としては複数ステップを踏むぶん時間がかかる。各ステップを速く保ちつつ、全体のP99を抑える。この両にらみが本番運用の監視ポイントになります。
トークン課金がコストに直結する
レイテンシと並ぶもう一つの監視軸が、コストです。LLMを使ったエージェントは、入力と出力のトークン量に応じて課金されるのが基本。エージェントが思考→行動→観察を何度も回せば、その都度トークンを消費し、料金が積み上がっていきます。1リクエストあたりは数円でも、本番で1日に何万件と処理すれば、月のコストは無視できない規模に膨らむ。
評価ハーネスにコスト指標を組み込むと、「精度を上げるためにステップ数を増やしたら、料金が倍になった」といった変化を数字で捉えられます。品質とコストはトレードオフの関係にあり、片方だけを最適化すると、もう片方が静かに悪化する。両方を同じダッシュボードで並べて見ることが、本番運用を持続させる前提になります。レイテンシとコストを継続的に観測する設計は、ログだけに頼らない本番監視の話とも地続きで、観測戦略そのものは別記事でも扱っています。
何を評価するかは「エージェント設計」で決まる
ここまで12指標と4カテゴリを見てきましたが、すべてのエージェントに12指標を一律で当てる必要はありません。何を測るべきかは、そのエージェントが何をするものか——つまり設計の型によって変わります。
AutoGPTの解説では、有用なAIエージェントは単なる質問応答ではないと整理されています。目標を達成するために文脈を集め、ツールを使い、次のステップを準備する。チャットボットが「答えを返す」のに対し、ワークフローを担うエージェントは「判断が要る場所で人間に仕事を引き渡す」点に特徴がある、という切り分けです。
答えるエージェントと行動するエージェントの違い
この2つは、評価で重視する指標が異なります。
| 設計の型 | 主な仕事 | 重点的に測る指標 |
|---|---|---|
| 答えるエージェント | 質問に回答する | ハルシネーション率・回答の忠実度 |
| 行動するエージェント | タスクを実行する | ツール選択精度・実行の成否 |
答えるエージェント、たとえば社内ナレッジに答えるチャットボットなら、評価の主役は生成カテゴリです。返した答えが検索した文脈と矛盾していないか、事実を捏造していないかを厳しく見る。一方、発注処理やデータ更新を担う行動するエージェントでは、エージェント行動カテゴリが主役になります。正しいツールを正しく呼べたか、実行が本当に完了したか。同じ「AIエージェント」でも、測るべき指標の重心がまるで違うことが分かります。
人間に引き渡す境界を決める
行動するエージェントの設計で外せないのが、どこまでを自動で進め、どこから人間に委ねるかの線引きです。AutoGPTの整理によれば、AIエージェントの価値は自動処理と人間の判断を適切に組み合わせる点にある。すべてを自動化しようとすると、判断の難しい場面でエージェントが暴走し、被害が出てから気づくことになりかねません。
この「引き渡しの境界」は、評価ハーネスの設計にも跳ね返ります。人間がレビューする工程を挟むなら、その手前までの精度を厳しく測り、人間の確認後は自動チェックを緩める、といった調整ができる。逆に完全自動で走らせる工程は、閾値を最も厳しく設定する。評価対象の設計が決まれば、どの指標をどの強度で測るかが自然と定まります。本番運用に耐えるエージェントの設計パターンそのものは別記事で詳しく扱っていますが、評価の観点からは「型が指標を決める」という順序を押さえておけば十分です。
閾値の決め方 — 品質とコストのバランス
指標を並べただけでは評価ハーネスは動きません。各指標に「この値を下回ったら不合格」という線、すなわち臨界閾値（critical threshold）を入れて、はじめて自動でゴー・ノーゴーを判定できるようになります。では、その数字をどう決めるのか。
出発点はビジネスの許容度です。閾値は技術的に決まるものではなく、「この用途で、どこまでの失敗なら許せるか」というビジネス判断から逆算します。同じハルシネーション率でも、許容できる水準は用途でまるで変わる。
– 高リスク領域（医療・金融・法務）: 閾値を最も厳しく。誤りが人命や資産に直結する – 一般的な顧客向け: 中程度。誤りはブランド毀損につながるが、即座の実害は限定的 – 社内ツール: 比較的緩め（ただし個人情報・人事・財務・書き込み権限を扱う場合は高リスクとして扱う）
元記事ではハルシネーション率2%未満が一例として挙げられていますが、これは公式基準ではなく出発点の目安。医療のような領域なら、ここからさらに厳しく締める判断もあり得ます。重要なのは、閾値を「えいや」で決めず、その用途で許される失敗コストから逆算する手順を踏むこと。
閾値を厳しくすると、通過する出力の品質下限は上がりますが（モデル自体の品質が上がるわけではありません）、不合格を減らすための再試行やステップ追加が増え、レイテンシとコストは悪化します。逆に緩めれば速く安くなるが、質の悪い応答が本番をすり抜ける。閾値設定とは、この品質とコストのバランスを数字に落とす作業にほかなりません。一度決めて終わりではなく、本番のデータを見ながら定期的に見直すものだと考えてください。
遅延評価という最大の落とし穴
評価ハーネスをめぐって、最もコストの高い失敗があります。それは「MVPを作り終えてから評価を後付けする」という進め方。元記事が指摘する核心の一つで、評価を最後に回すほど、あとで支払う代償は大きくなります。
なぜ後付けが高くつくのか。評価の仕組みが無いまま開発を進めると、エージェントの挙動が正しいかどうかを誰も数字で確認できないまま、機能だけが積み上がっていきます。デモはきれいに動く。けれど本番に出した瞬間、検証基盤が無いせいで、どこがどう壊れているのか分からない。前半で見た医療デプロイの事例が、まさにこれでした。テストは通っていたのに、ハルシネーションを測る仕組みだけが欠けていた。
Reddit上でも、似た構図への指摘があります。ある投稿者の報告では、計画段階では完璧に見えたエージェントが、実ツールに接続した途端に信頼性を失い、UIの変更やセッション切れのたびにスクリプトが壊れて保守コストが膨れ上がったといいます。評価の目を最初から組み込んでいれば、こうした破綻を早期に数字で捉え、傷が浅いうちに手を打てたはずです。
AutoGPTが説く設計段階の話とも重なります。何を自動化し、どこで人間に引き渡すかを最初に決めておけば、評価すべき対象も初日から見えている。設計と評価を後から接ぎ木するのではなく、最初から一体で考える。遅延評価を避けることは、結局のところ「day1から組む」という一点に集約されます。
day1から評価ハーネスを組む手順
最後に、評価ハーネスを初日から立ち上げる具体的な順番をまとめます。いきなり12指標を全部実装しようとすると重すぎて頓挫するので、最小構成から始めるのが現実的。
最小構成で回し始める順番
次の5ステップで、小さく回し始められます。
1. 4カテゴリから代表指標を1つずつ選ぶ。検索から文脈精度（または文脈再現率）、生成から忠実度（またはハルシネーション率）、エージェント行動からツール選択精度、本番運用からP99レイテンシ。まずこの4つだけ。 2. それぞれに閾値を仮置きする。最初は厳密でなくてよい。ベース記事のハルシ率2%未満・P99レイテンシ3秒未満を出発点に、自分の用途の許容度で調整する。 3. すべての応答に対して測定を走らせる。一部のサンプルだけでなく、本番のエージェント応答・ツール呼び出し・検索操作の一つひとつを評価対象として記録する。 4. 閾値割れをアラートにつなぐ。指標が線を下回ったら通知が飛ぶようにし、回帰を見逃さない仕組みにする。 5. 関係者の署名（サインオフ）を得る。医療デプロイの事例でコンプライアンス担当が最後に承認したように、測定結果を見せて「これなら出せる」という合意を取る。
この5ステップを回し始めれば、あとは指標を足し、閾値を実データで締め直していくだけ。代表指標4つから12指標へ広げるのも、最小構成が動いていれば段階的に進められます。手順そのものは太字で示した4指標の選定から始まり、測定→アラート→署名という流れに沿って組み上げる。CIや本番監視への組み込み方は、評価を開発フローの一部として常時走らせる設計に踏み込む話なので、観測戦略の別記事も合わせて参照してください。
ここで強調したいのは、リリース前の回帰テストや高リスク操作では「全応答に走らせる」を外さないこと。サンプリングで一部だけ測ると、たまに混じる致命的な失敗をすり抜けさせてしまう。サイレントに失敗するツール選択の誤りは、まさにこの隙間から漏れます。ただし本番での全量評価はコスト・遅延を増やし、外部のjudgeモデルを使う場合は回答・文脈・入力がそのモデルへ渡るため、データ保護要件に応じて全量・サンプリング・非同期評価を組み合わせ、送信データや契約条件も確認してください。
まとめ：評価ハーネスをマスターするためのロードマップ
本番のAIエージェントが崩れる原因は、モデルが賢くないからではありません。失敗を検知する評価基盤が無いから。この逆説を軸に、ハルシネーション率とツール選択精度という2つの痛点を、閾値で定量的に測る方法をたどってきました。
評価ハーネスは、検索・生成・エージェント行動・本番運用の4カテゴリに整理されます。検索では関連性と忠実度を、生成ではハルシネーション率を（ベース記事の閾値例では2%未満）、エージェント行動ではツール選択精度を、本番運用ではP99レイテンシ（同じく一例で3秒未満）とコストを見る。ReActの思考→行動→観察ループが各ステップを測定点に変え、エージェントの設計の型が、どの指標を重く測るかを決めます。
最大の落とし穴は、評価を後回しにする遅延評価。day1から最小構成で組み、全応答に走らせ、閾値割れをアラートにつなぐ。この順番で立ち上げれば、傷が浅いうちに失敗を捕まえられます。
習熟レベル別のチェックリスト
入門レベル: – 4カテゴリ（検索・生成・エージェント行動・本番運用）が何を測るかを説明できる – ハルシネーション率とツール選択精度が、なぜ本番の2大痛点なのかを理解している
実践レベル: – 代表指標4つに閾値を仮置きし、全応答に対して測定を走らせている – 閾値割れがアラートとして通知される仕組みを組んでいる
応用レベル: – 用途のリスクから逆算して閾値を調整し、品質とコストのバランスを管理している – エージェントの設計の型に応じて、測る指標の重心を変えられる
まず4指標の最小構成から始め、本番データが溜まったら閾値を締め直す。慣れたら12指標へ広げ、CIと本番監視に組み込んでいく。この段階を踏めば、評価ハーネスは継続運用できる検証基盤として育ちます。
よくある質問
Q. 評価ハーネスは小規模なエージェントにも必要ですか？
規模が小さくても、本番でユーザーや業務データに触れるなら必要です。むしろ小規模なうちに最小構成で組んでおくほうが安く済みます。検索の文脈精度（または再現率）、生成のハルシネーション率、ツール選択精度、レイテンシの4指標から始めれば、大がかりな仕組みは要りません。後付けで足すほどコストが膨らむため、初日から小さく回すのが結局は近道。
Q. ハルシネーション率はどう測るのですか？
エージェントの回答が、検索で取得した文脈と矛盾していないかを照合して測ります。事実として裏付けられない記述が混じった応答の割合が、ハルシネーション率です（主に文脈との整合を測るもので、外部世界の真偽そのものの検証には別途、正解データや専門家レビューが要ります）。元記事では一例として2%未満が挙げられています。すべての応答を対象に記録し、根拠の無い記述が閾値を超えたらアラートを上げる運用が基本になります。
Q. ツール選択の正しさはどう判定しますか？
エージェントが「どのツールを・どんな引数で・どの順序で呼んだか」を記録し、想定との一致を測ります。誤ったツール選択は例外を出さずに正常完了してしまうため、通常の成功・失敗ログだけでは気づきにくい。呼び出しの一つひとつを評価対象として残し、想定と照合することで、サイレントな失敗を後から検知できます。
Q. 評価は開発のどの段階で導入すべきですか？
初日からです。MVPを作り終えてから評価を後付けする「遅延評価」が、最もコストの高い失敗とされています。検証基盤が無いまま機能を積むと、本番でどこが壊れているのか数字で追えなくなる。最小構成でよいので、開発の最初から評価を一体で組み込んでください。
Q. 12指標を全部そろえないと意味がないですか？
そんなことはありません。4カテゴリから代表指標を1つずつ選んだ4指標でも、評価ハーネスとして機能します。まず4つで回し始め、本番データが溜まってから指標を足していくのが現実的。一度に12指標を実装しようとすると重すぎて頓挫しやすく、小さく始めて段階的に広げるほうが続きます。
| 4カテゴリ | 検索 / 生成 / エージェント行動 / 本番運用 |
|---|---|
| ハルシネーション率の閾値の例 | 2%未満（ベース記事の一例。公式の共通基準でなく用途ごとに設定） |
| P99レイテンシの閾値の例 | 3秒未満（ベース記事の一例。処理種別や非同期化でSLOは変わる） |
| 2大痛点 | ハルシネーション検知 / ツール選択精度 |
| 導入の鉄則 | day1から最小構成で全応答に走らせる |
なお、本記事で扱う「12指標」「ハルシネーション率2%未満」「P99レイテンシ3秒未満」は、元記事が提示する実務上のフレームワークおよび閾値例であり、業界団体や標準化機関が定めた共通基準ではありません。実運用では、用途・リスク・データ保護要件に応じて個別に調整してください。
参考資料
- Towards Data Science: Building an Evaluation Harness for Production AI Agents — A 12-Metric Framework From 100+ Deployments
- Zapier Blog: What are ReAct agents and how do they work?
- AutoGPT Blog: How to Build Useful AI Agents for Business Workflows — 7 Patterns Beyond Chatbots
- Yao et al.: ReAct — Synergizing Reasoning and Acting in Language Models (arXiv:2210.03629)
- （各ページ 2026年6月確認）
