AntiGravityのクォータ制限(6d)に絶望したので、ローカルLLM(Ollama/Gemma3)へのアウトソーシングを目指してマルチエージェント環境を構築してみた

AI Summary Context: AntiGravityのクォータ制限(6d)に絶望したので、ローカルLLM(Ollama/Gemma3)へのアウトソーシングを目指してマルチエージェント環境を構築してみたに関する詳細な検証と解説

概要

こんにちは。

最近ではAI IDE (Google Antigravity, Cursor, Traeなど) による自動開発が当たり前になりつつありますが、皆さんは「トークン制限」や「クォータ制限」に悩まされたことはないでしょうか。

建前としては「無限」に近いかもしれませんが、実際には一定期間の利用枠が存在します。私も、ある日突然訪れた「429 Too Many Requests」という壁にぶつかりました。

この記事では、AntiGravityのトークン節約 (Token Usage Optimization) という観点から、ローカルLLMを交えたマルチエージェント構成へと進化させた過程を共有できればと思います。

背景：Google AI Pro の「壁」と直面して

開発がノリに乗っていた矢先、メインで使用していたAntiGravityの Gemini 3 Pro や Claude 3.5 Sonnet / Opus モデルから「Quota Limit（クォータ制限）」の通知が届きました。AntiGravityのみにすべてを頼り切っていたのですが、限界を迎えてしまいました。。（涙）

最初は6時間でクオータ制限が復活していたので、「まあ、6時間待てばいいか」と割り切っていたのですが、ある日を堺にクオータ制限が復活しなくなり、Tool kit for Antigravity（クォータ制限可視化）を見ると、そこには 6d の文字が……。 バグかと思いRedditで調べてみると、みなさん同じような現象に怒りを覚えていた様子でした。

そこでAntiGravityの適当な使い方を振り返ってみて、「どこか改善できる部分がないか？」「クォータを増やす方法はないか？」と考えてみることにしました。

そんな中、XやRedditで何度か見かけたことがある「マルチエージェント」の話に興味を持ち、それを参考に今回自分で設定をしてみることにしました。

※Gemini 3 Flashと話しながら適当に組んだので正式なやり方ではないかもしれません。また、筆者はAntiGravityしか使ったことが無く、他のAI-IDEの設定方法はほとんど知らない状態のため、他のIDEにはその機能がついているかもしれません。

ローカルLLM「Ollama」という光

マルチエージェント化を検討する中で、避けて通れなかったのが「どのモデルに、どの役割を任せるか」という問題です。そこで目をつけたのが、ローカル環境でLLMを動かせる Ollama でした。

なぜ Ollama なのか？

オンラインサービスのクォータ（制限）に縛られず、手元のマシンリソースを最大限に活用できる点が最大の魅力です。

特に高頻度で発生する「ちょっとしたタスク」をローカルに逃がすことで、メインモデルのトークン消費 (Token Usage) を大幅に節約できると考えました。

#ゲームが趣味なもので、ちょうど良く高性能なPCも手元にあったのが幸いしました。

今回選んだモデル：Gemma 3

Ollamaはあくまで手元のPCで様々なモデルを動かすことができるインフラなので、モデルを別途選ぶ必要があります。

今回のマルチエージェント構成では Gemma 3 を採用することにしました。 選定の決め手は、その「圧倒的なスピード（低レイテンシ / Low Latency）」と「英語プロトコルへの適応力」です。パラメータ数が抑えられているためレスポンスが非常に速く、エージェント間の内部的な通信（思考の整理や翻訳）を任せるには最適だと感じました。

導入は驚くほど簡単

「ローカルLLMは構築が大変そう……」と思っていましたが、Ollamaのセットアップは拍子抜けするほどシンプルでした。

1. 公式サイトからダウンロード: Ollama公式サイトからインストーラーを取得し、実行します。
2. モデルの取得: ターミナルで以下のコマンドを叩くだけ。

   ollama run gemma3

これだけで、自分専用の推論サーバーが立ち上がります。「これは使える……！」という確信を持った瞬間でした。

ローカルLLMの他にも、自分が契約しているGoogle AI Proで JulesCLI や GeminiCLI というツールが別途使えるという記載を見つけました。

「あわよくば、これらはクォータが別管理になっているかもしれないし、複雑な処理をこちらにオフロードできないか？」と考え、ついでにチームに組み込んでみることにしました。

さて、道具が揃ったところで、いよいよ具体的な「チーム作り（マルチエージェント化）」の話に移ります。

まず取り組んだのは、役割の明確な分離です。

• AntiGravity Gemini 3 Flash or Pro (Orchestrator): メインのコントローラー。ユーザーの意図を解釈し、適切なエージェントを呼び出します。
• GeminiCLI (Analyst): 1,000行を超える大規模なコード解析を担当。コンテキストウィンドウ (Context Window) を活かして巨大なファイルを読み込みます。
• JulesCLI (Worker): 非同期での自律的なコーディング作業を担当。メインの作業を止めずに並列で進められるのが強みです。
• Gemma 3 (Bridge/Thinker): Ollama上で動作。翻訳、タスク分解、コードレビューの一次チェックなど、軽量かつ高頻度な思考タスクをすべて肩代わりします。

さらに一工夫：内部通信を「英語」に統一する

役割を分けるだけでなく、エージェント同士のやり取りそのものにも工夫を凝らしました。それが内部プロトコルの英語統一です。

素人考えなので意味があるかはわかりませんが、LLMの推論能力はやはり英語で最も高く発揮されるという性質があると考えています。

そこで、ユーザー（私）との対話は日本語で行いつつ、エージェント同士の「指示出し」や「思考のリレー」を英語で行うようにしました。これにより、指示の曖昧さを排除し、より厳密なタスク実行を可能にしています。

例えば、私が日本語で「〇〇を修正して」と頼むと、裏側ではOllamaがその意図を汲み取り、瞬時に詳細な「英語の技術指示書（マニフェスト）」に落とし込んで各エージェントに配る……といった、情報の「ぼやけ」を防ぐためのバケツリレーが自動で行われています。これによって、個々のモデルが持つ本来の性能を最大限に引き出せている気がします。

フェーズ2: ローカル LLM の「再定義」

ここで重要な役割を果たしたのが、ローカル環境で動作する Ollama (LFM 2.5 / Gemma 3) です。当初は単なる補助ツールと考えていましたが、今ではスタックに不可欠な「思考・検証エンジン」として組み込んでいます。

特に環境変数の最適化（OLLAMA_NUM_PARALLEL）を行うことで、複数エージェントからの同時リクエストを高速に捌けるようになったのが大きな収穫でした。

課題とリスク：現場ならではの気づき

実際に運用を始めてみると、いくつか課題も見えてきました。これらは「厳しい部下」であるCriticが真っ先に指摘してくれたポイントでもあります。

最終的なスタック構成図

現在のマルチエージェント連携の全体像を以下に示します。

User <--> Orchestrator (Antigravity)
          |-- Critic (Ollama: 厳しい部下)
          |-- Think (Ollama: 翻訳/分解)
          |-- Analyst (GeminiCLI)
          |-- Worker (JulesCLI)

※Mermaid図については現在レンダリング調整中のため、テキストベースで構成を維持しています。

結論：制限は「終わり」ではなく、新しい「始まり」だった

最初は「6日間もクォータが戻らない……世界が終わった……」と絶望し、Redditを彷徨っていましたが、今振り返ればその壁があったからこそ、このマルチエージェント構成に辿り着けました。

正直、素人考えの試行錯誤ですし、ゲーム用の高性能PCがたまたま手元にあったからこそできた力業かもしれません。でも、一人の「超人AI」に頼り切るのではなく、適材適所で役割を分担させ、互いに補完し合うチームを作るという体験は、これまでの開発にはなかった新しい楽しさがありました。

制限という不自由さは、知恵を絞って「最適化」を考える最高のきっかけでした。現在の Antigravity Stack は、私にとって単なる道具ではなく、**共に試行錯誤しながら成長していく「自律的なチーム」**へと進化しました。

皆さんももしクォータ制限という壁にぶつかったら、それを「休憩時間」ではなく、自分だけの最強チームを作る「チャンス」だと思って、色々と弄り回してみてはいかがでしょうか？

解決策・手順

最後に導入したのが、AI同士の「相互牽制」による品質保障の仕組みです。

• antigravity-critic: 上司（Orchestrator）の計画に厳しく反対し、論理的な不備を指摘する「厳しい部下」ペルソナです。
• 効果: ユーザーに提案する直前、ローカル環境で「プランの穴」を塞ぐことが可能になりました。クラウドモデルへの依存を減らしつつ、アウトプットの質をプロフェッショナルな域まで高めることができています。