Antigravity 2.0・CLI・IDE・SDK — 4つのサーフェスを実プロジェクトで束ねる

Antigravity CLI — ターミナルから離れたくないとき

CLI は高速性を狙って Go で書かれていて、キーボードだけで完結させたい人に向いています。アクティブなコマンドラインをロックせずに、ターミナルからバックグラウンドのエージェントを起動できるのが特徴です。

決め手になりやすいのは、ヘッドレス実行が要るかどうかです。SSH 越しの作業や、リモートのコンテナ内で動かしたい場合は、画面を持つアプリよりも CLI のほうが素直に収まります。私の場合、ブログのデプロイ周りをサーバー上で確認するときなど、手元にエディタを開かない作業では CLI を選ぶ場面が増えました。

なお、コンシューマ向けの Gemini CLI は 2026年6月18日に提供を終了し、Go 製の Antigravity CLI へ置き換わりました。以前 Gemini CLI をシェルスクリプトや cron に組み込んでいた方は、コマンド名と呼び出し方が変わっている可能性があります。放置していた自動処理が静かに止まっていないか、移行のタイミングで一度確認しておくと安心です。

Antigravity IDE — 変更を1行ずつ確かめたいとき

IDE サーフェスは、エージェントを今のワークスペースの中に直接置く形です。エージェントが編集しているコードを正確に目で追い、変更を1行ずつ承認したり拒否したりしたい場面で力を発揮します。

組み込みのデバッグ機能を使うと、エージェントがランタイムエラーを確認し、修正案をエディタ上に提示してくれて、それをワンクリックで適用できます。「AI に任せきりにせず、自分の目で通してから反映したい」という慎重なレビュー志向の人には、この入り口がいちばん落ち着きます。私もリリース前の最終確認では、変更を一つずつ目視できる IDE に切り替えるようにしています。

Antigravity SDK — 自分専用のエージェントを組みたいとき

SDK は Python のライブラリで、独自のカスタムエージェントをゼロから組み立てたいときの選択肢です。公式ツールを支えているのと同じ共有ハーネスの上で動くため、Google 公式のツールがアクセスしているのと同じツールやルールに直接触れられます。ローカルでエージェントを書いて、コードを一切変えずに Google Cloud へデプロイできる、という流れも示されています。

ただ、いきなり SDK でフルスクラッチのエージェントを書く前に、私がまず勧めたいのは「CLI のヘッドレス実行を既存のスクリプトから呼ぶ」という一段軽い自動化です。SDK でロジックを組むほどではないけれど、決まった手順を自前のパイプラインに組み込みたい、という用途はこちらで十分まかなえます。

ヘッドレス実行を放置運用に組み込む

私が最初に効果を実感したのは、記事のコード例を検証する工程をスクリプト化したときでした。手作業では1本あたり10分ほどかけていた確認が、スクリプト化して1分未満に短縮でき、しかも見落としが減りました。CLI はヘッドレスで起動できるので、Python の subprocess から呼び出して、結果を後続の処理に渡せます。以下は、指定したプロンプトをエージェントに投げ、標準出力を受け取るだけの最小のラッパーです。何を解決するコードかというと、「毎回ターミナルに張り付いて同じ指示を打つ」手間を1回のスクリプト実行にまとめるためのものです。

import subprocess
 
def run_agent(prompt: str, workdir: str = ".", timeout: int = 600) -> str:
    """Antigravity CLI をヘッドレスで実行し、標準出力を返す最小ラッパー。
    実際のフラグ名は導入中のバージョンの `antigravity --help` で確認してください。"""
    result = subprocess.run(
        ["antigravity", "run", "--headless", "--prompt", prompt],
        cwd=workdir,
        capture_output=True,
        text=True,
        timeout=timeout,
    )
    if result.returncode != 0:
        raise RuntimeError(f"agent failed: {result.stderr.strip()}")
    return result.stdout.strip()
 
 
if __name__ == "__main__":
    report = run_agent(
        "content/ 配下の新しい記事のコードブロックを抽出し、"
        "構文エラーがないか検証して、問題のあった箇所だけを一覧にまとめて"
    )
    print(report)

なぜ subprocess.run に timeout と returncode のチェックを必ず入れるかというと、放置運用では「静かに失敗して途中の出力だけ残る」のがいちばん厄介だからです。タイムアウトと戻り値で明示的に落としておけば、cron やスケジューラのログに失敗が残り、気づける状態になります。ここを省くと、成功したつもりで空の結果を後続に流してしまう事故が起きます。

フラグ名（run / --headless / --prompt）はバージョンによって変わる可能性があるため、導入している環境で antigravity --help を一度確認してから合わせてください。ここで大事なのは特定のフラグそのものではなく、「画面を持たない入り口があるからこそ、エージェントを自分のパイプラインの一部品として扱える」という設計の考え方です。SDK に進むのは、この段階で「もっと細かく状態を持ちたい」「途中でツールを差し替えたい」と感じてからで遅くありません。

1つの案件で4つをどう束ねるか

ここまでを踏まえて、私が実際にやっている段階ごとの割り当てを整理します。ひとつの機能追加を例にすると、流れはこうなります。

大事なのは、最初から正解を当てにいかないことです。コアは共通なので、ある作業で IDE を使い、別の作業で 2.0 に移っても学び直しはほとんど発生しません。私自身、案件の段階に応じて入り口を行き来していて、その都度いちばん手の届きやすいものを選ぶ運用に落ち着きました。段階が進むほど「人の目で確かめる」から「自動で回す」へ重心が移り、それに合わせて入り口も IDE から CLI・SDK へと移っていく、という流れが自然でした。

コストと移行の落とし穴

サーフェスの選択とは別に、実運用では利用枠とバージョンの管理がついて回ります。料金プランでいうと、AI Ultra（月額 $100）は AI Pro と比べて Antigravity の利用上限がおよそ5倍に設定されています。複数の案件で並行実行を多用する場合、2.0 の同時タスクは枠を消費しやすいので、どのプランでどこまで回せるかは早めに把握しておくと安心です。個人開発で無理なく回すなら、まず Pro の枠内で並行数を抑え、詰まる頻度が上がってから Ultra を検討する、という順序が現実的でした。

もう一つ、2.0 系のアップデートで一部の開発環境が壊れたという報告も出ています。私の対処は単純で、動いている構成のバージョンを固定しておき、更新は別のディレクトリで一度試してから本番に反映する、という段階移行です。自動処理を止めないためには、この「いきなり全部を最新にしない」姿勢がいちばん効きました。

迷ったときの判断軸

入り口で迷ったら、次の順に自分へ問いかけると素早く絞り込めます。まず「コードを書くより、複数の作業を同時に回したいか」を考え、当てはまるなら Antigravity 2.0 です。次に「ターミナルから出たくない、あるいはヘッドレスで動かしたいか」が当てはまるなら CLI を選びます。「変更を1行ずつ自分で承認したいか」なら IDE、「自分でエージェントのロジックを組みたいか」なら SDK、という順です。

そのうえで、段階が進んだら入り口も持ち替える、という視点を足してみてください。設計段階の 2.0 から、実装の IDE、検証の CLI、定常化の SDK へ。ひとつの案件の中で自然に重心が移っていくのを感じられれば、4つの入り口はもう「迷いの種」ではなく「使い分けられる道具」になっています。

まずは一番手に馴染む入り口をひとつ開き、次の段階で別の入り口に持ち替えてみる。その一往復が、4つを束ねる感覚をいちばん早くつかませてくれるはずです。お読みいただきありがとうございました。