AIエージェントを社内業務に入れると、最初は「評価を通したか」「監査ログを残したか」に意識が向きます。けれど、本番で困るのはその後です。tool error が増えている、同じ handoff を繰り返す、承認待ちが詰まる、外部送信前に怪しい retrieval を読んでいる、コストだけが急に跳ねる。こうした変化に気付けないと、事故になるまで誰も止められません。
この記事では、Claude Code、Codex、MCP server、社内 workflow agent を含む AIエージェント本番監視 の設計を整理します。事後に何を説明できるように残すかは AIエージェント監査ログ設計ガイド、本番投入前に何を落とすかは AIエージェント評価設計ガイド、事故後の止め方は AIエージェント停止手順ガイド、MCP server の事前審査は MCP サーバーカタログ設計ガイド に分けています。
今回扱うのは、稼働中の agent を何で観測し、どの兆候でアラートし、どの条件で止めるかです。
先に結論: AIエージェント監視はLLM監視だけでは足りない
AIエージェントの監視を、model latency、token usage、error rate だけで作ると弱いです。agent はモデルを呼ぶだけでなく、tool を選び、引数を作り、MCP や外部 API に触り、handoff し、人間承認で止まります。
私なら、最小構成でも次の7つを別々に見ます。
| 監視対象 | 見るもの | 典型的な異常 |
|---|---|---|
| run | 成功率、失敗理由、所要時間 | task が終わらない、timeout が増える |
| trace | agent span、generation、tool call、handoff | 同じ手順をループする |
| tool | tool 名、target、arguments、result | wrong tool、write tool の急増 |
| approval | 承認待ち時間、却下率、例外承認 | 承認が詰まる、却下理由が偏る |
| MCP | server、scope、response、token | 未承認 server、scope elevation |
| cost | input/output tokens、cache、外部 API cost | 1 run あたりの単価が跳ねる |
| safety | guardrail、外部送信、secret access | block すべき操作が通りそうになる |
OpenAI Agents SDK の tracing は、agent run、LLM generation、tool call、handoff、guardrail を trace / span として見られる構造を持っています。OpenTelemetry の GenAI semantic conventions も、GenAI client、MCP、provider 固有の span / metrics / events を扱う方向に進んでいます。つまり、本番監視は「ログを眺める」ではなく、agent run の操作列を観測可能にする設計として考えるべきです。
監視の単位は agent_run_id に寄せる
最初に決めるのは、監視単位です。私は agent_run_id を中心にします。
agent_run_id: agent-20260621-support-triage-0042
workflow: support_triage
agent_version: support-router@2026-06-21
permission_profile: read_then_draft
trace_id: trace_abc123...この ID を、trace、tool log、approval log、MCP request、PR / ticket / artifact に渡します。これがないと、アラートが出ても「どの依頼のどの操作か」を人間が追えません。
監査ログの記事では、後から説明できる証跡として相関IDを扱いました。本番監視では同じ ID を使って、稼働中に検索できるようにします。目的が違います。
- 監査ログ: 後から説明する
- 本番監視: 途中で気付いて止める
この2つを同じ schema で始めると楽ですが、保存期間と粒度は分けます。監視ダッシュボードに raw prompt や raw tool response を丸ごと出す必要はありません。
まず見るべきSLO
AIエージェントにいきなり細かい品質指標を入れるより、最初は運用 SLO を決めます。たとえば社内 PR review agent なら、次で十分です。
| SLO | 例 | アラート条件 |
|---|---|---|
| completion rate | 24時間で完了率 95%以上 | 1時間連続で 80% 未満 |
| median runtime | 1 run 10分以内 | p95 が 30分超 |
| tool error rate | tool call 失敗 5% 未満 | 15分で 20% 超 |
| approval wait | 承認待ち p95 2時間以内 | p95 が 8時間超 |
| unsafe block | high-risk tool は approval 必須 | approval なし write を検知 |
| cost per run | 通常 run の3倍未満 | 3回連続で閾値超え |
ここで「正しい答えを出したか」を SLO にしすぎない方がよいです。品質評価は eval suite で別に見ます。本番監視の初期目的は、詰まり、暴走、権限逸脱、外部影響、コスト異常を早く見つけることです。
trace で見るべき異常
trace では、最終回答ではなく操作列を見ます。OpenAI Agents SDK の default tracing は run 全体、agent span、generation、function tool、guardrail、handoff を span として扱います。この構造を前提にすると、見るべき異常はかなり具体化できます。
| 異常 | 見方 | 止める条件 |
|---|---|---|
| handoff loop | 同じ agent 間の往復回数 | 3回以上で human review |
| tool retry loop | 同じ tool / 同じ target の連続失敗 | 5分で3回失敗したら停止 |
| context thrash | retrieval query が広がり続ける | query数が通常の3倍 |
| late approval | write tool 直前まで承認情報なし | tool guardrail で block |
| silent degradation | final output はあるが required tool 未実行 | warning ではなく failed |
trace は「あとで眺めるグラフ」ではなく、実行中の停止条件に使います。たとえば handoff が3回続いたら、その run を人間確認へ回す。write tool の前に approval span がなければ block する。MCP write の前に catalog entry が見つからなければ止める。ここまで落とすと、監視が運用制御になります。
tool call は name / target / scope を分けて集計する
tool call の監視でよくある失敗は、tool_name だけを見ることです。同じ github tool でも、PR を読むのと issue にコメントするのではリスクが違います。
最低限、次の形で集計します。
{
"agent_run_id": "agent-20260621-support-triage-0042",
"tool_name": "github.create_issue_comment",
"target": "repo:nidoneko/HP",
"scope": "write:issue_comment",
"risk_level": "external_write",
"approval_id": "apr-20260621-09",
"result": "success",
"duration_ms": 842,
"input_tokens": 1290,
"output_tokens": 180
}集計軸はこの4つです。
tool_name: 何を呼んだかtarget: どの repo / system / URL に触ったかscope: read / write / admin / external-send のどれかrisk_level: 人間承認や停止条件に使う分類
OpenTelemetry GenAI semantic conventions では、tool call id、tool name、tool arguments、provider、model、token usage などを表現する方向が示されています。実務では、そのまま vendor 固有の trace に閉じず、自社の risk level を付け足す方が運用しやすいです。
MCP は server health ではなく scope drift を見る
MCP server の監視を uptime だけで見るのは足りません。AIエージェント運用で怖いのは、server が落ちることより、使うべきでない server や scope が使われることです。
見るべき項目は次です。
| 項目 | 正常 | アラート |
|---|---|---|
| server | catalog 登録済み | 未登録 server |
| version | 承認済み version | 未レビュー version |
| scope | task に必要な最小 scope | read task で write scope |
| token | 専用 service account | 個人 token / token passthrough |
| response | 要約ログのみ | raw PII / secret を監視基盤へ送る |
OWASP の Agentic AI threats は、LLM を組み込んだ autonomous system では能力とリスクが拡大することを前提に threat-model-based な整理を求めています。MCP も同じです。server が生きているかより、agent がどの権限で何をしたかを見ないと、運用リスクは下がりません。
アラートは少数の停止条件から始める
最初から高度な異常検知を入れる必要はありません。むしろ、最初は確実に止めるべき条件だけでよいです。
私なら、初期アラートは次の8つに絞ります。
- high-risk tool が approval なしで呼ばれた
- read-only run で write scope が要求された
- 未承認 MCP server が使われた
- 同じ tool が同じ target に3回連続失敗した
- handoff が3回以上ループした
.env、secret、credential file にアクセスした- 外部送信前に未信頼コンテンツを読んでいた
- 1 run の cost が直近中央値の3倍を超えた
このうち 1〜3 は即停止、4〜5 は human review、6〜7 は security review、8 は rate limit / budget review に回します。
alerts:
high_risk_without_approval:
severity: critical
action: pause_run
read_only_scope_violation:
severity: critical
action: block_tool
repeated_tool_failure:
severity: warning
threshold: 3
action: route_to_human
cost_spike:
severity: warning
threshold: 3x_median
action: reduce_concurrency重要なのは、アラート名ではなく action です。通知だけ出して誰も止めないなら、監視ではなく雑音になります。
ダッシュボードは3枚で足りる
AIエージェント監視のダッシュボードを最初から作り込みすぎる必要はありません。私は3枚に分けます。
1. Operations
- run count
- completion rate
- p50 / p95 runtime
- timeout count
- queued / running / waiting approval
- cost per run
これは運用担当が見る画面です。詰まりとコストを見ます。
2. Safety
- high-risk tool count
- approval missing count
- guardrail triggered count
- forbidden target access
- secret / credential access
- external write count
これは security / platform owner が見る画面です。止めるべき挙動を見ます。
3. Product Quality
- human correction rate
- reopen / retry rate
- eval regression after deploy
- top failure reasons
- ignored / abandoned runs
これは agent owner が見る画面です。便利さより、実務に耐えているかを見ます。
NIST AI RMF Playbook は Govern / Map / Measure / Manage の各機能に沿った行動例を示しています。本番監視は特に Measure と Manage に寄ります。測るだけでなく、測った結果を権限、運用、再開条件へ戻す必要があります。
prompt を直す前に分類する
本番監視で異常が出ると、すぐ prompt を強くしたくなります。ただし、原因は prompt とは限りません。
| 失敗分類 | 直す場所 |
|---|---|
| instruction_gap | system prompt、AGENTS.md、task template |
| tool_schema_gap | tool description、argument schema、examples |
| permission_gap | permission profile、approval policy、scope |
| mcp_catalog_gap | server owner、version、scope、kill switch |
| context_gap | retrieval、docs、input form |
| eval_gap | smoke eval、forbidden tool case |
| runbook_gap | alert action、owner、reopen condition |
たとえば「agent が GitHub に不要な comment を投稿した」場合、prompt を直す前に見るべき場所があります。write scope が広すぎないか。approval policy が抜けていないか。tool schema が comment と draft_comment を区別できているか。MCP catalog で external write として扱っているか。ここを見ずに prompt だけ直しても再発します。
小さく始める導入順序
最初の2週間なら、この順で十分です。
agent_run_idとtrace_idを全 artifact に渡す- run / tool / approval / MCP の4種類だけ構造化する
- high-risk tool と external write に risk level を付ける
- approval missing と read-only violation を即停止にする
- repeated tool failure と handoff loop を human review に回す
- cost per run と p95 runtime を見る
- 週次で top failure reasons を分類する
- 分類結果を eval、permission、MCP catalog、runbook に戻す
この順番なら、最初から高価な AI observability 製品を入れなくても始められます。重要なのは、trace を取ること自体ではなく、trace から止める条件を作ることです。
よくある失敗
1. 成功率だけを見る
成功率が高くても危険な tool を使っている可能性があります。completion rate と safety signal は分けて見ます。
2. raw prompt を監視基盤へ流す
監視しやすくなりますが、機密情報の二次漏洩源になります。通常ダッシュボードは要約、raw payload は短期保持の隔離ログに分けます。
3. アラートに owner がない
critical でも誰が止めるかが決まっていないと意味がありません。alert rule には owner と action を必ず持たせます。
4. eval と本番監視を切り離す
本番で起きた failure reason は、次の eval dataset に戻します。逆に eval で見ている forbidden tool が本番監視にないなら、release gate と runtime gate がずれています。
5. MCP を普通のAPI連携として扱う
MCP は agent が tool として呼ぶため、通常の API uptime だけでは足りません。server、scope、token、tool risk、response handling を一緒に見ます。
まとめ
AIエージェント本番監視の目的は、きれいな trace 画面を作ることではありません。稼働中の agent が、いつ詰まり、いつ権限を超え、いつ外部へ影響しそうかを早く見つけ、止めることです。
監査ログは後から説明するための設計です。評価設計は本番前に落とすための設計です。停止手順は事故後に広げないための設計です。本番監視は、この3つを稼働中につなぎます。
私なら、最初は agent_run_id、trace、tool risk、approval、MCP scope、cost、停止条件だけを入れます。そこまで見えない agent に、write 権限、外部 action、MCP write scope を広げるのは早いです。