Rust-lang/rust が LLM ポリシーを導入

2026年8月5日 · Jynn Nelson 最近、Rustプロジェクト内の5つのチームが、私が元々作成した、大規模言語モデル（LLM）が `rust-lang/rust` モノリポジトリへの貢献にどのように使用できるかを管理するポリシーを採用しました。注目すべきは、新しいポリシーはLLMに対する公式な見解ではなく、Rustプロジェクトのすべての箇所に適用されるわけではないということです。私は、以下に説明する非常に特定の目的のためにこれを書きました。この記事では、なぜそのポリシーを作成したのか、それが何を意味するのか、そしてこれがコントリビューターにどのように影響するのかについて説明します。 このポリシーは、以下のグループの人々に影響します。 * `rust-lang/rust` でプルリクエスト（PR）をレビューまたはモデレートする人々。 * `rust-lang/rust` でLLM生成コードを含むPRを作成する人々。 * LLMを使用して問題を発見し、`rust-lang/rust` に投稿する人々。 * `rust-lang/rust` でLLMを直接引用する問題やコメントを書く人々。 これらのグループのいずれにも該当しない場合は、作業方法について何も変更する必要はありません。 なぜこのポリシーが作成されたのか？ Rustプロジェクトは技術的な成果物の集まりですが、同時にそれらの成果物を構築、維持、拡張するために協力する人々のコミュニティでもあります。「Rustプロジェクトに貢献する」という言葉には、それらの成果物に対する作業の一部が含まれますが、コミュニティに参加し、そこにいる人々との協力を意味する部分も含まれます。 このポリシーが作成される前から、人々はLLMを `rust-lang/rust` に貢献するために使用していました。それらの使用方法の中には、私たちのコミュニティを尊重するものもありました。例えば、母国語でドラフトを作成できるようにメッセージを英語に翻訳したり、Rustの新しいコントリビューターが書く可能性のあるコードスニペットの診断が不十分な点を見つけたり、RFCを分析して言語の他の部分の議論が欠けていないかを確認したりすることです。しかし、それらの使用方法の一部は、意図的でない場合もありましたが、私たちのコミュニティに3つの主な問題を引き起こしました。 * 洗練された技術的な製品が、もはや努力と理解を示さなくなった。 * コードを書きやすくすることが、レビュー帯域幅に関する既存の問題を悪化させる。 * 人々がLLMとの間で機械的にコピー＆ペーストすることは、私たちの時間の無駄である。 時間が経つにつれて、これらの問題は増大し、それらを処理するための専用チャネルとモデレーションポリシーを作成する必要が生じました。しかし、それらのチャネルは、透明性と歓迎の精神という私たちの目標に反します。なぜなら、新しいコントリビューターはルールが何であるかを知らないからです。新しいポリシーは、それらのルールを公に形式化するため、新しいコントリビューターは、理解できない理由でPRが閉じられることなくコミュニティに参加する方法を知ることができ、既存のレビュー担当者は、それに従わないPRを閉じる際に、ルールを具体的な理由として容易に指摘できるようになります。 技術的な製品はもはや努力を示さなくなった 以前は、オープンソースプロジェクトが洗練され、十分にテストされ、詳細なPRを受け取った場合、それはそのPRに時間、労力、そして理解を費やした誰かがいることを示していました。これはRustの文化にいくつかの点で影響を与えました。 * 私たちは、他人のハードワークを表しているため、PRを閉じることに一般的に消極的です。 * 私たちのプロセスは、作成中またはレビュー中に新しい事実が発見された場合に既存のデザインを変更することを許可する、段階的な議論を重視しています。 * 私たちはPRを、誰かがコミュニティに参加し、将来のPRに取り組むためのメンターシップを受けることに興味があるという兆候として扱います。 LLMを使用すると、これらのシグナルのどれも信頼できなくなります。洗練されたPRはもはや努力を示さず、洗練されたPRの著者が必ずしもそのコードを理解しているとは限りません。自律エージェントの場合は、そもそも相手に人がいません。コードを書くことがはるかに容易になったため、洗練されたPRは、誰かが長期的に定着する可能性が高いことを示さなくなりました。 コードを書きやすくすることがレビューの問題を引き起こす 執筆時点では、`rust-lang/rust` には1,281件のオープンなPRがあります。これは、著者とレビュー担当者の両方が費やした驚異的な時間を表しています。私たちは長い間、コードを書きたい人が、それをレビューしてくれる人よりも多いという問題を抱えてきました。LLMの出現により、この問題はさらに悪化します。 レビューの作業のほとんどは、単にバグを見つけることではありません。その大部分は、この方向性が良いアプローチであるかどうか、PRがそもそも良いアイデアであるかどうかを決定することです。言い換えれば、レビューは決定で構成されています。「ショットガン」のようにPRをレビュー担当者に送りつけることは、彼らに高い精神的コストを強います。LLM PRの著者のほとんどは、自分が誠実に手助けしていると信じていると思いますが、私たちの観点からは、コード自体は変更の中で最も小さく、ある意味では最も重要でない部分です。私たちは、著者がコードの機能を理解しているか、将来どのように変更されるかを計画しているか、そしてそれがどのように見えるべきかを決定しているかにより、はるかに重点を置いています。コード自体はこれらのいずれにも役立ちません。 LLM出力を機械的にコピー＆ペーストすることは時間の無駄です レビューコメントに応答するために、それをLLMにコピー＆ペーストし、その応答をGitHubにコピー＆ペーストして戻す人々がよくいます。率直に言って、これは皆の時間の無駄です。LLMの意見を聞きたかったのであれば、私たち自身がそれを尋ねることができたでしょう。私たちは、機械の意見ではなく、あなたの考えを聞きたいのです。さらに、これはレビュー担当者と著者の間の信頼の侵害です。レビューする際の私たちの仮定は、最善を尽くしたいと思っている実在の人物と話しているということです。LLMのテキストを貼り付けることは疑念を生じさせます。著者は本当に気にかけているのか？ここに人がいるのか？ なぜポリシーが必要なのか？ このポリシーが導入される前は、「ワイルドウェスト」のようなモデレーションアプローチをとっていました。LLMのPRは数十件ありましたが、開示ルールはなく、人々は最初のPRとしてリスクの高いMIR最適化を追加しようとしたり、「Verification: git diff --check」をPRの説明に、それが何かをするかのように投稿したりしていました。モデレーターが「負担の大きいPRを拒否する権限をレビュー担当者に与える」という形で参照できるものはありましたが、私たちの執行は一貫性がなく、ルールはどこにも公開されていませんでした。実際には、「明らかにひどいものでない限り、何でもあり」というルールでした。 以前の状況と比較して、新しいポリシーはより厳格であり、より明確でもあります。LLMが良いか悪いか、あるいは秘密の第三の何かであるかについてのあなたの意見に関わらず、それらはもはや無視できません。私たちの選択は、「ポリシーなし」または「ポリシーあり」ではありません。私たちの選択は、ポリシーが非公式なモデレーションノートのリストであるか、それとも私たちが公に支持するものであるかです。 なぜLLMを完全に禁止したり、社会的に有益だと考えるLLMのあらゆる使用を許可したりしないのか？ それはRustのガバナンスがそのようには機能しないからです。「LLM生成コンテンツ、コードであれ文章であれ、一切禁止」とか「AIは他のツールと同じように使用できるツールである」と言うことができる、慈悲深い独裁者は存在しません。Rustはコンセンサスによって運営されています。 ポリシーに記載されている通りです。 Rustプロジェクト内には、AIベースのツールの使用がいつ/どのように/どこで許容されるかについてコンセンサスはなく、おそらく今後も決して存在しないでしょう。Rustプロジェクトやコミュニティの多くのメンバーはAIに価値を見出していますが、他の多くのメンバーは、その社会や気候への悪影響が深刻であるため、いかなる使用も許容できないと感じています。さらに他の人々は自分の意見を形成中です。これらの違いにもかかわらず、私たちは皆が共有する多くの価値観があります。 * 私たちの集合的なプロジェクトにおける深い専門家のコミュニティを構築すること。 * 全員が歓迎され、尊重されていると感じられる、包括的なコミュニティを構築すること。 私たちは、将来的にポリシーを変更できることを望んでいます。このポリシーには、元の採用よりも変更を容易にするいくつかの規定があります。リーダーシップ評議会は、30人もの承認が必要な「悪夢」のような要件を減らすために、LLMポリシーを扱うサブチームの作成も検討しています。 このポリシーのすべてのルールが完全に良いとは思いません。しかし、ルールを書き出すことは、書き出さないことよりも良いと信じています。そして、皆が少し嫌いなポリシーを持つことは、私たちがガバナンス構造を改善することを促します。 ポリシーは何を言っているのか？ ポリシーはそれ自体を次のように要約しています。 質問に答えたり、分析したり、要約したり、洗練したり、チェックしたり、提案したり、レビューしたりするためにLLMを使用することは問題ありません。しかし、作成するためではありません。最初のカテゴリの使用は許可されており、場合によっては開示が必要です。2番目のカテゴリの使用は厳しく制限されています。