NetworkManager、AIコーディングポリシーを策定。「会話」にも制限
Linuxのネットワーク設定を担うソフトウェアが、コードだけでなくレビューの対話にまで踏み込んだAIルールを敷いた。
Linuxのネットワーク設定を担うソフトウェアが、コードだけでなくレビューの対話にまで踏み込んだAIルールを敷いた。
5項目のポリシー
NetworkManagerのCONTRIBUTING.mdに、「AI coding assistants」と題するセクションが追加された。Red Hatのジョセフィーヌ・ファイファー（Josephine Pfeiffer）氏が提出したマージリクエストは、メンテナーのラフル・ラジェッシュ（Rahul Rajesh）氏の承認を経て、現地時間8月7日にマージされている。
ポリシーは5項目で構成されている。
Authors are responsible for 100% of the code they submit. Do not send a patch you cannot explain, and do not send one you have not built and tested yourself.
（提出するコードの100%に著者が責任を持つ。説明できないパッチを送るな。自分でビルドもテストもしていないパッチを送るな）
Write your own commit messages and Merge Request descriptions. Those explain why you are making the change, which is the part a tool cannot know.
（コミットメッセージとマージリクエストの説明文は自分で書け。なぜその変更をするのかを説明するのがそれらの役割であり、それはツールには分からない部分だ）
Respond to review comments yourself. If you cannot discuss your own patch with a reviewer, it will not be merged.
（レビューコメントには自分で応答せよ。レビュアーと自分のパッチについて議論できないなら、マージされない）
Everything in the Legal section applies unchanged. You are the one certifying that the contribution can be released under LGPL-2.1-or-later. A tool cannot certify that for you.
（法的セクションの内容はそのまま適用される。その貢献がLGPL-2.1-or-laterでリリースできると証明するのはあなた自身だ。ツールにはそれはできない）
Large machine-generated Merge Requests that no human has reviewed line by line will be closed.
（人が1行ずつレビューしていない、大規模な機械生成マージリクエストは閉じる）
AIの利用を禁止していない。だが提出したコードの全責任は著者にあると明記した。説明できないパッチ、自分でビルドもテストもしていないパッチは送るな。
LGPL-2.1-or-laterでのリリースを保証するのも著者の役割で、ツールには代われない。人がレビューしていない大規模な機械生成MRは閉じる。
コードの先にあるもの
5項目のうち、2つ目と3つ目に注目する。
コミットメッセージとMRの説明文は自分で書け。レビューコメントには自分で応答せよ。この2つは、コードの生成元ではなくコミュニケーションを規制している。
Linuxカーネルは4月にAssisted-by（AIによる支援）タグによる開示の規定を導入したが、あくまでコードが対象だ。GCCは7月29日、約15行を超えるAI生成コードの受け入れ拒否を発表した。Rustプロジェクトも8月6日に公式ポリシーを採択している。いずれもコードの出自に焦点がある。
NetworkManagerのポリシーが踏み込んだのは、コードの外側だ。「なぜこの変更が必要か」を説明する行為と、レビュアーの指摘に応じて議論する行為。パッチを書いた本人でなければ成り立たない。
コードを生成できても、変更の動機まで生成することはできない。レビュアーとの対話を通じてパッチが磨かれていく過程にAIを介在させない、と宣言した。
なぜ今なのか
NetworkManagerのポリシー策定は、偶然のタイミングではない。
同じ週、Linuxの無線LANメンテナーであるヨハネス・ベルク（Johannes Berg）氏が、AIが生成したパッチに対する「3秒ルール」を宣言した。3秒で修正の正当性が読み取れないAIパッチは無視する、という方針だ。
ネットワーキングサブシステム全体でも、ヤクブ・キチンスキ（Jakub Kicinski）氏が「通常の倍のパッチが流れ込む週もある」と報告している。Linux 7.1ではAI起因のノイズを減らすために古いネットワークドライバーやISDNサブシステムが削除された。
Linuxカーネル 7.2-RC6は、カーネル史上最大のRC6になった。AI生成パッチの増加がその一因だ。
NetworkManagerはカーネル本体ではないが、Linuxのネットワークスタックと密接に連携するユーザー空間のソフトウェアだ。GNOME搭載のほぼすべてのディストリビューションに標準で入っている。Red Hatが主導する開発プロジェクトとして、カーネル側で起きている波を無視できる立場にはない。
「禁止」と「責任」の間
OSSコミュニティのAIポリシーは、大きく2つの方向に分かれている。
一方にGCCやGentooのように、AI生成コードの受け入れ自体を拒否するアプローチがある。もう一方は、Linuxカーネルのように利用を認めつつ開示と責任を求める方針だ。NetworkManagerは後者に近い。AIを使ってもいい。だがコードの責任も、コミットメッセージも、レビューへの応答も、すべて人が引き受ける。
| コードの扱い | 対話の規制 | |
|---|---|---|
| 利用を認める | ||
| Linuxカーネル | 許可 (Assisted-byタグで開示) | — |
| NetworkManager | 許可 （著者が全責任） | ○ |
| QEMU | 限定許可 （20行以下・テスト等） | — |
| 拒否する | ||
| GCC | 15行超のコードを拒否 | — |
| Gentoo | 全面禁止 | — |
ファイファー氏のポリシーは短い。禁止語は1つも使われていない。5つの項目が述べているのは、開発者がすでに守っているはずのことだ。説明できないコードを送るな。自分でビルドしろ。レビューには自分で答えろ。
当たり前のことを、改めて書かなければならなくなった。それが2026年のオープンソース開発だ。
関連記事
- GCC、LLM生成コードの受け入れを「約15行」で線引き
- GNOME、セキュリティ開示を90日から30日に短縮
- 1991年のLinuxカーネルをRustで書き直した大学生の話
- QEMU、AI生成コードの「全面禁止」から限定許可へ
- GCC、AIポリシー策定の作業部会を設置
- Linux Wi-Fiメンテナ、AIパッチに「3秒ルール」を宣言
- LLMがコードを突き始めた。Linuxカーネル、27年前のドライバーを削除
- LinuxカーネルのstagingがLLMパッチを自動拒否へ。例外はセキュリティ修正のみ
- Linux 7.2-rc5公開。パッチ量は膨張、中身は平穏
- Debian、LLM利用の全面禁止か条件付き容認かを正式投票へ
