GitHubのOSPO責任者に訊いてみた。生成AI時代のOSSメインテナーの疲弊を防ぐ施策とは？

GitHubのオープンソースプログラムオフィス（OSPO）のディレクターであるAshley Wolf氏へのインタビューをお届けする。これはオープンソースのメインテナーに対する負担が、生成AIによる大量のプルリクエストのレビューによって疲弊してしまうというオープンソースコミュニティ特有の問題に対するGitHubの対策として、プルリクエストの量を制限する仕組みの発表に合わせて行われた。

Zoomで行われたインタビュー。右下がWolf氏だ

これはオープンソースのメインテナーを支援する「Maintainer Month」が2026年5月に設定されたことを受けて、GitHubとしてのオープンソースコミュニティに対するサポートを訴求するブログ記事に呼応して行われた。

●参考：Welcome to Maintainer Month: Celebrating the people behind the code

この記事の中では今回のインタビューに応えてくれたAshley Wolf氏が2月に「オープンソースの永遠の9月」が始まっているということを記した記事を紹介し、現在OSSコミュニティが直面している問題を整理している。この「永遠の9月」という記述を理解するには少し説明が必要だろう。アメリカでは大学の新学期は9月に始まる。そのため毎年9月は新入生が新しい学校に慣れるために在校生は慣れない新入生の行為に我慢をする必要があり、それがインターネットユーザーにおいても起こることから「9月はネットユーザーが急増して面倒なことを起こす月」となってしまった。それがオープンソースメインテナーにおいては「永遠に続く9月」という状態になってしまったのは、近年の生成AIによる大量のコード修正や機能追加のリクエストの急増が原因だ。

●Ashley Wolf氏のブログ記事：Welcome to the Eternal September of open source. Here's what we plan to do for maintainers.

「永遠の9月」に関しては以下のWikipediaのページを参照して欲しい。

●参考：https://en.wikipedia.org/wiki/Eternal_September

この生成AIによって製造される低品質なコードを指す言葉として、すでに「AI Slop」と呼ばれる単語が産まれているが、これはGitHubのケースではコミュニティの文脈を理解しないまま生成されるプルリクエストとなる。そのコードはそれを送る側にとってはプルリクエストを送ったという実績が残せるため価値があるが、実際にそのコードがコミュニティのためになっているのかを判断するのはレビューを行うメインテナーである。つまり生成する側のコストは低く価値は高いが、受け取る側のコストは高くレビューすることから得られる価値は変わらないというバランスが取れていない状況に陥っているわけだ。

これに対してGitHubは以下の施策を実施したと記載されている。

-Repo-level pull request controls:

これはリポジトリーのレベルでプルリクエストの数を制限する機能だ。これによってリポジトリーが受け取るプルリクエストを抑えメインテナーのレビューの負担を低くすることが可能になる。

-Pinned comments on issues:

イシューに対してコメントを固定する機能。

-Banners to reduce comment noise:

コメントノイズを減らすバナーを表示する機能。

-Pull request performance improvements:

プルリクストの差分表示を改善して高速化。大きなサイズのプルリクエストにおいては67％の高速化を実現。

-Faster issue navigation:

イシュ―をブラウズする機能を改善し、高速化。

-Temporary interaction limits:

特定のユーザーやリポジトリーに対するアクティビティを一時的に制限する機能を追加。

これらの施策では言ってみれば出血している傷口に対してバンドエイドを貼る対処療法でしかなく、究極的には「誰がプルリクエストを送ろうとしているのか？ その人物は信用に値するのか？」を確認するしかないだろう。しかしオープンソースプロジェクトは、どの企業に属しているのかに関わらず誰もが貢献するコードの品質によってのみ判断されるべきだという文化的な考え方がある。またコミュニティによっては新規のコントリビュータは初期のプルリクエストを生成AIで作ることを禁止するルールを設定するなどの抑止策を施しているが、どれも焼け石に水という状況だ。

またプロジェクトによっては新規に公開されたパッケージのリポジトリーを一定期間、公開せずに冷却期間を設定するというツールも開発されている。この例はRustのパッケージツールであるCargoを使ってパッケージを公開する際に、冷却期間を設けて未知の脆弱性が攻撃に利用されないように第3者が確認を行う時間を与えるというものだ。これにより、パッケージの中に悪意のあるコードを忍ばせることを防ぐことができる。これも生成AIによってソースコードが容易に生成できることに対する対処療法の一例だろう。

●参考：Announcing the crates.io Cooldown Proxy ? mitigating supply-chain attacks through delayed availability

ちなみにこのProxyは一般社団法人生活情報基盤研究機構が開発し、公開しているソフトウェアである。

こうした状況に対してGitHubのOSPOの責任者がどう応えるのかをインタビューの中で訊いた。

まず自己紹介をお願いします。

Wolf：私はGitHubで数年ほど勤務していますが、現在は社内向けOSPOの責任者でTODO Groupのステアリングコミッティーにも参加していました。社外との関わりとしてはオープンソースコミュニティの意見を聞くことでコントリビュータやメインテナーが何を考えているのか？ 困っていることはなにか？ をGitHubのプロダクトに反映することも継続しています。

今回はオープンソースコミュニティにおけるAI Slop問題を解決するためのGitHubの施策について補足していただけるということですが、プルリクエストの数を制限する機能や一時的にプルリクエストを止める方法などがすでに実施済みだそうですね。それについてのアップデートはありますか？

Wolf：そうですね。一時的にリポジトリーに対するアクティビティを抑止することについては永続的に設定する機能を追加しました。どれもレビューを行うメインテナーからの要望があった機能です。

AI Slopの問題は生成AIによるコーディングアシスタントが容易にコード生成を行えるということが起点となっていますが、レビューを実施するメインテナーをアシストする機能は将来的に公開されるんでしょうか？

Wolf：すでに我々のデベロッパー、彼はあるオープンソースプロジェクトのメインテナーなんですが、がメインテナーをアシストするAIエージェントを開発しています。まだ公開はされていませんが、GitHub Universeが開催される2026年10月にはもう少し詳しい内容を公開できると思います。

私があるオープンソースのメインテナーにインタビューした時にコントリビュータが増えることよりも実際にレビューを行うレビューワーが増えて欲しい、レビューワーはこれまでのリポジトリーにある議論、つまりイシューがどういう文脈で作られたのか、もしくは作られなかったのかを理解して欲しいというリクエストがありました。そのリポジトリーメインテナーのアシスタントがそのような機能を実装してくれることを祈ってます。

●参考：Kustomizeのリードに昇格したエンジニアが語るOSSへの参加を持続させるコツとは

最後にGitHubのOSPOの代表として何かアップデートはありますか？

Wolf：生成AIが広く使われるようになり、オープンソースの利用もさらに拡がっていることを感じています。同時に生成AI、エージェンティックAIと言った方がいいかもしれませんが、企業の現場でどう応用できるのか、それを運用していくには何が必要なのか？ といった課題についてOSPOのコミュニティとしても検討するチームが必要となったので、ワーキンググループを立ち上げています。これは「Agentic AI to Empower OSPOs Working Group」というそのものの名称で活動を始めています。これは実際にエージェンティックAIを企業の中で使う場合のベストパターンをドキュメントとして残して共有することで、AIの実装と運用に活かそうというものです。

随分と長い名前ですが、やりたいことをそのものズバリで表していると言えますね（笑）

対処療法ではあるものの、何もしないのではなくメインテナーが望む機能追加を着実に行っているGitHubの姿勢が感じられたインタビューとなった。より詳細な情報については、2026年10月末に行われるGitHub Universeで明らかになるのだろう。

●GitHub Universe公式サイト：https://githubuniverse.com/