数万行のコードベースを壊さずに作り変える — Antigravity Editor View で進める大規模リファクタリングの実務

マルチファイル同時変換 — Editor View の真価

Antigravity の Editor View が最も威力を発揮するのは、複数ファイルにまたがる変更を一括で処理する場面です。

パターンベースの一括リファクタリング

たとえば、プロジェクト全体で callback パターンを async/await に移行する場合を考えましょう。

// Before: Callback pattern
function fetchUser(id: string, callback: (err: Error | null, user?: User) => void) {
  db.query(`SELECT * FROM users WHERE id = ?`, [id], (err, rows) => {
    if (err) return callback(err);
    callback(null, rows[0] as User);
  });
}
 
// After: Async/Await pattern
async function fetchUser(id: string): Promise<User> {
  const rows = await db.query(`SELECT * FROM users WHERE id = ?`, [id]);
  return rows[0] as User;
}

Editor View で対象ファイル群を選択した状態で、以下のプロンプトを使います。

Convert all callback-based functions in the selected files
to async/await pattern. Preserve error handling semantics,
update all call sites, and add proper TypeScript return types.
Show me the diff before applying.

重要なのは 「Show me the diff before applying」 の一文です。これにより、Antigravity は Diff View で変更内容を提示し、あなたが承認してから適用します。数十ファイルの変更でも、差分を確認してから一括適用できるため安全です。この一文を省くと AI はすぐに書き換えに走るので、私は定型句として必ず添えるようにしています。

型の段階的厳格化

JavaScript から TypeScript への移行や、any 型の排除は大規模プロジェクトでよく発生するリファクタリングです。

// Step 1: AI が any を検出して型を推論
// Before
function processData(data: any): any {
  return data.items.map((item: any) => ({
    id: item.id,
    name: item.name.trim(),
    score: item.score * 100,
  }));
}
 
// After: AI による型推論の結果
interface DataItem {
  id: string;
  name: string;
  score: number;
}
 
interface ProcessedItem {
  id: string;
  name: string;
  score: number;
}
 
function processData(data: { items: DataItem[] }): ProcessedItem[] {
  return data.items.map((item) => ({
    id: item.id,
    name: item.name.trim(),
    score: item.score * 100,
  }));
}

この型推論は、Antigravity が呼び出し元のコードやテストコードを分析することで、高い精度で実行されます。

レガシーコードのマイグレーション戦略

レガシーコードの移行は、一度にすべてを書き換えるのではなく、段階的に進めるのがベストプラクティスです。Antigravity の Editor View はこのアプローチを強力にサポートします。

Strangler Fig パターンの実装

旧コードを新コードで段階的に置き換える Strangler Fig パターンを、AI の支援のもとで実装します。

// Phase 1: Adapter を作成（旧 API と新 API を橋渡し）
class LegacyPaymentAdapter implements PaymentGateway {
  private legacy: LegacyPaymentService;
  private modern: ModernPaymentService;
  private useModern: boolean;
 
  constructor(config: { enableModernPayment: boolean }) {
    this.legacy = new LegacyPaymentService();
    this.modern = new ModernPaymentService();
    this.useModern = config.enableModernPayment;
  }
 
  async processPayment(amount: number, currency: string): Promise<PaymentResult> {
    if (this.useModern) {
      // New path: Modern implementation
      return this.modern.charge({ amount, currency });
    }
    // Legacy path: Will be removed after migration
    const result = await this.legacy.oldCharge(amount, currency);
    return this.normalizeResult(result);
  }
 
  private normalizeResult(legacyResult: LegacyResult): PaymentResult {
    return {
      transactionId: legacyResult.tx_id,
      status: legacyResult.ok ? 'success' : 'failed',
      timestamp: new Date(legacyResult.ts),
    };
  }
}

Editor View のプロンプト例は次の通りです。

Analyze the LegacyPaymentService class and create a
Strangler Fig migration plan:
1. Generate an adapter that wraps the legacy service
2. Define the modern interface based on actual usage patterns
3. Create a feature flag to toggle between legacy and modern
4. List all call sites that need to use the adapter

テストカバレッジの自動拡張

リファクタリング前にテストカバレッジを高めておくことは、安全な移行の基盤です。AI によるテスト生成機能と組み合わせることで、既存コードのテストを自動生成できます。

Generate comprehensive tests for the LegacyPaymentService
before refactoring. Cover: happy path, edge cases,
error scenarios, and boundary conditions.
Use the existing test patterns in this project.

Antigravity はプロジェクト内の既存テストのスタイル（Jest, Vitest, Mocha など）を自動検出し、一貫したスタイルでテストを生成します。

パフォーマンス最適化リファクタリング

AI を活用したパフォーマンス分析も、Editor View の強力な使い方です。

N+1 問題の検出と修正

// Before: N+1 query pattern（AI が自動検出）
async function getOrdersWithProducts(userId: string) {
  const orders = await db.query('SELECT * FROM orders WHERE user_id = ?', [userId]);
 
  // ⚠️ N+1: Each iteration triggers a separate query
  for (const order of orders) {
    order.products = await db.query(
      'SELECT * FROM products WHERE order_id = ?',
      [order.id]
    );
  }
  return orders;
}
 
// After: Batch query pattern（AI が変換）
async function getOrdersWithProducts(userId: string) {
  const orders = await db.query('SELECT * FROM orders WHERE user_id = ?', [userId]);
 
  if (orders.length === 0) return [];
 
  const orderIds = orders.map(o => o.id);
  const products = await db.query(
    `SELECT * FROM products WHERE order_id IN (${orderIds.map(() => '?').join(',')})`,
    orderIds
  );
 
  // Group products by order_id
  const productsByOrder = products.reduce((acc, p) => {
    (acc[p.order_id] ||= []).push(p);
    return acc;
  }, {} as Record<string, Product[]>);
 
  return orders.map(order => ({
    ...order,
    products: productsByOrder[order.id] || [],
  }));
}

このような最適化パターンは、以下のプロンプトで検出と修正を一括で行えます。

Scan the repository for N+1 query patterns, unnecessary
re-renders in React components, and synchronous file
operations that could be parallelized. For each finding,
generate the optimized version with before/after comparison.

実運用で測った費用対効果 — 複数プロジェクトを並行で作り変えた記録

ここからは、私自身が個人開発で4つのサイトと複数のモバイルアプリを並行運用しながら、Editor View でリファクタリングを進めた際の実感を、できるだけ数字に近い形でお伝えします。あくまで一個人の運用記録ですが、判断の目安にはなるはずです。

冒頭で触れた「3年分の技術的負債」を抱えたコードベースは、any 型が 200 箇所以上、循環参照が 7 組ありました。従来の手作業なら、影響範囲の調査だけで数日は溶けていた規模です。Editor View に依存関係分析を任せたところ、構造の把握は半日で終わりました。一番削減できたのは「書く時間」ではなく「調べる時間」だったのです。

体感として、効果が大きかった作業と、そうでもなかった作業ははっきり分かれました。下の表は、私が並行運用の中で繰り返し感じた傾向を整理したものです。

この表から私が学んだのは、AI は「調べる・置き換える」の反復作業でこそ真価を発揮し、「どこを境界にするか」「何を壊してはいけないか」という設計判断は最後まで人の仕事として残る、ということです。費用対効果を最大化したいなら、AI に渡す範囲を「可逆で機械的な変換」に絞るのが近道だと考えています。

AI に任せて事故りかけた3つの場面

正直に書きますと、最初からうまくいったわけではありません。並行運用の中で、私自身が肝を冷やした場面がいくつかありました。再発防止のために記録している3つを共有します。

ひとつ目は、テストが薄い箇所をまとめて変換してしまったことです。Diff は綺麗に見えたのですが、テストが存在しない関数だったため、本番で初めて挙動の差異に気づきました。それ以来、変換の前に必ずカバレッジを確認し、テストのない領域は「先にテストを足す」工程を挟むようにしています。

ふたつ目は、AI が「ついでに」周辺コードまで整えてしまうことです。依頼した範囲を超えて変数名やフォーマットを変えられると、レビューのノイズが一気に増えます。私はプロンプトに「Only modify what is necessary for this change. Do not reformat unrelated code.」と添えることで、変更を最小限に抑えるようにしました。

みっつ目は、一度に大きく入れすぎて、どの変更が問題を起こしたか切り分けられなくなったことです。数十ファイルを一括適用してテストが落ちると、原因の特定に逆に時間がかかります。今は「1コミット1関心事」を徹底し、モジュール単位で小さく刻んでいます。

どれも特別な失敗ではありません。ですが、こうした小さな痛みを一つずつ手順に落とし込んでいくことが、AI を信頼できる相棒に育てる地道な道のりなのだと感じています。

ロールバックを前提に設計する — フィーチャーフラグと kill switch

大規模な変更を本番に入れるとき、私が最も大切にしているのは「いつでも戻せる」状態を保つことです。前進する勇気は、退路があるからこそ持てるものだと考えています。

Strangler Fig パターンでフィーチャーフラグを挟んでおくと、新旧の実装を環境変数ひとつで切り替えられます。さらに私は、異常を検知したら即座に旧実装へ戻す「kill switch」を最初から組み込むようにしています。

// 環境変数 + ランタイム監視で新実装を即座に無効化できる
function shouldUseModern(): boolean {
  if (process.env.MODERN_PAYMENT_KILL_SWITCH === 'on') {
    return false; // 緊急時は問答無用で旧実装へ
  }
  return process.env.ENABLE_MODERN_PAYMENT === 'true';
}

このスイッチがあるだけで、リファクタリングの心理的な重さがまるで変わります。「失敗しても1行の環境変数で戻せる」と分かっていれば、思い切って前に進めます。Editor View に移行プランを作らせるときも、私は必ず「Include a kill switch and rollback path.」を要件に加えるようにしています。

安全なリファクタリングのためのワークフロー

最後に、大規模リファクタリングを失敗なく遂行するための、私自身が落ち着いたワークフローをまとめます。

ステップ 1: 分析フェーズ

Editor View でプロジェクト全体をコンテキストに含め、アーキテクチャ分析を実行します。依存関係グラフ、循環参照、結合度の高いモジュールを特定します。

ステップ 2: テスト強化フェーズ

変更対象のモジュールについて、AI テスト生成でカバレッジを 80% 以上に引き上げます。特に境界値テストとエラーハンドリングのテストを重点的に追加します。

ステップ 3: 段階的変換フェーズ

Diff View で差分を確認しながら、モジュール単位で変換を適用します。各ステップごとにテストを実行し、既存の機能が壊れていないことを確認します。

# 各変換ステップ後に実行
npm test -- --coverage --changedSince=main

ステップ 4: 統合テストフェーズ

全変換が完了したら、エンドツーエンドテストを実行して統合の問題がないことを確認します。

# E2E テスト実行
npm run test:e2e
 
# 型チェック
npx tsc --noEmit
 
# Lint
npm run lint

おわりに — 次の一歩

Antigravity の Editor View を活用した大規模リファクタリングは、AI によるアーキテクチャ分析、マルチファイル同時変換、段階的マイグレーション支援という三つの柱で成り立っています。従来は数週間かかっていたコードベース全体のリファクタリングが、AI のアシストにより数日で安全に完遂できるようになりました。

ただ、一連の作業を通して私が一番強く感じたのは、技術そのものよりも姿勢の問題でした。AI を「全自動ツール」としてではなく、「全体像を見せてくれる相棒」として迎え入れること。Diff View での確認、可逆な一歩から始めること、kill switch を先に仕込んでおくこと——この三つを習慣にするだけで、大規模リファクタリングの成功率は驚くほど安定します。

もし今、開くのが怖いコードベースを抱えているなら、まずは依存関係分析のプロンプトをひとつ投げてみてください。全体が見えた瞬間に、怖さは「やるべきことの一覧」に変わります。あなたのプロジェクトが、静かに、確実に作り変わっていくことを願っています。