Antigravity × LiteLLM で複数 LLM プロバイダを 1 つのプロキシに束ねる実装ガイド

朝一でコードを書き始めて、Gemini の無料枠を午前のうちに使い切ったことがある人なら、その後ろめたい一日を思い出すかもしれません。私もまさにそうで、続きを書きたいのに「Quota exceeded」が並ぶのを眺めるしかなく、結果的にローカルの Gemma 4 に切り替え直すために 30 分溶かしました。プロバイダごとに API キーや設定を出し入れする作業を、もう何度繰り返したのか分かりません。

LiteLLM はこの「切り替えコスト」を 1 つのプロキシで吸収してくれるツールです。Antigravity はカスタム OpenAI 互換エンドポイントに対応しているため、LiteLLM を間に挟むと、IDE 側の設定を 1 行も変えずに「今日は Claude」「混雑していたら Gemma」「コードレビューだけ Gemini」のような切り替えが可能になります。ここでは私が実際に運用している構成を例に、設計の勘所と本番で気づいた落とし穴を共有します。

なぜ Antigravity に LiteLLM プロキシを挟むのか

LiteLLM の魅力は、単に「複数プロバイダを呼べる」だけではありません。Antigravity と組み合わせたときに効いてくるのは次の 3 点です。

OpenAI 互換 API に統一できる: Antigravity のカスタムプロバイダ設定は OpenAI 互換 API を前提にしています。Gemini も Claude も Ollama も、LiteLLM を通せば OpenAI 形式で叩けます。
フォールバックチェーンが宣言的に書ける: model_list と fallbacks を YAML に書くだけで、429 や 5xx が出たら自動で別のモデルに切り替わります。Antigravity 側に再試行ロジックを書く必要がありません。
コストとレイテンシをログに取れる: LiteLLM は Prometheus 互換のメトリクスとリクエストログを出します。「今月どのモデルにいくら払ったか」を Antigravity の挙動と紐づけて分析できます。

似た用途では LibreChat のセルフホスト版もありますが、LibreChat はチャット UI を含むスタックなので、Antigravity から呼ぶ用途には少し重く感じます。プロキシだけが欲しいなら LiteLLM の方が素直です（LibreChatでセルフホスト型マルチAIプラットフォームを作る方法に LibreChat の構成例があります）。

アーキテクチャ全体像

私が常用している構成を図で書くと、こうなります。

Antigravity（IDE）→ HTTPS → LiteLLM Proxy（Docker）→ Gemini / Claude / OpenAI / Ollama
LiteLLM Proxy は Cloud Run か自宅の Mac mini で動かす（後述します）
ローカル Gemma 4 は Ollama 経由で同じ LiteLLM に登録する

ポイントは、Antigravity から見ると エンドポイントは 1 つだけ という点です。http://localhost:4000/v1 のような単一の URL を IDE に登録しておけば、裏でどのプロバイダが応答していようが Antigravity は気にしません。

LiteLLM プロキシのセットアップ

最小構成は Docker Compose で 5 分で立ちます。config.yaml でモデルとフォールバックを宣言します。

# config.yaml — LiteLLM プロキシ設定の最小例
# 「メインは Gemini、429 が出たら Claude、それでもダメなら Gemma 4 ローカル」を宣言
model_list:
  - model_name: smart  # Antigravity から呼ぶ論理名
    litellm_params:
      model: gemini/gemini-2.5-pro
      api_key: os.environ/GEMINI_API_KEY
  - model_name: smart-backup
    litellm_params:
      model: anthropic/claude-sonnet-4-6
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: smart-local
    litellm_params:
      model: ollama/gemma3:27b
      api_base: http://host.docker.internal:11434
 
router_settings:
  fallbacks:
    - { smart: ["smart-backup", "smart-local"] }
  num_retries: 2
  timeout: 30
 
litellm_settings:
  drop_params: true  # Antigravity が送る非対応パラメータを黙って落とす
  set_verbose: false

drop_params: true は地味ですが効きます。Antigravity は OpenAI 互換ヘッダで frequency_penalty などを送ることがあり、Gemini が知らないパラメータでエラー停止する事故を防げます。

# docker-compose.yml — そのまま動く構成例
services:
  litellm:
    image: ghcr.io/berriai/litellm:main-latest
    ports:
      - "4000:4000"
    volumes:
      - ./config.yaml:/app/config.yaml
    environment:
      GEMINI_API_KEY: ${GEMINI_API_KEY}
      ANTHROPIC_API_KEY: ${ANTHROPIC_API_KEY}
      LITELLM_MASTER_KEY: ${LITELLM_MASTER_KEY}
    command: ["--config", "/app/config.yaml", "--port", "4000"]

docker compose up -d で起動して、curl -H "Authorization: Bearer $LITELLM_MASTER_KEY" http://localhost:4000/v1/models が返ってくれば成功です。期待出力は data 配列に smart smart-backup smart-local が並んでいる形になります。

Antigravity から LiteLLM を経由する設定

Antigravity の Settings から Custom OpenAI-compatible Provider を追加します。私の手元では次のような値で動いています。

Base URL: http://localhost:4000/v1
API Key: LITELLM_MASTER_KEY で設定した値
Model ID: smart（LiteLLM の model_name を入れる）

ここまで来ると、Antigravity のチャット欄から普段通り会話するだけで、裏で LiteLLM がフォールバックを面倒見てくれます。Gemini が落ちている日に IDE を再起動する必要がなくなり、これだけで体感ストレスがかなり減ります。

ローカル Gemma を本格的に併用したい場合は、Antigravity でローカル LLM をセットアップする完全ガイドと組み合わせると、外部 API 障害時の最後の砦として機能します。

ルーティング戦略 — フォールバック・コスト・レイテンシ

実運用では「常に Gemini」よりもタスクごとに使い分けた方が満足度が上がります。私が落ち着いた設定はこの 3 つです。

コードレビュー専用: claude-sonnet-4-6 を主、gemini-2.5-pro をフォールバック。長文の差分理解は Claude が外しにくく、指摘の言い回しが命令調にならないのも実用上ありがたいポイントです。月曜の Claude が混雑しがちな時間帯にだけフォールバックが効いてくれれば十分です。
大量のリファクタリング: gemini-2.5-pro を主、smart-local（Gemma 4）をフォールバック。トークン単価が低く、止まっても手元で続行できます。先日のクロスリージョン障害でもほぼ気付かないまま作業を続けられました。
個人実験・夜間バッチ: smart-local を主、gemini-2.0-flash をフォールバック。電気代以外はゼロ円で、業務に乗せるには気が引けるような実験はすべてこのプロファイルに流しています。

ありがちな失敗は、まったく性格の違うモデルを同じプロンプトで使い回そうとすることです。Claude に効く書き方は Gemma 4 ではしばしば外れますし、その逆もあります。プロファイルは「どのキーを持っているか」ではなく「自分の書くプロンプトの型」に揃えるのが結局は近道です。プロバイダごとにプロンプトを大きく変えたいなら、フォールバックチェーンに無理やり押し込まず、別の論理モデル名として分けてしまった方が運用が落ち着きます。

LiteLLM の router_settings には routing_strategy: latency-based-routing も用意されており、リアルタイムで一番速いモデルを選ばせる設定もできます。私はコストの読みやすさを優先して使っていませんが、レスポンス速度に厳しいエージェントを書くなら一度試す価値があります（Antigravity × Ollama でローカル LLM 統合も合わせて読むと、ローカル側のレイテンシ最適化が分かります）。

私がハマったポイント

公式ドキュメントには書かれていない、実際に詰まった点をいくつか共有します。

コンテキスト長の不一致でフォールバックが沈黙する: Gemini 1M トークンの感覚で長文を投げると、Claude にフォールバックしたとたん 200K で切れることがあります。LiteLLM は黙って前半だけ送るので、出力が短くなって初めて気づきました。max_input_tokens を model_list に明示しておくと、超過時に明示的に失敗してくれます。
Antigravity のストリーミングと num_retries の相性: ストリーミング中にプロバイダ側が切断すると、num_retries が走っても Antigravity 側はすでにトークンを受け取った後の状態になります。num_retries: 2 程度に抑え、エージェント側で完了確認を入れるのが安全でした。
LITELLM_MASTER_KEY を .env にコミットしてしまう: 当然ながら GitHub Secret Scanning に検出されます。gitleaks をプリコミットフックに入れて、config.yaml と .env をブロックする設定にしてからは事故ゼロです。
Cloud Run にデプロイすると Cold Start で 10 秒ほど詰まる: 自宅運用なら気になりませんが、共有環境では min-instances=1 を設定するか、Mac mini を 24 時間起動するスタイルに切り替えました。
キー単位の予算上限はレート制限より頼れる: LiteLLM は仮想キーごとに max_budget を設定でき、これを月次の上限として運用しています。誰かが gemini-2.5-pro をループでうっかり叩いても、プロキシが上限超過の時点でリクエストを拒否するので、課金額が想定外に膨らみません。アラートに頼るより安心して眠れる設定です。

全体を振り返って — まず今日試すなら

LiteLLM の導入は思ったより軽く、Antigravity との相性も良好です。手元の API キーが 2 つ以上ある人なら、試して損はない構成だと思います。今日試すならまずは Docker Compose で config.yaml を 1 ファイル書き、Antigravity の Custom Provider に登録するところまでで十分です。フォールバックの YAML を 2 行足すだけで、Quota 切れに振り回されない開発環境が手に入ります。

より深い AI 観測性まで踏み込みたい方は、Antigravity と OpenTelemetry で AI 可観測パイプラインを構築するも参考になります。LiteLLM のメトリクスを OpenTelemetry に流せば、モデル別の応答時間やエラー率を 1 つのダッシュボードで眺められるようになります。

書籍で体系的に