はじめに
2025年11月18日、Googleは Gemini 3 Pro のリリースと同時に、
開発者向けAIエディタ Google Antigravity を発表しました。
Antigravityは、
「開発者がアーキテクトとして設計に集中し、AIエージェントが実装を担当する」
という開発スタイルを実現する エージェントファースト型AI開発プラットフォーム です。
特に注目すべき点は、
- マルチワークスペース や マルチエージェント 機能が使える
- Claude Codeの CLAUDE.md のような ワークフロー定義ファイル (.agent/workflows/) を備えている
これによって、複数タスクを同時並行で実行できることや、実装手順、設計思想をAIに明示的に伝え、段階的な開発プロセスを自動化することができます。
本記事では、この Antigravityのワークフロー機能 を活用し、実際に X（旧Twitter）のクローンアプリ を開発しながら、その開発体験と効果的な開発ポイントを分析していきます。
想定読者
以下に当てはまる方向けです。
- Cursor / Claude Code / codex / Copilot Agent 等を普段使っている
- Antigravity を触る前に「どんなことができるのか」を知りたい
Google Antigravity について
1. Antigravityの主な特徴
| 機能 | 内容 |
|---|---|
| エージェントファースト | AIがタスク分解から実装まで自律的に進行 |
| Editor + Manager 構成 | コード編集画面＋複数エージェントを管理するビュー |
| Artifacts | 実装履歴、スクショ、録画、タスクリストを自動生成・保存 |
| ブラウザ統合 | エージェントがブラウザを操作してUIチェックや修正を行う |
2. Agent Manager と Editor
| View | 役割 |
|---|---|
| Editor View | 従来のコード生成のためのチャット入力欄と修正指示中心 |
| Agent Manager Surface | 複数エージェントや複数ワークスペースを束ねて管理 進行状況や成果物を俯瞰できる |
-
Editor View
-
Agent Manager Surface
エディターの上部バーのボタンまたはキーボード ショートカットを使用して開くことができます（Cmd + E）
3. 利用できる複数のAgentモード
Antigravityのワークフローでは、エージェントの動作モードとして主に Planning と Fast の2種類が用意されています。
タスクの性質や目的に応じて使い分けることで、効率と品質を両立させることができます。
◼︎ Planning モード
エージェントが実行前に計画を立てるモードです。
要求の理解、構造化、調査が必要なタスクに適しています。
- タスクを複数のステップに分割して整理する
- 必要なアーティファクト（コード例、設計案、資料など）を生成する
- 前提条件の確認・検討を行う
- 最終的な品質を高めるための作業計画を自動で立てる
主に 複雑な開発タスク や チーム開発時の検討フェーズ で力を発揮します。
◼︎ Fast モード
計画を立てずに 即座にタスクを実行するモード です。
部分的な修正やローカルな処理に向いています。
- 変数名の変更や軽微なコード編集
- Bash コマンドの実行
- 小さく限定的な修正
- スピード重視の作業
品質よりも スピードと即時性 を優先したいケースで役立ちます。
使い分けのイメージ
| モード | 特徴 | 主な用途 | 例 |
|---|---|---|---|
| Planning | 事前計画・調査重視 | 複雑な開発課題 | 機能設計、ワークフロー設計、アプリ全体構造の提案 |
| Fast | 即時実行・局所変更 | 細かな改善や補助 | タイポ修正、変数名リネーム、依存の追加 |
4. 利用できるLLM
- Gemini 3 Pro (high)
- Gemini 3 Pro (low)
- Claude Sonnet 4.5
- Claude Sonnet 4.5 (thinking)
- GPT-OSS
レート制限は、主にキャパシティの許容範囲に基づいて決定されますが、
全体での制限ではなくモデル毎の制限となっている点はいいですね。
5. 全体設定
この辺りの設定はインストール時にも選択するが以下から設定変更可能です。
◼︎ アーティファクトレビューポリシー
- Always Proceed : エージェントはレビューを要求しません
- Agent Decides : エージェントがいつレビューを依頼するかを決定します
- Request Review : エージェントは常にレビューを依頼します
◼︎ ターミナルコマンドの自動実行
- Off : 端末コマンドを自動実行しない
- Auto : エージェントは、特定の端末コマンドを自動実行するかどうかを決定します
-
Turbo : 端末コマンドを常に自動実行します
※ 設定可能な拒否リストにあるコマンドを除く
6. Subagent（サブエージェント）
Antigravityでは、メインエージェントがすべての作業を直接行うわけではなく、
タスク内容によっては 専門特化した Subagent を起動 して処理を委任します。
特に、ブラウザ操作が必要なケースでは
Browser Subagent が呼び出され、実行を担当します。
Antigravity Browser Extension（Chrome 拡張機能）
このSubagentはメインエージェントとは異なるモデルを使用し、以下の操作ツールにアクセスできます。
- クリック、スクロール、タイピング などのブラウザ操作
- コンソールログの取得
- DOMのキャプチャ
- スクリーンショット撮影
- 動画録画
7. Antigravity ワークフロー
◼︎ ワークフローとは
Antigravityでは、開発タスクを再利用可能な形で指示としてまとめたものを
.agent/workflows/ 配下の Markdownファイル として管理する。
◼︎ ワークフローの実装と運用
Antigravityでは、開発フローに関する手順やコマンドをMarkdownで定義できます。
.agent/workflows/ に配置され、必要に応じてエージェントに呼び出して実行させることができます。
◼︎ ワークフローの保存場所
ワークフローは以下のディレクトリにまとめます：
.agent/
├── rules.md # 常に自動読み込みされるプロジェクトルール
└── workflows/
├── backend-docs.md # バックエンドドキュメント確認ワークフロー
├── frontend-docs.md # フロントエンドドキュメント確認ワークフロー
└── project-overview.md # プロジェクト全体概要ワークフロー
rulesは常に自動読み込みされるファイルであり、
workflowsは用途に応じて複数配置でき、/ コマンドで即座に呼び出せます。
ファイル名は、「一目で用途が分かる短い名前」が望ましいです。
◼︎ ワークフローファイルの構造
ファイルの中身は、基本的に 「目的」→「手順」 の二段構成で書きます。
# バックエンドドキュメント読み込みワークフロー
このワークフローは、Gin + Go バックエンドの主要なドキュメントとルールを確認するためのものです。
## 1. プロジェクト構成の確認
バックエンドのディレクトリ構造を確認します:
```bash
tree apps/backend -L 2
```
## 2. Go モジュールの確認
### go.mod の確認
依存関係を確認:
```bash
cat apps/backend/go.mod
```
## 3. エントリーポイントの確認
## 4. ディレクトリ構造の理解
...
Antigravityの仕様として、
GitHub FlavorのMarkdown(GFM) に準拠して書く必要があります。
コードブロックや箇条書きで 視覚的に流れが把握できる形 にしておくと、エージェントの理解精度も上がります。
Turboによる自動実行制御
ワークフローのステップは、必要に応じて 自動化指示アノテーション を付与できます。
| 指示 | 動き |
|---|---|
// turbo |
そのステップを自動実行 |
// turbo-all |
全ステップを強制自動実行 |
// turbo or // turbo-all
### 実装ステップ1
xxxxxxxxxxxxx
### 実装ステップ2
xxxxxxxxxxxxx
「Garageモード（高速プロトタイピング）」を活かす場合には特に便利ですが、
git操作や破壊的操作（DBミグレーション、デプロイ、削除系コマンド）では慎重に扱うべきです。
ワークフローを導入するメリット
| 観点 | 内容 |
|---|---|
| 再現性 | すべての作業手順が再利用可能な形で残る |
| 自動化 | Turbo指定で人手作業を削減 |
| 標準化 | チームで同じ作業フローを共有できる |
| 透明性 | エージェントの処理内容が追跡可能 |
アプリ開発実践
X（旧Twitter）クローンを題材に、
- 一括生成 vs 段階生成の差を可視化
- Antigravity を使った段階的開発手法の検証
- Clean Architecture × Monorepo と AI の相性確認
を目標にしています。
◼︎ 実装していく
1. とりあえず何もコンテキストを与えずに実装してみた
最初の指示：
Next.js + Ginで、Xクローンアプリを作成してください。
投稿、返信、ブックマーク、DM、認証、退会までの最小限機能でお願いします。
Monorepo で docker-compose で起動できるように。
◼︎ 実装
Antigravity は自動で以下のタスクを作成し、順次実行します：
- プロジェクト＆フォルダ作成
- Next.js 初期化、実装
- Gin 初期化、実装
- Docker-compose生成・DB準備
- テスト
◼︎ 結果
- ブラウザ起動
-
サインアップ画面
-
ログイン画面
-
タイムライン画面
-
リポスト画面
-
同じ投稿がブックマークされるなどの複数のバグ確認
一撃で、体感では 80% 程度の実装が完了しました。
Antigravity が自動生成した UI は、本家 X のレイアウトに近いデザインになりました。
もっと細かく指示しながら開発すれば、より完成度が上がると思います。
◼︎ 作成されたディレクトリとファイル
バックエンドは典型的なMVC構成で作成されるみたいでした。
.
├── apps
│ ├── backend
│ │ ├── Dockerfile
│ │ ├── controllers
│ │ │ ├── auth.go
│ │ │ ├── bookmark.go
│ │ │ ├── dm.go
│ │ │ ├── reply.go
│ │ │ ├── tweet.go
│ │ │ └── user.go
│ │ ├── db
│ │ │ └── db.go
│ │ ├── go.mod
│ │ ├── main.go
│ │ ├── middleware
│ │ │ ├── cors.go
│ │ │ └── jwt.go
│ │ ├── models
│ │ │ ├── bookmark.go
│ │ │ ├── dm.go
│ │ │ ├── reply.go
│ │ │ ├── tweet.go
│ │ │ └── user.go
│ │ ├── routes
│ │ │ ├── auth.go
│ │ │ ├── bookmark.go
│ │ │ ├── dm.go
│ │ │ ├── reply.go
│ │ │ ├── tweet.go
│ │ │ └── user.go
│ │ └── utils
│ │ └── token.go
│ │
│ └── frontend
│ ├── Dockerfile
│ ├── README.md
│ ├── public/
│ ├── app
│ │ ├── (auth)
│ │ │ ├── login
│ │ │ │ └── page.tsx
│ │ │ └── signup
│ │ │ └── page.tsx
│ │ └── (main)
│ │ ├── layout.tsx
│ │ ├── page.tsx
│ │ ├── messages
│ │ │ └── page.tsx
│ │ ├── bookmarks
│ │ │ └── page.tsx
│ │ ├── profile
│ │ │ └── page.tsx
│ │ └── tweet
│ │ └── [id]
│ │ └── page.tsx
│ ├── components
│ │ ├── CreateReply.tsx
│ │ ├── CreateTweet.tsx
│ │ └── Tweet.tsx
│ ├── lib
│ │ └── api.ts
│ ├── eslint.config.mjs
│ ├── next-env.d.ts
│ ├── next.config.ts
│ ├── package-lock.json
│ ├── package.json
│ ├── postcss.config.mjs
│ └── tsconfig.json
├── docker-compose.yml
└── README.md
2. 次はワークフローを導入して、コンテキスト読み込ませて実装してみる
◼︎ 技術スタック
| レイヤ | 技術 |
|---|---|
| Frontend | Next.js 16 |
| Backend | Go (Gin) |
| ORM | GORM |
| DB | PostgreSQL 15 |
| Auth | JWT (JSON Web Tokens) |
| Infra | Docker / Docker Compose |
| Repo | Monorepo構成 |
| AI IDE | Google Antigravity |
| LLM | Gemini 3 Pro |
◼︎ ディレクトリ構成
.
├── apps/
│ ├── web/ # Next.js
│ └── api/ # Gin
◼︎ アーキテクチャ構成
Go 側の内部構成（Clean Architecture）
./api/
├── cmd/
│ └── api/
│ └── main.go # DI + router + server
│
├── go.mod
├── go.sum
│
└── internal/
├── domains/ # Entity & domain behavior
│ ├── models/
│ │ ├── post.go # Tweet entity
│ │ ├── user.go
│ │ ├── like.go
│ │ └── follow.go
│ └── seeds/
│ └── init.go
│
├── infrastructures/ # Technology implementation
│ ├── databases/
│ │ ├── database.go # GORM init
│ │ └── migrate.go # AutoMigrate or Goose
│ └── repositories/
│ ├── post_repository.go # GORM implementation
│ ├── user_repository.go
│ └── follow_repository.go
│
├── presentation/ # I/O (HTTP, handler, DTO)
│ ├── handlers/
│ │ ├── posts_handler.go
│ │ ├── users_handler.go
│ │ └── auth_handler.go
│ ├── requests/
│ │ ├── posts_request.go
│ │ └── users_request.go
│ └── responses/
│ ├── posts_response.go
│ └── users_response.go
│
├── repositories/ # Domain repository interfaces
│ ├── post_repository.go # Interface only
│ ├── user_repository.go
│ └── follow_repository.go
│
├── routes/
│ └── routes.go
│
└── usecases/ # Application core
├── post_usecase.go
├── user_usecase.go
└── follow_usecase.go
◼︎ コンテキストの用意：インストラクションファイルなどのドキュメントを作成する
.agent
├── rules.md # 常に自動読み込みされるプロジェクトルール
└── workflows
├── implementation-backend.md # バックエンド実装ワークフロー
├── implementation-frontend.md # フロントエンド実装ワークフロー
├── backend-architecture-layers.md # バックエンド Clean Architecture 各層の詳細
├── backend-architecture-overview.md # バックエンドアーキテクチャ概要とディレクトリ構成
├── backend-coding.md # バックエンドコーディング規約
├── frontend-architecture.md # フロントエンドアーキテクチャ概要
├── frontend-coding.md # フロントエンドコーディング規約
├── code-review.md # コードレビューチェックリスト
├── testing-backend-integration.md # バックエンド統合テスト戦略
├── testing-backend-unit.md # バックエンド単体テスト戦略
└── testing-frontend.md # フロントエンドテスト戦略
◼︎ 段階的な開発ルールを明示する
- PBI単位で実装を依頼する
1. サインアップができる
→ メールアドレスとパスワードでユーザー登録できること
→ 画面とAPIの両方でバリデーションを実装すること
→ パスワードは8文字以上、半角英数字＋記号
→ パスワードはハッシュ化して保存
2. ログインができる
→ ...
3. タイムラインが表示できる
4. ポストができ、タイムラインに表示される
5. ポストに対して、返信ができる
6. ポストをリポストができる
7. いいねができる
8. ブックマークができる
9. プロフィールを表示できる
10. 退会できる
◼︎ 実装
・プロンプト入力
・実行するとタスク化して、順番に実装してくれる
・機能ごとに実装をお願いする
・Taskファイルに依頼したことのタスクが追加されていく
◼︎ 結果
・本家と限りなく類似した画面を作成してくれた
・ツイート、リプライ、リポスト、いいね、ブックマーク機能も実装してくれた
◼︎ 一括生成 vs 段階的開発の結果比較
| 観点 | 一括生成 | 段階的実装 |
|---|---|---|
| スピード | 速い。まとめて実装してくれる | 遅め。段階的に進めるため時間がかかる |
| バグ | コンテキストが少ないため挙動がシンプルで、初期は安定しやすいこともある | 機能追加で依存関係が増えるため、相互作用でバグが出ることがある |
| アーキテクチャ | MVCでそのまま実装されがち。共通化なし | 設計通りのアーキテクチャで実装される |
| コード品質 | 一見動くが、保守性が低く実務には向きにくい | 保守しやすい・拡張しやすいコードになる |
| 手戻り | 生成後にまとめて大量に発生しがち | 実装しながら都度レビューできるので少ない |
| メリット | 開発が一気に終わる／スピード重視 | 設計意図が反映され、長期運用向き |
| デメリット | 後から直すと破壊的修正になりがち | 時間がかかる／追加機能でバグが出やすい |
まとめ： Antigravity + Gemini 3 Pro を使ってみての所感
- Antigravity + Gemini 3 Pro の組み合わせは、現時点でも十分実用的
- 特に Task や Artifacts の自動保存による 開発プロセスの可視化 が秀逸
- ただし、まだ 無料パブリックプレビューで、正式なサブスク形態ではない
- LLMはキャパシティ制限制で、レートは5時間ごとにリセット （すぐ上限くる）
- 正式版リリース時には、課金プラン・機能拡張・精度向上が期待できる
ひとことで言うと、
「あ、これはAI IDEがより進化して使いやすくなったな〜」
という感触でした。
今回作成したコード