はじめに
最初に断っておくと、この記事はClaude Code自体のROIや利用コストの話ではない。あなたのチームがどれだけ速く・安全に出荷できているかを測定・改善する話だ。
AIツールを使って開発速度が上がったはずなのに、なぜかリリースが不安定になった——そういう感覚を持っているEMは少なくない。Google 2024年のDORA報告でも、開発者の84%がAIツールを利用し全コードの41%をAIが生成する一方で、デリバリー安定性が7.2%低下したという数値が出ている。コード変動（チャーン）は2026年に倍増すると予測されている。
「速く作れているのになぜリリースが安定しないのか」——この問いへの答えを数値で出すために、DORAメトリクスとClaude Codeを組み合わせる方法を紹介する。
DORAの5指標とAI時代の新たな意味
DORAは2025年に5指標へ更新された。デプロイ頻度（Eliteは1日複数回）、リードタイム（Eliteは1時間以内）、変更失敗率（Eliteは0〜5%）、MTTR（Eliteは1時間以内）、そして2025年追加のリワーク率——本番パッチとして展開された予定外修正の割合だ。
「チームが速い/遅い」という感覚を数値化できるのがこの5指標だが、AI時代に特に重要になったのがリワーク率だ。AIが「速く作れる」ようになったことで、レビューを通過した後に問題が発覚する事例が増えている。速度が上がっているのに品質が下がるという逆説の正体は、ここにあることが多い。
Claude CodeでDORAボトルネックを特定する
エンジニアリングリードのHelio Medeirosは、git logからリードタイムとデプロイ頻度を抽出することで、主観的な評価から客観的な対話への移行を実践した。
このリポジトリのgit logを分析して、過去3ヶ月のDORA指標を算出して。
必要なデータ： 1. デプロイ頻度: productionブランチへのマージ頻度（週単位） 2. リードタイム: feature/fix/*ブランチのコミット作成〜mainマージまでの時間（中央値・p95） 3. PRのサイクルタイム: PR作成〜マージまでの時間（中央値）
以下の形式でレポートを作成して： - 現状値 vs Eliteベンチマーク（1日複数回/1時間以内） - ボトルネックがコーディング時間・レビュー待ち・CI待ちのどこにあるか - 改善優先度のトップ3
Medeirosはこう言っている。"DORA did not tell me whether my team was using AI. It told me whether AI was making our system better"——「DORAはチームがAIを使っているかどうかを教えてくれるのではない。AIが実際にシステムを良くしているかどうかを教えてくれる」。AIの導入有無ではなく、成果を数値で測ることの重要性を端的に表した言葉だ。
PRサイクルタイムの詳細分解にはこのプロンプトが使える。
過去90日間のPR履歴を分析して。
ボトルネックを以下で特定して： - PR作成〜最初のレビューコメントまでの時間 - レビューラウンド数（理想は2ラウンド以内） - レビュー待ちが最長になった時間帯・曜日 - サイズ別（small/medium/large）のサイクルタイム比較
改善施策を「効果大×実装コスト小」から優先順位付けして。
リワーク率の検出では、本番マージから72時間以内に「fix」「hotfix」「patch」「revert」がコミットメッセージに含まれるケースをリワークとして定義し、全デプロイに対する割合を算出させることができる。目安として10〜15%程度が参照されることがあり、これを大きく超えているようならAIによるコード生成のレビュー品質に問題がある可能性が高い。
AI支援コードレビューの効果にも注意が必要だ。arxivの独立調査ではPRサイクルタイムが31.8%削減された事例がある一方、METR研究では不適切な設定下で経験豊富な開発者が19%遅くなるケースも報告されている。この差（8%〜31.8%）は設定品質の違いによるものだ。「AI導入したら当然速くなる」という前提は危険で、計測しながら調整する姿勢が要る。
AI採用率をDORAと並行して追う
MergeScoutは2026年において、AI採用率（PRsのうちAI支援開発が使われた割合）をDORAを補完する重要指標として提唱している。チームのAI活用成熟度が生産性の先行指標になるという考え方だ。
AI採用率の計測では、GitHubのPRに「claude」「ai-generated」「co-authored-by」などのコメントが含まれる割合を集計したり、Claude Codeのセッションログを参照してアクティブユーザー数と利用頻度を把握したりする方法がある。
ここで注意すべきなのが「ミラーアンプリファイア効果」（Plandek, 2026年）だ。AIは既存のプロセスを増幅する。チームにボトルネックがあれば、AIはその課題も拡大する。AI採用率が上がるほど、既存のボトルネックを先に特定・修正することが重要になる。
誤検知率が10%を超えるとエンジニアの信頼が失墜し、AIを使わなくなる逆効果が出るという報告もある。精度の低いまま強制採用しても数値は上がらない。
CLAUDE.md × SMART目標でチームの改善サイクルを回す
CLAUDE.mdにメトリクス警告ルールを定義しておくと、日常のコードレビューでClaudeが自動的にDORA劣化リスクを指摘するようになる。
# CLAUDE.md（メトリクス警告ルール）
<h2>Engineering Metrics Rules</h2> When reviewing code or PRs, flag: - PRサイズが500行以上: レビュータイム増加・リワーク率上昇リスク - 本番ブランチへの直接コミット: デプロイ頻度の正確な計測を阻害 - fix/hotfix/revert コミット: リワーク率のカウント対象になる可能性 - テストなしの本番コード変更: 変更失敗率上昇リスク
Helio Medeirosが実践するSMART目標の設定例として、デプロイ頻度を週2回→週5回（3ヶ月以内）、リードタイムの中央値を3日→1日以内（PRサイズ削減で対処）、AI採用率を50%→80%（スラッシュコマンドの標準化で対処）といった形がある。
注意が必要なのはメトリクスゲーミングだ。デプロイ頻度を上げるために小さすぎるPRを量産する行動が出ることがある。PRサイズとデプロイ頻度をセットで追うと、そのバランスが崩れていないか確認できる。また、5人チームと50人チームでは同じデプロイ頻度でも意味が違う。Eliteベンチマークとの比較より「チーム自身の前月比較」の方が健全な指標になる。
Medeirosはこうも言っている。"The real risk is not slow adoption. It is forced adoption that burns trust"——「本当のリスクは採用が遅いことではない。信頼を壊す強制採用だ」。メトリクスは問題を見つけて改善するための道具であり、数値で責任を追及するために使うものではない。この認識をチームで共有しておかないと、数値を見せた瞬間に防衛的な空気が生まれる。
まとめ
「チームが速い」という感覚と「チームが安全に出荷できている」という事実は、別物だ。AIを使い始めてから速度が上がったのに品質が下がっているなら、それはDORAで測れる問題であり、Claude Codeで分析・改善できる問題でもある。
git logを渡してリードタイムを算出させるところから始められる。数分で「ボトルネックがレビュー待ちにある」という具体的な情報が手に入る。感覚ではなく数値で改善の議論を始めてほしい。
コメント