Rust、メインリポジトリに正式なLLMポリシーを採用

Rustプロジェクトの5つのチームは、大規模言語モデルの使用方法を定めた正式なポリシーを採用し、rust-lang/rust（プロジェクトの主要モノレポ）への貢献時に適用します。このポリシーは、ポリシーの作者であるJynn Nelsonが2026年8月5日にInside Rustブログで発表しました。（コンパイラ、libs、types、rustdoc、bootstrapチームが承認）このポリシーは、Nelsonが「未公開の “wild west” 的なモデレーション手法」と表現したものを、公開された文書化されたルールに置き換えるものです。

このポリシーはプロジェクト全体のAIに対する立場を示すものではなく、そうであることを明確にしています。適用範囲は rust-lang/rust リポジトリと、承認したチームに限られます。しかしその範囲内では、明確な境界線が引かれています。LLMは思考のためのツールとして歓迎されますが、思考の代替としては認められません。

ポリシーの実際の内容

文書は次の一文で要約されています：

質問への回答、分析、要約、洗練、チェック、提案、レビューに LLM を使用することは問題ありません。ただし 作成 することは禁じられています。

実務上はこの方針は3つの層に分かれます。無条件で許可：出力を見るのが貢献者本人だけであるプライベートな利用—コードベースに関する質問、スレッドの要約、自己のコードのプライベートレビュー。必ず開示が必要な許可：機械翻訳、誤字修正などの些細な変更、LLM 補助によるバグ発見、LLM レビューボット（別個の明示的にラベル付けされた GitHub アカウントから実行され、個々のユーザーがブロック可能）。禁止：LLM が作成したコメント、ドキュメント、コンパイラ診断、LLM の実行を必須とするプロセス、LLM レビューをマージやリジェクトの根拠とすること。

執行面で最も厳しいのは違反の取り扱いです。LLM の使用を意図的に偽ることは、プロジェクトの行動規範に違反したこととみなされ、ハラスメントと同等のレベルで警告、再犯時は禁止措置が科されます。文書は多くの条項が実務上は執行不可能であることを明示し、これは意図的であると述べています：「我々の目的はすべての違反を捕まえることではありません… 代わりに、曖昧な否認の余地を排除し、ポリシーに従うか、意図的に違反するかの選択を強いることです。」

LLM が書いたコードに対する限定的実験

LLM が生成したコードが全面的に禁止されているわけではありません。厳格な参加条件を設けた実験として位置付けられます：変更は事前に指名されたレビュアーと合意し、コンパイラの健全性に重大な影響を与えず、十分にテストされ、レビューを受け、かつ必ず開示されなければなりません。新規貢献者は、まずレビュアーの確保なしに LLM 作成のプルリクエストを開くことはできません。対象コードにテストスイートが存在しない場合、作者はテストを書き加えるか、プルリクエストをクローズしなければなりません。例外は認められません。

この実験にはサーキットブレーカーが組み込まれています。6 週間のウィンドウ内でマージされたプルリクエストの半数以上が LLM 作成である場合、LLM 作成プルリクエストのマージはシェアが 50％ 未満に戻るまで停止され、最低 10 日間のクールダウンが適用されます。このウィンドウは Rust の 6 週間リリースサイクルと一致します。対象プルリクエストはすべて新しい ai-assisted ラベルが付与され、データ収集（LLM 補助貢献者が学習し、再参加し、有用な成果を上げているか）を目的としたプライベートな Zulip チャンネルに投稿されます。ゲートキーピングを目的としたものではありません。

なぜ今なのか

Nelson の発表は、チームが非公式なモデレーションから文書化されたルールへ移行した3つの圧力を示しています。洗練されたプルリクエストはもはや努力や理解のシグナルとみなされず、レビュー文化が依拠する信頼シグナルが腐食しています。コード生成コストの低下は、既存のレビュー帯域幅不足をさらに悪化させています——リポジトリには現在 1,281 件の未処理プルリクエストがあり、不足している資源は常にコードではなくレビュアーの判断でした。また、レビューコメントを LLM に貼り付けて出力を再度貼り付ける貢献者は、Nelson の言葉を借りれば「皆の時間を浪費し、レビュアーが人間と対話しているという前提を壊す」行為です。

背景にはプロジェクト内部の本格的な分裂があります。ポリシーの動機付けセクションは、Rust 内で AI ツールの受容について「合意はなく、将来的にも得られない可能性が高い」ことを明示しています。メンバーは日常的に使用する者から、いかなる使用も容認できない者まで幅広く存在します。そこで文書は変更可能な構造で作られています：大幅な改訂には各承認チームのサインオフが必要で、承認チームが全体でポリシーを撤廃できるほか、リーダーシップ評議会が現在検討中のプロジェクト全体の LLM 委員会が優先して規則を拡大し、チャット、フォーラム、現在ポリシーが存在しないリポジトリまでカバーできるようになります。

細部の条件

見出しが示すほど広範ではありません。ポリシーは rust-lang 組織内の他のリポジトリ、言語チームが行う課題追跡や安定化レポート、スタイルガイド、承認していないチームを対象外としています。各チームは独自に規則を設定できます。rust-lang 組織のメンバーは「非重要」な LLM 作成コードに対する例外が認められますが、ポリシーはその例外の使用を強く非推奨し、ポリシー施行前に作成されたプルリクエストも同様に例外とします。LLM 使用を理由に貢献者をハラスメントすること自体が禁止されており、使用がポリシー違反であったかどうかに関わらず適用されます。

今後の展開

プライベートな Zulip チャンネルは ai-assisted ラベルが使用開始された時点で LLM 作成プルリクエストのデータ収集を開始し、最初の 6 週間サーキットブレーカー期間が実験がマージキューを圧迫しているかどうかをチームに示します。リーダーシップ評議会が検討中の専任 LLM 委員会の提案が成立すれば、このポリシーに優先権が与えられ、プロジェクト全体に規則が拡大され、現在ポリシーが全く存在しないチャット、フォーラム、リポジトリまでカバーされます。Nelson の投稿はまさにその結果を主張しており、このポリシーを最終的な答えではなく第一歩として位置付けています。