Antigravity開発でAIエージェントが暴走する?初心者が陥る失敗パターンとAGENTS.md作成の極意

Googleが発表した「Antigravity」。AIエージェントが自律的に開発を進める次世代IDEとして注目されていますが、実際に使い始めてみると、すぐに壁にぶつかる開発者も少なくありません。

思った通りのコードが返ってこない、最初は良かったのに開発が進むにつれてエージェントが過去の指示を忘れてバグを量産し始めた。そして何より、試行錯誤しているうちに利用制限(Rate Limit)に達してしまい、開発が強制ストップしてしまう。

このような経験はないでしょうか。

Antigravityのエージェントは非常に強力ですが、彼らは文脈を与えずに仕事を丸投げすれば、見当違いな成果物を上げてくる新入社員のようなものです。

そこで重要になるのが、プロジェクト内に配置する仕様書「AGENTS.md」です。

この記事では、Antigravityでの開発において初心者が陥りがちなダメなパターンと、開発ストップのリスクを回避するための、AIに質問攻めにしてもらう仕様書作成フローを解説します。

なぜ失敗するのか? Antigravity開発で陥るダメなパターン4選

AGENTS.mdの書き方に入る前に、なぜエージェントとの共創がうまくいかないのか。典型的な失敗例と、その代償を見ていきます。

パターン1:指示が抽象的すぎる(テレパシー期待型)

「いい感じにコードを修正して」「可読性を高くして」といった指示です。 エージェントにとってのいい感じと、人間のいい感じは違います。基準がなければエージェントは確率論で勝手に判断し、開発者の意図とは真逆のコードを生成します。それを修正するためにまた指示を出す、という泥沼にハマります。

パターン2:毎回同じことをチャットで指示している(伝書鳩型)

新しいファイルを作るたびに「TypeScriptで」「Tailwindを使って」といちいち入力している状態です。 チャットの履歴が流れると、エージェントは前の指示を忘れます。結果、あるファイルではconstを使い、別のファイルではvarを使うといったスタイル不統一が発生します。

パターン3:プロジェクトの前提を伝えていない(迷子型)

使用しているライブラリのバージョンや、フォルダ構成のルールを伝えていないケースです。 Antigravityのエージェントであっても、今このプロジェクトがどのバージョンで動いているかを知らなければ、古い書き方を提案してしまいます。動かないコードが出力され、デバッグに時間を浪費します。

パターン4:試行錯誤で利用制限を食いつぶす(ガス欠型)

これがAntigravity開発において最も深刻な問題です。指示が曖昧なため、「なんか違う、修正して、エラー出た、また修正」というラリーを繰り返してしまうパターンです。

高度なAIモデルには、一定期間あたりの利用回数制限(Rate Limit)やトークン制限が存在します。仕様書なしでダラダラと修正を繰り返していると、あっという間に制限に達します。

開発がノッてきたところで「利用制限に達しました」といった通知が表示され、作業が強制終了してしまう。エージェントに任せるはずが、逆にエージェントの都合で人間が待たされることになります。これは開発効率を著しく下げる最大の落とし穴です。

解決策:AGENTS.mdで一発回答させる

これらの問題、特に回数制限の浪費を防ぐ手段が、プロジェクトのルートディレクトリに仕様書ファイル「AGENTS.md」を置くことです。

このファイルにプロジェクトの法律を書いておけば、Antigravityのエージェントはコードを書く前に必ずこれを読み込みます。最初から正解に近いコードを出力してくれるため、やり取りの回数が激減し、貴重な利用枠を節約でき、開発が止まることもありません。

しかし、ここで最大の壁があります。そもそも、仕様書に何を書けばいいかわからないという問題です。

そこで有効なのが、インタビュー作成法です。

実践編:「以上」と言うまで聞き続けろ! 最強の仕様書作成フロー

自分で一生懸命ルールを考える必要はありません。エージェント自身にインタビューさせて、書かせればいいのです。

Antigravityのチャット欄で「仕様書を作って」と頼むのではなく、「仕様書を作るための材料を引き出して」と頼むのがポイントです。以下のステップで進めてみてください。

ステップ1:チャット欄にインタビュー開始プロンプトを投げる

Antigravityのチャット欄に、以下のプロンプトをそのまま貼り付けてください。

【プロンプト】 私は現在、Antigravity環境での開発用に、エージェントが参照するための仕様書(AGENTS.md)を作成したいです。

あなたは優秀なテックリードです。 このプロジェクトに最適な「技術スタック」「コーディング規約」「ディレクトリ構成」「禁止事項」などを定義するために、ユーザーである私に対して必要な情報をヒアリングしてください。

【重要なお願い】

  • 一度にまとめて質問せず、一つずつ質問してください。
  • 回答を受け取ったら、その内容を踏まえて次の質問をしてください。
  • 技術的なことがわからず「おまかせ」と回答があった場合は、一般的なベストプラクティスを採用してください。
  • 必要な情報がすべて揃うまで質問を続け、最後に『以上』と宣言されるまで絶対に仕様書の出力を開始しないでください。

それでは、最初の質問をお願いします。

ステップ2:エージェントからの質問にひたすら答える

プロンプトを投げると、エージェントは「了解しました。ではまず、このプロジェクトで実現したいアプリケーションの概要と、主な目的を教えてください」といった質問をしてきます。

これに対して、自分の言葉で答えていきます。「個人で使うタスク管理アプリを作りたい。シンプルにしたい」などです。

するとエージェントはさらに深掘りしてきます。「使用する技術スタックについてです。フロントエンドのフレームワークはどうしますか?」

このように、エージェント自身がAGENTS.mdに書くべき項目を熟知しているため、ガイドに従って答えていくだけで済みます。もし分からないことがあれば「初心者だからおすすめにして」と言えば、Antigravity推奨の構成を提案してくれます。

ステップ3:「以上」と宣言してファイルを出力させる

一通りのヒアリングが終わった、あるいはもう伝えることがなくなったと思ったら、魔法の言葉を唱えます。

「以上」

するとエージェントは、これまでの対話内容をきれいに整理・構造化して、Markdown形式の仕様書を出力してくれます。

完成したAGENTS.md(例)と配置方法

インタビューの結果、以下のような内容が出来上がるはずです。これをコピーして、プロジェクトのルートディレクトリに「AGENTS.md」という名前で保存してください。

ここまでが難しいという場合もまずは、どんどん出力してそのうえで作ればいいのです!

まずは、どんどん出力をしてたくさんの情報を与えてください。
それが仕様書を作るうえでとても大切なことです。
ここに時間をかけないとその後、時間がとてもかかってしまいます。

Project Rules & Guidelines

1. プロジェクト概要

  • 個人用タスク管理アプリケーション
  • シンプルさとレスポンス速度を最優先する

2. 技術スタック

  • Framework: Next.js (App Router使用)
  • Language: TypeScript
  • Styling: Tailwind CSS

3. コーディング規約

  • 型定義: any型は原則禁止。必ず型定義を行う。
  • コンポーネント: 関数コンポーネントを使用し、export const形式で記述する。

4. 禁止事項

  • useEffectの過剰な使用は避ける。
  • サーバーコンポーネントで使える処理をクライアント側に書かない。
  • APIキーをハードコーディングしない。

この方法の最大のメリット:コストと時間の節約

このAGENTS.mdがあるだけで、エージェントは最初から「TypeScriptで、Tailwindを使って、Next.jsの流儀で」コードを書きます。

これまで3往復、4往復とかかっていた修正ラリーが「一発OK」になれば、エージェントのAPIコール回数は大幅に減ります。これで、開発の良いところで制限がかかって作業終了という悲劇を回避できるのです。

まとめ:エージェントは指示待ちではなく引き出し上手な相棒にする

Antigravityを使いこなすための仕様書作成において、もっとも大切なマインドセットは一人で悩んで書こうとしないことです。

初心者が陥る「何を書けばいいかわからない」という悩みは、AI自身に解消させましょう。「以上」と言うまでひたすら聞き続けてもらう。この逆インタビューの手法を使えば、今日からAntigravityのエージェントは、阿吽の呼吸で動く頼もしいパートナーに変わります

コメントを残す