AIエージェントのPR乱発に立ち向かうAGENTS.md戦略

朝、コーヒーを片手にGitHubのダッシュボードを開くと、身に覚えのないプルリクエスト（PR）が数十件も積み上がっている。しかも、そのすべてが人間ではなく、AIエージェントによって自動生成されたものだとしたら、あなたはどうするだろうか。これはSFの絵空事ではない。18万以上のスターを獲得しているオープンソースプロジェクト「AutoGPT」のファウンディングAIエンジニアであるNicholas Tindle氏が、日々直面している生々しい現実である。現在、彼らのリポジトリには常時150件近いオープンPRが存在し、その大部分がCopilotやOpenClaw、あるいはAutoGPT自身の内部ツールといったAIエージェントによって作成されているという。

多くのメンテナーは、この「AIスロップ（ゴミ）」の氾濫に辟易し、PRの受付自体を閉鎖するという防衛策に走りたがる。しかし、私はこのアプローチはあまりにも勿体ないと考える。Nicholas氏が指摘するように、これは「他人が自分のプロジェクトのためにコンピュート（計算資源）の代金を払ってくれている」状態なのだ。問題は、AIエージェントの存在そのものではなく、彼らをコントロールする術を我々が持っていないことにある。我々エンジニアが直面しているのは、AIがコードを書くスピードに、人間のレビューが追いつかないという「デッドロック」状態なのだ。

ここで我々が犯しがちな最大の過ちは、従来の「CONTRIBUTING.md」やWikiといったドキュメントが、AIエージェントにとっても有効に機能すると盲信することだ。エージェントは、人間のようにリポジトリ全体を探索してドキュメントを自発的に読みに行くことはしない。彼らは「目の前にあるディレクトリ」のコンテキストしか見ていないのだ。だからこそ、AutoGPTはドキュメントをエージェントの目の前に置く戦略をとった。最初に導入されたのは、Claudeが生成するPRの文脈不足を解消するための「CLAUDE.md」だった。しかし、CopilotやCodexといった他社製エージェントがこれを無視したため、彼らは標準的な「AGENTS.md」を中央に配置し、すべてのエージェント指示をそこに集約する構造へと進化させた。ドキュメントを「読ませる」のではなく、コードの配置そのものでエージェントの挙動を「規定する」というこの発想の転換こそ、AIファースト時代におけるメンテナーの必須スキルであると私は確信する。

では、具体的にどのようにしてAIエージェントを「ただ働き」させ、プロジェクトの品質向上に貢献させるべきか。AutoGPTが実践し、劇的な効果を上げている4つの「ゲート（関門）」は、すべてのモダンな開発現場が今すぐ模倣すべき極めて実用的なハックである。これらは、AIの特性を逆手に取り、彼らの自律的な修正ループを強制する仕組みだ。

第一に、PRテンプレートの厳格な適用だ。AutoGPTでは、テンプレートに従わないPRは容赦なく自動クローズする。面白いことに、このルールを明文化しただけで、エージェントは人間よりも忠実にテンプレートを守るようになったという。Nicholas氏が「テンプレートに従わないのは人間だから、その場合は優しく対応する」と語るように、AIと人間のフィルタリングとしても機能している。第二に、「テストプラン」のトリックである。PRテンプレートに「テスト計画」の記述を義務付け、その文言をトリガーにして「test PR」というスキルを起動させる。これにより、エージェントは自らブラウザを立ち上げ、アプリを起動し、変更内容を実際にテストせざるを得なくなる。結果として、「動かないコード」のPRはほぼゼロになった。

第三に、CI（継続的インテグレーション）を単なる警告ではなく「超えられない壁」にすることだ。Codecovなどのカバレッジ閾値を必須チェックとし、テストが通らなければマージできないようにする。エージェントはCIの失敗を確認すると、自らテストコードを書き直して再挑戦する。メンテナーが手を下すことなく、AIが勝手にテストを補完していくのだ。第四に、CLA（寄稿者ライセンス同意書）や行動規範のチェックボックスを「人間検知器」として利用することだ。CLAの署名には、ブラウザでのGitHub OAuth認証という、現在のエージェントが最も苦手とするプロセスが必要となる。署名がなければ1週間で自動クローズする仕組みにすることで、最終的なマージの段階で確実に「人間」をループに引き戻すことができる。

さらに、レビューの「やったふり」を防ぐハックも秀逸だ。エージェントは、コードを修正せずに対話スレッドを「解決済み（Resolved）」にすることがある。これに対し、AutoGPTでは「pr-address」スキルを定義し、「修正、コミット、プッシュ、返信、解決」の順序を強制している。返信には「git rev-parse HEAD」から取得した最新のコミットSHAの添付を義務付け、古いコミットの使い回しや「了解しました」という口先だけの返答を完全にシャットアウトしている。この徹底したプロセス設計は、スパゲッティコードやデッドロックを未然に防ぐための、シニアエンジニアならではの知恵の結晶と言える。

しかし、これほど高度な自動化ゲートを構築してもなお、我々は根本的な問いに直面せざるを得ない。それは、「我々は本当に、AIが生成したすべてのコードを受け入れるべきなのか」という哲学的な問いである。他人のLLM（大規模言語モデル）の出力をマージすることは、極めて非対称な行為だ。コードを生成したエージェントやその所有者は、PRを送った時点でタスクを完了する。しかし、そのコードのバグを修正し、依存関係をアップデートし、将来にわたってメンテナンスし続けるのは、他ならぬ我々人間のメンテナーなのだ。この「メンテナンスの負債」を無限に抱え込むことは、オープンソースコミュニティの持続可能性を著しく損なう。

実際、SQLiteのように「外部からのコード貢献を一切受け入れず、バグ報告のみを受け付ける」という境界線を引いているプロジェクトもある。これは、AIファースト時代において極めて賢明で、かつ尊重されるべき選択肢だ。すべてのプロジェクトが、AIエージェントの踏み台になる必要はない。また、技術的な落とし穴も無視できない。AutoGPTの検証では、質の悪い「AGENTS.md」を乱立させた結果、エージェントのコンテキストが汚染され、かえって挙動が悪化したという。さらに、CLIツールが個別のユーザーとしてAPIを叩くことで、GraphQL APIのレート制限に一瞬で達してしまう問題や、8つのエージェントを並行して走らせるテスト環境の莫大なトークンコストなど、現実的な「金銭的・リソース的コスト」がメンテナーに重くのしかかる。

ここで、我々エンジニアが明日から取るべき「実践的な処方箋」を提示したい。まず、自身の管理するリポジトリの「認可済みアプリ（Authorized OAuth Apps）」を今すぐ監査することだ。様々なAIツールを試行錯誤する中で、不要な権限を持ったアプリがリポジトリにアクセス可能なまま放置されていないだろうか。これは重大なセキュリティホールになり得る。次に、あなたのプロジェクトにおける「境界線」を定義することだ。AIエージェントの貢献を歓迎するなら、今すぐコードの隣に「AGENTS.md」を配置し、彼らをコントロールするためのゲートを設計せよ。もしそのコストが支払えない、あるいはプロジェクトのロードマップに合致しないのであれば、PRの受付を制限し、コラボレーターのみに絞る決断を躊躇してはならない。AIが文章を書き、コードを生成する時代において、人間の価値は「何を書くか」ではなく、「何を受け入れ、何を捨てるか」という『編集と意思決定』にシフトしている。あなたのプロジェクトは、このAIファーストの荒波を乗りこなす準備ができているだろうか。それとも、押し寄せるAIスロップの波に沈んでいくのだろうか。今、その決断が我々一人ひとりのエンジニアに突きつけられている。