---
title: "AIエージェント監視ダッシュボード：1,238回の実行"
description: "AIエージェント監視ダッシュボードに必要なパネルを、自分の30日分のログ（ツール呼び出し127,610回、実行1,238回）から示し、一律の制限が外れる理由も説明します。"
url: "https://madsalt.tech/ja/blog/ai-agent-monitoring-dashboard/"
author: "Denys Zaichenko"
language: "ja"
published: 2026-10-29
---

# AIエージェント監視ダッシュボード：1,238回の実行

TL;DR

私が開発に使っているエージェント環境から、30日分のログを取り出しました。ツール呼び出しは127,610回、完了したエージェントの実行は1,238回です。監視ダッシュボードに何を表示すべきかは、3つの事実で決まりました。ツールエラーの59%は、何かが壊れたのではなく、私自身のガードルールが何かを拒否したものでした。だからエラーには2つのカウンターが要ります。すべてのエージェントに同じ制限時間を課すのは間違いです。テスト先行のコーディングエージェントの21%は12分を超えましたが、コード探索役は0%でした。そして、エージェント起動の5回に1回は、開始前に拒否されており、「1日あたりの実行数」のグラフにはこれが一切現れません。

私はDenys、フルスタックかつAIエンジニアです。1つのリードのコーディングセッションが、専門のエージェントに仕事を渡す形で開発しています。探索役、プランナー、テスト先行のコーダー、セキュリティとコードのレビュー役です。[3,315回のエージェント実行で壊れたもの](https://madsalt.tech/ja/blog/multi-agent-orchestration-what-broke/)では失敗を数えました。この記事で問うのは別のこと、ダッシュボードに何を載せるべきか、です。

**データ。** 私自身の環境のセッションログと起動台帳、2026年9月24日から10月23日まで。以下の数字はすべて、1つのスクリプトでそこから算出しました。クライアント名とプロジェクト名は、使ったデータに含まれていません。1人分の作業量であり、ベンチマークではありません。

## AIエージェント監視ダッシュボードには何を表示すべき？

[Grafanaのエージェントオブザーバビリティのドキュメント](https://grafana.com/docs/grafana-cloud/observe-and-act/agent-observability/)のようなベンダーのガイドは、レイテンシ、トークン、コスト、エラーを中心に据えています。私のログが示すのは、この4つは必要だが十分ではないということです。パネルは5つです。

1. **起動：開始、拒否、完了、失敗**を日ごとに。
2. **エラーを「ルールに拒否された」と「壊れた」に分けて**、ツールごとに。
3. **エージェントの種類ごとの所要時間とツール呼び出し数**を、中央値と90パーセンタイルで、種類ごとの制限付きで。
4. **実行あたりのトークン**。これがコストです。
5. **現在実行中のもの**を、各実行の経過時間と、その種類の通常範囲とを並べて。

この記事の残りは、それぞれの裏付けとなる数字です。

## 開始すらされないエージェント起動はどのくらい？

| 起動、30日間   | 件数         |
| -------------- | ------------ |
| 起動の試行     | 1,775        |
| 開始前に拒否   | 352（19.8%） |
| 最も多かった日 | 258回の起動  |
| 中央値の日     | 40回の起動   |

私の環境は、起動のたびに確認します。指示書がエージェントの変更してよいファイルを挙げているか、実行中の別のエージェントがすでにそのファイルを押さえていないか、リスクのある工程にどのモデルが必要か。5回に1回の起動は通りませんでした。実行数のグラフは開始した起動だけを数えるので、これらはすべて隠れます。

## ツールエラーになぜ2つのカウンターが要る？

127,610回のツール呼び出しのうち、6,691回がエラーで返りました。1,000回あたり52回です。次に、エラーの内容で分けました。

![ツールエラー6,691件の内訳。30日間で127,610回のツール呼び出し。自分のガードルールに拒否：3,954、本当に失敗：2,737。](https://madsalt.tech/charts/ja/ai-agent-monitoring-dashboard-errors.svg)

*図1. 私のエージェントのログ、2026年9月24日から10月23日まで。エラーのテキストで分類。*

| ツール           | 呼び出し | エラー | うち、ガードルールに拒否 |
| ---------------- | -------- | ------ | ------------------------ |
| シェル           | 50,960   | 4,985  | 2,970                    |
| ファイル編集     | 28,244   | 743    | 602                      |
| ファイル読み取り | 26,348   | 145    | 1                        |
| ファイル書き込み | 8,238    | 208    | 195                      |
| エージェント起動 | 1,719    | 287    | 132                      |
| Web検索          | 2,527    | 57     | 0                        |

6,691件のエラーのうち3,954件、59%は、私自身のルールが「だめ」と言ったものでした。チェックを飛ばすことになるコマンド、必須の確認の前の編集、別のエージェントが持っているファイルへの書き込みです。この数が増えるのは、ルールが働いているか、エージェントがルールと戦っているかのどちらかです。残りの2,737件は本当の失敗です。失敗したテスト、クラッシュしたコマンド、読み込めなかったページ。1つのグラフでは両者が混ざります。拒否が多い日は悪い日に見えますが、実際には何も壊れていません。

## すべてのエージェントに同じ制限時間でよい？

よくありません。私はサブエージェントを12分または80回のツール呼び出しで止めていますが、ログを見ると種類ごとの違いがよく分かります。

![12分の制限を超えた実行。エージェントの種類別の実行の割合（%）、30日間、1,238回。テスト先行コーダー（214回）：21、セキュリティレビュー役（46）：6.50、コードレビュー役（33）：6.10、ブラウザテスト実行役（38）：5.30、汎用（142）：1.40、コード探索役（44）：0。](https://madsalt.tech/charts/ja/ai-agent-monitoring-dashboard.svg)

*図2. 私のエージェントのログ、2026年9月24日から10月23日まで。*

| エージェントの種類     | 実行 | 中央値（分） | 90パーセンタイル | 12分超     | 80回超のツール呼び出し |
| ---------------------- | ---- | ------------ | ---------------- | ---------- | ---------------------- |
| テスト先行コーダー     | 214  | 6.8          | 17.1             | 45（21%）  | 66（31%）              |
| セキュリティレビュー役 | 46   | 5.0          | 10.9             | 3（6.5%）  | 2                      |
| コードレビュー役       | 33   | 4.8          | 10.2             | 2（6.1%）  | 3                      |
| ブラウザテスト実行役   | 38   | 4.3          | 10.5             | 2（5.3%）  | 2                      |
| 汎用                   | 142  | 3.1          | 6.5              | 2（1.4%）  | 8                      |
| アーキテクト           | 72   | 5.2          | 8.5              | 0          | 4                      |
| コード探索役           | 44   | 1.9          | 3.4              | 0          | 0                      |
| 全1,238回の実行        |      | 4.0          | 11.8             | 72（5.8%） | 98（7.9%）             |

テストを書き、実行し、コードを直し、また実行するコーディングエージェントは、ファイルを読むだけのエージェントより多くの時間と呼び出しを必要とします。制限が1つだと、コーダーは5回に1回打ち切られ、探索役は通常の6倍の長さ固まっていても、誰も気づきません。私が作るパネルは、種類ごとの90パーセンタイルを表示し、全体の数字ではなく、その種類自身の値を超えた実行中のエージェントに印を付けます。止める前に、ログに残った最後の動作を読みます。長いテスト実行の15分目にいるエージェントは作業中で、最後の動作が10分前のエージェントは固まっています。

## 1回の実行はトークンでいくらかかる？

中央値の実行は125,828トークン、90パーセンタイルは211,884トークンでした。エージェントが読んだものと書いたものをすべて数えています。探索役は低め（中央値86,389）、汎用エージェントは高め（141,495）でした。価格は変わるのが速すぎて載せられないので、ダッシュボードは実行とモデルごとのトークンを保存し、コストを描くときに最新の価格表を当てるべきです。同じ仕事がモデルごとにいくらかかるかは、[AIエージェントの費用](https://madsalt.tech/ja/blog/how-much-does-an-ai-agent-cost/)にあります。

1,775回の起動のうち、883回は中位モデル、827回は最大のモデル、33回は最新の最上位モデル、32回はその他でした。エージェントの54%にはファイルの変更が許可されていました。

## 完了した実行は本当に成功した？

報告のあった1,238回の実行のうち、1,172回が完了し、64回が失敗し、2回が停止されました。この94.7%が示すのはエージェントが終わったことで、作業が正しいことではありません。私の環境では、コードの変更はすべて、差し戻せるセキュリティレビュー役とコードレビュー役を通りますが、実行のステータスにはそれが一切現れません。ダッシュボードが示せるのは、実行が終わったことです。結果が正しいかどうかには、もう1つのエージェントか、テストか、人が要ります。

## そのためのツールは？

顧客と話すエージェントが動く本番アプリには、Langfuse、LangSmith、Datadog、Grafanaのエージェントビューのようなホスト型のトレーシングツールが、レイテンシ、トークン、トレースをカバーし、出力を採点できるものもあります。1台のマシンで複数のコーディングエージェントを動かす場合は、エージェントのフックイベントをローカルのデータベースに読み込むオープンソースのダッシュボードがあります。私の数字は、環境がもともと書き出すログから取りました。起動1回につき1行の起動台帳と、セッションのトランスクリプトです。1人の開発者にはそれで足り、その2つのファイルに対するスクリプト1本で、ここにあるすべての表ができました。

エージェントマップ、ワークフロービルダー、コストチャートを備えた完全なオーケストレーションの画面がどうなり得るかは、プロトタイプの[マルチエージェント管制ダッシュボード](https://madsalt.tech/ja/work/multi-agent-orchestration/)にあります。

**制限。** 開発者1人、環境1つ、30日間。「ガードルールに拒否」はエラーのテキストから判定しているため、一部のエラーは反対側に数えられている可能性があります。所要時間とツール呼び出し数は、バックグラウンドで動いて報告したエージェントのものです。フォアグラウンドで動いたエージェントは所要時間の表に入っていません。失敗はエージェントの種類に確実には割り当てられなかったため、合計としてのみ示しています。

本番でエージェントを動かしていますか？

何を計測するか、情報交換できれば嬉しいです。売り込みはありません。

[お問い合わせ](https://madsalt.tech/ja/#contact)