ASADASHI
複数の紙製AIエージェントが自動でコードを書きテストを完走するミニチュアジオラマ
バイブコーディング2026.05.22·読了 2·難易度: ふつう

AIがコードを書いてテストまで自動で完走する

複数の紙製AIエージェントが自動でコードを書きテストを完走するミニチュアジオラマ

朝の出汁版(通勤2分)

  • ポイント1: 「Antigravity 2.0」と「Gemini 2.5 Flash」を組み合わせることで、コマンド一つでプロトタイプの生成からブラウザテスト・検証動画の出力まで自動で実行できるようになった。
  • ポイント2: 複数のAIエージェントが役割分担しながら動く「マルチエージェント」構成により、指示を出す側は仕様だけ伝えれば、実装・確認・記録のサイクルをAIが回してくれる構造になっている。
  • ポイント3: 発表内容を参考に、まずは「/goal」コマンドで目標を渡すところから試してみると、自分のプロジェクトにどこまで使えるかイメージしやすい。

出汁の素(深読みモード)

これって結局どういうこと?

「AIがコードを書く」はもう珍しくない。注目したいのは、その先——「書いたコードを自分でテストして、結果を動画で記録するところまでAIが完走する」という段階に来たということ。

今回の発表(@shota7180のポスト)では、「Antigravity 2.0」と「Gemini 2.5 Flash」を組み合わせ、/goal でゴールを渡すだけで、プロトタイプの生成→ブラウザ上での動作確認→検証録画の出力までを自動で実行するデモが公開された。

要は「仕様を伝えたら、実装・確認・記録のサイクルをAIが自律的に回す」という構造。コードを書く手間より、動作確認や修正のやりとりに時間を取られていた人にとっては、これが変わる可能性がある。

なぜこのタイミングで重要?

AIコーディングツールの競争軸は、今年に入って「コードを生成できるか」から「どこまで自律的に動けるか」に急速に移っている。

これまでのツールは「人間がコードを確認して、テストして、修正指示を出す」サイクルを前提にしていた。Cursorのような補完系、v0のようなUI生成系も、最終的な確認と判断は人間が担う設計だった。

以前のASADASHIでも触れた「AIが調べる・直す・作るを全部やる」流れと同じ方向性で、今回はそこに「テスト・記録の自動化」が加わった形だ。

注目したいのは「マルチエージェント構成」という点。一つのAIが全部やるのではなく、役割を分担した複数のエージェントが連携して動く。/grill-me(要件の深掘り)、/goal(目標設定)、/browser(ブラウザ操作)という3つのコマンドが、それぞれ異なるエージェントの動作をトリガーする設計になっている。

この構造が意味するのは、「指示の粒度を細かくしなくてもAI側がタスクを分解する」という変化だ。AIへの指示コストが最大9割減という話とも重なるが、今回はさらに「確認工程ごと省く」方向に踏み込んでいる。

Gemini 2.5 Flashがバックエンドに使われている点も見逃せない。速度と推論バランスに優れたモデルであり、自動テストのような反復処理に向いている。プロトタイピングのサイクルを速く回したい人にとって、モデル選択の合理性が高い組み合わせといえる。

具体的に始めるなら

まず構造を把握する(コード不要)

発表内容を読む限り、Antigravity 2.0はコマンドベースのインターフェースを持つAIエージェントフレームワーク。まず公式の発表ポストに添付されているデモ動画を見て、どの操作がどのフェーズに対応しているかを確認するところから始めると全体像をつかみやすい。

コードが書けなくても「どういうゴールを渡せば何が生成されるか」を把握しておくだけで、自分のプロジェクトに使えるかどうかの判断材料になる。

/goal コマンドから入る

触り始めるなら、最もシンプルな入口は /goal コマンド。ゴールを自然言語で渡すと、エージェントがタスクに分解して動き始める設計になっている。最初に渡すゴールは「小さく・具体的に」するのが現実的。たとえば「問い合わせフォームが送信できるかブラウザで確認する」レベルの粒度から試すと、自動テストの動作イメージが掴みやすい。

Gemini 2.5 Flashを単体で感触確認する

Antigravity 2.0の環境構築前に、Gemini 2.5 Flash単体の推論速度・コード生成品質をGoogle AI Studio(無料枠あり)で確認しておくと、組み合わせたときの期待値を現実的に調整できる。特に「生成されたコードの精度」「英語指示と日本語指示での差」を比べてみると、本番利用の感触がつかめる。

自動テスト・録画の活用を考えるなら

ブラウザテストと検証録画の自動出力は、LPや申し込みフォームのチェックを繰り返している人に刺さる機能だ。手動でスクリーンショットを撮って「ここが崩れてる」と報告する作業を、AIが録画付きでやってくれる構造はQAの自動化として使い道がある。

まず「自分が毎週繰り返しているブラウザ確認作業」をリストアップして、その中で最もルーティン化されているものを最初のターゲットにするとフィットしやすい。

組み合わせで広がる発展案

生成されたプロトタイプをそのままNotion・Slackに投稿する自動化と組み合わせると、「作って→確認して→共有する」サイクルをほぼ人手なしで回せる構成になる。n8nやMake(旧Integromat)のようなワークフロー自動化ツールとの接続を視野に入れると、プロトタイプ生成の先まで繋げやすい。

よくある疑問

Q. コードが書けなくても使える?

コマンドを渡すインターフェースが中心のため、ゴール設定や指示出し自体はコード不要で操作できる設計になっている。ただし、生成されたコードを修正したり、エラーに対処したりする場面ではコードの読み書きができると明らかに有利。「コードなしでプロトタイプを確認するところまで」は試しやすいが、カスタマイズや本番投入には開発知識があったほうがスムーズ。

Q. Gemini 2.5 Flashは無料で使える?

Gemini 2.5 FlashはGoogle AI Studio経由で無料枠が提供されている。APIとしての利用はGoogleのAI Platformから取得でき、一定のリクエスト数までは無料で試せる。Antigravity 2.0との組み合わせで使う場合はAPIキーの設定が必要になるため、まずAI Studio単体で動作を確認してからAPI連携に進むのが現実的な順序。

Q. 日本語での指示・出力は使えるレベル?

Gemini 2.5 Flashの日本語対応は公式にサポートされており、コード生成・説明文の出力いずれも日本語で扱える。ただしAntigravity 2.0のコマンド体系(/goal 等)は英語ベースで設計されており、ゴールに渡す指示文を英語で書いたほうが精度が安定する傾向が発表内容からは読み取れる。日本語プロジェクトへの適用は可能だが、指示は英語で渡す運用を前提にしておくと安全。

もう一歩踏み込みたい人へ

マルチエージェント構成の技術的背景

Antigravity 2.0のマルチエージェント設計は、タスクを単一のLLMに投げるのではなく、役割ごとに分割したエージェントが協調して動く構造を取っている。/grill-me が要件を深掘りし、/goal がタスクに分解、/browser がブラウザ操作を担うという役割分担は、LangChainやLangGraphのようなエージェントオーケストレーション設計に近い考え方。

自動化ワークフローへの組み込み

生成されたプロトタイプや検証録画をそのままパイプラインに流したい場合、Antigravity 2.0のAPIエンドポイントやWebhookの有無を公式ドキュメントで確認するのが先決。出力をファイルとして受け取れるなら、n8nのFile Readノードやりか Make(Integromat)のHTTPモジュールで下流の自動化に繋ぎやすい。

Playwright / Puppeteerとの違い

ブラウザテスト自動化としてはPlaywrightやPuppeteerがすでに広く使われているが、それらはテストコードを自分で書く必要がある。今回の構成はゴールを渡すだけでブラウザ操作コードの生成・実行・録画までをAIが担う点が異なる。既存のPlaywrightテストスイートを持っている場合は、Antigravity 2.0で生成したコードをPlaywrightの形式に変換して統合するアプローチも検討できる。

関連リポジトリとして、.NETプロジェクト向けのAIコーディング支援スキル集 dotnet/skills も参考になる。AIエージェントにコーディングタスクを委譲する際の設計思想を読み取るのに使える構成になっている。

元になったツイート

  • アップデートされた「Antigravity 2.0」と「Gemini 3.5 Flash」を組み合わせて実際にプロトタイプを作りました。 /grill-me /goal /browser コマンドを扱いマルチエージェントで生成。 そして、ブラウザテストと検証録画の出力まで自動で実行してくれます↓ https://t.co/N6XKtfmFVY https://t.co/qCN5rCC0i8

参照ソース