AI パートナーとの日常開発ワークフロー — Antigravity で変わる「書く・考える・検証する」サイクル

取り組みの背景 — AI ツールを「使う」から「協働する」へ

Antigravity を手に入れたとき、多くの開発者は最初「賢い自動補完ツール」として使い始めます。しかし数週間後、本当の価値に気づきます。それは「コードを書く前に思考を整理してくれる存在」としての役割です。

フェーズ1：計画（Plan）— コードを書く前の 15 分

タスクを Antigravity に「説明する」ことから始める

実装を開始する前に、まず Agent パネルに今日取り組むタスクを自然言語で説明しましょう。これは自分の思考を整理するためと、Antigravity がプロジェクトコンテキストを把握するための双方に効果があります。

// Agent パネルへの入力例
今日のタスク：ユーザープロフィール画面に「フォロー中のユーザー」一覧を追加する。
現在の実装：UserProfile.tsx がある。フォロー機能の API エンドポイントは /api/users/:id/following で、
フォロワー数・フォロー中数は既に useSocialStats フックで取得済み。
課題：無限スクロールと、自分自身がフォローしているかどうかの状態管理が未実装。

この入力に対して Antigravity は実装ステップのアウトラインを提示してくれます。完璧なプランでなくても構いません。「認識のずれ」をコーディング開始前に発見することが目的です。

チェックリスト：計画フェーズで確認すること

実装前に次の問いを Antigravity と一緒に確認する習慣を持つと、手戻りが大幅に減ります。

まずデータの流れとして、新しいコンポーネントはどこからデータを受け取るかを確認します。次に副作用として、この変更で既存の他機能に影響が出る箇所はないかを確認します。エラーケースとして、API が失敗したとき・データが空のときの UI はどうなるかも確認が必要です。最後にテストとして、どの単位でテストを書くかを決めておきます。

フェーズ2：実装（Implement）— AI と「対話しながら」書く

インラインコマンドを使ったイテレーティブ実装

実装フェーズで最も効果的なのは、Cmd+K（Mac）/ Ctrl+K（Windows）のインラインコマンドを活用した「小さく試す・すぐ直す」サイクルです。

// Step 1: まず骨格だけ書いて Antigravity に肉付けさせる
// Cmd+K → "この関数の本体を実装して。useInfiniteQuery を使うこと"
 
export function useFollowingList(userId: string) {
  // ← カーソルをここに置いて Cmd+K
}

Antigravity が生成したコードを見たとき、「なぜこの設計にしたか」を問い返す習慣を持ちましょう。

// Agent パネルへ: 「なぜ cursor ベースのページネーションを選んだ？offset ベースとの違いは？」
 
// 生成されたコード例（説明付き）
export function useFollowingList(userId: string) {
  return useInfiniteQuery({
    queryKey: ["following", userId],
    queryFn: async ({ pageParam }) => {
      // cursor ベース: フォロー中のリストが頻繁に変わっても
      // ページ境界がずれない。offset ベースだと追加・削除で
      // 同一ユーザーが2回表示されたり消えたりする問題がある。
      const res = await fetch(
        `/api/users/${userId}/following?cursor=${pageParam ?? ""}&limit=20`
      );
      if (!res.ok) throw new Error("Failed to fetch following list");
      return res.json() as Promise<{
        users: FollowingUser[];
        nextCursor: string | null;
      }>;
    },
    getNextPageParam: (lastPage) => lastPage.nextCursor,
    initialPageParam: "",
  });
}
 
// 期待する動作：
// - 初回: cursor なしで最初の20件取得
// - 追加ロード: 前ページの nextCursor を引き継いで続きを取得
// - nextCursor が null になったらページ終端

「詰まったとき」の引き出し

実装中に詰まったとき、多くの開発者は即 Google や Stack Overflow に向かいます。しかし Antigravity にまず聞くほうが効率的なケースが多いです。

// 詰まりパターン1: エラーの意味がわからない
"このエラーメッセージ『TypeError: Cannot read properties of undefined (reading 'map')』が
useFollowingList の戻り値を使っているときに出る。どの状況で発生するか、
最も可能性の高い原因と修正方法を教えて"

// 詰まりパターン2: 設計に迷っている
"フォロー状態（自分がフォローしているか）を管理するのに、
グローバルな Zustand store に入れるべきか、それともコンポーネントローカルの state で十分か。
このアプリの規模（MAU 5,000 程度の小規模 SNS）では？"

// 詰まりパターン3: パフォーマンスが心配
"FollowingList が 1,000 件以上になった場合のレンダリングパフォーマンスを改善するには？
今は全件を仮想スクロールなしで表示している"

フェーズ3：検証（Verify）— コードを「批評してもらう」

実装後レビューを Antigravity に依頼する

コードを書き終えたら、人間のコードレビューを受ける前に Antigravity による自動レビューを実施します。これは「恥ずかしいミスを事前に潰す」ためだけでなく、自分が気づいていない設計上の問題を発見するためです。

// Agent パネルへのレビュー依頼例
"今書いた FollowingList コンポーネントをレビューして。
特に以下の観点で：
1. メモリリーク・無限再レンダリングのリスク
2. エラーハンドリングの抜け
3. アクセシビリティ（スクリーンリーダー対応）
4. TypeScript の型安全性"

// Antigravity が指摘した問題例と修正
 
// ❌ 問題: Intersection Observer のクリーンアップなし
useEffect(() => {
  const observer = new IntersectionObserver(handleIntersect);
  if (loadMoreRef.current) observer.observe(loadMoreRef.current);
  // クリーンアップなし → メモリリーク
}, []);
 
// ✅ 修正: クリーンアップ関数を追加
useEffect(() => {
  const observer = new IntersectionObserver(handleIntersect);
  const element = loadMoreRef.current;
  if (element) observer.observe(element);
 
  return () => {
    if (element) observer.unobserve(element);
    observer.disconnect();
  };
}, [handleIntersect]); // handleIntersect を依存配列に追加

テストケースの洗い出し

Antigravity はテストケースの網羅性チェックが得意です。

// "この useFollowingList フックのテストケースを列挙して" への回答例
 
describe("useFollowingList", () => {
  // 正常系
  it("初回ロード時に最初の20件を返す");
  it("loadMore を呼ぶと次のページを追加取得する");
  it("nextCursor が null のとき hasNextPage が false になる");
 
  // 異常系
  it("API が 401 を返したとき error state になる");
  it("API が 500 を返したとき error state になる");
  it("ネットワークエラーが発生したとき error state になる");
 
  // エッジケース
  it("フォロー中が 0 件のとき空配列を返す");
  it("同一 userId で複数回マウントされても重複リクエストが発生しない");
  it("コンポーネントアンマウント後のレスポンスが state を更新しない");
});

3フェーズのサイクルを「習慣化」するコツ

朝のセッション開始儀式

毎朝 Antigravity を開いたとき、前日のコンテキストを復元する短いメッセージを送ります。

"今日は UserProfile の続きをやる。昨日は useFollowingList フックを実装した。
今日は FollowingList コンポーネントの UI を作って、フォロー/フォロー解除ボタンも追加する予定。"

これにより Antigravity がプロジェクトの状態を即座に把握し、提案の精度が上がります。

セッション終わりの「次への橋渡し」

作業終了前に 5 分かけて Antigravity に次のセッション用のコンテキストノートを作成させます。

"今日の作業内容と、明日引き継ぐべき未完成タスク・判断保留事項を
箇条書きでまとめて。AGENTS.md に追記できる形式で"

よくある失敗パターンと対策

パターン1：一度に大きな指示をしてしまう

大きなタスクを一気に依頼すると、Antigravity の出力品質が下がります。

// ❌ 悪い例（範囲が広すぎる）
"プロフィールページ全体をリファクタリングして、パフォーマンスを改善して、
テストも書いて、Storybook のストーリーも追加して"

// ✅ 良い例（スコープを絞る）
"UserProfile.tsx のレンダリング最適化だけやる。
具体的には useMemo と useCallback が不足している部分を特定して修正して"

パターン2：生成されたコードをそのまま使う

Antigravity の生成コードは「叩き台」です。必ず内容を理解してから採用する習慣を持ちましょう。特にセキュリティ・認証・決済に関わるコードは必ず自分でレビューを行います。

パターン3：Antigravity への「お礼」を忘れる

これは冗談半分ですが、会話の流れを自然に保つことで出力の一貫性が高まります。フィードバックを返し続けることで、Antigravity はより精度の高い提案を出し続けられます。

まとめ

AI パートナーとしての Antigravity を最大限に活用するには、「計画→実装→検証」の3フェーズそれぞれで意識的に協働する習慣が必要です。

計画フェーズでは実装前にタスクを言語化し、認識ずれを防ぎます。実装フェーズではインラインコマンドで小さく試し、なぜその実装なのかを問い返します。検証フェーズでは Antigravity にコードレビューを依頼し、テストケースを網羅します。

関連記事としてAntigravity ベストプラクティス集やカスタムエージェント作成ガイドも参考にしてください。