LLVMで9月2日、AIコーディングエージェント向けの案内ファイル「AGENTS.md」を、ソースコードを管理するリポジトリの最上位へ追加する議論が始まった。Nick Desaulniersが示した草案のAGENTS.mdはわずか2行で、既存のAI利用方針とコーディング規約を読むよう促す。狙いは、レビュー担当者が同じ注意を繰り返す前に、生成物を持ち込む側へルールを届けることだ。ところが開発者からは、共有文書の実効性や維持負担への疑問が相次いだ。AI支援をすでに認めるLLVMで、なぜこの小さな追加が議論を呼んでいるのか。

AD

2行の草案が変えようとするもの

草案PR #220659の2行が伝える内容は、貢献する前にAI利用方針とコーディング規約を確認する、という一文に収まる。9月4日日本時間の確認時点ではDraftで、採用は決まっていない。規約の本文を転記せず、リポジトリ内にある既存文書を参照する構成だ。

AGENTS.mdは、AIエージェントにビルドやテストの手順、コードの書き方などを伝えるMarkdown形式のファイルである。人間向けのREADMEを補い、AIが作業前に参照する場所をそろえる。ただし、文章を置くこと自体に、投稿やファイル操作を禁止する技術的な強制力はない。

RFCでDesaulniersは、LLVMの文書をreStructuredTextからMarkdownへ移していることに触れ、人間が読む既存文書をそのまま参照できると説明した。人向けとAI向けに別々の規約を保つ負担を避ける発想である。一方、AGENTS.mdとCLAUDE.mdは現在Gitの追跡対象から除外されており、共有するには除外設定も変える必要があるという。

提案の範囲は絞られている。サブプロジェクトごとのAGENTS.mdやSKILLS.md、モデル固有の設定ディレクトリは対象外だ。CLAUDE.mdからAGENTS.mdを参照する方法にも言及しているが、これも提案段階である。現行のAI利用条件を変更する話ではなく、その条件へエージェントを案内する入口をプロジェクト側が用意するか、という変更なのだ。

LLVMが守ろうとしているレビューの時間

LLVMの現行AI利用方針は、AIが作ったコードや文章を他者へレビュー依頼する前に、人が読んで確認するよう求める。投稿者は内容について質問に答えられなければならず、相当量の生成物を使った場合はPR説明などで開示する。人の承認なしに自動レビュー結果を投稿する行為も認めない。生成物について責任を負うのは、あくまで投稿者である。

この線引きには、保守担当者へ検証の負担を押しつける貢献を防ぐ目的がある。方針は、レビューに費やす時間に見合う価値を投稿側へ求め、未確認の生成物を受け取った担当者が問題を探す状態を避けようとする。また、新しい参加者が学び、将来の保守担当者になることも重視する。そのため、学習用に用意されたgood first issueの解決にAIを使うことは禁止されている。一方、承認済みのBazel-fixer botには例外がある。全面禁止の規則ではない。

たとえばAIが修正案を作っても、投稿者がその変更の理由を説明できなければ、レビュー担当者は意図の再構成から始めなければならない。規約を事前に知らせる狙いは、この手戻りを入口で防ぐことにある。ただし、エージェントが規約を読んだことと、人間が生成物を理解したことは別だ。AGENTS.mdを採用しても、投稿前の確認を引き受ける人が必要な点は変わらない。

AD

共通の案内と個人の指示は分けられるか

議論でJonas Devlieghereは、自作のLLVM開発スキルが役立っていると述べ、各自が同じ案内を維持する負担を減らすため共有を支持した。LLDBで一般LLVM規約を使っても、その規約に合わせて不適切に書き換えることはなかったという。ただし、内部で余計な計算や探索が増えていたかは分からないとも認めている。

すでに自分用の指示を使っている人には、別の悩みがある。Reid Klecknerは私用リポジトリの指示ファイルを各作業コピーへリンクし、ビルド先などの個人設定を伝えていると説明した。公式のAGENTS.mdが同じ場所に入れば、自分の設定をどう追加・上書きするかを決める必要がある。共通化によって、既存の作業環境を組み替える負担が生じ得る。

Fangrui Song（MaskRay）は、共有リポジトリに置く設定の性格から反対した。.clang-formatのように結果を検証できる設定と、個人の作業方法を左右する指示は異なる、という主張だ。書式や静的検査はすでにCIで行い、AI方針は人間の義務を定めている。エージェントへの指示を追加することで何が改善するかを、別途示す必要があると捉えている。

サブプロジェクトの違いも無視できない。LLVMのコーディング規約は既存コードのスタイルを優先し、libc++ではC++標準に合わせるため一般規約から外れると明記する。同じリポジトリでも、すべての場所に同じルールを適用できるわけではない。

Cullen Rhodesが示した経験は、指示の寿命という問題を具体化する。コンパイラ内部のGlobalISelやgeneric MIRを扱う際、定義や直前の呼び出し側が保証済みの引数の数・種類を、AIが重ねて確認するコードを書いたという。そこで不要な検査を避ける指示を加えたが、本人はそれを共有ファイルへ提案することにためらいを示す。自分のエージェントに依存し、効果を確かめにくく、モデルが改善すれば不要になるかもしれないからだ。個人の試行錯誤で得た指示を、全員が維持すべき規則へ昇格させる難しさがある。

研究が測った成功率と、測っていない責任

Aaron Ballmanが有効性への疑問とともに挙げたのが、Thibaud GloaguenらのarXiv公開論文である。2月12日公開、6月23日改訂のv2は、CTXbenchの12リポジトリ138課題と、SWE-bench Liteの11のPythonリポジトリ300課題を使い、四つのモデルと対応エージェントを調べた。LLVMを評価した実験ではない。

最新版の結果では、指示なしとLLM生成、指示なしと開発者提供の成功率の差は、いずれも統計的に有意ではなかった。開発者提供はLLM生成を有意に上回ったが、指示なしに対する改善が確認できたわけではない。一方、LLM生成の指示によって平均推論費用はSWE-benchで20%、CTXbenchで23%増えた。指示はおおむね守られ、テストや探索が増えていた。

この結果は、指示を増やせば作業がよくなるという期待に慎重さを求める。ただし成功率とは、テストをすべて通る修正の割合だ。投稿者が説明できるか、無断投稿を避けられるか、保守担当者のレビュー時間が減るかは測っていない。Klecknerも、本人の認証情報を使って勝手にGitHubへコメントしない、といった振る舞いは成功率やトークン数に表れないと指摘した。LLVMで採用を判断するなら、修正の正しさと投稿時の行動を分けて確かめる必要がある。

AD

レビューの負担をどこまで減らせるか

RFCには、必要な条件に当てはまるときだけ規約リンクを読む案も出た。MattPDはその方向を示し、Louis Dionneはlibc++のテストと貢献文書へ案内する最小構成なら支持した。どちらも合意済みの設計ではないが、全員に同じ長い指示を読ませるより、作業場所に応じて入口を分ける考え方は見える。

草案と現行規約から、その役割を分けると次のようになる。

機能 現在の担い手 AGENTS.mdの役割／限界
参照先の案内 AI Tool Policy、Coding Standards、サブプロジェクトの文書 最上位から既存規約へ誘導できる。作業場所ごとの例外や個人設定まで自動で解決しない。
機械的な検査 CI、.clang-format、静的検査 実行すべき検査を案内できるが、検査そのものを代替しない。今回の草案は既存規約への参照に限られる。
投稿者の説明責任 生成物を読む投稿者と、人間による承認を求める現行AI方針 責任を知らせる入口にはなる。投稿者が理解し、質問に答え、承認した事実を強制できない。

参照先の案内、機械的な検査、投稿者の説明責任は、別々に確認する必要がある。

この区別に立つと、案内ファイルの短さだけで実用性を判断することも難しい。本文が2行でも、リンク先を毎回すべて読ませれば処理は増える。逆に、短さを優先して作業先の規約を見落とせば、担当者が後から同じ注意を繰り返すことになる。条件に応じて文書を参照する案には、読む量と案内の正確さを両立させようという意図がある。

今後の判断材料は、正しいサブプロジェクトの文書へたどり着けるか、規約違反への同じ注意が減るか、そして投稿者が変更を理解して承認しているかである。こうした行動を確かめられれば、LLVMはAIを使う側の手間と、受け取る側のレビュー時間を合わせて導入の価値を判断できる。