Google「Antigravity 2.0」が開発者の反発を招いた理由

プラットフォームの中核には、エージェント実行や長時間のタスク処理、コーディング支援に最適化されたAIモデル Gemini 3.5 Flash が使われている。

Googleはこの方向性を、単なる「AIによる補助」から AIが実際に作業を実行する開発環境への進化 と位置づけている。

IDE中心から「エージェント管理ツール」への大転換

ここで大きな議論を呼んだのが、Antigravityの役割そのものが変わった点だった。

旧バージョンのAntigravityは、VS CodeやCursorのようなIDEにAI機能を追加したツールとして比較されることが多かった。

しかしAntigravity 2.0では、Googleは方向性を大きく変更。従来のIDEモードを廃止し、エージェントを管理するプラットフォームへと再設計した。

新しい環境では次のような操作が中心になる。

• 複数のAIエージェントを起動して協調させる
• サブエージェントに作業を委任する
• 長時間の非同期タスクを実行する
• エージェントが生成した成果物やプロジェクトを管理する

つまり、人間がコードを書く環境ではなく、AIエージェントを指揮するコントロールセンターという位置づけになった。

開発者の反発を招いた最大の理由

反発の原因は、AIエージェントという概念そのものではない。実際、多くの開発者はAIによるコーディング支援を歓迎している。

問題になったのは、既存ユーザーのワークフローが突然変わったことだった。

フォーラムでは、アップデートによって

• コードエディタ
• ファイルツリー
• ターミナル

といったIDEの基本機能が消え、チャット型の「Agent View」中心のUIになったという報告が相次いだ。

さらに、強制的または自動的にアップデートされた結果、

• 既存の開発環境が壊れた
• WSLなどのリモート開発環境が使えなくなった
• 依存していた機能が消えた

といった問題も報告されている。

日常的にエディタ・ターミナル・Git操作などを組み合わせて開発しているエンジニアにとって、これらが突然使えなくなるのは大きな問題だった。

「能力」ではなく「ワークフロー」の問題

今回の騒動で明らかになったのは、ソフトウェア開発が依然として手触りのある作業だということだ。

多くの開発者は日常的に次の作業を行っている。

• ファイルを直接編集する
• ターミナルコマンドを実行する
• Gitなどでバージョン管理をする
• インタラクティブにデバッグする
• コンテナやWSLなどのリモート環境で作業する

こうした基本操作をAIエージェントに委任するモデルは魅力的だが、完全に置き換えるにはまだ早いと感じる開発者も多い。

そのため一部ユーザーは、旧バージョンを再インストールしたり、VS Codeなど従来のIDEに戻る動きも見られた。

業界全体で起きている「2つの方向性」

Antigravity 2.0の議論は、実はAI開発ツール全体で起きている大きなテーマを象徴している。

現在、開発環境には大きく2つの方向性がある。

1. AI補助型IDE
従来のIDEにAIコパイロットを組み込み、コード生成やリファクタリング、テスト作成などを支援する。

2. エージェント主導型開発
開発者が目標を指示し、AIエージェントが実装作業を実行する。

GoogleはAntigravity 2.0で明確に後者へ舵を切った。デスクトップアプリ、CLI、SDK、APIを統合し、AIエージェントチームをオーケストレーションする開発基盤を作ろうとしている。

しかし現時点では、多くの開発者はまだ

「AIはアシスタントであり、主役はIDE」

というスタイルを好んでいる。

今回の騒動が示した教訓

Antigravity 2.0の問題は、単なる製品バグやUI変更ではない。

それは ソフトウェア開発の未来をどう設計するか という議論だった。

Googleは「AIが実際に開発作業を行う未来」を見据えている。一方で開発者コミュニティは、既存ワークフローを壊さず段階的にAIを取り入れたいと考えている。

このギャップが、今回の反発の根本にある。

今後、エージェント型開発が普及するかどうかは、従来のIDE的な操作を残したハイブリッドなアプローチをどれだけ実現できるかにかかっているかもしれない。