はじめに
AIエージェントの運用監視は、サーバーが動いているかを見るだけでは不十分です。依頼が完了したか、どのツールを使ったか、人へ戻したか、結果が正しかったか、失敗から復旧できたかを一つの実行単位で追跡します。本番導入では「稼働率」より「業務が安全に完了した割合」が中心指標になります。
Google CloudのAgent observabilityは、モデルとのやり取り、ツール利用、エージェントの行動、性能、セキュリティ、品質を監視対象として整理しています。OpenTelemetryも、ログ、メトリクス、トレースを共通の属性で関連付けるための規約を提供しています。
通常システムと異なる失敗
通常のAPIは、成功コードが返れば処理の成否を判断しやすい設計です。AIエージェントでは、処理が正常終了しても内容が不適切なことがあります。逆に、人へ確認を求めて停止した処理は、設計どおりの成功かもしれません。
また、一つの依頼で複数のモデル呼び出しやツール操作が発生します。途中の再試行が増えると、最終結果は得られても、時間とコストが膨らみます。技術状態と業務結果を分けて測る必要があります。
本番で見るべき七つの指標
1. 業務完了率
依頼が定義した完了条件まで到達した割合です。モデルの応答成功率ではなく、登録、通知、確認など業務上の最終状態で測ります。
2. 例外・人への引き渡し率
エージェントが判断を止め、人へ戻した割合と理由を記録します。率が高すぎれば対象範囲や参照データを見直します。ただし、危険な操作を適切に止めた場合は望ましい結果です。
3. 承認待ち時間
人の承認がボトルネックになると、自動化しても全体時間は縮みません。承認依頼から判断までを測り、通知先や権限者を改善します。
4. ツール呼び出し失敗率
APIエラー、権限不足、形式不一致、タイムアウトをツール別に集計します。モデルエラーと外部システムエラーを混ぜないことが重要です。
5. 出力品質
正確性、関連性、ルール適合、差し戻し理由をサンプル評価します。自動評価だけでなく、業務担当者による定期レビューも組み合わせます。
6. 実行コスト
一件あたりのモデル呼び出し回数、トークン、外部API、処理時間を測ります。品質向上のための再試行が、費用に見合っているか判断します。
7. 復旧時間
失敗を検知してから、原因特定、再実行、取消、利用再開までにかかった時間です。長時間処理では、Microsoftが示すようなチェックポイントと再開可能な実行方式が有効です。
ログ・メトリクス・トレースをつなぐ
- ログは、入力検証、例外、承認、ツール結果などの出来事を記録します。
- メトリクスは、完了率、待ち時間、失敗率、コストの傾向を示します。
- トレースは、一件の依頼がモデル、検索、API、承認をどう通ったかを時系列で示します。
三つを実行IDで結ぶと、ダッシュボード上の異常から個別の原因へたどれます。保存項目と機密情報の扱いは証跡設計の6項目を基準にしてください。操作権限の異常はAIエージェントの権限設計と合わせて監視します。
最初のダッシュボード
最初から多数の指標を作る必要はありません。対象業務を一つ選び、「受付件数・完了・人へ引き渡し・失敗・処理時間」の五つを週次で確認します。差し戻し理由を上位三つに分類し、プロンプト、データ、ツール、権限、業務ルールのどこを直すか決めます。
実行チェックリスト
- 業務の完了条件をシステム上で判定できる
- 一件の実行を同じIDで追跡できる
- モデル失敗とツール失敗を分けている
- 人へ戻した理由を分類している
- 品質を定期的に人が確認している
- 一件あたりの時間とコストを見ている
- 途中状態から安全に再開できる
- 異常な権限利用を通知できる
まとめ
AIエージェントの監視では、モデルの応答だけでなく業務の完了、例外、人の承認、ツール、品質、コスト、復旧を一続きで見ます。まず一業務の五指標から始め、実行IDでログ・メトリクス・トレースを結ぶことが、改善可能な運用の土台になります。