5つのRustチームがLLMルールを採用して人間によるコードレビューを保護

Why it matters

Rust is confronting the central constraint of AI-assisted software development: models can produce code faster than experienced maintainers can judge, explain and support it.

Five Rust teams have adopted an LLM contribution policy written by Jynn Nelson, a longtime Rust maintainer and compiler team lead at Ferrous Systems, giving reviewers explicit rules for handling AI-generated code and text in the rust-lang/rust monorepo.

コンパイラ、ライブラリ、types、rustdoc、bootstrap の各チームとそのサブチームは、最近その規則を承認したと、NelsonはInside Rustの投稿（8月5日公開）で書いている。この方針は Rust プロジェクト全体を統治するものではない。language や edition を含むチームは引き続き独自の運用を決める自由があり、メインの Rust モノレポ以外のリポジトリはその範囲外となる。

Nelsonは、技術的決定とコントリビュータガバナンスが衝突する Rust の部分に長年携わってきた。履歴書には rustdoc と docs.rs のリード、Rust の bootstrap チーム創設、メンテイナの採用、rustdoc のコンパイル時間を9分の1に短縮したことが記されている。Ferrous Systems に加わる前の2025年9月までは、YottaDB、TCDI、Redjack、Cloudflare でコンパイラ、データベース、ネットワークインフラに取り組んでいた。

その経歴は、AI に関する広範な判断よりもメンテナンス性に焦点を当てた方針を形作った。Nelson の懸念は、生成された出力がオープンソースのレビュアーがかつて時間を投資する先を決めるために使っていたシグナルを弱めているという点にある。磨き上げられたプルリクエストは、志望メンテイナによる数日の慎重な作業を表しているかもしれないが、マージ後に提出者が説明・修正・サポートできない出力である可能性もある。

Nelson's governance fix

公開発表は8月5日だったが、この方針は数か月をかけて作られた。Rust Forge の提案は4月17日にオープンし、広範な私的および公開の議論を経ている。議論の記録によれば、それに先立つ Rust Zulip の会話だけで3,000件を超えるメッセージが生成されており、その後の GitHub 上の議論は含まれていない。

Nelson はこの作業を、執行が一貫していないことへの対応として位置付けた。Rust のレビュアーはすでに多数の LLM 支援によるプルリクエストに遭遇しており、初参加のコントリビュータがリスクの高いコンパイラ最適化を提案しているケースもあった。モデレーター側には共通の開示ルールがなく、レビュアーが作業をクローズした後に初めて期待値を知ることになっていた。

公開された LLM 利用ポリシーは、双方に文書化された基準を与える。作業上の要約は簡潔だ：「LLM を使って質問に答えたり、分析したり、要約したり、洗練したり、チェックしたり、提案したり、レビューしたりするのは構わない。しかし、作り出すことはダメだ。」

私的な AI 支援は一般に許容される。コントリビュータはモデルにコードベースについて質問したり、議論を個人的に要約したり、自分の作業を非公開でレビューしたり、自分の解決策を書く前に可能なアプローチを生成したりできる。ルールはまた、人間が結果を検証し、バグを報告する際にモデルの関与を開示することを条件に、LLM を使ってバグを見つけることを許可している。

公開される成果物にはより厳しい制限が課される。コントリビュータは、LLM によって最初に作成されたコメント、Issue 本文、プルリクエストの説明、ドキュメント、コンパイラの診断、あるいは重要なソースコメントを自分自身の文章として提出することはできない。明確に引用が示されている場合は、周囲の寄与が独立して成立しているときに限り許可される。機械翻訳、些細な編集、AI 支援のレビューは開示を条件に条件付きで許可される。

この区別はコントリビュータに責任を負わせる。モデルは誰かの思考や検査、翻訳を助けるかもしれないが、人間はそれでも議論を組み立て、変更を理解し、レビュアーに対して説明責任を負わなければならない。

AI-generated code gets an experimental lane

Rust の規則は生成コードを禁止するところまでは踏み込まない。通常のコントリビューションプロセスより高い参加基準を設けた管理された実験枠を作っている。

LLM によって作成された変更は、プルリクエストを開く前に同意するレビュアーと調整されていなければならない。サウンドネスに関わる領域を避け、コードベースの品質基準を満たし、テストを含み、作成者とレビュアーの双方が理解していることが必要だ。新しいコントリビュータがまず生成コードを提出してからレビュアーを探すことはできない。

受け入れられた提出物には ai-assisted ラベルが付けられ、Rust 組織のメンバーがアクセスできるプライベートな Zulip チャンネルに投稿される。そのチャンネルは、コントリビュータが学んでいるか、さらなる作業で戻ってきているか、メンテナンスに値する変更を生み出しているかどうかの証拠を集めることを意図している。レビュアーは AI 支援のプルリクエストを拒否することができ、LLM によるレビューが人間の承認や作成者自身のレビューの代替になることはない。

方針には数値によるサーキットブレーカーも含まれる。LLM によって作成された変更がローリングの6週間期間にマージされたすべてのプルリクエストのうち50%を超えた場合、Rust はその割合が閾値を下回るまでさらに AI 生成物のマージを停止する。クールダウンは少なくとも10日間続く。

その制限は意図的に保守的に設定されており、実際には理論上のものにとどまるかもしれない。これは Rust の根本的な優先順位を明確にする：生成された提出物がコードベースを食いつぶしたり、参加のために AI ツールが事実上の必須条件になったりすることは許されない、ということだ。

The scarce resource is reviewer judgment

Nelson は発表時点で rust-lang/rust に1,281件のオープンなプルリクエストがあると報告した。この数字はスナップショットにすぎないが、方針を駆動する非対称性を捉えている。AI システムはコードの供給を、オープンソースプロジェクトがアーキテクチャ上の選択、長期的な保守コスト、安全性への影響を評価できる経験豊富な人材を採用する速度よりもはるかに速く増やし得る。

コンパイラのレビュー作業は、たいていの場合、単に不具合のある行を特定することだけで終わらない。メンテイナは、提案された方針が Rust にふさわしいかどうか、それが他のコンパイラコンポーネントとどう相互作用するか、数か月後に誰がその変更を理解できるかを判断しなければならない。生成コードはもっともらしい実装を提示するコストを下げるが、そうした判断を下すコストは下げない。

方針は、より差し迫った協力関係の崩壊にも対処している：レビュアーのコメントをコントリビュータが LLM に入力し、その応答を貼り付けて GitHub に戻すという行為だ。Nelson は、レビュアーが求めているのは作成者の論拠だと主張する。機械生成の応答は、メンテイナに対してパッチを理解している人物とやり取りしているのか、それとも単にレビュアーとモデルの間のメッセージを中継しているだけなのかを不確かにさせる。

Rust の答えは、貢献権を人間の理解に結び付けることだ。方針はレビュアーにスタイルから AI が書いたコードを検出することを求めておらず、疑いに基づく公の非難を行わないよう警告している。作成者は使用を開示しなければならない。疑わしい不誠実さはプルリクエスト内での議論ではなく、モデレーションを通じて扱われる。

A local compromise, for now

この限定的な適用範囲は、Rust が意思決定を行う方法を反映している。プロジェクトは責任と AI に関する見解が異なるチーム間の合意を通じて運営されている。Nelson は、一部のコントリビュータはこれらのツールに実益を見いだしている一方で、技術的・社会的・環境的コストを理由に反対する者もいると書いている。採用された方針は、専門知識、包摂性、レビュアーの能力に関する共有の懸念から出発している。

プロジェクト全体の答えはまだ定まっていない。7月14日のプログラム管理アップデートは、Rust の Leadership Council が、より広範なルールを書き直したり改訂したりできる LLM 委員会を議論していると述べている。提案では、プロジェクト内の異なる見解を代表する4〜5名のメンバーを求めていた。

そのガバナンス作業が進むまでは、Nelson の方針が Rust の中央リポジトリで最も忙しい部分に対する実務的な運用モデルを提供する。実験の余地を残しつつ、生成された作業が限られたレビュアーの注意を受けるに足ることを提出者自身が証明するコストを負わせる。このトレードオフは、コード生成が安くなり、メンテナンス性が頑固に人間に依存し続けるにつれて、オープンソース全体で馴染み深いものになる可能性が高い。