保守・基盤開発者
原因の調査が複数ファイルに広がる
履歴のコピーやimportが遅いと分かっても、修正の影響範囲を調べる時間がかかる。AIに計測、依存関係の調査、差分と試験の作成をつなげて任せる使いどころがある。
GEMINI 4 ARGON / AUTONOMOUS INVESTIGATION
GoogleのADK保守チームは、既存コードの遅さを調べる仕事をAIに任せた。11時間後に届いた6案から、人間が2案を採り、4案を捨てた。成果を決めたのは、長く調べ続ける力と、互換性・実用効果を確かめるレビューだった。[1]
規約・計測・修正・試験をつなぐ
4案は互換性や実用性で棄却
InMemorySessionServiceが対象
「20万行」は調査対象の規模。 全行を書き換えたわけではなく、採用commitは22ファイルの変更。約40%はモデル要求前のADK準備処理で、アプリ全体の速度改善率ではない。[1] [2]
ONE-PAGE BRIEF
人が性能改善の目標、互換性、保守規約、未マージPRという停止点を定義。ArgonがAntigravityとリポジトリ規約を使い11時間で6案を提案。人が2案を採り、4案を棄却しました。
採用は履歴の選別後コピーと、互換性を保った遅延import。長いセッションの準備は約40%、importは21%短縮。新規プロセスから初回モデル要求までは3.07→3.09秒で改善なし。公開16,892試験を通過しても内部25テスト対象で互換性問題が見つかりました。
ADKは、AIエージェントを構築するGoogleのオープンソース基盤。保守チームが向き合ったのは、約20.5万行にまたがる性能問題だった。呼び出し元や共有データ、テストが依存する属性まで確認しながら、既存の動作を守る必要がある。[1]
保守・基盤開発者
履歴のコピーやimportが遅いと分かっても、修正の影響範囲を調べる時間がかかる。AIに計測、依存関係の調査、差分と試験の作成をつなげて任せる使いどころがある。
技術責任者・レビュー担当
受け取るのは採用前の変更案。公開API、内部テスト、実際の利用、保守の複雑さを照合し、効果がある範囲だけを選ぶ。
対象者と業務への読み替えは編集部の整理。事例の実行主体はGoogleのADKチームです。
Googleの事例報告 2回目の実行では、.agents/skillsにチームの規約を置き、Antigravityの/goalで目標を維持した。モデル選択だけで、この調査環境ができるわけではない。[1]
メモリ内セッションの読み出しで、返すイベントだけをコピーする。Session / Eventの深いコピーも最適化し、会話が長いほど増える準備負担を減らした。[2]
起動時に読み込んでいた計測・認証・LLMフローを遅延化。テストが差し替える属性を残し、利用側の互換性も維持した。[2]
| 測定した範囲 | 改善前 | 改善後 | 報告された変化 |
|---|---|---|---|
| 50内部turn後の、モデル要求までの準備 * | 64 ms | 36 ms | −43% |
| 150内部turn後の、モデル要求までの準備 * | 200 ms | 122 ms | −39% |
| 158内部turnを実行するADK負担 | 65.6秒 | 56.1秒 | −14% |
| 新規プロセスのimport | 1.22秒 | 0.97秒 | −21% |
| 新規プロセス → 初回モデル要求 | 3.07秒 | 3.09秒 | +1% / 改善なし |
測定は6〜12回の中央値。no-opモデルと即時応答ツールを使い、ADK自身の負担を測定。* の2行はガベージコレクション(GC)を無効にしている。ここでのturnは内部のツール呼び出し等の処理単位で、ユーザーとの会話往復数とは異なる。%はcommit記載値。[2]
約40%を、自社アプリ全体の速度に換算しない。 実際のモデル応答やツール待ちを含む速度は、この測定では分からない。外部DBを使うセッションストアの読み出しも、この変更の対象外。[1]
importの短縮は、初回処理の短縮と一致しない。 遅らせたモジュールは最初の利用時に読み込まれるため、新規プロセスから初回モデル要求までの時間は改善していない。
速度の数値だけでは採れない。人間レビューでは、古い状態を返す危険、外部ライブラリへの依存、実用上の効果、将来の保守負担を確認していた。[1]
合成試験で速くても、メモリ参照の再利用で別セッションの古いデータを返す危険がある。
OpenTelemetryの非公開属性への依存は、ライブラリ更新で壊れる可能性がある。
独立した評価で端から端までの遅延が改善せず、主要なコードの読みやすさも下がる。
状態管理が複雑になる一方、改善は合成リプレイ試験に限られ、通常利用での利点が乏しい。
4案の棄却理由はGoogleの説明を要約。自社での採否は、実データと利用側の条件で別途判断します。[1]
人の役割は「AIの答案に丸を付ける」だけではない。 未知の利用条件を持ち込み、互換性を確かめ、得られる効果と増える複雑さを比較する。事例から読み取れるのは、この分担の重要性だ。
長時間実行の前に、コードを渡してよい範囲、実行環境、操作権限、時間・費用の上限、停止点を設定する。最初は未マージPRかローカル差分までを成果にすると、採用判断がしやすい。
編集部作成の依頼例。公式promptの転載ではありません。単一の依頼文で11時間の完走や同等の性能改善を保証するものではありません。
GEMINI APP
Google AI Pro / UltraがArgonの対象。アプリのモデル選択で利用する。プランと残りの利用枠を確認する。[3]
ANTIGRAVITY
個人向けはGoogle AI Ultra。アプリ・CLI・IDE拡張に対応。Antigravity IDE本体ではArgonは使えない。[4]
API / AI STUDIO
Gemini APIは有料ティア、AI StudioはGoogle AI Ultraという入口がある。モデルIDはgemini-4-argon。[5]
チャットでArgonを選ぶことと、リポジトリを自律調査させることは別の準備が必要。 この事例はAntigravityにコード、規約、実行できる試験を用意し、人が結果をレビューしたもの。利用できるプランでも、そのまま同じ成果が出る保証はない。
契約中のプランと個別アカウントの利用可否は未確認。利用条件・提供状況・上限は変更されるため、入口の公式ページと手元の表示を確認してください。
11時間の自律調査は、レビューできる候補を増やした。実務で重要なのは、原因・差分・測定条件を受け取り、効果のある範囲と壊さない条件を確かめることだ。
未検証:当サイトでのArgon実行、ADKの性能再測定、自社コードでの速度・互換性・費用。数値はGoogleの限定条件での報告。導入手順と依頼文は編集部の提案です。