Linux KernelのAGENTS.md提案、AIエージェントが人間のルールに従えるかを検証
Linux kernelのAGENTS.md提案が加えるのは、わずか1つのシンボリックリンクだ。しかし、AI支援によるコードをめぐって深まりつつある対立を対象としている。2026年9月24日に提出されたこのパッチは、コーディングエージェントがkernelの既存指示を自動的に見つけやすくするものだ。
提案されたファイルは、自律的な貢献を許可したり、kernelのレビュー基準を緩和したりするものではない。AIツールをプロジェクトの詳細な貢献ポリシーへすでに案内しているREADMEを、エージェントへ示すだけである。この変更が扱うのは、より限定的な問題だ。エージェントは、人間向けに書かれたドキュメントを読む前に行動してしまうことが少なくない。
この区別は重要である。kernelはすでに、AIツールに対して人間に代わってパッチを証明しないよう指示している。また、人間によるレビュー、適切な帰属表示、テスト、そして責任も求めている。そのためLinux kernelのAGENTS.md提案は、発見しやすい指示と、より厳しい現実を対置する。リポジトリ内のファイルはエージェントを導けても、信頼できないパッチを信頼できるものにはできない。
Linux KernelのAGENTS.md提案は入口を1つ変える
このパッチは、エージェントが既存ルールを見つける方法を変えるだけで、ルール自体は変更しない。
kernelメンテナーのSasha Levinは、「docs: add AGENTS.md as a symlink to README」と題するパッチを提出した。この提案は、リポジトリに既存のREADMEファイルを指す、トップレベルのAGENTS.mdというシンボリックリンクを作成する。
シンボリックリンクは、あるファイル名を別のファイルへリダイレクトするファイルシステム上の参照だ。この場合、エージェントがAGENTS.mdを開くと、指示の複製ではなく、READMEですでに利用可能な同じ内容を受け取ることになる。
この設計は、メンテナーが同期を維持しなければならない2つのポリシー文書を作ることを避ける。Levinのシンボリックリンク提案によると、既存のREADMEはすでにAIツールをDocumentation/process/coding-assistants.rstへ案内している。問題は、その案内が役立つ前に、エージェント自身がREADMEを開く判断をしなければならないことだ。
多くのコーディングエージェントは、特別な名前の指示ファイルを自動的に調べる。AGENTS.mdは、ビルドコマンド、テスト要件、コーディング規約、安全上の境界など、リポジトリレベルの指示に使われる一般的なファイル名の1つになっている。
提案されたkernelファイルには、独立した文章は含まれない。その内容はリンク先であるREADMEだけだ。これにより、人間と機械の入口は、単一の管理対象ソースに結び付けられる。
Levinは、発見可能性が重要である理由を説明するため、統制された例を示した。2つのエージェントに対し、Makefile内のkernelリリース名を「AI Test」へ変更するコミットを作成するという同一の依頼を与えた。
AGENTS.mdがない場合、片方のエージェントはユーザーのためにSigned-off-by行を生成した。もう一方はAIによる帰属表示を付けなかった。いずれの結果も、kernelが文書化している期待に反していた。
シンボリックリンクがある場合、報告によれば両エージェントはAssisted-by: LLMタグを使用し、人間の署名を追加しなかった。また、プロジェクトのコミットメッセージ規約にもより厳密に従った。片方は説明的な本文を加え、もう一方は想定される「subsystem: summary phrase」という件名構造を使った。
これは限定的な挙動テストであり、エージェントの信頼性を広範に評価したものではない。エージェントが微妙なバグを見つけられるか、安全な修正を作れるか、サブシステム固有の制約を理解できるかは測定していない。自動的に発見される既存指示への経路を与えられた後、2つのエージェントが異なる挙動を示したことを表している。
報道時点で、この変更はなおレビュー中だった。したがって、Linuxがすでに採用したものとして説明するのは事実を誇張することになる。正確には、kernelメンテナーがこのリンクを提案し、それを裏付ける証拠を提示した、ということだ。
著名なkernelセキュリティ開発者であるKees Cookは、了承の意を示して応答した。彼は、エージェント専用の別ポリシーを維持するのではなくREADMEを使う方法を支持した。彼のレビュー応答でも、エージェントがパッチを作成する前に貢献ドキュメントを読むことが望ましいと指摘された。
このパッチは小さく、儀礼的なものに見えるほどだ。しかし、実用上の目的は明確である。AIツールがすでに調べるよう訓練または設定されている経路上に、必須のプロセス情報を置こうとしている。
つまり、この提案はインターフェースの変更だ。人間はドキュメントツリーを参照し、コミュニティの規範を解釈できる。コーディングエージェントは、ツールが認識するファイル名やパスを通じてそれらの規範が公開されると、より予測可能に動作する。
ここで問われるのは、Markdownが生成コードを改善できるかどうかではない。信頼できる入口が、メンテナーが手作業で検出する前に、繰り返されるプロセス上の誤りを防げるかどうかである。
既存のKernelルールでも責任は人間に残る
Linux kernelのAIポリシーは、エージェントをあくまで支援者として扱い、貢献の法的・技術的な責任者とは見なさない。
基礎となるルールは、提案されたシンボリックリンクよりすでに大幅に踏み込んでいる。kernelのAI貢献ガイドは、AIツールとその利用者に対し、標準の開発プロセス、コーディングスタイル、パッチ提出要件、ライセンスルール、生成コンテンツのポリシーを案内している。
最も重要なのは、AIエージェントがSigned-off-byタグを追加してはならないとガイドが定めていることだ。この行は装飾的なコミットメタデータではない。一般にDCOと呼ばれるDeveloper Certificate of Originに基づく、人間による証明を表す。
DCOは、提出された作業がそのライセンスの下で合法的にプロジェクトへ導入できることを、貢献者が表明するための仕組みだ。言語モデルは人間に代わってその証明を行えない。また、その人物が責任を負うために必要なレビューを完了したかどうかも判断できない。
人間の提出者は、生成されたコードをレビューし、ライセンス遵守を確認し、署名を追加して、貢献に対する責任を負わなければならない。エージェントが署名そのものを挿入すると、これらの別個の手順が生成テキストにまとめられてしまう。
だからこそ、Levinのテストは範囲が小さくても重要である。エージェントは単に不評な書式を選んだだけではない。人間だけが正当に行える表明を生成したのだ。
kernelのドキュメントは、AIの関与には別のマーカーを割り当てている。AIツールが貢献した場合、パッチはAssisted-byタグを使用すべきである。Coccinelle、Sparse、Smatch、Clang-Tidyといった任意の解析ツールも、LLMラベルの後に記載できる。
この帰属モデルは、支援と著者性・証明を区別する。モデルが責任を負えるふりをせずに、レビュー担当者へ有用な文脈を提供する。
ドキュメントは、AI支援によるバグ対応についても厳格なプロセスを定めている。エージェントは関連するドキュメントを完全に読み、特定のバグを見つけ、重要でないものではない問題は再現を試みるべきだ。検証に耐えない発見は放棄すべきである。
問題が実在するように見える場合、エージェントは修正を書き、ビルドし、再現手順または完全な解析に対してテストし、kernelのパッチチェックを実行すべきだ。検証できなかった事項はすべて明示しなければならない。
このガイドはさらに、関連するメンテナーとメーリングリストを特定するようエージェントに指示している。問題が通常のバグ対応プロセスに属するのか、機密性のあるセキュリティプロセスに属するのかを評価しなければならない。実際の提出は、そのエージェントを利用する人間に任せる必要がある。
これらの要件は、AGENTS.mdだけを解決策として扱うことの限界を示している。このファイルはエージェントを正しいチェックリストへ導ける。しかし、再現手順に意味があるか、テストが十分か、人間がコードを理解しているかを確認することはできない。
kernel開発は、専門的な期待を持つ数千のコンポーネントにもまたがる。一般的な指示に、すべてのアーキテクチャ上の制約、ハードウェアの前提、メンテナーの好みを盛り込むことはできない。
エージェントは、目に見える書式ルールを完全に順守していても、ライフタイム管理、ロッキング、メモリ順序、デバイス動作を誤解する可能性がある。洗練されたコミットメッセージはそのようなパッチをレビューしやすくするかもしれないが、根底にある推論を正しくするものではない。
ここには有用な境界がある。リポジトリの指示は、避けられる管理上のミスを減らせる。技術的な確信は、依然として証拠、テスト、専門家のレビュー、そして責任を負う貢献者から得なければならない。
メンテナーにとって、この分離は重要である。不備のある提出はすべて、その技術的な中身に到達する前から注意を消費する。指示の発見性を高めれば、受け入れ基準を下げずにその負担を軽減できる。
貢献者にとっても、ポリシーは同様に明確だ。エージェントを使っても責任は移転しない。開発者は、すべての行を手作業で書いた場合と同じように、結果を説明し擁護できなければならない。
AIコーディングエージェントがREADMEを見落とし続ける理由
対立しているのは、存在するドキュメントと、エージェントの自動コンテキスト内に現れる指示である。
リポジトリは従来、人間のために貢献情報を整理してきた。READMEはプロジェクトを紹介し、貢献用ファイル、ドキュメントディレクトリ、メーリングリストのページ、スクリプトには、より専門的な手順が置かれている。
Linuxのソースツリーに到着した人間は、この階層をたどれる。狭いプロンプトを受け取ったエージェントは、その代わりに、すぐ関連すると判断したファイルだけを調べるかもしれない。ルートのREADMEを開かなければ、AIポリシーへのREADMEリンクは見えないままとなる。
この挙動は、AI支援によるQualcomm I2C修正について最近行われたkernelの議論で表面化した。あるメンテナーは、プロセスがREADMEから始まり、coding-assistants.rstへ続く連鎖として文書化されていると指摘した。それでも、ツールはその連鎖を確実にはたどらなかった。
メンテナー間の議論では、一般的なツールがデフォルトで調べるAGENTS.mdまたはCLAUDE.mdファイルがないことが提起された。また、そのようなファイルを追加しても、必ずしもすべてを解決するわけではないとの注意も示された。
これが新たな提案の背景にある圧力だ。kernelメンテナーは、リポジトリがエージェント向けにドキュメントを最適化しているかどうかにかかわらず、AI支援によるパッチに直面している。入口を追加しないことは、貢献者がこうしたツールを使うことを止めない。
実際の選択肢は、より限定される。メンテナーはエージェントに人間向けドキュメントを一貫性なく発見させるか、リポジトリのルートに馴染みのある道標を置くことができる。
より広範なAGENTS.mdの慣例では、このファイルをエージェント向けのREADMEとして説明している。そのオープンフォーマットのドキュメントによれば、6万を超えるオープンソースプロジェクトがこの慣例を使っている。ただし、この数値はアクティブなエージェント利用について監査された測定値ではなく、インデックス化された例を反映している。
この形式には必須のスキーマがない。プロジェクトは、セットアップコマンド、コードスタイルのルール、テスト、セキュリティ上の懸念、より深いドキュメントへのリンクを列挙できる。ネストされたファイルは、サブディレクトリにより具体的な指示を与えられる。
この柔軟性は、この形式が広まった理由の説明にもなる。リポジトリは、特定の専有設定システムに依存せず、複数のツールにわたって1つのプレーンなMarkdownファイルを使える。
kernelの提案は、このパターンを非常に保守的に用いるものだ。大きなエージェント向けマニュアルを作成したり、すでに別の場所で管理されている情報を繰り返したりはしない。既存のREADMEを、エージェントが要求する可能性が高い名前で公開する。
このアプローチは、人間向けと機械向けのガイダンスの整合性も保つ。Kees Cookは、READMEは意図的にエージェントでも機能するよう設計されたと述べた。そこへのリンクは、人間のコントリビューターが目にすることのない私的なルール一式を新設するのではなく、その共通の経路を強化する。
共有された情報源は、ポリシーの乖離を抑える。メンテナーがREADMEまたはAIガイドへの参照を更新すれば、エージェントはシンボリックリンクを通じてその変更を受け取る。コピーされたAGENTS.mdは、気付かれないまま古くなる可能性がある。
それでも、シンボリックリンクの利用には互換性上の考慮点がある。Unix系システムではリポジトリ内のシンボリックリンクを自然に扱えるが、一部のWindows構成では通常のファイルとしてチェックアウトされる。その場合、エージェントには参照先の内容ではなくREADMEという語だけが見える可能性がある。
特に確立されたLinuxワークフローを中心に開発されるプロジェクトにとって、これは提案を無効にするものではない。ただし、このパッチは魔法のメタデータではなくインフラとして評価されるべき理由を示している。
ツールの挙動にも違いがある。AGENTS.mdを自動的に読み込むエージェントもあれば、ツール固有のファイル名を優先するものや、明示的な設定を必要とするものもある。汎用的に見えるファイル名が、普遍的な取り込みを保証するわけではない。
したがってこのパッチは、多くのエージェントにとって想定される経路を改善する一方、ツール間の差異をなくすものではない。その効果は、クライアントがリンクをたどり、指示を尊重し、タスク全体を通じて維持することに依存する。
これらの条件は、単に優れたドキュメントがあることより強い。一方で、強制力のある技術的統制よりは弱い。
より良い指示でも生成されたパッチを安全にはできない
AGENTS.mdは遵守を改善できるが、正確性、来歴、真の人間レビューを確立することはできない。
この提案を支持する最も強い論拠は運用面にある。エージェントはすでにカーネル関連のパッチを生成しているため、メンテナーはルールへ至る予測可能な経路を示すべきだ。不適切な署名や帰属情報の欠落を防げば、レビュー時間を節約できる。
最も強い批判もまた運用面にある。生成されたパッチは、目に見えるすべての指示に従っていても、検出が難しい形で誤っている可能性がある。
指示追従の評価では、単純で観測可能な結果が使われることが多い。エージェントは正しいタグを追加したか。指定されたコマンドを実行したか。件名を正しく整形したか。こうした確認は重要だが、カーネルの品質はより深い性質に依存する。
修正はコンパイルを通過しても、競合状態を持ち込む可能性がある。再現プログラムはあるハードウェア構成では動作しても、別の構成を見落とすかもしれない。エージェントは適切なドキュメントを引用しても、そのドキュメントがコントリビューターに既知であることを前提とする不変条件を誤解する可能性がある。
より整った見た目が、誤った信頼を高めるリスクもある。構造化されたコミットメッセージ、有効な帰属情報、成功したチェックにより、AI支援パッチは成熟して見えるかもしれない。レビュー担当者はなお、これらのシグナルを技術的健全性の証明ではなく、プロセス遵守として扱う必要がある。
カーネルの現行ポリシーは、その問題を見越している。人間がコードをレビューし、責任を引き受けることを求めている。また、自信に満ちた文章の陰に欠落を隠すのではなく、未実施のテストや失敗した検証を開示するようコントリビューターに求めている。
人々がこれらの要件に従うかどうかは、AGENTS.mdの及ぶ範囲ではない。コントリビューターは帰属タグを削除し、失敗したテストを無視し、理解していないコードを提出できる。このファイルには、人間のレビューが行われたことを独立して確認する仕組みはない。
他のオープンソースプロジェクトは、同じ問題に異なる戦略で対応してきた。linux-firmwareリポジトリは2026年初頭、貢献ルールと帰属に関するガイダンスを含む、エージェント向けドキュメントを採用した。そのfirmware guidanceは、エージェントが読めるポリシーの近い先例となった。
NetworkManagerは、AIポリシーを定めた後、より対抗的なアプローチを取った。報道によれば、その指示は非準拠のエージェントに対し、コントリビューターとの通信に通常とは異なるカナリア語を入れるよう求めた。メンテナーは、プロジェクトのポリシーを回避しながら隠れた指示に従った提出物を検出できる。
そのカナリア機構は、指示ファイルの正反対の利用法を示している。エージェントが受け入れ可能なパッチを作成する手助けをするのではなく、拒否のきっかけとすべき自動化された挙動を特定するためにファイルを使う。
両方のアプローチは、同じ事実を認識している。エージェントはリポジトリのコンテキストを読み、それに応じて出力を変える。違いは、その挙動を遵守へ導くべきか、それとも検出シグナルとして使うべきかにある。
カーネルの提案はガイダンスを選ぶ。エージェントを使うコントリビューターであっても、他の全員と同じ法的、技術的、レビュー上の義務を果たすなら参加できるという前提に立つ。
これは、監督のないカーネル開発を支持するものではない。エージェントが作業を開始する瞬間に、既存の境界を見える形にしようとする試みだ。
この提案は、機械だけのために存在する指示を作ることも避けている。AGENTS.mdがREADMEを指すことで、メンテナーとコントリビューターはエージェントが受け取るのと同じ情報源を確認できる。
透明性は役立つが、プロンプトインジェクションや悪意あるリポジトリ内容には対処しない。コーディングエージェントは日常的に、ファイル、Issue本文、コメント、ログ、外部ページから指示を取り込む。矛盾する指示や敵対的な指示が、信頼されたポリシーと競合する可能性がある。
トップレベルのファイルは、協調的なツールに優先順位を設定できる。しかし、特にエージェントが矛盾した文言を含む深い階層のファイルを読む場合、すべてのツールがその優先順位を正しく適用する保証はない。
関連する保守上のリスクもある。ワークフローの変化に伴い、あらゆるリポジトリガイダンスは古くなり得る。提案されたシンボリックリンクは重複を抑えるが、リンク先の文書はなお継続的な見直しを必要とする。
カーネルの規模は、その保守を特に重要なものにする。広く正しい指示であっても、特定のサブシステムには不十分な場合がある。エージェントとコントリビューターは引き続き、ローカルドキュメント、メンテナー、ビルドシステム、テストインフラを参照しなければならない。
したがって、慎重な見方は「AGENTS.mdがAIコードを解決する」でも「このファイルは無意味だ」でもない。最も困難な検証作業を手付かずのまま残しつつ、予測可能な特定のエラー群を減らすことはできる。
この控えめな主張は、Levinの例によって裏付けられている。それ以上に広い結論には、さまざまなサブシステムとツールにまたがる実際の貢献からの証拠が必要だ。
次に起きることはシンボリックリンクそのものより重要になる
この提案は、採用後のレビュー結果、エージェントの挙動、メンテナーの作業負荷によって評価されるべきだ。
最初のシグナルはパッチの行方である。承認は設計を支持するが、この変更が標準的なプロジェクトインフラになるには、カーネルのドキュメント化プロセスを経てメインリポジトリに到達する必要がある。
レビュー担当者はシンボリックリンクをそのまま受け入れるかもしれないし、通常のファイルを求めるかもしれない。互換性調整を求めたり、README経由では不十分だと判断したりする可能性もある。どの結果も、カーネルが自動化ツールにルールをどのように公開したいかを明らかにするだろう。
第2のシグナルは、主要なコーディングエージェントが一貫してリンクをたどるかどうかだ。Levinによる2つのエージェントの比較は有用だが、規模は小さい。より広い検証では、異なるツール、プロンプト、作業ディレクトリ、貢献の種類を対象にすべきである。
成功した実装では、生成された署名が減り、Assisted-byタグの一貫性が高まり、より良いコミット件名と、未テスト作業に関するより明確な開示が生まれる。これらは観測可能なプロセス改善だ。
失敗は別の形で現れる。エージェントがシンボリックリンクを無視したり、リンク先の一部しか読まなかったり、サブシステム固有の要件を見落としながら一般的なルールに従ったりする可能性がある。ツール固有の指示ファイルが依然として必要になるかもしれない。
第3、そして最も重要なシグナルはメンテナーの作業負荷である。このファイルが低品質な提出を増やさずに反復的な修正を減らすなら、実用的な目的を果たしたことになる。
整ったエージェント出力が、説明できないパッチを送るコントリビューターを増やすなら、このリンクは見た目を改善する一方でレビュー負担を悪化させる可能性がある。その結果は、この提案の根底にある賭けを弱めるだろう。
メンテナーは、コントリビューターが帰属情報を誠実に利用するかも注視すべきだ。Assisted-byの慣行は、人々がそれを残して初めて価値を持つ。生成時の自動的な遵守は、誰かが提出前にコミットを編集することを防げない。
Linux以外のプロジェクトも結果を注視するだろう。カーネルは最も可視性が高く、要求も厳しい共同コードベースの一つであるため、エージェント向け指示の扱いは、パッチ自体が技術的には小さくても象徴的な重みを持つ。
その影響を普遍的なポリシーと混同すべきではない。小規模なリポジトリ、商用チーム、異なるリスク特性を持つプロジェクトは、より充実した指示ファイル、ツール固有の構成、自動ゲート、あるいは特定の生成された貢献の禁止を選ぶ可能性がある。
カーネルのアプローチが注目されるのは、並行する開発プロセスを構築しないからだ。エージェントを、すでに人々を統治しているプロセスへと戻す。
エンジニアリングチームにとっての当面の教訓は、発見可能性と権限を分けることだ。エージェントが読めるコンテキストは、正しいコマンドと制約を特定できる。テスト、レビュー、所有権、承認システムは、引き続き作業を強制しなければならない。
こうした境界を文書化するチームは、engineering knowledge baseを通じて技術的コンテキストを検索可能にしておくこともできる。重要なのは、複数のエージェントファイルにルールをコピーするのではなく、保守される一つの情報源を公開することだ。
今後数か月にわたり、パッチ履歴、実際のAI支援による提出、メンテナーの反応を注視すべきである。これらのシグナルは、LinuxカーネルのAGENTS.mdガイダンスが回避可能なノイズを除去するのか、それともそのノイズの到来方法を標準化するだけなのかを示す。
リポジトリメンテナーも、同様に具体的な問いを立てるべきだ。繰り返されるエージェントのミスのうち、どれがコンテキスト不足によるもので、どれが強制力のある統制を必要とするのか。ツールが見つけられる場所に安定したガイダンスを置き、その後に挙動が変わるか測定する。Markdownファイルでは証明できないすべてのことについては、人間のレビューが責任を負い続けるべきだ。
