🤖

AntigravityとローカルLLMをMCPで繋ぐ！完全無料でクオータを99%削減する連携術

に公開
Obsidian
Model Context Protocol
Ollama
Qwen
Gemini
tech

はじめに

生成AIをヘビーに使い倒す開発者や学習者にとって、最大の敵は「APIクオータ（利用制限）の枯渇」ではないでしょうか。

私はAIアシスタント「Antigravity（Gemini）」の優秀な対話UI（特に出力に対してピンポイントでコメントできる機能）が大好きで、思考整理やブログの下書きに使い込んでいました。

しかし、過去の学びやプロフィールなどの「前提情報」をObsidianにストックし、それを裏でAIに読み込ませて対話しようとすると、一瞬でクオータ制限に達してしまうという問題に直面しました。

この問題を解決するため、クラウドAIとローカルLLMを「MCP（Model Context Protocol）」で接続し、「1つの画面で完結させながら、クオータ消費を極限まで削る」ハイブリッド環境を構築しました。その設定手順と効果を共有します。

1. モチベーション：大好きなAntigravityのUIで、クオータを節約したい

  • 実現したかった理想
    • 対話から得た気づきや「学び（学んだ事実、思ったこと、チャレンジしたいこと、アイデア）」を、前提説明の手間なくスムーズにObsidianに蓄積して脳を育てること。
    • 何よりも「出力された原稿にピンポイントでコメントを入れ、対話しながら磨き上げていく、Antigravity独特の素晴らしいUI機能」を守り抜くこと。
  • 直面した課題
    • 前提知識となるファイルをクラウドAI（Gemini）に読み込ませる（読書させる）と、チャットの往復のたびに全テキストをクラウド側で再処理するため、一瞬でクオータ制限に達してしまう。

2. やったこと：OllamaとMCPによる接続設定

構築の手順は非常にシンプルで、以下の3つのステップで完了します。

ステップ 1：OllamaとローカルLLMのインストール

ローカルPCに Ollama をインストールし、ターミナルから以下のモデルをダウンロードします。

# 快速型：日常の検索・簡単な要約用
ollama pull qwen2.5:7b

# 熟考型（Reasoning）：ディープな分析用
ollama pull qwen3.5:9b

ステップ 2：MCP中継サーバーの登録

AntigravityとOllamaを接続するため、中継用のコンセントとしてオープンソースの @iflow-mcp/ollama-mcp を使用します。

ステップ 3：mcp_config.json の編集

AntigravityのMCP設定ファイル（mcp_config.json）に、以下の設定を追加してアプリを再起動します。

{
  "mcpServers": {
    "ollama": {
      "command": "npx",
      "args": [
        "-y",
        "@iflow-mcp/ollama-mcp"
      ]
    }
  }
}

3. 成果：クラウドのインプット量を削り、クオータを99%削減する

本ハイブリッド環境のキモは「司書（ローカルLLM）」と「作家（Antigravity）」の役割分担にあります。

  • 司書（快速ローカルモデル Qwen2.5:7b）：
    PC内の数万文字のファイルをローカルで全量読書し、必要なエッセンスだけを数百文字のダイジェストに濃縮する（ローカル処理のため、クオータ消費は完全0）。
  • 作家（クラウドAI Antigravity）：
    司書が届けてくれた数百文字のダイジェスト（メモ用紙1枚）だけを読み込み、高度な清書を行う。

トークン消費（クオータ）の期待効果

クラウドAIに投げるインプット文字数を「何万文字」から「数百文字」へと劇的に圧縮したため、毎往復のインプットにかかるクラウド側のクオータ消費を**【約99%削減する想定】**が成り立ちます。

Geminiによる削減率シミュレーション

  • 従来の全量読書: 2万トークンのノート × 10往復 ＝ 合計20万トークン 消費。
  • ハイブリッド連携: Qwenがまとめた200トークンの要約 × 10往復 ＝ 合計2,000トークン 消費。（※インプット消費トークン量を約99%削減）

4. 試行錯誤とブレイクスルーの軌跡

ここに至るまでには、多く試行錯誤をして寝不足になりました（ご笑納ください）。

  • 失敗 ①：ハルシネーションの罠
    • AIから「Ollamaを入れれば、Antigravityの画面上のプルダウンからQwenを選んで動かせます！」と回答され、それを信じて半日を無駄にし、クオータを使い果たすデッドエンド（のちにハルシネーションであることをGemini自身から告げられる）。
  • 失敗 ②：拡張機能の互換性チェックエラー
    • エディタ版のAntigravity IDEへ移行するも、これもGeminiに勧められたローカル連携ツール（Continue）の互換性エラーに阻まれ、インストール拒否。
  • 失敗 ③：VSCodeへの移行という「妥協」への抵抗
    • 「VSCodeにRoo Code拡張機能を入れてAIエージェント化するしかない」と勧められ、移行する寸前まで行く。しかし、大好きなAntigravityのUI画面を絶対に手放したくないため、寝る前にギリギリで踏みとどまる。
  • ひらめきのブレイクスルー
    • 諦めて寝る前の最後のプロンプトで対話している際、AntigravityにローカルLLMを操作されるアイデアが出力された。
    • 友人から聞いていた「最近は高機能なAIから低レベルなAIにタスクを割り振れるらしい」という噂と、以前Obsidian連携で学んでいた「MCP」の知識が脳内で結びついた。
    • すべてをローカルLLMに任せるのではなく「Antigravity（クラウド）から、使い慣れたMCPを介してローカルLLMに指示だけ出し、UIとしてはAntigravityを使い続けられるのではないか？」と気づいたことで、今回のハイブリッド要約連携が誕生した。

5. まとめと今後の展望

偶然のひらめきと既存の知識が重なったことで、妥協せず大好きなAntigravityのUI画面を守り抜いたまま、クオータを劇的に削減できる理想の環境が完成しました。

今後は、以下のステップでこの環境を育てていく予定です。

  1. 実クオータ削減率の検証：運用しながら、実際にどれほどクオータ消費が抑えられているか経過を追う。
  2. PCスペックの壁とモデルの使い分け：
    快速型Qwen2.5（7B）は爆速で動くが、熟考型Qwen3.5（9B）は私の「16GBメモリPC」ではファンの音が凄まじく、メモリ消費が80%を超えるためギリギリである。このスペック上限の中で、どう切り替えて使いこなすかの見極め。

Discussion