Linux Foundationは2026年10月20日、生成AIがオープンソースソフトウェア（OSS）の開発に与える影響を調べた報告書を発表した。調査によると、生成AIの利用によってコード作成にかかる時間は平均52％短縮された一方、受け付ける変更提案のうち、低品質なものやAI生成によるものが占める割合は平均25％に上ると推定されている。いずれも回答者の自己申告に基づく数字だが、AIによってコードを書く作業が速くなる一方、その成果物を審査する側には新たな負担が生じている実態が浮かび上がった。特に大規模なOSSプロジェクトでは、レビュー時間が増えたとする回答が多く、AIを使った変更提案を提出する前に、投稿者がどこまで検証を済ませるべきかが課題となっている。

AD

コード作成時間が52％短縮、その数字が意味するもの

調査は2026年4月から6月にかけて、OSSの開発に参加する貢献者と、変更提案の審査やプロジェクトの保守を担うメンテナーを対象に実施された。Linux Foundationや協力団体がメールやSNSなどで参加者を募集し、234人が45問のWebアンケートに回答した。報告書を執筆したのはLF ResearchのSam Boysel氏とAnni Lai氏で、Red Hatがスポンサーとなり、Futurewei、OpenSSF、LF AI & Dataが調査を支援している。なお、今回の報告書はアンケート調査をまとめたものであり、査読を経た実験研究ではない。

コード作成時間がほぼ半減したという結果は、96人の回答者が推定した、生成AIの利用前後における典型的な作業時間に基づいている。報告書の図19によると、コード作成にかかる平均時間は4時間18分から2時間6分に短縮された。コードレビューとフィードバックに要する時間も、2時間30分から1時間24分に減少している。報告書では、それぞれの短縮率を52％、44％としている。

ただし、これらの数字は、AIを使う開発者と使わない開発者に同じ課題を与え、実際の所要時間を計測した結果ではない。回答者が過去の経験を振り返って見積もった時間であり、開発工程全体の所要時間が半分になったことを意味するものでもない。実際の開発現場でAI導入の効果を見積もるには、調査で対象となった作業が、自分たちの開発工程のどこに相当するのかを確認する必要がある。

また、生成AIによる時間短縮の効果は、作業の種類によって大きく異なる。調査対象となった6種類の作業すべてで平均所要時間が短くなったものの、技術的な議論では20％、変更提案を巡る議論では19％の短縮にとどまった。コードを書く作業と、その意図を他者に説明して合意を形成する作業では、AIによる効率化の度合いが異なることが分かる。さらに、難度の高い作業については、64％が時間を節約できたと回答した一方、21％は逆に時間が増えたと答えている。生成AIを使えば、難しい作業も一律に速くなるという結果ではない。

調査結果を解釈する際には、実施時期や回答者の集め方にも注意が必要だ。報告書が公表されたのは10月だが、回答を集めたのは同年4〜6月であり、それ以降に登場したAIモデルやツールの効果は反映されていない。また、Linux Foundationや協力団体のネットワークを通じて参加者を募集しているため、回答者がOSS開発者全体を代表しているとは限らない。今回の数字は、あくまで調査に参加した開発者やメンテナーの経験を表すものとして捉える必要がある。

大規模なOSSプロジェクトほどコードレビューの負担が増加

生成AIによる効率化が進む一方、メンテナーの間では、低品質な変更提案が増えているとの懸念が広がっている。Linux Foundationの報告書では、レビューに費やす時間に見合う価値が期待しにくい低品質なAI生成投稿を「AI slop」と呼んでいる。調査対象となったプルリクエスト（PR）は、コードなどの変更をプロジェクトに取り込んでもらうための提案だ。報告書の図2によると、こうした低品質な投稿が占める割合は、回答者の推定で平均25％に達した。

ただし、この25％は公開リポジトリに投稿されたPRを網羅的に調べた結果ではなく、111人の回答者が見積もった割合の平均である。また、報告書の本文では低品質なAI生成投稿として説明しているものの、図中の指標は「低品質、AI生成、またはその両方」と、より広い定義になっている。したがって、世界中のOSSプロジェクトに投稿されるPRの4分の1が低品質なAI生成コードだと断定することはできない。

特に注目されるのは、プロジェクトの規模によってレビュー負担に違いが見られる点だ。報告書9〜10ページの図1と図2では、プロジェクトの規模別に、低品質なAI投稿の推定割合とレビュー時間の変化を比較している。

プロジェクト規模 「AI slop」の平均推定割合（図2） レビュー時間が増えたと回答した割合（図1）
小規模 23％ 46％
中規模 20％ 55％
大規模 31％ 64％

※Linux Foundationの調査報告書に基づく。図2は111人、図1は174人の回答を集計したもので、設問と回答者数は異なる。報告書では、貢献者が10人未満のプロジェクトを小規模、50人超を大規模と分類している。

大規模プロジェクトでは、レビュー時間が増えたと回答した割合が64％に達し、小規模プロジェクトの46％を18ポイント上回った。ただし、これはレビューにかかる時間そのものが18％長くなったという意味ではない。また、規模別の回答者数や誤差は図に示されていないため、この差が統計的に有意なのか、生成AIの利用が直接の原因なのかまでは判断できない。それでも、規模の大きなプロジェクトほどレビュー負担の増加を訴える回答者が多いという傾向は読み取れる。

大規模プロジェクトでは、生成AIの普及以降に変更提案の投稿量が増えたと答えた割合も69％に達した。また、AI支援による投稿について最も多く挙げられた懸念はメンテナーの燃え尽きで、63％がこれを問題視している。ただし、この63％は実際に燃え尽きを経験した人の割合ではなく、回答者が懸念している問題を表す数字だ。

一見すると、生成AIによって個人のコードレビュー時間が短縮されているのに、プロジェクト全体ではレビュー負担が増えるという結果は矛盾しているように見える。しかし、自分が担当する作業を効率化することと、外部から次々に寄せられる変更提案を理解し、採用の可否を判断することは別の仕事だ。個々のレビュー作業が速くなっても、投稿数が増えれば、メンテナーが処理しなければならない仕事の総量は増える可能性がある。今回の調査だけでは、AIが節約した作業時間と、新たに発生した審査負担を差し引いて、OSS開発全体の生産性が向上したかどうかを判断することはできない。少なくとも、個人の作業速度だけを指標にしても、共同開発の効率を十分に評価できないことが分かる。

AD

AI生成コードの検証責任は誰が負うべきか

生成AIの利用が広がる一方、OSSプロジェクトにおける正式な運用ルールの整備は十分に進んでいない。報告書の図5では、119人の回答者のうち、AI利用を正式に許可する方針があると答えた割合は35％だった。一方、方針がなく、今後策定する予定もないとする回答が32％、策定を予定しているという回答が23％、明示的にAI利用を禁止しているという回答が10％を占めた。AIの利用を認めるか禁止するかという判断だけでなく、利用を認める場合にどのような条件を設けるかが重要になっている。

投稿者側にも、AI生成コードを検証する必要があるという認識は広がっている。137人が回答した図16では、61％がAI生成コードを行単位で詳しく確認し、完全な機能テストを実施してから提出すると答えた。ただし、これも回答者の自己申告であり、実際に投稿されたコードの品質が保証されているわけではない。また、既存のAI利用方針について尋ねた54人の回答では、AIの利用状況に関する透明性や開示を求めるものと、投稿者自身にレビューの責任を負わせるものが、それぞれ76％を占めていた。

LF Researchの上級副社長Hilary Carter氏は、Linux Foundationの発表で、テストと開示の責任を投稿者に持たせる必要があると指摘した。生成AIを使って作成した変更提案であっても、その内容を理解し、適切にテストしたうえで提出する責任は投稿者にあるという考え方だ。これにより、受け入れ側のメンテナーが変更の意味を一から調べ直したり、基本的な動作確認をやり直したりする負担を抑えることが期待される。

こうした考え方を具体的なルールに落とし込んでいる例が、Linuxカーネルのツール生成コンテンツに関する指針だ。この指針では、投稿者が変更内容全体を理解し、レビュー中の質問に答えられることを求めている。また、使用したツールや、そのツールが変更のどの部分に関与したのかを明らかにし、実施したテストの内容も説明しなければならない。投稿者が変更内容を理解しておらず、十分な説明もできない場合、メンテナーは詳細なレビューを行わずに提案を却下できるという立場を示している。

LinuxカーネルのAIコーディング支援に関する文書では、バグの発見から修正までの作業について、さらに具体的な手順を定めている。自明ではないバグについては再現を試み、修正を作成したうえで、ビルドと動作検証を行うことを求める。また、実施できなかったテストや、用意できなかった再現手順がある場合は、その事実を明示しなければならない。AIがコードを生成した場合でも、内容を検証し、変更提案の責任を負うのは人間であるという原則が貫かれている。

もっとも、これらはLinuxカーネル独自の指針であり、すべてのOSSプロジェクトに適用される共通ルールではない。それでも、AIの利用そのものを認めるかどうかだけでなく、メンテナーが採用の可否を判断するために必要な情報を、投稿者にあらかじめ提出させるという方向性は参考になる。今回のLinux Foundationの調査は、こうしたルールを導入すれば実際にレビュー負担が減るという因果関係まで実証したものではない。今後は、AI利用の開示や投稿前のテストを求めることで、レビューの手戻りやメンテナーの作業時間がどの程度減るのかを検証する必要がある。生成AIによって個人が節約した時間をOSS開発全体の生産性向上につなげられるかは、コードを生成する効率だけでなく、その品質を誰が、どの段階で保証するのかという運用ルールにかかっている。