ClaudeやGPT等の既成のAPIを叩くのではなく、AIモデルを1から構築するとき、一般的にはデータを分割し、一部のデータをAIの学習データとして使用し、学習データとして利用しなかったデータを評価データとして使用します。学習データでAIを訓練し、評価データでそのAIの精度を評価する方法です。これは、学習データに対して過学習、すなわち、その学習データにおいてのみ正しく、学習データ以外のデータに対しては正解率が落ちてしまうAIができてしまうことを防ぐための、一般的なお作法として知られています。
一方で、出来上がったAIを世の中に出したとき、世の中の実際のデータと、この学習データや評価データが異なっていると、本番では使い物にならないAIを世の中に出してしまうことがあります。これは「ドリフト」と呼ばれる現象で、大きくは「データドリフト」と「コンセプトドリフト」と呼ばれる現象に分けられます。
例えば、過去の購買データをもとに顧客の離反を予測するモデルがあったとします。そのAIモデルを構築する際に、学習データや評価データが「春・夏」のデータのみで、実際にそのモデルを世の中に出した時が「秋・冬」であれば、季節によって購買行動は変わり得るので、学習データと評価データが持つデータの傾向が、実際の本番時のデータと大きく分かれ、精度が想定外に落ちてしまうことがあります。これが、データドリフトです。
データドリフトがデータの傾向が変化することであるのに対して、コンセプトドリフトはAIモデルが対象としている世界の意味合いが変わっていくことで、精度が落ちてしまうことを指します。例えば、AIモデルの学習時点では、来店頻度の低下や問い合わせ件数の増加が顧客の離反を示すシグナルであったかもしれません。しかし、競合サービスの登場、価格改定、コロナ禍のような外部環境の変化、顧客層の変化によって、「何が離反なのか」そのものが変わることがあります。このとき、入力データの見た目が多少変わっただけではなく、入力と出力の関係、つまり何をもって正解とするかの構造が変わっています。これがコンセプトドリフトです。
従来の機械学習では、このようなドリフトに対して、データ分布の監視、予測精度の継続的なモニタリング、モデルの再学習といったMLOpsの仕組みが発展してきました。モデルは一度作って終わりではなく、現実の変化に合わせて保守し続けるものだという認識がありました。
では、生成AIやAIエージェントの時代には、何がドリフトするのでしょうか。一般的に、生成AIを使ったシステムを作る際、一からLLMを自社で作ることは少ないです。多くの場合、ClaudeやGPT等の既にあるLLMのAPIを叩きながら、その周辺にRAG、プロンプト、ツール、ワークフロー、権限管理、ログ管理などを組み合わせてシステムを構築します。
このとき、従来の機械学習における「データドリフト」がなくなるわけではありません。例えばRAGシステムでは、参照ドキュメントの更新や陳腐化という形で、データの傾向の変化は依然として重要な論点です。ただし、生成AIやAIエージェント時代には、それに加えて「コンセプトドリフト」の方に注意する機会が、相対的に多くなると考えられます。
特に重要なのは、AIエージェントにおいては、モデルではなく、評価基準であるルーブリックや、評価用データであるゴールデンデータセットもコンセプトドリフトしていくという点です。
本記事では、AIエージェントの評価において、ルーブリックやゴールデンデータセットも固定的なものではなく、時間とともに変化していくという前提に立ちます。そのうえで、評価を固定的な工程としてではなく、継続的に更新される運用基盤として扱う考え方を、本記事では 「Living EvalOps」 と呼びます。これは筆者が本記事で用いる呼称であり、確立した業界標準用語ではありません。EvalOps（評価の運用化）という発想自体は近年使われ始めていますが、本記事ではそこに「Living（生きている=運用ログから継続的に更新され続ける）」という性質を明示的に冠することで、評価資産を静的なテスト資産ではなく動的に育てる対象として捉える点を強調します。
AIエージェント時代のコンセプトドリフト
改めてコンセプトドリフトについて説明します。コンセプトドリフトとは、簡単に言えば、モデルが学習した「入力と正解の関係」が時間とともに変わることです。 機械学習モデルは、過去のデータからパターンを学習します。たとえば、過去のメールデータをもとに迷惑メールを判定するモデルであれば、「どのような文面や送信元が迷惑メールらしいか」を学習します。しかし、スパム業者の手口が変われば、過去に有効だった判定基準は徐々に通用しなくなります。
ここで重要なのは、単にデータの傾向が変わること、すなわちデータドリフトと、コンセプトドリフトは同じではないという点です。コンセプトドリフトは、「同じような入力に対して、正解とすべき出力が変わる」ことを意味します。 例えば、採用候補者のスクリーニングを支援するAIを考えてみます。ある時点では、特定の技術スタックの経験が重要だったとしても、数年後には生成AIを前提とした開発経験や、業務変革の経験がより重視されるかもしれません。この場合、過去の「良い候補者」の定義を固定したままモデルを評価しても、現在の採用方針に合った評価にはなりません。つまり、モデルだけでなく、正解の定義そのものが変わっているのです。
ルーブリックのドリフト
AIエージェントの評価では、この問題がさらに複雑になります。従来の機械学習では、比較的明確な正解が存在することが多くありました。離反するかしないか、与信を通すか通さないか、画像に猫が写っているかどうか、といった形です。
一方で、AIエージェントが担う業務は、より曖昧で、複数ステップで、状況依存的です。例えば、社内問い合わせ対応エージェントであれば、単に正しい情報を返せばよいわけではありません。ユーザの意図を確認したか、社内規程に沿って回答したか、必要に応じて人間へエスカレーションしたか、過剰に断定しなかったか、機密情報を漏らさなかったか、といった複数の観点で評価する必要があります。 営業支援エージェントであれば、商談メモを要約するだけでなく、次に取るべきアクションを提案し、顧客の関心に合わせて提案内容を調整し、社内の営業プロセスに沿ってCRMを更新することが求められます。
このようなAIエージェントの評価では、「正解」は単一のラベルではありません。多くの場合、以下のようなルーブリックによって評価されます。
- タスクの目的を正しく理解しているか
- 必要な情報を過不足なく収集しているか
- 適切なツールを選択しているか
- 誤った前提で処理を進めていないか
- ユーザや業務担当者にとって実用的なアウトプットになっているか
- セキュリティ、コンプライアンス、社内ルールを守っているか
- 不確実な場合に適切に確認・保留・エスカレーションしているか
しかし、AIエージェントの文脈ではこれらの評価基準がドリフトしていく可能性があります。
例えば、AIエージェントを業務に導入すると、利用者の期待値が変わることもあります。最初は「それっぽく答えてくれるだけで十分」と思われていたものが、業務利用が進むにつれて、「社内ルールに厳密に準拠してほしい」「回答だけでなく次のアクションまで提案してほしい」「曖昧な場合は勝手に進めず確認してほしい」といった要求に変わっていきます。
また、業務プロセス自体も変わります。社内規程が改定される、利用するSaaSが変わる、承認フローが変わる、責任分界点が変わる等です。すると、昨日まで正しかったエージェントの行動が、今日からは望ましくない行動になることがあります。つまり、AIエージェントにおいては、それを評価するルーブリックがドリフトしていくのです。
ゴールデンデータセットのドリフト
同じことは、ゴールデンデータセットにも言えます。
ゴールデンデータセットとは、AIシステムの評価に使う代表的なテストケース群です。典型的な問い合わせ、難易度の高いケース、過去に失敗したケース、重要な業務シナリオなどを集め、モデルやプロンプト、エージェント設計を変更した際に、品質が落ちていないかを確認するために使います。生成AIシステムの実装において、ゴールデンデータセットは非常に重要です。なぜなら、生成AIの出力は確率的であり、単純な単体テストだけでは品質を保証しにくいからです。
しかし、このゴールデンデータセットもまた、時間とともに古くなります。導入初期に作ったテストケースは、当時想定していた業務シナリオを反映しています。しかし、本番運用が始まると、実際のユーザは想定外の聞き方をします。業務部門は、当初想定していなかった使い方を始めます。例外ケースや失敗パターンも、運用して初めて見えてきます。
その結果、初期に作ったゴールデンデータセットだけを使い続けていると、次第に現実の利用状況を反映しなくなります。特に、AIエージェントの場合は、ユーザの期待、業務プロセス、利用可能なツール、許容されるリスク、エスカレーション基準が変わります。したがって、ゴールデンデータセットは「一度作ったら保管しておくテスト資産」ではなく、「本番ログから継続的に更新される評価資産」として扱う必要があります。
この問題は、多くの生成AIプロジェクトの進め方とも関係します。一般に、PoCの段階で評価観点や評価データを作成し、例えば100件程度のテストケースで回答の正確性、網羅性、自然さ、安全性などを人手で評価します。そのうえでプロンプトを改善し、RAGの検索設定を調整し、モデルを変更します。このアプローチ自体は必要であり、初期品質を確認しないまま本番導入することはできません。問題は、その評価セットが本番後もそのまま使われ続けることです。
PoC時点の評価データは、あくまでその時点で想定された利用シナリオを反映したものにすぎません。ルーブリックも同様です。初期段階では「正確に答えること」が重視されていたとしても、運用が進むと「回答しない判断」や「人間に確認する判断」のほうが重要になることがあります。例えば、社内規程に関するAIエージェントでは、曖昧なケースに対して無理に回答するよりも、「このケースは人事部に確認してください」と返すほうが望ましい場合があります。初期の評価ルーブリックが「回答の網羅性」を重視しすぎていると、このような安全な保留判断を低く評価してしまう可能性があります。つまり、固定された評価基準は、時間が経つにつれて、現実の望ましい振る舞いとズレていくのです。
Living EvalOps
では、AIエージェントをどのように実装・保守すべきでしょうか。結論から言えば、必要なのは「Living EvalOps」です。
ここでいうLiving EvalOpsは、LLMOpsと対立する概念ではありません。LLMOpsは、LLMアプリケーションを本番環境で構築・デプロイ・監視・改善していくための広い運用概念です。そこには、プロンプト管理、RAGの改善、モデル選定、コスト管理、セキュリティ、監視、評価などが含まれます。一方で、Living EvalOpsは、その中でも特に「評価」に焦点を当てた考え方です。AIエージェントの評価基準であるルーブリック、評価用のゴールデンデータセット、評価結果、改善判断を、固定的なテスト資産ではなく、運用ログに基づいて更新され続ける資産として扱います。
つまり、LLMOpsがLLMアプリケーション全体の運用を扱う概念だとすれば、Living EvalOpsはその中で「評価そのものをどのように運用し、育て続けるか」に焦点を当てた概念です。従来のテストは、開発工程の最後に品質を確認するためのものでした。一方で、AIエージェントにおける評価は、リリース前の関門であると同時に、リリース後の運用そのものです。
特にLiving EvalOpsでは、以下の4つを継続的に回すことが重要だと考えます。
- 本番ログの収集 : AIエージェントがどのような入力を受け取り、どのような推論を行い、どのツールを呼び出し、どのような出力を返したのかを、軌跡として記録します。最終回答だけでなく、途中の判断、ツール選択、エラー、リトライ、エスカレーションの有無まで記録することが重要です。
- 失敗・違和感・高リスクケースの抽出 : すべてのログを人間が確認することは現実的ではありません。そこで、ユーザからの低評価、再質問、手戻り、長すぎる実行時間、ツールエラー、権限エラー、機密情報に近い入力、曖昧な回答などをシグナルとして、重点的にレビューすべきケースを抽出します。
- ルーブリックとゴールデンデータセットの更新 : 抽出されたケースをもとに、「このケースでは何が望ましい振る舞いだったのか」を人間が判断します。その結果、既存のルーブリックに不足があれば評価観点を追加し、既存のゴールデンデータセットに含まれていない重要ケースがあれば新たに追加します。
- 変更管理と回帰評価 : プロンプト、RAG、ツール、モデル、ガードレール、ワークフローを変更するたびに、更新されたゴールデンデータセットで回帰評価を行います。評価結果が改善しているのか、特定のケースで退化していないかを確認します。
このサイクルを回すことで、AIエージェントの評価は、固定されたチェックリストから、業務の変化を取り込む運用基盤へと変わります。以下では、4つの要素をそれぞれ詳しく見ていきます。
本番ログの収集
最初の要素は、本番ログの収集です。Living EvalOpsのすべては、ここで何を記録できているかに依存します。後段の抽出も、ルーブリック更新も、回帰評価も、収集されていない情報からは作れないからです。
ここで重要なのは、評価対象を「最終回答」だけに閉じないことです。AIエージェントは、単一の出力を返すだけのシステムではありません。観測し、計画し、ツールを使い、途中結果を解釈し、必要に応じて再試行し、最終的な回答やアクションに至ります。つまり、AIエージェントの良し悪しは、最終的なアウトプットだけでなく、そこに至るまでの過程に宿ります。正しい答えにたまたま辿り着いたのか、正しい手順で辿り着いたのかは、最終回答だけを見ていては区別できません。
そのため、ログとしては最終回答に加えて、次のような軌跡を記録しておくことが望ましいです。ユーザの入力、エージェントが立てた計画、参照したドキュメント、呼び出したツールとその引数、ツールからの返り値、途中で行った判断、発生したエラーやリトライ、人間へのエスカレーションの有無、そして最終的な出力です。これらを1つのトレースとして、一連の流れが後から追える形で残します。
実装としては、各ステップにIDを振り、入力・出力・所要時間・使用トークン数などを構造化して記録するのが一般的です。近年はエージェントの実行トレースを記録・可視化するための専用ツールも増えています。ただし、ツールの選定そのものよりも重要なのは、「後から評価したい観点が、ログから復元できるか」という視点で記録項目を設計することです。例えば、エスカレーション判断を評価したいのにエスカレーションの有無が記録されていなければ、その観点は永遠に評価できません。最初から完璧なログ設計は難しいので、評価したい観点が増えるたびに記録項目を見直していくことになります。
失敗・違和感・高リスクケースの抽出
2つ目の要素は、収集したログの中から、レビューすべきケースを絞り込むことです。
本番運用が始まると、ログは大量に蓄積されます。そのすべてを人間が目視で確認することは、現実的ではありません。一方で、ランダムにサンプリングするだけでは、頻度は低いが重大な問題を見逃します。重要なのは、平均的なケースではなく、何かが起きている可能性が高いケースを優先的に拾うことです。
そこで、ログに含まれるさまざまな情報を「シグナル」として使い、レビュー候補を抽出します。シグナルには、大きく分けてユーザ由来のものとシステム由来のものがあります。ユーザ由来のシグナルとは、ユーザからの明示的な低評価、同じ質問の繰り返し、言い直し、会話の途中離脱などです。これらは、エージェントの回答が何らかの形で期待に応えられなかった可能性を示します。システム由来のシグナルとは、ツールエラー、権限エラー、異常に長い実行時間、リトライ回数の多さ、機密情報に近い入力の検出などです。これらは、エージェントが内部的に困難に直面した、あるいはリスクの高い状況に置かれたことを示します。
例えば、「ユーザが明示的に低評価した会話」と「ツールエラーが発生した会話」と「実行時間が上位数%に入る会話」を機械的に抽出するだけでも、レビューすべきケースの密度は大きく上がります。閾値や対象とするシグナルは、運用しながら調整していくものですが、最初は「明らかに何か起きていそうなもの」から始めることが重要です。
ここで意識しておきたいのは、低評価がついていない=良かった、とは限らないという点です。ユーザがそもそも誤りに気づかなかった場合、低評価は付きません。特に専門性の高い領域では、ユーザが回答の誤りを判断できないこともあります。だからこそ、ユーザ由来のシグナルだけに頼らず、システム由来のシグナルや、後述するルーブリックによる機械的なスコアリングと組み合わせることが重要になります。
ルーブリックとゴールデンデータセットの更新
3つ目の要素は、抽出したケースを使って、評価基準と評価データそのものを更新することです。ここが、Living EvalOpsが「Living（生きている）」と呼べる中心の工程です。
抽出されたケースに対して、まず人間が「このケースでは、何が望ましい振る舞いだったのか」を判断します。この判断こそが、本記事の前半で述べた「ドリフト」を捉える瞬間です。例えば、曖昧な問い合わせに対してエージェントが断定的に回答していたとします。導入初期のルーブリックでは「網羅的に回答できているので高評価」だったかもしれません。しかし運用が進んだ今、本来は「人事部に確認するよう促すべきだった」という結論になったとします。このとき起きているのは、エージェントの劣化ではなく、望ましい振る舞いの定義の変化、すなわちルーブリックのドリフトです。
この判断を踏まえて、2つの更新を行います。1つは、ルーブリックの更新です。既存の評価観点では今回のケースを正しく評価できないのであれば、評価観点を追加したり、重みを見直したりします。先の例で言えば、「曖昧なケースで適切に保留・エスカレーションしているか」という観点を追加し、断定的な回答をむしろ減点する形に変えることになります。もう1つは、ゴールデンデータセットの更新です。今回のような重要なケースが既存のテストケースに含まれていなければ、新しいテストケースとして追加します。これにより、同じ失敗が次回以降の変更で再発しないかを、自動的にチェックできるようになります。
ここで有効なのが、ゴールデンデータセットを単一のデータセットとして扱うのではなく、性質ごとに層を分けて管理する考え方です。具体的には、絶対に壊してはいけない基本ケース（Core Set）、事故につながりやすい高リスクケース（Risk Set）、本番ログから継続的に追加される新しいケース（Fresh Set）の3層に分けると、安定性と変化対応を両立しやすくなります。この工程で本番ログから追加されていくケースは、主にFresh Setに蓄積され、その中でも特に重大なものはRisk Setに昇格させる、といった運用が考えられます。
注意したいのは、この更新を場当たり的に行わないことです。誰が、いつ、どのケースをきっかけに、どの観点を追加・変更したのかを記録しておかないと、後から「なぜこの評価基準になっているのか」が分からなくなります。ルーブリックやゴールデンデータセットも、コードやプロンプトと同じようにバージョン管理の対象として扱うべきです。これにより、評価スコアが変化したときに、「エージェントの実力が変わったのか」「評価基準の方が変わったのか」を切り分けられるようになります。
変更管理と回帰評価
4つ目の要素は、更新された評価基準と評価データを、実際の変更プロセスに接続することです。せっかく評価資産を育てても、それが変更の意思決定に使われなければ意味がありません。
AIエージェントのシステムは、さまざまな箇所が変更されます。プロンプトの修正、RAGの検索設定やドキュメントの更新、利用するツールの追加・変更、モデルのバージョンアップ、ガードレールの調整、ワークフローの変更などです。生成AIシステムの難しさは、ある一箇所の変更が、一見無関係なケースの挙動に影響を与えうる点にあります。プロンプトを少し変えただけで、これまで正しく動いていた別のケースが壊れる、ということが起こります。
そこで、これらの変更を本番に反映する前に、更新済みのゴールデンデータセットで回帰評価を行います。回帰評価とは、変更前後で評価セットを通し、スコアが改善したのか、あるいは特定のケースで悪化（退化）していないかを確認することです。ここで、前述の3層が効いてきます。狙った改善が達成できているかをFresh Setで確認し、これまで守れていた品質が維持されているかをCore Setで確認し、重大な事故につながる挙動が混入していないかをRisk Setで確認する、といった形です。平均スコアが上がっていても、Risk Setの1ケースが壊れていれば、その変更は見送るべきかもしれません。
そして、この回帰評価を、単なる参考情報ではなく、リリースの判断基準（ゲート）として組み込むことが重要です。例えば、「Core SetとRisk Setのスコアが基準を下回ったら本番反映しない」「下回った場合は限定的なリリースに留める」といったルールを定めておきます。評価を、変更を止める力を持ったプロセスにして初めて、品質劣化を未然に防ぐことができます。
ここまでの4つの工程を回した結果は、再び最初の「本番ログの収集」に戻ります。変更を反映したエージェントは、また新しいログを生み出し、その中から新しいケースが抽出され、評価基準が更新されていきます。Living EvalOpsが一度きりの作業ではなく、継続的なサイクルである理由がここにあります。
おわりに
機械学習の時代に、我々はコンセプトドリフトという問題を通じて、AIモデルは現実世界の変化にさらされ続けることを学びました。AIエージェントの時代には、その対象がさらに広がります。
ドリフトするのは、ユーザの期待、業務プロセス、利用可能なツール、社内ルール、リスク許容度、そして評価基準そのものが変わっていきます。そのため、AIエージェントの評価は、一度作ったテストケースを回すだけでは不十分です。ルーブリックも、ゴールデンデータセットも、運用ログから学びながら更新され続ける必要があります。
AIエージェントを本当に業務に組み込むのであれば、必要なのは単なる精度評価ではありません。評価基準を育て、評価データを育て、変更管理と接続し、品質劣化や評価基準のズレを継続的に検知する仕組みです。これが、本記事で提案するLiving EvalOpsです。
AIエージェントを「作って終わり」にせず、現場の変化に合わせて評価・改善・保守し続けること。Velcore Consultingでは、AIエージェントの設計・実装だけでなく、その評価運用基盤まで含めた支援を行っています。
AIエージェントの評価・監督・説明責任まで含めた設計・実装・運用支援について、
Velcore Consulting がご相談を承っています。