AIコーディングで本当に効率は上がったのか：3種類の証拠を1つの結論として扱わない

ある開発者は、AIのおかげで10分でプロトタイプを作れたと言います。別の開発者は、AIによる変更をレビューするほうが一から書くより遅いと言います。この2つの発言は同時に成り立ちます。プロトタイプの作成、成熟したプロジェクトの修正、長期的な保守は、同じ種類の作業ではありません。タスク、完了基準、時間の計測方法を明確にしないと、「効率が上がった」という議論は簡単にかみ合わなくなります。

技術リードにとってより有用な問いは、「自分たちのタスクで、AIは作業のどの部分を減らし、どこに作業を移したのか」です。本記事では、METRが公開した複数の研究を軸に、一見矛盾する結論の読み方を説明し、チームで採用できる評価方法を紹介します。データは2026年9月5日時点のものです。EveryInfra社内での効率実験や、モデルのランキングは含みません。

「19%遅くなった」は、実際に何を測ったのか

2025年7月に公開された研究で、METRは自分が関わるオープンソースプロジェクトをよく知る開発者16人に246件の実際のタスクに取り組んでもらい、当時のAIツールの使用を許可するかどうかをランダムに割り当てました。この研究条件では、AIを使用した場合のタスク完了時間は19%増加しました。この研究は2025年初頭のツールと特定の作業シナリオを対象としたもので、2026年のあらゆる開発作業に一律に当てはまる結果ではありません。

こうした対象範囲の限定は、結果を軽視するためではなく、その有用性を保つためのものです。大規模なリポジトリをよく知るメンテナーは、プロジェクトの慣習、過去のトレードオフ、エラーが起きやすい箇所をすでに把握しています。モデルが提示した最初の変更案が妥当に見えても、こうした背景に照らして見直す必要があるかもしれません。一方、不慣れなプロジェクトへの参加、一度きりのデータ処理、アイデアの素早い検証には、異なる制約が伴う可能性があります。

そのため、この実験から「AIコーディングは役に立たない」と言い切るのはエビデンスの範囲を超えています。「プロンプトを書ける人なら誰でも必ず効率が上がる」と解釈するのも、同様に根拠がありません。この実験は、主観的な感覚とタスクの完了にかかる時間が必ずしも一致しないことを示すものとして捉えるのが適切です。

当時のHacker Newsでの議論では、読者からサンプルサイズ、プロジェクトへの習熟度、その後の手戻りをどう計測すべきかといった疑問も出されました。こうしたコメントは評価上の問いを補うのに役立ちますが、新たな実験結果として扱うことはできません。特に、印象的な経験上の比率を、あらゆるプロジェクトに当てはまる統計的な法則として書くべきではありません。

2026年に公開された後続資料から新しいパーセンテージを単純に導き出せない理由

2026年2月の実験設計の更新で、METRは、その後の実験で参加者とタスクに選択バイアスが生じたこと、またマルチエージェントの同時実行によって時間の計測が難しくなったことを明確に指摘しました。AIを使わないことが条件となるタスクに割り当てられるのをためらう開発者もいました。研究者は、ツールによる支援効果は高まっている可能性があるものの、既存のデータではその伸びの大きさを確実に推定するには不十分だと述べています。

これは「以前の実験が覆された」ということではありません。以前の実験は、当時研究対象とした状況を今も表しています。その後の資料が示しているのは、新しい環境では研究対象や測定方法そのものも変化しているということです。AIをより積極的に使う人はサンプルに含まれていない可能性があり、AIに最も適したタスクは提出されていない可能性があります。

企業でのパイロット導入では、この問題は実務に直結します。成果を提示する意思のあるユーザーだけを集計対象にすると、失敗したタスクや途中で断念したタスクを見落としがちです。AIに不慣れなメンバーだけを参加させると、学習段階での摩擦を長期的な影響と見なしてしまう可能性があります。どちらの選び方も結論を変える可能性があります。

まず、タスクがどのようにパイロットの対象となったかを記録し、そのうえで平均的な結果を見ることをおすすめします。誰が参加しなかったか、どのタスクが除外されたか、除外の理由は何かを記録しておきましょう。ここで無関係な個人情報を集める必要はありません。タスク種別に分類したログのほうが、成功したデモをいくつか見せるだけよりも説明力があります。

速く作業すること、多く生み出すこと、高い価値を届けることは、同じ指標ではない

METRは2026年5月の技術職向け調査で、速度と価値をさらに区別しました。調査対象は349人の技術職で、回答者が自己申告した仕事の価値の倍率の中央値は、質問の言い回しによって1.4倍から2倍の範囲でした。自己申告による速度の倍率の中央値は3倍でした。これはアンケートにおける主観的な推定値であり、ランダム化実験で確認されたチームの生産性向上ではありません。

この2つの指標がずれるのはなぜでしょうか。あるチームがAIを使って社内向けのデモページを短時間で複数作ったとします。それらのページが重要な要件の確認に役立てば、価値は高いかもしれません。一方、どの意思決定にも使われなければ、コードファイルやページの数は増えても、ビジネス上の価値は伴わない可能性があります。これはあくまで仮定上の例であり、特定の企業を対象とした調査サンプルではありません。

逆に、AIによってエンジニアがドキュメントを確認する回数やツールを切り替える回数が減れば、プロジェクトの最終納期が大きく変わらなくても、仕事のしやすさは向上する可能性があります。こうした改善は記録する価値がありますが、同じ割合で人件費を削減できたと言い換えるべきではありません。

私たちは、次の3つの問いを分けて明確に立てるようにしています。同じタスクをより速く完了できたか、同じ水準に達するまでにどれだけの手作業が必要だったか、完了したタスクにより大きな価値があったか、です。これらを1つの「効率改善倍率」にまとめてしまうと、チームが作業方法を見直すうえで最も役立つ情報が失われます。

チームで評価するなら、まず「完了」を定義する

新しいツールを導入する前に、合意した完了基準をあらかじめ確定しておきます。たとえばAPI連携のタスクであれば、正常系が動作すること、重大な障害を説明できること、必要なテストが通ること、引き継ぎ担当者が制約を理解していることを条件にできます。プロジェクトごとに条件を追加・削除してもかまいませんが、結果をよく見せるためにAIの出力を見てから要件を下げることはできません。

次に、2種類の時間を分けて記録します。1つ目は、待ち時間を含む、タスク開始から受け入れまでの経過時間です。2つ目は、要件の理解、コンテキストの準備、レビュー、手戻りを含む、実際に人が作業した時間です。複数のエージェントを並行して実行する場合、各マシンの実行時間（分）をそのまま合算して人の作業時間とみなすことはできません。また、待ち時間のすべてを短縮できた時間として数えることもできません。

パイロットを始めるための記録は、次のフィールドだけで足ります。

• タスクの種類、複雑さの評価、メンバーのコードベースへの習熟度。
• 使用したツールとバージョン、AIの支援があったかどうか、最終承認の責任者。
• 最初のバージョンが生成されるまでの時間、所定の完了基準に達するまでの時間、実際の人の作業量。
• レビューで見つかった問題、手戻りの回数、その後に発見された不具合。
• タスクの業務上の目的、最終的に採用されたかどうか、採用されなかった場合はその理由。
• 中断したタスク、失敗したタスク、自ら取りやめたタスクも記録から消してはいけません。

このチェックリストは私たちが推奨する評価方法であり、METRの実験を再現するものではありません。また、少数のサンプルから有意な結論が得られることを保証するものでもありません。主な目的は、作業が生成、検証、引き継ぎのどの段階で滞っているのかを具体的に把握することです。

現在の摩擦の多くがインターフェースの不一致に起因しているなら、より高性能なモデルに切り替えても問題は解決しない可能性があります。たとえば、SDKがリクエストを組み立てられるからといって、サービス側が同じパラメータやレスポンス方式をサポートしているとは限りません。こうした互換性の判断については、サイト内のOpenAI SDKとGeminiの移行の境界で解説しています。これらの連携上の制約も、パイロットタスクの完了基準に含めるべきです。

少数のサンプルは意思決定に役立てるもので、宣伝用の数字を作るためのものではない

一定期間評価したら、結果をタスクの種類ごとに分けて見ます。リスクが低く構造が明確なタスクでは人の作業が減った一方、モジュールをまたぐ変更ではレビューが増えたのであれば、次に取るべきはAIを使う範囲の調整かもしれません。すべてのタスクで一律に利用を増やしたり止めたりする必要はありません。

結果を振り返る際は、タスクの難易度や品質要件が変わっていないかも確認します。以前はエラー処理まで完全に行う必要があったタスクが、今は正常系だけで完了しているなら、両者を直接比較すべきではありません。以前は引き継ぎ可能な計画が1つ得られていたタスクで、今は採用されない草案が10件生成されているなら、成果物の増加を件数だけで判断すべきではありません。

ツールのコストは評価軸の1つとして扱えますが、人によるレビュー、失敗時の手戻り、保守にかかる投資とあわせて見る必要があります。信頼できる記録がない場合は、API呼び出し回数や生成されたコード行数を投資対効果として見せるのではなく、現時点では算出できないと認めるべきです。タスクへの適合性、失敗時の挙動、コスト指標をあわせて比較する方法については、API選定ガイドを参照してください。

METRには、誤解されやすい研究結果をどう伝えるかを扱ったサイエンスコミュニケーションに関するノートもあります。企業のコンテンツでも同じことが言えます。読者が自分に合うかどうかを判断するうえでは、最も目を引く数字を選ぶより、魅力に欠ける制約もそのまま残すほうが効果的なことが多くあります。

「AIコーディングは効率を上げるのか」という問いに、新たな論説が1本出たからといって一律の答えが出るわけではありません。しかしチームは、この問いを答えやすい形にできます。どのような種類のタスク、ツールのバージョン、完了基準のもとで、人の作業時間が減ったのか、品質は変わったのか、成果は実際に採用されたのか、という形です。ツールの利用を広げるかどうかを決める前に、まずこうした範囲を限定した答えを得るほうが、タスクから切り離された効率倍率について議論するよりも役に立ちます。