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）」と呼んでいます。 1. Comprehension（理解度） 彼らはこの変更を提案するに十分なほど問題を理解していますか？ いくつかのプロジェクトでは、コード提出前に理解度をテストするようになりました。例えば Codex や Gemini CLI では最近、ガイドラインを追加しました：コントリビューターはまずイシューを開き、プルリクエストを送る前に承認を得る必要があります。この理解度のチェックはその会話の中で行われます。 また、この分野では対面でのコードスプリントやハッカソンが盛んに行われており、メンテナーが潜在的なコントリビューターとリアルタイムで会話を交わして、関心と理解度の両方を確認できる場となっています。 私はコントリビューターにプロジェクト全体を理解することを期待しているわけではありません。それは非現実的です。しかし、彼らが自分の理解度を超えたコードを提出しないようにすることは確かめる必要があります。成長するにつれて、より多くの責任を引き受けることができるようになります。 2. Context（文脈） 彼らは私がこれを適切にレビューするために必要なものを提供してくれているでしょうか？ 理解度は、彼らの理解に関するものです。文脈は、レビュアーとしてあなたの職務を遂行する能力に関するものです。 彼らは関連するイシューへのリンクを貼りましたか？トレードオフについて説明しましたか？AI の使用を開示しましたか？ 最後の項目はますます一般的になっています。ROOST はシンプルな 3 つの原則からなるポリシーを持っています。Processing Foundation はチェックボックスを追加しました。Fedora も数ヶ月にわたる議論の後、軽量な開示ポリシーを導入しました。 AI の使用を開示することは、レビュアーに文脈を提供することです。プルリクエストが AI の支援を受けて作成されたことを知っていれば、レビューの調整を行うことができます。これには、より明確化のための質問をしたり、コードが動作するかどうかだけでなく、貢献者がトレードオフを理解しているかに焦点を当てたりすることが含まれるかもしれません。 また、Copilot 向けの robots.txt に相当するものとして、AI コーディングエージェント（AGENTS）に指示を提供する AGENTS.md もあります。scikit-learn、Goose、Processing などのプロジェクトでは、AGENTS.md を使用して、ガイドラインの遵守やイシューの割り当て確認、組織の規範への尊重など、エージェントに対する指示を伝達しています。これにより、レビューに必要な文脈を集める負担を、貢献者（またはそのツール）側に負わせることができます。 3. 継続性 彼らは再び戻ってきますか？ これはメンターシップのフィルターです。 一時的な貢献は有益である場合もありますが、あなたのメンターシップへの投資は、繰り返し戻ってきて思慮深く関与する人々に限定すべきです。 あなたのメンターシップは時間とともに拡大できます： プルリクエストでの素晴らしい最初の会話 → レビューを教訓的な瞬間にする 彼らは再び戻ってきます → 何か一緒にペアプログラミングするよう提案し、その後より難しいタスクを勧め始めます それでも再び戻ってくる場合 → イベントに招待するか、コミット権限を検討してください 教訓 理解と文脈がレビューにつながります。継続性がメンターシップにつながります。 メンテナーとしてこれは、これら 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 に掲載されました。

AI時代におけるオープンソース・メンターシップの再考

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト