Linuxカーネルのソースツリーに AI コーディングアシスタント利用ポリシーが追加された
目次
Linuxカーネルのソースツリーに Documentation/process/coding-assistants.rst という新しいドキュメントが追加された。AIコーディングアシスタントを使ってカーネルに貢献する際のルールを公式に定めたもので、Hacker Newsでは264ポイント・173コメントと大きな反響を呼んでいる。
追加したのはNVIDIAのSasha Levin（Linux LTSカーネル共同メンテナ）。2025年12月23日にコミットされ、ドキュメントメンテナのJonathan Corbetが承認した。コミットメッセージには「2025 Maintainers Summitで到達した合意に基づく」と明記されている。
2025 Maintainers Summitでの議論
このポリシーの原型は、2025年のLinux Kernel Maintainers Summitで形作られた。Sasha Levinが基本方針を提示し、Stoakes、Jiri Kosinaからも個別の提案が出て議論が行われた。
Linus Torvalds自身も発言しており、「LLM生成コードには法的懸念が伴いうる」としつつ、現行の開発者認証プロセスで責任問題は対処可能だという立場を示した。
一方で、AIによるコード生成がカーネル開発で実際に大規模に起きている段階ではないとも述べた。
議論の中で興味深かったのは、AIツールがコード生成以外ですでに実用されている事実が共有された点だ。
Jens Axboeは、自動化ツールが人間3人のレビューをすり抜けた条件分岐の反転バグを検出した事例を報告。
Starovoitovは自動レビューの約60%が高品質で、さらに20%に有用な知見が含まれていたと報告している。
このあたりの文脈は、GoogleのSashikoリリースとも繋がる。SashikoはLinuxカーネルパッチを自動レビューするAIシステムで、人間のレビューを通過した既知バグの53.6%を検出したと報告されていた（過去記事）。
Summit全体としては、厳格な規制よりも透明性の確保と慎重な実験を支持する方向でまとまった。
3つのルール
マージされた coding-assistants.rst はシンプルなドキュメントで、大きく3つのルールを定めている。
AIエージェントはSigned-off-byを付けてはならない
ドキュメント中で最も強い表現が使われている箇所がここだ。
AI agents MUST NOT add Signed-off-by tags. Only humans can legally certify the Developer Certificate of Origin (DCO).
Linuxカーネルでは、すべてのパッチに開発者が Signed-off-by タグを付ける。これはDCO（Developer Certificate of Origin）への署名で、「このコードがGPL-2.0互換であること」「自分に提出する権利があること」を法的に認証する行為である。
AIエージェントにはこの法的認証を行う能力がない。人間の提出者が以下のすべてに責任を負う。
| 責任 | 内容 |
|---|---|
| コードレビュー | AI生成コードをすべて確認する |
| ライセンス確認 | GPL-2.0-only互換であることを検証する |
| DCO署名 | 自分のSigned-off-byタグを付ける |
| 全責任の引き受け | 貢献に対する全面的な責任を負う |
Assisted-byタグによる帰属表示
AI支援を受けた場合、コミットメッセージに Assisted-by タグを含める。フォーマットは以下の通り。
Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]具体例として Assisted-by: Claude:claude-3-opus coccinelle sparse が挙げられている。AGENT_NAME はAIツール名、MODEL_VERSION は使用モデルのバージョン、角括弧内は併用した静的解析ツール（coccinelle、sparse、smatch、clang-tidy等）を示す。git、gcc、make、エディタのような基本ツールは記載しない。
ライセンスと開発プロセスの遵守
AIツールが生成するコードはGPL-2.0-onlyと互換でなければならず、適切なSPDXライセンス識別子を使用する必要がある。通常のカーネル開発プロセス（coding-style.rst、submitting-patches.rst等）への準拠も同様に求められる。
タグの変遷とCo-developed-byが見送られた理由
Sasha Levinの初期RFC（2025年7月）では、AI帰属に Co-developed-by タグが検討されていた。しかしDavid HildenbrandやKonstantin Ryabitsevの提案を受けて Assisted-by に変更された。
理由は明確で、Linuxカーネルの既存タグ体系との整合性にある。
| タグ | 意味 |
|---|---|
| Signed-off-by | DCOの法的認証（必須） |
| Reviewed-by | コードレビュー実施の表明 |
| Acked-by | メンテナの承認 |
| Tested-by | テスト実施の表明 |
| Reported-by | バグ報告者のクレジット |
| Co-developed-by | 共同開発者（Signed-off-byとペアで使用） |
| Assisted-by | AI支援の帰属表示（今回の新規追加） |
Co-developed-by は対応する Signed-off-by とペアで使うルールがある。
AIに Signed-off-by を付けさせないというポリシーと矛盾するため、新しいタグが必要だった。
「共同開発」ではなく「支援」という位置づけにすることで、AIは著者ではないという立場を明確にした。
なお、Assisted-by タグが checkpatch.pl（カーネルのパッチ検証スクリプト）で当初弾かれる問題が発生したが、Sasha Levinがv2パッチで対応し、Joe Perchesが承認している。
HNのコメントに見る論点
Hacker Newsのコメント欄では、ポリシーへの評価と著作権問題の2軸で議論が展開された。
トップコメントのqsortは「refreshingly normal（驚くほどまとも）」と評した。
責任とライセンス遵守を求めるだけの、多くの人が支持できるベースラインだという指摘。
pibakerは「こんな当たり前のことを明文化しなければならないこと自体が、AI貢献の問題の大きさを物語っている」と返した。コードを理解せずにAI生成パッチを投げる開発者の横行が背景にある。
AIの学習データに起因する著作権リスクも大きな論点だった。sarchertechは、多様なソースで訓練されたAIを使う以上、GPL適合を保証するのは不可能だと主張。反論として、人間だって過去に見たコードを無意識に再現するリスクは同じだという意見がついた。
DCOの仕組みは侵害リスクそのものを排除するわけではなく、法的責任を人間の提出者に移転することで責任の所在を明確にしている。
Summitで残った未解決の問題
Summitの議論ではすべてが解決されたわけではない。
Konstantin Ryabitsevは、プロプライエタリなAIシステムへの依存に警鐘を鳴らした。
挙げたのがBitKeeperの事例だ。かつてLinuxカーネルのバージョン管理に使われていたプロプライエタリツールBitKeeperは、ライセンス問題でアクセスを失った。
その経験がGitの誕生に繋がったのは有名な話だが、AIツールでも同様の依存リスクがあるという指摘は重い。
Shuah Khanは、高価なAIツールへのアクセスが企業所属の開発者に偏っている点を指摘した。
個人のコントリビューターがAI支援なしで開発する一方、企業開発者はフルスタックのAIツールを使える。
カーネルコミュニティの多様性に影響しうる問題だ。
AI支援レビューに対するオプトアウトの仕組みも未定のまま残っている。自分のパッチをAIにレビューされたくないメンテナが拒否できる手段は、現状では定められていない。
AIとOSSコントリビューションの摩擦
AI生成コードによるオープンソースプロジェクトへの負荷増大は、Linuxカーネルに限った話ではない。Jeff Geerlingが「AIがオープンソースを壊しつつある」と警鐘を鳴らし、curlプロジェクトでも低品質AIコントリビューションの問題が顕在化している（過去記事）。
Linuxカーネルのアプローチは、AI利用を禁止するのではなく、人間が全責任を負った上で使用を開示する方向を選んだ。
Assisted-by タグは強制ではなく推奨で、Sasha Levin自身がSummitで「あえて強制はしない」と述べている。
coding-assistants.rst は49行の短いドキュメントだが、この枠組みが実際にどう機能するかは今後のコミットログ次第だ。