← 最新の論文
💻 computer science

GitHub Copilot and Developer Productivity: An Observational Dose-Response Analysis

16,223人のマイクロソフトのエンジニアを43週間にわたって対象とし、個人のスキルや努力を制御するためにエンジニア内固定効果デザインを用いた本研究は、GitHub Copilotの使用が、同等のコーディング時間におけるプルリクエスト完了率の40.5%の単調な増加に関連していることを発見しており、これは単なる多忙な時期との相関ではなく、真の効率性の向上を示している。

原著者: Alex Heilman, Alex Kyllo, Emerson Murphy-Hill

公開日 2026-06-02
📖 1 分で読めます☕ さくっと読める

原著者: Alex Heilman, Alex Kyllo, Emerson Murphy-Hill

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む

新しいハイテクなランニングシューズが、実際に人の走るスピードを速めるのかどうかを確かめたいと考えていると想像してみてください。

最も分かりやすいテスト方法は、2つのグループを比較することです。ハイテクシューズを履いているグループと、普通のスニーカーを履いているグループです。しかし、ここに問題があります。ハイテクシューズを「選んだ」人々は、もともとプロのアスリートである可能性があります。もしシューズを履いている人々がより速く走ったとしても、それはシューズのおかげなのでしょうか、それとも単に彼らがもともと優れたランナーだったからなのでしょうか?

これは、Microsoftの研究者が「GitHub Copilot」という、ソフトウェアエンジニアのコーディングを支援するAIツールに対して直面したのと全く同じパズルです。彼らはこう知りたかったのです。AIを使うことは、実際にエンジニアの生産性を高めるのか、それともAIを最も多く使っているエンジニアは、単に生まれつき生産性が高い人々なのでしょうか?

さらに厄 So 悪いことに、ここには二層目の混乱が存在します。あるエンジニアが特定の週にAIを多用しているのは、AIが魔法のような力を持っているからではなく、その週が大規模なプロジェクトに取り組んでいる「繁忙期」で、1日80時間働いていたからかもしれません。その場合、彼らがより多くの仕事(プルリクエスト)を完了させたのは、AIが彼らを「速く」させたからではなく、単に長く働いたからということになります。

解決策:「自己比較」実験

研究者たちは、一部のエンジニアにツールの使用を強制的にやめさせることはできなかったため(それは非倫理的であり、業務を妨害することになるため)、「Within-Engineer(個人内)」分析と呼ばれる巧妙なトリックを用いました。

これを次のように考えてみてください。エンジニアA(AIを使用)とエンジニアB(使用しない)を比較する代わりに、彼らはエンジニアAを、エンジニアA自身と比較したのです。

彼らは同じエンジニアを43週間にわたって観察しました。

  • 第1週: そのエンジニアはAIをほとんど使わなかった。
  • 第2週: そのエンジニアはAIをヘビーに活用した。

同じエンジニアを比較することで、エンジニアAとエンジニアBを隔てているあらゆる要素(天賦の才能、職務、チーム文化など)を自動的に相殺することができました。彼らはこう問いかけたのです。「この特定の人物がAIをもっと多く使用したとき、使用していないときと比較して、より多くの成果を出しているだろうか?」

「効率性」テスト:彼らはよりハードに働いたのか、それともスマートに働いたのか?

ここにもう一つ、厄介な変数がありました。それは**「努力量(エフォート)」**です。
もしエンジニアがAIを多用しているなら、その人は単に、5時間ではなく10時間デスクに向かってコーディングしているだけかもしれません。もし彼らがより多くの仕事を完了させたとしても、それは単にデスクに座っていた時間が長かったからかもしれません。

これを解決するために、研究者は「コーディングに費やした時間」を一定に保つための統計的な「フィルター」(PPMLと呼ばれるモデル)を使用しました。

  • 問い: 「エンジニアAがちょうど8時間コーディングする場合、AIをヘビーに使っているときとそうでないときとで、完了するコードの量は変わるのか?」

結果: はい。コーディングに費やした時間が全く同じであったとしても、AIをヘビーに使用しているエンジニアは、全く使用していない週と比較して、約**40%多くのコードプロジェクト(プルリクエスト)**を完了させていました。

「偽造(Falsification)」テスト:言い訳を排除する

研究者たちは、懐疑論者がこの結果に対して他の理由を挙げてくることを予見していました。そこで、結果が単なる偶然ではないことを確認するために、7つの異なる「嘘発見器」テストを実施しました。

  1. 「汎用AI」テスト: AIを多く使うエンジニアは、単に「テックに強い」だけであり、他のAIツール(WordやExcelなどのもの)も使っているために、生産性が高く感じられているだけではないか?

    • テスト: コーディング以外のアプリ(PowerPointなど)でのAI使用が、コードの記述量を予測するかどうかをチェックしました。
    • 結果: いいえ。WordでのAI使用はコードの記述量には影響しませんでした。重要なのは、コーディング専用のAIでした。
  2. 「チームの熱狂」テスト: チーム全体が「盛り上がっている」週だったために、全員がAIを使い、全員がコードを多く書いていたのではないか?

    • テスト: あるエンジニアのAI使用量が、その同僚たちのコードの出力量を予測するかどうかをチェックしました。
    • 結果: いいえ。もしそれが単なるチーム全体の熱狂であれば、あなたのAI使用量が隣人のアウトプットを予測するはずですが、そうはなりませんでした。
  3. 「タスク切り替え」テスト: AIを多用する週には、エンジニアが他人のコードレビューをやめて、自分のコードを書くことだけに集中していたのではないか?

    • テスト: コードの記述量が増えることが、コードレビューの減少を意味していないかをチェックしました。
    • 結果: いいえ。エンジニアはAIを使用しているとき、コードを多く書くだけでなく、レビューもより多く行っていました。彼らはタスクを入れ替えたのではなく、あらゆる作業をより多くこなしていたのです。
  4. 「細分化」テスト: エンジニアたちが、数字を良く見せるために大きなプロジェクトを小さくて簡単なパーツに切り分けていたのではないか?

    • テスト: コードプロジェクトのサイズを調査しました。
    • 結果: いいえ。最大のブーストは、小さなプロジェクトではなく、むしろ**最大かつ最も複雑なプロジェクト(7ファイル以上)**において見られました。
  5. 「簡単な作業」テスト: 彼らは単に、難しいコーディングではなく、簡単な事務作業(テキストファイルの更新など)を行っていたのではないか?

    • テスト: 「簡単な」設定ファイルと「難しい」コードファイルを分離しました。
    • 結果: いいえ。生産性の向上は、むしろ難しいコードファイルにおいてより強力でした。
  6. 「タイミング」テスト: 第1週のAI使用は、第2週まで続く「生産的な気分」の兆候に過ぎなかったのではないか?

    • テスト: 前週のAI使用量が今週の出力量を予測するかどうかをチェックしました。
    • 結果: いいえ。ブーストは、AIが使用されたまさにその週にのみ発生していました。

結論

この研究は、GitHub Copilotがエンジニアの効率を真に向上させていると結論付けています。

エンジニアがこのツールを集中的に使用すると、同じ時間内でおよそ40%多くの仕事を完了させることができます。単に生産性の高い人がこのツールを使っているのではなく、ツール自体が「力の増幅器(フォース・マルチプライヤー)」として機能し、エンジニアが労働時間を増やすことなく、より多くの成果を出せるよう支援しているようです。

ただし、研究者たちは注意深く注釈を加えています。この研究は**「効率性」(時間あたりの成果)を測定しているものであり、「総時間の節約」**を測定しているわけではありません。もしAIがタスクを1時間ではなく30分で終わらせる助けになったとしても、あなたの「効率」は上がりますが、あなたは単に早めに仕事を終えて帰宅しているだけかもしれません。この研究は「スピード」が上がることを証明していますが、エンジニアがその余った時間をどのように使っているかまでは明らかにしていません。

自分の分野の論文に埋もれていませんか?

研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。

Digest を試す →