RustのLLM方針草案は正しい線引きをしている

2026年4月17日に作成されたRust Forgeのプルリクエストでは、rust-lang/rust向けのLLM利用方針が提案されています。2026年5月17日時点で、このプルリクエストはまだ未解決で、issueコメントが65件、レビューコメントが284件あります。つまり、この提案はまだ採用済みの方針ではありません。¹

それでも、この草案には今読む価値があります。多くのAIコーディング指針が避けている境界線を、はっきり示しているからです。LLMは、人が考える、学ぶ、確認する、試すことを助けられます。しかし、プロジェクトが判断、審美眼、説明責任、共有理解を守る場所では、人間の著作性を置き換えるべきではありません。²

この提案は、既存のRustの貢献規範にも合っています。現在のRust Forge貢献ガイドは、すでに貢献者に対して、信頼を築くこと、レビュアーの時間を尊重すること、自分が完全に理解している作業を提出すること、提出前に細部まで確認すること、コメントを簡潔に保つことを求めています。³ コンパイラのレビュー方針でも、レビュアーにはレビュー対象コードへの十分な理解が必要であり、レビュー時間には限りがあるとされています。⁴ LLM草案は、こうした以前からの期待を、AI支援を受けた作業に対して具体化しています。

要約

Rustの草案は、学習、要約、私的レビュー、個人用ツール、実験を目的とした私的なLLM利用を認めています。² 一方で、LLMに由来する公開コメント、issue本文、プルリクエスト説明、ドキュメント、コンパイラ診断、さらにLLMレビューだけでコードをマージまたは却下できると扱う運用は禁止しています。² LLMが作成したコード変更については、狭い実験枠を設けています。条件は、依頼されたものであること、重要度の低い領域であること、開示されていること、高品質であること、十分にテストされていること、作者とレビュアーの双方が完全に理解していることです。² 私の見方では、この方針が優れているのは、出力量ではなく、知的な管理責任を最適化しているからです。

重要なポイント

• メンテナーへ: 方針は、生産性を語る前に、レビュー能力、プロジェクトの声、説明責任を守るべきです。
• AIコーディングチームへ: 私的利用は広く認めても、公開される著作、ドキュメント、診断、マージ権限にはより厳しい線を引くべきです。
• 貢献者へ: 開示が意味を持つのは、人間がなお作業の責任を負っている場合だけです。「モデルが書いた」は言い訳になりません。
• ツール開発者へ: レビューボットには、別の主体、ブロック可能性、偽陽性を増やさない設計、助言に留まる立場が必要です。
• エージェントチームへ: 草案で最も良い規則は技術的なものではなく、文化的なものです。AIは速く書くためではなく、より良く書くために使う、という規則です。²

草案は思考と著作を分けている

多くのLLM方針は、異なる2つの行為を「AIを使う」という1つの分類に押し込めます。Rust草案は、その行為を私的な思考と公開される著作に分けています。

私的な思考には、広い許可が与えられています。貢献者は、コードベースについてLLMに質問できます。私的な理解のためにコメントを要約できます。自分のコードや文章を私的にレビューできます。個人用の開発ツールを作れます。自分で解決策を書く前に、学習のためにあり得る解決案を生成することもできます。²

公開される著作には、厳しい線が引かれています。草案は、LLMが最初に作成したコメントを個人アカウントから投稿することを禁じています。同じ規則は、issue本文とプルリクエスト説明にも適用されます。² さらに、LLMが最初に作成したドキュメントも禁止しています。対象には、実質的なソースコメント、docコメント、安全性コメント、複数段落のコメント、コンパイラ診断が含まれます。²

この区別は正しいものに見えます。公開される成果物には、プロジェクトの声が宿るからです。コンパイラ診断、安全性コメント、ドキュメントは、単に情報を運ぶだけではありません。Rustがどう考えるかをユーザーに教えるものです。同時に、プロジェクトが長期的に保守する負担にもなります。

LLMが生成した文章は、洗練されて見えながら、その負担を弱めることがあります。レビュアーは、こう問わなければならなくなります。この言い回しを選んだのは誰か。この含意を理解しているのは誰か。境界条件の責任を負うのは誰か。あとで混乱が起きたら誰が直すのか。草案は、貢献者が人間アカウントの信頼性を保ったまま、その責任だけを外部化することを認めていません。

最も強い規則: AIレビューをマージ権限にしない

草案は、LLMレビューを変更のマージまたは却下に十分な条件として扱うことを禁じています。² レビューボットは存在してもかまいませんが、草案はそれを助言に留めるよう求めています。プルリクエストをブロックする前に、レビュアーはLLMコメントを明示的に支持しなければなりません。また、作者には引き続き自己レビューの義務があります。²

この規則は、陥りやすい失敗を避けます。チームはAIレビューを追加して、ワークフローがより安全になったと言いがちです。しかし、その新しいツールが、誰も評価する時間のない主張の流れをもう1本増やしただけ、ということもあります。ボットは本物のバグを見つけることがあります。一方で、些細な異議、古いスタイル助言、幻覚による制約、理解していないコードへの自信あるコメントを出すこともあります。

Rust草案は、この問題を構造的に扱っています。

要点は、LLMレビューに価値がないということではありません。レビュー権限は、人とプロジェクトのプロセスに属するということです。機械はレビュアーを支援できます。しかし、記録上のレビュアーそのものにはなれません。

コードの例外は意図的に狭い

草案は、LLMが作成したコードをすべて禁止しているわけではありません。5つの条件を満たすコード変更について、実験枠を作っています。依頼されたもの、重要度の低いもの、高品質なもの、十分にテストされたもの、十分にレビューされたものです。²

それぞれの言葉に意味があります。

依頼されたものとは、レビュアーがLLM作成のプルリクエストをレビューすることに、事前に同意しているという意味です。新しい貢献者は、そのPRに割り当てられた同じレビュアーと先に話さない限り、この経路でLLMを使えません。²

重要度の低いものは、AIが作成した変更を、健全性の退行を起こし得る領域から遠ざけます。草案は、内部ツールをよりあり得る対象として挙げ、trait system、MIR building、query systemのような領域はおそらく適切ではないとしています。²

高品質とは、そのコードが少なくとも他の変更と同じ基準を満たす必要があるという意味です。草案は、コードベースの品質を下げるPRを明確に拒否しています。²

十分にテストされたものは、基準を引き上げます。LLMが作成したPRには、より高いテスト期待が課されます。LLMによってテストを書くことが容易になるからです。既存のテストスイートがそのコードをカバーしていない場合、作者は新しいテストを書くか、PRをクローズしなければなりません。²

十分にレビューされたものとは、作者とレビュアーの双方がコードを完全に理解することにコミットするという意味です。プロジェクトメンバーによるレビューは、自己レビューの代わりにはなりません。²

この実験枠はよくできています。AIが作成したコードは役に立たない、と決めつけてはいません。同時に、貢献者がパッチを生成し、メンテナーに仕分けを任せ、理解に人間の労力を使わないという、怠惰な「AI支援貢献」も拒んでいます。

速くではなく、より良く

草案で最も重要な一文は、LLMは人が速く書くためではなく、より良く書くために使うときに最も効果を発揮する、というものです。²

この一文は、AIコーディングの標準になるべきです。

速さだけを求めると、作業は作者からレビュアーへ移ります。貢献者はパッチ生成で1時間を節約し、メンテナーは有用なコードを奇妙なテスト、肥大化したコメント、曖昧な診断、所有者のいないデザイン判断から切り分けるのに3時間を費やします。最終的に差分がコンパイルできても、プロジェクト全体では損をします。

より良い作業を目指すなら、問いは変わります。ツールは人間の理解を鋭くしたのか。作者が検証した境界条件を見つけたのか。作者が理解しているテストの下書きを助けたのか。最終的な貢献は、レビューしやすく、保守しやすく、信頼しやすくなったのか。

Rust草案は、この区別を運用可能にしています。私的なLLM利用は、作者の理解を改善できます。公開されるLLM由来の著作は、プロジェクトの共有理解を損なうことがあります。AIが作成した実験的なコードは、依頼、範囲、品質、テスト、レビューのすべてが追加の負担を引き受ける場合にだけ進められます。

この組み合わせは、全面的な楽観論にも全面的な禁止にも勝ります。技術は助けになるかもしれない。しかし、モデルが安く作ったというだけで、責任の薄い出力をプロジェクトが吸収することはない。そう言っているのです。

モデレーション節は犯人探しを避けている

草案は、執行についても珍しいほど慎重です。貢献者に対し、LLM利用について探偵ごっこをする必要はないと伝えています。違反が明らかに見える場合は、方針を示す。境界線上に見える場合は、モデレーターに報告して先へ進む。それでよいとしています。²

同じ節は、LLM利用について不誠実であることを行動規範上の問題として扱います。一方で、LLMを使った人に嫌がらせをすることは許されないとも明記しています。² この組み合わせは重要です。疑いを招く方針は、止めようとしているAI生成コンテンツよりも速くコミュニティを傷つけることがあります。

良いAI方針には、2つの境界が必要です。

草案は、すべてのレビュアーを調査員に変えることなく、貢献者に責任を置いています。それはコードと同じくらい、レビュー文化を守ることでもあります。

他のプロジェクトが取り入れるべきこと

Rustの提案が注目に値するのは、雰囲気ではなく役割を定義しているからです。

LLMは、次のように使います。

• 私的なチューターとして。
• 私的なレビュアーとして。
• 自分の理解のための要約者として。
• 人間がバグを検証する場合のバグ発見支援として。
• レビュアーが同意し、範囲が低リスクに留まる場合の実験元として。

LLMを、次のようには使いません。

• 自分のコメントの公開作者として。
• プロジェクトドキュメントの声として。
• コンパイラ診断の作者として。
• 人間レビューの代用品として。
• 書いていないテストの言い訳として。
• 自分が理解していないコードをメンテナーにレビューさせる方法として。

この一覧は、メンテナーに道徳論よりも役に立つものを与えます。運用できる方針です。

私の見方

この草案は、AIコーディングが生む品質問題と噛み合っています。コードは安く作れるようになります。しかし、レビューの注意、審美眼、一貫性、プロジェクトの声、社会的信頼は安くなりません。希少性は上流へ移ります。

出力量を最適化するプロジェクトは、もっともらしい差分でメンテナーを溺れさせます。責任ある管理を最適化するプロジェクトは、なおAIを使えます。ただし、人間の作者をより有能にし、レビュアーの負担を軽くする形でだけです。

Rust草案は、その希少な層を守っています。診断、コメント、ドキュメント、レビュー権限を、交換可能なテキストではなくプロジェクトの一部として扱っています。テストと自己レビューを、付属品ではなく義務として扱っています。実験への道は用意していますが、白紙委任ではありません。

これは、真剣なソフトウェアプロジェクトにとって正しい方向です。Rustが何かを採用する前に、具体的な規則は変わるかもしれません。それでも根本の形は変えるべきではありません。AIは人がより良い仕事をする助けになれます。しかし、貢献の責任はなお人間が負わなければなりません。

FAQ

このRust方針は採用されていますか？

いいえ。2026年5月17日時点で、この方針は「Add an LLM policy for rust-lang/rust」という未解決のRust Forgeプルリクエストとして存在しています。現在のrust-lang/rust-forge main branchには、まだsrc/policies/llm-usage.mdは含まれていません。¹⁵

草案はすべてのAI利用を禁止していますか？

いいえ。草案は、学習、要約、レビュー、個人用ツール、アイデア生成を目的とした私的なLLM利用を条件付きで認めています。また、開示され、依頼され、重要度が低く、高品質で、十分にテストされ、十分にレビューされたLLM作成コードについて、狭い実験枠も設けています。²

草案は何を禁止していますか？

草案は、LLM由来の公開コメント、issue本文、プルリクエスト説明、ドキュメント、コンパイラ診断、そしてLLMレビューだけでコードをマージまたは却下することを禁止しています。²

なぜ草案はドキュメントと診断をここまで厳しく扱うのですか？

ドキュメントと診断は、プロジェクトの声、ユーザーへの案内、長期的な保守義務を担うからです。草案は、場合によって周辺のロジックをLLMが支援することは認めています。しかし、メッセージそのものをLLMが作成することは禁じています。²

AIコーディングチームはこの提案から何を学ぶべきですか？

私的な支援と公開される著作を分けることです。AIが他者に影響する場所では開示を求める。レビュー権限は人間に残す。AIがコード作成を助けた場合は、テストと自己レビューの基準を引き上げる。より多くの出力ではなく、より良い仕事を最適化することです。

参考文献