【警告】Antigravityへの「丸投げ」は危険?トークン枯渇を防ぐハイブリッド運用術

2026年3月11日

【警告】Antigravityへの「丸投げ」は危険?トークン枯渇を防ぐハイブリッド運用術

こんにちは、てつです! 2026年3月現在、AIは私たちの日常に深く浸透し、ブログ運営においても強力なパートナーとなりつつありますよね。 特にGoogleの「Antigravity(アンチグラビティ)」のような高度なAIエディタは、その圧倒的な便利さで作業効率を劇的に向上させてくれます。

しかし……その便利さに盲目的に頼りすぎると、思わぬ落とし穴に嵌ることがあります。 今回は、私が自作ブログの運用で実際に経験した 「Antigravityのトークン消費問題」 と、そこから見出した 「解決策(ハイブリッド運用術)」 についてお話しします。

「全部お任せ」の代償:ある日突然のロックアウト

最近、Antigravityを使っていて「あれ、まだそんなに使ってないのに、もう制限がかかったの?」と感じることが増えました。

私のブログはGitHubで管理しているのですが、記事が増えるたびにAntigravityに「画像圧縮して、CommitしてPushまでやっといて!」と、カスタム指示で 完全に丸投げ していたんです。 最初は魔法のように快適だったのですが、記事数が積み重なるにつれ、Antigravityが裏側で「リポジトリ全体の整合性」を確認するために凄まじい量のトークンを消費していることに気づきました。

便利さに甘えた結果、 「7日間制限」 という隠れた壁に思い切りぶち当たってしまったのです(泣)。

この現象は、以前書いた以下の記事で触れた「AIの予期せぬ挙動による利用制限」と似た側面があります。 AIの「思考」プロセスはブラックボックス化しているため、ユーザー側からは見えない部分で大量のコンテキスト(文脈)を読み込み、トークンを激しく消費してしまうんですね。

https://tetsu-blog.net/posts/gemini-infinite-loop-prevention/

私が踏んだ「3つの落とし穴」


私の実体験から分かった、自作ブログ運用におけるAntigravityのトークン消費に関する罠は、大きく以下の3点です。

落とし穴①:AIに「空気を読ませよう」としたこと

「いい感じに更新して」という曖昧な指示は、AIにとって 「全ファイルをスキャンして空気を読め」 と言っているのと同じでした。

特にブログのようにファイル数が多く、それぞれが独立した文脈を持つ場合、AIは指示のたびにリポジトリ全体を読み込もうとします。仮に記事が100記事あれば、100ファイル分の読み込みが発生してしまうわけです。 AIは人間のように「なんとなく察する」ことはできません。具体的な指示がない限り、可能な限りの情報を参照しようとする特性があるんです。

落とし穴②:画像圧縮とGit操作の自動化

これが一番の罠でした。 私は「画像圧縮→Commit→Push」を一貫してやらせていましたが、Antigravityは「安全にPushできるか」を確かめるために、毎回プロジェクト全体を舐めるようにスキャンします。

Gitリポジトリの整合性チェックは、AIにとって非常にコストのかかる処理です。毎回リポジトリ全体のRAG(検索拡張生成)を行わせるようなもので、これだけで利用枠の半分以上を溶かしていました。 特に画像ファイルなどのバイナリデータは、テキストデータに比べて処理の負担が大きくなってしまいます。

落とし穴③:過去記事の放置

2025年後半に書いた古い記事。実はこれらも、Antigravityにとっては「今の文脈」の一部として扱われていました。

例えば、私が定期的に投稿している「FXスワップ運用報告」のような記事が増えるほど、AIがスキャンする対象はどんどん増大します。 触る必要のない過去ログが、今の貴重なトークンを食いつぶしていたのです。明示的に除外しない限り、AIはすべてを等しく扱おうとしてしまうんですね。

「トークン節約」のために変えた私の運用

制限を回避しつつ、効率も落とさないために、現在は以下の 「ハイブリッド運用」 に切り替えました。

「視界」を限定するSkillの活用(this と all)

チャット欄にただ「〜して」と打つ代わりに、AIに与えるコンテキスト(読み込む範囲)を明示的に制御するSkillを導入しました。 具体的には、現在開いているファイルのみを参照させる @this と、プロジェクト全体を参照させる @all を明確に使い分けます。

スキル @this (トークン節約モード) @all (全体最適化モード)
対象範囲 現在開いているファイル1つだけ リポジトリ全体
トークン消費 最小 多い
主な用途 記事の執筆、誤字修正、文章校正、特定ファイルの画像圧縮など サイト全体のリンク切れチェック、カテゴリの統一、全体デザインの提案など
ルール 他のファイルを探索(スキャン)することは禁止。推測するかユーザーに質問する。 必要に応じて全ファイルをスキャンし、サイトマップやインデックスとの整合性をチェックする。

簡単に言うと、@this は「このファイルだけ見て」、@all は「全部見て」 という指示になります。 普段のブログ執筆や修正では徹底して @this を使い、サイト全体の構成を見直したい時など、本当に必要な場面でのみ @all を使うようにしました。 (@all を使う場合でも、.antigravityignore というファイルで不要な過去記事などは徹底的に除外しています)

これにより、不要なトークン消費を劇的に削減できました!

プッシュは「GitHub Desktop」で1クリック(人間の介入)

もう一つの大きな変更点は、GitへのコミットとプッシュをAIから取り上げた ことです。

画像の圧縮自体はAIに @this スコープで実行させますが、その後のGit操作は自分で「GitHub Desktop」などのツールを使って行うようにしました。 AIに「Gitの状況を考えさせる」コストをゼロにすることで、 予期せぬトークン消費やリポジトリの整合性チェックによるオーバーヘッドを完全に排除 できます。

AIに複雑なワークフローをすべて丸投げするのではなく、「人間が介入すべきポイント(バージョン管理など)」を明確にすることで、リスクを低減できる良い例だと実感しています。

まとめ:AIとの上手な付き合い方

Antigravityは本当に素晴らしいツールですが、「何でもできるからといって、何でもやらせていいわけではない」 ということを今回身をもって学びました。

AIの「視界」をコントロールし、得意な作業(テキスト生成や単一ファイルの処理)に集中させ、管理や判断が必要な部分は人間が引き受ける。この ハイブリッドな運用 こそが、現在のAIツールを最もストレスなく、かつ最大限に活用するコツだと思います。

皆さんは、AIツールを使っていて「あれ、思ってたよりすぐ制限かかっちゃったな…」と感じたことはありませんか? もし心当たりがあれば、ぜひAIへの「丸投げ」を見直して、今回ご紹介した「視界のコントロール」を試してみてくださいね!

あわせて読みたい