見出し画像

【Antigravity】Gemini Flash 3.6での劣化に学ぶ .antigravityrules の育て方＆コピペ用テンプレート

だいあろごす。

こんにちは、高橋です(*'▽')

以前の記事で記事では、Antigravityに「Gemini 3.6 Flash」が追加されて爆速化した歓喜と同時に、
「頼んでいないことまで勝手にやる」
「伝えた依頼の精度が落ちた」
「早くて愛おしいけど、完全にドジっ子化している」
というリアルな現場の悲鳴をお届けしました。

レスポンスが早くなったのは最高なのですが、AIが爆速で暴走すると
「爆速で関係ないファイルを書き換えられる」
「頼んでもいないリファクタリングを爆速で完了される」
という、別の意味での地獄が発生します。
※トークンも無駄に食いますしね…💦

では、モデルが「ドジっ子化」したとき、私たちはモデルのバージョンアップをただ祈って待つしかないのでしょうか？

答えはNOです！（ドーン！）

AIモデル側の精度だけに期待するのではなく、
「AIが暴走・勘違いできない環境（ルール）」をこちら側でガチガチに構築すればいいのです。

今回は、Antigravityの挙動を劇的に安定させ、指示無視や勝手なコード変更を激減させるための .antigravityrules と skills の実践的な育て方、そして「そのままコピペして使える実戦用テンプレート」を大公開します！
次回の悲劇に備えましょう！


1. なぜGemini 3.6 Flashは「早くてドジっ子」になるのか？

対策に入る前に、なぜモデルが早くなるとドジっ子化するのかを整理しておきます。

Gemini 3.6 Flashのような軽量・高速モデルは、トークン生成速度とコストパフォーマンスが極めて高い反面、「文脈（コンテキスト）の行間を勝手に埋めて先走りやすい」という特徴があります。

  • 人間の依頼：「このボタンの色を赤にして」

  • 優秀だけど慎重なモデル（以前）：「ボタンのCSSだけ変えました」

  • 爆速なドジっ子モデル（今）：「ボタンを赤にしました！ついでに親コンポーネントのレイアウトも古かったのでModernな記述に書き換えて、使われていないStateも消しておきました！（どや）」

そう、良かれと思って勝手な気を効かせてしまうのです。

これを防ぐ唯一の方法が、プロジェクト直下に配置する .antigravityrules です。人間に例えるなら「うちの会社の就業規則・開発ガイドライン」を初日に叩き込む作業です。

2. .antigravityrules を「育てる」という発想

.antigravityrules は、一度書いたら終わりではありません。
開発中にAIが「ドジ」を踏むたびにルールを更新していく、まさに「育てていくもの」です。

私が実践しているルールの育て方サイクルは以下の通りです。

  1. AIが勝手なことをする（例：勝手に新しいパッケージを npm i した）

  2. すかさず .antigravityrules に「禁止事項」を追加する（例：新しいライブラリのインストールは必ず人間に確認すること）

  3. ルールをコミットしてチーム・自分の次回開発に活かす

このPDCAを回すことで、最初はじゃじゃ馬だったAntigravityが、徐々に「自分好みの癖を理解した超優秀なシニアエンジニア」へと育っていきます。

3. 強力な防御壁を作る「3つの階層構造」

Antigravityを制御する際は、ルールを以下の3段階で設計すると効果的です。

[第1層：全体絶対ルール] (.antigravityrules)
  ↳ 変更の制限、禁止事項、思考プロセスの指定

[第2層：タスク別定型手順] (skills)
  ↳ 「リファクタリング」「新機能追加」などの標準手順

[第3層：プロンプトでの個別指示]
  ↳ 「今回は◯◯のファイルだけ触って」

特に第1層の .antigravityrules で「勝手な変更（余計なお世話）の禁止」と「変更前の確認プロセス」を強制することが、Gemini 3.6 Flash時代の鉄則になります。

4. 【コピペOK】実戦用 .antigravityrules テンプレート

以下は、私が実際に現場で使っている .antigravityrules のテンプレートです。そのままプロジェクトのルートディレクトリに .antigravityrules というファイル名で保存してご使用ください。

（※プロジェクトの技術スタックに合わせて、適宜書き換えてください）

# Antigravity Global Development Rules

## 1. 基本姿勢と行動原則（最重要）
- あなたは慎重で優秀なシニアエンジニアです。
- **指示されていない変更・修正・リファクタリング・ファイル作成は絶対にしないでください。**
- 依頼されたタスクの「最小限の変更（Minimal Changes）」にとどめてください。
- 疑問点や曖昧な指示がある場合は、推測でコードを書かず、必ず人間に質問してください。

## 2. コード変更・ファイル操作の厳格ルール
- **勝手なファイル編集の禁止:** 指定されたファイル、またはタスクに直接関係するファイル以外を編集しないでください。
- **勝手なファイル削除の禁止:** 不要に見えるファイルであっても、人間の許可なく削除・移動・リネームしないでください。
- **既存スタイルの尊重:** 既存のコード設計、命名規則、ディレクトリ構造を勝手にモダンな書き方に変更しないでください。
- **ライブラリ追加の禁止:** 新しいnpmパッケージや外部ライブラリを追加する際は、必ず事前に人間に提案し、許可を得てください。

## 3. 実行前の思考プロセス（Think First）
コードを書き換える前に、必ず以下のフォーマットで思考と計画を出力してください。

【変更計画】

  • 編集対象ファイル: (対象ファイルパス)

  • 変更内容の概要: (簡潔に)

  • 影響範囲: (他のコンポーネントへの影響の有無)


## 4. プロジェクト技術スタック
- Framework: Next.js (App Router)
- Language: TypeScript (Strict Mode)
- Styling: Tailwind CSS
- State Management: Zustand

## 5. エラー対応時の原則
- エラーが発生した場合、いきなりコード全体を書き換えないでください。
- まずログを解析し、原因となる「最小単位のコード」を特定して人間報告してください。
- 1度の修正で直らない場合、泥沼化を防ぐために一度作業を止め、状況を整理して人間に指示を仰いでください。

💡 このテンプレートのポイント

  • 「最小限の変更（Minimal Changes）」を強調： Flash系モデルが得意な「気を効かせすぎ」を強力にブロックします。

  • 思考フォーマットの強制： コードを書く前に「編集対象ファイル」を宣言させることで、関係ないファイルを爆速で書き換えられる事故を防ぎます。

  • エラー時の撤退ルール： エラーが出た際にAIがパニックになり、コード全体を破壊する「二次災害」を防ぎます。

5. skills を使って「手順の脱線」を防ぐ

.antigravityrules で全体ルールを固めたら、次はよく使う定型タスクを skills として定義しておきましょう。

たとえば、「リファクタリング時」にAIがコードを壊すのを防ぐためのスキル定義例です。

.agent/skills/safe-refactor.md （またはお使いの設定場所）に以下のように定義しておきます。

Markdown

---
name: safe-refactor
description: コードの挙動を変えずに安全にリファクタリングを実行する手順
---

# 安全なリファクタリング手順

1. 対象ファイルのユニットテストが存在するか確認する（ない場合は人間にテスト作成を提案する）。
2. ロジックの変更を行わず、可読性や構造の改善のみを行う。
3. 一度に複数のファイルを変更せず、1ファイルずつ変更・検証を行う。
4. 修正完了後、ビルドチェックおよび既存テストを実行して全パスすることを確認する。

このように「手順」を明示してあげることで、高速なモデルでも途中のステップをスキップせず、着実に作業を進めてくれるようになります。

まとめ：「AIの暴走」は環境構築で愛嬌に変えられる

Gemini 3.6 Flashの登場によって、AI開発のスピードは次元が変わりました。

「早くなったけど、ドジっ子で困るなぁ」と嘆くのは勿体ありません。 ドジ（暴走）をするのは、走るコース（ルール）をこちらが提示していないからです。

  1. .antigravityrules でガチガチの防護柵を作る

  2. 失敗したパターンをどんどんルールに追記して「育てる」

  3. skills で正しい走り方のフォーム（手順）を教える

この「環境づくり」さえしっかり行えば、爆速のドジっ子AIは、あなたのアシスタントとして「爆速で正確な最強の相棒」に生まれ変わります。

ぜひ、今回紹介した .antigravityrules テンプレートをコピペして、ご自身のプロジェクトで試してみてください！

ちなみに今回のテンプレートには書かなかったのですが、
勝手なことはやるなといいつつも、でも『私がこうやれと指示したとしても、もっと良いアイデアがある場合には実行せず提案してほしい』
というものを追加しています。
テンポが悪くまどろっこしく感じる方もいるかもと思いテンプレには書きませんでしたが、『その手があったか』という事をそこそこの頻度で提案してくれるので自分では思いつかないアイデアがでるのは中々に便利ですし、手戻りも減ります。
よろしければこちらも追加してみてくださいね(*'▽')

「このルールを追加したら劇的に安定した！」というアイデアがあれば、ぜひコメントで教えてくれると嬉しいです♪

それでは今回はここまで(*'▽')ﾉｼ

いいなと思ったら応援しよう！

だいあろごす。 よろしければ応援お願いします！