TL;DR
私が開発に使っているエージェント環境から、30日分のログを取り出しました。ツール呼び出しは127,610回、完了したエージェントの実行は1,238回です。監視ダッシュボードに何を表示すべきかは、3つの事実で決まりました。ツールエラーの59%は、何かが壊れたのではなく、私自身のガードルールが何かを拒否したものでした。だからエラーには2つのカウンターが要ります。すべてのエージェントに同じ制限時間を課すのは間違いです。テスト先行のコーディングエージェントの21%は12分を超えましたが、コード探索役は0%でした。そして、エージェント起動の5回に1回は、開始前に拒否されており、「1日あたりの実行数」のグラフにはこれが一切現れません。
私はDenys、フルスタックかつAIエンジニアです。1つのリードのコーディングセッションが、専門のエージェントに仕事を渡す形で開発しています。探索役、プランナー、テスト先行のコーダー、セキュリティとコードのレビュー役です。3,315回のエージェント実行で壊れたものでは失敗を数えました。この記事で問うのは別のこと、ダッシュボードに何を載せるべきか、です。
データ。 私自身の環境のセッションログと起動台帳、2026年9月24日から10月23日まで。以下の数字はすべて、1つのスクリプトでそこから算出しました。クライアント名とプロジェクト名は、使ったデータに含まれていません。1人分の作業量であり、ベンチマークではありません。
AIエージェント監視ダッシュボードには何を表示すべき？
Grafanaのエージェントオブザーバビリティのドキュメントのようなベンダーのガイドは、レイテンシ、トークン、コスト、エラーを中心に据えています。私のログが示すのは、この4つは必要だが十分ではないということです。パネルは5つです。
- 起動：開始、拒否、完了、失敗を日ごとに。
- エラーを「ルールに拒否された」と「壊れた」に分けて、ツールごとに。
- エージェントの種類ごとの所要時間とツール呼び出し数を、中央値と90パーセンタイルで、種類ごとの制限付きで。
- 実行あたりのトークン。これがコストです。
- 現在実行中のものを、各実行の経過時間と、その種類の通常範囲とを並べて。
この記事の残りは、それぞれの裏付けとなる数字です。
開始すらされないエージェント起動はどのくらい？
| 起動、30日間 | 件数 |
|---|---|
| 起動の試行 | 1,775 |
| 開始前に拒否 | 352（19.8%） |
| 最も多かった日 | 258回の起動 |
| 中央値の日 | 40回の起動 |
私の環境は、起動のたびに確認します。指示書がエージェントの変更してよいファイルを挙げているか、実行中の別のエージェントがすでにそのファイルを押さえていないか、リスクのある工程にどのモデルが必要か。5回に1回の起動は通りませんでした。実行数のグラフは開始した起動だけを数えるので、これらはすべて隠れます。
ツールエラーになぜ2つのカウンターが要る？
127,610回のツール呼び出しのうち、6,691回がエラーで返りました。1,000回あたり52回です。次に、エラーの内容で分けました。
| ツール | 呼び出し | エラー | うち、ガードルールに拒否 |
|---|---|---|---|
| シェル | 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回のツール呼び出しで止めていますが、ログを見ると種類ごとの違いがよく分かります。
| エージェントの種類 | 実行 | 中央値（分） | 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エージェントの費用にあります。
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本で、ここにあるすべての表ができました。
エージェントマップ、ワークフロービルダー、コストチャートを備えた完全なオーケストレーションの画面がどうなり得るかは、プロトタイプのマルチエージェント管制ダッシュボードにあります。
制限。 開発者1人、環境1つ、30日間。「ガードルールに拒否」はエラーのテキストから判定しているため、一部のエラーは反対側に数えられている可能性があります。所要時間とツール呼び出し数は、バックグラウンドで動いて報告したエージェントのものです。フォアグラウンドで動いたエージェントは所要時間の表に入っていません。失敗はエージェントの種類に確実には割り当てられなかったため、合計としてのみ示しています。