dev-ai-coding-metrics

AI コーディング指標

成果を見栄えだけの指標や単一の総合スコアにまとめることなく、コーディングアシスタントとコーディングエージェントを測定します。

重要な違いはモードです。アシスタントはインラインまたはチャットで支援しますが、エージェントは複数ステップの作業を実行するため、タスク単位での測定が必要です。同じものとして扱って測定してはいけません。

このスキルを使う場面

きっかけ	例
パイロットや展開の評価指標を設計する	「200 人のエンジニアに Copilot を展開します。何を測定すればよいですか？」
利用率は上がっているのに成果が横ばいの状況を診断する	「シートの利用率は 80% ですが、PR の処理量は変わっていません」
アシスタントとエージェントのワークフローを比較する	「これらは別々に計測すべきですか？」
ROI モデルや経営陣向けレポートを作成する	「財務部門が第 3 四半期までに更新の判断を求めています」
ベンダーのベンチマークより優れた実験を設計する	「ベンダーの数値は信用できません。独自の調査を行うにはどうすればよいですか？」

デフォルト

ルール	理由
利用可能なテレメトリではなく、意思決定から始める	計測しやすいものだけを測る偏りを防ぎます
アシスタントとエージェントのファネルを分ける	混ぜると、どのワークフローが成果を生み出しているのか分からなくなります
すべての速度指標に品質と体験を組み合わせる	速度だけでは誤解を招きます
チームレベルで集計する	個人向けダッシュボードは監視につながります。個人データに関するポリシーを参照してください
ベンチマークは能力を示すシグナルとして扱い、ビジネス KPI としない	ベンチマークの差が、本番環境での差を意味するわけではありません

ワークフロー

1. 意思決定の内容を定義します。
2. プログラムのモードを選びます。アシスタント、エージェント、または混合です。
3. 必要最小限の評価指標を作成します。
4. 調査の設計を選びます。
5. 成果物を 1 つ作成します。

クイックリファレンス

意思決定から成果物への対応：

意思決定	デフォルトの成果物
ツールの購入、更新、または削減	ROI モデルと経営陣向けレポート
導入を促進する	導入指標とアンケート
デリバリーへの影響を証明する	生産性指標と実験計画
品質の変化を確認する	品質指標とダッシュボード
信頼や摩擦を把握する	開発者体験指標とアンケート
コーディングエージェントを評価する	エージェント実行指標と実験計画

プログラムモード

モード	分析単位	主な重点
アシスタント	開発者日、チーム週、リポジトリ月	導入、デリバリー、品質、体験
エージェント	タスク、PR、ワークフローの実行	タスク成功、マージ、リバート、レビュー負荷、受け入れられた変更あたりのコスト
混合	チーム週とタスク単位のサンプル	結果を組み合わせる前に、2 つのファネルを分ける

指標の分類

意思決定に答えられる最小限の評価指標を使用します。

分類	分かること
導入	実際の利用が継続しているか
デリバリー	AI が実際に関与する箇所で、ソフトウェアのフローが速くなっているか
品質	速度の向上が、欠陥、手戻り、レビュー負荷、または拡張機能の堅牢性の低下によって相殺されていないか
経済性	ツールと運用のコストに見合う価値があるか
体験	開発者がツールを信頼し、使い続けたいと思っているか
エージェント実行	自律型ワークフローが、デモだけでなく本番環境でも成功しているか

研究設計のデフォルト

計画上のデフォルト：介入前のデータを8週間分用意します。これはローカルな計画上の最低ラインであり、研究に基づく十分性の基準ではありません。因果関係を検証するパイロットを始める前に、ベースライン固有の週ごとの分散とチーム週数から、最小検出可能効果（MDE）を算出してください。そのMDEが、実際に行動に移す可能性のある効果より大きい場合は、因果関係を検証する調査を実施せず、方向性を示すものと明記した記述的なスコアカードを報告してください。

状況	設計
新規パイロットで、対照群がない	導入していないチームまたは導入が遅いチームとの間で差分の差分法を用いるか、介入前の時点が8点以上ある中断時系列を用います。単純な介入前後の差分は、凍結、組織再編、採用の波を取り込むため、方向性を示すにとどまります。チームごとに導入時期が異なる場合、通常の二方向固定効果DiDにはバイアスが生じます。段階的導入に対応した推定量を使い、平坦な事前トレンドを証拠と見なす前に、事前トレンドを検出する検出力を確認してください（因果推論の基礎）
比較可能なチームが十分にある	マッチングしたA/Bテスト、または層別割り当て
チームがツールの恒久的な利用禁止に抵抗する	クロスオーバー設計
1つのタスク群におけるエージェントのワークフロー変更	タスク単位のシャドー比較、またはレビュアーに条件を知らせない評価
リーダーシップが迅速な回答を求めている	因果関係を主張せず、明示的な注意事項を添えたバランススコアカード

コホートと分母に関する合意事項

結果を確認する前に、測定対象集団を固定してください。各指標について、対象となる集団、割り当てルール、実際の曝露、観察期間、採用する結果を記録します。eligible、assigned、exposed、observedの件数を並べて報告し、割り当てられたコホートをアクティブユーザー、完了したタスク、またはマージ済みPRに黙って置き換えないでください。生存者だけを分母にすると、セットアップの失敗、放棄されたエージェントの実行、未マージの変更が問題である場合にこそ、導入率と成功率が実態より高く見えます。

観察が不完全な場合は、理由（not_started、abandoned、still_open、telemetry_missing、excluded_by_rule）を明記し、ファネルに含めてください。まだオープンの作業は、結果観察期間が終了するまでは失敗ではなく右側打ち切りとして扱います。テレメトリに不備がある場合でも、報告を方向性を示すものとして提示できますが、各割合の根拠となる分母と、欠損ケースが意思決定にどう影響し得るかを明記する必要があります。

GitHubのPRをエクスポートする際は、作成日が対象期間内のコホートに、オープン、クローズ済み・未マージ、マージ済みの結果をすべて残してください。PRのエクスポートだけでは、PRを生み出さなかった割り当て済みタスクを把握できません。エージェントの成功を報告する前に、タスクレジストリと結合してください。作成者単位のCSVは、個人データポリシーに基づく制限対象のソースデータとして扱います。

測定チェックリスト

AIコーディングに関するレポートを公開する前に使用してください。

• ベースラインを確立した（介入前に8週間以上）
• アシスタントとエージェントのファネルを分けて追跡している
• すべての速度指標に、少なくとも1つの品質指標を組み合わせている
• サンプルサイズ、信頼水準、研究設計を明記している
• 交絡要因（チームの変更、リリース圧力、ポリシー変更）を記録している
• ベンダーの証拠をベンダーの証拠と明記している
• 安定化後に使用状況を測定している（1週目の目新しさの期間ではない）
• ROIモデルにレビュー負荷と手戻りのコストを含めている
• 編集可能なエージェントを、仕様が変化する各チェックポイントで測定し、後半のチェックポイントにおけるコストと品質の傾きを含めている
• チームレベルで集計している（マネージャーが個人を確認できるダッシュボードは使用しない）

エビデンスのルール

研究から導かれた、長期的に適用できるルールです。日付付きの研究、数値、注意事項はreferences/evidence-update.mdに記載しています。

• AIは既存のシステムの強みと弱みを増幅します。あらゆる状況で効果を高めるものではありません。
• 主観的に感じられる改善と測定された改善は異なる場合があります。自己申告による改善を、測定された効果として報告しないでください。
• スループットの向上によって、レビューやインシデントに負荷が移る可能性があります。スループットの向上を示す際は、レビュー負荷とインシデントの指標も併せてください。

不正対策チェックリスト

次のいずれかに該当するスコアカードまたはレポートは却下してください。

• 使用状況、速度、満足度、品質を混ぜた単一の総合的な AI 生産性スコア
• 席のアクティベーション数やプロンプト量を、成果への影響として挙げている
• 技術スタック、タスク構成、人員配置、リリースのプレッシャーを考慮せずにチーム間を比較している
• 測定期間が 8 週間未満、または第 1 週の新規性による影響期間を含んでいる
• ベンダーのベンチマークを、本番環境での ROI の根拠として挙げている
• ROI モデルからレビューの負担が除外されている
• マネージャーが個人単位の AI 使用状況を確認できる
• 統制された設計なしに、前後の傾向を因果関係があるものとして示している
• SlopCodeBench の平均値や推移のシグナルを、組織の目標または因果的な ROI の根拠として使用している

個人データポリシー

これは個人単位のデータに関する唯一のポリシーであり、このページを参照する dev-contribution-quality-analysis と共有されています。

• デフォルトではチーム単位です。AI の使用状況と AI 支援の指標は、個人ごとにマネージャーに表示されることはなく、人事評価、昇進、人員配置の判断に使用されることもありません。
• 個人単位の出力は、本人がオプトインした自己レビューまたはコーチングに限り許可されます。まず本人に提示し、サンプリングした根拠と訂正の手段を併せて示します。
• 個人に関する質問（「AI をうまく使っているのは誰か」「エンジニアごとの品質」）は、これらの制限のもとで dev-contribution-quality-analysis に振り分けます。AI ツールがチームに与える影響の評価は、このページで扱います。

ナビゲーション

リファレンス

• references/adoption-metrics.md — アシスタントとエージェントの導入ファネル、指標の定義、停滞パターン、プライバシールール
• references/productivity-metrics.md — AI ワークフローに適用した DORA と SPACE、デリバリースタックの分解、交絡要因の管理
• references/quality-metrics.md — 目標値とアラートしきい値を含む、欠陥、複雑性、テスト、セキュリティ、技術的負債の指標
• references/roi-framework.md — 全コストモデル（レビュー負担を含む）、便益モデル、シナリオ計画、経営陣向けレポートの構成
• references/developer-experience-metrics.md — 満足度調査、認知負荷、摩擦の指標、信頼の較正、DX のアンチパターン
• references/agent-execution-metrics.md — エージェントのファネル、主要指標、レビュアーの負担、パイロット／拡大／経営判断のためのスコアカード
• references/benchmarking-methodology.md — A/B、導入前後、クロスオーバー、シャドー設計、統計的厳密性、交絡要因の管理
• references/theory-of-constraints-applied.md — 計測前のボトルネック特定、ROI のためのスループット会計、レビューチューの保護に向けた DBR、展開停滞に向けた CRT、導入と品質の緊張関係を解消するための蒸発する雲
• references/evidence-update.md — 注意書き付きの日付入り引用：METR RCT（2025）、METR 2026 update（選択バイアスに関する注意）、DORA 2025 AI report、DORA 2026 ROI report、DX Core 4、Faros 2026 telemetry、SlopCodeBench

アセットとデータ

• assets/metric-dashboard-template.md
• assets/adoption-survey-template.md
• assets/roi-calculator-template.md
• assets/executive-report-template.md
• assets/experiment-design-template.md
• data/sources.json
• data/sample-ai-metrics.json

スクリプト

• scripts/roi_calculator.py — キャパシティ価値のシナリオを計算する場合は、観測期間と、実測した両方の負担項目を指定してください。コストがゼロの場合、ROI は定義できません。ファミリーごとの評価範囲は説明用のローカル基準であり、検証済みの構成概念ではありません。
• scripts/extract_github_events.py — PR の結果コホートまたはコミットのテレメトリーを収集する場合に使用します。ライブエクスポートの前に、GitHub エンドポイントの権限とレート制限に関するガイダンスを確認してください。
• scripts/README.md

相互参照

• ../dev-contribution-quality-analysis/SKILL.md — コミットと PR の履歴に基づく個人またはチームの貢献品質。Individual-Data Policy に準拠します
• ../dev-context-engineering/SKILL.md
• ../ai-agents/SKILL.md
• ../qa-observability/SKILL.md
• ../product-management/SKILL.md

学びのループ

過去の判断や落とし穴が関係する場合は、learnings.consolidated.md があれば参照してください。必要な履歴を確認するとき、または利用可能な代替手段としてのみ learnings.md を使用します。それ以外の場合は、どちらも参照しません。

適用後、記録しておく価値のあるパターン、未然に防ぐべきミス、または意外だった分野の事実に遭遇した場合は、agents-skills-feedback-loop/scripts/append_learning.py を使って、日付入りの箇条書きを learnings.md に1つ追記してください。SKILL.md 自体は変更しないでください。