Google Antigravity 2.0とは？Managed Agentsと永続環境で何ができる？

監修者_SD以外

監修者プロフィール

森下浩志

日本最大級のAI情報プラットフォーム「romptn ai」編集長。著書に「0からはじめるStable Diffusion」「0からはじめるStable Diffusion モデル・拡張機能集編」など、AmazonベストセラーのAI関連書籍を多数執筆。AIにおける情報の非対称性を解消するための社内研修や出張講義も行う。

Antigravity 2.0の全体像

ここでは、Antigravity 2.0の位置づけを先にそろえます。

Antigravity 2.0は、単にエディタ画面が新しくなった話ではありません。GoogleのI/O 2026では、Gemini APIのManaged Agents、Google AI Studio、ローカル開発へつなぐAntigravityの導線が、同じagent-firstな開発基盤としてまとめて紹介されました。

まずは「Antigravity 2.0は入口や体験の束」「Managed Agentsはその力をAPIから呼び出す経路」と分けて考えると迷いにくくなります。この切り分けが分かると、次の章で出てくる実行環境や自動化の話も整理して追いやすくなります。

Managed Agentsの仕組み

ここからは、Managed Agentsが何を肩代わりするかを見ていきます。

公式Quickstartの要点は、1回のinteraction作成でエージェント本体とremote環境をまとめて立ち上げられることです。従来のように、モデル呼び出し、実行環境、ツール接続、状態保持の土台を細かく組み合わせる代わりに、Google側のharnessに土台づくりを預けられます。

ただし、何もかも自動で決まるわけではありません。開発者は、何をさせるかという入力、必要なsystem instructions、使わせたいtoolsやskillsを設計します。Managed Agentsの価値は、全部お任せではなく、面倒な基盤を減らした上で振る舞いを決めやすい点にあります。

永続環境で残るもの

ここでは、永続環境の意味をはっきりさせます。

Managed Agentsの環境は、会話の履歴そのものではなく、独立したLinux sandboxです。environment="remote" で新しい環境を作り、返ってきたenvironment IDを次回に渡すと、同じ作業場所を開き直すようにファイルや追加パッケージの状態を引き継げます。

一方で、会話の流れをつなぐ役割はprevious_interaction_id側にあります。つまり「何を話したか」と「どんな作業場所が残るか」は別の仕組みです。この違いを押さえると、試作、検証、長時間作業をどう分けるべきか判断しやすくなります。

何が作れる？

次は、読者が一番気になる「で、何に使えるのか」の話です。

Managed Agentsが向くのは、単発の文章生成よりも、考える、実行する、結果を見てもう一度動く、という往復がある作業です。たとえばコードを書いて保存する、スクリプトを走らせて出力を確認する、設定を変えてもう一度試す、といった流れは相性が良い部類に入ります。

このあと3つの小見出しで、開発、データ処理、社内ルール付き運用に分けて見ていきます。自分の仕事を当てはめながら読むと、どこから試すべきかが見えやすくなります。

① コーディングと検証

Managed Agentsの使い道として、まず想像しやすいのがコーディングと検証です。

コードを書くだけでなく、ファイル保存や実行結果の確認まで含む往復に向いているため、「小さな検証スクリプトを作る」「テスト用の出力ファイルを生成する」「直した結果をもう一度確かめる」といった流れで価値が出やすくなります。

特に、試行錯誤の途中で中間ファイルを残したい作業では、環境が分かれている利点が効きます。ローカル開発のすべてを置き換えるというより、重い往復作業を切り出して任せるイメージで考えると導入しやすいです。

② データ処理と資料作成

次は、コード以外の実務へ広げたときの見方です。

公式の環境ドキュメントでは、パッケージを入れて実行し直す流れが前提として示されています。これは、CSVやログを整理する、グラフ用の下処理をする、資料に入れるテキストやファイルを整える、といったデータ作業にも相性が良いことを意味します。

ポイントは、出力を一度作って終わりではなく、結果を見て条件を変えやすいことです。分析メモ、生成物、補助スクリプトを同じsandboxに置けるので、途中成果を失いにくく、次の依頼へつなげやすくなります。

③ 専用ルールのagent

ここでは、Managed Agentsを自分たち仕様に近づける考え方を見ます。

公式のcustom agentsドキュメントでは、system instructionsを足すだけでなく、toolsの差し替えや、AGENTS.md、SKILL.md のようなファイルを環境にマウントする方法まで案内されています。つまり、汎用のagentをそのまま使うだけでなく、社内ルール、作業手順、出力の型を持つ専用agentへ育てやすい設計です。

この発想を持つと、Antigravity 2.0は便利なIDEというより、作法付きの実行基盤として見えてきます。記事制作、調査、コードレビューのように、毎回の判断基準が似る仕事ほど相性を考えやすいです。

導入前の注意点

最後に、試す前に知っておきたい前提を整理します。

執筆時点では、Agents OverviewではManaged AgentsがPublic Preview、Interactions APIではBetaとして案内されています。しかもInteractions APIは新しい標準として推されている一方、安定本番ではgenerateContentの継続利用も勧められています。そのため、いきなり基幹処理を全面移行するより、新規のagentic workflowや社内検証から始める方が安全です。

あわせて、環境は無期限に残るわけではなく、非アクティブが続くと削除されます。さらに外向きネットワークは既定で開いているため、機密データや外部接続の扱いは最初にルールを決めておく必要があります。便利さと運用設計はセットで考えるのが実務的です。

よくある質問

まとめ

ここまでの要点を最後に絞ります。

まずは、自分の仕事で「考える、実行する、結果を見てもう一度動く」作業を1つ選び、Managed Agentsで切り出せるかを試してみてください。

派手なデモよりも、この小さな切り出しがAntigravity 2.0の価値を一番つかみやすい入り口になります。