10月25日、Sergio De Simoneが「Google Optimizes Agent Development Kit's 200K-line Python Codebase Overnight with Gemini 4 Argon」と題した記事を公開した。この記事では、GoogleがGemini 4 Argonを使って自社のAgent Development Kit（ADK）の20万行超のPythonコードベースを一晩で最適化し、2件の改善がマージされた実例について詳しく紹介されている。
11時間の無人実行で2件の改善を実現
GoogleはAIエージェントに対して、いわゆる「空のフォルダから作るgreenfield開発」ではなく、既存の大規模コードベースへの介入という難題を課した。対象はAgent Development Kit（ADK）のPythonリポジトリ。約800ファイル・20万行超のコードと、16,892件のユニットテストを抱える本番級のコードベースだ。
パフォーマンス改善がこの実験の難易度を高めている理由を、Google自身がこう説明している：
パフォーマンス改善は、モデルにとって難しいテストだ。一つのファイルを開いて遅い箇所を見つければいい話ではなく、症状が現れる場所とは別の角度から見て、コードベース全体がどう組み合わさっているかをつかみながら長時間走り続ける必要がある。
使用モデルと実行環境：Gemini 4 ArgonとAntigravity
今回の実験で使用したGemini 4 Argonは、Googleが2026年に投入したGemini 4シリーズの一モデルだ。Gemini 4シリーズは長文脈処理と自律的なタスク遂行を重視した設計で、Argonはその中でもエージェントワークロード向けに位置づけられている。
エージェントの実行環境として使われたのはAntigravityだ。AntigravityはGoogleが提供するエージェント実行基盤であり、Gemini 4 ArgonをはじめとするモデルをLLMバックエンドとして呼び出しながら、ツール使用・コンテキスト管理・ゴール保持といったエージェントループを担う。つまり今回の構成は「AntigravityがADKリポジトリに対して自律的に操作を行い、その推論エンジンとしてGemini 4 Argonを使う」という関係になる。
プロンプト設計と「新人エンジニア向けオンボーディング」戦略
Google engineersは最初に短い試験実行を行い、プロンプトの内容を調整。ユニットテストやベンチマークに関するチームの規約をエージェントに守らせるため、リポジトリ固有のガイドラインを.agents/skillsファイルに記述した。これは「新人エンジニア向けのオンボーディングガイド」に相当する。コンテキストウィンドウを無駄に消費しないよう、エージェントはタスクに必要なスキルファイルだけを読み込むよう指示されている。
最終的なプロンプトは以下の通りだ（Antigravityの/goalモードを使い、コンテキスト圧縮をまたいでもゴールが保持されるようにしている）：
/goal Make ADK add no noticeable overhead to any agent: at startup, in long sessions,
in multi-agent and workflow setups. Keep what the model receives and the public API
unchanged, and back each change with a test that would catch a regression. Open one
pull request against main that the ADK maintainers would approve, with before and
after numbers in its description. Don't merge it.
実際に採用された2件の変更
11時間の無人実行を経て、Argonはリポジトリガイドラインの読み込み、パフォーマンスベースラインの計測、改善案の提案、自己レビュー、全ユニットテストの実行を完了した。
最終的にコードベースへの採用が認められた変更は2件だ：
- セッション履歴の改善：イベントのコピー前にフィルタリングを挟むことで、インメモリのセッション準備オーバーヘッドを約40%削減
- 遅延インポートの導入：重いパッケージを必要になるまで読み込まないようにすることで、パッケージインポート時間を21%短縮
単一のLLM呼び出しレベルでは28msや78msの差にすぎない。しかしADKはツール呼び出しを数十〜数百回繰り返すマルチターンの実行をサポートしており、小さな改善が積み重なる：
1回のLLM呼び出しが数秒かかる中で、人間は28msや78msを感じない。しかし158ターンのツール呼び出しを重ねると、それらのコピーが積み上がる。除去することで、158ターンの実行全体が65.6秒から56.1秒へ短縮された（純粋なフレームワークオーバーヘッドが約10秒削減）。
却下された4件が示す現実
Argonが生成した変更のうち、4件は開発者レビューで却下された。元記事によれば、却下理由として挙げられた主な観点は以下の通りだ：
- 信頼性・保守性の懸念：変更がコードベースの長期的な保守を複雑にすると判断されたケース
- 測定可能な改善が得られない変更：ベンチマーク上で有意な差が確認できず、リスクに見合わないと判断されたケース
互換性への影響や、既存のチーム規約との齟齬も却下要因として示唆されており、エージェントが自律的に判断した変更がそのままレビューを通過するわけではないことを示している。
Googleはこの点について、既存コードベースへのAIエージェント適用における現状の限界として正直に認めている。PRレビュー、デバッグ、テストといったコーディング後のタスクに要する人的コストは依然として高く、この課題は他の調査でも確認されている。
今回の実験は、AIが既存コードベースを自律的に改善できることを示しつつも、最終的な判断は人間のレビューに委ねられているという現実も浮き彫りにしている。採用率33%（6件中2件）という数字は、現時点の自律コーディングエージェントの実力を端的に表している。
詳細はGoogle Optimizes Agent Development Kit's 200K-line Python Codebase Overnight with Gemini 4 Argonを参照していただきたい。
