Google I/O 2026のブログを読んで、ちょっと手が止まった。
Googleが「Vibe Codingで作ったクイズ」を公式ブログで紹介していて、しかもそれを書いたのはコーディング経験ゼロの編集者だという。
AntigravityというコーディングエージェントをGoogle AI Studioに載せて、Geminiにプロンプトを生成させてアプリを作った、という流れらしい。
これ、普通に気になる。
最初「またノーコードツールの話か」と思ってスルーしかけた。
でも記事をちゃんと読むと、ちょっと違う。
Geminiを使って「AI Studioに渡すためのプロンプトを生成させる」という2段構えになっている。
つまり人間がプロンプトを直書きするんじゃなくて、LLMにプロンプトを書かせてからそれをエージェントに渡す、という構造だ。
これ、自分が個人開発でやってることに近い感覚がある。
最近、Claude APIを叩くスクリプトを書くとき、system promptの草案をまずChatGPTに書かせてから手直しする、という流れが定着してきた。
プロンプトをLLMに最適化させる、という発想自体は新しくないけど、それをエージェントへの入力として直接使う、というループは確かに「次のフェーズ」感がある。
Antigravityエージェントの詳細はまだ公開情報が少ないが、Google AI Studio上でGeminiモデルを使いながら動くアーキテクチャっぽい。
コンテキストにソース(アナウンスのドキュメントやデザイン参考)をアップロードして、そこからUIを生成させている。
要は RAG + エージェント + UI生成 を一本化したパイプラインだ。
チームのSlackで「Vibe Codingって結局非エンジニア向けでしょ」という発言を先月見かけた。
自分も半分そう思っていた。
でも今回の記事を読んで、その整理はちょっとズレてると感じている。
Vibe Codingが怖いのは、生成されたコードを誰もレビューしない状態で本番に乗ることだ。
エンジニアじゃない人が作ったものが、そのままデプロイされるケース。
でもエンジニアがVibe Codingを使う場合は話が変わる。
自分がやってみたいのは、こういう使い方だ。
スクラッチで書くのとどっちが速いか、というより「思考のスケッチツール」として使う感じ。
デザインツールでいうFigmaのFigJam的な位置付け。
とりあえず形にしてから詰める、あのテンポ感をコードでやる。
実際に先週、個人開発のボードゲームスコア管理アプリで試した。
フロントのコンポーネント設計をAI Studioで一回生成させて、出てきたReactのコードを見ながら「ここはuseReducerにしたい」「このpropsの渡し方は嫌だ」という判断を先に出せた。
ゼロから書き始めるより、何かに突っ込むほうが自分の好みが言語化しやすかった。
Google AI Studioは無料枠がある。
Gemini 2.5 Proは1日あたりのリクエスト制限があるが、PoC用途なら十分なレベルだ。
ClaudeのAPIと比べてどっちのほうがVibe Coding用途に向いてるか、まだ判断できていない。
Antigravityエージェントがどこまでコンテキストを食うのかも気になる。
UIの生成をループさせるとトークンを大量に使いそうで、個人の無料枠だとすぐ詰まりそうな予感がある。
そのあたりのコスト感は実際に使い込まないとわからない。
彼女に「また夜中に何かインストールしてるの」と言われながら、今夜 Google AI Studio のAntigravityを一回ちゃんと触ってみるつもりだ。
クイズアプリ程度のものを一本作って、生成されたコードの品質を自分の目で確認する。
そこで判断する。
Googleが「Vibe Codingで作ったクイズ」を公式ブログで紹介していて、しかもそれを書いたのはコーディング経験ゼロの編集者だという。
AntigravityというコーディングエージェントをGoogle AI Studioに載せて、Geminiにプロンプトを生成させてアプリを作った、という流れらしい。
これ、普通に気になる。
ノーコードの話じゃなくて、プロンプト設計の話だった
最初「またノーコードツールの話か」と思ってスルーしかけた。
でも記事をちゃんと読むと、ちょっと違う。
Geminiを使って「AI Studioに渡すためのプロンプトを生成させる」という2段構えになっている。
つまり人間がプロンプトを直書きするんじゃなくて、LLMにプロンプトを書かせてからそれをエージェントに渡す、という構造だ。
これ、自分が個人開発でやってることに近い感覚がある。
最近、Claude APIを叩くスクリプトを書くとき、system promptの草案をまずChatGPTに書かせてから手直しする、という流れが定着してきた。
プロンプトをLLMに最適化させる、という発想自体は新しくないけど、それをエージェントへの入力として直接使う、というループは確かに「次のフェーズ」感がある。
Antigravityエージェントの詳細はまだ公開情報が少ないが、Google AI Studio上でGeminiモデルを使いながら動くアーキテクチャっぽい。
コンテキストにソース(アナウンスのドキュメントやデザイン参考)をアップロードして、そこからUIを生成させている。
要は RAG + エージェント + UI生成 を一本化したパイプラインだ。
「コード書けない人が使うもの」という雑な整理をやめた
チームのSlackで「Vibe Codingって結局非エンジニア向けでしょ」という発言を先月見かけた。
自分も半分そう思っていた。
でも今回の記事を読んで、その整理はちょっとズレてると感じている。
Vibe Codingが怖いのは、生成されたコードを誰もレビューしない状態で本番に乗ることだ。
エンジニアじゃない人が作ったものが、そのままデプロイされるケース。
でもエンジニアがVibe Codingを使う場合は話が変わる。
自分がやってみたいのは、こういう使い方だ。
- PoC用のUIをAI Studioで5分で生成して、APIの動作確認に使う
- 生成されたコードをそのまま使わず、構造だけ参考にしてリライトする
- プロンプト → コード → レビュー → 修正 のループを短くする
スクラッチで書くのとどっちが速いか、というより「思考のスケッチツール」として使う感じ。
デザインツールでいうFigmaのFigJam的な位置付け。
とりあえず形にしてから詰める、あのテンポ感をコードでやる。
実際に先週、個人開発のボードゲームスコア管理アプリで試した。
フロントのコンポーネント設計をAI Studioで一回生成させて、出てきたReactのコードを見ながら「ここはuseReducerにしたい」「このpropsの渡し方は嫌だ」という判断を先に出せた。
ゼロから書き始めるより、何かに突っ込むほうが自分の好みが言語化しやすかった。
APIコスト的に個人開発で使い続けられるか
Google AI Studioは無料枠がある。
Gemini 2.5 Proは1日あたりのリクエスト制限があるが、PoC用途なら十分なレベルだ。
ClaudeのAPIと比べてどっちのほうがVibe Coding用途に向いてるか、まだ判断できていない。
Antigravityエージェントがどこまでコンテキストを食うのかも気になる。
UIの生成をループさせるとトークンを大量に使いそうで、個人の無料枠だとすぐ詰まりそうな予感がある。
そのあたりのコスト感は実際に使い込まないとわからない。
彼女に「また夜中に何かインストールしてるの」と言われながら、今夜 Google AI Studio のAntigravityを一回ちゃんと触ってみるつもりだ。
クイズアプリ程度のものを一本作って、生成されたコードの品質を自分の目で確認する。
そこで判断する。