Google Antigravity のルール：全体とプロジェクトの指示を設定する

Antigravity のルールとは何ですか

Google Antigravity のルールは、エージェントがファイルから見つけ、関連する作業で参照する永続的な指示、コーディング規約、設計上の制約です。チャットの指示は通常、その会話だけに適用されます。ルールは保存されたコンテキストとして、Antigravity が見つけられる範囲内で後の会話にも影響します。毎回説明している判断、たとえば実行するテスト、生成ファイルの扱い、データベースの規約を残すのに向いています。

使いやすいルール設定では、対象となる作業、エージェントが取るべき行動、守るべき境界を明確にします。実行に移せる程度に具体的で、レビューできる長さに保ちましょう。ルールを追加しても、あらゆるコマンドや外部操作が自動的に許可されるわけではありません。変更案、シェルコマンド、ネットワーク、秘密情報、破壊的な操作は、これまでどおり自分の確認手順で点検してください。

• チャット指示 現在の会話に向けた一度限りの依頼です。
• ルール 対応するファイルと範囲から読み込まれる永続的な指示です。
• Skill 作業手順と補助リソースをまとめて再利用する仕組みです。詳しくは Antigravity Skills ガイドを参照してください。

全体、ワークスペース、ディレクトリの範囲を選ぶ

必要な人やプロジェクトをすべて含む範囲のうち、最も狭いものを選びます。グローバルルールはユーザープロファイルに沿ってワークスペース間で使われるため、どの場所でも安全な個人の好みに限るのが適切です。ワークスペースルールはリポジトリと一緒に管理でき、チームがコードと合わせてレビューできます。大きなプロジェクトの一部だけに別の規約が必要なら、ディレクトリルールが役立ちます。

Google Antigravity のルールは累積して適用されます。新しいファイルが過去の指示を置き換えるのではなく、検出された指示が組み合わされます。競合するときは、より具体的なディレクトリのルールが優先されます。グローバル設定とリポジトリ設定が矛盾しないようにし、ローカルな例外がある場合はルール内で明記しましょう。表は Antigravity App 向けに現在案内されている保存場所です。

Antigravity App でルールを作成する

Antigravity App では、アプリのメニューまたはプロジェクト設定から Customizations パネルを開き、Rules タブを選びます。必要な範囲に合わせて + Global または + Workspace を選択してください。App がファイルベースのルールを作るので、保存後に内容を確認して編集できます。IDE や CLI では操作画面が異なる場合があるため、公式に案内された保存場所と各利用面の手順を確認しましょう。

リポジトリ用ルールは、大きな方針を並べるより、繰り返し発生する判断を一つ選んで始めます。対象のファイルや作業、従うべき行動、結果の確かめ方を書きます。「慎重に進める」のような曖昧な表現より、「パーサーを変更したら関連する単体テストを実行する」のような検証可能な指示が有用です。プロジェクト固有の事実はリポジトリで管理し、他の開発者もコードと一緒に確認できるようにします。

1. 範囲を選ぶユーザープロファイル、ワークスペース、サブディレクトリのどこに指示を置くか決めます。
2. Rules を開くApp の Customizations から Rules に進み、Global または Workspace の項目を作ります。
3. 行動を一つ書く目的、適用対象、必要な行動、確認方法を簡潔に明記します。
4. 保存ファイルを確認する保存先を確認し、ルールに頼る前に最終的な文章を読みます。

Frontmatter と起動モードを設定する

単独の AGENTS.md と GEMINI.md は frontmatter を使いません。Markdown の内容がそのディレクトリ範囲で継続して有効になります。rules/ 内のモジュール型 Markdown ファイルは YAML frontmatter で始まり、正しい trigger を宣言する必要があります。trigger はルールがコンテキストに読み込まれる条件を決めるため、対象作業がどれほど頻繁か、いつ判定できるかに合わせて選びます。

always_on は範囲内のすべてのターンに必要な短い指示向けです。model_decision は、説明がタスクと一致したときだけ詳しい内容を参照させる用途に適しています。glob はファイルパターンに応じて起動し、必須の globs フィールドを指定します。manual は @ で明示的に呼び出したときだけ読み込む設定です。現在のドキュメントには、この四つの trigger 値が記載されています。

---
trigger: glob
globs: "*.ts, *.tsx"
description: "TypeScript ファイルを変更するときにこの規約を適用する。"
---

# TypeScript の変更

- export する関数に型を付ける。
- 編集後に対象を絞った TypeScript テストを実行する。
- 生成ファイルを手で変更しない。

ルールが適用されたかを確認する

ファイルを保存しただけでは、意図したルールが読み込まれた証拠になりません。範囲と明確に一致する、小さくリスクの低い依頼で動作を確かめます。glob ルールならパターンに一致するファイルと、一致しない近いファイルの両方で試します。manual ルールは一度 @ で明示して呼び出し、呼び出さない場合と結果を比べます。ルールによる変化を観察できるようにタスクを絞りましょう。

結果を確認するときは、エージェントが全般的に慎重になったという印象ではなく、ルールで指定した具体的な振る舞いを探します。変更されたファイルと実行コマンドを確認してください。期待した動作がない場合は、パス、ワークスペースのルート、frontmatter の綴り、trigger、glob パターン、より具体的なルールとの競合を順番に調べます。一度に一つの原因を変更し、同じテストを繰り返すと修正の効果が分かります。

1. 明確なタスクを選ぶルールの影響が分かる小さな依頼を使い、危険な変更は避けます。
2. 境界を確かめるファイル単位のルールでは、一致するファイルと一致しないファイルを比べます。
3. 証拠を見る応答、コマンド、変更ファイル、テスト結果をルールの内容と照らし合わせます。
4. 編集後に再確認する範囲または trigger の一箇所を変更して同じテストを再実行します。

ルールの問題を解決し、内容を保守する

Google Antigravity のルールが無視されるように見えたら、まずファイルが現在のワークスペースと対応する保存場所にあるか確認します。次に正確なファイル名、.agents の表記、YAML の区切りとインデントを点検してください。モジュール型ルールに有効な trigger がなければ、意図どおり読み込まれないことがあります。glob ルールは一致することが分かっているパスで試し、パターンの引用方法も確認します。manual ルールは自動起動しないため、@ で明示的に呼び出します。

ルールにはコンテキスト量の上限もあります。ドキュメントによると、ファイル取り込み後の各ルールファイルは 24 KB に制限され、アクティブなグローバルルールと always_on ルールは合計 20,000 トークンの予算を共有します。総量を超えると、最も大きいルールがパスと説明だけの参照に置き換えられる場合があります。always_on は短く保ち、長い資料は model_decision に移して、どんな作業で参照すべきか description に書きましょう。