AIエージェントの監視｜残す5つのログ

AIエージェントが営業メールの下書きを作った。文章は自然で、担当者もそのまま使えそうだと感じた。ところが、参照した顧客情報が一世代前だった。なぜ古い情報を選んだのか、後から確かめようとしても記録がない。

こうなると、原因はモデルなのか、検索なのか、指示なのか、それとも権限設定なのかを切り分けられない。再現できない失敗は直しにくい。同じ事故が起きないことを祈る運用になってしまう。

AIエージェントの監視で見るべきものは、CPU使用率やAPIエラーだけではない。依頼から判断、ツール操作、承認、結果までを一つの実行として追えるかが要点だ。

AIエージェントの監視は「答え」だけを見ても足りない

通常のチャットAIなら、入力と回答を比べるだけでも多くの問題を見つけられる。AIエージェントは事情が違う。途中で検索し、複数のツールを呼び、外部データを読み、ときには業務システムを書き換えるからだ。

Google Cloudのエージェント評価文書では、最終回答に加えて、予測されたツール呼び出しの軌跡と期待する軌跡を比較する考え方が示されている。この考え方を業務運用へ当てはめると、最終結果が正しくても、禁止された経路を通った実行を不合格にできる。

監視と評価も分けて考える。

• 評価は、用意したテストで期待どおりに動くかを判定する
• 監視は、実際の業務で何が起きたかを継続して捉える

公開前のテストに合格しても、入力データ、利用者、接続先は変わる。AIエージェントの評価設計で合格条件を作り、本番では同じ条件を監視へつなげる。この両方が必要になる。

2026年7月に更新されたAIセーフティ・インスティテュートの評価観点ガイドも、AIエージェント特有の観点として「観測と制御」を追加した。自律的な挙動と外部環境との相互作用を捉えることが、従来の回答評価だけでは足りない理由である。

成果物・安全性・観測性を扱った概念編に対し、ここでは一件の実行を調査できる実装仕様に絞る。5つの「ログ」は厳密には、実行コンテキスト、トレース、監査ログ、評価結果、運用メトリクスである。保存先や保持期間は異なっても、共通の実行IDで結ぶ。

ログ1：依頼と実行条件

最初に残すのは、何を頼まれ、どの条件で実行したかだ。入力文を丸ごと保存するだけでは足りない。

版の記録は地味だが効く。モデルや指示を更新した翌日に品質が落ちたとき、変更前後を比較できるからだ。知識源はファイル名だけでなく、更新日時や版番号まで持たせたい。

一方、依頼文に個人情報や契約情報が含まれるなら、全文保存は危ない。監視のために機密情報を増やしては本末転倒だ。保存対象、マスキング、閲覧権限、保持期間を先に決める。

ログ2：判断とツール操作の軌跡

次に、AIエージェントがどの順番で何をしたかを残す。

• どの知識源を検索したか
• どのツールを、どんな目的で呼んだか
• 呼び出しが成功したか
• 何回再試行したか
• どの条件分岐を選んだか
• どこで停止したか

ここで保存したいのは、モデルの長い思考文ではない。監査に必要なのは、外から確認できる行動と客観的な証跡だ。たとえば、検索クエリ、参照文書のIDと版、ツール名、機密値を除いた引数、応答コード、結果の識別子やハッシュ、状態遷移を構造化して残す。その上で「候補が2件あり、一意に決められないため更新せず停止した」と要約する。

要約だけでは再現できない。要約と原データを分け、通常の運用画面ではマスキング済みの項目だけを見せる。原データへのアクセスは障害調査担当に限定し、閲覧した事実も監査ログへ残す。

この形なら、個人の内省のような曖昧な文章を集めずに、再現可能な事実を追える。API仕様書で決める5つの契約に沿って、入力、出力、認証、エラー、版を記録項目へ落とすと、外部接続の調査もしやすい。Oracleの監視・評価ガイドでも、応答だけでなくインタラクション、エラー、利用パターンを追跡する考え方が示されている。

状態遷移も同じ実行IDへ結びつける。AIエージェントの状態管理で整理した「受付済み」「確認中」「承認待ち」「完了」のような状態があれば、どこで滞留したかを集計できる。

ログ3：権限、承認、外部変更

事故の影響が大きいのは、AIが外部へ変更を加える場面だ。メール送信、CRM更新、ファイル移動、契約処理などは、結果だけでなく権限の根拠を残す。

最低限、次の項目が要る。

1. 実行主体と認証方式
2. 要求した権限と実際に使った権限
3. 対象システムと対象レコード
4. 変更前後の差分
5. 承認者、承認時刻、承認対象
6. 取消や復旧に必要な識別子

「人が承認した」という一行だけでは弱い。承認後に内容が変わった可能性を除けないからだ。承認時の下書きに識別子を付け、実行した内容と一致するかを確認する。

権限不足で止まった記録も重要である。失敗件数として隠すのではなく、安全機能が働いた件数として分ける。社内AIエージェントの権限設計と監視項目を同じ表で管理すると、設計した境界が本番でも守られたかを確認しやすい。

ログ4：結果と業務上の合否

「処理が正常終了した」と「仕事が成功した」は別物だ。メールAPIが200を返しても、宛先や内容が間違っていれば業務は失敗である。

結果ログには、技術的な成否と業務上の合否を分けて持たせる。

Google Cloudの本番AIエージェント向けKPIガイドは、従来の言語モデル評価だけでは自律型エージェントを測りきれないと整理している。現場でも、回答の自然さだけでなくタスク完了と業務成果を見る必要がある。

重大な失敗は平均点に埋めない。「権限外の更新が1件でもあれば不合格」「誤送信は0件」のように、別枠の失格条件を置く。100件中99件が成功しても、残り1件が契約書の誤送信なら安心とは言えない。

ログ5：時間、コスト、障害

最後は、実行時間、利用量、障害の記録だ。AIエージェントは複数回のモデル呼び出しとツール操作を重ねるため、1回の回答だけを見るより費用と待ち時間が膨らみやすい。AIエージェントの費用を分ける5つの内訳と同じ単位で記録すると、見積もりと実績を比較できる。

見る項目は次のとおりである。

• 全体の処理時間と工程別の時間
• モデル呼び出し回数とトークン量
• ツール別の呼び出し回数
• 再試行と同じ処理のループ回数
• 1タスク当たりの費用
• エラー種別と復旧までの時間

IBMによるAIエージェントの評価解説でも、成功率、エラー率、コストが代表的な指標として挙げられている。特に見るべきは平均だけではない。上位5％の遅い実行や、費用が急増した実行を追うと、無限ループや外部APIの不調を見つけやすい。生成AIのAPIを選ぶ4つの運用条件にあるデータ保持や可用性も、障害調査に必要な前提としてログ台帳へ含めたい。

上限も仕様にする。「同じツールは3回まで」「10分を超えたら人へ戻す」「予算上限を超える前に停止する」と決める。監視は異常を眺める画面ではなく、止める条件と組み合わせて初めて役に立つ。

要件定義と受け入れテストへ変換する

5種類の記録は、実装担当だけのメモにしない。要件定義書、受け入れテスト、運用責任へ対応付ける。

責任分界も曖昧にしない。発注側は業務上の合否と権限を決める。開発側は記録と停止を実装する。運用保守側は警告を見て、復旧と再開を担う。どこか一社へ「監視をお願いします」と丸投げすると、通知は届いても判断者がいない状態になる。

5つのログを一つの実行IDでつなぐ

ログが別々のサービスに散らばると、調査のたびに時刻を手掛かりに照合することになる。そこで、依頼を受けた時点で実行IDを発行し、すべての記録へ付ける。

流れはシンプルだ。

1. 依頼受付時に実行IDを作る
2. 判断、検索、ツール操作へ同じIDを渡す
3. 承認画面にもIDを表示する
4. 結果、費用、エラーを同じIDへ結びつける
5. 人への引き継ぎ時にもIDを渡す

これで「なぜこの結果になったか」を一件ずつたどれる。ダッシュボードは後でよい。最初は、1件の実行を端から端まで再現できる構造を優先する。

監視設計の成果物は、ログ項目一覧だけではない。正常、警告、停止、事故の条件と、誰がいつ見るかまで決める。

AIエージェントの監視は、ログを大量に集める競争ではない。失敗を再現し、安全に止め、次の改善へつなげられる記録を選ぶ仕事だ。

株式会社Atsumellでは、業務フローの可視化から、AIエージェントの権限、停止条件、評価、監視までを一続きの仕様として設計している。試作品は動いたが、本番で何を記録すべきか決まっていない場合は、お問い合わせから相談してほしい。

関連記事

• AIエージェントの要件定義は評価設計から
• AIエージェントは「状態管理」で壊れにくくなる
• 社内AIエージェントは権限設計から