2025年12月23日付のパッチメールで提案されたLinuxカーネルのAI支援文書は、2026年1月6日にコミット78d979db6cef557c171d6059cbce06c3db89c7eeとして取り込まれた。コミットメッセージは、これが2025 Maintainers Summitの合意に基づいて追加された文書だと説明している。ここで起きたのは、AIを禁じる宣言ではない。Linuxが、AI支援を使うときの人間責任、DCO、そして補助の記録をどのように並べるかを、既存の投稿規律の上に載せて明文化した、ということだ。

この動きは、カーネルの既存ルールを壊すものではない。Signed-off-byは人間が引き受ける法的・手続き的な責任線であり、Assisted-byはAI支援を使った事実の開示である。Linuxはその二つを分けた。AIを特別な例外にするのではなく、責任の所在を曖昧にしないための運用文書を増やしたのだ。

AD

何が新しく文書化されたのか

追加されたDocumentation/process/coding-assistants.rstは、AIツールがカーネル開発を手伝うときも標準の開発プロセスに従うべきだと整理している。対象はAIだけではない。READMEも更新され、AIコーディングアシスタントがこの文書を読んでから貢献するよう導線が敷かれた。つまり、AI支援は周縁の注意書きではなく、投稿の入口に組み込まれたわけだ。

文書の中身は、まずライセンスとSPDXである。カーネルへの貢献はGPL-2.0-onlyとの互換性を満たし、適切なSPDX識別子を使わなければならない。次に、Signed-off-byの扱いが明示された。AI agentsはSigned-off-byを付けてはならず、DCOを法的に証明できるのは人間だけだ。加えて、人間の提出者はAIが生成したコードをレビューし、ライセンス適合性を確認し、自分のSigned-off-byを付け、最終責任を持つ必要がある。

この時点で見えるのは、新しい法体系ではないということだ。既存のsubmitting-patches.rstには、sign-offが「そのパッチを書いた、またはオープンソースとして渡す権利がある」ことを示すと書かれているし、追加タグは定義されたものでなければ基本的に無視される。新文書は、その既存の考え方をAI支援のケースに合わせて読み替えたにすぎない。

Linux が問題にしているのは AI の利用そのものではなく投稿責任である

この更新の焦点は、AIを使ったかどうかではない。焦点は、誰がそのパッチを理解し、誰がそのパッチの責任を負い、誰がそれを提出できるのかである。Linuxは「AIが書いたから駄目」とは言っていない。むしろ、AIを使っても良いが、人間が内容を確認し、責任を引き受けることが条件だと定めている。

だから、この文書は「AI禁止令」ではなく、責任分担の明文化である。カーネル側が嫌うのは、ツールの種類そのものより、理解されていないコードが責任の所在を曖昧にしたまま流れ込むことだ。AIは速く草案を作れるが、パッチの正当性を証明する主体ではない。そこを分けるために、Signed-off-byは人間のまま残された。

development-processが以前から述べているように、元の開発者は長期的にもコードに責任を持ち続けるべきである。今回のAI文書は、その責任観を新しい作業手段に適用しただけだ。AI支援が入ったからといって責任の線が消えるわけではないし、Linuxが求めているのはまさにその線を保つことである。

AD

DCO と Assisted-by は何を分けているのか

ここで最も重要なのは、Signed-off-byとAssisted-byを同列に見ないことである。前者はDCOの核であり、提出者がそのパッチに法的責任を持つことを示す。後者は、AI支援を使った事実を記録するための属性だ。責任の証明と、支援の開示は別物である。

AI文書はAssisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]という形を示している。ここで挙げるのは、coccinelle、sparse、smatch、clang-tidyのような補助ツールであり、git、gcc、make、エディタのような基本ツールは含めない。つまり、このタグは「何が作業に関与したか」を簡潔に示すためのもので、日常的な開発道具まで全部列挙するためのものではない。

この分離が効く理由は、既存ルールと矛盾しないからだ。submitting-patches.rstは追加タグを定義済みのものに限って扱い、Signed-off-byの最後は提出者でなければならないとする。Assisted-byはそこに新たに加わる開示タグだが、DCOの代わりではない。両者を混ぜると、AIが法的な提出主体であるかのような誤読になる。Linuxはその誤読を避けるために、責任の線と開示の線を分けたのである。

なお、現行のマージされたベースラインではAssisted-byは「含めるべき」という書き方であり、Signed-off-byと同じ硬さの必須署名として読むのは危うい。ここを強く言い切りすぎると、Assisted-byがDCOそのものに見えてしまう。この記事で押さえるべきなのは、AI支援の記録は必要だが、法的証明は人間に残る、ということだ。

実務上の含意と、Hacker News で混線しやすい論点

実務では、この整理はかなり具体的だ。カーネルに関わる開発者がAIを使うなら、コードをどう作ったかより、最終的に自分がどこまで理解し、どう責任を負うかが問われる。企業やチームにとっても、レビュー、ライセンス確認、署名、AI支援の開示を、日々のパッチ運用にどう埋め込むかが論点になる。AIを導入する話は、結局のところ開発フローの設計問題に落ちる。

Hacker Newsでも、反応は二つの方向に割れた。あるユーザーは「正気で退屈」と受け取り、別のユーザーはbanに見えるのではないかと議論している。

判断の軸はもっと単純である。LinuxはAIを禁じていない。だが、AIが書いたものをそのまま提出して良いとも言っていない。人間がレビューし、人間がSigned-off-byを付け、人間が責任を持つ。そのうえで、AI支援はAssisted-byで記録する。この運用に乗れるなら、AIはカーネル開発の補助具として使える。乗れないなら、問題はツールではなく、責任の持ち方にあるのだ。

Sources