「Antigravity にコードを書かせたら TypeScript のエラーが100件以上増えた」——そんな経験はないでしょうか。私自身、Antigravity を使い始めた頃は同じ状況に何度も遭遇しました。エラーを1つ直すとまた別のエラーが出てきて、気づくと AI の修正ループに引き込まれて30分が経過…というのは決して珍しいケースではありません。
この問題は Antigravity の使い方を少し変えるだけで、ほぼ根絶できます。まずはエラーが量産される仕組みを押さえ、そのうえで再発を止める具体策へ進みます。
なぜ AI 生成コードは TypeScript エラーを起こしやすいのか
Antigravity が TypeScript エラーを起こしやすい理由は、主に3つあります。
型定義ファイルを見ていないという問題があります。プロジェクトに types/ フォルダや *.d.ts ファイルがあっても、Antigravity のコンテキストにそれらが含まれていないと、AI は存在しない型を推測で使います。特に自前の型定義（User, Product, ApiResponse など）は要注意です。
ライブラリのバージョン差を無視しているという問題もあります。React 18 と 19 では JSX の型定義が変わっています。Next.js 14 と 15 では App Router の型も異なります。AI が学習した情報は特定バージョンのものであり、あなたのプロジェクトで使っているバージョンと必ずしも一致しません。
tsconfig.json の strict 設定を把握していないという問題もあります。"strict": true を有効にしているプロジェクトでは、AI が生成する「ゆるい」コードが軒並み型エラーになります。noImplicitAny や strictNullChecks の影響は特に大きく、AI が undefined チェックを省略したコードを書くと即座にエラーになります。
エラーの種類から根本原因を特定する
全てのエラーを同列に扱うのは非効率です。まず以下のコマンドでエラーの種類を確認しましょう。
# エラーコード別に集計して頻出パターンを把握する
npx tsc --noEmit 2>&1 | grep "error TS" | grep -oP "TS\d+" | sort | uniq -c | sort -rnエラーコードが見えると、同じ根本原因から派生していることがほとんどだとわかります。
Property 'xxx' does not exist on type 'yyy'（TS2339） — コンテキスト不足が原因です。型定義ファイルを AI に見せましょう。
Type 'string | undefined' is not assignable to type 'string'（TS2322） — strictNullChecks が有効なのに AI が null チェックを省いた場合です。
Cannot find module 'xxx' or its corresponding type declarations（TS2307） — @types/xxx が未インストール、または AI が存在しないパッケージを参照しています。
Argument of type 'xxx' is not assignable to parameter of type 'yyy'（TS2345） — ライブラリのバージョン差が原因の場合が多いです。package.json のバージョンを AI に共有しましょう。
コンテキスト強化でエラーを事前に防ぐ
エラーが出てから修正するより、最初からエラーが出ないコードを生成させる方が明確に効率的です。作業開始時に以下を明示的に伝えることをお勧めします。
# プロジェクトの型情報をまとめてコンテキストに追加する
cat tsconfig.json
cat package.json | grep -A 30 '"dependencies"'
find . -name "*.d.ts" -not -path "*/node_modules/*"チャットの冒頭で「このプロジェクトは TypeScript strict モードを使っています。strictNullChecks: true です。型推論を省略せず、必ず明示的な型注釈をつけてください」と一言添えるだけで、エラー発生率が体感で70〜80%減ります。
特に自前の型定義が多いプロジェクトでは、型定義ファイルをコンテキストに含めることを習慣にしてください。
カスタムルールで再発を根本的に防ぐ
毎回コンテキストを手動で追加するのは手間です。.rules（または .antigravity/rules.md）にプロジェクト固有のルールを記述しておきましょう。
# TypeScript コーディングルール
## 型安全
- このプロジェクトは TypeScript strict モードを使用しています
- `any` 型の使用は禁止です（`unknown` を使ってください）
- `\!` 非nullアサーションは使わず、適切なnullチェックを行ってください
- 関数の引数・戻り値には必ず型注釈を付けてください
## 型定義の場所
- カスタム型は `types/` ディレクトリに集約されています
- APIレスポンスの型は `types/api.ts` を参照してください
## 使用ライブラリのバージョン
- React 19
- Next.js 15（App Router）
- Zod でバリデーションこのルールファイルを設定すると、Antigravity は毎回このコンテキストを参照してコードを生成します。「any を使った」「null チェックがない」といった問題も自動で避けてくれるようになります。
エラーが大量発生した後の収束手順
すでにエラーが大量に出てしまった場合は、AI による「全エラー一括修正」は避けてください。コンテキスト不足のまま修正させると、修正が修正を呼ぶ悪循環になります。
まず以下でエラーをカテゴリ別に把握します。
npx tsc --noEmit 2>&1 | grep "error TS" | grep -oP "TS\d+" | sort | uniq -c | sort -rn次に型定義ファイルを Antigravity に共有してから修正を依頼します。
「TypeScript エラーが出ています。修正前に以下の型定義ファイルを確認してください：
[types/api.ts の内容]
この型定義を前提に、以下のエラーを修正してください：
[エラーログの最初の20行]」
ファイル単位で修正を進めることも重要です。全エラーを一度に修正しようとせず、エラーの多いファイルから1ファイルずつ進めてください。
# ファイル別エラー数を確認する
npx tsc --noEmit 2>&1 | grep "error TS" | sed 's/(.*//' | sort | uniq -c | sort -rn | head -10Zod との組み合わせで型安全を徹底する
AI 生成コードのエラーを防ぐ上で、Zod との組み合わせは特に相性が良いです。API レスポンスを Zod スキーマで定義しておくと、AI は「この型でバリデーションする」という明確な指示として理解します。
import { z } from "zod";
// APIレスポンスの型定義（Zodスキーマ）
const UserSchema = z.object({
id: z.string().uuid(),
name: z.string().min(1),
email: z.string().email(),
role: z.enum(["admin", "user", "guest"]),
createdAt: z.string().datetime(),
});
// スキーマから型を自動生成
type User = z.infer<typeof UserSchema>;
// バリデーション付きでデータを取得
async function fetchUser(id: string): Promise<User> {
const res = await fetch(`/api/users/${id}`);
if (\!res.ok) throw new Error(`HTTP ${res.status}`);
const data = await res.json();
// 型が合わなければここで例外が出るため、後続の処理が安全になる
return UserSchema.parse(data);
}この形式で型定義をしておくと、Antigravity が新しいコードを書く際にスキーマから型を正確に推論できます。TypeScript エラーの発生が大幅に減りました。
TypeScript エラーとの戦いは、最終的には「AI にどれだけ正確なコンテキストを与えられるか」の問題です。ルールファイルと型定義の共有を習慣にするだけで、開発の体験がかなり変わります。まずは .rules ファイルに TypeScript のコーディングルールを書くことから始めてみてください。