OCIエージェント評価フレームワーク (2026/07/01)

https://blogs.oracle.com/ai-and-datascience/oci-agent-evaluation-framework

投稿者：Kishore Pusukuri

エグゼクティブサマリー

エージェント型AIシステムは、単に回答を生成するだけではありません。証拠を収集し、ツールを呼び出し、IDを使用し、状態を維持し、コンポーネント間で連携し、時には副作用を引き起こすこともあります。これにより、評価の問題が変わります。

チャットボットは多くの場合、その応答によって評価されます。一方、エージェントは、応答、動作、使用するツール、状態変化、そして問題発生時の復旧経路など、あらゆる側面から評価する必要があります。

このブログでは、エージェントを評価するためのライフサイクルアプローチとして、OCIエージェント評価フレームワークを紹介します。このフレームワークでは、機能の認定、プロンプトのテスト、検索拡張生成（RAG）、ツールと軌跡、リリース準備状況の評価、本番環境での動作監視、インシデントを復旧および再認証の対象範囲に変換することなどについて解説します。

重要なのは、答えが正しいかどうかだけでなく、経路、認証、状態変化、信頼性、本番環境での動作、および復旧が安全で、追跡可能で、本番環境に対応できる状態であるかどうかです。

エージェント評価はライフサイクル全体にわたる規律であり、回答、経路、ツール、状態変化、信頼性、本番環境における動作、および復旧を総合的に評価する。

エージェントにとって最終回答の採点が有利になる理由

多くのエージェント評価は、依然としてツール呼び出しログを添付したチャットボット評価に似ています。それでは不十分です。最終的な回答は有用に見えても、その回答を生成する過程で、認証、承認、プライバシー、ツール境界、状態変更、または復旧に関するルールに違反している可能性があります。表1は、従来の出力スコアリングとエージェントのライフサイクル評価を比較したものです。

表1. 出力スコアリングと薬剤ライフサイクル評価の比較

寸法	出力スコアリング	薬剤ライフサイクル評価
評価単位	最終回答	結果、経路、状態、回復
主な証拠	プロンプト、出力、スコア	トレース、取得、ツール呼び出し、ポリシーイベント、状態検証ツール
よくある失敗	間違った答え	安全でない、または信頼できない経路を通った正解
ケイデンス	ベンチマークまたはCIチェック	オンボーディング、開発、リリース、保証、リカバリ
制作リンク	弱い、または存在しない	リプレイ、カナリア、ドリフト、インシデントリプレイ、ランタイムアクション

正解であっても、危険な道筋を辿る可能性がある

企業サポート担当者が顧客に「お客様のアカウントステータスが更新されました」と正しく伝える場面を想像してみてください。最終的な回答は適切に見え、最終評価者は合格と判断するかもしれません。

トレース結果を見ると、状況は異なっていた。エージェントは特権更新ツールを使用し、必要な承認をスキップし、誤った認証コンテキストを渡して顧客レコードに書き込み、その後成功を報告していた。ライフサイクルを考慮した評価ツールであれば、顧客向けの回答は正しくても、このやり取りは失敗と判断すべきである。

エージェントの評価はライフサイクルに沿って行われます

エンタープライズエージェントの評価は、一度限りのリリース活動ではありません。契約、データセット、トレース、メトリクス、決定といった評価基盤は、システムの導入から復旧まで一貫して使用されるべきです。自律性、データの機密性、本番環境への影響、および結果が増大するにつれて、証拠の深度も増します。図1はライフサイクルループの概要を示しています。評価は導入から始まり、開発とリリースを経て、本番環境の動作を監視し、インシデントや逸脱を今後のカバレッジに反映させます。表2は、ライフサイクルの各段階を評価の質問と典型的な実行タイプに対応付けています。

図1. エージェントの評価はライフサイクルに沿って行われ、インシデントやドリフトによって新たなカバレッジが開発およびリリース評価にフィードバックされます。

表2. エージェント評価ライフサイクル段階と典型的な実行例

ステージ	評価に関する質問	典型的な走行
機内で	その機能は、限定的な使用において安全かつ十分に有用でしょうか？	能力、スキル/プラグイン、評価者認定
開発する	エージェントは、後退や危険な経路を経ることなく、改善を続けているか？	プロンプト、RAG、軌道、安全性回帰
リリース	候補者は、提示された業務範囲とリスクの下で準備が整っているか？	リリースゲート、統計ゲート、信頼性。
保証する	生産行動は承認された範囲内に収まっていますか？	リプレイ、カナリア、ドリフト、A/Bテスト
回復する	この修正によって問題は解決し、カバレッジは改善されましたか？	インシデント再現、再認証、ランタイム訓練

開発サイクルは軽量に保ち、自律性、データの機密性、生産への露出、および影響が増大するにつれて、証拠の深さを増していく。

テスト対象システムがより主体性を持つようになると、何が変わるのか

テスト対象システム（SUT）は、プロンプト、モデルエンドポイント、RAGワークフロー、ツールワークフロー、モデルコンテキストプロトコル（MCP）アプリケーション、シングルエージェント、マルチエージェントシステム、長時間実行エージェント、またはデプロイ済みサービスである可能性があります。評価は、テスト対象の表面に合わせて行う必要があります。表3は、テスト対象システムがエージェント性を高めるにつれて、評価の深さがどのように変化するかを示しています。

表3．試験対象システム別の評価項目

テスト対象システム	評価する	最終解答の採点が不十分な理由
プロンプト / LLMエンドポイント	指示に従う、形式、事実性、拒否、遅延、コスト	1つの応答のみをチェックします
RAGワークフロー	検索、グラウンディング、引用、鮮度、アクセス制御	証拠は古かったり、不正なものであったりする可能性がある。
ツールワークフロー	ツール選択、引数、スキーマ、ポリシー、状態検証	良い答えが出ても政策は失敗する可能性がある
MCPアプリケーション	発見、記述子、認証、同意、副作用	MCPもまたセキュリティ境界である
単独エージェント	結果、経路、ツール、記憶/状態、回復、終了	安全でない自律性でも成功する可能性がある
マルチエージェントシステム	委任、役割割り当て、共有状態、エスカレーション	チームの成功は違反者を隠蔽する可能性がある
長年のエージェント	セッションライフサイクル、チェックポイント/再開、コールバック、古いインテント、予算	故障は数時間後に発生する可能性がある
制作サービス	リプレイ、カナリア、ドリフト、ランタイムアクション、インシデントリプレイ	オフラインのスコアは、実際の運用状況を証明するものではありません。

最終回答の採点は、単純な応答チェックに適しています。ツールを使用するエージェント、ステートフルなエージェント、MCP対応エージェント、および本番環境エージェントには、軌跡を示す証拠が必要です。リスクとアクションの範囲に合致する最も簡便な評価方法を使用してください。

結果、経過、状態、回復状況を評価する

エージェントの場合、タスクの完了とパスの品質は個別に評価する必要があります。結果チェックでは、タスクが完了したかどうかを確認します。パスチェックでは、エージェントが許可された証拠、ツール、ID、承認、および副作用制御を使用したかどうかを確認します。ツールの使用チェックでは、選択、引数、認可コンテキスト、およびポリシー決定を確認します。状態検証では、エージェントの自己報告ではなく、ターゲットシステムを確認します。回復と終了チェックでは、エージェントがエラー、証拠の欠落、タイムアウト、ループ、拒否、エスカレーション、および停止条件を安全に処理したかどうかを確認します。

品質と保証は分離しておくべきです。品質の証拠は、タスクの価値（成功、正確性、検索品質、根拠、引用、信頼性、遅延、コスト）を測定します。保証の証拠は、システムが安全性、セキュリティ、プライバシー、アクセス制御、承認、副作用、自律性の境界内に収まっているかどうかを測定します。平均品質スコアが高いからといって、プライバシーの漏洩、承認の回避、安全でないツールパス、制御されていない書き込みが隠蔽されてはなりません。

RAG、ツール、MCPの証拠は異なる

RAG評価：検索の妥当性、根拠、引用の正確性、鮮度、アクセス制御フィルタリングをそれぞれ個別に評価します。引用は、それが付随する特定の主張を裏付ける場合にのみ有用です。引用数が多いことが、引用の正確性を意味するわけではありません。

ツール評価：リクエスト、引数、スキーマ検証、認証コンテキスト、ポリシー決定、承認状態、および副作用の結果を検査します。書き込み操作または特権操作の場合は、フィクスチャ、サンドボックス、UI状態、API応答、または操作後の不変条件を通じてターゲット状態を確認します。

MCP評価：発見、記述子、ツール、リソース、認証、同意、トークン処理、出力、セッション、副作用をプロトコルおよびセキュリティ境界の証拠として扱う。境界準拠は最終回答から推測してはならない。

信頼性評価は、1回の成功運転だけにとどまらない。

チームは、「エージェントは成功できるか？」だけでなく、「どのくらいの頻度で成功するのか、どのような安全な経路で、どのような外乱下で、どの程度のコストと遅延で、どのような障害モードで成功するのか？」も問うべきである。

確率的エージェントの場合、1回の成功実行はリリース証拠とはみなされません。結果の一貫性、軌跡の一貫性、ツール選択のばらつき、回復のばらつき、遅延/コストのばらつき、およびポリシー決定のばらつきを報告してください。同じサンプルに対する繰り返し試行は、独立したサンプルとしてカウントしないでください。必要な高リスクのスライスが検出力不足の場合は、結果をPASSではなくREVIEWに送ってください。

スコアの良し悪しは、評価指標と評価者の質に左右されます。リリースグレードで使用する場合、ゲート可能な評価指標にはメトリックカード、ゲート可能な審査員またはレビュープロトコルには評価者カード、G2/G3の決定には統計的決定プランを使用する必要があります。

長時間実行されるエージェントはセッションリスクを増加させます。チェックポイント/再開、コールバック、メモリ、承認TTL、古い意図のチェック、予算の枯渇、依存関係のずれ、安全な終了、およびランタイム無効化は、最初の応答時だけでなく、セッション全体にわたって評価する必要があります。

評価する行動を追跡する

これは、個人的な思考の流れではなく、観察可能な動作に依存します。有用なトレースでは、モデル呼び出し、取得スパン、ツール/MCP呼び出し、ポリシー決定、承認、状態イベント、回復イベント、終了イベント、エラー、タイミング、コスト、および検証結果が記録されます。図2は、エージェントが計画、証拠の取得、承認の確認、実行、状態の検証、回復または再計画を行う際に、評価者が検査すべき観察可能なパスを示しています。

図2．エージェント評価では、結果と観察可能な経路（計画、検索、承認、実行、検証、復旧、再計画）の両方を検証します。評価結果は、最終的な対応だけでなく、追跡可能な証拠にも結びつく必要があります。

RAGの場合、トレースにはチャンクID、引用マッピング、コーパスまたはインデックスのバージョン、鮮度メタデータ、およびアクセス制御の決定事項が保持される必要があります。書き込みアクションの場合は、状態検証ツールへのリンクが必要です。

ツール対応エージェントの最小限のトレース:

クリップボードにコピーされました

エラー: コピーできませんでした

model_call -> retrieval -> policy_decision -> tool_call_request -> tool_call_result -> state_event -> recovery_or_termination_event

トレース連携がなければ、スコアは単なるダッシュボードに過ぎません。トレース連携があれば、チームは障害のデバッグ、ケースの再現、リリースの比較、インシデントとカバレッジの関連付けを行うことができます。

デバッグマップ:回答が間違っている場合 -> プロンプト、モデル、取得、グラウンディングを検査します。回答は正しいが安全でないアクションの場合 -> ツール、ポリシー、承認、状態検証を検査します。不安定なエージェントの場合 -> 繰り返し軌跡、変動、ループ、コスト、レイテンシを検査します。本番環境のドリフトの場合 -> リプレイ、カナリア、依存関係の変更、インシデントトレースを検査します。

生産保証は証拠を行動に移す

評価はリリースで終わりではありません。トラフィック、コーパス、ツール、プロンプト、ポリシー、モデル、ユーザー行動の変化に伴い、本番環境の動作が変化する可能性があります。そのため、リプレイ、カナリアリリースまたはオンライン保証、ドリフト検出、長時間セッション監視、インシデントリプレイなどを通じて、継続的にチェックを行う必要があります。

重大な問題が発生した場合、システムは単なる警告ではなく、責任ある意思決定へと導く必要があります。リリースおよび本番環境における保証に関する決定は、証拠とライフサイクル段階に応じて、合格、不合格、レビュー、隔離、ロールバック、ダウングレード、または無効化のいずれかの結果を出力する可能性があります。再認証は、修正を証明し、適用範囲を更新し、機能を承認済みの状態に戻すためのフォローアップワークフローです。

運用保証システムは、キューの負荷、プロバイダのスロットリング、予算の枯渇、古いキャッシュの再利用、レビュー担当者のバックログなどの理由で、リスクの高いスライス、繰り返し行われる確率的試行、トレースの取得、状態検証、または人間によるレビューのパスを黙って破棄してはなりません。必要なカバレッジが失われた場合、その決定は理由コードと担当者の責任を伴って、レビューまたは失敗へとルーティングされるべきです。

リリースまたは本番環境のテスト実行では、単なるスコアではなく、責任ある判断結果を出力する必要があります。上記のサポートエージェントのケースでは、結果はFAILとなり、トレース、ポリシーイベント、および状態検証ツールに関連付けられた、、、などの理由コードが出力されます。次の対応としてはapproval_boundary_violation、人間によるレビューと、読み取り専用モードへの一時的なダウングレードが考えられます。wrong_authorization_contextstate_modified_before_approval

リリースおよび本番環境における品質保証に関する決定は、追跡可能で、レビュー可能で、責任の所在が明確で、実行可能なものでなければなりません。リスクの高い決定や監査レベルの決定には、EvidenceBundleが必要となる場合がありますが、軽量な開発や CI の実行には通常必要ありません。

チームがOCIを始める方法

チームは初日から完全なリリースグレードのパスを必要とするわけではありません。

• SDK/CLIは、ローカルでのオーサリング、プロンプトおよびRAG回帰テスト、軌跡デバッグ、CIチェック、および開発者への迅速なフィードバックに最適です。
• マネージド評価サービスは、評価が本番環境への移行（A/Bテストを含む）、リプレイ、カナリア保証、ランタイムアクション、共有証拠、機密データ、テナント分離、保持、コスト/容量管理、または監査レベルの証拠をサポートする場合に最適です。

実践的な最初の1週間：RAGパス、ツールパス、拒否またはエスカレーションパスをそれぞれ1つずつ選択する。バージョン管理されたサンプルとトレースを使用してSDK/CLI診断を実行する。ツールの使用、認証、状態検証、および復旧のための軌跡チェックを追加する。その後、重要なスライスを管理評価へと昇格させる。

配信モデルは、2つの異なる評価基準を生み出すべきではありません。SDK/CLIとマネージドサービスでは、宣言されたSUT（テスト対象システム）、バージョン管理されたデータセット、トレース、メトリクス、評価者定義、ゲートポリシー、決定事項、および該当する場合は証拠資料を共有する必要があります。

OCI実装では、開発者は軽量なSDK/CLI実行を使用してローカル診断やCI回帰テストを実施できます。評価エンジニアは、トレースカバレッジ、RAGエビデンス、ツール/MCPチェック、信頼性実行を追加できます。リリースオーナーは、選択した実行を管理ゲートに昇格できます。セキュリティ、プライバシー、SREチームは、本番環境リプレイ、カナリア保証、ランタイムアクション、エビデンスパッケージを使用して、デプロイされたエージェントを承認された範囲内に維持できます。

エージェントが行動を起こす前に尋ねられる6つの評価質問

重大な行動を起こす前に、次のことを自問してください。

1. どのSUT、モデル、プロンプト、ツール、ポリシー、データセットのバージョンがテストされましたか？
2. どのようなシナリオ、リスク区分、ネガティブパス、および生産プロセスが対象となりましたか？
3. どの検索証拠、引用、およびアクセス制御の決定がその答えを裏付けたのか？
4. どのツールが、どのような引数、ID、認証、承認のコンテキストで呼び出されたのか？
5. どの状態が変化したのか、そしてそれはどのように検証されたのか？
6. システムがドリフトしたり、故障したり、ループしたり、境界を侵害したり、証拠のカバレッジを失ったりした場合、どうなるでしょうか？

成熟度境界

このフレームワークは、証拠の質と意思決定の規律を向上させるものであり、AIリスクの不在を証明するものではありません。本番運用、監査対応、またはリファレンスアーキテクチャに関する主張は、実装証拠が作成、レビュー、承認された特定のSUTクラス、リスク階層、意思決定グレード、および配信モデルに対してのみ行うべきです。これらの成果物が存在するまでは、正しい主張はより限定的になります。つまり、フレームワーク設計は定義済みであり、実装証拠は保留中であるか、実際に存在する成果物の範囲に限定されます。

回答チェックからライフサイクル評価まで

次のフロンティアはライフサイクル評価です。テストプロンプト、検索、ツール、軌跡、状態変化、信頼性、本番環境の動作、および復旧をまとめて評価します。

エージェント機能は、結果が有用であり、経路が許容可能であり、ツールとデータが承認されており、状態変化が検証されており、何らかの問題が発生した場合にシステムが復旧できる場合にのみ推進されるべきである。

適切な初期評価セットには、RAGジャーニー、ツール対応ジャーニー、ネガティブパス、リカバリパス、および本番環境のリプレイスライスがそれぞれ1つずつ含まれている必要があります。カバレッジを拡大する前に、これらのパスを追跡可能にしてください。

モデルが提案する。システムが動作する。プラットフォームはライフサイクル全体を評価する必要がある。