AI駆動開発の効果測定はなぜ的を外すのか — 保守開発の現場で測るべき指標
はじめに
前回の記事([選定編へのリンク])では、AI駆動開発ツールの選定を「2つのゲート+ポイント制」で設計する話を書きました。その終点はパイロット導入と効果計測です。今回はその計測を扱います。
先に本記事の主張を言い切ります。世の中に出回っているAI導入の効果測定は、グリーンフィールド(新規開発)前提のものが多く、日本のシステム開発現場の大半を占める保守開発では的を外します。 保守の現場でエンジニアの時間を食っているのは、コードを書くことではありません。読むこと・調べることです。ならば測るべき指標も変わるはずです。
対象読者は前回と同じく、AI駆動開発の導入を検討・推進しているCTO・IT部門責任者などの意思決定層です。
「導入した。で、効いてるの?」に答えられますか
AIツールを導入した組織の多くが、この問いに答えられません。「開発者の評判はいい」「なんとなく速くなった気がする」— 意思決定層への報告がこのレベルだと、次の投資判断(拡大するのか、やめるのか)ができず、導入は「入れっぱなし」で塩漬けになります。
原因はツールではなく、計測の設計にあります。よくある失敗は3つです。
- 比較の基準がない。 導入後の数字を眺めるだけでは、「効果があった気がする」以上のことが言えません
- 速度しか測っていない。 CodeRabbitの調査(2025年12月)では、AIが共同執筆したプルリクエストに人間のみの場合に比べて約1.7倍の問題が検出されています。速度単独の改善は、品質の先食いかもしれません
- 判断基準を後から決めている。 結果を見てから「どう解釈するか」を議論すると、結論ありきの解釈合戦になります
計測設計の4原則
上の失敗の裏返しが、そのまま設計原則になります。
- 比較の基準を先に確保する。 導入後の数字だけでは何も判断できません。基準は2通りあります — 普段からDORA指標などを計測している組織は過去の履歴が、そうでない組織は後述する「くじ引き方式」の同時期対照群が、それぞれ基準になります
- 判断基準を先に合意する。 「何がどれだけ改善したら拡大、悪化したら撤退」を、パイロット開始前に意思決定層と合意します(具体例は後述)
- スピードと品質は必ずペアで見る。 片方だけの改善は改善ではありません
- 数字を「作りにいけない」設計にする(ゲーミング耐性)。 指標を置くと、その指標だけを良くする行動が生まれます。コミット数や行数は簡単に水増しできてしまうため、成果に近い指標(リードタイムや障害率)を選び、個人ではなくチーム単位・成果単位で測り、そもそも計測値を個人評価に使わないことを宣言します(理由は後述)
基本の指標セット(5層)
汎用的に使える指標を5層に分けて挙げます。全部を測る必要はありません。計測の負荷も考慮して、各層から1〜2個を選ぶのが現実的です。
1. スループット
- 変更リードタイム:チケット着手から本番反映までの時間。DORA指標の一つで、CTO層への報告言語として最も通じやすい指標です
- チケットのサイクルタイム:保守開発なら「1チケットあたりの所要時間」が最も自然な単位です
ここで必ず出る疑問が、**「チケットごとに難易度が違うのに、所要時間を比べて意味があるのか?」**です。もっともな疑問で、これへの答えは計測方法の設計そのものに関わるため、後述の「効果測定の進め方は2択」でまとめて扱います。
2. 品質・安全
- 変更障害率:リリースに起因する障害の割合。これもDORA指標です
- レビュー差し戻し率:AI導入後にここが悪化していたら、速度の改善は品質の借金で買っている可能性があります
- 静的解析・SASTの検出数の推移:セキュリティ観点の定点観測として
3. レビュー負荷
- レビュー所要時間・指摘件数:AI導入後の典型的な現象が「生成は速いがレビューが詰まる」というボトルネックの移動です。ここを測っていないと、「個々の作業は速くなったのに全体のリードタイムが縮まない」原因が見えません
4. 定着度
- アクティブ利用率:契約ライセンス数に対する実利用者の割合。使われないツールの効果はゼロなので、効果より先にまず定着を確認します
- AI提案の受入率:補完型ツールの多くは管理画面で取得できます
- 開発者満足度:週次の簡易サーベイで十分です。定量で見えない「ツールの癖に苦しんでいる」等の兆候はここで拾えます
5. コスト
- 実際にかかった月額費用:定額部分+従量部分の実額。2026年は主要ツールが従量課金へ移行しており、エージェントが自律的に長く動くほどトークン消費=請求が伸びます。定額前提の予算計画は危険です
- 削減された工数との対比:リードタイム短縮分を工数単価に換算し、費用と比べます
予算の桁感(2026年7月時点)
コスト計測の前提として、金額の桁感を載せておきます。円換算は1ドル=162円前後(2026年7月16日時点)で計算しています。価格改定だけでなく為替でも変わるため、稟議の前には必ず各社の価格ページで最新情報を確認してください。
課金モデルの基本は、ユーザー単位の月額サブスクリプション+従量クレジットのハイブリッドです。チームプランは席数×単価で、最低席数の縛りは一部エンタープライズプランを除いて基本的になく、少人数のパイロットから始められます。
| 区分 | 月額の目安(1ユーザーあたり) | 備考 |
|---|---|---|
| 無料枠 | $0 | 個人の検証用。回数制限あり |
| 個人・入門プラン | $10〜20(約1,600〜3,200円) | 各社のPro相当 |
| チームプラン | $20〜40前後(約3,200〜6,500円) | 組織管理機能付きの席数課金 |
| ヘビーユース・上位プラン | $100〜200(約1.6万〜3.2万円) | 長時間の自律実行・並列エージェント運用向け |
| エンタープライズ | $39〜60+従量(約6,300〜9,700円+従量) | SSO・監査ログ・IP補償・エアギャップ対応等 |
なお「定額」を謳うプランも、多くは上限付き定額+任意の従量オーバーフローという構造です(上限に達したら、リセットを待つか従量課金で使い続けるかを選ぶ形)。利用量が読めて予算の予見性を優先するなら上限付き定額の上位プラン、利用が不均一で重い利用でも止めたくないなら従量ベース、という選び分けになります。
試算のイメージとして、5人チームのパイロットなら、補完型のみで月$50〜200(約8,000円〜3.2万円)、エージェント型を本格的に使う場合で月$500〜1,000(約8万〜16万円)程度が出発点です。後者は大きく見えますが、エンジニア1人の月単価の数日分に過ぎません。リードタイム短縮が少しでも計測できれば回収できる水準であり、だからこそ「計測できているか」がすべてを分けます。
保守開発の現場で測るべき3指標(本記事の本丸)
ここからが本題です。上の5層は汎用ですが、保守開発中心の現場では、これだけだとAIの効果を過小評価します。理由は冒頭に書いた通り、保守のコストの本体が「書く」ではなく「読む・調べる」にあるからです。以下の3つを足してください。
1. 影響調査・コード理解の時間
「このチケットの修正はどこに波及するか」を調べる時間です。既存システムに手を入れる場合、実装そのものより影響調査のほうが長いことは珍しくありません。そしてここは、コードベースを読ませて質問できるAIが最も効く場所です。チケットの作業時間を「調査」と「実装」に分けて記録するだけで計測できます。ベースラインとの比較で、「実装は変わらないが調査が半分になった」という保守現場特有の効果が可視化されます。
2. 障害対応のMTTR(平均復旧時間)
障害発生から復旧までの時間です。原因調査(ログの解析、該当コードの特定)にAIを使うと、ここが顕著に縮む現場があります。DORA指標の一つでもあり、意思決定層には「障害対応が速くなる」は生産性の話より通じることも多い指標です。
3. ドキュメント整備の進捗
AIによる既存コードのドキュメント生成は、新規開発の現場では副産物ですが、ドキュメントが作られていない、または設計書と実装が乖離してしまった現場では主要成果になり得ます。仕様書のないモジュールにドキュメントが付くことは、属人化の解消・引き継ぎコストの削減・次のAI活用の精度向上(AIに読ませる文脈が増える)に直結します。「ドキュメント化されたモジュール数」のような単純なカウントで十分です。
この3指標の意味は、「新規開発が少ないうちの現場でAIを入れて意味があるのか?」という問いに正面から答えられることです。答えは「ある。ただし測る場所が違う」です。
効果測定の進め方は2択 — DORA指標を測っているか、いないか
指標を並べただけでは、まだ「AIのおかげでどれだけ得したのか」という意思決定層の問いには答えきれません。チケットの難易度は一件ごとに違い、時期によっても構成が変わるからです。この問題への対処は、自社に計測の下地があるかどうかで分かれます。
すでにDORA指標を測っている企業:そのまま前後比較でよい
DORA指標とは、Googleの研究プログラム(DORA:DevOps Research and Assessment)が世界数千組織の調査から確立した、開発パフォーマンスの標準指標です。①デプロイ頻度、②変更リードタイム、③変更障害率、④平均復旧時間(MTTR)の4つで構成され、スピード(①②)と安定性(③④)をペアで見る設計になっています。
普段からこれらを継続計測している組織なら、話は簡単です。導入前の長い履歴がそのままベースラインになるため、AI導入前後の比較が素直に成立します。新しい計測の仕組みを作る必要はありません。ただし、3点だけ注意してください。
- 外れ値をはじく:重い案件が1本入るだけで短期の数字は跳ねます。平均ではなく中央値や85パーセンタイルで、分布として見てください
- 比較期間を十分に取る:DORA指標は本来、組織レベルの長期傾向を見るための統計です。導入直後は学習曲線で一時的に悪化もするため、導入後最低6〜8週間、できれば四半期単位で比較します
- スピードと安定性を必ずセットで見る:リードタイムの改善と変更障害率の悪化が同時に起きていないか。片方だけの報告は意思決定を誤らせます
測っていない企業:見積もり+くじ引きの併用が効く
多くの組織はこちらのはずです。今からDORAの計測基盤を整備してベースラインを取るのは数か月がかりで、パイロットの意思決定には間に合いません。そこで効くのが、プランニングポーカーとランダム化比較の併用です。
プランニングポーカーは、チケットの大きさをチーム投票で見積もる、アジャイル開発で広く使われる手法です(小規模チームなら担当者個人の見積もりでも構いません)。運用はPM/TLに委託できる粒度です。これを計測の物差しに転用し、次の手順で回します。
- 見積もる:チケットの工数を「AIなし前提」で見積もり、確定させる
- くじを引く:確定後に、そのチケットでAIを使ってよいかを抽選で決める
- 実測する:実際にかかった工数を記録する
- 比較する:「実工数÷見積もり」の比率を、AI利用群と非利用群で比べる。群間の差がそのままAIの効果です。あわせて差し戻し率・障害率も群間で比較し、品質が落ちていないかを必ず確認します
順序が命です。「見積もりの確定→くじ→着手」を崩さないでください。 くじの結果を知ってから見積もると「AIありだから小さめでいいか」という無意識の補正が入り、物差し自体が歪みます。同じ理由で、「AIがなかったら何時間かかったか」を後から見積もらせるのも禁物です。反実仮想の自己申告には体感バイアスが乗ります。METRのランダム化比較試験(2025年7月)では、経験豊富なOSS開発者16名・実課題246件をAI利用可/不可にランダム割当したところ、開発者は作業後も「AIで20%速くなった」と感じていたのに、実測では19%遅くなっていました(2025年時点のツールでの結果。METRは2026年2月の続報で、最新ツールでは高速化に転じたと報告しています)。体感と実測は、これほど食い違い得るということです。ちなみにこの研究の設計 — 課題ごとのランダム割当 — は、まさに本節の「くじ引き方式」そのものです。
この方式は**ランダム化比較試験(RCT)**と呼ばれる、新薬の治験と同じ実験設計です。この方法を使う理由は、本記事の冒頭で挙げた「計測設計の4原則」を仕組みで担保しやすくするためです。
- 選択バイアスが消える:ランダム化しないと、現場は自然に「AIが得意そうなチケット」にAIを使うため、効果が水増しされます。くじなら難しいチケットも簡単なチケットも両群に同じ確率で落ち、難易度のバラつきも時期の偏りも、同一期間・同一チーム内の比較なので一挙に消えます
- 事前のベースライン計測が不要:比較の基準が「過去の自分たち」ではなく「同じ期間の対照群」だからです。すでにAIを導入済みでベースラインを取りそびれた組織でも、今日から測り始められます
- 品質の劣化まで因果として検出できる:「AI群は速いが差し戻しも多い」という速度と品質のトレードオフを、同じ実験装置で捕捉できます
- 数字を「作りにいけない」:見積もりはくじの前に確定するため、見積もる時点では誰もそのチケットがどちらの群に落ちるか知りません。仮に見積もりが盛られても歪みは両群に等しくかかり、群間の差として出てくる効果の数字は歪みません。計測設計の4原則で挙げたゲーミング耐性を、運用の宣言ではなく仕組みの側で担保できます
実務上の注意は4つ。
- 期間限定と明言する:「くじに外れたらAI禁止」を日常運用にしてはいけません。AIの利便性を実感し始めた開発者からツールを取り上げ続けることは強烈なモチベーションダウンであり、人材流出の契機にすらなり得ます。計測のためのパイロット期間だけの協力である、と最初に枠を切ります
- 緊急チケットの除外ルールを事前に決める:障害対応をくじで縛るわけにはいきません。ただし除外をその場の裁量にすると恣意が入るため、除外条件は開始前に固定します
- くじで制御する「AI」の範囲を先に定義する:制御するのはパイロット導入するツールだけです。ChatGPTのような対話型AIの日常利用はすでに現状の一部なので、両群とも従来通りで構いません。隠れ利用を完全に防ぐ手段はないため、計測の目的の説明と「個人評価に使わない」宣言(後述)で、ごまかす動機自体を消しておきます
- チケット数を確保する:群を分けるためサンプルが半分ずつになります。チームが小さい場合は期間を延ばして件数を稼いでください
ここまでやる組織は多くありませんが、手順そのものは「見積もる→くじ→記録→比較」だけです。「体感」や「気がする」を排した数字を経営会議に出せる価値を考えれば、十分に割に合います。
運用設計:パイロットの期間と判断基準
パイロット期間は6〜8週間が目安です。比較の基準はここまでの2択にそのまま対応します — DORA指標を計測済みの企業は過去の履歴が、未計測の企業はくじ引きの対照群が基準になるため、どちらの場合も計測のためだけの準備期間を別途設ける必要はありません。見積もりとくじの運用ルールを決めたら、すぐに始められます。
一方で、パイロット期間を短くしすぎてはいけません。導入直後は学習曲線の途中で、一時的にむしろ生産性が下がるのが普通だからです。そこで測ると、本来の効果を過小評価してしまいます。
判断基準の合意は、たとえばこんな形です。
変更リードタイムが20%以上改善し、かつ変更障害率が悪化していなければ、対象チームを拡大する。アクティブ利用率が50%未満なら、効果判定の前に定着阻害の原因を分析し、ツールの再選定を含めて検討する。
くじ引き方式の場合は、「AI利用群の(実工数÷見積もり)が非利用群より20%以上小さい」のように群間差で定義してください。数字そのものは組織で調整して構いません。大事なのは、この文をパイロット開始前に意思決定層と合意しておくことです。
計測値を個人評価に使わない、と宣言する
最後に、地味ですが計測の成否を分けるポイントを一つ。計測値を個人の人事評価に使わないことを、パイロット開始時に明文化して宣言してください。
これをしないと、現場は数字を作りにいきます。チケットを細かく割ってスループットを水増しする、レビューを形骸化させて所要時間を縮める — 人は測られ方に適応する生き物です。そうなった瞬間、すべての計測値は意思決定の材料として無価値になります。加えて、「監視されている」という感覚はAI導入そのものへの現場の抵抗を強めます。計測の目的は人の査定ではなくツールへの投資判断である、と明確にすることは、データの信頼性と導入の成功率の両方に効きます。
まとめ
- 比較の基準なき計測に意味はない。基準は、DORA計測済みなら過去の履歴、未計測なら同時期の対照群(くじ引き)
- スピードと品質は必ずペアで見る。速度単独の改善は品質の先食いかもしれない
- 判断基準(拡大/撤退の条件)はパイロット開始前に意思決定層と合意する
- 保守開発の現場では、「影響調査・コード理解の時間」「MTTR」「ドキュメント整備」を測る。保守のコストの本体は書くことではなく読む・調べることにある
- 効果測定の進め方は自社の下地で2択。DORA指標を継続計測しているなら前後比較(外れ値をはじき、期間を十分に取る)、していないなら見積もり+くじ引きの併用。「AIなしなら何時間か」の自己申告は使わない
- コストは従量込みの実額で計測する。5人でのエージェント本格利用は月8万〜16万円程度 — エンジニア単価と比べれば、計測さえできていれば回収可能性を判断できる水準
- 計測値を個人評価に使わないことを宣言する。これを怠ると数字も導入も両方死ぬ
選定(前回)→パイロット→計測(今回)→拡大/縮小/再選定、でループが閉じました。AI駆動開発の導入は一度きりのイベントではなく、このループを回し続ける運用です。ツールは半年で入れ替わっても、この判断の構造は使い回せます。
本記事の価格・市場動向は2026年7月時点の情報です。この分野は変化が速いため、実際の判断時には最新情報の確認をおすすめします。