導入：Antigravityでのフルスタック開発体験
都内でソフトウェアエンジニアをしています。
最近、Googleの自律型AIエージェント「Google Antigravity」を用いて、『Zaim Lens』（※家計簿アプリZaimの非公式入力補助ツール）というSPA + FastAPI + Cloud Run構成のWebアプリを一人で開発し、公開しました。
SaaSアプリ
ソースコード（GitHub）
開発に利用したAI環境
- Google AI Proプラン（Geminiの利用のため。月額2,900円、年額29,000円）
これまでAIといえば、GitHub Copilotのような「人間が書くコードの賢い補完」というイメージが強かったと思います。しかし今回Antigravityを使って体感したのは、「AIが自律的に要件を解釈し、コードを書き、テストまで回す」という明確なパラダイムシフトでした。
ただ、「AIに丸投げすれば完璧なアプリが魔法のように出てくる」わけではない、ということも同時に体感しました。
とりあえず動くプロトタイプを作るだけなら丸投げでも驚くほどうまくいきます。しかし、そこから「自分が納得のいく完成品」へと引き上げるためには、 いまのところ人間のスキルも必要でした。
本記事では、次世代の「AI駆動開発」において、人間が本当に果たすべき役割について、等身大の実体験から得た気づきを共有します。
ペイン①：高精度モデルのレート制限と「精度のジレンマ」
個人開発を進める中で、最初にぶつかった壁が「AIモデルの制限」でした。
Antigravityでは高精度な「Gemini 3.1 Pro」を使えるのですが、自律的に何度もコードを書き換えてテストを繰り返すエージェントの特性上、使い続けるとすぐに週間レートリミット（API制限）に到達してしまいます。
一方で、制限が緩く高速な「Gemini 3 Flash」を使うと、コンテキストウィンドウ（文脈の保持力）と精度において、どうしてもProとの差を感じる場面がありました。
💡 解決策：GeminiアプリとAntigravityの二刀流（ピンポン・ワークフロー）
「Antigravityに直接雑投げすればいいのでは？」と思うかもしれません。確かに、適当な依頼でもAntigravityは立派な「実装計画」を出力してくれます。しかし、その計画書はA4用紙1枚分ほどのボリュームになり、1機能開発ごとに 人間が隅々まで読んでレビューするには重すぎる（認知負荷が高すぎる） という問題がありました。
そこで編み出したのが、普段使いの「Geminiアプリ（Proモード）」と「Antigravity（Flashまたは節約Pro）」を併用する、以下のワークフローです。
-
Geminiアプリで「超軽量レビュー」をする
まず、ブラウザのGeminiに「〇〇機能を作りたいので、Antigravityに投げるプロンプトを提案して」とざっくり投げます。出力されるのは数行の簡潔なプロンプトです。人間はこの 「数行のテキスト」だけをレビュー します。この時点で「あ、そのエラー処理の観点抜けてたわ」といった要件の漏れや解釈違いに一瞬で気づけるため、レビューが劇的に軽く済みます。 -
Antigravityに実装計画を作らせる
推敲した短いプロンプトをAntigravityに渡し、具体的な実装計画（A4サイズの詳細な手順）を出力させます。 -
実装計画を、さらにGemini（Pro）にレビューさせる
出力された重厚な実装計画を人間が気合で読むのではなく、そのままGeminiアプリ（Proモード）に投げ返します。Proモデルの恩恵で、かなり高精度な技術的指摘やエッジケースの発見をしてくれます。
この 「要件定義（設計）はGeminiアプリ、実装はAntigravity、その計画のレビューも再びGeminiアプリ」 というAI同士のピンポンとPM的な分業によって、レートリミットを回避しつつ、手戻りが劇的に減り、何より「人間の脳のメモリ消費」を大きく節約することに成功しました。
ペイン②：1000行の壁と「設計原則」の喪失
開発当初、私はAIが生成するコードに対して少し疑いの目を持ちつつも、こう考えていました。
「このコード、人間（私）が読んでレビューするには可読性が低くて厳しいな……。でも、実装者本人である『AI』が問題なく扱えるのなら、DRY原則や単一責任原則といった人間向けの綺麗な設計は、無理に求めなくてもいいか」
人間向けのベストプラクティスを無視して1つのファイルに処理が肥大化していっても、AIならコンテキストを失わずにバグらず動かし続けられるのではないか、と半信半疑ながら任せていたのです。
しかし、開発規模が1つのファイルで1000行を超えたあたりから、異変が起き始めました。
AIが「既存の関数定義行だけを勝手に消す（関数の中身の実体はそのまま残っている）」など、人間では絶対に起き得ないような猟奇的なバグを頻発させるようになったのです。
💡 気づき：AIにこそ「人間向けの設計原則」が必要
理由はシンプルで、コンテキストウィンドウの限界による 「AIの認知負荷のパンク」 でしょう。
AIが迷わずコードを修正できるようにするためには、人間以上に「ファイルの分割」や「DRY原則の徹底」を明示的に指示し、 AIの認知負荷を下げてあげる（見通しを良くしてあげる） 必要がありました。
謎の成功体験：なぜ「大規模リファクタリング」は得意なのか
1000行の壁で新規実装のバグに苦しむ一方で、不思議な体験もしました。
「肥大化したファイルを5つに分割して」といった構造変更や、「インフラ環境を丸ごと別のものに入れ替えて」といった大規模なリファクタリングは、驚くほどバグなしでスムーズに完遂してくれたのです。
💡 考察
これは、AIの「パターン認識」という特性によるものだと推測しています。
ゼロから新規でロジックを考えさせるよりも、「すでに動いている既存実装」という強固なリファレンス（正解）を見ながら構造を変える作業のほうが、AIにとっては圧倒的に得意（必要なコンテキストが揃っている）なのだと思います。
結論：AI時代の真の人間力は「PMのツッコミ」
一般的に、AI時代には「AIに対するプロンプト（仕様）を正確に言語化する力が重要になる」と言われています。しかし、今回のフルスタック開発を通して、私の実感は少し違いました。
仕様の言語化や構造化すら、前述の通りGeminiアプリがやってくれる時代です。
人間の真の提供価値は、緻密な言語化スキルではなく、「抽象的な『あるべき姿（ビジョン）』を思い描き、そこからブレていないかを監視すること」 にあります。
人間が100点の正解コードを知っている必要はありません。
- 「ここってこれでいいんだっけ？」
- 「後々、こっちの機能を追加するときに困らない？」
といった、些細だが重要な「ツッコミ（問い）」をAIに投げること。
これが、動くプロトタイプを「自分が納得のいく完成品」へと引き上げる最大の鍵でした。
このトリガーさえ人間が引けば、AIは勝手に思考し、「おっしゃる通りです。その場合は〜」と軌道修正してくれます。逆に、人間がこの「違和感へのツッコミ」をサボると、バグや仕様漏れがそのままシステムに定着してしまいます。
総括：開発は「プログラミング」から「マネジメント」へ
AIエージェントを使った開発は、もはやコーディングというより 「優秀だがたまにポカをする外注ベンダーへの発注・レビュー業務」 に感じました。
プログラミング言語の細かな文法を追う時間よりも、システムの抽象概念を維持し、違和感に気づく「PM（プロジェクトマネージャー）的な視点」が、想像以上に強力な武器になるパラダイムだと感じました。
「設計をゼロから完璧に言語化するのは難しそう…」とAI開発を躊躇している方がいたら、まずはAIにたたき台を作らせてみてください。ゼロイチの言語化はAIの力を借りつつ、人間は「PMとしてのツッコミ」で舵取りをする。
そんな気負わないスタンスで、ぜひAIエージェントとの個人開発への一歩を踏み出してみてはいかがでしょうか。
参考リンク
- 今回開発したアプリ：Zaim Lens（※非公式ツール）
- ソースコード（MITライセンス）: GitHub
- 『Zaim Lens』の機能紹介 : note