Antigravity「Customizations」完全攻略ガイド —例示や説明なしで、一発で正解を出させるー
はじめに
本記事では、AntigravityのCustomizations機能を使って「何を作りたいか」を伝えるだけで、期待通りのコードが一発で生成される環境を構築します。

「ログイン・ホーム・ユーザー登録画面を作り、仮のメールアドレスとパスワードでログインできるようにして。バリデーションとテストもお願い。」と入力して生成されたアプリ。
ログイン画面
登録画面
ホーム画面
準備編
Customizationsとは?
プロンプトエンジニアリングを毎回行う手間を省き、設定ファイルとして永続化・自動化する仕組みのことです。(GeminiのGemやChatgptのgptsみたいなものです。)
Customizations
これを設定することでプロジェクト専属の熟練エンジニアへとAIを進化させ、期待通りの成果物を出力させることができます。
1. Rulesの設定(技術スタックを固定する)
Rulesとは一言でいうとプロジェクト内のルールのことです。
例えば、「CSSファイルを作らずTailwindを使う」「any型を禁止する」といった制約を日本語で明記します。
rulesの設定方法
1.画面右上のメニューから 「Customizations」 を開きます。

2.「Rules」 タブを選択します。
3.「+ Workspace」 をクリックし、名前に 「project-rule」 と入力して作成します。
※+Workspaceで作成するとプロジェクトルート以下で適用されます
4.作成されたファイルに、以下のコードを貼り付けます
# 言語設定
- **コミュニケーション**: 全ての応答は日本語で行うこと。
- **コードコメント**: コード内のコメントは日本語で記述すること。
- **コミットメッセージ**: 以下のプレフィックス記法に従い、日本語で記述すること。
- (feat, fix, docs, style, refactor, test, chore)
- 例: `feat: ログイン機能の実装`
# 役割定義:AIにどのような振る舞いをさせるか
role:
name: "Senior Frontend Engineer"
tone: "Professional, Concise, Helpful"
language: "Japanese" # 出力言語を日本語に固定
# 技術スタックの明示:ここを変えるだけで別プロジェクトにも流用可能
tech_stack:
framework: "Next.js 14 (App Router)"
language: "TypeScript"
styling: "Tailwind CSS"
validation: "Zod"
testing: "Playwright (E2E)"
form: "React Hook Form"
ui_library: "Shadcn UI (Radix UI)"
# コーディング規約:ここが「暗黙の了解」を言語化する肝
coding_standards:
general:
- "KISS原則(Keep It Simple, Stupid)を重視し、過度な抽象化を避ける"
- "コードはそのままコピペで動く完全な状態で出力する(省略禁止)"
- "import文は絶対パス(`@/components/...`)を使用する"
react:
- "コンポーネント定義はアロー関数を使用する (`const Component = () => {}`)"
- "Named Exportを使用する (`export default` は禁止)"
- "Propsの型定義は `interface` ではなく `type` を使用する"
- "クライアントコンポーネントが必要な場合のみ `'use client'` をファイルの先頭に記述する"
styling:
- "スタイリングはTailwind CSSのみで行う(CSS Modules禁止)"
- "クラス名の結合には `clsx` と `tailwind-merge` を使用する (`cn`ユーティリティ)"
- "カラーコードのハードコーディング禁止(`bg-blue-500` ではなく `bg-primary` 等のセマンティックトークンを使用)"
type_safety:
- "Any型の使用は厳禁。不明な場合はジェネリクスかunknownを使用"
- "ZodスキーマをSingle Source of Truthとし、TypeScriptの型は `z.infer` で生成する"
testing:
- "テストは Playwright を用いたE2Eテストを基本とする"
- "テスト実行時は必ず `--headed` フラグ等を使用し、ブラウザを視覚的に起動させる(ヘッドレス実行は原則禁止)"
- "テストコードはユーザーの操作(クリック、入力、遷移)をシミュレートする形式で記述する"
このファイルを作成することで、プロンプトで「Reactで書いて、Tailwindで…」と毎回指定する必要がなくなります。
2. Workflowsの設定(実装手順)
Workflowsは実装手順を指定します。
AIは放っておくと思考停止でいきなり実装を始めてしまいます。
これを防ぎ、強制的に「シニアエンジニアの思考プロセス」で仕事をさせる機能が Workflows です。
Workflowの設定方法
Rulesと同様に、Customizationsメニューから設定します。
1.画面右上のメニューから 「Customizations」 を開きます。
2.「Workflows」 タブを選択します。
3.「+ Workspace」 をクリックし、名前に 「tdd-flow」 と入力して作成します。
4.作成されたファイルに、以下のコードを貼り付けます。
steps:
- "1. [User Story] 実装する機能を「ユーザーがブラウザで〇〇すると、画面が△△に変化する」というE2E形式で定義する"
- "2. [Test Case Planning] コードを書く前に、以下の観点でテストケース一覧をMarkdownの表形式で作成する: (A)正常系 (B)異常系(バリデーション、通信エラー) (C)境界値(最大文字数、空文字)。これによりテストの網羅性を担保する"
- "3. [E2E Test First (Red Phase)] 確定したテストケースに基づき、Playwright のテストスペックを作成する。実行時は必ず **ブラウザを起動(Headed mode / --headed)** し、期待する要素が存在しないこと(Red状態)を目視でも確認する"
- "4. [Black Box Testing] テスト記述時は内部実装(Stateや関数)への依存を禁止し、`page.getByRole` や `page.fill` など、ユーザーに見える要素のみを操作対象とする"
- "5. [Visual Verification] DOMの存在確認だけでなく、`toBeVisible()` や `toHaveURL()` を用いて、立ち上がったブラウザ上で正しく表示・遷移されているかを検証条件に含める"
- "6. [Implementation (Green Phase)] ブラウザテストをパスさせるためだけの「最小限の実装」を行う"
- "7. [Self-Healing Cycle] テストが失敗した場合、ユーザーに助言を求めず、以下のループを自律的に実行する: (1) エラーログとブラウザ状態を分析 (2) 原因(セレクタ不一致、タイムアウト、ロジックミス)を特定 (3) 実装コードを修正 (4) テスト再実行。これをテストがGreenになるまで繰り返す"
- "8. [Browser Compatibility] 最終確認として再度ブラウザを立ち上げてテストを実行し、人間の目でも違和感(一瞬のチラつきやレイアウト崩れ)がないことを保証する"
準備はこれで完了です。
実践編
実際にAIに開発を依頼してみましょう。
検証ケース:管理画面のログイン・登録機能
通常、ここまでの要件を伝えるには「Next.jsで、デザインはTailwindで、バリデーションはZodで…」と長文のプロンプトが必要です。 しかし、今回は違います。
指示を投げる
エディタのチャット欄に一言だけ入力します。
/tdd-flow ログイン・ホーム・ユーザー登録画面を作り、仮のメールアドレスとパスワードでログインできるようにして。バリデーションとテストもお願い。
技術選定も、ファイル構成も、言語指定さえしなくても、project-ruleで指定した技術スタックが反映されています。
生成されたImplementation Plan
実行
Planを承認すると、実行フェーズに移行します。
Agentは、ruleとworkflowからフレームワークや実行手順などの情報を読み取り、コードを生成します。
コード生成が終わるとテストを実行し、エラーが出た場面は自動で修復し、Webアプリを完成させます。
完成したものがこちらになります。
ログイン画面
登録画面
ホーム画面
簡単な指示でここまでクオリティの高いものが作成できました。
まとめ
Customizationsを設定するだけで面倒なプロンプト入力から解放されクオリティの高い成果物を出力することができました。
「AIが変なコードを書く」「指示を聞いてくれない」と悩んでいる人は、プロジェクトのルールが言語化されているかを一度見直してみてください。
逆に言えば、rules.md や workflows.md にチームのルールさえ書き込んであれば、AIは最強のパートナーに変わります。
これは単なる効率化にとどまらず、チーム全体の開発規約を見直し、言語化する良い機会にもなるはずです。
最後に
このアカウントでは、ただの「ツール紹介」ではなく、明日から開発フローを変えるための実践方法を共有していきます!
更新を見逃さないよう、ぜひ今のうちにZennのアカウントをフォローしてお待ちください!!!
Discussion