株式会社renue
案件モニタリングAI
案件モニタリングAIで、この記事のテーマを実務に落とし込めます
renueが社内で運用しているシステムをサービス化したものです。何ができるか、どう動くかをサービスページでご覧ください。
AIエージェント利用モニタリングとは？全社導入後に「放置」してはいけない理由
Claude CodeやCopilot、CursorなどのAIコーディングエージェントを全社導入すると、利用状況を把握する仕組みが必要になります。しかし、導入はゴールではなくスタートです。「ライセンスは配布したが、誰がどれだけ使っているかわからない」「一部のパワーユーザーだけが活用し、大半の社員はほぼ未利用」という状況を防ぐには、導入後の継続的な確認が欠かせません。
AIエージェントの利用モニタリングとは、組織全体のAIエージェント利用状況をセッション単位で計測・可視化し、利用パターンの分析からアクション（コーチング・Skill標準化・セキュリティ対策）を導出するプロセスです。利用量だけでなく、作業の結果や手戻り、コストも継続して観測し、導入後の改善に結び付けます。
本記事では、AIコーディングエージェントの全社利用モニタリングについて、計測すべき指標・ダッシュボード設計・利用パターン分析・リスク検出・改善アクション導出までを、実践知見に基づいて解説します。
モニタリングで計測すべき5つの指標カテゴリ
1. 利用量指標（Adoption Metrics）
最も基本的な指標として、以下を日次・週次で計測します。
- アクティブデバイス数 / 全デバイス数：ライセンス稼働率を把握。稼働していない端末やライセンスの有無を把握できます
- セッション数（週次）：個人別・チーム別のセッション数推移。全社展開が進むと週に数千セッション規模に達することもある
- メッセージ数：セッション内でのAIとのやり取り回数。月に膨大なメッセージをやり取りするヘビーユーザーがいれば、そのユーザーの使い方を全社に展開する価値がある
- モデル別利用比率：Claude Opus、Codex、Cursor等のモデル・ツール別利用割合を把握し、ライセンスコスト最適化に活用
2. 効率性指標（Efficiency Metrics）
「たくさん使っている」だけでは、AIを効果的に活用しているとは限りません。効率性を測る指標が重要です。
- user_to_assistant_ratio：ユーザー発言数をAI発言数で割った比率です。集計条件をそろえ、作業の種類・成果・手戻りと併せて使います。特定の比率だけで理想的な利用や指示過多とは判定しません。
- セッションあたり平均時間：極端に短いセッション（30秒以下）が頻発する場合、前のセッションでの修正漏れを追加修正している可能性がある
- コード受入率（Accept Rate）：AIが提案したコードのうち、実際に採用された割合
3. 品質指標（Quality Metrics）
- PR作成数・マージ率：AIを活用して作成されたPRが実際にマージされているかを追跡
- CIパス率：AI生成コードのCI通過率を監視。低下傾向があれば失敗原因を調べ、コード・実行環境・テスト自体に加え、プロンプトやCLAUDE.mdの指示も確認
- Skill利用率：カスタムSkillの利用頻度。利用の多さだけで自動化の成功とは判断せず、成功率・手戻り・削減できた工数と併せて評価
4. セキュリティ指標（Security Metrics）
- セキュリティアラート件数：.envファイルへのアクセス、機密情報の露出リスクを検出
- デプロイに関する確認：許可された環境・実行条件を明確にし、意図しない環境へのデプロイを防げているか確認します。
- トークン平文露出：SlackトークンやAPIキーがプロンプトに平文で貼り付けられるケースの検出
5. コスト指標（Cost Metrics）
- トークン消費量（入力/出力別）：OpenTelemetry経由でトークン使用量を計測し、API費用を可視化
- キャッシュ効率：プロンプトキャッシュのヒット率を監視。キャッシュ効率が低い場合、同じ情報を繰り返し送信している可能性がある
- 1PRあたりコスト：AIコストをPR単位で割った生産性指標
ダッシュボード設計：3層アーキテクチャ
第1層：データ収集（Telemetry Layer）
AIエージェントの利用データを収集する方法は、主に3つあります。
| 方式 | メリット | デメリット | 代表ツール |
|---|---|---|---|
| 公式Analytics API | データの正確性が高い、セットアップが容易 | 契約・APIごとに対象と鮮度が異なる。Codeは日次集計・最大約1時間遅延、Enterpriseの利用状況は通常翌日 | Claude Code Analytics API / Claude Enterprise Analytics API |
| OpenTelemetry統合 | カスタム指標の追加が自由、リアルタイム性が高い | 初期構築コストが高い | claude-code-otel、Grafana |
| セッションログ解析 | 最も詳細な分析が可能、利用パターンの深堀りに最適 | 解析基盤の構築が必要 | 独自実装 |
2026年9月17日時点で、Claude Code Analytics APIはClaude Platformの組織向けで、Admin APIにアクセスする権限が必要です。個人アカウントでは利用できず、日次集計の指標を最大約1時間の遅延で取得します。一方、Claude Enterprise Analytics APIはEnterprise組織向けで、claude.aiの主所有者が発行するAnalytics APIキーを使います。利用状況は通常、対象日の翌日17時UTC頃から取得でき、コスト・使用量は通常4時間以内、最大24時間程度の遅延があります。更新済み時刻・取得可能日と対象指標を確認し、両APIのキーや鮮度を混同しないでください。（出典：Analytics APIの対象・キー・更新頻度、Claude Code Analytics API仕様）
第2層：可視化（Visualization Layer）
収集したデータを、以下の3つのビューで可視化します。
（1）組織全体ビュー
- 週次セッション数の推移グラフ
- アクティブ/非アクティブユーザーの割合
- エージェント別（Claude Code / Codex / Cursor）利用分布
- モデル別（Opus / Sonnet / Haiku）利用比率
（2）個人別ビュー
- 利用時は機密性・安全性・プライバシーを個別に確認してください。
- user_to_assistant_ratio分布
- 主要ツール/Skill利用状況
- セキュリティアラート件数
（3）リスクビュー
- 未利用者リスト（要フォロー対象）
- セキュリティアラートの集計・分類
- デプロイ事故のタイムライン
- トークン/APIキー露出アラート
第3層：アクション導出（Action Layer）
ダッシュボードの最終目的は「見る」ことではなく「改善アクションを導出する」ことです。具体的なアクション例を後述します。
セッション分析で確認する5つの行動パターン
以下は、AIエージェントの使い方を振り返るための一般的な行動パターンです。実在の利用者のセッションから抽出した分析結果や、個人の発言記録を紹介するものではありません。作業の種類と成果に照らして、適した進め方を検討します。
パターンA：計画→実装→レビュー→デプロイの一気通貫型
1セッション内で実装→ビルド→テスト環境デプロイ→動作確認→PR作成→CIレビュー対応まで完結させるパターンです。
手順を再利用できる形にする進め方です。CI指摘への対応やPR作成前の確認をSkillなどにまとめ、対象・完了条件・停止条件を定義して利用する方法を検討します。
全社展開ポイント：自分のワークフローをSkill化する。繰り返す作業手順（CIレビュー対応、PR作成チェック等）をSkillとして定義すると、次回からコマンド1つで自動化できます。
パターンB：AIの作業手順を観察→プロンプト改善のメタ最適化型
API経由のLLM呼び出しで期待通りの結果が出ないとき、同じ作業をClaude Codeに直接やらせて、表示される作業手順・ツールの使用・出力を観察し、再現できる手順をプロンプトに落とし込むパターンです。
指示と応答の回数だけで優劣を判定せず、タスクの完了条件、成果、手戻りを併せて確認します。作業項目と完了した内容を記録し、未完了のものと区別すると、長い作業でも進捗を追いやすくなります。
全社展開ポイント：Claude Codeを「プロンプトエンジニアリングの実験台」として使う。AIのツール実行と結果を確認し、APIプロンプトの改善に活かせます。観測できる行動や出力から分析する方法であり、内部推論の全体を読み取る方法ではありません。（出典：Claude Codeの処理ループとツール）
パターンC：事実ベースの深堀り調査型
AIの回答を確かめる指示の例として、「観測された挙動と再現条件を示して」「原因の仮説と検証結果を分けて説明して」と伝える方法があります。実際の利用者の発言引用ではありません。
環境変数が反映されない場合は、設定ファイルだけで原因を決めつけず、値の読込順序・実行環境・ライブラリの仕様を切り分けて確認します。設定を一つずつ変え、再現条件と期待する動作を比較するための一般的な調査手順です。
全社展開ポイント：AIの説明を結論だけで採用せず、原因の仮説、再現条件、公式資料や検証結果を確認します。理由を尋ねることと、原因を実証することを区別します。
パターンD：スクリーンショット活用の高速イテレーション型
UIの調整では、スクリーンショットと期待する状態を共有し、位置や色などの変更点を具体的に伝える進め方が考えられます。修正後の画面を確認し、意図と合っているかを確かめます。
全社展開ポイント：UI作業では、画像と文章で変更点を示し、修正の往復回数や確認にかかる時間を記録して、伝え方を改善します。
パターンE：複数エージェント並列実行型
Claude CodeやCodexなどを使い、依存しない作業を複数のエージェントへ分担する進め方が考えられます。担当範囲を分け、成果のレビューと統合を行います。特定のモデルが常に推論や実装に優れると一律には決めません。
全社展開ポイント：タスクの複雑度に応じてエージェントを使い分ける。推論系はOpus、実装系はCodexという使い分けを試し、独立した作業を並行して進めます。効果はエージェント数だけでは決まらないため、レビューと統合を含む総工数や品質で評価してください。
リスク検出：モニタリングで防ぐ3大セキュリティリスク
AIエージェントの利用モニタリングでは、生産性だけでなく、機密ファイルへのアクセスや意図しない操作などの一般的なセキュリティリスクも確認します。以下の3分類は確認観点の整理であり、実際の事故を報告するものではありません。
リスク1：機密情報の露出（.envファイルアクセス）
AIエージェントが.envファイルにアクセスし、APIキーやデータベース接続文字列などの機密情報がセッションログに記録されるリスクです。未対応のアラートが大量に蓄積してしまう場合もあります。
対策：CLAUDE.mdには.envファイルを扱わない指示を明記し、Skill/ワークフローにも確認を組み込みます。ただし、指示文だけではアクセス権は変わりません。Claude Codeのpermission設定や実行環境のアクセス制御で、機密ファイルを読める経路を制限し、許可したシェル等の経路も含めて検証します。（出典：指示文と実際の権限制御の違い）
リスク2：誤デプロイ
デプロイ先や実行条件が曖昧だと、意図しない環境へ操作するリスクがあります。実行前に対象環境と権限、承認の要否を確かめ、許可された範囲でのみ操作できるかを検証します。
対策：CLAUDE.mdにデプロイ先環境の制約を明記し、デプロイコマンド実行前の確認ステップをSkill化します。
リスク3：トークン・認証情報の平文貼り付け
SlackトークンやAPIキーをプロンプトに直接貼り付けてしまうケースです。セッションログに平文で記録され、情報漏洩のリスクがあります。
対策：トークン管理のベストプラクティス（環境変数経由での参照、シークレットマネージャーの活用）を全社ガイドラインとして整備し、セッションログのスキャンで平文トークンを自動検出する仕組みを構築します。
モニタリング結果から導出する改善アクション
ダッシュボードで現状を把握したら、具体的な改善アクションに落とし込みます。業務を自動化・効率化する際には、まず業務を完璧に理解して言語化することが前提です。モニタリングも同様に、「何を計測し、何を改善するか」を構造化してから取り組む必要があります。
即効性のあるアクション（1週間以内）
- 未利用者への導入サポート：セッション数0のユーザーを特定し、1on1のオンボーディングを実施。機材はあるがセッションが発生していない人には、初期セットアップの支援が有効
- 優秀Skillの全社テンプレ化：パワーユーザーが自作したSkill（CIレビュー自動修正、PR事前チェック等）を汎用化し、共有リポジトリに配置
- acceptEditsモードの推奨：承認待ち時間を減らすため、信頼できる作業での利用を検討。自動承認の対象は作業ディレクトリ等のファイル編集と一部のファイル操作で、全コマンドを無条件で許可するモードではありません。組織の権限設定に従って使用（出典：acceptEditsの対象範囲）
中期アクション（1ヶ月以内）
- Skill自作ガイドの整備：自分のワークフローをSkill化する方法をドキュメント化し、全社に展開
- スクリーンショット活用の啓蒙：UI作業でのビジュアルフィードバックの効果を共有し、活用を促進
- AIの回答を検証するチェックリスト：観測事実、原因の仮説、再現条件、検証結果を分けて確かめる手順を整理し、共通のガイドラインとして利用します。
長期アクション
- 複数エージェント並列パターンの標準化：タスクの複雑度に応じた使い分けパターンを全社ガイドラインに
- プロンプト品質のモニタリング：user_to_assistant_ratioをタスク内容・手戻り・成果と併せて確認し、改善点に応じて個別コーチング。比率だけで指示過多と判定しない
- MCP（Model Context Protocol）によるモード切替：日報作成、PMO業務、コーディングなど、業務に応じてMCPサーバーのON/OFFをSkillsで管理し、コンテキスト品質を向上
モニタリング基盤の構築ステップ
ステップ1：データ収集の設計
まず、どの指標をどのデータソースから取得するかを設計します。
| 指標カテゴリ | 推奨データソース | 更新頻度 |
|---|---|---|
| 利用量（セッション、メッセージ） | Claude Code Analytics API / Enterprise Analytics API（製品・指標ごとの対応を確認） | 日次バッチ。元データの取得可能日と更新時刻を確認 |
| コスト（トークン、キャッシュ） | OpenTelemetry + Grafana | リアルタイム |
| 品質（PR、CI） | GitHub API連携 | イベント駆動 |
| セキュリティ | セッションログスキャン | 日次バッチ |
| 利用パターン | 独自セッション解析基盤 | 週次 |
ステップ2：ダッシュボードの実装
Grafanaはダッシュボードの可視化先の一例です。公開コミュニティプロジェクトのColeMurray/claude-code-otelは、OpenTelemetry Collector、Prometheus、Loki、Grafanaを組み合わせた構成を公開しています。Claude Code公式のテレメトリには、入力・出力・キャッシュ関連トークン、推計コスト、コード変更量、アイドル時間を除くアクティブ時間等があります。キャッシュ効率はトークン種別から集計条件を定めて算出します。アクティブ時間をセッション開始から終了までの経過時間と混同せず、費用も確定請求額とは区別してください。OSSで表示する指標は、導入する版とダッシュボード設定の対応を確認します。（出典：ColeMurray/claude-code-otel、Claude Code公式テレメトリ指標）
ステップ3：アラートの設定
以下のアラートを設定します。
- コストアラート：日次/月次のトークン消費が閾値を超えた場合に通知
- セキュリティアラート：.envアクセス、トークン平文検出時に即時通知
- 利用率アラート：2週間以上セッションがないユーザーを週次でリスト化
ステップ4：定期レビューサイクルの確立
週次で利用状況レポートを生成し、月次で改善アクションのレビューを実施します。この際、AIの「6領域（渉外・戦略・分析・設計・開発・PMO）」の観点から、各メンバーがAIを活用してどの領域に守備範囲を広げているかを評価すると、組織全体のケイパビリティ向上が可視化できます。
コードレビューSkillに学ぶモニタリング品質基準
AIエージェントの利用品質をモニタリングする際、「何をもって品質が高いとするか」の基準が必要です。本記事では、コードレビューSkillの設計を、その基準を考えるための参考にします。
効果的なコードレビューSkillは、以下の3フェーズで構成されます。
- Phase 1：致命的な問題のチェック — ハードコード、エラー握りつぶし、フォールバック処理の排除
- Phase 2：アーキテクチャ・設計のチェック — SOLID原則、DRY原則、クリーンアーキテクチャの遵守
- Phase 3：パフォーマンス・セキュリティのチェック — N+1問題、SQL injection、タイムアウト処理の確認
このフェーズ構造を、利用モニタリングにも応用できます。
- Phase 1（セキュリティ）：.env露出、トークン平文、誤デプロイの検出
- Phase 2（効率性）：user_to_assistant_ratio、セッション時間、Skill活用率の分析
- Phase 3（ROI）：トークンコスト対PR産出量、コード受入率の評価
まとめ：AIエージェント利用モニタリングのチェックリスト
AIエージェントの全社導入後に使うチェックリストの例です。各段階の期間や利用率の目標は、対象業務・利用者・成果の評価条件を決めてから設定します。
| フェーズ | 項目 | 完了基準 |
|---|---|---|
| 導入初期 | アクティブユーザー率の計測 | 対象者・集計期間を定め、利用率と未利用理由を把握 |
| 導入初期 | 未利用者の特定・フォロー | 全未利用者にオンボーディング実施 |
| 安定期 | 利用パターン分析 | 5つのパターンに分類し、優秀パターンを特定 |
| 安定期 | セキュリティアラート対応 | 未対応のアラートをゼロに |
| 最適化期 | Skill標準化 | 対象業務に必要な共有Skillを整備し、利用・成果を確認 |
| 最適化期 | コスト最適化 | 1PRあたりコストの目標値を設定・達成 |
| 継続改善 | 月次レビューサイクル | 定期レビューで改善アクションを継続実行 |
AIエージェントは導入して終わりではありません。モニタリング→分析→アクション→改善のサイクルを回すことで、組織全体のAI活用レベルが継続的に向上します。まずは自社の利用状況を可視化することから始めてみてください。
あわせて読みたい
- 5Sとは｜整理・整頓・清掃・清潔・しつけの意味・目的・進め方を解説
- AIリードスコアリング実装ガイド【2026年版】— 4要素スコアリング×テリトリー管理×ステータス倍率の本番アーキテクチャ
- AIカスタマーサポート完全ガイド【2026年版】— RAG・チャットボット・有人連携の実装パターンとツール比較
関連記事
AI開発のご相談はrenueまで。
