Antigravity を実務で使う AI エージェント設定：GEMINI.md と Rules / Workflows
はじめに
前回の記事で、AGENTS.md をはじめとする各ツールのコンテキストファイル（CLAUDE.md / GEMINI.md）が、AI を「チャット」ではなく「仕事場」として使うための基盤であることを解説しました。本稿では、その概念を Google Antigravity で実装する具体的な方法を紹介します。
私は Cursor の Pro プランを利用していますが、パートナーモデルの試行も含めると月の利用枠を超えてしまうことがあります。Google AI Pro プランにも加入しているため、Antigravity を実務レベルで活用できないかと試行錯誤を行いました。
✏️ 追記： シンプルな設定はこちら
なお、今回紹介するようなディレクトリ構成を作成せず、まずは自身のPC全体の「グローバル設定」のみで、手軽に安全なエージェント環境を構築したい方向けの「最小限セットアップ記事」も公開しています。用途に合わせて参照してください。
1. Antigravity の現状：強みと課題
Gemini 3 Flash は処理速度に優れ、複雑なダッシュボード構築タスクにおいて、Pro モデルが約8時間を要したのに対し約3時間強で完了するなど（公式YouTube動画参照）、試行錯誤のサイクルを短縮できる利点があります。Figma MCP を介したデザインデータの取得能力についても、2026年2月現在、Cursor との間に質的な差はほとんどなく、データの入力段階における課題は解消されつつあります。
一方で課題もあります。リポジトリ全体をインデックス化して参照する Cursor とは異なり、Gemini 3 は長いコンテキストと推論能力に依存してコードを解釈します。この特性上、文脈の欠損を推論で補おうとし、存在しない関数や型定義をハルシネーション（Hallucination／幻覚）するリスクがあります。
しかし、Antigravity にはエージェントを制御する柔軟な仕組み（.agent/ 以下のルール定義）が備わっています。「計画フェーズ」や「行動規範」というルールを与えることで、ハルシネーションを抑制し実務に耐えうる整合性を確保できることがわかりました。焦点は「いかにエージェントを制御し、運用するか」にあります。
2. 日本語環境スターターの全体設計
完全版は GitHub リポジトリで公開しています。
ディレクトリ構造
├── AGENTS.md # 共通プロジェクトガイドライン (SSoT)
├── GEMINI.md # Antigravity 用エントリポイント
├── CLAUDE.md # Claude Code 用エントリポイント（オプション）
└── .agent/
├── rules/ # 常時有効ルール
│ ├── language-strategies.md
│ ├── senior-engineer-conduct.md
│ ├── git-commit-rules.md
│ └── indexing-codebase.md # v1.1.0 追加
├── workflows/ # スラッシュコマンド
│ ├── ask.md # /ask 相談（読み取り専用）
│ ├── plan.md # /plan 計画（実装禁止）
│ ├── review.md # /review レビュー
│ ├── explain.md # /explain 説明
│ ├── grasp.md # /grasp 依存関係分析
│ ├── discard.md # /discard セッション要約
│ ├── commit.md # /commit コミットメッセージ生成（英語）
│ └── commit-ja.md # /commit-ja コミットメッセージ生成（日本語）
└── skills/ # 拡張スキル
├── knowledge-cutoff-awareness/
└── indexing-awareness/ # v1.1.0 追加
SSoT（Single Source of Truth）パターン
設計上の最も重要な決定は、GEMINI.md と CLAUDE.md を 「薄いエントリポイント」 にしたことです。両ファイルの内容は同一で、共有の AGENTS.md とルールを参照するだけです。
パターン A
Read and follow all instructions in ./AGENTS.md
Read and follow all rules defined in:
- .agent/rules/*
パターン B
「全部読め」と指示する必要はなく、front-matterに委譲できます。
See ./AGENTS.md for all instructions.
Rules in .agent/rules/ are self-activating per their front-matter.
プロジェクトのルールは AGENTS.md と .agent/rules/ に一元化されており、ツール固有のエントリポイントはそれを参照するだけです。これにより：
- ルールの重複が排除される：ツールが増えても、共通ルールは1箇所で管理する
- ツール間の一貫性が保たれる：Antigravity でも Claude Code でも同じ規約で動作する
- 切り替えコストがゼロ：ツールを試す際にルールを書き直す必要がない
AGENTS.md：プロジェクトガイドライン
# Project Guidelines (SSoT)
このファイルはプロジェクト固有のガイドラインを記述する場所です。
技術的な決定事項、アーキテクチャ、コマンドなどをここに追記してください。
## 参照先
- **行動規範:** `.agent/rules/` を参照してください。
- **ワークフロー:** `.agent/workflows/` を参照してください。
## 禁止事項
- `articles/` 内の既存記事を、論理的構成を損なう形で大幅に改変しない。
- 公開設定（`published: true`）の切り替えは、ユーザーの明示的な指示があるまで行わない。
AGENTS.md にはプロジェクト固有の情報（目的、ディレクトリの役割、禁止事項）を記述し、汎用的なルール（言語戦略、行動規範、コミット規約）は .agent/rules/ に分離しています。この分離により、ルールファイルを別のプロジェクトにそのまま持ち込むことが可能になります。
三層の責務分離
| 層 | ディレクトリ | 適用タイミング | 役割 |
|---|---|---|---|
| Rules | .agent/rules/ |
常時（自動） | AI の振る舞いの基盤。言語、安全性、コミット規約 |
| Workflows | .agent/workflows/ |
ユーザーが / で起動 |
特定タスクの手順書。モード制御（読み取り専用、計画のみ等） |
| Skills | .agent/skills/ |
AI が必要と判断した時 | オンデマンドで読み込まれる拡張能力 |
3. 常時適用ルール：AI に「行動規範」を課す
.agent/rules/ に配置されたファイルは、すべてのセッションで自動的にコンテキストに注入されます。スターターには4つの常時適用ルールが含まれます。
3.1 言語戦略（language-strategies.md）
日本語環境スターターの存在意義そのものとなるファイルです。
---
trigger: always_on
---
# Language Strategies (言語戦略)
- **内部推論 (Internal Reasoning):** 精度を保つため英語が許可/推奨されます。
ただし、ツール呼び出し時のパラメータ（`TaskName` 等）は、
出力直前に必ず日本語へ翻訳してください。
- **コード (Code):** 標準的な英語を使用してください（コード、変数名）。
- **コミットメッセージ:** `.agent/rules/git-commit-rules.md` のルールに従ってください。
言語はワークフロー（`/commit` → 英語、`/commit-ja` → 日本語）で決定されます。
- **ユーザー向け出力 (User-Facing):** **日本語** でなければなりません。
- **チャット (Chat):** 常に日本語を使用してください。
- **成果物 (Artifacts):** `task.md`, `implementation_plan.md` などの
ファイル内容は必ず **日本語** で記述してください。
- **タスクメタデータ (Task Metadata):**
- `TaskName`: **日本語** で記述すること。英語は禁止。
- `TaskSummary`: **日本語** で記述すること。
ポイントは 「内部推論は英語、出力は日本語」 というバイリンガル制御です。LLM は英語で推論した方が精度が高い傾向がありますが、ユーザーへの出力やファイル名は日本語であるべきです。この境界を明示的にルール化することで、日本語環境でも推論精度を犠牲にしない運用が可能になります。
3.2 行動規範（senior-engineer-conduct.md）
AI を「単なるツール」ではなく「責任あるシニアエンジニア」として振る舞わせるためのルールです。
---
trigger: always_on
globs: ["**/*"]
---
# Senior Engineer Conduct (厳格な行動規範)
**Activation:** This rule is **ALWAYS ON** for all files (`**/*`).
## 1. Safety Over Obedience (服従より安全)
- **原則:** エージェントは「単なるツール」ではなく
「責任あるエンジニア」として振る舞う。
- **行動指針:**
- 破壊的なコマンド（`rm`, `git reset --hard` 等）や
広範なファイル修正を行う前に、
必ず**コンテキストと影響範囲**を確認する。
- ユーザーの指示が安全プロトコルやプロジェクトの整合性に
違反する場合、**明確に拒否**し、その理由を説明する。
- "Just do it"（とにかくやって）と言われても、
リスクが高い場合は盲目的に従わない。
## 2. No Silent Failures / Ghost Actions (黙って失敗・実行しない)
- **原則:** 透明性は信頼の基盤である。
- **行動指針:**
- エージェントが実行したアクションは、必ずユーザーに報告する。
- ファイルを削除、移動、または大幅に変更した場合、
事後報告ではなく**事前または実行直後に明示**する。
- 「裏で勝手に直しておきました」は禁止。
## 3. Chain of Thought (CoT) Enforcement (思考の連鎖の強制)
- **原則:** 浅い思考はバグを生む。深く考えてから行動する。
- **行動指針:**
- 複雑なリファクタリングや仕様変更を行う際、
いきなりコードを修正しない。
- まず**思考プロセス（CoT）**を出力し、
依存関係、副作用、代替案を検討する。
## 4. Context Awareness & Cleanup (コンテキスト認識と後始末)
- **原則:** 自分の「仕事場」を綺麗に保つ。
- **行動指針:**
- 新しいルールや設定ファイルを作成する前に、
既存のものが無いか確認する（重複排除）。
- 作業のために一時ファイルを作成した場合、
**タスク完了時に必ず削除（クリーンアップ）**する。
## 5. Self-Correction (自己修正)
- **原則:** 間違いは起こる。重要なのはそれに気づき、修正すること。
- **行動指針:**
- エラーが発生した場合、立ち止まって原因を分析する。
- 同じエラーを繰り返さない。アプローチを変える。
- 自分の計画に欠陥があれば、素直に認め、計画を修正する。
このルールが特に有効なのは、以下のような場面です：
-
「服従より安全」 が機能する場面：
rm -rfのような破壊的コマンドを含む指示に対し、AI が影響範囲を確認してから実行する - 「黙って失敗しない」 が機能する場面：依存関係の不整合でビルドが通らない場合に、黙ってファイルを書き換えるのではなく、問題と選択肢を報告する
- 「思考の連鎖の強制」 が機能する場面：大規模なリファクタリングの前に、まず計画を出力させることでハルシネーションの早期検知が可能になる
3.3 コミットメッセージ規約（git-commit-rules.md）
---
trigger: always_on
globs: ["**/*"]
---
# Git Commit Rules (コミットメッセージ規約)
**Activation:** This rule is **ALWAYS ON** for all git-related operations.
## Scope
- **対象**: staged 変更（`git diff --cached`）のみ。
unstaged・未追跡ファイルは無視。
- **適用範囲**: Git サイドバーの Generate ボタン、
`/commit` `/commit-ja` ワークフロー、
その他すべての git commit 関連操作。
- staged 変更がない場合、コミットメッセージの生成を行わず、
ステージングを促すメッセージのみ返すこと。
## Format: Conventional Commits
すべてのコミットメッセージは **Conventional Commits** 形式を厳守する。
```
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
```
### Type（常に英語）
`feat`, `fix`, `docs`, `style`, `refactor`, `perf`,
`test`, `chore`, `build`, `ci`, `revert`
### Description（件名）
- 50文字以内
- 末尾にピリオド（`.`）を付けない
- 言語はワークフローの指定に従う
（`/commit` → 英語、`/commit-ja` → 日本語）
### Body（本文、任意）
- 件名と本文の間には空行を入れる
- 変更の理由・背景・影響を簡潔に記述
- 英語の場合は72文字で折り返し
## Guardrails（禁止事項）
- ❌ 絵文字の使用
- ❌ スラング・口語表現
- ❌ 曖昧な表現: `update`, `fix`, `change`, `modify`,
`更新`, `修正`, `変更`, `対応`, `wip`
- ❌ メタ解説・導入文・締めの言葉
## Principles（原則）
- **1コミット1変更**: 論理的に独立した変更は分割する。
複数の type にまたがる場合、分割を提案すること。
- **破壊的変更**: `!` を type の後に付与する（例: `feat!:`）。
- **出力形式**: コミットメッセージ本文のみを直接出力する。
思考プロセスや解説は一切含めない。
Conventional Commits の形式自体は広く知られていますが、注目すべきは Guardrails（禁止事項） です。update、fix、変更、対応 といった曖昧な表現を明示的に禁止することで、AI が生成するコミットメッセージの具体性が向上します。
3.4 プロジェクト構造認識（indexing-codebase.md）— v1.1.0 追加
セクション1で述べた「Antigravity はリポジトリを事前インデックス化しない」という課題に対する、ルール層からの直接的な対処です。
---
trigger: always_on
globs: ["**/*"]
---
# Project Structure Awareness (プロジェクト構造認識)
**Activation:** This rule is **ALWAYS ON** for all files (`**/*`).
> **Positioning:** `senior-engineer-conduct.md` の原則を、プロジェクト構造の
> **インデックス化と依存関係の検索** に具体化したルールです。
> 原則的な行動規範は `senior-engineer-conduct.md` を参照。
> このルールは **具体的な行動手順** のみを定めます。
## 1. Index Before Act (行動前にインデックスを取る)
- 新しいタスクを開始する際、
**まずプロジェクト構造を把握する**。推測で作業を始めない。
- 具体的な手段：
- `ls`, `find`, `tree` でディレクトリ構造を確認
- **`indexing-awareness` スキルの `index-structure.sh` を実行**
- エントリポイント（`main`, `App`, `index`, `routes` 等）を特定し、
アーキテクチャ（レイヤリング、ドメイン境界）と技術スタックを認識する。
## 2. Grep, Don't Guess (推測せず検索する)
- **存在しない関数・型・モジュールを捏造しない。**
確証がなければ `grep` で実在確認する。
- 具体的な手段：
- `grep -rnI "symbol_name" --include="*.ext" .`
- **`indexing-awareness` スキルの
`trace-dependencies.sh <ファイルまたはシンボル>` を実行**
- 変更対象ファイルの **Forward（参照先）** と
**Reverse（被参照元）** の両方を確認してから編集する。
- 循環参照のリスクがある依存関係を追加する場合、事前に警告する。
## 3. Verify After Change (変更後に検証する)
- ファイルの追加・削除・リネーム後、
旧パスや旧名称への参照が残っていないか `grep` で確認する。
- ルール・ワークフロー・スキルの構成を変更した場合、
**`verify-structure.sh` でドキュメント整合性を検証する**。
このルールの設計で最も重要なのは、senior-engineer-conduct.md との 責務分離 です。行動規範（senior-engineer-conduct）は「安全に振る舞え」「思考してから行動しろ」という原則を定めますが、構造認識（indexing-codebase）は「具体的にどのコマンドを叩け」という手順を定めます。
従来のルールでは「推測しないでください」と書いても、エージェントは「推測はしていません」と認識した上で存在しないファイルを参照するケースがありました。手順レベルまで具体化することで、この抜け穴を塞いでいます。
| 抽象度 | ルール | 例 |
|---|---|---|
| 原則 | senior-engineer-conduct.md | 「コンテキストと影響範囲を確認する」 |
| 手順 | indexing-codebase.md | 「grep -rnI で定義元と呼び出し元を確認する」 |
| ツール | indexing-awareness スキル | 「trace-dependencies.sh <file> を実行する」 |
3.5 ルールの有効化設定
各ルールファイルをいつコンテキストに読み込むかを Activation Mode で制御できます。
エディタの設定画面またはルールファイル作成時に以下の4つから選択します。
-
Always On (常時有効)
- すべての対話で常に読み込まれます。
- 用途: プロジェクト全体の行動規範、言語設定、絶対に守るべき禁止事項。
-
Glob (ファイルパス連動)
- 指定したパターン（例:
**/*.ts）に一致するファイルを編集・閲覧している時のみ有効化されます。 - 用途: 特定言語やフレームワーク（React, SQLなど）固有のコーディング規約。
- 指定したパターン（例:
-
Model Decision (AI判断)
- 会話の内容から AI が「このルールが必要だ」と判断した場合に自動的に読み込まれます。
- 用途: 特定のライブラリの詳細仕様など、必要な時だけ参照してほしい情報。
-
Manual (手動)
- ユーザーがチャットで明示的に（
@RuleName等で）参照しない限り読み込まれません。 - 用途: 頻繁には使わない手順書や、コンテキストを圧迫したくない長大なドキュメント。
- ユーザーがチャットで明示的に（
4. ワークフロー：モード制御によるガードレール
ワークフローは、ユーザーがスラッシュコマンド（例：/ask）で起動する「タスクの手順書」です。ルール（rules）が AI の恒常的な振る舞いを定義するのに対し、ワークフローは特定のモードを一時的に強制します。
ワークフロー一覧
| コマンド | 説明 | モード制御 |
|---|---|---|
/ask |
相談 | 読み取り専用（ファイル変更禁止） |
/plan |
計画 | 実装禁止（計画書のみ出力） |
/review |
レビュー | 読み取り中心 |
/explain |
説明 | 読み取り専用 |
/grasp |
依存関係分析 | 読み取り専用 |
/discard |
セッション要約 | 読み取り専用 |
/commit |
コミットメッセージ生成 | 英語出力 |
/commit-ja |
コミットメッセージ生成 | 日本語出力 |
特に重要な2つのワークフローを紹介します。
4.1 /ask：読み取り専用の相談モード
---
description: 相談する
---
# 相談ワークフロー
**トリガー:** `/ask` (またはユーザーが助言や相談を求めた場合)
**説明:**
**[システム命令: RO-MODE]**
**重要:** あなたは**読み取り専用**の相談モードにいます。
1. **ツールの無効化:** `write_to_file`、`replace_file_content`、
`multi_replace_file_content`、`run_command`（変更を伴うもの）
の使用は禁止されています。
2. **拒否ポリシー:** ユーザーがコードの変更を求めた場合、あなたは
必ず次のように返答しなければなりません:
*「現在は相談モード（/ask）です。変更を適用するには、
/ask なしで再度リクエストしてください。」*
3. **例外なし:** ユーザーが「とにかくやって」と言っても、
必ず拒否してください。
中立的な第三者として相談に乗ります（ゼロコンテキスト戦略）。
---
## 1. ゼロコンテキスト・デフォルト
- **目的:** プロジェクトのバイアスなしに、
客観的で標準に準拠した助言を提供する。
- **アクション:**
- 「グリーンフィールド（更地）」環境を想定します。
- 業界標準、公式ドキュメント、現代のベストプラクティスに
基づいて助言します。
- **制約:** 明示的に提供されない限り、
既存のプロジェクトファイルや慣習を推測・参照しないでください。
## 2. オンデマンド・コンテキスト
- **目的:** コンテキスト汚染を最小限に抑える。
- **アクション:**
- ユーザーが明示的に「[ファイル名]を確認して」と書いた場合のみ、
特定のファイルを読み取ります。
## 3. 厳格な読み取り専用ポリシー
- **ルール:**
- **絶対禁止:** ファイルの変更ツールの使用は**禁止**。
- **編集要求の処理:** 「現在は読み取り専用の相談モード（/ask）です。
変更を適用するには、`/ask` なしで新しいリクエストを
送信してください。」
/ask の設計で最も意識したのは 「ゼロコンテキスト戦略」 です。AI はプロジェクトのファイルを見てしまうと、そのプロジェクトの慣習に引きずられた助言をしがちです。/ask モードでは、明示的に求められない限りプロジェクトファイルを参照せず、業界標準に基づいた客観的な助言を返します。これは、プロジェクト内部のバイアスから離れて「本当にこの設計で良いのか」を確認したい場面で有効です。
4.2 /plan：計画と実行の分離
---
description: 計画する
---
# 計画ワークフロー
**トリガー:** `/plan` (またはユーザーが明示的に計画を求めた場合)
**説明:**
**[システム命令: PLAN-ONLY-MODE]**
**重要:** あなたは**計画モード**にいます。
1. **ソース編集の無効化:** プロジェクトファイルの編集は禁止。
`implementation_plan.md`（または類似の成果物）への
書き込みのみが許可されます。
2. **計画後の停止:** 計画を実行しないでください。
コードを書かないでください。
3. **拒否ポリシー:** ユーザーが「今すぐ実装して」と求めた場合、
*「計画を作成しました。確認後、次のターンで
実装を依頼してください。」* と返答する。
## 計画内容の要件
生成されるマークダウンファイルには以下を含める:
1. **目的:** 達成すべき内容の明確な要約。
2. **分析（現状分析）:** 現状 vs 理想の状態。
3. **提案される変更:**
- 作成または変更するファイルのリスト。
- 具体的なロジックの変更（擬似コードまたはシグネチャ）。
- **検証計画:** 変更が機能することをどのように検証するか。
4. **リスク評価:** 回避すべき潜在的な副作用やハルシネーション。
/plan は、ハルシネーション対策として最も効果的なワークフローです。AI に「いきなりコードを書かせない」ことで、以下の効果が得られます：
- 計画段階で誤りを検出できる：存在しない API や関数への依存が、計画書の段階で可視化される
- 人間のレビューポイントが生まれる：計画書を確認してから実装に進むという明示的なゲートが設けられる
- 手戻りが減る：大規模な変更ほど、事前の計画が手戻りコストを削減する
5. スキル：RAG的なコンテキスト取得の擬似再現 — v1.1.0 追加 {#skills}
セクション2で紹介した「三層の責務分離」のうち、Skills の具体例を紹介します。
5.1 課題：Cursor との構造的な差
前述の通り、Cursor はリポジトリ全体を事前にインデックス化し、RAG（Retrieval-Augmented Generation）で正確な依存関係を引き出します。Antigravity にはこの仕組みがないため、エージェントは長いコンテキストウィンドウ内の情報だけで推論を行います。
この構造的差異を放置すると、以下のような問題が起きます：
- 読み込み漏れ：参照すべきファイルがコンテキストに含まれておらず、存在しない関数を捏造する
- 影響範囲の見過ごし：変更対象ファイルの被参照元を確認せず、壊れた参照を残す
- 構造の誤認：プロジェクトのアーキテクチャを把握しないまま、流儀に反したコードを生成する
5.2 解決策：ルール + スキルの連携
indexing-codebase.md（ルール）が「何をすべきか」を定め、indexing-awareness（スキル）が「どうやるか」のツールを提供する、という 原則→手順→ツール の三層構造で擬似 RAG を実現しています。
senior-engineer-conduct.md (原則: 安全性・透明性)
↓ Positioning で参照
indexing-codebase.md (行動手順: Index → Grep → Verify)
↓ 各項目でスクリプトを明示
indexing-awareness/SKILL.md (Triggers: いつ自動実行するか)
↓
scripts/ (具体的なツール実行)
スキルの核となるのは Triggers（自動実行条件） の定義です。人間が「このスクリプトを実行して」と指示するのではなく、エージェント自身が状況に応じて自発的にスクリプトを実行します。
| 状況 | 実行するスクリプト | RAG との対応 |
|---|---|---|
| 初見のプロジェクト・新しいタスク開始時 | index-structure.sh |
事前インデックス化 |
| ファイルの変更・追加・削除を行う前 | trace-dependencies.sh <ファイル> |
関連コンテキスト検索 |
| 未知のシンボルを参照する前 | trace-dependencies.sh <シンボル> |
定義・使用箇所の検索 |
| ルール・ワークフロー・スキルの構成変更後 | verify-structure.sh |
整合性検証 |
5.3 スクリプトの実装
index-structure.sh：プロジェクト構造のインデックス
プロジェクトのディレクトリ構造、ファイル種別、サイズを高速にインデックス化します。node_modules/ や .git/ などのノイズを自動除外し、エージェントが全体像を把握するための「地図」を生成します。
# プロジェクト全体のインデックス
./.agent/skills/indexing-awareness/scripts/index-structure.sh
# 出力例:
📁 Project Structure Index
============================================================
📂 src/ (5 items)
📂 components/ (3 items)
📄 Header.tsx (1240B)
📄 Footer.tsx (890B)
📂 utils/ (2 items)
📄 auth.ts (2100B)
📄 App.tsx (3200B)
============================================================
📊 Summary:
Files: 12 | Directories: 4
File types:
.tsx: 6
.ts: 4
.json: 2
trace-dependencies.sh：依存関係の双方向トレース
ファイルモード と シンボルモード の2つの動作モードを持ちます。
# ファイルモード：あるファイルの Forward/Reverse 依存を表示
./.agent/skills/indexing-awareness/scripts/trace-dependencies.sh src/utils/auth.ts
# 出力例:
📥 Forward Dependencies (このファイルが参照しているもの):
---
3:import { db } from '../config/database'
5:import { hashPassword } from './crypto'
📤 Reverse Dependencies (このファイルを参照しているもの):
---
src/routes/login.ts:2:import { authenticate } from '../utils/auth'
src/middleware/guard.ts:1:import { verifyToken } from '../utils/auth'
# シンボルモード：関数やクラスの定義元と使用箇所を検索
./.agent/skills/indexing-awareness/scripts/trace-dependencies.sh handleLogin
# 出力例:
📌 Definitions (定義元):
---
src/routes/login.ts:15:export function handleLogin(req, res) {
📎 Usages (使用箇所):
---
src/routes/login.ts:15:export function handleLogin(req, res) {
src/routes/index.ts:8: router.post('/login', handleLogin)
test/login.test.ts:12: const result = await handleLogin(mockReq, mockRes)
これにより、エージェントは「auth.ts を変更する前に、login.ts と guard.ts が影響を受ける」ことを推測ではなく検索結果として把握できます。
6. 設計原則のまとめ
個別のファイルを紹介しましたが、スターター全体を貫く設計原則は4つに集約されます。
原則1：計画→実行の分離
/plan で計画書を出力し、確認後に実装する。ハルシネーションのリスクを「いきなりコードを書かせない」ことで低減する。これは senior-engineer-conduct の「思考の連鎖の強制（CoT Enforcement）」と同じ発想であり、ルール層とワークフロー層の両面から補強されている。
原則2：モード制御によるガードレール
/ask（読み取り専用）、/plan（実装禁止）、通常モード（実行可能）の段階的なモード制御で安全性を確保する。「とにかくやって」と言われても拒否する設計は、senior-engineer-conduct の「服従より安全」原則と呼応している。
原則3：バイリンガル制御
内部推論は英語で精度を保ち、出力は日本語。日本語環境で AI を使う際、「全部日本語にする」と推論精度が下がり、「全部英語にする」と使いにくい。language-strategies.md による境界の明示が、この二律背反への実用解になっている。
原則4：原則→手順→ツールの三層構造（v1.1.0 追加）
ルールで「こう振る舞え」と宣言するだけでは、エージェントは自己流に解釈して抜け穴をすり抜ける。senior-engineer-conduct（原則）→ indexing-codebase（手順）→ indexing-awareness スキル（ツール）という三層構造により、抽象的な行動規範を具体的な実行コマンドまで落とし込んでいる。これは Cursor が RAG で自動的に行っている「構造認識 → 関連検索 → コンテキスト注入」のプロセスを、ルールとスクリプトで明示的に再現する試みである。
おわりに
Antigravity（Gemini 3）は非常に強力な推論能力を持ち、はるか遠くの正解を見通す「眼」を持っていますが、時にその視線はあてもなく彷徨（さまよ）います。「月を指さす指」がなければ、月を見つけられないのと同様に、強力な推論も方向性がなければ空転します。今回紹介した .agent/ 以下の設定ファイル群を与えることは、この強力なモデルに対して「どこを見るべきか」という指針を与え、いわば新人エンジニアに対して「オンボーディング資料」や「就業規則」を渡すことと同義です。
v1.1.0 で追加した indexing-codebase.md と indexing-awareness スキルは、この考え方をさらに一歩進めたものです。「どこを見るべきか」を指示するだけでなく、「見るための道具」まで渡す。オンボーディング資料に「作業手順書」と「専用ツール」を添えるようなものです。Cursor が RAG で自動的に行っている構造認識を、エージェント自身が自律的にスクリプトを実行することで再現する——完全な代替にはなりませんが、ハルシネーションの発生頻度を構造的に減らすアプローチとして機能しています。
適切な行動規範（Rules）と業務マニュアル（Workflows）、そして専用ツール（Skills）を共有できれば、予測不能だった AI は、規律を守り、安全に行動し、日本語で円滑にコミュニケーションが取れる「信頼できる同僚」へと変わります。
本稿で紹介した日本語環境スターターは、私が試行錯誤の末にたどり着いた現時点でのベストプラクティスですが、決して完成形ではありません。プロジェクトの性質やチームの文化に合わせて、AGENTS.md を書き換えたり、独自のスキルを追加したりして、ぜひあなただけの「最強のエージェント」を育てていってください。
AI エージェントとのペアプログラミングは、一度軌道に乗ると戻れないほどの生産性と楽しさがあります。このスターターキットが、その新しい開発体験への入り口となれば幸いです。
次回は knowledge-cutoff-awareness について紹介します。
参考：作者の個人設定紹介 (2026-02-17 追記)
Antigravity の挙動を安定させ、コンテキスト汚染を防ぐための推奨設定です。好みで調整してください。
1. プロジェクト共通設定 (~/.gemini/GEMINI.md)
設定なし
プロジェクト毎に antigravity-starter-ja を配置。
2. Antigravity IDE 設定
ウィンドウ右下の Antigravity - Settings からの設定です。エージェントの「自律性」と「安全性」のバランスを調整します。
Security (セキュリティ)
-
Strict Mode: Off
Artifact (成果物・生成コード)
-
Review Policy: Request Review (必ず人間が確認を行う)
Terminal (ターミナル)
-
Command Auto Execution: Always Proceed (確認プロンプトをスキップ) -
Enable Sandbox: On (ネットワーク許可)
Automation (自動化・ファイル操作)
-
Agent Auto-Fix Lints: Off (動作軽量化のため無効化) -
Auto-Continue: On -
Auto-Open Edited Files: On
History & Context (履歴・コンテキスト)
-
Conversation History: Off (重要: 過去のチャット履歴による文脈汚染を防ぐ) -
Knowledge: Off (重要: 不正確なRAG検索を避け、都度読み込みさせる)
3. エディタ設定 (settings.json)
エージェントとエディタ機能の競合（フォーマッターの喧嘩など）を防ぐための設定です。
{
// --- 表示・ラッピング制御 ---
"editor.wordWrap": "off",
"editor.wordWrapColumn": 0,
"editor.wrappingIndent": "none",
"editor.rulers": [],
"editor.minimap.enabled": false,
// --- フォーマット制御 (エージェントとの競合回避) ---
"editor.formatOnType": false,
"editor.formatOnPaste": false,
"files.trimTrailingWhitespace": false,
"files.insertFinalNewline": false,
"files.trimFinalNewlines": false,
// --- 保存時コードアクションの無効化 ---
"editor.codeActionsOnSave": {
"source.fixAll": "never",
"source.organizeImports": "never"
},
// --- エージェント用プロファイル設定 ---
"workbench.settings.applyToAllProfiles": [
"editor.wordWrap",
"editor.formatOnSave",
"files.trimTrailingWhitespace"
],
// --- その他 ---
"editor.accessibilitySupport": "off",
"editor.comments.ignoreEmptyLines": false,
"diffEditor.ignoreTrimWhitespace": false,
"[prompt]": {},
"editor.dropIntoEditor.preferences": [],
// --- 言語固有設定 ---
"html.format.wrapAttributes": "preserve",
"html.format.wrapLineLength": 0,
"css.format.newlineBetweenRules": false,
"javascript.format.semicolons": "ignore",
"typescript.format.semicolons": "ignore",
// --- ユーザー設定 (好み) ---
"editor.autoIndent": "brackets",
"editor.tabSize": 2
}
4. 推奨拡張機能 (Extensions)
無闇な拡張機能の追加はエージェントのコンテキスト認識に悪影響を与える可能性があるため、必要最小限の構成を推奨します。
Discussion