Linuxカーネルの開発で、AIの利用を申告するための「Assisted-by」タグが必須ではなくなった。招待制のLinux Kernel Maintainer Summitでの議論を受け、Sasha Levin氏が2026年10月9日に要件を削除するパッチを提出し、10月14日にJonathan Corbet氏が取り込んだ。その後、Linux 7.4向けのDocumentation更新として、10月21日までにLinus Torvalds氏が管理する本流リポジトリへマージされた。ただし、正式リリース済みのLinux 7.3の文書には、従来の要件が残っている。

変更の背景には、AI利用の申告が十分に機能していなかったという事情がある。Linux 7.3のリリース候補第7版（-rc7）までに取り込まれた非マージコミットのうち、Assisted-byタグが付いていたのは約10%にとどまった。一方、AIに開発者証明の署名を付けさせない規定や、内容を理解・説明できないパッチをメンテナーが却下できる規定は維持されている。Torvalds氏もThe Registerのコラムニスト、Steven J. Vaughan-Nichols氏に宛てたメモで、問題なのはAIの利用そのものではなく、コードを理解しないままパッチを提出することだと説明した。今回の変更は、AIを使ったかどうかの形式的な申告よりも、提出者が成果物に責任を持てるかを重視する方向への転換といえる。

AD

Linux 7.0から7.4へ、AI利用の申告ルールはどう変わったのか

Levin氏が10月9日に提出した最初のパッチは、4つのファイルを変更し、1行を追加して51行を削除するものだった。コミットメッセージもわずか2文という簡潔な内容だったが、最終的に本流へ取り込まれた版（コミット 1e03529）では、変更範囲が1行追加・88行削除へと拡大した。イタリア語、ブラジルポルトガル語、繁体字中国語の翻訳文書も対象となっている。コミットメッセージには、Linux 7.3の-rc7までの非マージコミット18,533件のうち、タグ付きが約10%にすぎなかったことや、メンテナーサミットで全会一致ではないものの、要件の削除に強い支持が集まったことが理由として追加された。7月の議論ではタグの維持を主張していたGreg Kroah-Hartman氏も、今回は削除を支持する立場に変わったという。

具体的には、coding-assistants.rst からAssisted-byタグの書式と使用例を説明する節が丸ごと削除された。また、submitting-patches.rst からは、タグによるAI利用の明示を求め、記載しなければパッチの取り込みに支障が生じる可能性があるとした記述がなくなった。パッチの形式を検査する checkpatch.pl でも、認識対象の署名タグ一覧から Assisted-by: が削除されている。さらに、AIによるバグ修正の手順6は、従来の「Signed-off-byを付けず、Assisted-byタグを付ける」から、「Signed-off-byを付けない」という指示だけに変更された。ただし、このパッチにはAssisted-byタグの使用そのものを禁止する記述はない。

coding-assistants.rst の変更履歴を比較すると、AI利用の申告方法が段階的に簡素化されてきたことが分かる。Linux 7.0から7.2ではAIエージェント名とモデルのバージョンを記載する形式だったが、7.3では大規模言語モデルを表す「LLM」という一般的な表記に置き換えられた。そして次期版向けの文書では、帰属表示の節そのものが削除されている。

Linuxの版・文書の状態 Assisted-byの書式 バグ修正手順6 AIによるSigned-off-by
v7.0、v7.1 Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2] 該当する手順の節なし 禁止
v7.2 同上 Signed-off-byを付けず、Assisted-byタグを付ける 禁止
v7.3（10月18日時点の現行版） Assisted-by: LLM [TOOL1] [TOOL2] 同上 禁止
linux-next向け（10月23日時点） 該当する節なし Signed-off-byを付けない 禁止
本流master（10月24日確認） 該当する節なし 同上 禁止

この比較から明らかなのは、変更されたのがAIの利用をどう記録するかという規則であり、提出者の責任を定めた規則ではないという点だ。表に示した各版では、AIにSigned-off-byを付けさせない規定が一貫して維持されている。Assisted-byタグがなくなっても、人間がパッチの内容と出所に責任を持つ仕組みは変わらない。

Signed-off-by は、パッチのコミットメッセージ末尾に付ける署名行で、提出者がDCO（Developer Certificate of Origin、開発者による出所証明）に同意したことを示す。DCOは、寄稿するコードを提出する権利が自分にあることなどを、開発者自身が宣言するための仕組みだ。カーネルの文書では、法的な意味を持つこの証明を行えるのは人間だけだと定めている。したがって、AIが生成したコードであっても、人間の提出者が内容をすべてレビューし、ライセンスへの適合性を確認したうえで、自分のSigned-off-byを付ける必要がある。

Assisted-byタグは、こうした責任の所在を示す署名とは異なり、AIを開発に利用した事実を記録するためのものだった。その要件が削除されても、提出者がパッチの内容を理解し、責任を負うという原則は維持される。AIがコードの大部分を生成したとしても、責任の主体は署名した人間のままだ。

さらに、今回の削除パッチは、別の文書である generated-content.rst には手を加えていない。この文書では、署名者以外が作成したツール生成物が提出物に相当量含まれる場合、カバーレターとコミットメッセージを通じて、その出所を明らかにするよう求めている。カバーレターとは、複数のパッチをまとめて提出する際に先頭へ添え、変更全体の目的や経緯を説明するメールだ。使用したツール、プロンプトの概要、AIが関与した部分、実施したテストなどが、開示する情報の例として挙げられている。

同文書は、提出者がパッチの内容を完全に理解し、その変更を説明・正当化できなければならないとも定めている。理解できない場合は提出すべきではなく、それでも提出されたパッチについては、メンテナーが詳細なレビューをせずに却下できる。追加のテストを求めたり、レビューの優先順位を下げたりすることも認められている。この規定はLinux 7.3の coding-assistants.rst からすでに参照されており、今回新たに導入されたものではない。つまり、Assisted-byタグの要件がなくなっても、AI生成物の出所に関する透明性と、提出内容を理解・説明する責任は引き続き求められる。

7月には維持されたAssisted-by要件が、10月に削除された経緯

LinuxカーネルでAIの利用方法を文書化する動きは、今回が初めてではない。2025年7月25日、Sasha Levin氏は「Add initial set of rules and docs」という件名で、AI利用に関する初期ルールを追加するパッチを提出した。このパッチは Documentation/AI/main.md に68行の規則を追加するもので、AIの関与をコミットで明示することや、AIにSigned-off-byを付けさせないことなどが盛り込まれていた。ただし、この文書は後に追加された coding-assistants.rst とは別のファイルである。

Linux 7.0では coding-assistants.rst が追加され、LWNによれば、Assisted-byタグの使用を求める記述もこのとき導入された。その後、2026年7月2日、Jeff Layton氏がLLMの帰属表示要件を削除するパッチを提出した。Layton氏は、要件が導入されてから数カ月が経過したものの、得られる情報の信号対雑音比が非常に低いと指摘している。理由として挙げたのは、規則が一貫して守られていないこと、プロプライエタリなLLM企業の無料広告になっていること、そして何のために情報を収集するのかが明確でないことの3点だった。

この提案に反対したのが、主要メンテナーのGreg Kroah-Hartman氏だった。同氏は、タグに記載する名前や形式は重要ではなく、LLMが使われているという情報そのものが必要だと主張した。利用が分かれば、それを踏まえてパッチをレビューでき、申告内容が虚偽であれば責任は提出者にあるという考えだ。自身が担当するサブシステムでは、すでに複数のパッチでタグが役立っており、今後はAIを使う場面も増えると説明していた。この段階では、Assisted-byタグの要件は維持された。

7月14日には、AIによるカーネルパッチの自動レビューを行う「Sashiko」をめぐる議論の中で、Torvalds氏がAI利用に対する自身の立場を明らかにした。同氏は「Linuxは反AIのプロジェクトではない」と述べ、AIはほかの開発ツールと同じく、明らかに役立つ道具だと説明している。この発言はAssisted-byタグについて直接述べたものではないが、Linuxカーネル開発がAIの利用そのものを否定していないことを示していた。

転機となったのが、10月8日にプラハで開催された招待制のLinux Kernel Maintainer Summitだ。約30人が参加した1日限りの会合で、LWNのJonathan Corbet氏による記録では、議論の中心はLLMの利用だった。翌9日、Levin氏がAssisted-byタグの要件を削除するパッチを提出すると、Krzysztof Kozlowski氏は、以前の合意を覆す変更であるにもかかわらず、理由が十分に説明されていないと指摘した。要件を変更すること自体には反対しないものの、方針転換の根拠を示すべきだという立場だった。

7月にはLayton氏の削除提案にKroah-Hartman氏が反対し、要件が維持された。それから約3カ月後、メンテナーサミットの翌日にLevin氏が同じ趣旨のパッチを提出し、今回はKroah-Hartman氏も削除を支持する側に回った。パッチは10月14日に取り込まれ、21日までに本流へマージされた。この方針転換を支えたのが、サミットで要件の廃止に強い支持が集まったことと、タグの利用率が約10%にとどまっていたという実績だった。

AD

Assisted-byタグ付きは約10%、自己申告が機能しなかった理由

Linux 7.3の-rc7までに取り込まれた非マージコミット18,533件のうち、Assisted-byタグが付いていたのは1,884件で、全体の約10.2%だった。ただし、この数字をAI利用者の申告率や規則の遵守率と解釈することはできない。分母はAIを使ったコミットではなく、すべての非マージコミットであり、実際にAIを利用した変更が何件あったかは分からないからだ。Corbet氏は、LLMを利用して作成されたパッチの実数は、この数字よりはるかに多いはずだと見ている。

Corbet氏自身も、メンテナーサミットでタグの実効性について問題を提起した。LLMを使いながらタグを付けない投稿者は多く、規則を知らない人もいれば、AIを使ったことを意図的に隠そうとする人もいるという。さらに、タグが付いているかどうかを確認するメンテナーも少ないため、結果としてタグが有用な判断材料になっていないと指摘した。そのうえで、規則を確実に守らせる方法を考えるか、要件そのものを廃止するかの二択を提示している。ただし、タグが有用な信号になっていないというのはCorbet氏の評価であり、サミットの公式な結論として示されたものではない。

自己申告に基づくタグが有効に機能するには、提出された情報を確認する仕組みが必要になる。タグの記載漏れがあっても、メンテナーが確認していれば不備を指摘できる。しかし、確認がほとんど行われなければ、タグがないことはAIを使っていない証拠にはならない。Corbet氏の指摘は、後者の状況が広がっているというものだった。

一方、タグをレビューの手がかりとして活用していたメンテナーもいる。Laurent Pinchart氏は10月13日、Assisted-byタグが欠けていることを理由にパッチのレビューで説明を求めており、付け忘れではないかと質問しても返答がない場合が多いと述べた。ただし、同氏もタグをGitのコミット履歴に残すこと自体には大きな意味を感じておらず、AI利用の説明をカバーレターに記載させる方法を提案している。この案に対する支持は少なかったという。

LWNの記録によると、Torvalds氏は、タグの記載要件がLLMの利用をためらわせる可能性があるとして、削除に賛成した。AIを使っていると認めることを恥ずかしく感じる提出者が少なくないとも考えていたという。一方、Shuah Khan氏はタグが今も有用だと主張した。それでもCorbet氏は、会場全体ではタグが役割を終えており、要件を廃止してよいという強い合意が形成されたと記録している。

ただし、AIがどのように使われているかを把握したいという関心までなくなったわけではない。サミットでは、使用したモデルやAIを利用した開発工程を知りたいという意見もあり、その情報はコミットメッセージではなく、カバーレターに記載する案が出された。今回なくなったのは、Assisted-byという特定のタグを使った申告義務であり、AI利用の経緯を説明すること自体が不要になったわけではない。

Torvalds自身のAI支援パッチ、最大23倍の性能向上とその条件

Torvalds氏は10月13日、Linux Kernel Mailing List（LKML）とlinux-mmに、メモリページの参照カウント処理を改善するパッチシリーズを投稿した。メンテナーサミットでLLMの利用が大きな議題になることを踏まえ、長年取り組んできた問題を実際にLLMの助けを借りて解決してみることにしたという。対象となったのは、多数のCPUが同時にファイルを読み出す際に、ページの参照カウント処理が性能上のボトルネックになる問題だ。特に、通常の pread() などによる読み出し処理で、その影響が大きくなっていた。

10本のパッチからなるこの改良では、Ryzen Threadripperを使ったテストで最大23倍の性能向上が確認された。ただし、Torvalds氏自身が、非常に人工的な条件で得られた結果だと注意を促している。テストでは、同じページ内の小さな領域をすべてのCPUスレッドが繰り返し読み出しており、実際のアプリケーションで得られる改善幅は、これよりはるかに小さいと説明している。

問題の原因は、ページキャッシュに存在するフォリオの参照カウントを、複数のCPUが頻繁に更新することにあった。フォリオとは、1ページ以上の連続したメモリをまとめて管理する単位だ。通常の read() では、フォリオの読み出し中に参照カウントを増やし、処理が終わると減らす。しかし、多数のCPUスレッドが同じフォリオを読み出す場合、参照カウントが保存されているキャッシュラインを各CPUが繰り返し更新しようとするため、CPU間のキャッシュ整合性維持に伴う負荷が増える。この影響によって、64スレッドでの読み出し性能は毎秒1,330万回程度で頭打ちになっていた。

Torvalds氏の提案は、頻繁に読み出されるフォリオに特別な印を付け、その解放をRCU（Read-Copy-Update）の猶予期間が経過するまで遅らせるというものだ。RCUは、読み出し側の処理を止めずに、データの解放を安全な時点まで延期できる仕組みである。フォリオの解放が遅延されることを利用し、ページフォールトが発生しない限り、読み出し処理をRCUの保護下で完了できるようにする。これにより、従来必要だった参照カウントの増減を省略でき、複数のCPUが同じキャッシュラインを書き換える競合を減らせる。実測では、64スレッドでの読み出し性能が毎秒約1,330万回から約3億400万回へと向上した。

興味深いのは、Torvalds氏自身がコミットメッセージの作成にもAIを利用していた点だ。同氏は、道具を使わずに自分で書くよりもメッセージが少し冗長になったと認めながら、それがかえって良い結果につながっている可能性もあると述べている。少なくとも、AIの使用を隠すのではなく、利用した経緯と検証条件を説明する姿勢を示していた。

先行する noref-filemap-read-with-llm ブランチについては、Phoronixが10月11日、コミットメッセージの内容を紹介している。それによると、コードやテストプログラム、性能比較に用いたレビュー、説明文の初稿などは、Torvalds氏の指示に基づいてAIコーディング支援ツール「Claude Code」が生成し、性能測定は本人のマシンで実施したという。ただし、10月13日のメーリングリストへの投稿にはClaude Codeという製品名は登場しない。同投稿ではLLMを使った事実に加え、測定条件や従来の試行錯誤について、Torvalds氏自身が詳しく説明している。単にAssisted-byタグを付ける場合と比べ、レビュー担当者が判断に使える情報は多い。

LWNのサミット記録によると、Torvalds氏は会合の前週まで、カーネル開発にLLMを使ったことがなかったという。また、AIが不適切な応答を返さないように作業環境を整えるまで、6カ月を要したとも説明している。こうした準備を経て、実際の性能改善にAIを利用する試みを始めたことになる。

その後、10月19日にはMeta所属のKiryl Shutsemau氏が、Torvalds氏の提案を再構成した18本のRFC（意見募集用）パッチを投稿した。性能測定にはThreadripper 7975WX上で動作する64 vCPUのKVMゲストを使用し、ext4ファイルシステム上で64スレッドが16バイトの pread() を繰り返す条件を設定した。その結果、読み出し性能は毎秒1,500万〜1,570万回から、6,890万〜7,010万回へと向上した。CPUの脆弱性対策は、既定の設定のまま有効にしていたという。

ただし、この結果をTorvalds氏の最大23倍という改善率と直接比較することはできない。テストに使用した環境も、パッチの実装内容も異なるためだ。それでも、LLMの支援を受けて作成された提案が、別の開発者によって再構成され、改めて測定されるという、通常のカーネル開発プロセスに組み込まれたことは確認できる。

これらの事例で重要なのは、AIを使用したという事実だけでなく、何を変更し、なぜ性能が改善し、どのような条件で測定したのかが説明されている点だ。AIが生成したコードであっても、開発者が変更の意図と動作を理解し、測定条件を示すことができれば、レビュー担当者は技術的な妥当性を検証しやすくなる。日本の開発者がAIの支援を受けたパッチをLinuxカーネルへ提出する場合も、タグの有無だけでなく、変更理由や検証方法を具体的に説明することが重要になる。

AD

コミットメッセージは人間が書くべきか、サミットの合意とTorvaldsの見解

Assisted-byタグの削除をめぐっては、AI利用の透明性をどのように確保するかという議論も続いている。Laurent Pinchart氏は10月13日、別の開示方法を用意しないままタグだけを削除することに不満を示した。さらに、Mesaプロジェクトのように、コミットメッセージを人間が自分で書くことを求める方針をLinuxカーネルにも導入できるのではないかと提案している。AIによって生産性が向上したと主張する開発者が、なお開発工程全体を自分で管理しているというのであれば、コミットメッセージを手作業で書く負担は小さいはずだという考えだった。

これに対し、Kees Cook氏は、人間がコミットメッセージを書くべきだという原則には賛成しつつ、Assisted-byタグと同様に、その規則を強制することは難しいと指摘した。また、自身のコミットログも、自分とLLMによる共同作業の成果だと説明している。AIを文章作成の補助に使うことと、開発者が説明責任を負うことは、必ずしも両立しないわけではないという立場だ。

Pinchart氏は、強制できないという理由だけで規則を設けないのであれば、Signed-off-byの要件も同じ理由で不要になるはずだと反論した。カーネル開発には技術的に完全な強制が難しい規則が数多く存在するものの、それでも開発者に期待する行動を明文化することには意味があるという。特にAIの利用が広がっている現在は、何を求めるかを明確にしておく必要があると主張した。

この反論は、Assisted-byタグを削除する理由を考えるうえで重要な論点を含んでいる。強制の難しさだけを理由にするのであれば、ほかの自己申告に基づく規則との違いを説明しにくい。今回残された規定と削除された規定の違いは、強制できるかどうかだけでなく、何を確認するためのものかという点にもあると考えられる。Assisted-byタグが開発に使った道具を示すのに対し、Signed-off-byやパッチを説明できることを求める規定は、提出者の責任と理解を確認するためのものだからだ。ただし、これは一連の議論から導ける解釈であり、サミットが公式に示した説明ではない。

Torvalds氏は同日、Pinchart氏の提案に直接返信し、AIを特定の作業に使うべきではないという考え方に疑問を呈した。同氏は皮肉を込めて、パッチの提出にコンパイラを使うな、コミットメッセージを書くのにエディタを使うなと言うのと変わらないと指摘している。そして、開発者に期待するのは最善を尽くし、自分が何をしているのかを理解することであり、その理解は使用する道具とはほとんど関係がないと述べた。重要なのは、AIを利用したかどうかではなく、成果物を理解し、責任を持って提出できるかという考え方だ。

一方、LWNの記録では、メンテナーサミットにおいて、コードをLLMが生成したとしてもコミットメッセージは人間が書くべきだという大筋の合意があったとされている。しかし、Torvalds氏自身は、その5日後に投稿したパッチシリーズについて、道具を使ったことでコミットメッセージが冗長になったと説明していた。また、Vaughan-Nichols氏へのメモでは、AIにコミットメッセージを書かせるべきではないという主張を見当違いだと評している。善意に基づく意見ではあるとしながらも、有能な開発者にはAIを道具として積極的に活用してほしいという立場を示した。

つまり、サミットで共有されたとされる考え方は、人間がコミットメッセージを書くことを重視している一方、Torvalds氏自身の実践と発言は、AIによる文章作成の支援を認める方向にある。ただし、LWNが記録した合意は正式な規則ではなく、Corbet氏による会合の解釈を含んでいる。また、Vaughan-Nichols氏が紹介したTorvalds氏の見解も、同氏に宛てた私信の引用だ。Torvalds氏のパッチはAIを使用した事実を明示しており、今回の規則変更に反するものではない。

現時点で、Linuxカーネルの文書には、コミットメッセージを必ず人間が手作業で執筆しなければならないという明文規定はない。generated-content.rst は、AIなどが生成した内容の出所について透明性を確保し、提出者がパッチを理解・説明することを求めているが、コミットメッセージの執筆者を人間に限定してはいない。内容を理解できない提出を却下する規定は残る一方、開示の方法や説明の十分性をどこまで求めるかは、個々のメンテナーの判断に委ねられる部分が大きい。

AI生成パッチの急増にどう対応するか、タグ廃止後も残る責任

Torvalds氏はVaughan-Nichols氏へのメモで、AIの普及によって表面化した問題を2つ挙げている。一つは、AIが大規模なコードベースから実際のバグを発見するようになり、すでに多忙なメンテナーの仕事がさらに増えることだ。もう一つは、コードを十分に理解しないまま、AIにパッチを生成させて投稿する人が現れることである。同氏は、どちらもAIそのものが原因というより、AIによって既存の問題が顕在化したものだと考えている。

特に後者について、Torvalds氏は、新しい技術を学ぼうとする開発者を妨げるつもりはないとしながらも、投稿後の対応に責任を持たない「ドライブバイ・パッチ」や、パッチを送ること自体を目的とするような投稿は抑えたいと述べている。問題はAIを利用したかどうかではなく、投稿者が内容を理解し、その後のレビューや修正に対応できるかという点にある。

こうした懸念の背景には、カーネル開発に参加する新規投稿者の増加がある。Corbet氏によると、Linux 7.3では初回貢献者が800人近くに達した。LWNの記録では、Torvalds氏は問題を、カーネルの仕組みを十分に知らない人からのパッチが増えていることにあると捉え、その原因をLLMだけに求めるのは適切ではないと主張した。対策として、AIによる自動レビューを行うSashikoの報告を24時間遅らせる案や、こうした投稿のレビュー優先度を下げることを挙げている。また、新規投稿者がコードを提出する際のハードルを高くする時期が来たとの考えも示した。ただし、AIを利用しない開発者を排除する意図はないと、Pinchart氏からの確認に答えている。

AIによるバグ報告の増加については、Greg Kroah-Hartman氏も見通しを示している。同氏は、今後18カ月ほどは大量のバグ報告が寄せられるものの、その後は多くのバグが修正され、状況が落ち着くと予想している。ただし、これは同氏の見立てであり、実際にその期間で負担が減るかどうかは今後の推移を見なければ分からない。

そもそも、Assisted-byタグは大量のバグ報告や低品質なパッチへの対策として設けられたものではない。内容を理解しないまま提出されたパッチには、人間の署名者が責任を負う規定や、説明できない変更を詳細なレビューなしに却下できる規定が引き続き適用される。メンテナーには追加のテストを求めたり、レビューの優先度を下げたりする裁量も認められている。AI利用の経緯をカバーレターで説明する運用が広がれば、こうした判断に必要な情報を提出者自身が示すことにもつながる。

Assisted-byタグの要件削除は、次期Linux 7.4向けの本流にすでに取り込まれている。今後は正式リリースでの文書の確定に加え、AI利用の経緯をカバーレターなどで説明する運用がどこまで定着するかが注目される。コミットメッセージの執筆にAIを使うことについても、開発者とメンテナーの間で議論が続く可能性がある。

今回の変更によって、LinuxカーネルがAI生成コードの受け入れ条件を無条件に緩めたわけではない。人間がSigned-off-byで責任を負い、自分の提出した変更を理解・説明できなければ、パッチは詳細なレビューを受けることなく却下される可能性がある。この原則を維持したまま、カーネル開発で重視されるのは、AIという道具を使った事実の申告から、その成果物を提出者が理解し、技術的に説明できるかという実質的な確認へと移りつつある。