2025年12月23日にパッチメールで提案され、2026年1月6日にLinuxカーネルのソースツリーにコミットされた coding-assistants.rst。この59行の文書は、2025年のMaintainers Summitでの議論を経て、AI生成コードをどう扱うかの公式ルールを定めたものです。
この記事では、20年近くサーバーを運用してきた経験から、このポリシーが何を意味するのか、そしてAI時代にLinuxエンジニアとして何が求められるのかを、私なりの視点で語ります。
【この記事でわかること】
・Linuxカーネルが採択したAIコード受入れポリシーの核心
・Signed-off-byとAssisted-byタグの役割と意味
・他のOSSプロジェクトとの対応の違いから見えるLinuxの合理性
・AI時代にLinuxエンジニアに求められる姿勢
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
Linuxカーネルが策定したAIコードポリシーとは何か
2026年1月6日、コミット78d979db6cefとしてマージされたcoding-assistants.rstは、たった59行の文書です。しかしその中身は、非常に明快な原則で貫かれています。ポリシーの核心は一言で言えば「人間が全責任を負う」ということです。
AI生成コードを提出する開発者は、すべてのコード行を完全にレビューし、Signed-off-byタグを付与して法的責任を引き受けなければなりません。AIエージェントがSigned-off-byを付けることは厳禁です。法的責任を負えるのは人間だけだからです。
さらに、AI支援を受けた場合はAssisted-byタグで明記することが求められます。形式は
Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2] と定められており、どのAIツールを使ったかが後からgrepで追跡できるようになっています。Linus Torvaldsは、AIの包括的な禁止を「meaningless self-satisfaction（無意味な自己満足）」と呼びました。「AIスロップについて議論すること自体が愚かだ」とまで言い切っています。低品質なコードを書く開発者は、どんなツールを使っても低品質なコードを書く。ツールを監視するより、提出者に責任を負わせる方が効果的だ、と。
私はこの考え方に強く共感しました。
「道具に罪はない」というLinux文化の本質
セミナーで3,100名以上を指導してきた中で、受講生から繰り返し聞かれる質問があります。「このツールを使っていいですか」「この方法は邪道じゃないですか」。たとえばconfigureスクリプトが登場した頃、「手動で設定ファイルを書くのが本物のエンジニアだ」と言う人がいました。ansibleが普及した頃にも「手作業でやらないと理解が深まらない」と主張する人がいました。そして今、AI支援ツールに対しても同じ議論が繰り返されています。
Linuxカーネルのポリシーは、この議論にはっきりとした答えを出しました。道具が何であるかは問わない。しかし、その道具で生み出したものに対する責任は、人間が引き受ける。
20年近くサーバーを運用してきた経験から言うと、サーバーの障害対応で重要なのは「誰がどのツールでデプロイしたか」ではなく、「誰がその変更に責任を持っているか」です。深夜3時に電話が鳴ったとき、対応するのは人間です。AIが代わりに謝ってくれるわけではありません。
Signed-off-byの仕組みは、まさにこの原則を体現しています。1991年のカーネル開発初期からある「名前を署名する」という文化が、AI時代にも有効に機能しているのです。
他プロジェクトと比較して見える「Linuxの合理性」
このポリシーの意味をより深く理解するために、他のオープンソースプロジェクトの対応と比較してみます。GentooとNetBSDは、AIの訓練データに著作権が不明確な素材が含まれる可能性を理由に、AI生成コードを完全に禁止しました。cURLプロジェクトでは、低品質なAI生成コードがメンテナーの処理能力を圧迫し、バグバウンティプログラムを中止する事態にまで追い込まれています。
一方でLinuxカーネルは、厳格な人間責任を条件に「条件付き許可」という道を選びました。
この判断の背景には、GPL-2.0ライセンスの法的優位性もあります。GPLで訓練されたAIがLinuxパッチに類似コードを再現しても、既存ライセンスと一致するため法的問題が生じにくい。BSDライセンスのプロジェクトはGPLコードを法的に吸収できないため、汚染リスクがより深刻になります。
さらにAssisted-byタグは、Torvaldsが「フォレンジックツール」と呼ぶ機能を持っています。後日、特定のAIモデルとバグパターンの相関をgrepで追跡できるのです。禁止するのではなく、記録して追跡可能にする。この発想は実に合理的です。
私が現場でよく見かけるのが、「問題を禁止で解決しようとする」パターンです。しかし禁止は監視コストを生み、秘匿を誘発します。実際に、過去にはAI利用を秘匿した開発者が提出したコードがパフォーマンス劣化を引き起こした事例も報告されています。Linuxの「禁止ではなく透明性」というアプローチは、長年のオープンソース開発から得た知恵だと感じます。
AI時代にLinuxエンジニアとして求められるもの
では、このポリシーは現場のLinuxエンジニアにとって何を意味するのでしょうか。レビュー時にAI生成修正の約3分の1が訂正を要するというデータがあります。つまり、AIが書いたコードをそのまま提出することは、カーネルの品質基準では通用しません。AIの出力を正しく評価し、問題を見抜ける力が求められます。
これは、カーネル開発者に限った話ではありません。
サーバー構築の現場でも、AIが提案した設定をそのままコピーして適用するエンジニアと、その設定が自社環境で安全かどうかを検証してから適用するエンジニアでは、障害発生率に大きな差が出ます。
セミナーで3,100名以上を指導してきた中で、伸びる受講生に共通しているのは「なぜそうなるのかを自分で理解しようとする姿勢」です。AI時代にはこの姿勢がより一層重要になります。便利なツールが増えるほど、「理解せずに使う」誘惑も増えるからです。
Linuxカーネルのポリシーが私たちに突きつけているのは、結局シンプルなことです。「あなたはそのコードの意味を理解していますか。責任を持てますか。」
まとめ
| 項目 | 内容 |
|---|---|
| 策定時期 | 2026年1月6日（コミット78d979db6cef） |
| 文書名 | coding-assistants.rst（59行） |
| 核心ルール | 人間がSigned-off-byで全責任を負う |
| 透明性の仕組み | Assisted-byタグでAI使用を明記 |
| 他プロジェクトとの違い | 禁止ではなく条件付き許可 |
| エンジニアへの示唆 | AIの出力を評価・検証できる力が不可欠 |
AIを使うかどうかは個人の選択です。しかし何を使うにしても、自分が扱う技術を理解し、その結果に責任を持つ。この原則だけは、これからも変わらないはずです。
AIに頼る前に、Linuxの基礎力を固めたい方へ
AIツールを活かすにも、土台となるLinuxの知識がなければ出力の正しさを判断できません。まずはサーバー構築の基本を体系的に押さえることが、AI時代を生き抜く最短ルートです。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として15年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。