はじめに
本記事は、Googleの自律型AIコーディングエージェント「Antigravity」を活用し、バイブコーディングによるWebアプリ開発を実践した記録と、その過程で得られた知見や所感についてまとめたものになります。
バイブコーディング (Vibe Coding) とは？
従来のプログラミングでは、人間が設計書を作成しそれに基づいてコーディングをするスタイルが主流となっています。近年では生成AIの発達が著しく、コーディングの部分をAI任せることも増えています。
これに対してバイブコーディングでは、人間がAIエージェントに「こんな機能を作って」「このエラーを直して」と自然言語で指示を出し、AIエージェントがコードを生成・編集・実行するのを「ただ雰囲気に身を任せて (Vibeで) 見守る」という新しい開発スタイルです。
開発者はコードの細部に責任を持たず、全体の設計やインフラ設定、意図の伝達に集中します。
2025年末に将棋棋士の藤井聡太さんが今年一番ハマったものに「バイブコーディング」を挙げており、非ITエンジニアの方でも知っている人は多いかもしれません。
Antigravityとは？
バイブコーディングという考え方を体現するツールの一つが、Googleが開発しているAntigravityです。
従来のAIコーディングツールは、開発者が主体となってコードを書き、AIは補完や修正を支援する役割を担っていました。一方、Antigravityは設計・実装・テストといった開発プロセス全体をAIエージェントが自律的に実行することを目指した「AIエージェント中心」の開発環境です。開発者は「こんな機能を追加したい」「この課題を解決したい」といった目的や要件を自然言語で伝え、AIエージェントはそれをもとに計画を立て、コードの生成や修正・テスト・動作確認までを担当します。
現在はCursorやClaude CodeなどのAI開発支援ツールが広く利用されていますが、Antigravityはその先にある「コードを書く」から「AIに開発を任せる」への変化を象徴する存在として注目されています。
今回の開発のきっかけ
近年、私の実務においても、コーディングをはじめとした様々な場面で生成AIを活用する機会が増えてきました。
そうした中でふと「比較的シンプルな設計や実装であれば、どこまでAIに任せられるのか？AIはプログラマーを代替するのか？」という疑問を抱くようになりました。
そこで今回は「自分は極力コードを書かない」というルールを設け、生成AIを主体とした開発でどこまで本格的なWebアプリを構築できるのかを検証してみることにしました。
開発の目標
今回のプロジェクトにあたり、以下の3つの目標を掲げました。
開発者は極力コードを書かない
Antigravityのポテンシャルを検証するため、実装は100%エージェントに自律的に行わせます。私はエージェントへの指示出し、成果物のレビュー、インフラ関連の設定、動作確認に徹しました。
未経験の技術領域における学習の助けとなるか？
今回はパブリッククラウドにGoogle Cloudを採用しています。私はこれまでパブリッククラウドはAWSしか利用したことがありませんでした。未経験の技術領域において、開発者のスキルアップを加速させることができるか検証しました。
成果物として、実アプリの公開およびQiitaで知見を共有する
単にローカル環境で開発を完結させるのではなく、CI/CDの構築から本番環境へのデプロイ、パブリック公開までを一貫して実施することを目指しました。また、その過程で得られた学びや課題を整理し、本記事としてアウトプットしています。
成果物
成果物
今回のプロジェクトの成果物として、宇宙関連データを集約した宇宙ポータルダッシュボード「CosmoPulse」を構築・公開しました。
- 機能
- 宇宙写真 (NASA APOD: Astronomy Picture of the Day) の表示
- 地球接近小惑星情報 (NeoWs) の可視化
- 宇宙開発/ロケットニュースの一覧表示
- 国際宇宙ステーション (ISS) のリアルタイム位置トラッキング (マップ表示)
また、下記のドキュメント類についてもエージェントに任せて自動構築しました。
- 開発ドキュメント: VitePress
- API仕様書: Swagger UI
- UIカタログ: Storybook
開発プロセス
アイデア出しおよび技術スタックの選定
アイデア出しはAntigravityではなくGeminiのチャットにて行いました。
- 公開APIを利用したアプリ案をいくつか提案してもらう
- その中から今回のテーマを採用し、Antigravityに依頼するための仕様書を作成してもらう
- 仕様書と利用したい技術スタックをAntigravityに渡して壁打ちする
私が経験のある技術スタックをベースとし、最終的に以下の技術スタックを採用することとなりました。
- バックエンド: Java 17 + Spring Boot 3.x + Gradle (Kotlin DSL)
- フロントエンド: React + TypeScript + Vite
- DB: Cloud Firestore (NoSQL)
- パブリッククラウド: Google Cloud
- アーキテクチャ: Firebase Hosting + Cloud Run + Secret Manager + Cloud Firestore
アーキテクチャ
ユーザーアクセスおよびデータフロー
インフラコストを最小限に抑えつつ、かつアクセス急増時にも耐えられるような設計を目指しました。
- 宇宙写真・小惑星情報・宇宙ニュース API
- 一日一回の更新とし、キャッシュをFirebaseとFirestoreの二段構えとする
- Firebase Hosting
- フロントエンドから取得されるキャッシュ
- Cloud Runの起動回数を抑え、コンテナの稼働時間 (課金) を削減する
- ユーザーに一番近いGoogleの配信サーバ (エッジサーバー) に保存され、そこから取得するため応答が速くなる
- Firestore
- バックエンドから取得されるキャッシュ
- キャッシュが保存されていないCDNエッジサーバーからアクセスされた場合や、Firebaseのキャッシュが揮発した場合のオリジンとして機能する
- Firebase Hosting
- 一日一回の更新とし、キャッシュをFirebaseとFirestoreの二段構えとする
- ISS API
- リアルタイム性が求められるため、フロントエンドから一定間隔で直接APIリクエストを実施する
CI/CD
GitHub の main ブランチへのプッシュを検知し、GitHub Actions がフロントエンド (Firebase Hosting) とバックエンド (Cloud Run) のビルド・コンテナデプロイを完全自動で実行します。
Google Cloud上での請求管理・自動シャットダウン設定
意図せず大量に課金されることを防止するために予算アラートを設定し、以下のような自動フローを構築しています。
- 事前準備
- 請求管理用のPub/Subトピックを作成
- 予算アラートを設定し、超過時の通知先に作成したトピックを設定
- プロジェクトの請求先アカウントの紐づけを解除するCloud Run関数を作成し、作成したトピックをサブスクライブ
超過時は以下のフローで動作します。
- 予算アラートからトピックに通知
- トピックにて予算超過メッセージを配信
- Cloud Run関数が起動し、プロジェクトの請求先アカウントの紐づけを解除
- 各種サービスがシャットダウン (無料アカウントの範疇に切り替わる)
復旧時は管理画面からプロジェクトに再度請求先アカウントを紐づけることでアプリが自動起動します。
まとめ
目標の振り返り
開発者は極力コードを書かない: ⭐⭐⭐⭐⭐
今回のプロジェクトにおいて私は直接コードを修正することはほとんどなく、ローカル開発時に外部APIのAPIキーを設定したくらいです。ただ、想定と違う内容で修正されることも多々あり、軽微な修正 (特定箇所の文言修正など) については人間が直接修正したほうが早いなと感じることがありました。
とはいえ、大筋の実装については100%エージェントに自律的に行わせることができたため、ポテンシャルとしては期待通りでした。
未経験の技術領域における学習の助けとなるか？: ⭐⭐⭐⭐
今回の開発を通じてGoogle Cloudの深める事ができました。
特に効果的だったのは、開発者のスキルセットや現在のプロジェクトに即した形で説明してもらうことができるという点です。習得対象の技術領域が全くの未経験であれば難しいかもしれませんが、ある程度の周辺知識を備えている場合は有効だと感じました。
成果物として、実アプリの公開およびQiitaで知見を共有する: ⭐⭐⭐⭐
アプリの公開については前項の通り実施することができました。
記事の執筆については ①私が骨子を作成 ②Antigravityが加筆・修正 ③私の方で修正 という流れで進めています。開発中はAIとのチャットが途切れ途切れになる事が多いですが、Antigravityがその内容をまとめて反映してくれるため、開発者が一から執筆するよりも効率的に記事を公開することができました。
得られた知見と所感
ラピッドプロトタイピングへの適性
アイデア出し、アーキテクチャ設計、実装、CI/CD構築、本番公開、さらには本記事の執筆までを含めて5～6人日で完了しました。
「動く仕様書」としてのアプリをこのスピードで形にし、要件定義や認識合わせを加速できる点は、AI駆動開発ならではの大きな強みだと感じました。
デザインの「AIらしさ」とデザイナーの価値
AI (今回の開発ではGeminiのモデルを利用しています) に画面デザインを一任すると、どうしてもAIっぽさを感じるものとなってしまいました。
私は専門外ではありますが、人間のデザイナーが持つクリエイティビティの価値と重要性を改めて実感しました。
開発のきっかけとなった「AIはプログラマーを代替するのか？」という疑問について
今回の開発を通じて、純粋なコーディング作業については今後AIによって大きく代替される可能性があると感じました。一方で、コードレビューやアーキテクチャ設計、インフラ運用、トラブルシューティングといった領域については、当面の間は人間のエンジニアが担う役割だと考えています。実際に開発中も、AIエージェントが誤ったコードを生成したり、ビルドエラーを解消できなかったりする場面がありました。
AIの生産性を最大限に活かすためには、基礎的な技術力に加え、システム全体を俯瞰した設計力や問題解決能力、そしてAIと効率的に協働するスキルがこれまで以上に重要になると感じています。プログラマーが不要になるというよりも、「実装者」から「AIを活用して開発を導く航海士」へと役割が変化していくのではないかと考えています。
感想
新しい開発スキームのポテンシャルを実感することができ、全体を通じてとても面白いプロジェクトとなりました。
この記事がみなさんのAIエージェントを利用した開発の一助となれば幸いです。