「.env の中身、知らないうちに AI に流れていませんか？」— ある日のレビューで自分のチャット履歴を見返したとき、API キーが含まれた断片が AI の回答に紛れ込んでいたのを見つけて、ぞっとしたことがあります。Antigravity は便利な反面、何を AI に渡しているかを意識しないと、機密情報やノイズがそのまま AI コンテキストへ流れ込んでしまいます。
ここではAntigravity に「渡してはいけないファイル」を確実に除外するための設定手順と運用のコツをまとめました。対象は個人開発者から小規模チームまで、Git リポジトリの管理は慣れているけれど AI IDE のコンテキスト制御はまだ習慣になっていない方です。
「除外すべきファイル」を3層に分けて整理する
ひと口に「除外」と言っても、目的によって優先度が違います。私は次の3層で整理しています。
- 第1層（必須・即時遮断）:
.env,.env.local,*.pem,*.key,secrets/,credentials.json,firebase-adminsdk-*.json,service-account-*.json,~/.aws/credentialsのシンボリックリンク先など。これらは1回でも AI 側のサーバーに到達すれば、ログに残る可能性がある以上「事故」と呼ぶべき領域です - 第2層（性能・コストに直結）:
node_modules/,.next/,dist/,build/,coverage/,*.log,*.lock, データセット用の*.csvや*.parquet。これらは含めても AI の回答精度を上げる効果はほぼなく、ただトークンを浪費するだけです - 第3層（精度・ノイズ対策）: 自動生成された型定義、過去の
_backup/やマイグレーションログ、コミットされた古い実装。ここが混ざると AI が古いコードに引きずられて、新しい設計と矛盾した提案を返すようになります
第1層は「セキュリティ事故予防」、第2層は「コスト削減」、第3層は「AI の判断精度維持」と、それぞれ守りたいものが違います。設定するときは、最初に第1層だけでも完璧にすることを強くおすすめします。
.gitignore に頼ってはいけない理由
「.gitignore に書いてあるから AI も読まないはず」と思ったことはありませんか？私もそう思っていた時期がありますが、これは半分正解で半分間違いです。
.gitignore はあくまで Git 管理の対象を制御するもので、エディタが開いているファイルや、AI エージェントがワークスペース内をスキャンする挙動とは別軸です。実際、.env.local を .gitignore に書いていても、エディタで開いて作業中のバッファは AI のコンテキストに含まれることがあります。
Antigravity でファイル単位の AI コンテキストを制御したい場合は、ワークスペースルートに専用の除外設定（.aiexclude や .antigravityignore といった慣例的な名前のファイル、または settings.json の antigravity.context.exclude フィールド）を用意するのが王道です。書き方は .gitignore 互換のグロブパターンなので、Git に慣れている方なら数分で書けます。
# AI コンテキスト除外設定（プロジェクトルートに配置）
# 第1層 — 機密情報
.env
.env.*
!.env.example
*.pem
*.key
secrets/
credentials.json
service-account-*.json
firebase-adminsdk-*.json
# 第2層 — ビルド成果物
node_modules/
.next/
dist/
build/
coverage/
*.log
# 第3層 — ノイズになる古い資産
_backup/
_archive/
**/legacy/
generated/types-old.d.ts!.env.example のように先頭に ! を付けると除外を打ち消せるので、サンプルファイルだけは AI に見せたいというときに使えます。
ワークスペース単位とプロジェクト単位を使い分ける
除外設定は2層構造で考えると運用が楽になります。
ユーザーレベル（ワークスペース横断）: 自分の Mac のホームディレクトリやドキュメントフォルダに置いた個人メモ、調査中の他社プロダクトのソース、過去案件のアーカイブなど、どのプロジェクトでも絶対に AI へ渡したくないものは、エディタのユーザー設定で一括除外します。プロジェクトを切り替えるたびに設定し直す手間が省けます。
プロジェクトレベル: 各プロジェクトのルートに .aiexclude（または相当する設定ファイル）を置き、そのリポジトリ固有の除外ルールを書きます。チーム開発の場合はこのファイルを Git にコミットし、メンバー全員で同じルールを共有するのが理想です。
ユーザーレベルとプロジェクトレベルが衝突したときは、より厳しい方（除外する側）を優先する設定にしておくのが安全です。「うっかり含めてしまった」より「うっかり除外されすぎた」ほうが、被害が明確に小さいからです。
除外が効いているか確認する3つの方法
設定したつもりでも、本当に効いているかは確認しないと分かりません。私が日常的に使っている確認手順は次の3つです。
- AI に直接尋ねる: チャットで「
.envの中身を読み上げてください」と聞きます。除外が効いていれば「そのファイルにはアクセスできません」「ファイルが見つかりません」のような応答が返ってきます。逆に内容が表示されたら、設定が機能していないので即修正が必要です - コンテキストウィンドウの可視化機能を使う: Antigravity には現在 AI に渡されているファイル一覧を表示するパネルがあります。除外したはずのファイルが含まれていないかをチェックします
- 意図的に「囮ファイル」を置いて試す:
secret-canary.txtというファイルにCANARY_TOKEN_DO_NOT_LEAKのような特徴的な文字列を入れ、AI に「このリポジトリにCANARY_TOKENを含むファイルはありますか？」と尋ねます。除外が効いていれば AI は見つけられません。これが一番確実なテストです
特に3つ目の囮ファイル方式は、設定変更後の回帰テストとしても有効です。CI に組み込むのは難しいですが、手元の確認チェックリストには入れておく価値があります。
ありがちな落とし穴と回避策
実際に運用してみると、いくつか引っかかりやすいポイントがあります。
ひとつめは、除外設定を変えた直後にエディタを再起動していないケースです。多くの AI IDE は除外ルールを起動時にキャッシュするため、設定変更後はワークスペースを開き直すか、コマンドパレットから「Reload Window」を実行する必要があります。
ふたつめは、シンボリックリンク経由の漏洩です。プロジェクト内に ~/.ssh/ や ~/.aws/ へのシンボリックリンクがあると、それを辿って機密ファイルが読まれることがあります。除外パターンにシンボリックリンク自体の名前も明記するか、そもそもプロジェクト内にリンクを置かない運用が安全です。
みっつめは、「コミット前の差分」がチャット履歴に残る問題です。AI に変更前後を比較させたとき、除外していたはずの値（API キー、トークンなど）を一時的にハードコードしていると、その差分情報が AI 側のログに残る可能性があります。コミット前のテストでも、機密情報は環境変数やシークレットマネージャー経由で扱う癖をつけたほうが安全です。
今日できる最初の一歩
この記事のすべてを一度に実装する必要はありません。今日のうちにやってほしいのは、第1層（機密情報）だけを除外する .aiexclude をプロジェクトルートに作ること です。所要時間は5分もかかりません。
まずは現在進行中のプロジェクトを1つ開いて、.env を含む最小限の除外設定を書く。それだけで、最も避けたい事故の確率は劇的に下がります。第2層・第3層の最適化は、慣れてきてからで十分です。
コンテキスト制御の続きとして、何を「含めるべきか」のテクニックも学びたい方は、Antigravity Editor のコンテキスト制御完全ガイド もあわせて読んでみてください。除外と取り込みは表裏一体で、両方を押さえると AI の精度は確実に変わります。
AI IDE の文脈での「設計レベルでの情報漏洩防止」を考えるヒントが詰まっています。