8月9日、pbxscience.comが「Rust Adopts a Formal LLM Usage Policy for Its Core Repository」と題した記事を公開した。この記事では、RustのコアリポジトリにおけるLLM使用に関する正式ポリシーの策定と、その具体的な内容について詳しく紹介されている。
「禁止」ではなく「線引き」——Rustが選んだアプローチ
2026年8月5日、RustプロジェクトはInside Rust Blogにて、コアリポジトリrust-lang/rustへのコントリビューションにおけるLLM（大規模言語モデル）使用ポリシーを正式に発表した。著者はJynn Nelson。compiler、libs、types、rustdoc、bootstrapなど複数のチームが既に批准している。
このポリシーが興味深いのは、AIツールを全面禁止しなかった点だ。代わりに設けた区別は、極めてシンプルなものである。
「LLMを使って質問し、分析し、要約し、洗練させ、確認し、提案し、レビューするのは構わない。だが、創作（create）はダメだ。」
つまり、LLMを「思考の補助」として使うのはOK。LLMに「成果物を生み出させる」のは、厳格な条件下でのみ許容される——という構造だ。
なぜ今、ルールが必要だったのか
Nelson のポストは、プロジェクトが非公式に抱えていた3つの問題への対応としてこのポリシーを位置づけている。
第一に、PRの品質がコントリビューターの理解度を反映しなくなった。 丁寧に整えられたプルリクエストが、実はコードを理解していない投稿者から来ている——Rustのレビュー文化が長年暗黙の前提としていたシグナルが機能しなくなりつつある。
第二に、コードを書くコストとレビューするコストの非対称が拡大した。 LLMによってコードの生産は容易になったが、レビューの負荷は変わらない。記事執筆時点で、リポジトリにはオープン状態のプルリクエストが1,200件以上あったと記されている。
第三に、「リレー投稿」問題。 レビュアーのコメントをそのままLLMに投げ、返ってきた回答をGitHubに貼り付ける——このような機械的なやり取りが、レビュアーとコントリビューター間の信頼を損なっていた。
ポリシーが存在しなかった時代は、モデレーターがこれらをアドホックに対処するしかなく、執行が一貫せず、新規コントリビューターも何が許されるのか判断できない状態だったという。
ポリシーの具体的な中身
公開しない個人利用（コードベースへの質問、提出前の自己レビュー）は、開示義務なしで自由に行える。LLM由来のコンテンツを公開する場合は、以下のルールが適用される。
| 用途 | 可否 | 開示義務 |
|---|---|---|
| 機械翻訳 | ✅ 可 | 必要 |
| LLM支援によるバグ発見 | ✅ 可 | 必要 |
| 他者のコードのLLMレビュー | ✅ 可 | 必要 |
| LLM生成コードの変更 | 条件付き可 | 必要（厳格） |
| セキュリティ・健全性クリティカルなコードのLLM生成 | ❌ 事実上不可 | — |
LLM生成コードの変更が許容されるのは、事前にレビュアーと合意済みであること、コードベースの非クリティカルな部分であること、高い品質基準とテストカバレッジを満たすこと、そして明確に開示されていること——この4条件をすべて満たす場合に限られる。
特筆すべきは、LLMが生成したコードは人間が書いたものより高い基準を課せられる点だ。テストは難易度にかかわらず必須とされている。
AI関与の隠蔽は、いかなる状況でも許されない。 レビュアーはルールに従わないPRを説明なしにクローズする権限を持ち、コントリビューターを専用のメンタリングチャンネルに誘導するよう求められている。
意図的に「狭く」設計されたポリシー
このポリシーはrust-lang/rustリポジトリとこれを批准したチームにのみ適用される。crates.ioのパッケージや、RFCなどの言語設計プロセスには及ばない。
Nelsonは、このポリシーがAIツールの良し悪しについて結論を出すものではないと明言している。Rustコミュニティ内でもAI活用に価値を見出す人から、そのコストを受け入れられないと考える人まで意見は分かれており、コンセンサスは存在しない——とポリシー文書自体が認めている。
ポリシーが狙うのはその論争に決着をつけることではなく、開示・スコープ・品質という行動規範を定めることで、AI観の異なるメンバーが同じ土俵でコラボレーションできるようにすることだ。
またチームは、このポリシーをデータ収集の起点とも位置づけている。LLMを活用したコントリビューターがその後も継続的に関与するかどうか、ツールが学習を助けているかどうか——こうした観察が、将来の改定に活かされる予定だ。
※編集部の考察：LLMによるコード生成が普及するなかで、OSSプロジェクトがどのようにガバナンスを設計するかは、Rustだけの問題ではない。「禁止か許可か」の二択ではなく、用途と開示義務で細かく区分するこのアプローチは、他のプロジェクトにとっても一つの参照事例となるだろう。
詳細はRust Adopts a Formal LLM Usage Policy for Its Core Repositoryを参照していただきたい。
