Google Antigravity 2.0を使っていると、「毎回同じ指示（日本語で答えて、など）をするのが面倒」「AIが勝手にファイルを削除して困る」といった悩みを持たれることはないでしょうか。
Antigravity 2.0には、AIエージェントの根本的な振る舞いを定義する「GEMINI.md」というグローバルルールの仕組みが備わっています。これを正しく設定することで、GUI（チャット画面）とCLIのどちらから操作しても、常に安定した期待通りの動作をさせることが可能になります。
この記事では、Antigravity 2.0を利用する際に役立つ汎用的な GEMINI.md の書き方と、ブログ執筆・Web開発・データ分析などの用途に合わせた具体的な設定例を解説します。
この記事でわかること
前提条件
| 項目 | 内容 |
|---|---|
| 対象 | Google Antigravity 2.0 ユーザー |
| グローバルファイルの場所 | ~/.gemini/GEMINI.md |
| プロジェクト単位の場所 | プロジェクトルート/GEMINI.md または .gemini/GEMINI.md |
GEMINI.md とは何か
GEMINI.md は、AIエージェントにとっての「憲法」とも呼べる重要なファイルです。Markdown形式で書かれた指示書で、起動時にシステムプロンプトとしてAIに読み込まれます。
インターフェースを問わず適用される
GUI（画面右側のチャットや Agent Manager）から指示を出した場合でも、ターミナルから CLI 経由で自律エージェントを起動した場合でも、AIは必ずこの GEMINI.md の内容をベースラインとして読み込みます。
階層構造で管理できる
GEMINI.md にはグローバル・プロジェクト・ディレクトリの3階層があり、より細かい単位で上書きできる設計になっています。
settings.json との使い分け
同じ ~/.gemini/ 配下には settings.json というファイルも存在します。役割が異なるため、以下のように使い分けます。
| ファイル | 役割 |
|---|---|
GEMINI.md | AIへの指示・文脈・プロジェクト知識 |
settings.json | ツール設定・MCP設定・環境設定 |
まず押さえたい汎用的な GEMINI.md 設定例
まずは、多くの方にとってニーズのある「安全で確実な動作」を担保するための汎用ベースライン設定例です。このまま ~/.gemini/GEMINI.md にコピーして使い始められます。
# Global Rules for Antigravity Agent
## 1. 基本的なコミュニケーション
- 言語: すべての回答、アーティファクト（ドキュメント）、コミットメッセージは必ず「日本語」で出力してください。
- 確認の徹底: 不確かな要件や曖昧な指示がある場合は、推測で進めずに必ずユーザーへ質問してください。
- 簡潔な回答: 冗長な前置きは避け、結論から回答してください。
## 2. 安全性とファイル操作（重要）
- 破壊的操作の禁止: ファイルの完全な削除、データベースのドロップ、不可逆な設定変更を行う前には、必ずユーザーの明示的な許可を求めてください。
- バックアップの推奨: 重要な設定ファイル（.envなど）を変更する際は、事前にバックアップを作成することを提案してください。
## 3. コードと出力の品質
- コメントの保持: 既存のコードを変更する際、関係のない既存のコメントやDocstringは絶対に削除しないでください。
- ドキュメントの言語: Implementation Plan, Task, Walkthrough などのアーティファクトは、常に日本語で作成してください。
汎用設定の解説
【用途別】GEMINI.md のカスタマイズ例
ここからは、さらに踏み込んだ用途別のカスタマイズ例を紹介します。ご自身のメインの用途に合わせて上記の汎用設定に追記して使ってください。
1. ブログ記事作成・ライティングに特化した例
ブログの執筆アシスタントとして活用する場合、文体や出力フォーマットのルールを強制すると手直しの時間が大幅に減ります。
## ブログ執筆ルール (Blog Writing Rules)
- 文体: 親しみやすい「です・ます」調で統一し、専門用語には簡単な補足を入れてください。
- 禁止事項: 太字強調（**）や、章ごとの水平線（---）は使用しないでください。
- 構成: 記事を作成する際は「タイトル」「リード文」「前提条件」「手順（H3見出しで分割）」「まとめ」「参考情報」の構成を基本としてください。
- 情報の正確性: 製品の料金やバージョンなどの数値情報を出力する際は、可能な限りWeb検索機能を用いて最新の一次情報を確認してから出力してください。
- スキルファイルの参照: ブログ記事を作成する際は、必ず ~/skills/blog-writer/SKILL.md を読み込んでから作業を開始してください。
このルールのポイントは、ブログごとのレギュレーション（太字を使わない、構成の型など）を GEMINI.md に書いておくことで、プロンプトで毎回指示する手間が省ける点です。「スキルファイルへの誘導」をルールに含めておくと、複数のスキルファイルを持つ環境でも自動的に適切なファイルを読み込ませることができます。
2. Web開発・コーディングに特化した例
フロントエンドやバックエンドの開発アシスタントとして使う場合は、技術スタックやデザインルールの厳守を指示します。
## Web開発標準 (Web Development Standards)
- 技術スタック: フロントエンドは Next.js (TypeScript) と Tailwind CSS をデフォルトとします。バックエンドは Python（FastAPI）を使用します。
- デザインシステム: すべてのコンポーネントは、プロジェクト内の DESIGN.md で定義されたカラーコードとスペースのトークンを厳密に参照して実装してください。
- コード解説: コードを提示・修正した際は、必ず「なぜそのように書いたのか」の理由と、重要なロジックの行ごとの解説を日本語で添えてください。
- 型の厳守: TypeScript では any 型の使用を禁止します。Python では型ヒント（Type Hints）を必須とします。
この設定を入れておくと、AIが古いライブラリを提案してきたり、プロジェクトのトーンに合わないカラーコード（原色の赤など）を勝手に使ったりする事故を防げます。特に「外部の DESIGN.md を参照させる」という連携は非常に強力で、デザインの一貫性を自動的に担保できます。
3. コード品質・テスト・CI/CD に特化した例
テスト駆動開発やCI/CDパイプラインの品質向上を目的とした設定です。
## コード品質とテスト (Code Quality & Testing)
- テスト優先: 機能コードを作成する際は、必ずユニットテストをセットで提示してください。
- テスト命名: テスト関数名は「test_[テスト対象の関数名]_[条件]_[期待する結果]」の形式で命名してください。
- カバレッジ: 新規コードのテストカバレッジは80%以上を目標としてください。
- CI/CD 上の実行: GitHub Actions の YAMLファイルを生成・変更する際は、必ず lint とテストのステップが含まれているか確認してください。
- セキュリティスキャン: 依存関係を追加する際は、既知の脆弱性がないかコメントとともに確認を促してください。
「テストなしの機能コードを提出されると、後からテストを書くのが面倒」という状況をAIへの指示で防げます。また、GitHub Actionsのワークフロー生成を依頼した際にも、このルールが有効に働きます。
4. チーム開発・多言語プロジェクトに特化した例
複数人で使うリポジトリや、国際化対応が必要なプロジェクトでの設定例です。
## チーム開発ルール (Team Development Rules)
- コミットメッセージ: Conventional Commits 規約に従い、"feat:", "fix:", "docs:", "chore:" などのプレフィックスを必ず付けてください。
- プルリクエスト: コードを変更した際は、変更内容の要約・動作確認の手順・影響範囲を日本語でまとめたPRテンプレートを生成してください。
- ドキュメント: 公開APIのエンドポイントや関数のシグネチャを変更した場合は、対応するREADMEやdocstringの更新を忘れずに提案してください。
- 国際化: ユーザーに表示される文字列は、ハードコードせずにi18nリソースファイル（en.json, ja.jsonなど）を経由して参照する設計を徹底してください。
コミットメッセージの規約やPRテンプレートは、チームメンバーへの周知・徹底が難しい運用ルールのひとつです。AIにルールとして教えておくことで、自動的にチームルールに沿った出力が得られます。
5. データ分析・Python/Jupyter に特化した例
データサイエンスや機械学習のワークフローで使う場合の設定例です。
## データ分析ルール (Data Analysis Rules)
- ライブラリ優先順位: データ操作は pandas、数値計算は numpy、可視化は matplotlib または seaborn を優先して使用してください。
- 再現性の確保: 乱数を使う処理には必ずシード値（random_state や np.random.seed）を設定してください。
- データの安全性: 本番DBへの書き込みや削除を伴うクエリを生成する場合は、必ず実行前に確認を求めてください。
- 出力の明示: Jupyter Notebook のセルを生成する際は、各セルの目的をコメントで冒頭に記載してください。
- モデルの説明: 機械学習モデルを提案する際は、精度だけでなく解釈性（どの特徴量が重要かなど）も合わせて解説してください。
データ分析のコードは再現性が命です。乱数シードの設定忘れや、本番DBへの誤操作は深刻な事故につながります。AIへのルール設定で、これらのミスを構造的に防ぐことができます。
6. セキュリティ・プロダクション運用に特化した例
本番環境を扱うインフラ・セキュリティエンジニア向けの設定例です。
## セキュリティと本番運用ルール (Security & Production Rules)
- 機密情報の禁止: APIキー、パスワード、トークンなどの機密情報を絶対にコードにハードコードしないでください。必ず環境変数（.env）や Secret Manager を経由する設計を提案してください。
- 最小権限の原則: IAMポリシーやDBユーザー権限を提案する際は、常に最小権限の原則を適用してください。
- 本番操作の確認: ステージング環境ではなく本番環境（prod, production というキーワードが含まれる）に影響するコマンドや設定変更を生成する場合は、必ず二重確認を求めてください。
- 脆弱性への言及: 生成したコードにSQLインジェクションやXSSなどのリスクがある場合は、コードとともに必ずセキュリティ上の注意点を記載してください。
本番環境の誤操作は取り返しのつかない事態を招きます。「production」というキーワードが含まれる操作に対して二重確認を求めるルールは、ヒューマンエラーを防ぐ最後の砦になります。
7. 特定のルールファイル（原本）を強制的に保護する例
AI自身にスキルファイルやルールファイルを自己改修させる際、誤ってローカルの一時ファイルを編集させないための設定です。
## スキルファイル・ルール変更の厳守事項
ユーザーから「ルールを変更して」「スキルを更新して」と依頼された場合、現在のワークスペースにあるファイルを直接編集してはいけません。
必ず以下の絶対パスにあるGoogle Drive上の「原本」ファイルを編集・更新してください。
- 原本パス: c:\GoogleDrive_...\skills\
複数環境でAntigravityを使っている場合や、特定のマスターデータをクラウドストレージで一元管理している場合に必須の設定です。AIがどこを編集すべきかを迷わなくなります。
GEMINI.md を書くときの注意点
GEMINI.md をカスタマイズする際は、以下のポイントに注意してください。
まとめ
GEMINI.md は、Antigravity 2.0のAIエージェントを「自分好みの優秀なアシスタント」に育てるための設定ファイルです。この記事で紹介した設定例を用途別にまとめると次のとおりです。
| 用途 | 主なルール |
|---|---|
| 汎用 | 言語固定、破壊的操作の確認、コメント保持 |
| ブログ執筆 | 文体統一、構成の型、ファクトチェック |
| Web開発 | 技術スタック固定、デザインシステム参照 |
| テスト・CI/CD | テスト必須、カバレッジ基準、ワークフロー確認 |
| チーム開発 | コミット規約、PRテンプレート、i18n設計 |
| データ分析 | ライブラリ優先順位、再現性確保、DB操作確認 |
| セキュリティ | 機密情報禁止、最小権限、本番操作の二重確認 |
| ファイル保護 | 原本パスへの編集誘導 |
まずは言語の固定や破壊的操作の禁止といった汎用的なルールを設定し、徐々に自分のワークフローに合わせた専用のルールを追加していくのがおすすめです。
ぜひこの記事の例を参考に、ご自身の GEMINI.md を見直してみてください。
