2026年8月15日 / 生産性

AIの効率化は測れない。では何が言えるのか

AIを使った開発の効率化目標が、数値で降りてくる。

新規開発でも改修でも流用案件でも、一律で同じ削減率。その数字の根拠を尋ねても、明確な答えが返ってこないことがある。

出どころの見当はつく。各社の導入事例やベンダーの発表は、経営層の目にも入る。「AIで開発が◯%速くなった」という見出しは、この数年ずっと流れ続けている。それを見て目標を置くのは、経営判断としてむしろ自然な動きだ。

だから多くの現場で似た状況が起きている。担当者が手を抜いているわけではない。根拠を出せないのには理由がある。その数字を出せる方法論が、いま存在しない。

最も真面目にこれを測ろうとした研究機関が、測定を諦めて実験の設計をやり直している。

測ろうとした人たちに何が起きたか

熟練開発者は19%遅くなった

非営利研究機関のMETRが2025年、経験豊富なオープンソース開発者16名を対象にランダム化比較試験を行った。246の課題、平均2時間規模、画面録画つき。自分が普段コミットしているリポジトリで、実際の作業をしてもらう設計だ。

結果は、AIツールを使った条件のほうが19%長くかかった。

より重要なのは、その次だ。

作業前、開発者はAIによって24%速くなると予想していた
実測では19%遅くなった
作業後も、20%速くなったと認識していた

METR自身は後の調査でこの乖離を振り返り、参加者は AIの効果を平均40パーセントポイント過大評価していたと書いている。画面録画で計測されているのに、本人の実感はそれと逆を向いていた。

この研究から引き出すべき教訓は「AIは開発者を遅くする」ではない。著者自身が、そうした過剰一般化を明確に否定している。引き出すべきは、体感が生産性の指標にならないという一点だ。

社内アンケートで「AIで効率が上がった実感がある」を集めても、それは何の証拠にもならない。

なお、この研究のページには現在、METR自身による注記が付いている。 2026年2月に、後期2025年のAIツールについての新しいデータを公開した、と。 19%という数字は、著者自身が過去のものとして扱っている。 単独で引くべきではない。

実験が成立しなくなった

では、その後どうなったのか。

METRは2025年8月、より大きな規模で二度目の実験を始めた。 57名の開発者、143のリポジトリ、800を超えるタスク。参加者の開発経験は中央値で10年である。

そして2026年2月、実験デザインの変更を発表した。理由は結果が悪かったからではない。 得られたデータが、現在の生産性への影響について信頼できる信号を与えないからだ。

AIなしで仕事の半分をやりたくないという開発者が増え、参加者の確保が難しくなった。そして参加した開発者に調査したところ、30〜50%が、AIなしではやりたくないタスクをそもそも提出していなかったと答えている。

これが意味することは重い。 AIが最も効くタスクが、構造的にデータから欠落する。

測定しようとする行為そのものが、測定対象を歪めてしまう。

ただしMETR自身は、この選択効果について但し書きを付けている。影響を受けているのは開発者とタスクの少数派であり、バイアスの程度には限りがある、と。

そしてもう一点、重要な留保がある。 METRは、2026年初頭の開発者はAIによって実際に速くなっている可能性が高いと考えている。参加者への聞き取りにもとづく判断だ。

つまりMETRの立場は「AIは効かない」ではない。効いている可能性が高いと考えているが、その大きさを測る手段を失った、というものである。

では下限は出せないのか

ここで多くの人が思うことがある。筆者もそう思った。

正確な数字は無理でも、最低これくらいは効率化している、という下限なら出せるのではないか。実際、AIを使い始めた人はほとんど元に戻りたがらない。それだけの選好があるなら、効果はあるはずだ。

結論から書くと、出せない。理由が四つある。

「戻りたくない」は効率の証拠にならない

直感としては強い。しかしそれが測っているのは選好であって処理量ではない。

戻りたくない理由は分解できる。実際に速い。速度は変わらないが認知的な負荷が軽い。 AIなしのワークフローが錆びていて戻るのが苦痛。単純に楽しい。

そしてMETRの研究は、二番目が一番目なしに起こりうることの実証である。 19%遅くなりながら、20%速くなったと感じていた。

表明された選好より、実際の行動のほうが強い証拠ではある。だがそれは「AIを使いたい」の証拠であって、「AIで速い」の証拠ではない。

統計的に下限が引けない

METRの追試では、推定値そのものは出ている。

対象	推定値	信頼区間
2025年初頭の原研究	19%遅い	+2% 〜 +39%
追試・原メンバーの部分集合	18%速い	−38% 〜 +9%
追試・新規参加者	4%速い	−15% 〜 +9%

追試の二つは、どちらも信頼区間がゼロをまたいでいる。つまり統計的には「速くなった」と言い切れていない。

「18%速くなった」とだけ報じている記事は少なくないが、区間まで載せているものはほとんど見かけない。

補正しても出せない

METR自身は、選択効果を考えるとこれらの推定値は真の効果の下限だろうと述べている。実際にはもっと速い可能性がある、ということだ。

しかしこれは方向であって大きさではない。補正するには、提出されなかったタスクの分布が必要になる。そのデータは定義上、存在しない。

METR自身、実験から外れた開発者とタスクにおいては真の速度向上がはるかに大きい可能性がある、と書いている。同時に、自己申告される非常に高い数値については、先行研究が示したとおり信頼性に欠けるとも付け加えている。

上にも下にも、確かなことが言えない状態である。

分母そのものが動く

さらに根本的な問題がある。 AIは「どのタスクに着手するか」自体を変える。

タスクがスキップされたということは、分母が変わったということだ。分子である時間だけを比べても、比率は意味を持たない。

別の道からも、同じ壁

ここまではMETRという一つの研究の話である。特殊な事情ではないか、と思われるかもしれない。

まったく異なる手法の調査が、同じ結論に着いている。

開発分析ツールを提供するGitClearが、2023年から2026年にかけての 6億2300万件のコード変更を分析した。実験ではなく観察データだ。

AIを日常的に使う開発者は、使わない開発者の4〜10倍の産出を示した。桁が違う。

だがGitClear自身が、この差を “dark matter productivity” と呼んでいる。ツールの効果では説明がつかない何かがある、という認識だ。そして**同一人物の過去と比較した場合、伸びは25%**にとどまる。

差の大半は、AIによって生まれたものではない。 もともと生産性の高い開発者が、AIを早く採用しただけだった。

	METR	GitClear
手法	ランダム化比較試験	観察・6.23億変更
選択効果の形	参加者が自己選択で抜ける	ヘビーユーザーが元から高生産性
結論	巨大な数字の正体は選択効果	同左

正反対の方法で、同じ壁にぶつかっている。

（GitClearは開発分析ツールのベンダーであり、報告書本文はメールアドレス登録の先にある。本稿で参照したのは公開されている要旨のみで、査読も経ていない。METRの数字と同列には扱えない点は付記しておく。なお4〜10倍という値は、GitClearが自社の複数のレポートにまたがって提示しているもので、どのサンプルに基づく数字かは公開されている範囲からは確定できない。測定の厳密さを問題にしている以上、この数字も同じ基準で扱う。）

問いを変える

ここまでで分かるのは、「AIは何%効率化するか」という問いには答えが出せない、ということだ。手法を変えても、母集団を変えても、同じ壁に当たる。

ただし、答えの出せない問いを立て続けているだけではないか、という見方もできる。

問いを変えてみる。

「どういう条件なら、効率化が言い切れるか」

こちらには答えがある。少なくとも、条件を整理することはできる。

以下では三つの条件で考える。

仕様が閉じているか — 作るべきものが確定しているか
参照すべき範囲が狭いか — 判断に必要な情報がどれだけ広がるか
正解を機械的に検証できるか — 出力が正しいかを人の合意なしに判定できるか

この三つを当てると、現場でよく言われる区分が、意外な形で崩れる。

「上流は苦手、下流は得意」という直感

現場で聞く感触は、だいたい一致している。テストコードの生成、定型的な実装、ドキュメントの整備——このあたりは明確に速くなった。一方で、何をどう作るかを決める段階では、あまり助けにならない。そういう実感を持っている人は多いはずだ。

時間のデータは、この直感を支持しているように見える。

McKinseyが2023年に社内の開発者40人強を対象に行った調査では、コードのドキュメント作成はおよそ半分の時間で、新規コードの記述もそれに近い水準で完了したと報告されている。一方、開発者自身が「複雑」と判断したタスクでは、 削減幅は10%未満まで縮んでいる。

きれいに直感どおりだ。定型は速くなり、難しいものは速くならない。

ところが、同じ調査の別の図表は逆を向いている

この調査には、時間削減とは別の指標がもうひとつある。 制限時間内にタスクを完了できた割合だ。

複雑度	AIなし	AIあり	完了しやすさ
低	92%	94%	ほぼ変わらず
中	73%	83%	10〜15%高い
高	42%	54%	25〜30%高い

（McKinseyの表現は「時間内に完了する可能性が25〜30パーセント高い」であり、相対的な比較である。実数の差は12ポイントにあたる。）

時間削減が最も小さかった高複雑度タスクで、完了しやすさの改善が最も大きい。低複雑度では、完了率はほとんど動いていない。

完全に逆を向いている。

難しい仕事において、AIは作業を速くしていない。終わるようにしている。 そしてその価値は、時間という物差しには映らない。

これは前節で見た測定不能の問題と、同じ構造をしている。指標を「X%の時間削減」に固定した瞬間、最も大きい効果が測定対象の外に落ちる。

（この調査は2023年6月、被験者は McKinsey 社内の開発者40人強。ツール世代も母集団も限定的であることは踏まえておきたい。ただし後述する構造の議論は、削減率の絶対値には依存しない。）

上流を一括りにすると見えない

では「上流」の中身を分解してみる。先に挙げた三つの条件を当てると、上流工程の中で評価が割れる。

上流の作業	仕様の閉じ具合	参照範囲	検証可能性
不慣れな技術・領域の調査	開いている	広い	高い
選択肢の列挙・比較	開いている	広い	高い
たたき台の作成	開いている	広い	高い
何を作るかの決定	開いている	極めて広い	低い
要件の粒度を揃える	開いている	広い	低い

上の3つは、仕様が閉じておらず参照範囲も広いが、検証可能性が高い。調査結果は試せば裏が取れる。選択肢の網羅性は人が判断できる。たたき台は気に入らなければ捨てればいい。外れたときのコストが小さい。

だから時間は縮まなくても、着手できるようになる、進むようになる。完了しやすさが25〜30%高まったというのは、おそらくこの種の効き方だ。

「上流は苦手」という直感が実際に当たっているのは、下の2つだけである。

苦手さの正体は工程ではない

では下の2つが難しいのはなぜか。上流だからではない。 正解が外部にあり、検証がステークホルダーの合意でしか行われないからだ。

何を作るかの決定に、機械的な正解判定は存在しない。要件の粒度も同じで、粗いまま渡せば、AIは参照すべき暗黙情報を持たないまま出力する。そしてその暗黙情報は、コードにもドキュメントにも書かれていない。関係者の頭の中にある。AIの外にある。

同じ理屈が下流にも当てはまる。

既存コードの改修で、現在の挙動が意図された仕様なのか、放置された不具合なのかを判断する場面がある。

手順としては、まずコードとドキュメントを突き合わせて整合性を確認する。この工程はAIがよく効く。散在した記述を集めて矛盾を指摘するのは得意な部類だ。

だが、そこで出てきた答えが正しいかは、AIには判断できない。最終的には顧客への仕様確認か、有識者の判断を仰ぐことになる。

AIが出せるのは「コードとドキュメントから読み取れること」までで、それが意図と一致しているかは、コードにもドキュメントにも書かれていない。関係者の記憶と、当時の判断の中にある。

下流であっても、正解が外部にあれば同じ壁が立つ。つまり効き方を決めているのは工程の位置ではなく、正解がどこにあるかだ。

流用率と改修率、そして正解の所在

もうひとつ、見積もりの場で混同されやすい変数がある。

流用率 — 既存資産をどれだけ持ち込めるか（入力の量）
改修率 — 持ち込んだもののどれだけに手を入れるか（変更の深さ）

直感的には、改修率が高いほどAIは効きにくそうに思える。読む量が増え、触っていい範囲も曖昧になるからだ。

だが実際にはそうならない領域がある。

仕様を変えずに実装言語を入れ替える老朽更新を考えてみる。流用率も改修率も高い。コードのほとんどに手が入る。それでもAIはよく効く。

理由は明快で、正解が既存の挙動として確定しているからだ。何を作るべきかを決める必要がない。移植前の振る舞いが仕様そのものになる。検証も比較で済む。

類似機能を参照しながら改修を組み立てる場合も同じ構造になる。参照先が正解の役割を果たしている限り、AIは持ち込んだ量の多さを負担ではなく材料として扱える。

逆に手間が跳ね上がるのは、その参照先が崩れるときだ。

言語のバージョン変更、OSの入れ替え、データベース製品の移行。いずれも非互換を伴う。

このうち言語やOSの非互換は、まだ扱いやすい部類に入る。壊れる箇所がコンパイルエラーや実行時エラーとして表に出るからだ。機械的に洗い出せる。

厄介なのはSQLの非互換である。 動くが、結果が変わる。 ソート順、NULLの扱い、暗黙の型変換。エラーは出ない。テストで踏まなければ、そのまま通ってしまう。

（現在のツールを使った場合にどうなるかを実測した公開データはない。ただし以下の構造は、ツールの世代に依存しない。）

人手でやると、既存資産の調査に時間が吸われる。そして吸われている時間の中身は、コードを読む作業そのものではない。 この挙動は意図されたものか、それとも偶然そうなっていただけかを一件ずつ判別する作業だ。

このとき何が起きているかというと、既存の挙動を正解として使えなくなっている。移行先では変わってしまう、あるいは変わってはいけない箇所が混ざっているのに、どれがそれなのかはコードからは分からない。影響範囲の調査に時間がかかるのは、この判別作業だからだ。

つまり流用率と改修率は、それ自体が難易度を決めているわけではない。 既存の挙動を正解として使えるかどうかが効いている。

	正解が既存挙動から取れる	取れない
例	仕様据え置きの老朽更新、類似機能の参照	非互換を伴う移行、仕様の妥当性が問われる改修
AIの効き	高い	低い
参照量の多さ	材料になる	負担になる

前節の上流工程と、まったく同じ軸である。

そして見積もりの場では、この区別が落ちやすい。「既存資産があるから安く済む」という判断は、正解が既存挙動から取れるケースでは正しい。だが同じ流用率でも、参照先が崩れる案件ではまったく成り立たない。

一律の削減率は、この差をまたげない。

まだ変数がある

ここまで挙げたのは一部にすぎない。効き方を左右する要因は、少なくとも三つの層に分かれる。

案件の性質 — 開発パターン、流用率、改修率、既存資産の有無、規模、画面中心か外部連携中心かといった特徴
インプットの質 — 要件定義の粒度
使う側の状態 — AIの習熟度、その領域が初回か二回目以降か

一層目だけで組み合わせは爆発する。そして三層目は時間とともに動く。同じ案件を半年後に測り直せば、違う数字が出る。

前節で見たMETRの被験者は、熟練開発者でありながらAIツールには不慣れだった。そして一年後、METRが実験を続けられなくなった原因も、この層の変化だった。

一律の目標値が成立しない理由は、二重になる。案件ごとに違うだけでなく、同じ案件でも時期によって違う。動いているものに、固定された定規を当てていることになる。

なお、ここまでの工程ごとの評価は仮説であり、筆者も実測値を持っていない。だからこそ、目標値は現場ごとに測って決めるしかない。

勘定に入っていないもの

もう一つ、効率化の議論から抜け落ちやすいものがある。

AIが出力したものが正しいかどうかは、人が確認しなければ分からない。前節で見たとおり、コードとドキュメントから読み取れる範囲を超えた判断は、 AIの側では完結しない。人間のレビューは必須になる。

そして生成量が増えれば、レビュー対象も増える。

ここから先は筆者の推測になるが、レビュー工数は従来より増えていると考えられる。効率化によって削減された分と、増加したレビュー工数の分を差し引きしなければ、正味の効果は分からない。にもかかわらず、目標として設定されるのは前者だけである。

推測の裏づけになりそうなデータはある。

前出のGitClearが2023年から2026年にかけて追跡した品質指標では、コード内のコピー&ペーストが41%増加し、5行以上連続する重複ブロックは81%増えている。一方で、新しく書かれたコードが既存の関数を呼び出す頻度は35%下がった。新しいコードが既存の構造に織り込まれず、独立した塊として積み上がっている。

書き直しの指標も動いている。作成から2週間以内に修正されるコードの割合は15%増えた。

GitClear自身の表現を借りれば、いまのAIワークフローは「動くコード、通るテスト、閉じたチケット」を出すよう動機づけられており、目に見えないものと後回しにされるものに静かに課税している、ということになる。

（GitClearは開発分析ツールのベンダーであり、報告書本文はメールアドレス登録の先にある。ここで参照したのは公開要旨のみで、査読も経ていない。数値そのものより、複数の指標が同じ方向を向いている点を見るべきだろう。）

レビュー対象の量が増え、重複が増え、関連が薄い塊として散らばっていく。レビューする側の負荷が上がらないと考えるほうが不自然に思える。

もしそうであれば、起きているのは効率化ではなく工程間でのコストの移動である。そして移動先である下流を測っていなければ、移動は改善として記録される。

明日から変えられること

数字が出せないという話で終わらせても仕方がない。ここまでの内容から、実務上の帰結を四つ引き出せる。

一律の目標値を置かない。 工程やタスクの性質で効き方が変わる以上、平均値には意味がない。削減率を設定するなら、区分を切ってからにする。

アンケートを効果測定に使わない。 先に触れた40パーセントポイントの乖離が示しているのは、体感が指標にならないという事実だ。「効率が上がった実感がある」という回答は、施策の成否を判定できない。

測るなら下流まで測る。 前節のとおり、コストが移動しているだけの可能性がある。マージまでの時間だけを追うと、移動を改善と誤認する。レビュー工数と、一定期間内に書き直されたコードの割合まで見る。既存のPRデータから、タスク種別と組み合わせて集計するだけでも判断材料になる。

文献の数字を自社に外挿しない。 本稿で挙げた数値はいずれも、特定の母集団・特定のツール世代のものだ。自社の目標設定に使えるのは、自社のデータしかない。

数字が欲しいという欲求について

最後に、書いていて気づいたことを書いておきたい。

筆者はこの原稿を書く過程で、「せめて下限は出せないか」と考えた。そして出せないと分かった。

一律の削減目標を設定する人も、おそらく同じ場所から出発している。判断には数字が要る。稟議には根拠が要る。その要請自体は、まったく正当だ。

そして冒頭に書いたとおり、目標の出どころには見当がつく。流通している数字を見て、それを置いている。

ここで一つ確認しておきたいことがある。その流通している数字は、どこから来たのか。

たとえば「AIで55%速くなる」という数字を目にした人は多いはずだ。出典はGitHub自身の調査で、HTTPサーバを書くという単一の課題での結果である。本稿で見たMETRの追試も、信頼区間を落として「18%速くなった」とだけ伝えている記事が少なくない。

つまり、一次情報に当たれば但し書きがついている数字が、但し書きの落ちた形で流通し、それを見て目標が置かれ、現場に降りてくる。どの段階にも悪意はない。それぞれが手元にある情報で動いているだけだ。

だが結果として、根拠のない数字が目標として一人歩きする。

問題は、要請が正当であることと、答えが存在することが別だという点にある。存在しない数字を求め続ければ、どこかで誰かがそれを埋めることになる。

いま問うべきは「何%効率化するか」ではない。 **「どういう条件なら効率化が言い切れるか」**である。そちらの問いには、答えがある。

個別の変数がそれぞれどう効くのかは、稿を改めて扱いたい。