AI時代におけるオープンソース・メンターシップの再考
GitHubブログは、AI生成コードの急増によるオープンソースコミュニティのメンター負荷増大と「エターナル・セプテンバー」化を指摘し、信頼回復のためのプラットフォーム改善とメンタリング戦略の再定義を呼びかけている。
キーポイント
AIによる作成コスト低下とレビューコストの非対称性
LLMによりコード生成が容易になった一方、レビューや保守のコストは下がっておらず、メンテナーの負担が非対称に増大している。
伝統的な貢献シグナルの信頼喪失と「エターナル・セプテンバー」現象
クリーンなコードや迅速な対応はAIが瞬時に生成可能になり、貢献者の真のコミットメントやコード理解度を測る指標として機能しなくなっている。
メンタリングの乗数効果維持とメンテナー燃え尽き危機
適切なメンタリングはコミュニティの成長を指数関数的に拡大させるが、無差別なPR対応によりメンテナーが消耗し、この乗数効果が失われる懸念がある。
プラットフォーム側の新規機能とコミュニティ評価基準の見直し
GitHubはRFCを公開して長期的な解決策を模索中だが、当面はメンテナー側が貢献者の学習意欲を見極める新しいメンタリング戦略が必要となる。
戦略的メンターシップの「3Cs」フレームワーク
寄与シグナルが読み取りにくいAI時代において、メンテナーは「理解度(Comprehension)」「文脈(Context)」「継続性(Continuity)」の3つのフィルターを用いて、メンターシップ投資の対象を戦略的に選別している。
AI活用開示によるレビューの最適化
コントリビューターがAI使用を開示することで、レビュアーはコードの動作確認だけでなく、トレードオフやコントリビューターの理解度に焦点を当てたレビュー調整が可能になる。
継続性に基づくメンターシップの段階的拡大
一時的な寄与ではなく継続的に関わるコントリビューターに対して、最初のPRを教訓の場とし、段階的にペアプログラミングや難易度の高いタスク、最終的にはコミット権限へとメンターシップをスケールアップさせる。
影響分析・編集コメントを表示
影響分析
本記事は、生成AIがオープンソース開発の社会構造に与える構造的変化を明確に可視化した。メンテナーのリソース枯渇を防ぐためには、単なるツール導入ではなく、貢献者の意図を評価する新しい指標とプラットフォーム側のフィルタリング機能の両立が不可欠となる。これにより、コミュニティの持続可能な成長モデルへの転換が加速する可能性がある。
編集コメント
AIコード生成の普及はオープンソースの「人間関係インフラ」を再構築する契機となる。プラットフォーム側がフィルタリングを強化しつつ、メンテナー側が貢献者の学習意欲を見極める新しい評価軸を確立することが、コミュニティ存続の鍵となる。
あなたに情景を描きましょう。
洗練されたプルリクエストがあなたの受信トレイに届きます。一見すると素晴らしいように見えますが、詳しく見てみると、いくつかの点におかしいと感じるものがあります。45 分後には、あなたは考え抜かれた励ましの返信を数件の明確化のための質問と共に作成しています。もしかしたら、この人はメンターとして素晴らしい新参者になるかもしれませんし、彼らが時間を投資してくれるなら、あなたの時間を使う価値があるかもしれません。
そして…何も起こりません。あるいは、フォローアップを通じて、貢献者が変更を説明するために必要な文脈を持っていないことが明らかになります。多くの場合、それは AI が、メンテナンスする準備が整う前に、妥当に見えるものを提出することを容易にしたからです。あるいは、あなたが午後の時間を誰かの LLM チャットセッションのデバッグに費やしてしまったことに気づきます。
これはより一般的になりつつあります。貢献者が悪意を持って行動しているからではなく、妥当に見えるものを生成することがこれほど簡単になったことがないからです。作成にかかるコストは低下しました。しかし、レビューにかかるコストは下がっていません。
オープンソースは独自の「永遠の 9 月」を経験しています：信頼を築き、新参者を指導するために依存する社会的システムに負担をかける、絶え間ない貢献の流入です。
シグナルが変わった
エコシステム全体のプロジェクトが同じ現象を目撃しています。tldraw はプルリクエストをクローズしました。Fastify は、スケールにおいてインバウンドレポートが管理不能になったため、HackerOne プログラムを停止しました。
全体の量は上昇し続けています。Octoverse 2025 のレポートによると、開発者は 2025 年に月間約 4,500 万件のプルリクエストをマージしており（前年比 23% 増）、プルリクエスト数は増加しているものの、メンテナの作業時間は同じです。
クリーンなコード、迅速な対応、複雑さへの対処といった従来のシグナルは、かつて誰かがコードベースを理解するために時間を投資したことを意味していました。しかし現在では AI がこれらの要素を数秒で生成できるようになったため、これらのシグナルは以前ほど明確な指標ではなくなっています。
ノイズを減らし、オープンソースの貢献に対する信頼を取り戻すために、GitHub を含むプラットフォームが中長期的な解決策を構築しています。実際、私たちのプロダクトチームはコミュニティからのフィードバックを求める RFC（提案書）を公開しました。私たちが何ができるかについてご意見があれば、ぜひお聞かせください。
ただし、プラットフォームの変更には時間がかかります。また、変更が実現したとしても、シグナルが以前ほど読み取りやすくない状況下でメンタリングがどのように見えるかを判断するための戦略は依然として必要です。ここでは現在機能しているアプローチをご紹介します。
なぜこれが緊急課題なのか
メンタリングこそが、オープンソースコミュニティをスケールさせる鍵です。
もし私がオープンソースの貢献者たちを集めた部屋で「どうやって始めたのか」と尋ねたら、全員が「良いメンターとの出会いから始まった」と答えるでしょう。
誰かを適切にメンタリングすることは、単に貢献者を一人増やすことではありません。自分自身を倍増させることです。彼らは同じように他者をオンボーディングする方法を学びます。これが乗数効果です。
YearBroadcast (年 1,000 件)Mentorship (6 ヶ月に 2 人、彼らも同様に)
11,0009
33,000729
55,00059,049
しかし、メンテナーたちはすべてのプルリクエストを送ってくる人々を指導しようとして燃え尽きています。新規参画者への指導を放棄すれば、乗数効果そのものを失うことになります。
指導を放棄することはできません。特に多くの長年のメンテナーが積極的な貢献から身を引く中ではなおさらです（この世代間の課題については、『将来のメンテナーは誰か？』で詳しく書きました）。したがって、誰に投資するかについて戦略的である必要があります。
3 つの C：大規模な戦略的指導のためのフレームワーク
寄与のシグナルが読み取りにくくなった中で、どこに指導のエネルギーを注ぐべきかをどう決定すればよいのでしょうか。プロジェクト全体で何が機能しているかを見てみると、メンテナーたちが使用している 3 つのフィルターがあることがわかります。私はこれを「3 つの C（Comprehension, Context, Continuity）」と呼んでいます。
- Comprehension（理解度）
彼らはこの変更を提案するに十分なほど問題を理解していますか？
いくつかのプロジェクトでは、コード提出前に理解度をテストするようになりました。例えば Codex や Gemini CLI では最近、ガイドラインを追加しました：コントリビューターはまずイシューを開き、プルリクエストを送る前に承認を得る必要があります。この理解度のチェックはその会話の中で行われます。
また、この分野では対面でのコードスプリントやハッカソンが盛んに行われており、メンテナーが潜在的なコントリビューターとリアルタイムで会話を交わして、関心と理解度の両方を確認できる場となっています。
私はコントリビューターにプロジェクト全体を理解することを期待しているわけではありません。それは非現実的です。しかし、彼らが自分の理解度を超えたコードを提出しないようにすることは確かめる必要があります。成長するにつれて、より多くの責任を引き受けることができるようになります。
- Context（文脈）
彼らは私がこれを適切にレビューするために必要なものを提供してくれているでしょうか？
理解度は、彼らの理解に関するものです。文脈は、レビュアーとしてあなたの職務を遂行する能力に関するものです。
彼らは関連するイシューへのリンクを貼りましたか？トレードオフについて説明しましたか？AI の使用を開示しましたか？
最後の項目はますます一般的になっています。ROOST はシンプルな 3 つの原則からなるポリシーを持っています。Processing Foundation はチェックボックスを追加しました。Fedora も数ヶ月にわたる議論の後、軽量な開示ポリシーを導入しました。
AI の使用を開示することは、レビュアーに文脈を提供することです。プルリクエストが AI の支援を受けて作成されたことを知っていれば、レビューの調整を行うことができます。これには、より明確化のための質問をしたり、コードが動作するかどうかだけでなく、貢献者がトレードオフを理解しているかに焦点を当てたりすることが含まれるかもしれません。
また、Copilot 向けの robots.txt に相当するものとして、AI コーディングエージェント（AGENTS）に指示を提供する AGENTS.md もあります。scikit-learn、Goose、Processing などのプロジェクトでは、AGENTS.md を使用して、ガイドラインの遵守やイシューの割り当て確認、組織の規範への尊重など、エージェントに対する指示を伝達しています。これにより、レビューに必要な文脈を集める負担を、貢献者（またはそのツール）側に負わせることができます。
- 継続性
彼らは再び戻ってきますか？
これはメンターシップのフィルターです。
一時的な貢献は有益である場合もありますが、あなたのメンターシップへの投資は、繰り返し戻ってきて思慮深く関与する人々に限定すべきです。
あなたのメンターシップは時間とともに拡大できます：
プルリクエストでの素晴らしい最初の会話 → レビューを教訓的な瞬間にする
彼らは再び戻ってきます → 何か一緒にペアプログラミングするよう提案し、その後より難しいタスクを勧め始めます
それでも再び戻ってくる場合 → イベントに招待するか、コミット権限を検討してください
教訓
理解と文脈がレビューにつながります。継続性がメンターシップにつながります。
メンテナーとしてこれは、これら 3 つすべてを確認するまで、深いメンターシップのエネルギーを投資しないことを意味します。
具体的な様子:
PR が着く → ガイドラインに従ったか？
いいえ → 却下。罪悪感なし。
はい → レビュー → 彼らは戻ってくるか？
はい → メンターシップを検討する
これは上記の最初の例と比較してみましょう。今回は、ガイドラインに従わずに完成されたプルリクエストが着きます。却下してください。罪悪感はありません。重要な貢献のためにあなたの時間を保護しましょう。
誰かが戻ってきてイシューに関与し、2 回目のプルリクエストを提出してフィードバックに慎重に対応する場合、今こそ注意を払う時です。それが投資するタイミングです。
これが乗数効果を保護する方法です。あなたは新規参画者を放棄しているのではありません。戦略的に行動しているのです。
もう一つの利点もあります：明確な基準はバイアスを減らします。雰囲気や勘に頼ると、自分と似ている人々や同じ文化的文脈を共有する人々にメンターシップを提供しがちです。3 つの C は直感ではなく評価基準を与え、それによりあなたのメンターシップがより公平になります。
始め方
実装する C を 1 つ選びます:
C 実装
理解 プルリクエスト前にイシューを要求
対面でのコードスプリントを開催してライブディスカッションを行う
コンテキスト：AI の開示または AGENTS.md の追加
継続性：誰が戻ってくるかを見守る
メンターを選ぶ際は、まず 1 つから始めつつ、最終的には 3 つすべてを確認する。
これは AI を活用した貢献を制限するためのものではない。人間のメンタリングを守り、コミュニティを健全に保つためのガードレールを構築するためのものだ。
AI ツールは定着するだろう。重要なのは、オープンソースが機能する本質である「人間関係」「知識の伝達」「乗数効果」を維持するために、我々の実践を適応させられるかどうかだ。
3 つの C（The 3 Cs）は、まさにそのための枠組みを提供してくれる。
リソース
プラットフォームレベルの解決策のための GitHub RFC
OpenAI Codex の貢献ポリシー
Google Gemini CLI の貢献ポリシー
ROOST AI ポリシー
Fedora AI の貢献ポリシー
AGENTS.md の処理
scikit-learn のプルリクエストテンプレート
Goose HOWTOAI.md
FOSDEM 2026 の講演から改変。Anne Bertucio、Ashley Wolf、Daniel Stenberg、Tim Head、Bruno Borges、Emma Irwin、Helen Hou-Sandí、Hugo van Kemenade、Jamie Tanna、John McBride、Juan Luis Cano Rodríguez、Justin Wheeler、Matteo Collina、Camilla Moraes、Raphaël de Courville、Rizel Scarlett、そしてオンラインで事例を共有してくれたすべての人々に感謝する。
本記事「AI エラにおけるオープンソースメンタリングの再考」は、最初に The GitHub Blog に掲載されました。
原文を表示
Let me paint a picture for you.
A polished pull request lands in your inbox. It looks amazing at first glance, but then you start digging in, and a few things seem off. Forty-five minutes later, you’ve crafted a thoughtful, encouraging response with a few clarifying questions. Who knows: Maybe this person might be a great new person to mentor, so it’s worth your time if they put in theirs.
And then…nothing. Or the follow-up makes it clear the contributor doesn’t have the context needed to explain the change, often because AI made it easy to submit something plausible before they were ready to maintain it. Or you realize you’ve just spent your afternoon debugging someone’s LLM chat session.
This is becoming more common. Not because contributors are acting in bad faith, but because it’s never been easier to generate something that looks plausible. The cost to create has dropped. The cost to review hasn’t.
Open source is experiencing its own “Eternal September”: a constant influx of contributions that strains the social systems we rely on to build trust and mentor newcomers.
The signals have changed
Projects across the ecosystem are seeing this same occurrence. tldraw closed their pull requests. Fastify shut down their HackerOne program after inbound reports became unmanageable at scale.
The overall volume keeps climbing. The Octoverse 2025 report notes that developers merged nearly 45 million pull requests per month in 2025 (up 23% year over year). More pull requests, same maintainer hours.
The old signals, like clean code, fast turnaround, and handling complexity, used to mean someone had invested time into understanding the codebase. Now AI can help users generate all of that in seconds, so these signals aren’t as telling.
To reduce noise and bring more trust back into open source contributions, platforms, including GitHub, are building longer-term solutions. In fact, our product team just published an RFC for community feedback. If you have thoughts on what we can do, we’d love to hear from you.
But platform changes take time. And even when they arrive, you’ll still need strategies for figuring out how mentorship looks today when signals aren’t as easy to read. Here’s what’s working.
Why this is urgent
Mentorship is how open source communities scale.
If I asked a room of open source contributors how they got started, they’d all say it began with a good mentor.
When you mentor someone well, you’re not just adding one contributor. You’re multiplying yourself. They learn to onboard others who do the same. That’s the multiplier effect.
YearBroadcast (1,000/year)Mentorship (2 every 6 months, they do the same)
11,0009
33,000729
55,00059,049
But maintainers are burning out trying to mentor everyone who sends a pull request. If we lose mentoring newcomers, we lose the multiplier entirely.
We can’t abandon mentorship, especially as many long-time maintainers step back from active contribution. (I wrote more about this generational challenge in Who will maintain the future?) So, we need to be strategic about who we invest in.
The 3 Cs: A framework for strategic mentorship at scale
So how do you decide where to invest your mentorship energy when contribution signals are harder to read? Looking at what’s working across projects, I see three filters maintainers are using. I call them the 3 Cs: Comprehension, Context, and Continuity.
- Comprehension
Do they understand the problem well enough to propose this change?
Some projects now test comprehension before code is submitted. Codex and Gemini CLI, for example, both recently added guidelines: contributors must open an issue and get approval before submitting a pull request. The comprehension check happens in that conversation.
I’m also seeing in-person code sprints and hackathons thriving in this area, where maintainers can have real-time conversations with potential contributors to check both interest and comprehension.
I’m not expecting contributors to understand the whole project. That’s unrealistic. But you want to make sure they’re not committing code above their own comprehension level. As they grow, they can always take on more.
- Context
Do they give me what I need to review this well?
Comprehension is about their understanding. Context is about your ability to do your job as a reviewer.
Did they link to the issue? Explain trade-offs? Disclose AI use?
The last one is becoming more common. ROOST has a simple three-principle policy. The Processing Foundation added a checkbox. Fedora landed a lightweight disclosure policy after months of discussion.
Disclosing AI is about giving reviewers context. When I know a pull request was AI-assisted, I can calibrate my review. This might mean asking more clarifying questions or focusing on whether the contributor understands the trade-offs, not just whether the code runs.
There’s also AGENTS.md, which provides instructions for AI coding agents, like robots.txt for Copilot. Projects like scikit-learn, Goose, and Processing use AGENTS.md to tell agents instructions, like follow our guidelines, check if an issue is assigned, or respect our norms. This can help to place the burden of gathering the context needed for a review to the contributor (or their tools).
- Continuity
Do they keep coming back?
This is the mentorship filter.
Drive-by contributions can be helpful but limit your mentorship investment to people who come back and engage thoughtfully.
Your mentorship can scale up over time:
Great first conversation in a pull request → make your review a teachable moment
They keep coming back → offer to pair on something, then start suggesting harder tasks
If they still keep coming back → invite them to an event, or consider commit access
The takeaway
Comprehension and Context get you reviewed. Continuity gets you mentored.
As a maintainer, this means: don’t invest deep mentorship energy until you see all three.
What this looks like:
PR Lands → Follows Guidelines?
NO → Close. Guilt-free.
YES → Review → They Come Back?
YES → Consider Mentorship
Let’s compare this to our first example above. This time, a polished pull requests lands without following the guidelines. Close it. Guilt-free. Protect your time for contributions that matter.
If someone comes back and is engaged in issues; if they submit a second pull request and respond thoughtfully to feedback, now you pay attention. That’s when you invest.
This is how you protect the multiplier effect. You’re not abandoning newcomers. You’re being strategic.
There’s another benefit too: clear criteria reduces bias. When you rely on vibes, you tend to mentor people who look like you or share your cultural context. The 3 Cs give you a rubric instead of gut feelings, and that makes your mentorship more equitable.
Getting started
Pick a C to implement:
CImplementation
ComprehensionRequire issue before pull request
Host an in-person code sprint for live discussions
ContextAdd AI disclosure or AGENTS.md
ContinuityWatch who comes back
Start with one but look for all three when deciding who to mentor.
This isn’t about restricting AI-assisted contributions. It’s about building guardrails that protect human mentorship and keep communities healthy.
AI tools are here to stay. The question is whether we adapt our practices to maintain what makes open source work: human relationships, knowledge transfer, and the multiplier effect.
The 3 Cs give us a framework for exactly that.
Resources
GitHub RFC for platform-level solutions
OpenAI Codex contribution policy
Google Gemini CLI contribution policy
ROOST AI policy
Fedora AI contribution policy
Processing AGENTS.md
scikit-learn pull request template
Goose HOWTOAI.md
Adapted from my FOSDEM 2026 talk. Thanks to Anne Bertucio, Ashley Wolf, Daniel Stenberg, Tim Head, Bruno Borges, Emma Irwin, Helen Hou-Sandí, Hugo van Kemenade, Jamie Tanna, John McBride, Juan Luis Cano Rodríguez, Justin Wheeler, Matteo Collina, Camilla Moraes, Raphaël de Courville, Rizel Scarlett, and everyone who shared examples online.
The post Rethinking open source mentorship in the AI era appeared first on The GitHub Blog.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み