AI時代の監視課題：「壊れていないが間違っている」問題
これまでのソフトウェア運用における監視は、システムが「壊れていないか？」という問いを中心に構築されてきました。メトリクス、ログ、トレースといった多様なツールを活用し、分散システムにおいても単一のリクエストを追跡する能力は非常に発達しています。
「従来の監視は、ソフトウェアの障害が最終的に機械で測定できる形で現れる」という前提に基づいています。
しかし、AIエージェントの登場により、この前提が揺らぎ始めています。例えば、顧客からの払い戻しリクエストを処理するAIエージェントを想像してみてください。応答速度は600ミリ秒、エラーレートはゼロ。
完璧に稼働しているように見えます。しかし、ポリシーでは140ドルの払い戻しが適切であるにもかかわらず、AIは古いドキュメントを参照して40ドルと回答してしまいました。
ダッシュボードはすべて緑色で、どこも「壊れていない」ように見えますが、決定は「間違っている」のです。（出典）
このような状況は、従来の監視アプローチでは発見が困難です。私の個人的なプロダクトでもAIエージェントを活用することを検討していますが、こうした「壊れていないが間違っている」ケースへの対処は、開発段階から考慮しておかなければならない重要なポイントだと感じます。特に、ユーザーとの直接的な対話が発生するようなサービスでは、信頼性に直結するため、設計段階での評価基準の明確化が不可欠です。
AIエージェントに特化した「実行レベルでの正確性」の測定
AIエージェントの場合、同じコードを実行しても、質問のフレーズ、取得されたコンテキスト、使用したツール、そしてモデルが生成した内容によって、あるリクエストは正しく、次のリクエストは間違っているという事態が発生し得ます。これは、エージェントが動作中に多くの振る舞いが決定されるという特性によるものです。
| 項目 | 従来のソフトウェア | AIエージェント |
|---|---|---|
| 監視の焦点 | システムのダウン、エラー | 振る舞いの正確性、意図通りか |
| 品質評価のタイミング | リリース前テストが主 | リリース後も継続的な実行時評価が必須 |
| 問題の現れ方 | エラーコード、レイテンシ | 正しくない出力、意図しない行動 |
| 解決策 | コード修正、インフラ調整 | プロンプト調整、ツール選択ロジック改善、モデル更新 |
したがって、「ソフトウェアが正しいことをしているか？」という問いは、リリース前に完全に答えることができなくなりました。その一部は、本番環境での継続的な実行を通じて明らかにする必要があります。Amazon CloudWatch Omniは、エージェント、アプリケーション、インフラを統合的に監視することで、この新しい課題に対応しようとしています。
評価の明示化と根本原因の追跡
AIエージェントの「正確性」を測定するには、その品質を明確に定義し、評価可能な形に落とし込む必要があります。例えば、「正しい払い戻し決定とは何か？」「エージェントはいつエスカレートすべきか？」といった問いに対し、具体的な運用上の定義を定めることが求められます。
このプロセス自体が、チームにとって暗黙知を形式知に変換する貴重な機会となるでしょう。（出典）
払い戻しが間違っていたとして、それが「チェーンのどこで間違ったのか」を追跡することが重要になります。
モデルの推論が悪かったのか、それとも下流の支払いサービスが古い設定で実行されていたのか。顧客の質問から、エージェントの決定、そしてその下のサービスに至るまで、原因と結果の連鎖を追跡できる可視性が必要です。AIエージェントがアプリケーション内のコンポーネントとなる以上、その振る舞いはシステム全体と並行して可視化されるべきです。
私の自宅で動かしているローカルLLMやStable Diffusionの試行錯誤でも、この評価の明示化は課題だと感じています。特に、生成されるコンテンツの「良し悪し」を定量的に評価するのは一筋縄ではいきません。そのため、人間が介入してフィードバックを返す仕組みを組み込むことを考えています。
今後の監視システムに求められる能力
ダッシュボードは、重要なシグナルを継続的に可視化する上で引き続き有用です。しかし、AIエージェントシステムでは、異常な事態が発生した後に初めて明らかになる重要な疑問が追加されます。例えば、「今週、ヨーロッパの顧客に対する払い戻し精度が低下したのはなぜか？」「取得ロジック、ツール選択、または下流サービスで何か変更があったか？」といった問いです。
これらの質問に直接答え、関連するテレメトリ（観測データ）をシステムが自動的に収集・提示できる能力が、今後のインシデント調査のあり方を大きく変えるでしょう。また、本番環境で発生した「間違った実行」は、単なるインシデントレポートで終わるべきではありません。
エージェントが間違った結果を出したトレース（実行経路）は、新しいデータセットとして活用できます。チームは、そのデータセットに対して変更を試し、新しいバージョンと古いバージョンを比較し、デプロイすることで、継続的な改善サイクルを回せるようになります。
この動きは、AIがコード生成や自動化の領域に深く入り込む中で、より一層重要になるでしょう。Claude CodeのようなAIコーディングツールを使っていると、コードの効率性や整合性はもちろん重要ですが、それが「意図した通りに機能しているか」「倫理的に適切か」といった、より高次の品質保証が求められるようになると感じます。単にバグがないだけでなく、その出力が「正しい」と判断できる基準作りが急務です。
