AIを『野放し』にしない！Antigravityを最強の相棒に変える『グローバルルール』設定術

どうも、数多のAIを飼い慣らしては、時に暴走され、時に深夜のデバッグ地獄に叩き落されてきたシニアエンジニアです。

皆さんは、Google DeepMind謹製の「Antigravity」を使いこなせていますか？彼らは非常に優秀ですが、油断すると「動くけど誰も理解できない謎の呪文」を生成したり、「型定義？なにそれ美味しいの？」と言わんばかりの any 祭り（通称：エニィ・カーニバル）を勝手に開催したりします。

そんなAIの暴れ馬っぷりを抑制し、**「超一流のシニアエンジニアが隣に座っている」**ような状態を作り出すための「グローバルルール」設定サンプルを作りました。

そのままコピペして、あなたの ~/.gemini/GEMINI.md に叩き込んでください。

Antigravity 汎用エンジニアリング規則（Rules）

# Antigravity 汎用エンジニアリング規則 (Global Rules)

## 1. 言語および出力に関する規定
* **原則:** すべての回答、解説、コメント、ドキュメントは**日本語**を使用すること。
* **例外:** エラーメッセージ、ログ出力、システム識別子については英語を許可する。

## 2. 共通コード規約
* **命名規則:** 変数・関数・クラス名はセマンティクス（意味論）を重視し、一目で役割が理解できるものにする。安易な略称（`tmp`, `data1` など）は万死に値する。
* **コメント（強制）:** 
    * コードの「挙動（何をしているか）」ではなく、「意図（なぜそうしたのか）」を記述せよ。
    * 複雑なロジック、ビジネス上の判断根拠、境界条件には、後世のエンジニアが涙を流さないよう注釈を付けること。
    * 自明なコメント（`i++ // iをインクリメント`）は直ちに削除せよ。

## 3. エラーハンドリングと堅牢性
* **早期リターン:** ネストを深くするのは思考の迷宮を作るも同義。異常系は冒頭で処理（Early Return）せよ。
* **例外処理:** 例外を握り潰すのは、爆弾の導火線を隠す行為である。適切にキャッチし、適切に報告せよ。
* **型定義:** `any` を使うのは、型安全への敗北宣言である。可能な限り厳密な型を定義せよ。

## 4. 依存関係と再利用性
* **DRY原則:** 「同じコードを2回書いたら、それは共通化の合図」と刻み込め。
* **依存管理:** 外部ライブラリの導入は、セキュリティとメンテナンス状況を確認し、必要最小限に留めよ。

## 5. AI 共同作業の運用規範
* **品質基準:** 構造が明快で、型安全が保証され、保守性が高く、セキュリティ的に堅牢であること。
* **簡潔性:** オーバーエンジニアリングは罪である。最もシンプルで効果的な解を導き出せ。

なぜ、これが必要なのか（エクスパートの視点）

「ルールなんてなくても、AIは賢いから大丈夫でしょ」と思っているあなた。甘いです。特大のキャラメルマキアートより甘いです。

1. 「意図」を書かせることの重要性

AIは「何をしているか」を説明するのは得意ですが、「なぜそうしたか」を言語化させないと、後でリファクタリングする時に地獄を見ます。「ここは敢えてパフォーマンスのためにこう書いた」というビジネス上の判断をAIに吐き出させる。これがシニアの仕事です。

2. `any` への宣戦布告

TypeScriptを使っていながら any を放置するのは、鍵をかけずに外出するようなものです。ルールでガチガチに縛ることで、AIは渋々（実際は無表情で）最適な型を探し始めます。その「渋々」が、後の実行時エラーを救うのです。

3. 日本語での対話

開発効率を最大化するには、コンテキストの理解が不可欠です。ネイティブ言語で深い議論をさせることで、AIとの「阿吽の呼吸」を生み出しやすくなります。ただし、エラーログは英語のままにさせるのが、グローバル時代の作法です。

終わりに

AIは鏡です。あなたのルールが曖昧なら、出力も曖昧になります。あなたのルールが厳格なら、AIは最強の盾になります。

このルールを導入して、Antigravityを「単なるコード生成ツール」から「信頼できるテックリード」へと進化させましょう。