Atsushi Nakatsugawa
March 01, 2026
|2 min read
March 01, 2026
2 min read
Share
Cut code review time & bugs by 50%
Most installed AI app on GitHub and GitLab
Free 14-day trial
AI is burning out the people who keep open source alive の意訳です。
ここ数か月、オープンソースコミュニティでは「AI slop（AIによる雑な成果物）」という言葉が繰り返し聞かれるようになっています。それは、普段は公に不満を言わないCEOたちによる LinkedInでの議論 にも現れています。
意訳） コーディングエージェントがOSSコミュニティを弱体化させ、チーム文化にも悪影響を与えています
私たちのオープンソースプラットフォームを作っているエンジニアリングチームと話す中で、よく出てくる嘆きがあります。バイブコーディング的な貢献によって、コミュニティの力学が大きく乱されているというものです。以前は、GitHubのIssueに「good first issue」と印を付ければ、意欲ある若いエンジニアが現れ、そのIssueで経験を積み、コミュニティのコントリビューターとして成長していました。それは私たちにとっても、彼らにとっても、そして何よりコミュニティにとって良いことでした。
ところが今では、「good first issue」を立てると、24時間も経たないうちに、低品質なバイブコーディングなslop（雑な成果物）で完全に埋め尽くされてしまい、本来の仕事に使うべき時間が奪われます。レビュー工程で「slopを品質の高いコードに変える」パターンは、生産性を落とし、士気も下げます。
エンジニアリングリーダーと話していても、多くの人が同じ現象が自分たちのチームでも起きていると感じています。コード量は増えていますが、エンジニアがAIで楽しい部分だけをやったあと、構造化されたレビューを通じてslopをプロダクションコードに仕上げる責任をチームに押し付ける形になり、緊張が高まっています。
私たち（エンジニアリングリーダー）が、AIエージェントをチームメンバーとして扱いたい（またはチームがエージェントをチームメンバーとして扱うことを許容したい）のであれば、チームに投資するのと同じように、そのエージェントにも投資する必要があります。コーディングアシスタントが、既存コードベースと整合する形で理解し貢献できるようにするために、必要なコンテキスト、ツール、スキルの開発・共有・運用徹底に時間を割かなければなりません。
皆さんの意見もぜひ伺いたいですし、私たちが「適切なコンテキスト、ツール、スキル」でコーディングエージェントを底上げするために取り組んでいることも共有したいです。DMで連絡してください。
また、Redditのスレッド でも、ここ数か月でAI slopが悪化していると感じるユーザーの声が見られます。
意訳）オープンソースはAI slopによってDDoSされており、GitHubがそれをさらに悪化させている
私はAI slop問題を注意深く追っていますが、改善するどころか悪化しているように見えます。
現状：
Daniel Stenberg（curl）は、AI生成によるバグレポートによってプロジェクトが「実質的にDDoSされている」と述べています。2025年の提出物の約20%がAI slopであり、一時は通常の8倍まで件数が急増しました。現在はバグバウンティプログラム自体を停止することも検討しています。
OCamlのメンテナーは、13,000行に及ぶAI生成PRを拒否しました。その理由は、AIコードのレビューは人間のコードよりも負荷が高く、低品質なPRが大量に送られることでPull Requestシステム全体が停止するリスクがあるためです。
Anthony Fu（Vueエコシステム）なども、「help wanted」のIssueをそのままAIエージェントに渡し、コードを理解しないままレビューコメントを反復するようなPRが大量に流入していると投稿しています。
GitHubは、CopilotをIssue/PR作成に統合することで状況をさらに悪化させています。しかも、Copilot由来の提出物をブロックしたり、どれがCopilotによるものか判別することすらできません。
さらに、人気OSSプロジェクトの Twitter投稿 では、外部コントリビューターからのPRを自動的にクローズする動きも出ています。
今週から、外部コントリビューターからのPull Requestを自動的にクローズします。これは本当に嫌ですが、申し訳ありません。
（投稿内の告知文）
皆さんへ。tldrawにおけるコントリビューション方針の更新です。
プロジェクトのために、外部コントリビューターからのPull Requestを自動的にクローズする運用を開始します。もちろん、Issue・バグレポート・議論は引き続き歓迎します。これは、GitHubがより良い管理ツールを提供するまでの一時的な方針です。
現状と対応
多くのオープンソースプロジェクトと同様に、最近、AIツールによって完全に生成されたコントリビューションが大幅に増加しています。形式的には正しく見えるPRもありますが、多くはコンテキスト不足、コードベースの理解不足、そして作者による十分な関与の欠如といった問題を抱えています。
Pull Requestを開くということは、メンテナー側がその変更を丁寧にレビューし、真剣に検討する責任を負うことを意味します。その約束を守り続けるために、今後はより選択的になる必要があります。そのため、いったんPRをクローズし、本当に検討対象となるものだけを選択的に再オープンする方針を取ります。基本的には、多くの依頼していない提出物はレビューされない前提になります。
奇妙な一年になりそうです
私は2021年にtldrawリポジトリを公開し、これまで多くの改善PRを受け入れてきたことを誇りに思っています。だからこそ、この決定は残念ですが、プロジェクト・コード・コミュニティにとって最善だと判断しました。うまくいけば、GitHubが状況改善のための管理機能を導入してくれるでしょう。
これは、プログラマーやオープンソースにとって奇妙な一年になりそうです。これまで貢献してくれた方も、これから貢献を考えている方も、あるいはプロジェクトを応援してくれている方も、状況が落ち着くまで少し見守っていてください。
ここで取り上げられているテーマは共通しています。AIが生成したPRが大量に流入し、マージはできそうに見えるものの、実際には機能しないケースが増えているということです。
一部のメンテナーはコントリビューションテンプレートを厳格化し、別のプロジェクトではPRを小さくするよう求めています。レビューキューを制御するために、新規コントリビューターを一時的に制限している例もあります。これは反AIの動きではありません。こうした懸念を示している人の多くは、自身もAIを利用しています。
人気AIエージェント OpenClaw の開発者であり、OpenAIに買収されたことで知られるPeter Steinbergerのような著名な人物でさえ、PRの増加に苦しんでいます。彼自身AIを積極的に使っているにもかかわらず、流入するコントリビューションのペースを管理するためのより良い解決策を 公に求めています。
OpenClawのPRが「あり得ない」ペースで増えています
昨日は一日中作業していましたが、約600コミットが追加されました。 以前は2700でしたが、今は3100を超えています。
すべてのPRとIssueをスキャンして、重複を排除してくれるAIが必要です。 さらに、さまざまなシグナルを使って、どのPRが妥当かを判定できる必要があります（つまり、実質的には深いレビューも必要です）。
理想的には、プロジェクトのビジョンドキュメントを基準に、方向性から外れたPRをマークまたは却下できる機能もほしいです。完全自動化は無理だとしても、補助してくれるだけでも助かります。
今のところ一番近いものは、あまり知られていないOSSプロジェクトです。 なぜこの領域に取り組んでいるスタートアップがないのでしょうか。
私はOSSプロジェクトのメンテナーとして、開発プロセスにAIを取り入れました。当初は理想的でした。開発スピードが上がり、修正が早く提出され、課題もより継続的に解決されるようになったからです。
以前は数か月かかっていた問題が、数時間で解決されることもありました。AIが人間の判断を補助する形で使われている限り、それは非常に有益でした。
しかし、完全自動エージェントへと重心が移るにつれて、重要な要素が失われつつあります。問題は構文ではなく、判断力です。
予想していなかったのは、PRレビューに費やす時間が急激に増えたことでした。これはコントリビューターの質が下がったからでも、AIが人を怠慢にしたからでもありません。単純に「コードを書くこと」が難しい部分ではなくなったのです。OSSでは、難しさそのものが自然なフィルターとして機能していました。
Stack Overflow Developer Survey のような調査では、多くの開発者（80%）がAIコーディングツールを利用中、または利用予定だとされています。実際、アクティブなリポジトリを見るだけでその変化は明らかです。
PRは以前より早く送れるようになり、平均的なサイズも大きく、単一プロンプトや短いやり取りから生成されたことが分かる形をしています。これは批判ではありません。私自身も毎日AIを使っており、以前のやり方に戻りたいとは思いません。
ただし、貢献コストが下がると当然起きることがあります。レビューは同じ速度で高速化されなかったのです。その結果、レビューはより認知的負荷の高い作業になりました。
例えば、5行の変更で済む問題に対して、新しい抽象化レイヤーが導入され、インターフェースやヘルパー、設定フラグまで追加されるPRを見たことがあります。技術的には動作していても、複雑性だけが増えているケースです。
表面的には問題がありません。テストは通り、CIもグリーンです。しかしレビュー担当者は、変更内容だけでなく「なぜこの設計なのか」「既存のアーキテクチャと矛盾していないか」まで理解する必要があります。
AIによって生成されたコードは、一見正しく見えることが多いです。フォーマットは整い、命名も妥当で、ロジックも意図的に見えます。それでも、どこか違和感があり、レビュー速度が落ちます。
次のような問いが出てきます。
なぜこの抽象化が必要なのか？
なぜこの関数は3つの責務を持っているのか？
なぜ技術的には動くのに、本番環境では脆く見えるのか？
よくある問題はエラーハンドリングです。あらゆる例外をcatchしてログに出力する実装は一見堅牢に見えますが、実際には重要な失敗を隠し、システム全体の前提を壊すことがあります。単体では正しくても、全体としては問題を生みます。
こうした問題を見抜くには、下流コンポーネントがどのように失敗を扱うかという暗黙知が必要です。これはドキュメントに書かれていないことが多く、Linterでは検出できません。
OSSには、過去のIssueに埋もれた設計判断や、暗黙的に共有されているだけの慣習が大量にあります。AIはそれを知らず、コントリビューターも知らないことが多いのです。そのギャップがレビューストレスの原因になっています。
OSSの持続性に関する研究では、ごく少数のコントリビューターがレビューの大半を担っている ことが示されています。つまり、少数の人に負荷が集中します。
メンテナーの燃え尽きはAI以前から存在していました。しかしAIによって、これまで管理可能だったバッファが取り除かれ、問題が可視化されました。PRは増え、明らかな誤りは減り、1件あたりのレビュー負荷は上がりました。
レビューは静かで遅い作業であり、スケールしません。レビュー能力を超えると、プロジェクトは突然壊れるのではなく、徐々に衰退します。レスポンスが遅れ、未解決Issueが増え、コントリビューターが離れていきます。
最近は、多くのプロジェクトが宣言しない形で、適応を始めています。自動チェックを強化し、PR説明の期待値を明確にし、メンテナーが見る前に変更を検証する流れが増えています。
レビューが前工程に移動しているのは、門番になりたいからではありません。人間の注意力が限られているからです。
AIがOSSを壊したのではありません。もともと存在していた問題を顕在化させただけです。コードを読むことは書くことより難しい、特にAIが書いた場合はなおさらです。
変化の本質は速度ではなく、量です。コードの生成は簡単になり、レビューは指数的に難しくなりました。
そこでAIコードレビューが意味を持ち始めます。人間が認知的負荷を使う前に動く、常時稼働のレビュアーとしてです。
私がOSSでCodeRabbitを使い始めたとき、次のような問題を即座に検出してくれました。
ページネーションのoff-by-oneエラー
外部呼び出しのエラーハンドリング不足
特定設定でのみ発生するエッジケース
リリース後に発見すると厄介なセキュリティ問題
さらに、形式的には動いているが防御的でないテスト不足も指摘されました。結果として、メンテナーが見る前にコードが整理されるようになりました。
その結果、人は以下のような「意図」に集中できるようになります。
プロジェクトの方向性に合っているか
長期的に妥当な抽象化か
トレードオフは適切か
AIは機械的な正しさを担当し、人間は戦略を担当できるのです。
PRの早期段階でフィードバックを自動化すると、レビューサイクルは短くなります。AIレビューが即座に返ると分かっている場合、コントリビューターは小さなPRを提出し、説明を明確にし、基本的な問題を先に修正するようになります。
私にとっての転機は、レビューが単なる便利機能ではなく「評判を守る仕組み」だと理解したことでした。AIがコードを書くなら、同じ厳密さでAIがレビューする必要があります。
これが、私がCodeRabbitに参加した理由です。レビュー品質、コードベース理解、IDE上でのローカルチェックなど、OSSで感じていたボトルネックを解決できました。AIによるコード生成が出力をスケールさせたなら、AIレビューは判断をスケールさせます。
OSSに必要だったのはAIを減らすことではなく、AIを正しく用いることでした。レビューを前倒しすることで、メンテナーは設計や方向性、本当に重要な作業に時間を使えるようになります。
OSSが崩壊する原因は悪いコードではありません。少数のメンテナーがすべてをレビューする状況です。
AIによってこの不均衡は悪化しました。修正やリファクタリングは数分で生成できますが、レビューは人間の速度のままです。その結果、通知は増え、キューは伸び、メンテナーは無償のトリアージを続けることになります。
燃え尽きは劇的ではありません。次のような形で現れます。
PRが何週間もレビューされない
時間不足で「won’t fix」が増える
深いレビューが減り、形だけの承認が増える
優秀なメンテナーが静かに離れる
これはツールの問題ではなく、注意力の問題です。
CodeRabbitは、疲れず急がない一次レビュアーとして機能します。PRを行単位でレビューし、ロジックエラー、エッジケース、セキュリティリスク、ファイル横断の影響を検出します。
メンテナーの作業は次のように変わります。
明らかなバグ探しではなく、設計判断に集中できる
要件漏れチェックではなく、高レベル判断に集中できる
小さな修正を抱え込まず、AIフィードバックで自己修正してもらえる
CodeRabbitはOSSを支援するために、100万ドルのスポンサーシップ を約束しています。CodeRabbitのAIはメンテナーを置き換えるものではなく、支援するためのツールです。反復的でミスしやすい部分をAIが吸収し、人間が重要な判断に集中できるようにします。
OSSは人々の貢献によって成立しています。AIによってコード量が増えるなら、レビュー側にも同等の支援が必要です。そうでなければ、負荷は少数のメンテナーに集中し続けます。
もしOSSプロジェクトを運営していてレビューキューが増え続けているなら、次のリポジトリで CodeRabbit を試してみてください。CodeRabbitはOSSでは無料です。メンテナー、コントリビューター、コミュニティは、PRノイズを減らし、コード品質チェックを自動化し、より意味のある貢献に対して時間を使いましょう。
