# Rethinking Open Source Contribution in the Age of AI Agents > [!info] Talk metadata > - **会議:** [[MLSys2026]] Day 2 (May 18 / Mon)、Grand Ballroom 1、09:00 - 09:25 PDT > - **登壇者:** Roger Wang（vLLM コアメンテナ） > - **URL:** https://mlsys.org/virtual/2026/invited-talk/10000 - **主張:** 人間のコントリビューターのレバレッジは「コードを書くこと」から、システムの理解・正しい問題選び・本番に出すものへのオーナーシップへと移った。AI エージェントを敵視せず、現代の開発に不可欠な存在として認めたうえで、人間がどこで本当の価値を出せるかを論じる。 ## 背景 — AI 生成 PR の急増 - Roger は別途 echo エンジンでネット上の動向を要約させており、vLLM の PR 推移を提示。直近半年で AI 生成 PR が急増（ほぼ毎週スパイク）。Opus 4.1 リリース（および Claude Code とおぼしきツール ※音声不鮮明）を起点にトレンドが立ち上がり、4.5 を経て今年は AI 由来コントリビューションが大量（約 16 件と言及）に。 - vLLM だけの問題ではなく、他の人気 ML システム系プロジェクト（具体名は音声不鮮明）も 2026 年初頭にこぞって同じ状況に直面した。 - 他メンテナの見解として Noa Yang（あるプロジェクトのコアメンテナ。所属は音声不鮮明で PyTorch 系の可能性）のブログ「Code review in the era of LLMs」を紹介。3 つの論点 = ①コントリビューションに注意を払いモチベーションを保つ、②ラウンドトリップを減らし直接的に接する、③CI が一度落ちても再挑戦の機会を与える。Roger は概ね同意しつつ「やや理想論」と評し、自分はコントリビューターにもっと負荷（challenge）をかける立場。 ## なぜ PR が close / reject されるのか — 典型的な失敗パターン - **① ローカルでは正しいが全体設計を見落とす:** 2 つの機能を互換にするための場当たり的なハックなど。手元の 2 機能では動いてもシステム全体の整合性を壊す。全体理解の欠如が原因。 - **② 根本原因を直さず症状を覆い隠す（bounty 狩り）:** バグ報告に 10 分で「やります」と飛びつき、エラートレースを Claude/Codex に投げて最小パッチを生成。エラーを消すだけで root cause を追わず、ハックを通すためにテストを 10 個でっち上げる。本当の問題が隠れ CI に引っかかり、本人も興味がないため PR が数週間放置される。 - **③ AI コードエージェントによる増幅:** Web ベースの自動 PR がコアコンポーネント全体に触れる。実例: バイラルになった機能で同日に 5 本の AI 生成 PR。メンテナが問い合わせると 2 名は応答し共同で仕上げた（"co-TC" と発言＝共同貢献者/メンテナ化と思われる）、残り 2 名は無応答（ボット同然）で close。マージできた 1 本も大型 PR で往復が多く、AI 生成ゆえ作者が想定外のエッジケースを理解できず、他者のバグ報告も重なり 2 週間・約 300 コメントを要した。最初から小さく分割すべきだった。 ## コントリビューター側がどうすべきだったか - **システムをまず理解する:** いきなり変更せず読む。AI はコード読解・コンポーネント間の連携理解の補助に最も強い。 - **正しい問題を正しい粒度で選ぶ:** AI に丸ごと機能生成させるのではなく、小さな問題から AI 補助で少しずつシステムを理解する。 - **独立したコミュニケーションを持つ:** 非同期の PR コメントは思考交換に向かない。興味があれば直接（オフライン/他チャネル）連絡し、善意を示す。 - **自分の仕事にオーナーシップと責任を持つ:** 機能/PR を出して消える（学生・研究者にありがち）のはアンチパターン。後続の課題に答え続ける人を求める。 ## 新規コントリビューターが信頼を得るには - 実装を出してからレビュー依頼するのではなく、アイデア・ベンチマーク・トレースを先に共有し方向性をすり合わせる。合意できればコードレビューはエージェントでも容易。 - 一つの領域を深掘りし、そのコンポーネントのオーナーになる。AI は表層的な小修正は得意だが設計上のトレードオフ理解に欠ける。 - 出した PR に居続け、コメント/課題に自分で対応する。オーナーシップ → メンテナとの信頼。 - 最重要: システム全体を考える。AI で自分のニッチな要求を満たす機能は作りやすいが、汎用プロダクトには不要。性能と信頼性を重視せよ。 ## メンテナ側がどうすべきか - バーを高く・ロードマップを明確に。コードが安価になった今、何でもマージせず fork を推奨する場面も（Triton 等、関心領域を明確に絞る例）。 - 追加（設計判断）をレビュー可能に。設計判断がコード/コミットに埋もれがち。ドキュメント/設計文書なしでは AI でも意図が読めない。透明性低下はコミュニティ自身の責任。 - CI と品質に投資。AI がコードを書く時代こそソフトウェア工学が重要。vLLM は本番運用されるため信頼性・バグフリーを重視し、機能より CI に投資。 - コントリビューターとの時間を増やす。PR レビューは AI の方が上手いので、人間は相手の意図理解・関係構築に時間を使う。直接連絡して関心と意図を把握する。 ## まとめ / Takeaway - コントリビューターの「ファネル」がリアルタイムで変化中。コード全体を読まずに PR を出せる新世代が登場し、従来の「育てて良い PR を出せるようにする」モデルは機能しない。 - 機会: メンテナにとってバーが上がり、重要なのは判断力・テイスト・オーナーシップ・システム理解、そしてコントリビューターとメンテナ間の信頼。vLLM に限らず重要インフラ系プロジェクト全般に当てはまる。 - 最終メッセージ: **PR で一番安いのはコードそのもの。** その周辺すべて（システム理解・信頼できる解決・成果のオーナーシップ）に注力すべき。これがメンテナとコントリビューターの信頼を育てる。 ## Q&A - Q: 多くの人間 PR を集めた人気プロジェクトから学べる教訓は? → 何でもエージェント PR をマージするプロジェクトは失敗例。鍵は "care"（仕事を尊重する姿勢）。ガイドライン/哲学として明示しないとプロジェクトはすぐにノイズだらけになる。 - Q: vLLM は Slack 等で活発に情報交換する動的コミュニティ。メンテナの主観的スキル/テイストの重要性が増す中、将来このコミュニティをどう成立させる? → 今は可能な限り自動化（例: メールは見ず、エージェントに要約させる）。重要な PR を見落とさないハーネス構築が大事。ただし全ては自動化しない。コントリビューターとメンテナの人間同士の対話に価値があり、一つのメッセージが大きな設計議論を生む。だから直接連絡を推奨する。 - Q: 高品質で急成長するプロジェクトの最大のボトルネックは? CI か、良いメンテナ/レビュー文化か? → 両側面。vLLM はこれが上手くできていなかった（何を作る/作らないの明確なバー設定が弱かった）。最優先目標でなければ見送り fork を推奨。また GPU 系は多数のハードウェア/モデルの組み合わせ検証が高コストで、バグなしを担保するのが非常に難しい。 - Q: コード品質はどう保つ? AI で大量かつ雑なコードが増える。設計が正しく機能が正しくてもコードが雑な場合、気にしない? → 品質は大いに気にする。だからこそ大型 PR を避け小さな PR の積み上げを好む。最初の小 PR でコントリビューターの厳密さ・設計テイストが見える。メンテナの基準に合わなければ reject する。これが品質コントロールの方法。