エディタから、エージェント管理へ ── Google Antigravity 2.0 が示す Agent OS の到来

エディタからエージェント管理へ ── 開発体験の重心移動

過去 2 年の AI コーディングツールの進化は、ほぼ 「エディタ」を中心に語られてきた。GitHub Copilot から始まり、Cursor、Claude Code、Codex CLI、Grok Build。どれも「エディタの中で AI がコードを書く」ことを軸に進化した。

Antigravity 2.0 はこの軸自体をずらした、と私は読んでいる。今回のリリースのキーポイントは大きく 4 つ：

• Desktop app ── 複数エージェントを並列で動かす command center
• Antigravity CLI ── Gemini CLI からの移行先。Desktop と同じ agent harness を共有する別 UI
• Antigravity SDK ── harness を自分のワークフロー / プロダクトに組み込んで自前 PC・サーバーで動かす方向
• AI Studio × Android × Firebase 連携 ── プロンプト → 実装 → 検証 → 公開の統合導線

並べてみると分かるが、これは「エディタの強化」ではない。「エージェントをどう束ね、どう動かすか」のレイヤーに重心が移ったと読める。1 つの作業を 1 つのエディタで進める感覚から、複数の作業を同時に走らせ、それを管理する感覚へ。

4 つの柱 ── Desktop / CLI / SDK / 統合導線

>2-1Desktop app ── command center

複数のエージェントを並列で動かす命令塔。dynamic subagents（動的に子エージェントを増減）、scheduled tasks（cron 的な定期実行）、Project 単位の権限管理が入った。「1 つの作業を 1 つのエディタで進める」感覚から、「複数の作業を同時に走らせて見渡す」感覚に近づいた。

>2-2Antigravity CLI ── 同 harness の別 UI

従来の Gemini CLI からの移行先。ターミナル派向けの軽量 UI だが、重要なのは Desktop と同じ agent harness を共有する点。CLI だけ別物ではなく、同じ基盤の別インターフェースになる。Desktop で組んだエージェントが CLI からも同じ挙動で呼べる、という構造。

FIG.2-2 — SHARED HARNESS

外側の点線枠が Antigravity ローカルインストール。中に Desktop (GUI) と CLI (Go binary) の 2 つの front-end が同居し、両方の矢印が 同一の LOCAL APP SERVER（agent harness 本体: agent definitions / permissions / scheduler / tools · skills）に流れ込む。Desktop で組んだジョブが CLI からも同じように呼べるのはこのため。すべての model 呼び出しは下の Gemini 3.5 Flash API に集約される。

>2-3SDK ── harness を自分のプロダクトに埋め込む

Google の agent harness を、自分のワークフローやプロダクトに組み込める方向に広がった。これは 「AI にコードを書かせるツール」 ではなく 「AI エージェントを作って運用する基盤」 に近い。SDK で書いたコードが動く場所は 自前の PC / サーバー / CI ランナー ── Google が hosted で動かしてくれるわけではなく、自社プロダクトの一部としてあなたのプロセス内で実行される。Antigravity が単なる Google 純正 IDE で終わらず、他社プロダクトの中で動く部品として広がる可能性がある。

FIG.2-3 — SDK EMBED

上層 = あなたのアプリケーション（Slack ボット / 社内ダッシュボード / Datadog アラートを受けた自動修復バックエンド等）が Antigravity SDK を import / call する。中層 = agent harness をライブラリとして使う API（client = Antigravity(...) / result = client.run(prompt, context)）。下層 = SDK は 自前のプロセス（local PC / server / VM / container / CI runner）で動く ── Google が hosted で動かしてくれるわけではない。agent は「話しかける hosted service」ではなく「import する部品」になる。

>2-4AI Studio × Android × Firebase 連携

「3 つの製品が UI 上で繋がる」というより、Antigravity を中心 harness とし、両端に AI Studio（入口）と Android / Firebase（出口）を Skill / 共有 harness 経由で繋ぐ構造。具体的な橋渡しは以下:

• AI Studio → Antigravity（"Export to Antigravity"）: AI Studio Build 自体が今や Antigravity と同じ agent harnessを使う。Web 上で試作した agent を、専用ボタンで Antigravity に書き出すと 「full agent conversation」（会話履歴 / agent 設定 / コード）ごと ローカル環境に持ち越せる。「プロンプトをコピペし直す」のではなく、Web プロトタイプ → ローカル production への state 保持移行が公式機能になっている。
• Antigravity → Android: 公式の Android Skills を agent に装着すると Android SDK / Gradle / マニフェスト等の流儀が harness 内に追加される。さらに Android CLI 1.0 の studio コマンドで起動中の Android Studio に接続し、IDE の深いコード理解を借りられる（"Open in Android Studio" 的なハンドオフを agent 主導で発火させる）。エンドツーエンドの Android アプリ構築まで担当できる構造。
• Antigravity → Firebase: 同様に Firebase Skills で Firestore / Functions / Hosting / Auth を agent が理解し、設定とデプロイまで含めて任せられる

つまり Google エコシステムの「縦の統合」は、UI レベルではなく harness と Skill（agent への能力パック）レベルで再設計されている。アイデア → 実装 → 検証 → 公開の距離を縮める仕掛けが、エディタの追加機能ではなくエージェント基盤として実装されているのが特徴的。

FIG.3 — INTEGRATION BRIDGES

中央の Antigravity 2.0 が agent harness の本体。左 UPSTREAM AI Studio から "Export to Antigravity" で full agent conversation（chat / config / code）が state 保持のまま 持ち越される。右 DOWNSTREAM の Android / Firebase は Skills（装着可能な能力パック） として harness に追加され、SDK / Gradle / Firestore / Functions などのドメイン流儀を agent が理解する。UI ではなく harness と Skill の層で統合している。

"専門ワーカー層" ではなく "Agent OS" のレイヤー

Antigravity 2.0 を Claude Code / Codex CLI / Grok Build と並べて「どれが一番か」と比べると、論点がズレる。これらはレイヤーが違う。

>3-1専門ワーカー層 vs Agent OS

Antigravity 2.0 の登場で、Google 純正の "Agent OS 寄り" プロダクトがフロントに出てきた。同じ Google 内では Workspace Studio が「Workspace 圏内の Agent OS」として閉じているのに対し、Antigravity は開発文脈の横断 Agent OSを狙っている。

>3-2VS 構図で並べると壊れる

「Antigravity 2.0 vs Claude Code」のような並べ方はレイヤー違反になる。Antigravity が SDK として他社プロダクトに広がれば、その上で Claude Code を呼ぶ・Codex CLI を呼ぶ・Grok Build を呼ぶ、という構図もありうる。比較対象は同じ Agent OS 層の Hermes / Copilot Studioに置くのが筋。

FIG.4 — LAYER STACK / Agent OS が specialist worker を呼ぶ

上層 Agent OS 層（Antigravity 2.0 / Hermes / Copilot Studio）が下層の 専門ワーカー層（Claude Code / Codex CLI / Grok Build / Cursor Agent）を "calls / orchestrates" する 2 階層構造。同じレイヤー内で比較（peer comparison）し、レイヤー間で組み合わせる（cross-layer composition）、というのが正しい思考の進め方。

比較軸の刷新 ── 「モデルの賢さ」では足りない

Antigravity 2.0 が変えたのは「個別の AI コーディングツール」ではなく 「比較軸そのもの」だ、というのが私の見方。§02 で見た 4 つの柱（Desktop / CLI / SDK / 統合導線）を構造として読み返すと、それぞれが従来の「どのモデルが賢いか」では捉えられない設計選択を含んでいる:

• Desktop の dynamic subagents + scheduled tasks → 「どんな harness で組むか」「いつ 自動実行するか」
• CLI が Desktop と app server を共有（§2-2 FIG）→ 「同じ harness を別 UI から呼ぶ」という harness 設計
• SDK が自前プロセスで動く（§2-3 FIG）→ 「どの 権限境界 / どこで動くか」を呼び出し側が決める
• AI Studio / Android Skills / Firebase Skills（§2-4 FIG）→ 「どの コンテキストを agent に与えるか」を Skill パックで切替
• Antigravity の "agentic IDE" としての出力レビュー UI → 「どう人間が レビューするか」

つまり Antigravity 2.0 の構造を素直に解きほぐすと、自然に harness / 権限境界 / コンテキスト / タイミング / レビュー という 5 つの軸が立ち上がってくる。「Agent OS とは何の集合か」を問うた瞬間に出てくる軸、と言ってもいい。

Antigravity 2.0 が示しているのは、AI ツールの比較軸そのものを更新しろというメッセージだと思う。

FIG.1 — AXIS MAP

旧軸は「どのモデルが賢いか / どのエディタが速いか / コンテキストウィンドウ」。新軸は harness / 権限境界 / コンテキスト / 自動実行タイミング / レビュー の 5 つ。モデル単体性能ではなく Agent OS の設計で比べる時代へ。

軸ごとに「エディタ時代の評価」と「Agent OS 時代の評価」を並べると、何が変わったのかが一目で見える:

補足: 旧軸の「どのモデルが賢いか（GPT-5 / Claude Opus / Gemini / grok-4.3）」は、harness や context によって出力品質が桁違いに変わるので、もはや単独軸として成立しにくい。

この 5 軸の設計が 開発生産性そのものを左右する。モデルが賢くなっても、harness が雑だと「Slop を自動化するだけ」になる（Slop を自動化するなの原則はここでも効く）。

AI コーディングの次の主戦場 ── エディタの中ではない

結論はシンプルだ。AI コーディングの次の主戦場は、エディタの中ではなく、エージェントをどう編成・監督・継続実行するかになる。

FIG.2 — BATTLEFIELD TIMELINE

主戦場の階段型タイムライン。2023 プロンプト → 2024 コンテキスト → 2025 エディタ → 2026〜 Agent OS。Antigravity 2.0 がこの転換点にいる。

これまでの主戦場：

• 2023: プロンプトの上手さ（プロンプトエンジニアリング）
• 2024: コンテキストの揃え方（vibe coding / Cursor）
• 2025: エディタの中での AI 介入（Claude Code / Codex / Grok Build）

これからの主戦場：

• 2026〜: Agent OS としての harness 設計 ── Antigravity 2.0 / Hermes / Copilot Studio / Workspace Studio
• 個人開発者の「使うツール」が、エディタ単独から 「Agent OS + 専門ワーカー」の組み合わせ に移る
• 「複数の作業を並列で進める / cron で自走させる / 自分の文脈を harness に蓄える」が日常になる

個人と組織それぞれの選び方

個人 vs チーム / 組織で何が変わるかを §04 の 5 軸ごとに並べると、選び方の根拠が見える:

補足: 「harness」自体は個人 / チーム中立な概念（モデルに巻き付ける実行装置）。チーム対応の度合いは個別実装に依存する ── Claude Code / Hermes / Cursor は基本「個人ローカル」前提、Antigravity 2.0 は Project permission + SDK + Enterprise 文言で「個人とチームの両建て」、Copilot Studio は M365 圏内で「最初からチーム/業務」を前提。

>6-1個人 ── Hermes と Antigravity を併用

OSS 派の個人は引き続き Hermes が強い。Obsidian 連携・多モデル切替・gateway（Telegram / Discord / LINE / Slack）の標準対応は今のところ Hermes ならでは。

Google エコシステム派の個人には Antigravity が刺さる。AI Studio で試したアイデアを Antigravity Desktop に持ち込み、Firebase まで一気通貫で持っていける統合導線は Hermes には作れない。

実用解は 併用。Hermes で個人の暗黙考プールを動的にオーケストレーションし、Antigravity を Google 圏の重い開発作業に当てる。

>6-2組織 ── 3 Agent OS の横断選定

エンタープライズでは 3 つの Agent OS を「業務文脈」「開発文脈」「個人文脈」で使い分ける構図になる：

• Microsoft Copilot Studio ── M365 / Power Platform 圏の業務自動化
• Google Workspace Studio ── Google Workspace 圏の業務自動化
• Google Antigravity 2.0 ── 開発文脈の Agent OS（横断）

選定は 「どの圏のエコシステムを軸にするか」 でほぼ決まる。M365 中心なら Copilot Studio、Google 中心なら Antigravity + Workspace Studio。業務系（Workspace / M365）と開発系（Antigravity）を別 Agent OS として併用するのが自然。