LoongSuite-PilotとSLSでAIコーディング利用を組織単位に測る

Alibaba Cloudは、LoongSuite-PilotとAlibaba Cloud SLSを使い、Claude Code、Copilot、Cursor、QoderなどのAIコーディング利用をイベント単位で収集し、組織能力として分析する実装を紹介しました。

要点

• コード行数やPR数ではなく、誰がどのエージェント、モデル、ツール、スキルを使い、何トークン消費したかをイベント単位で収集します。
• 利用イベントと人事・組織のディメンションを分け、部署変更後も分析軸を更新できる設計です。
• SLS上の共通CTEで30以上のグラフの定義を揃え、部署、個人、スキル、リポジトリ、利用集中度へ段階的に掘り下げます。
• 利用量は成果そのものではないため、品質、手戻り、納期、業務成果と別に結び付ける必要があります。

今回のブログ記事で語られていること

記事は、個人がAIで速くコードを書けても、組織の生産性や利益へ自動的に転換されるわけではないという問題から始まります。新規開発とレガシーコードでは効果が異なり、導入初期には学習や手順変更で一時的に生産性が下がることもあります。そこで、満足度アンケートとCI/CDの集約KPIの間に、AIコーディングエージェントの利用行動を追う測定層を置きます。LoongSuite-PilotはOpenTelemetryの生成AI向け意味規約を拡張し、利用者、セッション、エージェント、モデル、入力・出力トークン、ツール呼び出し、参照したSKILL.mdなどを個別イベントとしてSLSへ送ります。

データ設計では、利用イベントのファクトテーブルと、社員番号・氏名・部署階層を持つ人員ディメンションを分離します。これにより、過去イベントを書き換えずに最新の組織構造で集計でき、利用登録はあるがイベントがない人もLEFT JOINで検出できます。SLSダッシュボードでは共通CTEを使い、日・利用者・エージェント・提供者・モデルの粒度へ事前集約します。定義を一か所に置くことで、30を超えるグラフの「アクティブ利用者」や対象部署の条件が食い違うのを防ぎます。

分析は、全体の利用者数・トークン・セッションから始まり、エージェントやモデルの構成、時間推移、部署別の普及率、個人別利用へ進みます。さらにSKILL.mdのパスからスキル名を抽出し、呼び出し回数と利用者数で組織資産として定着した手法を探します。リポジトリ別のトークン量では投資が中核コードへ向いているかを見て、上位10%の利用者への集中度では、一部の先行者だけが使っている状態か、組織へ広がっているかを確認します。記事はSQLやJOINの注意点まで示しますが、測っているのは主に利用行動です。利用が多いことと、品質や事業成果が上がったことは分けて評価する必要があります。

背景にあるテーマ

AIコーディングの調達が部署単位へ広がると、ライセンス数だけでは普及、費用、再利用されるスキル、支援が必要な部署を判断できません。一方、詳細な個人ログは監視にもなり得るため、目的と利用範囲の合意が欠かせません。

今回のブログ記事が関係する人

開発生産性チーム、エンジニアリング責任者、AIコーディングの調達担当、FinOps、SRE、従業員データのガバナンス担当に関係します。

どう読むと価値があるか

そのまま同じダッシュボードを作るより、利用イベントと組織情報を分離する点、指標定義を共通化する点、利用集中を確認する点を設計例として読むと有用です。個人評価への短絡は避ける必要があります。

実務へのつながり

収集前に、必要な項目、保存期間、閲覧者、個人への説明、評価利用の可否を決めます。利用量に加えて、レビュー時間、欠陥率、リードタイム、再作業などをチーム単位で結び付けると、導入効果を誤読しにくくなります。

結局、今回のブログ記事をどう読むべきか

AIコーディングを個人の感想から組織的な観測へ移す具体例です。可視化の細かさを成果と混同せず、プライバシーと品質指標を同時に設計することが要点です。