10月5日に止まる antigravity-preview-05-2026、差し替えで済む構成と済まない構成

日曜の朝に廃止表を開き直したら、Managed agents の行に日付が入っておりました。antigravity-preview-05-2026 の停止日が 10 月 5 日、後継は antigravity-preview-09-2026 です。

最初に手が伸びたのは、後継エージェントのドキュメントでした。何が新しくなったのかを読めば、直すべき場所が見えるだろうと思ったのです。

ところが小一時間読んでも、自分のコードのどこを触ればよいのかは見えてきませんでした。読む順番が逆だったのだと気づいたのは、コーヒーが冷めてからです。相手の変更点より先に、自分の依存を数えます。 順番を入れ替えたとたん、作業は十数分で終わりました。

公式が出しているのは、日付と後継の名前だけです

Gemini API の廃止ページで、Managed agents の節に載っているのはこの二行です。

同じページの注記には、表の停止日は「最も早い可能性のある日付」であり、正確な日付は改めて周知されると書かれています。前倒しはされない、という読み方で差し支えありません。

ただし表が教えてくれるのはここまでです。新旧のハーネスで組み込みツールの名前や引数がどう変わったか、という差分表は、少なくとも私が探した範囲の公式ページには見当たりませんでした。二次情報にはいくつか具体的な記述が出回っておりますが、裏の取れていないものを手順書へ書き写すと、切り替えの当日にいちばん困るのは自分です。

ですので以下では、差分表が無くても判断できる一点だけを扱います。

output_text しか読んでいないなら、文字列の差し替えで終わります

Interactions API の応答には、最終的な文章が interaction.output_text に入ります。加えて、エージェントが途中で何をしたかが interaction.steps に並びます。

自分のコードがどちらを読んでいるか。ここが分かれ目です。

# 依存が浅い側。最終出力しか見ていません
interaction = client.interactions.create(
    agent="antigravity-preview-05-2026",
    input="今週の変更点を3行でまとめてください",
    environment="remote",
)
print(interaction.output_text)

この形であれば、agent の文字列を後継名に書き換えるだけです。ツールの名前が変わろうと引数の綴りが変わろうと、サンドボックスの中で完結する話で、こちらには降ってきません。

ひとつだけ添えておきます。後継エージェントの既定モデルは gemini-3.8-flash です。agent_config を省略している場合はこの既定が効きますので、モデルを固定したい運用であれば、この機会に明示しておくほうが後から悩まずに済みます。

interaction = client.interactions.create(
    agent="antigravity-preview-09-2026",
    input="今週の変更点を3行でまとめてください",
    environment="remote",
    agent_config={
        "type": "antigravity",
        "model": "gemini-3.8-flash",  # 省略時もこれが既定です。明示しておくと後で読み返しやすくなります
    },
)

steps を読んでいるなら、依存している名前を先に数えます

もう一方は、途中経過を自分で解釈している構成です。ツール呼び出しを記録したい、特定のツールが走ったら通知したい、という理由でこちらを書いた方は多いはずです。

# 依存が深い側。ステップの中身に手を入れています
for step in interaction.steps:
    if step.type == "function_call" and step.name == "write_to_file":
        notify("ファイルが書かれました: " + str(step.arguments))

step.name の文字列と、step.arguments のキーの綴り。この二つに寄りかかっている箇所が、切り替えで沈黙する可能性のある場所です。例外は出ません。条件に当たらなくなるだけですので、気づくのは数日後の「通知が来ていない」という違和感からになります。

まず、いま自分が何に依存しているのかを機械的に数えます。応答オブジェクトを渡すと、現れたツール名と引数キーの集合を返すだけの関数です。

def collect_tool_surface(interaction):
    """steps に現れたツール名と、その引数キーを集めます。
 
    返り値の形: write_to_file というキーに path, content という集合が入ります。
    切り替えの前後で同じ入力に対して呼び、差分を見るために使います。
    """
    surface = {}
    for step in getattr(interaction, "steps", []) or []:
        if getattr(step, "type", None) != "function_call":
            continue
        name = getattr(step, "name", None)
        if not name:
            continue
        args = getattr(step, "arguments", None) or {}
        if not isinstance(args, dict):
            args = {}
        surface.setdefault(name, set()).update(args.keys())
    return surface

getattr で受けているのは、SDK の版によってステップの属性が増減しても落ちないようにするためです。移行の確認に使う道具が移行のせいで壊れるのでは、意味がありません。

切り替える前に、同じ依頼を両方へ一度ずつ通します

差分表が公開されていない以上、いちばん確かなのは自分の入力で両方を一度ずつ動かし、返ってきた形を並べることです。停止日まではどちらも生きておりますので、いまだけ使える確かめ方でもあります。

from google import genai
 
client = genai.Client(api_key="YOUR_API_KEY")
 
PROMPT = "docs 配下の Markdown を1つ読み、見出しだけを抜き出して summary.txt に書いてください"
 
 
def run(agent_name):
    interaction = client.interactions.create(
        agent=agent_name,
        input=PROMPT,
        environment="remote",
    )
    return collect_tool_surface(interaction)
 
 
old = run("antigravity-preview-05-2026")
new = run("antigravity-preview-09-2026")
 
for name in sorted(set(old) | set(new)):
    if name not in new:
        print("[消えた] " + name + " 引数: " + str(sorted(old[name])))
    elif name not in old:
        print("[増えた] " + name + " 引数: " + str(sorted(new[name])))
    else:
        gone = sorted(old[name] - new[name])
        added = sorted(new[name] - old[name])
        if gone or added:
            print("[引数が変わった] " + name + " 消えた: " + str(gone) + " 増えた: " + str(added))
 
# 出力例（依頼の内容によって現れるツールは変わります）
# [消えた] write_to_file 引数: ['content', 'path']
# [増えた] WriteToFile 引数: ['CodeContent', 'TargetFile']

一度で結論を出さないでください。エージェントは毎回まったく同じ手順を踏むとは限りませんので、依頼の内容を二、三種類に変えて走らせ、そのうえで消えた名前だけを拾います。自分のコードが分岐に使っている名前がその中にあれば、そこが直す場所です。

もうひとつ。ファイル操作は environment を指定したときに自動で有効になり、サンドボックスの側で実行されます。function_call として応答には現れますが、こちらから結果を返す必要はありません。応答待ちのループを自作している場合、ここを取り違えると手が止まりますので、requires_action の扱いは切り替えの前に一度見直しておくと安全です。

ついでに確かめておける、裏の取れている項目

差分表は無くても、後継エージェントのドキュメントから読み取れる制約はいくつかあります。切り替えのついでに目を通しておくと、移行後に「動かない理由が分からない」時間を減らせます。

私の場合、引っかかったのは生成パラメータの行でした。旧構成の呼び出しに temperature を残したまま後継へ向けると、切り替えたその場で 400 が返ります。停止日を待たずに気づけるぶん、これはむしろ親切なほうの失敗です。

10 月 5 日より前の、落ち着いた日のうちに

最初のうち、私は外から降ってくる変更に対して、いつも相手側のドキュメントから読み始めておりました。読み終えても手は動かず、結局あとから自分のコードを検索し直すことになります。いまは順番を決めています。自分が寄りかかっている名前を数えてから、相手の変更点を読む——Lab のサイトを自動で更新する仕組みでも、受託でお預かりしているサイトのプラグイン更新でも、この順番だけは変えないようにしております。個人開発で抱えているものが増えるほど、この順番の効き目は大きくなりました。

今日やるとしたら、steps という語で自分のリポジトリを一度検索するところまでで十分です。一件も出てこなければ、agent の文字列を書き換えて終わりになります。出てきたら、上の比較スクリプトを走らせる日を今週のどこかに決めてください。

停止日の当日に慌てないためのいちばん静かな方法は、まだ両方が動いているあいだに一度だけ並べて見ておくことなのだと思います。

エージェントが揃わないまま走り出したときの止めどきについては、MCP が欠けたまま始まったセッションを、どこで止めるかに書きました。モデル ID のほうの棚卸しは二次情報の「10月16日」が一次表に見当たらない — Gemini のモデル廃止日を自分で棚卸しするが近い話です。

最後までお読みいただき、ありがとうございました。