複数のAIコーディングエージェント（Claude Code、Codex、Cursorなど、コードを自律的に書き進めるツール群）を並行稼働させる開発現場が増えています。10個のターミナルを行き来して「どのエージェントが止まっているか」「どのリポジトリでテストが落ちているか」を目視確認する運用は、人数が増えるほど破綻します。
この記事は、複数リポジトリ・複数エージェントを並行運用していて、可視性の欠如に困っている開発者やSRE（サイト信頼性エンジニア、システムの可用性を維持する役割）に向けた内容です。AIエージェントの稼働監視をどの方式で構築するか、判断材料を整理しました。
なぜ「エージェント監視」という新しい運用課題が生まれたのか
従来の監視対象はサーバーやコンテナでした。CPU使用率やHTTPレスポンスタイムを見ていれば異常の兆候はつかめます。
ところがAIコーディングエージェントは「プロセスは生きているが仕事が止まっている」状態を作ります。入力待ちのまま数時間放置されているセッションは、プロセス監視ツールの iotop や top では検知できません。エージェントが参照しているセッションファイルやSQLiteの状態を読まないと、停滞に気づけない構造です。
オープンソースプロジェクト「Nabi Station」は、この課題に対してローカルデーモン（常駐プロセス）がClaude Codeのセッションファイル、Codexの読み取り専用SQLite状態、Cursorのトランスクリプトをメタデータだけ解析し、都市の建物として可視化する構成を取っています。重要なのは、ソースコードやメッセージ本文、.envファイルは一切開かず、ツール名・パス・ターン状態・タイムスタンプだけを読む点です。
この設計思想は、クラウド移行の現場で監視基盤を選ぶときの判断とよく似ています。何を収集するか、どこで処理するか、誰がデータに触れるかという3つの軸は、サーバー監視でもエージェント監視でも共通の論点だからです。
判断軸1: データ主権とコンプライアンス要件
ソースコードやターミナル活動、リポジトリのメタデータは機微情報です。特に受託開発やクライアントワークでは、第三者のAIサービスにコードを送信すること自体が契約違反になるケースがあります。
Nabi Stationがローカル実行のGemma（Googleのオープンウェイトモデル、重みが公開されているため自前のマシンで動かせる）をOllama経由で動かしているのは、この制約への対応です。デフォルトモデルは gemma4:12b で、分析結果は外部に送信されません。
クラウドの監視SaaS（Datadog、New Relicなど）を使う場合は、収集したログやトレースがベンダーのクラウドに蓄積されます。金融・医療・官公庁系のプロジェクトでNDA（秘密保持契約）が厳しい場合、この時点でSaaS型は選択肢から外れることがあります。
判断軸2: 運用コストと人的工数のバランス
ローカル実行型は月額課金が発生しない代わりに、GPUリソースとモデル運用の工数がかかります。gemma4:12b クラスのモデルをまともな速度で動かすには、相応のVRAMを積んだマシンが必要です。
SaaS型監視は初期構築が速く、ダッシュボードもすぐに使えます。ただしエージェント単位・リポジトリ単位の粒度でカスタムメトリクスを定義する設定工数は別途かかります。Datadogであればカスタムメトリクスの送信数に応じて課金が増える仕組みもあるため、エージェントを10個、20個と増やしたときのコスト試算は事前に確認しておく必要があります。
判断軸3: 検知したい異常の種類
監視で検知したい異常が「プロセス停止」なのか「意味的な停滞」なのかで、必要な仕組みが変わります。
プロセス停止やリソース枯渇であれば、従来型のインフラ監視（Prometheus + Grafanaなど）で十分に検知できます。一方、「エージェントは動いているが人間の入力待ちで3時間止まっている」「テストは通っているがドキュメントが更新されていない」といった意味的な停滞は、セッションの中身を解釈する層が必要です。
Nabi Stationの設計では、約20項目のチェックでリポジトリの成熟度（空のプロジェクトからプロダクション品質まで)を機械的に判定し、その判定結果だけをGemmaに渡して推奨アクションの文章を生成させています。判定ロジック自体はAIに任せず、決定論的なルールベースで行っている点がポイントです。AIに事実判断と文章生成の両方を任せると、ハルシネーション（事実と異なる内容を生成する現象）のリスクが監視結果の信頼性を損ないます。
判断軸4: 障害対応時の根本原因分析のしやすさ
障害が起きたときに「いつから」「どのエージェントが」「何をしていたか」を遡れるかどうかも重要な軸です。
SaaS型はログの長期保存・検索UIが整備されているため、インシデント発生から数日後でも時系列を追いやすい利点があります。ローカル型は保存期間やストレージ容量を自分で設計する必要があり、ログローテーションの設定を怠ると肝心の記録が消えていることがあります。
| 観点 | ローカル実行型(Ollama+Gemma等) | SaaS型監視(Datadog等) |
|---|---|---|
| データ送信先 | 自マシン内で完結 | ベンダークラウドに送信 |
| 初期構築コスト | GPU確保・環境構築が必要 | 比較的低い |
| ランニングコスト | 電力・ハードウェア償却 | メトリクス数に応じた従量課金 |
| 長期ログ保存 | 自前で設計が必要 | 標準機能として提供 |
ケース別の推奨
受託開発でクライアントのコードを扱い、NDAでAIサービスへの送信が禁止されている条件なら、ローカル実行型を選ぶべきです。Nabi Stationのように読み取り専用でセッションファイルを解析し、ローカルLLMで要約する構成が適しています。
社内の自社プロダクト開発で、すでにDatadogやNew Relicを他のインフラ監視に使っている条件なら、既存SaaSにカスタムダッシュボードを追加する方が運用の一元化という点で合理的です。監視基盤を二重化すると障害対応時にどちらを見るか迷う時間が増えます。
エージェントの台数が3〜5個程度で、個人や小規模チームが使う条件なら、まずはNabi Stationのようなオープンソースのローカルツールをデモモード（?demo パラメータ）で試し、実運用に乗せるかを判断する進め方が現実的です。
あえて見送るべき条件
エージェントを1〜2個しか並行稼働させていない場合、専用の可視化基盤を構築するコストは見合いません。ターミナルを並べて目視確認する運用で十分なケースです。
またGPUリソースを確保できないチームがローカルLLM型を無理に導入すると、推論速度が遅く、かえって状況把握が遅れる逆効果になります。gemma4:12b のようなモデルはCPUのみでの実行では実用速度が出ないため、専用GPUの有無を事前に確認してください。
社内にNode.js 22.13以上やpnpmのような特定のランタイム・パッケージマネージャーを導入する運用ルールがない組織では、ツールの依存関係を維持する保守コストが見落とされがちです。導入前に運用チームの誰が保守を引き継ぐかを決めておく必要があります。
まとめ
AIエージェントの稼働監視は、従来のサーバー監視とは検知したい異常の性質が異なります。プロセス生存ではなく「意味的な停滞」を捉える設計が必要です。
判断の起点は、扱うコードの機密性、GPUリソースの有無、既存監視基盤との統合コストの3点です。NDAや契約上の制約があるならローカル実行型、既存SaaSと一元管理したいならSaaS拡張が候補になります。
まず試すなら、Nabi StationをNode.js 22.13以上とpnpm 9.9.0の環境で pnpm install && pnpm dev し、?demo 付きURLでデモ都市を眺めてみてください。実際のリポジトリに向けて動かす前に、どのデータが読み取られどのデータが読まれないのか、daemon側のコードで確認しておくと安心です。