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

Posted at 2026-05-20

本記事は自分のブログの内容を持ってきたものです。本家:
https://okikusan-public.pages.dev/antigravity-agent-os

Antigravity 2.0 は単なる AI IDE のアップデートではなく、開発体験の重心が「エディタ」から「エージェント管理」へ移る転換点に見える。Desktop / CLI / SDK / 統合導線を束ねる構造は、Claude Code / Codex / Grok Build と同じ「専門ワーカー層」というより、Agent OS に近い。

比較軸はもう「どのモデルが賢いか」だけでは足りない。harness 設計 / 権限境界 / コンテキスト / 自動実行タイミング / レビュー、この 5 つが開発生産性を左右する。AI コーディングの次の主戦場を整理する。

▍ 元ネタ

▍ TERMS — 用語と前提（先に揃える）

本記事で繰り返し出てくる用語と編集軸を最初に揃える。

Agent harness
モデルの周りに巻き付ける「実行装置」全体。Karpathy の Agent = Model + Harness 定義でいう Harness 側。具体的には:

システムプロンプト / ロール定義
ツール (file 操作 / Bash / Web fetch / MCP 経由の外部呼び出し等)
メモリ / 状態
権限とガードレール
フィードバックループ (再試行、検証、サブエージェント生成)

実例:

Claude Code の harness = CLI agent loop + ツール群 + プロジェクト権限
Cursor の harness = エディタ統合 + Apply 機構 + コードベース index
Antigravity の harness = ローカル app server + ランタイム + Skill パック装着機構

要するに「モデルが賢くても harness が雑だとエージェントとして使い物にならない」「同じモデルでも harness を取り替えると振る舞いが激変する」、その振る舞いを決める部分が harness。

Agent OS 層 / 専門ワーカー層

Agent OS 層 = harness を共有しつつ複数 UI / 権限 / scheduler / エージェント編成を一元管理 (Antigravity / Hermes / Copilot Studio)
専門ワーカー層 = 呼ばれて作業する側 (Claude Code / Codex CLI / Grok Build)

「Agent OS」は Google 公式の用語ではなく、コミュニティと本記事の編集軸。

Subagent: 親エージェントが動的に生成する子エージェント。Antigravity 2.0 のローンチデモでは 93 並列で OS をゼロから構築。

Skill: エージェントに装着する能力パック。Android Skills / Firebase Skills など、特定ドメインの API・流儀を harness に追加する仕組み。

App server: Antigravity ローカルインストール内に常駐する共有バックエンド。Desktop UI と CLI バイナリ両方が同じ app server を叩いて harness を動かす。

比較 5 軸: 本記事の評価軸 ── (1) harness 設計 / (2) 権限境界 / (3) コンテキスト / (4) 自動実行タイミング / (5) 人間レビュー。

TL;DR

Antigravity 2.0 のポイントは Desktop / CLI / SDK / AI Studio×Android×Firebase 連携 の 4 つ。バラバラな機能追加ではなく、同一の agent harness を 4 つの UI で共有する構造。
Claude Code / Codex / Grok Build は専門ワーカー層、Antigravity 2.0 はそれらを束ねる Agent OS。レイヤーが違うので "VS" で並べると論点が崩れる。
比較軸の刷新が必要：(1) どの harness で / (2) どの権限境界で / (3) どのコンテキストを読み / (4) どのタイミングで自動実行し / (5) どう人間がレビューするか。
個人なら Hermes (OSS) × Antigravity 純正、組織なら Copilot Studio / Workspace Studio / Antigravity の横断選定。エディタ単体比較は周回遅れ。

§ 01 SHIFT — エディタからエージェント管理へ

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

Antigravity 2.0 はその流れを転換させた。これは AI IDE のアップデートではない。Desktop アプリ / CLI / SDK / AI Studio との統合導線を一斉に揃え、**「エージェントを管理するための基盤」**になっている。同一の agent harness を 4 つの UI で共有する構造、と読むのが筋。

§ 02 PILLARS — 4 つの柱

2-1 Desktop app ── command center

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

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

従来の Gemini CLI からの移行先。ターミナル派向けの軽量 UI だが、重要なのは Desktop と同じ agent harness を共有する点。CLI だけ別物ではなく、同じ基盤の別インターフェースになる。

▍ 補足: 「同じ harness を共有」とは
2 つの別アプリが競合するのではなく、1 つのローカルインストールの中に Desktop UI / CLI バイナリ / 共通の app server (agent harness 本体) が同居する構造。@karthickdotxyz の表現でいう "Same tools and app server as Antigravity 2.0"。

同時起動は不要 ── Desktop か CLI か、どちらか片方で完結する

設定 / agent 定義 / 権限 / scheduled task は共有 ── Desktop で組んだジョブが CLI からそのまま呼べる

CI / サーバー headless 用途は CLI 中心、対話開発は Desktop 中心、という棲み分けが自然になる

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

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

▍ CLI と SDK ── 何が違うのか
ローカル / サーバーどちらにも入れられる点は CLI も SDK も同じ。違うのは**「想定された主用途」**:

CLI = 人間 (またはシェルスクリプト) が直接対話する用途を主目的にした対話的フロント

SDK = あなたのプログラムから関数呼び出しでエージェントを使う用途を主目的にしたライブラリ

厳密には CLI もプログラムからシェル経由で呼べるが、subprocess 経由は (a) 起動オーバーヘッド / (b) テキスト出力のパースが脆い / (c) 型がない / (d) ストリーミングや構造化イベントが扱いづらい、というコストがつく。AWS CLI と boto3 (AWS Python SDK) の関係と同じ。

2-4 AI 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 設定 / コード) ごと ローカル環境に持ち越せる。
Antigravity → Android: 公式の Android Skills を agent に装着すると、Android SDK / Gradle / マニフェスト等の流儀が harness 内に追加される。さらに Android CLI 1.0 の studio コマンドで起動中の Android Studio に接続し、IDE の深いコード理解を借りられる。
Antigravity → Firebase: 同様に Firebase Skills で Firestore / Functions / Hosting / Auth を agent が理解し、設定とデプロイまで含めて任せられる。

Google エコシステムの「縦の統合」は、UI レベルではなく harness と Skill (agent への能力パック) レベルで再設計されている。

公式ローンチ動画: https://www.youtube.com/watch?v=6C0FjHoN3qE

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

▍ 用語注: 「Agent OS」について
本記事で繰り返し使う 「Agent OS」 は Google 公式の用語ではない。Antigravity 2.0 のローンチ直後に X 上で @grok が "the emerging Agent OS category" と言及し、@arsh_goyal も "centralized Agent Manager" と類似のフレーミングをしている。本記事はこの言葉を借りて、同一 harness を複数 UI で共有し、権限・スケジューラ・サブエージェント編成を一元化する構造を OS の比喩で捉える編集軸として使う。

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

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

	専門ワーカー層	Agent OS 層
役割	呼ばれて作業する側	全体を編成・監督する側
代表例	Claude Code / Codex CLI / Grok Build / Cursor Agent	Hermes (OSS) / Microsoft Copilot Studio / Google Antigravity 2.0
得意	即時推論・コード生成・ファイル操作	複数 UI / 並列実行 / 権限管理 / harness 共有を一元化

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

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

▍ Hermes / Copilot Studio との直接比較

Hermes = OSS / 個人寄り / 多モデル / 22 gateway / Obsidian 連携 / ドメイン汎用 (コード以外も)

Microsoft Copilot Studio = M365 圏内 / 企業権限管理 / Power Platform 連携 / 業務ワークフロー特化

Google Antigravity 2.0 = Google 純正 / AI Studio × Android × Firebase 縦統合 / ソフトウェア開発に特化 ("Built for developers for the agent-first era" を公式に明言)

スコープが違う点が重要: 同じ Agent OS 層に居るからといって役割が同じわけではない。Hermes は領域非依存の汎用 harness、Copilot Studio は業務ワークフロー、Antigravity は software engineering ドメイン専用。**「個人/組織がどのドメインで agent を編成するか」**で選び方が変わる。

§ 04 AXIS — 比較軸の刷新

§02 の 4 柱を構造として読み返すと、それぞれが従来の「model IQ 軸」では捉えられない設計選択を含んでいる:

Desktop の dynamic subagents + scheduled tasks → どんな harness で組むか / いつ自動実行するか
CLI が Desktop と app server を共有 → 同じ harness を異なる UI から呼ぶ設計
SDK が自前プロセスで動く → どの権限境界 / どんな環境で動かすか
AI Studio / Android / Firebase Skills → どのコンテキストを agent に与えるか
agentic IDE のレビュー UI → どう人間がレビューするか

つまり Antigravity 2.0 を理解しようとすると、自然に「harness / permission / context / timing / review」という 5 つの軸が立ち上がってくる。

▍ これは私見: 5 軸を選んだ理由
この 5 軸は Google / IDC / Forrester 等が定めた標準軸ではなく、私（菊池）が「これが効く」と考える編集的合成。「3 軸でも 7 軸でもなく、この 5 軸でこそ Agent OS 時代の生産性を捉えられる」と判断した根拠:

harness: モデルが同じでも harness 設計でエージェントの「振る舞い」が決まる

権限境界: エージェントが自律的に動く時代、permission scope の設計が blast radius を決める

コンテキスト: 同 IQ の同モデルでも、与えるコンテキストで出力品質が桁違いに変わる

タイミング: 手動 / hook / cron で動く agent は別物。Antigravity 2.0 が scheduled tasks を公式機能にした事実が補強

レビュー: human-in-the-loop の負荷が生産性のボトルネック

個々の用語は業界共通ですが、この 5 つを「評価軸セット」として束ねたのは私の判断。違う切り方を提案する人がいて当然です。

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

軸	エディタ時代 (〜2025) の評価	Agent OS 時代 (2026〜) の評価
harness	エディタの補完速度・UX (Cursor / Claude Code / Codex のどれが速い・使いやすいか)	どんなツール・記憶・権限・フィードバックループをモデルに巻き付けるかの設計
権限境界	1 人の開発者が手で操作する前提なので、ほぼ議論不要	自律 agent が動くので Project / User / Agent 単位の permission scope が blast radius を決める
コンテキスト	コンテキストウィンドウのサイズ (何トークン入るかの「量」)	何を引っ張ってきて agent に与えるか (docs / コード / issue / 運用ログ、という「質」と Skill パック)
タイミング	人間がtyping する瞬間に補完が出るかどうか (同期 / 即時)	手動 / hook / cron / scheduled task で agent をいつ走らせるか (非同期 / 並列 / 24/7)
レビュー	コードを書く前後で人間が読む (人間が中心、AI は補助)	自動実行された agent 出力をどこまで信頼し、どこで人間が止めるか

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

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

§ 05 BATTLEFIELD ── AI コーディングの次の主戦場

主戦場はもうエディタの中ではなく、Agent OS のオーケストレーション設計にある。

2023: Prompt engineering (single model calls)
2024: Context assembly (RAG + memory)
2025: AI in the editor (Copilot + inline suggestions)
2026+: Orchestrate agents (Agent OS) ── compose / supervise / continuous execution

▍ VOICES — ローンチ 48 時間で出てきたユースケース

ローンチから 48 時間で X 上に出てきたユースケースを抜粋。話題は「専門ワーカーが書く」ではなく「エージェント群を編成して動かす」側に明らかに寄っている。

@andreasawires: "93 parallel sub-agents, 12 hours, 15K+ model requests, 2.6 billion tokens, under $1K in API credits" でフル OS をゼロから構築
@andyzhang (Antigravity チーム): "Antigravity 2.0, a desktop application to manage all of your agents" の launch 告知
@mirrokni (Vahab Mirrokni, Google): Antigravity の /teamwork agents で AlphaZero 論文を end-to-end 再現 (RL + TPU + Web アプリ)
@SHT4BHARAT: "We are officially out of the chatbot era and deep into production-scale autonomous workflows"
@karthickdotxyz: Antigravity CLI 公式ローンチ告知 ── Go 製、async workflows、Same tools and app server as Antigravity 2.0
@neuecc (Yoshifumi Kawai): 「Antigravity 2.0 の変化の方向性は当然っちゃあ当然。実際 Cursor 3 めっちゃ好ましかったですもの」
@gptzone_net: "Antigravity 2.0 no se debería evaluar como un autocompletado más agresivo. Se debería evaluar como un cambio de workflow"
@BeamManP: Gemini 3.5 Flash が音楽の構造解析を可能に ── 同じエンジン上で起きている変化として

§ 06 FIT — 個人と組織それぞれの選び方

▍ ここからは私見です
このセクションで述べる「個人なら○○、組織なら○○」という選び方は、Google / Microsoft / Nous Research 等の公式ガイドラインではなく、私（菊池）の個人的な推奨です。

事実ベース: Hermes = OSS / 多モデル / Obsidian 連携 / 汎用ドメイン。Antigravity 2.0 = Google エコシステムに縦統合 / ソフトウェア開発特化。Microsoft Copilot Studio = M365 圏内 / 業務ワークフロー特化。

私見: 個人開発者なら Hermes と Antigravity の併用が現実解と私が考えるが、組織で違う最適があり得る。「全部 Copilot Studio に寄せた方が運用が楽」「全部 Hermes ベースで OSS 統一する方が透明性が高い」など、違う見解も十分成立する。

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

軸	個人用途	チーム / 組織用途
harness	各自ローカルで好きな harness を入れる	統一 harness を社内標準化 / Antigravity SDK で社内プロダクトに埋め込んだカスタム harness
権限境界	個人の Mac / 個人 repo への read / write が中心	Project / User / Role の階層 ACL、社内システムへの権限分離、agent 個別の scope 制限
コンテキスト	個人の Obsidian / 個人 git repo / 個人 Slack DM	社内 Confluence / 共有 GitHub org / 全社 Slack / Linear・Jira / on-call runbooks
タイミング	個人 PC で対話的、または個人の cron で軽く回す	共用サーバー / CI ランナー / 24/7 稼働環境に SDK 経由で agent を組み込む
レビュー	個人の self-check	code review / PR approval flow / 監査ログ / コンプライアンスチェック

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

▍ チームで harness を共有するなら SDK 一択
Antigravity の Desktop / CLI のスタンドアロン構成は、構造上「個人マシンに常駐する app server」が前提。同じハーネスをチームで共有しようとしても、agent 定義 / Project / scheduled task はそれぞれのローカル app server に紐づくので、git で config を share してもインスタンスは別々。

チームで harness を「共有」したいなら、SDK 経由で社内バックエンド / 共用サーバー / CI ランナーに埋め込み、複数ユーザーから単一の harness インスタンスを叩く構造を自前で組むのが現実解。Google が hosted の「Managed harness」を提供しない以上、"team harness as a Service" は自社で実装する必要がある、というのが現時点の制約。

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 / 経費精算 / カレンダー / ドキュメントレビュー)
開発文脈 = Google Antigravity 2.0 (コーディング / Android / Firebase / GCP)
個人文脈 = Hermes 系 OSS (個人の暗黙考プール / Obsidian / カスタム gateway)

エディタ単体 (Claude Code / Codex CLI / Cursor) を選定の中心に置く時代は終わり。

✦ まとめ

Claude Code / Codex / Grok Build は専門ワーカー層、Antigravity 2.0 / Hermes / Copilot Studio / Workspace Studio は Agent OS 層。レイヤーが違うものを VS で並べる議論はもう成立しない。同じレイヤー内での比較と、別レイヤー間の組み合わせ設計に思考を移す必要がある。

評価軸は harness 設計 / 権限境界 / コンテキスト / 自動実行タイミング / レビュー の 5 つ。「モデルの賢さ」だけでは捉えきれない。

個人なら Hermes と Antigravity を併用、組織なら Copilot Studio / Workspace Studio / Antigravity を業務軸・開発軸・個人軸で使い分ける。エディタの中ではなく、Agent OS の設計でこそ生産性が決まる。

詳細とインタラクティブな図解は本家ブログでご覧ください:
https://okikusan-public.pages.dev/antigravity-agent-os

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up