Antigravity 09-2026：ファイル編集・Hookの対象・古い状態の拒否

バージョン変更で権限の境界も動く

Googleの9月17日のリリースノートは、5月のpreviewをantigravity-preview-09-2026へ置き換える。リモート実行のテキストだけを読む場合はagentの指定変更が中心だが、ローカルでツールを実行したりfunction callを解析したりする場合は操作契約も確認する。ファイル引数はPascalCaseとなり、編集は全体書き直しから範囲置換へ変わった。編集ツールはreplace_file_contentで、TargetFile、StartLine、EndLine、TargetContent、ReplacementContentを扱う。

そこでアプリ側に必要になるのが、どの時点で観測したファイルに対し、その変更を許可したのかという判断だ。引数の形式が正しくても、人間が1行追加した後では対象範囲が古くなる。本記事は使い捨てファイル1つを対象にした独自の未実行演習である。Kumyuのツール実行器は変更せず、有料agentも呼び出さない。

終了予定表は5月previewに2026年10月5日を記載し、表の日付は終了しうる最も早い日だと注記している。10月4日の確認時点では予告された境界であり、終了した証拠ではない。旧形式の実行器を、黙って切り替える復旧経路として残さない。

画面操作から具体的なファイル契約へ

Anthropicの2024年10月のcomputer use発表では、画面の観測と操作が公開されたagentインターフェースになった。Googleの2026年5月19日のリリースノート節はmanaged Antigravity previewを導入し、9月の節はファイル操作契約を変更している。それぞれ別の提供元の出来事であり、製品間の継承関係を主張するものではない。継続する設計課題は、提案された操作を観測時の環境に結び付けることだ。

現行のAntigravityガイドはGoogleがホストするLinux環境とツールの制限を説明する。ホストされた環境とローカル実行器は管理主体が違う。Hookの説明を適用する前に、どちらを対象にしているか記録する。本記事では短い変更表からローカル実行器のAPIや提供元の行番号規約を確定しない。

1. 1許可された1ファイルと現在のdigest
2. 2対象範囲の観測
3. 31つの置換を提案

1. 1ツール名・パス・状態を照合
2. 2その編集を許可
3. 3最終ファイルを検証

1. 1未知の操作・digest変更・対象不一致
2. 2書き込み前に拒否
3. 3理由を記録

Hookがあっても対象操作を捕捉するとは限らない

公式Hook資料のmatcherはコンテナ内のツール名をRE2で照合する。末尾が_fileの名前を対象にする例では、replace_file_contentは捕捉されない。実際のツール名に対して適用範囲を確認し、shell経由のファイル変更も別経路として調べる。

同資料では、クラッシュ、HTTPエラー、タイムアウト、認識できない判断JSONを許可として扱う。明示的な拒否は操作を取り消すが、Hookが利用できないことは拒否の成立を意味しない。したがって、権限判断に失敗したら変更を止める要件を、リモートの事前Hookだけでは満たせない。これは提供元の文書に記載された挙動であり、侵入試験の結果ではない。

ここで提案するローカル実装の方針は単純だ。唯一の書き込み経路の中で権限を判断し、明示的に成功した場合だけ進める。未知の名前、不正な引数、判断器の停止、状態比較の失敗は、そのリクエストを終了させる。ホスト環境で拒否手段が文書記載のHookだけなら、別の強制される境界を確認できるまで機密性のある書き込みを有効にしない。プロンプトやmatcherを増やしても、実行基盤の失敗時の挙動は変わらない。

使い捨ての状態で1つの編集を予行する

実装前にオフラインの作業表を作る。作業表では読みやすさのため行番号を1から付けるが、実際の呼び出し前には提供元の範囲指定と改行の規約を別途確認する。name=demo、mode=draft、owner=fixtureという3行を用意し、中央の行だけをmode=reviewedへ変える。これらは独自の演習用文字列だ。

ケース	条件	作業表で求める結果
許可された編集	現在のdigest・対象文字列・許可ファイル・新版のツール名が一致	1回だけ置換し、先頭と末尾の行は変えない。
同時挿入	観測後に行が追加された	古いdigestを検出し、書く前に拒否する。
対象不一致	範囲内が記録した文字列と違う	拒否し、別の出現箇所を探さない。
範囲外のパス	シンボリックリンクを含め演習外へ解決される	書き込み用に開く前に拒否する。
判断器の失敗	タイムアウトか有効な判断が得られない	拒否し、バイト列を変えない。
旧形式の操作	古いツール名か古い引数の大文字小文字	対応しない契約として拒否する。

ローカル実装では、このファイルの状態比較と変更を1つの直列化された操作にする。digestを確認してファイルを解放し、後から書くと競合が入る。この小さな予行では、対象へ同時に書く別の処理を許可しない。別の実利用者が必要になる前に、汎用編集フレームワークは作らない。成功メッセージだけで終わらず、最終バイト列全体を確認する。差分が正しくてもプロジェクトのビルドは失敗しうるので、ファイルに適した意味上の検証は別に定義する。

最初に失敗した境界を診断する

ツール名、正規化したパス、入力digest、判断、期待差分、最終digest、経過時間、停止理由を記録する。使い捨てファイルだけを用い、本番ファイルやfunction payload全体をログへ出さない。そこには秘密情報が含まれうる。形式の拒否は操作契約、digest不一致は古い観測、最終バイト列の不一致は変更処理や競合の問題として、モデルのタスク品質から分ける。

1リクエストの期限と小さいファイルサイズ上限を設定する。オフラインでも時間とローカル資源は使う。将来のホスト環境での予行にはモデル、sandbox、通信、保存費用が発生しうるため、別途許可された時点で現行の契約を確認する。この記事のためにagent呼び出し、リモート編集、Hookの障害注入、性能・セキュリティ測定は実行していない。表は受け入れ条件であり、測定値ではない。

コミュニティ報告にも製品の識別が必要

実際に読んだ9月23日のReddit threadは、デスクトップv2.16.0、WSL、会話の再表示を扱う。コメントにはLinuxのモデル表示やIDE拡張で編集が再適用されたという報告があるが、正確なbuild、payload、再現記録はない。個別の利用面についてのコミュニティ報告であり、Gemini APIのファイル操作やホスト環境のHookを検証したものではない。回帰らしき挙動を診断する前に製品面とバージョンを記録する、という観点で読む。

次はcomputer useの評価作業表へ進む。この更新ノートは、その観測状態に基づく評価へファイル契約と権限判断の失敗ケースを追加する。移行成功やagentの安全性が自動的に成立したとは主張しない。