Linuxカーネル、AI生成コードを条件付きで容認へ
Linuxカーネルが、AI支援コードの受け入れを条件付きで公式に容認する方針を打ち出している。条件は明快だ。人間が最終責任を負い、出自を隠さないこと。禁止ではなく、ルール化という選択だった。
Linuxカーネルが、AI支援コードの受け入れを条件付きで公式に容認する方針を打ち出している。条件は明快だ。人間が最終責任を負い、出自を隠さないこと。禁止ではなく、ルール化という選択だった。
「締め出す」でも「野放し」でもない、第三の道
議論の前提がひとつ覆った。Linuxカーネルは、AIが書いたコードを拒まない。拒まないかわりに、細かい札を首から下げさせる。札を下げない者は、門を通れない。そういう設計になっている。
Linuxカーネルのリポジトリに追加されたDocumentation/process/coding-assistants.rstという文書が、その内容を簡潔に示している。AIツール、およびAI支援を使ってカーネルに貢献する開発者向けのガイダンスという位置づけだ。文面は驚くほど短い。短いからこそ、方針の輪郭がはっきり見える。
禁止という選択もあった。一部のメンテナがより厳しい制限を求めていた経緯もある。だが採用されたのは「同じ土俵に上がれ、ただし出自を申告せよ」という線だ。AIを特別扱いしないことが、かえって一番重たい縛りになっている。
ルールの核心は「人間が肩代わりしない」こと
文書を読むと、要求の中心は一貫している。「責任の所在を曖昧にするな」という一点だ。
AI支援コードであっても、開発プロセス・コーディングスタイル・パッチ投稿の既存文書にそのまま従わなければならない。ライセンス面ではGPL-2.0-onlyとの互換性、適切なSPDX識別子、license-rules.rstの順守が求められる。ここまでは、人間のコードと何ひとつ変わらない。
差が出るのは、署名の扱いだ。ここで一気に現実の重みがかかってくる。
AIエージェントはSigned-off-byタグを付与してはならない。Developer Certificate of Origin（DCO）を法的に証明できるのは人間だけであり、提出者はAIが生成したコードの全レビュー、ライセンス要件への準拠、自身のSigned-off-byタグによるDCO証明、そして貢献に対する完全な責任を引き受けなければならない。
| 項目 | 人間の開発者 | AIエージェント |
|---|---|---|
| Signed-off-by タグの付与 | ○ | × |
| DCOの法的証明 | ○ | × |
| 生成コードの最終レビュー | ○ | × |
| ライセンス要件への準拠責任 | ○ | × |
| 貢献物に対する完全な責任 | ○ | × |
| Assisted-by タグでの明示対象 | — | ○ |
つまり、AIに名前は貸さない。AIの出力を通すなら、通した人間が全部被れ。これは倫理の話ではなく、法の話だ。DCOは契約であり、契約を結べるのは人間だけ、という素朴な原則に立ち返っている。
Assisted-byというタグが意味するもの
もうひとつの柱が、出自の追跡だ。AIが関与した貢献には、Assisted-byという独自タグの付与が求められる。書式はAGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]という形で、ツール名・モデル・バージョン、そして補助的に使った解析ツールを並べる。
文書に掲げられた例がやや示唆的だ。
| フィールド | 意味 | 例 |
|---|---|---|
| AGENT_NAME | AIツール・フレームワーク名 | Claude |
| MODEL_VERSION | 使用したモデルのバージョン | claude-3-opus |
| [TOOL1] [TOOL2] | 補助的な解析ツール（任意） | coccinelle sparse |
支援者：AnthropicのClaude（モデル：claude-3-opus）、補助ツールとしてcoccinelleとsparseを使用
gitやgcc、make、エディタといった基本開発ツールは記載不要、と明記されている。つまりここで捕捉しようとしているのは、「書く行為」に介入したAIだけだ。コンパイラや静的解析の類と、コードを生成するAIを意図的に区別している。
一見すると事務作業のようだが、この記録がカーネル開発に何をもたらすかを考えると、意味は軽くない。数年後、どの領域のコードにどのモデルがどれだけ関与したのかを、メタデータから追える状態になる。バグの追跡、品質の統計、脆弱性の遡及調査──すべての足場になる。禁止するより、データを残す方がよほど工学的な態度だ。
「Torvalds本人もvibe codingしてるじゃないか」問題
面白いのは、この文書が話題になる少し前、Torvalds本人が個人プロジェクトでAIコーディングを使っていた件が取り沙汰されていた点だ。本人のAudioNoiseというオーディオ可視化ツールの作業で、Google製のAIアシスタントに手伝わせたコミットが残っている。本人はコミットメッセージで、組み込みの矩形選択が使い物にならなかったので独自のRectangleSelectorを書かせた、と率直に述べ、手作業よりよほど良いかと問われれば間違いなくそうだと添えた。
これを「カーネルの主が転向した」と読むのは早とちりだ。本人は文脈を明確にしている。カーネルのような本業では依然として厳格で、可視化ツールのような「自分の詳しくない領域の個人プロジェクト」でAIに助けてもらうのとは別の話だ、と。今回のカーネル側のルールは、まさにこの線引きを組織レベルで制度化したものに見える。使うなとは言わない。ただし本業の基準は一切下げない、という姿勢だ。
Hacker Newsの議論でも、この現実主義を支持する声が目立った。あるユーザーは要点を端的にまとめている。
要するに、AIは使っていい。ただしコミットに完全な責任を持ち、コードはライセンスを満たせ、ということだ。拍子抜けするほどまともじゃないか？
この「拍子抜けするほどまとも」という形容が、おそらく今回の文書に対する最も的確な評価だろう。
それでも残る不安
もちろん、反論の余地はある。スレッドを下っていくと、より根源的な懸念も見える。AIが訓練データから著作権付きコードを吐き戻す可能性、生成物の品質が低いまま責任だけが人間に押し付けられる構造、そしてレビュアーの負荷だけが静かに増えていく未来。いずれも無視できない論点だ。
とくに最後の点は重い。AIを使う側は時間と労力を節約できる一方で、検証作業はメンテナに丸投げされる。この非対称性を今回のルールは直接には解決しない。「Assisted-byが付いていれば警戒心を持ってレビューできる」という、間接的な防御しか用意していない。
だが、完璧な制度を待っていたらカーネルは止まる。Linuxというプロジェクトは、いつもそうやって動いてきた。理想的な設計を議論し続けるより、最低限の約束事を決めて走り出す。走りながら直す。今回のAI方針も、その系譜の一作に見える。
小さな文書が引いた、大きな一本線
coding-assistants.rstはわずか数十行の短い文書だ。しかし、そこに書かれていないことまで含めて読むと、かなり鮮明なメッセージが立ち上がる。
AIは道具だ。道具として扱う。便利なら使え。ただし、出力の最終責任はキーボードの前の人間にある──この古くからあるエンジニアリング倫理を、AI時代のカーネル開発にそのまま持ち込んだ。新しい何かを発明したわけではない。古い原則の適用範囲を広げただけ、とも言える。
半年後、他のオープンソースプロジェクトがこの文書を参照しはじめる光景は、わりと簡単に想像できる。そのときLinuxが引いた一本線は、思ったより長く残るかもしれない。
参照元
他参照
関連記事
- Linux 7.1、37年間続いたi486サポートに幕を下ろす
- Linuxに「ドリキャスのメモカ」用ファイルシステムが提案
- Anthropic、OpenClaw開発者をBAN
- Framework「パソコンは終わった」宣言の真意と次世代イベント
- Redox OSがLLM生成コードを全面拒否、議論の余地なし
- Claude Code劣化問題、AMDのAI責任者が膨大なログで告発
- トーバルズ、Linux 7.0来週リリースへ rc7で最終確認
- Claudeサブスク、サードパーティ切り離しへ──OpenClaw問題の最終章
- Claude Codeソース流出が招いた罠：偽リポジトリがマルウェアを配布
- Red Hat流出メモ──AI全面移行を全エンジニアに号令
