Antigravityの自動モード――難しいのは「全自動」ではなく「どこで止めるか」

最近のAntigravityのセッションで、こんな実用的な質問が出ました。自動モードは確かに楽ですが、エージェントが確認なしに動き出すことがあります。かといって、毎回止めて確認していたら、自分がボトルネックになってしまう、と。

この矛盾は、エージェントにコードを書かせていると珍しいことではありません。私たちの答えは、より賢い「全自動」スイッチを用意することではなく、制御をいくつかの層に分けることでした。いつ聞くのか、いつ止めるのか、どの画面で動かすのか、どんな環境で動かすのか、そして一度の会話をどう再現可能な流れにするのか。以下で紹介する機能には、すでに使えるものと、まだ開発中のものが混在しています。

自動モードで大事なのは「いつ止まるか」

まずは最も直接的な層、質問とレビューです。

最近、複数選択のサポートを追加しました。エージェントが一度に複数の質問を動的に投げかけられます。質問画面の下部では、あらかじめ設定したレビューポリシーの種類を選べます。権限については、Antigravityは自動モードに対応し、エージェント自身がコマンドを安全に実行できるか判断します。Appではデフォルトですべての操作がサンドボックス内で実行され、自分のディレクトリ内のファイルを読むだけでネットワークに触れないなら、承認は不要です。自動モードは、ユーザーが処理する承認リクエストの総数を大幅に減らせます。

ただし「自動」は「もう止まらない」という意味ではありません。CLIではShift-Tabで閲覧と実行を切り替えられます。/planはもっと明確な例で、権限設定がどうであれ、実行後に計画のレビューを出し、入力を待って必ず止まります。ルールを使って、Antigravityに「これは自動実行しないでほしい」と伝えることもできます。権限設定はプロジェクト全体のグローバル設定であり、会話のたびに説明し直すものではありません。

だからこそ、「複数選択の質問」と「レビューポリシー」はセットで見る必要があります。質問の数を増やすか減らすかではなく、本当に判断が必要なポイントに人の注意力を配分する仕組みです。会場からは、「システムは自動で動いている前提にして、重要なところだけ人が介入する」という設計思想が提案されました。これに対して私は、チームで要素をどう統合するかを研究しているところだと答えました。現時点ではこれらの選択肢しかありませんが、近いうちに新しい案を出せるはずです。この方向性は私たちも模索しています。自動化の価値はクリック数を減らすことではなく、人が本当に判断すべき場所にだけ注意を向けられるようにすることにあるのだと思います。

私自身は「Turbo」寄りの使い方をしていますが、その前提として、作業を簡単に引き継げるよう復旧手段を多く用意しています。速さは、後戻りできないことを意味しません。

モデル選び：デフォルトのGeminiで十分、速さはFlashに任せる

会場で、状況に応じてモデルを変えるのかと聞かれました。私の答えはシンプルです。個人のタスクはすべてGeminiモデルで、日常的なタスクはデフォルトの設定を使います。複数のスキルを呼び出したり、異なる効果を追求したりするタスクのときだけ、別のモードに切り替えます。

Flashもよく使います。たいてい速く、あまり考え込む必要がありません。たとえばヘルスチェックを回しているサーバーがあり、そこでFlashがスキルやコマンドを実行し、結果を表示してくれます。とても良い結果を出してくれます。私の感覚では、Antigravityは日常使いに向いていて、チームでの協業でもさまざまな種類のタスクをこなせます。

モデル選びは過剰に設計しなくてよいと思います。ほとんどのタスクはデフォルトのモデルで足ります。速く、軽くしたいときはFlashを使い、タスクの形が変わったら設定を変える。目の前のループを回し切るほうが、モデルを比べ続けるより合理的です。

同じエージェントに、4つの入り口

Antigravityは4つの別製品ではなく、同じエージェントが4つの入り口から入ってくるイメージです。どれを選ぶかは、どこまで深く関わりたいかで決まります。

Appはメインプラットフォームで、多層的なマルチエージェント監督を中心に設計されています。並列会話と分割ビューに対応し、会話を起動するための設定もいろいろあります。左端には会話レールがあり、ターンのプレビューにカーソルを合わせると日付ごとの章が見えるので、長い会話をたどるときに便利です。ArtifactsのPDFビューアでは、項目を選んでコメントでき、MarkdownやHTML以外のリッチな内容を扱うのに向いています。キーボードショートカットはすべてWebサイトに掲載されています。

CLIは、エージェントを自分の環境に置きたい人向けです。Bashの1コマンドでインストールでき、CLIはほぼ毎日更新されています。Antigravity本体もmacOS、Windows、Linux向けのアプリを提供しています。CLIの利点は、コードをどこで動かすかを制御できることです。サーバーのハイパーバイザー上にインストールしてリモートからアクセスしたり、ヘッドレス環境で安全に動かしたりできます。Appにはない機能も多く、プラグインやMCPのインストールと管理も簡単です。agy -pのような呼び出しでヘッドレスCLIにプロンプトを送り、結果を受け取れます。プランモード、自動実行モード、その中間の状態にも切り替えられます。JSON Schemaのサポート、出力の表示やフォーマットも、ヘッドレスモードで使えます。

IDE拡張は、特定のタスクを深掘りするときの橋渡しです。Xcodeへの対応を発表し、Zed、Android Studio、VS Code、Visual Studio、JetBrains IDE、Eclipseもカバーしています。基盤にはACP（Agent Client Protocol）を使っているので、同じ会話機能をより多くの画面に持ち込めます。

SDKは、ワークフローそのものを変えたい人向けです。Google Antigravity Python SDKを使えば独自のフローを構築でき、SDKのコードはGitHubでオープンソースになっています。モデル呼び出しの方法を完全に置き換えることも可能です。GemmaチームはAntigravity SDKでGemma 27Bを動かし、完全にオフラインかつ無料で実現しました。OpenAI互換のエンドポイントにも対応しているので、自分でホストしているモデルなら、ローカルでもリモートでも接続できます。ブログ記事ではハイブリッドワークフローも紹介しました。機密データはデバイス上で処理し、指定した部分だけをSDKで実行して、Antigravityから結果を受け取る形です。SDKは宣言的で、コンテキストの設定やスコープの限定を自分で制御できます。組み込みツール、モデルの種類、サブエージェントのアクセス権、実行環境も指定できます。エージェントをCI/CDパイプラインに組み込みたい人にとっては、より直接的な道です。サンドボックスについても、毎回遅い仮想マシンやDockerコンテナを立ち上げるのではなく、macOSとWindows向けに専用のサンドボックスを用意しています。

リモートコントロールは、この流れをさらに一歩進めます。私はすでに仕事の約80%をリモートコントロールに移しました。Google社内では、従業員の90%がAntigravityのWeb版を使っていると推測しています。CLIとAppにはそれぞれリモートコントロール版があり、同じ場所で共存します。

自動化の土台：サンドボックスと権限

自動モードを安心して使えるかどうかは、最終的にどんな環境で動くかにかかっています。

Appでは、デフォルトですべての操作がサンドボックス内で実行されます。CLIもサンドボックスに対応していますが、デフォルトでは有効になっておらず、設定でオンにする必要があります。macOSとWindowsの両方にサンドボックスを用意しました。Windowsでは最新のWSL APIを使い、Microsoftと協力して動作を確認しています。macOSにはコンテナシステムがあり、信頼できないコマンドを制御された環境で実行できます。これらのモードの目的は、勝手にコマンドを実行したり、システム上のプロジェクトを削除したりする心配をなくすことです。外向きのネットワークはデフォルトですべて無効で、毎回明示的に許可するか、許可リストに追加する必要があります。

サンドボックスの外側には権限システムがあります。どのツールに読み取り、設定、アクセスを許可するかを具体的に決められます。このルールはカスタムサブエージェントにもシステム自体にも適用され、CLIにも対応する設定方法があります。Vimを本当に愛用する開発者向けに、Vimモードも追加しました。CLIチームはAppとの体験の差を縮めようとしていますし、問題があれば直接相談できます。

ここで見落とされがちなトレードオフがあります。Appは安全をデフォルトにし、CLIはスイッチをユーザーに渡します。前者は「エージェントを監督したいだけ」という場面に、後者は「自分が何をしているか分かっていて、実行場所を完全に制御したい」という場面に向いています。どちらがより安全というわけではなく、デフォルト値が違うのです。

エンジニアリングループ：一度の会話を一つの流れにする

エージェントが長く連続して動けるようになると、本当に効いてくるのは、「より良いプロンプトを書くこと」から「より良いループを設計すること」への転換です。

Antigravityには、ループを巡るコマンドがすでに揃っています。/grill-meは要件を掘り下げ、/planは実施計画を出します。どちらもレビュー可能な成果物を生成します。ジェネラティブUIは、HTMLと動的な成果物で複雑な画面を構築する方法を提供します。ブラウザサブエージェントは初期バージョンからあり、Chrome MCPを制御できます。最近は組み込みブラウザのサポートも追加し、こうした操作を一か所に集めました。CLIでは/artifactで成果物を探せますし、Appではサイドパネルで確認できます。完了後には操作手順が生成されるので、何をしたのかを検証できます。

UI共有も面白い方向です。毎日使っているデータを、より直感的でインタラクティブな形で見せられます。私は可視化チャートを考えるのが好きです。これは非開発者にとって特に有用です。たとえば財務情報を見るとき、プロダクト内にダッシュボードを生成し、すべてオフラインで、サイドバーの一要素として動かせます。チームがApps Scriptなどを使って作ったクールな事例も見てきました。まだ試したことがないなら、何かを作り始める前に、まず可視化プロトタイプを作ってみることをおすすめします。

ビジュアルはアプリ開発で見落とされがちです。Chrome MCPのサブエージェントと組み込みブラウザのサブエージェントは、生成物の動画や画像を取得し、Geminiモデルの視覚理解でデザインを改善できます。さらに一歩進めたいなら、Google LabsのStitchを見てください。ワンクリックのMCPサポートがあり、Antigravityから委託してアプリ専用のデザインを生成できます。ハッカソンのような場面で特に役立ちます。

バージョン管理とターミナルも同じループの中にあります。AntigravityにはネイティブのGit機能があり、コミットメッセージを完全に管理し、コミット内容を正確に指定したい人に向いています。ターミナルはリモートコントロール系のタスクで特に便利で、ソフトウェアをインストールしたリモート端末で直接コマンドを実行できます。

マルチエージェント協業の課題はコンテキストです。現在の最善策のひとつは、会話の種類ごとに独立したGitワークツリーを使うことです。それらは.geminiフォルダに置かれ、Antigravityが管理し、会話を削除すると完全に消えます。さらに高度な調整機能も開発中で、サブエージェントが毎回コードベース全体のコピーを立ち上げなくて済むようにしています。

もう一段外側には、BoostやTeamworkといったコマンドがあり、本当の並列化を実現します。/learnは、うまくいった会話のあとに立ち止まって振り返り、スキルやルールを更新、削除、再設定するのに向いています。スケジュールと自動化は、cronのようにエージェントを動かします。ずっと見張っている必要はなく、自動化プログラムから会話を開始し、設定したカスタムフローを起動するだけです。私の習慣は、仕事を始めるときにメールやカレンダー、イベントを確認し、ブロッカーやフォローが必要な人を見つけることです。そうすれば、最初から確認して行動できる内容が用意されます。

冒頭の問いに戻りましょう。自動モードにどこまで任せるべきか。私の考えは、「任せるか任せないか」ではなく、「どこで止まるかを設計してあるか」です。権限、計画、サンドボックス、ワークツリー、スラッシュコマンド。一見ばらばらの機能ですが、すべて同じ問いに答えています。エージェントが長く動くようになったとき、人がどのポイントで介入すれば、雑事に埋もれず、判断権も手放さずに済むのか、という問いです。