AIエージェントは、一度動けば完成するソフトウェアではありません。モデル更新、データ更新、ツール変更、業務ルール変更により挙動が変わるため、継続的な評価と監視が必要です。そこで重要になるのがAgentOpsです。AgentOpsは、エージェントの開発・評価・配備・監視・改善を一つのライフサイクルとして扱う考え方です。
更新日：2026年9月17日。 AIエージェント関連の仕様・製品・料金・提供地域は短期間で変わるため、本稿では考え方と実装判断を中心に整理します。
なぜチャットAIより評価が難しいのか
チャットAIなら、回答の正確さや有用性を見ればよい場合があります。AIエージェントでは、同じ結果に至るまでに複数ツールを使い、途中で判断し、再試行し、外部状態を変えます。最終文章が正しくても、途中で不要な個人情報を取得していたら問題です。逆に途中で遠回りしても、低コストで安全に目的を達成していれば許容できる場合があります。
そのため評価は「最終結果」「過程」「安全」「コスト」「時間」の複数軸で行います。
最初に作るべき評価データセット
本番ログを待つのではなく、導入前に代表ケースを作ります。正常系だけでなく、データ不足、矛盾、曖昧指示、権限不足、API障害、外部文書の不正命令、長い会話、重複依頼などを含めます。各ケースに期待結果と禁止行動を紐づけます。
重要なのは、評価ケースを一度きりのテストにしないことです。プロンプト、モデル、ツール説明、検索方式を変更するたびに同じケースを再実行し、改善した項目と悪化した項目を比較します。
AIエージェントで追う主要KPI
| 分類 | KPI例 | 読み方 |
|---|---|---|
| 成果 | タスク成功率 | 業務の最終目的を達成した割合 |
| 品質 | 回答根拠一致率 | 参照データと結論が一致するか |
| ツール | ツール選択精度 | 正しい機能を選べたか |
| ツール | 引数正確性 | ID・日付・数量などが正しいか |
| 運用 | 人への引継ぎ率 | 自動化できないケースの割合 |
| 運用 | 再試行回数 | ループや不安定性の兆候 |
| 速度 | 完了時間 | 人手・従来システムとの比較 |
| 費用 | 1タスクコスト | モデル・検索・API・計算資源の合計 |
| 安全 | ポリシーブロック件数 | 危険操作を防げた回数 |
| 安全 | 重大逸脱率 | 禁止操作・漏えいなどの発生率 |
トレースは「何を考えたか」より「何をしたか」を重視する
企業監査で必要なのは、モデルの内部思考を保存することではなく、入力、参照元、選択したツール、引数、実行結果、承認、最終出力といった外部から確認できる行動履歴です。これらを時系列で追えるようにします。
AWSはアラビア語の公式発表で、Amazon ConnectのAIエージェントについて、ツール呼び出しや失敗箇所を追跡できるトレース機能を案内しています。また目標成功率やツール選択精度などの指標も提供しています。特定製品を使わない場合でも、同じ考え方は自社実装に応用できます。
失敗原因を5分類すると改善が速い
- 入力・業務定義の問題：依頼自体が曖昧、必要条件がない
- 知識・検索の問題：必要情報が見つからない、古い文書を参照
- モデル判断の問題：意図理解や推論を誤る
- ツールの問題：説明が曖昧、APIが不安定、引数設計が悪い
- ガバナンスの問題：権限や承認条件が不足または過剰
失敗を「AIが間違えた」でまとめると改善できません。どの層が原因かをタグ付けし、頻度の高い原因から直します。
コスト最適化はモデル単価だけ見ない
高性能モデルから安価なモデルへ変えても、再試行が増えたり、人の確認が増えたりすれば全体コストは上がります。1タスクの総コストには、モデル入力・出力、検索、外部API、ブラウザー実行、コード実行、ストレージ、人のレビュー時間まで含めます。
簡単な分類は小型モデル、複雑な例外判断だけ高性能モデル、長文検索はRAGで絞る、同じ結果をキャッシュする、といった役割分担が有効です。
本番監視で設定したいアラート
- 同じツールを規定回数以上連続実行
- 通常より高いトークン・API費用
- 許可外の外部ドメインへのアクセス
- 重大操作の承認なし実行要求
- 一定時間以上完了しないタスク
- 特定部署・ユーザーで失敗率が急上昇
- モデル更新後の成功率低下
AgentOpsを運用会議に組み込む
週次または月次で、失敗上位、費用、利用量、引継ぎ率、重大ブロック、ユーザーからの苦情を確認し、次の改善項目を決めます。AIエージェントを情報システム部だけの運用にすると、現場業務の正解が分からなくなります。業務担当、IT、セキュリティの三者で見ることが重要です。
実務でさらに深掘りする
AgentOpsは「監視画面」ではなく改善の仕組み
AgentOpsはログを集めるだけでは成立しません。業務KPI、モデル出力、検索、ツール呼び出し、承認、人の修正、コストを一つの改善ループへ結びつけます。ある日の成功率が下がった時に、モデル変更、データ更新、API障害、利用者入力の変化のどこが原因か追える状態を目指します。
そのためには、各実行に一意のトレースIDを付け、入力から最終結果までの主要イベントを関連付けます。個人情報や機密本文は必要以上に記録せず、評価に必要なメタデータを残します。
オフライン評価とオンライン評価を分ける
オフライン評価は、あらかじめ用意した評価セットに対して変更前後を比較する方法です。再現性が高く、リリース前の回帰テストに向きます。オンライン評価は実利用の成功率、修正率、利用率、処理時間などを測り、本番でしか見えないケースを拾います。両方を組み合わせる必要があります。
オフラインで高得点でも、実際の利用者が曖昧な指示を出したり、データが更新されたり、外部APIが遅延すれば本番品質は変わります。オンラインで見つかった失敗を、次のオフライン評価セットへ戻す循環を作ります。
ツール呼び出しを評価する4段階
| 段階 | 評価内容 |
|---|---|
| 選択 | 使うべきツールを選んだか |
| 引数 | ID・条件・期間などを正しく渡したか |
| 実行 | API結果・エラーを正しく処理したか |
| 解釈 | 返り値を次の判断へ正しく使ったか |
最終回答が正しく見えても、間違ったツールや不要な権限を使っている場合があります。逆に最終結果が失敗でも、API障害が原因ならモデルの改善では解決しません。層別評価が重要です。
LLM-as-a-Judgeを過信しない
別のLLMに品質を採点させる方法は大量評価に便利ですが、採点モデルにも偏りと揺れがあります。重要な評価は、人が作った基準と代表ケースで校正し、一定割合を人手で再確認します。数値や構造化データは可能な限り決定的なコードで検証します。
評価基準も「良い回答か」ではなく、必須情報の充足、根拠との一致、禁止事項、文章形式などに分解すると安定します。
コストを品質と同時に最適化する
高性能モデルへすべて投げると品質は上がっても費用と待ち時間が増えます。分類、形式変換、単純抽出は小型モデルやコードへ任せ、曖昧な判断だけ高性能モデルへルーティングする方法があります。失敗時だけ上位モデルへ再試行する設計も有効です。
ただしルーティング自体の誤判定も評価対象です。モデル単価ではなく、成功1件あたりの総費用と処理時間で比較します。
リリースゲートの例
- 重大な禁止操作が評価セットで0件
- 主要タスク成功率が前バージョン以上
- 検索Recallやツール引数精度が基準以上
- P95処理時間が許容範囲
- 1タスク平均費用が予算内
- 人への引継ぎが正しく作動
- 監査ログから主要操作を再構成できる
すべての指標を一つの総合点へ潰さず、安全性のように最低条件を満たさなければ公開しないゲートを設けます。
よくある質問
成功率100％を目指すべきか
業務によります。低リスクの下書き業務なら人の修正を前提に高い自動化率を狙えますが、重大操作では成功率だけでなく誤実行0件を重視します。すべてを一つの精度指標にまとめず、安全性、業務成果、コストを別々に最低基準として持つ方が実務的です。
評価ケースは何件必要か
固定の正解はありません。最初は代表的な20〜100件から始め、失敗が見つかるたびに追加します。件数よりも、通常、境界、異常、攻撃、権限外など重要な失敗パターンを含むことが大切です。業務の多様性が高いほどケースも増やします。
人手評価はなくせるか
完全にはなくせません。構造化された数値や形式はコードで検証できますが、提案の妥当性や顧客向け文章の品質などは人の基準が必要です。LLM評価を使う場合も、人手評価で採点基準を校正し、一定割合を監査して評価器そのもののずれを確認します。
本番ログを評価データに使ってよいか
機密情報や個人情報をそのまま評価環境へコピーしないようにします。匿名化、マスキング、合成データへの置換を行い、必要な失敗構造だけを残します。利用規約や社内ルールも確認します。評価のために新しい情報漏えい経路を作らないことが重要です。
モデル変更のたびに何を見るか
主要タスク成功率、検索、ツール選択、引数、処理時間、費用、安全性を同じ評価セットで比較します。平均値だけでなく、重大ケースが悪化していないかを確認します。改善した指標があっても、安全ゲートを下回る場合は本番切り替えを行いません。
AgentOpsの担当者は誰か
運用チームだけへ任せず、業務オーナー、開発、IT運用、セキュリティが指標を共有します。業務KPIが悪化した場合に現場が、技術障害は開発が、権限逸脱はセキュリティが対応できるよう、アラートの種類ごとに責任者を決めます。
導入判断をより確実にする追加論点
評価結果を改善タスクへ変換する方法
失敗を記録するだけでは改善されません。各失敗へ原因カテゴリ、影響度、頻度、再現手順、担当者、修正予定を付けます。頻度が高く影響が大きいものから直し、修正後に同じケースを再実行します。検索、プロンプト、ツール、データ、権限のどこを変えたかも残すと、何が効いたか学習できます。
同じ失敗が別業務でも起きた場合は、個別プロンプトではなく共通ツールや認証基盤を直すべき可能性があります。AgentOpsは局所修正から組織的な標準化へつなげる役割も持ちます。
ダッシュボードに載せる指標を絞る
運用画面に数十指標を並べても、異常を見つけにくくなります。経営・業務向けには成功率、処理時間、人の確認時間、1件費用、重大事故を中心にし、開発者向けには検索Recall、ツール選択、引数エラー、再試行、モデル別費用を持ちます。
役割ごとに見る指標を分け、閾値を超えた時だけ詳細トレースへ入れる構成にすると、運用負担を抑えられます。
評価データを企業資産として管理する
良質な評価ケースは、企業固有の業務ルールと失敗知識が詰まった資産です。アクセス権限、変更履歴、期待結果の承認者を管理し、モデルベンダー変更時にも持ち出せる形式で保存します。
本番ログから追加する場合は個人情報を除去し、実際の顧客データを必要以上に複製しません。評価基盤を整えるほど、新モデルや新しいAIエージェントを安全に比較する速度が上がります。
実装・運用の最終補足
評価設計を経営会議で使える形にする
AgentOpsの評価結果は、開発者だけが見る技術ダッシュボードで終わらせず、事業判断へ翻訳します。例えば成功率が95％でも、残り5％が契約・支払いなど重大業務に集中していれば自動化範囲を広げるべきではありません。逆に軽微な文章修正が中心なら、人の確認工数を計測しながら自動化率を上げられます。
月次レビューでは、業務成果、安全、費用、利用定着の4分類で前月と比較し、次月に変更する一つか二つの仮説を決めます。変更を同時に大量投入すると何が効いたか分からなくなるため、評価可能な単位で改善します。評価を「採点」ではなく、経営と開発が同じ事実を見て次の投資を決める仕組みにすると、AgentOpsが事業運用の一部になります。
参照した一次情報・海外情報
本稿は、単一記事の翻訳転載ではなく、複数の一次情報・公式ドキュメントを照合し、日本企業の導入判断に必要な観点へ再構成したオリジナル解説です。各仕様は更新されるため、実装時はリンク先の最新版をご確認ください。
- Amazon Connect AI agent metrics（AR）
- Amazon Connect AI agent traces（AR）
- Build agents you can trust across any framework（EN）
- 智能体开发工程师（高级）（ZH）
- 20 questions for the Agentic Enterprise（EN）
AIエージェント導入を、構想だけで終わらせないために
AIエージェントは、モデル選定だけでは成果が決まりません。対象業務の分解、データ接続、権限、評価、現場運用までを一つの設計として扱う必要があります。Accomplirでは、AI導入、RAG、MCP、FDE人材、業務自動化を分断せず、実際に使われ続ける状態まで支援します。
AIエージェント・AI導入について無料相談する / FDE人材の発注・育成を見る / MCP導入の考え方を見る / RAG構築の考え方を見る