はじめに
こんにちは。トライベック株式会社で「Hirameki7」のフロントエンド開発を担当している鈴木です。
今回は、2025年11月に Google が「次世代IDE」として発表した Antigravity の設計思想について掘り下げていきます。
Antigravity は、従来のエディターとは明らかに異なる設計で作られています。
実際に触ってみると、「なぜこうなっているのか？」と疑問に感じるポイントがいくつもあります。
特に VSCode や Cursor に慣れていると、
・なぜエージェントマネージャーとエディターが分かれているのか
・なぜ Agent モードが存在しないのか
といった点に違和感を覚えるはずです。
しかし開発者の言葉を見ていくと、
これらの違和感はすべて 「エージェントファースト」という設計思想 から説明できることがわかります。
この記事では、
- Antigravity の UI に感じる違和感
- 開発者の言葉から読み解く思想
- その思想がどのように機能に落とし込まれているか
という順で整理しながら、
AI時代のコーディングにおける課題と、それに対する Antigravity の解答
を見ていきます。
従来のコードエディターとの違い
なぜエージェントマネージャーとエディターで画面が分かれているのか？
VSCode では、まずエディターがあり、その中で AI も使いつつコードを書いていくという流れが当たり前でした。
一方 Antigravity では、コードを書くエディター画面の他に、AI にタスクを任せ、進行を管理する 専用の画面としてエージェントマネージャーが存在します。
Agentモードがない。Planningモードとは？
GitHub CopilotやCursorを使う場合、大抵はAgentモードを使うことが多いですが、Antigravity には Agent モードはありません。
代わりに存在するのが PlanningモードとFastモードです。
こうした違いを見ると、Antigravity はAIを用いた開発の進め方そのものを再設計しようとしているように見えてきます。
開発者の言葉から設計思想を紐解く
YouTube に開発者が Antigravity の説明をしている動画があるので見てみました。
この動画では、今回のタイトルでもあるバイブコーディングの限界やAIによる質の低い成果物、エンジニアの集中持続の問題などが述べられていました。
今回は特に印象的だった発言を抜粋して見ていきます。
「大規模なコードベースは、バイブコーディングできない」
理論上、「バイブコーディング」は素晴らしく聞こえるかもしれません。しかし現実には、既存の大規模なコードベースをすべて雰囲気だけで作り変えることなど不可能だと、私たちは知っています。
新規開発や小規模なプロジェクトにおいてはバイブコーディングは素晴らしいものですが、
実際に開発現場で取り扱う既存の大規模なコードベースでは
「既存コードの理解」
「現在の実装に至った経緯の理解」
「変更による影響範囲の特定」
といった作業が必要になるため、バイブコーディングではどうしても限界があります。
「AIが生成した『スロップ（質の低い成果物）』の多くは、タスクの指示不足によってエージェントが迷走した結果である」
エージェントは絶えず賢くなってはいるものの、完璧ではなく、明らかに私たちの心を読むことはできません。実際、AIが生成する多くの粗雑な結果は、タスクの仕様不足が原因でエージェントが迷路に陥ることに起因しています。
AIに任せた結果、思っていたものと違うコードが出てきて、結局自分で書き直す──
多くの人がそんな経験をしていると思います。
結果として、
「生成コードの修正コスト」が増え、
最初から自分で書いたほうが早いという状況に陥ることも少なくありません。
「コンテキストスイッチは、時間を失う最大の理由の一つ」
誰だって、目の前のタスクに没頭するために数時間を確保したいと願っています。しかし現実は、緊急のバグレポートや単発の分析依頼、あるいはフローを中断させる「ちょっとした別の用事」が次々と舞い込みます。 たとえ単純なタスクであっても、一度切れた集中力を繋ぎ直すコストは馬鹿になりません。誰もが経験していることでしょう。
バイブコーディングとはズレますが、
もう一つ問題として挙げられていることがコンテキストスイッチです。
エンジニアにとって、集中してコードを書く時間は生産性を高めるうえで非常に重要です。
しかし実際の現場では、突発的なバグ対応や仕様確認の相談などが入り集中が途切れてしまうことも少なくありません。
設計の意図が見えてくる
こういった開発者の発言を聞くと、初めは疑問に感じたAntigravity の UI や機能は「なるほど、だからこうなっているのか」と腑に落ちてきます。
まず1つ目の疑問の
なぜエージェントマネージャーとエディターで画面が分かれているのか？
ですが、これは前述したコンテキストスイッチを回避するためのものと読み取れます。
エージェントマネージャー画面では、複数のワークスペースでAIが並列してタスクを実行することができるため、
エディター画面で作業に集中したい場合は、エージェントマネージャー画面を開き、タスクを指示して、自分は元の作業に戻ることが可能になります。
そして Antigravity には、この２画面を簡単に切り替えるためのショートカットがあります。（Ctrl + E / Cmd + E）
このショートカットが準備されているあたりにも、エージェントマネージャーとエディター画面を頻繁に切り替えることを前提とした Antigravity の設計意図を感じられます。
つまり Antigravity は、
「人間は1つの作業に集中し、AIは並列で動かす」
という役割分担を前提に設計されていると考えられます。
2つめの
Agentモードがない。Planningモードとは？
ですが、
これは前述した
「大規模なコードベースは、バイブコーディングできない」
という考えがダイレクトに現れている部分です。
一般的な Agent モードは、タスクを指示するとそのまま実装まで進めることができます。
しかしこのアプローチは、タスクの粒度や前提が曖昧なまま進んでしまうと、
結果として「バイブコーディング」に近い状態になりやすい側面があります。
Antigravity は、この問題を解決するために
「実装の前に必ず計画を作る」 というステップを挟んでいます。
それが Planning モードです。
Planning モードで作られた実装計画には、
Googleドキュメントのように
「ここはこうしてほしい」
「この前提は違う」
といった指摘を、コードを書く前の段階で差し込むことができます。
このように事前に実装計画を固めることで、
・大規模なコードベースでも破綻しない実装が可能になる
・AIとの認識ズレを事前に解消できる
といった効果が生まれます。
結果として、開発者が問題として挙げていた
「指示不足によるAIスロップ（質の低い成果物）」も防ぐことができます。
また、プランを立てるほどのタスクではない場合はFastモードを使うことで、AgentモードのようなAIとのやり取りが可能です。
まとめ
Antigravity の独特なUIは、単なる新しさではなく、
・大規模なコードベースでもAIを活用する
・AIの迷走を防ぐために計画を重視する
・コンテキストスイッチを最小化する
といった課題に対する、明確な設計の結果でした。
最初は違和感のあるUIに見えますが、
開発者の発言と照らし合わせることで、
すべてが一貫した思想の上に成り立っていることがわかります。
Antigravity は単なる「AI付きエディター」ではなく、
AIと協働するための開発環境そのものを再定義したツール
と言えるのかもしれません。