Google I/O 2026で発表されたAntigravity 2.0は、AIエージェントが約12時間でスケジューラやファイルシステムを含むOSを生成し、その上でDoomを動かしたデモを披露しました。これらはGoogleの主張ですが、エージェント中心の開発スタックが実用フェーズに入りつつある事実は、サーバーサイドエンジニアにとって無視できない地殻変動と言えます。本記事ではAntigravity 2.0の構成、デモの読み解き、Gemini 3.5 Flashの位置づけ、そして日本の現場が今から備えるべき論点を、検証済みファクトと出典明示の引用を区別しながら整理します。
Antigravity 2.0とは何かエージェントファーストへの再設計
Antigravity 2.0は、Google I/O 2026で日本時間2026年5月20日未明に発表されたリサーチプレビュー段階のプロダクトです。従来のIDE拡張的な位置づけから、エージェントによる自律的な開発実行を中心に据えたスタンドアロンのデスクトップアプリへと再構成されました。コードを書く道具というより、エージェントを駆動するための統合環境という色合いが濃くなっています。
提供形態は大きく3層に整理できます。1つ目はAntigravity CLIで、既存のGemini CLIから移行が推奨される新しいコマンドラインツールです。2つ目はAntigravity SDKで、エージェントへのプログラム的アクセスを提供し、自社インフラやサードパーティ環境にエージェントを展開できます。3つ目がManaged Agents in Gemini APIで、単一のAPI呼び出しで推論やツール使用、コード実行までを分離されたLinux環境で完結させる仕組みです。
連携先も広く、Android、Firebase、Google AI Studio、Workspaceといった既存スタックと結びついています。エンタープライズ用途ではGemini Enterprise Agent Platform経由での提供が想定されています。なおPublickey1の報道によれば、Geminiオーディオモデルによるネイティブな音声サポートも紹介されており、操作インタフェースが対話的な方向へ向かう兆しもうかがえます。
12時間でOSを生成したデモの数値を冷静に読み解く
本発表で大きな話題を呼んだのが、Antigravity 2.0自身に小さなオペレーティングシステムを生成させたデモです。Googleが壇上で示した主張値として、約12時間規模の実行時間、並列動作する93個のサブエージェント、1万5000件超のモデルリクエスト、約26億トークンの処理量、そして1000ドル未満のAPIコストという数字が提示されました。Publickey1は「12時間以上」と表現し、英語圏のDigit.inはnearly 12 hoursと書いており、表現には微妙な揺れが残ります。
生成範囲も注目に値します。スケジューラやメモリ管理、ファイルシステムまで含むコード一式が出力されたとされ、単なるテンプレートやスキャフォルディングを超えた水準であることをGoogleは強調しました。これを支えているのがDynamic subagentsと呼ばれる動的サブエージェント機能で、タスクをトップエージェントが分解し、並列に走るサブエージェントへ割り当てて最終的に結果を統合します。
ただし、ここで強調しておきたいのは、これらの数値はすべてGoogle自身がデモ環境で計測した値であり、第三者による独立検証は現時点で公表されていない点です。生成されたOSがどこまで実用品質に達しているのか、再現性や安全性、ライセンス面の取り扱いがどうなるのかは別問題として残ります。読者としては「Antigravity 2.0は12時間でOSを作れる」と短絡せず、「Googleの壇上デモではそうした数値が示された」と捉えるリテラシーが必要です。
Doom実行デモから読み取れる実用性と限界
同じデモでは、生成されたOS上で機関車を表示するslコマンドが実行されました。初回はビデオドライバとキーボードドライバが不足していたため失敗したものの、Antigravity 2.0にリアルタイムで修正を依頼することで両ドライバが補完され、その後はslに加えてDoomまでも動作したとされています。エージェントが不足要素を自分で特定し、コードを書き足し、動作する状態まで持っていく姿は、自己修復的な開発の一端を見せています。
もっとも、ここから読み取るべきは「すべてが完成形だった」ではなく、「動的な補完を前提とした開発ループが現実味を帯びた」ことです。デモ環境では失敗が許されるため、エラーを起点にしてエージェントが補修するフローがそのまま見せ場になります。一方で本番運用では、失敗の許容範囲、回帰テスト、セキュリティ境界、ライセンスの追跡といった検証と品質保証の観点が欠かせません。
エンジニア側のレビュー観点も変わります。生成された差分の妥当性、生成過程で参照したライブラリの来歴、サブエージェントが下した判断のトレーサビリティといった、これまで人間が暗黙のうちに担保していた論点を明示的にレビューする必要があります。エージェントが書いたコードを単にマージするのではなく、根拠と影響範囲を確認するためのチェック項目を設計することが、現場では先決になります。
Gemini 3.5 FlashとAntigravityハーネスの連携
Antigravity 2.0のデフォルトモデルはGemini 3.5 Flashです。Googleは他のフロンティアモデルと比較しておよそ4倍高速であると主張しており、また同社の説明ではGemini 3.1 Proに対してもほぼ全ベンチマークで上回るとされています。デモにおける12時間規模のロングランと1000ドル未満というコストは、この高速かつ低コストなモデルを前提に成立しています。
キーとなるのがAntigravityハーネスと呼ばれる実行基盤です。ハーネスとは、モデル単体ではなく、ツール呼び出し、ファイル操作、サブエージェントの起動、状態管理などを包み込む実行フレームワークを指します。Managed Agentsは分離されたLinux環境を一時的に立ち上げ、その中で推論、ツール使用、コード実行を完結させる構造になっており、エージェントの動作が外部環境から隔離される点はガバナンス上も重要な特徴です。
Googleは「Gemini 3.1 Proでは実現困難だった」と説明しています。これは単にモデル単体の精度の話ではなく、低レイテンシでサブエージェントを大量並列に動かしても破綻しないコスト効率と速度が、長時間タスクの完走に不可欠だったという文脈です。ただし、この発言はあくまでGoogle側の説明であり、3.1 Proで同じタスクを試した独立比較が公開されているわけではありません。読者としては「同社はそう説明している」という距離感で受け止めるのが適切でしょう。
開発体験はどう変わるのか数日から数時間へのシフト
Googleは発表のなかで「数日かかっていたエンジニアリング作業が、数時間、場合によっては数分に短縮される」と表現しました。これはあくまで同社の言い回しですが、サーバーサイド開発のフェーズ構成に与える影響は大きいと考えられます。設計、実装、テスト、運用準備という直列のステップを、ある程度の粒度ごとにサブエージェントへ委ねる発想が現実的な選択肢になり始めています。
これまで人間が逐次行っていたタスク分解が、エージェントによる動的な分解と並列実行に置き換わる可能性があります。タスクを細かなチケットに割って人間が割り振る代わりに、ゴールと制約条件、受け入れ基準を与え、サブエージェントが分担を決め並列に走り、最後に統合した差分が人間レビューに戻ってくる、という流れです。レビュー対象はコードだけではなく、エージェントの計画と判断の経路まで含まれるようになります。
既存パイプラインへ組み込む際の勘所は3点に集約できます。第一に、Antigravity CLIとSDKをCI/CDのどこに差し込むかという接続設計です。第二に、Managed Agentsが立ち上げる分離環境とプロダクション環境の境界をどう引くかというセキュリティ境界の設計です。第三に、APIコストとリクエスト件数のモニタリングであり、26億トークン規模のジョブが組織内で発生し得る前提でアラートと上限を設けることが現実的になります。管理者視点では、リソース消費の上振れと生産性向上のROIをセットで計測する仕組みが必要です。
日本のエンジニアと企業が今から備えるべきこと
リサーチプレビュー段階のプロダクトに早期に触れることには、機能を試す以上の意味があります。エージェント前提の開発体験を肌で確かめ、自分たちの評価軸を更新できることです。レスポンスの速さ、サブエージェントの分担粒度、エラー時のリカバリ挙動、ログの追いやすさといった観点は、触らずにベンチマーク表だけ眺めていても感覚が育ちません。社内の評価チームで小さな実験を回す価値は十分にあります。
コーディング規約とレビュー体制も再設計が必要です。エージェントが書いたコードと人間が書いたコードを区別するメタデータ、生成プロンプトや判断ログの保管方針、テスト戦略の改定、依存ライブラリのライセンス確認手順といった項目を、規約レベルで明文化することが現実的な備えになります。Gemini Enterprise Agent Platformを使う場合は、データの取り扱い境界、監査ログ、権限分離といったガバナンス論点も同時に検討すべきです。
AIコーディングツールの選定では、主張値と検証値を切り分けるリテラシーが決定的に重要になります。Cursor、GitHub Copilot、Claude Code、Antigravityなど、それぞれが得意領域と前提を持っており、ベンダーが公表する性能値はあくまで自社環境での測定です。自社の代表的タスクで横並びに試し、自分たちの基準で評価する文化を持つチームが、結果的に最も賢い選定にたどり着きます。
技術マネージャーの視点では、エージェントを使いこなす人材の育成と、組織設計の見直しが今後の論点になります。プロンプト設計、サブエージェント分割、レビュー観点の整備、コストガバナンスといった新しいスキルを誰がどこで身につけるかを早めに議論しておくことが、来期以降の競争力を左右します。Antigravity 2.0のデモ数値はGoogleの主張であるという前提を保ちつつ、エージェントファーストの選択肢が並んだ事実は受け止め、CLIやSDKに触れる時間を意識的に確保する姿勢が、いま日本の現場に求められる準備と言えるでしょう。
