Google Antigravity移行ガイド：10月5日までのローカルジョブ対応

Google Antigravityで実際に変わるもの

今回の対象は、Gemini APIのAntigravityマネージドエージェントです。パソコンにインストールするAntigravity IDEのアップデートではありません。

両製品はランタイムの基盤を共有しているため、名称が重なっています。今回変わるのは、アプリケーションがGoogleのInteractions APIへ送信するエージェントIDと、一部の連携でアプリケーション側が処理する組み込みツール呼び出しです。IDEを更新しても、このAPI契約が自動的に更新されるわけではありません。

新しいエージェントはantigravity-preview-09-2026です。デフォルトの推論モデルはGemini 3.8 Flashですが、Antigravity Agentガイドのとおり、アプリケーションはagent_configを使って別の対応モデルを選べます。ホスト型ワークスペース、バックグラウンドジョブ、ツールループについては、以前のGemini Managed Agents解説で説明しました。今回の移行は、その一段下にある問題です。ジョブが今後も開始できるか、ツール呼び出しを引き続き実行できるかを左右します。

Googleは、9月17日のリリースノートで移行を2つの経路に分けています。

• リモートサンドボックスで動き、output_textまたはmodel_outputだけを読むジョブは、エージェント文字列を変更します。
• local_environmentを使う、またはfunction_callステップを解析するジョブは、ツールアダプターも更新する必要があります。

判断基準はこの違いだけです。アダプターとは、ツール名と引数を受け取り、検証してローカルの処理を実行し、結果を返す小さなアプリケーションコードを指します。

ローカルツールの契約は5つの点で変わった

旧エージェントは、ファイル操作の大半を汎用的な読み取りと書き込みとして扱っていました。9月版エージェントでは、ファイル操作ごとに名前と引数が細かく分かれています。引数キーもsnake_caseからPascalCaseへ変わりました。

変更されたのは、ファイル操作と検索に関する5つの機能群です。表に挙げた組み込みツールのうち、2つは変わっていません。そのため、write_fileを前提にした包括的なハンドラーでは、新しいエージェントIDが正しくても失敗する可能性があります。

新しい編集契約は、操作の範囲もより明確です。小さな変更のためにファイル全体を送り返すのではなく、行範囲、そこに存在するはずのテキスト、置換後のテキストをエージェントが指定します。TargetContentが現在のファイルと一致しない場合、アダプターは呼び出しを拒否すべきです。そうしなければ、遅れて実行されたジョブが、人による新しい編集を上書きしかねません。

本格的な移行対応が必要なジョブはどれか

リモートでレポートジョブを動かす個人開発者

夜間ジョブがGoogleのサンドボックス内でAntigravityにデータ収集とレポート保存を依頼し、最後に完成したテキストを返すケースを考えます。アプリケーションはoutput_textを読み、途中のステップは一切確認しません。

この場合、移行は小規模です。antigravity-preview-05-2026をantigravity-preview-09-2026へ変更し、代表的なレポートを旧ジョブと並行実行して最終成果物を比較した後、スケジュールを移します。そもそも存在しないローカルツールディスパッチャーを作り直す必要はありません。

自社マシンでツールを動かすプラットフォームチーム

次は、ツール呼び出しを自社のランナー内で実行するリポジトリワーカーです。ファイルの読み取り、コード検索、設定編集を行い、その結果をインタラクションへ返します。

このチームには、より大きな移行作業が発生します。ディスパッチャーは新しい名前を認識し、PascalCaseの引数を検証し、パスとコマンドのポリシーを適用し、行範囲の編集を安全に処理したうえで、インタラクションが期待する形式で結果を返さなければなりません。その見返りは継続性です。5月版エンドポイントが消えた後も、コードレビュー、レポート生成、メンテナンスジョブを動かし続けられます。

すべてのステップを取り込むオブザーバビリティチーム

処理自体はすべてリモートで実行しながら、function_callステップを監査ログ、進捗UI、承認キュー、コストダッシュボードへコピーするアプリケーションもあります。こうしたチームは、出力だけを扱う利用者ではありません。

組み込みのファイルシステム操作をGoogleが実行する場合でも、パーサーがwrite_file、path、contentを前提としている可能性があります。許可リストとフィクスチャを更新し、実際の編集が「不明」と表示されたり、引数が欠落したり、誤った承認ポリシーへ振り分けられたりしないようにします。

無人トリガーを管理する運用担当者

スケジュールトリガーは、呼び出し時に人が見ていないため最もリスクが高いケースです。トリガーには、エージェント、環境、プロンプト、cronスケジュールが紐づきます。保存済みのインタラクションが5月版エージェントを指定したままだと、スケジュール自体は正常に見えても、停止後は背後の実行が失敗する可能性があります。

メインアプリケーションのSDK呼び出しだけでなく、すべてのトリガー定義に含まれるエージェントIDを棚卸ししてください。そのうえで、ツールの使い方が異なるパターンごとにジョブを1つずつシャドー実行します。どちらもAntigravityを使っているからといって、レポートジョブとリポジトリ修復ジョブを同じ移行テストで済ませることはできません。

小さなファイル編集契約テスト

最初に行うべき安全なテストに、本番環境の認証情報は必要ありません。記録済みの呼び出し形式を模したフィクスチャをアダプターへ渡し、使い捨てファイルを編集して、意図した行だけが変わったことを確認します。

以下のコードは、Googleが公開したreplace_file_contentという名前とPascalCaseフィールドを使い、Nodeで実行しました。これはローカルアダプターのテストであり、実際のGemini API呼び出しではありません。

import assert from "node:assert/strict";
import { mkdtempSync, readFileSync, writeFileSync } from "node:fs";
import { tmpdir } from "node:os";
import { join } from "node:path";

function applyReplaceFileContent(call) {
  assert.equal(call.name, "replace_file_content");

  const {
    TargetFile,
    StartLine,
    EndLine,
    TargetContent,
    ReplacementContent,
  } = call.arguments;

  const lines = readFileSync(TargetFile, "utf8").split("\n");
  const current = lines.slice(StartLine - 1, EndLine).join("\n");
  assert.equal(current, TargetContent, "line window no longer matches");

  lines.splice(
    StartLine - 1,
    EndLine - StartLine + 1,
    ...ReplacementContent.split("\n"),
  );
  writeFileSync(TargetFile, lines.join("\n"));
}

const dir = mkdtempSync(join(tmpdir(), "antigravity-adapter-"));
const file = join(dir, "scheduled-job.env");
writeFileSync(file, "owner=ops\nstatus=old\nmode=scheduled\n");

applyReplaceFileContent({
  name: "replace_file_content",
  arguments: {
    TargetFile: file,
    StartLine: 2,
    EndLine: 2,
    TargetContent: "status=old",
    ReplacementContent: "status=ready",
  },
});

assert.equal(
  readFileSync(file, "utf8"),
  "owner=ops\nstatus=ready\nmode=scheduled\n",
);
console.log("PASS: line 2 changed from status=old to status=ready");

テストは成功しました。それ以上に重要なのは、フィクスチャのTargetContentを変更すると、古い内容を編集せずに処理が停止することです。

判断すべき事業コストは、移行作業と未実行ジョブのどちらが重いか

Googleは、今回のエージェント移行に伴う新しいトークン単価を発表していません。変化する予算項目は、エンジニアリングと運用にかかる時間です。

次の2つのシンプルな式を使います。

出力だけを扱うリモートジョブなら、エージェント文字列の変更と1回のシャドー実行だけで済む場合があります。ローカルツール連携では、変更された5つの機能群、パーサーのフィクスチャ、安全性テスト、そして異なるワークフロー形態ごとの完全な実行1回を予算に含めてください。

もっともらしい一律の所要時間を作ってはいけません。用途を絞ったレポート生成ツールとローカルのコーディングエージェントでは、対象ツール、承認ロジック、障害コストが異なります。自社の諸経費込みエンジニア単価と、ジョブ1回あたりの事業価値を式に入れてください。そうすれば、ベンダー機能の一覧ではなく、財務判断に使える材料になります。

率直に言えること

上のローカルテストで証明できるのは、フィクスチャとアダプターが合っていることです。実際のエージェントがすべてのプロンプトに対して何を出力するかまでは証明できません。今回の検証環境にはGemini APIの認証情報がなかったため、ホスト型エージェントを実行したかのようには扱っていません。最後の合否判定には、使い捨て環境で記録した9月版エージェントの呼び出しを使ってください。

また、すべてのAntigravityユーザーに同じ対応が必要なわけではありません。

• 本番ジョブがantigravity-preview-05-2026を指定している、local_environmentを使う、function_callステップを解析する、または無人のスケジュールで動く場合は、今週中に着手してください。
• リモートサンドボックスで実行し、output_textまたはmodel_outputだけを利用する場合は、小規模な移行で済みます。IDを変更してシャドー実行してください。
• APIをまだ評価中で、5月版エージェントの本番ジョブがない場合は、新しいIDから開始してください。
• Antigravity IDEだけを使い、Gemini API経由でマネージドエージェントを呼び出していない場合は、今回の移行対応は不要です。

月曜日にまずやること

棚卸しの責任者を1人決めてください。デプロイ済みの設定、トリガー定義、環境変数、ダッシュボード、フィクスチャから、5月版エージェントIDと旧ツール名を検索します。誰かがコードを変更し始める前に、結果を「出力のみ」と「アダプター対応が必要」の2つのリストに分けてください。

次に、各リストから代表的なジョブを1つずつ移行します。9月版の実行結果を確認する間は、旧スケジュールを一時停止した状態で残します。その後、ワークフローの種類ごとに残りのジョブを移し、10月5日まで未知のツール呼び出しにアラートを設定してください。月曜日の成果物はスライドではありません。担当者付きの棚卸し表、成功したシャドー実行、残るすべてのジョブの移行日です。

実際のワークフローを壊しかねない変更について、平易な言葉でまとめた運用ノートを受け取りたい方は、ニュースレターにご登録ください。