ANTIGRAVITY LABEN
記事一覧/Agents & Manager
Agents & Manager/2026-04-23上級

Antigravity × マルチプロバイダー LLM フェイルオーバー — Gemini / Claude / ローカル Gemma を止めない本番構成

Gemini が 503 を返した瞬間、サービスが停止する構成になっていませんか。ルーター・回路遮断・段階的フォールバックを本番コードレベルで設計するための実装ガイドです。

antigravity435multi-providerfailoverresilience7gemini15claude3gemma2

プレミアム記事

先月、私が運用している AI エージェントが朝の 9 時から 11 時のあいだ Gemini API の 503 を返し続けました。Google Cloud のステータスページには障害情報が出ておらず、X(旧 Twitter)で検索してようやく一部リージョンで間欠的にエラーが出ていることが分かった、そんな状況でした。

このときサービスは完全に停止したわけではありません。ただ、レスポンスがエラーで埋め尽くされ、ユーザーから「壊れていますか」という問い合わせが十数件届きました。一晩で失った信頼は、半年かけて積み上げたものより大きく感じられました。

ここではあの朝の反省から組み直した「止まらない LLM 構成」の全実装を公開します。Antigravity のエージェント環境で、Gemini・Claude・ローカル Gemma 4 を組み合わせ、プロバイダーが落ちてもユーザー体験を守るためのルーター層・サーキットブレーカー・段階的フォールバックを、コピー&ペーストで動くコードとともに解説します。

この構成を本気で組み直したのは、私が個人開発でアプリ事業とこの Dolice Labs のサイト群を並行して回しているからでもあります。アプリの広告配信も、記事生成のパイプラインも、裏側では同じように外部 API に依存しています。どこか一つの応答が滞ると、収益とユーザーの信頼が同じ速さで削れていく——その感覚を何度か味わううちに、「止まらないこと」を後付けではなく最初の設計に織り込む癖がつきました。ここから先は、その癖を具体的なコードと数字に落とし込んでいきます。

マルチプロバイダー構成が必要になる瞬間

「LLM が落ちる」と聞くと、多くの方は「そんなに頻繁に起きない」と感じるかもしれません。確かに公式ステータスページで可視化される大規模障害は月に 1〜2 回程度です。

しかし実運用では、次のような部分的障害が毎週のように起きています。

  • 特定リージョンだけ 503 が頻発する(グローバル指標では健全)
  • レート制限に達したが、復旧まで 3〜5 分かかる
  • モデルが一時的に極端に遅くなる(p99 が 30 秒を超える)
  • 特定のトークン数だけ INTERNAL エラーを返す

単一プロバイダー構成だと、これらがそのままユーザーへ露出します。マルチプロバイダー構成の本質的な価値は「完全停止を防ぐこと」ではなく、「部分障害を吸収してユーザーに気づかせないこと」です。

この前提を共有した上で、どう組めば破綻しないかを設計していきます。

3 層の判断軸 — コスト・遅延・能力で切り替える

実装に入る前に、ルーティングの判断基準を整理しておきます。私が本番で回している構成は次の 3 層で考えています。

第 1 層は 能力軸です。そのリクエストに最低限必要な能力をプロバイダーが提供しているかどうかで判定します。たとえば 100 万トークンのコンテキストが必要なら Gemini 一択、ツールコールの複雑な JSON スキーマが必要なら Claude、オフライン環境なら Gemma を使う、といった具合です。

第 2 層は 遅延軸です。同等能力を満たすプロバイダーが複数ある場合、p95 レイテンシが低い方を優先します。ただし現在のレスポンス時間ではなく、過去 5 分間の移動平均を見るのがコツです。スパイクで判断すると切り替えが震えます。

第 3 層は コスト軸です。能力と遅延が同等なら、トークン単価が安い方を選びます。これは最後の判断軸にするのが重要です。コストを最優先にすると、障害時にコストで負けた高品質プロバイダーへの切り替えがうまく働きません。

この順序を逆にすると、たとえば「コストで Gemini を選んだが 503 が返ってきた → Claude にフォールバック → でも Claude の方が遅い → さらに Gemma にフォールバック」というループが発生しやすくなります。必ず「能力 → 遅延 → コスト」の順で判定してください。

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること
Gemini・Claude・ローカル Gemma を能力→遅延→コストの順で切り替えるルーター層の全コード
サーキットブレーカーと段階的フォールバックを本番設定値つきで実装する手順
3 か月運用して見えたフォールバック率・p95・コスト配分の実測値と障害ふりかえりテンプレート
Stripe による安全な決済 · いつでもキャンセル可能

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または
メンバーシップなら全記事が読み放題 →
シェア

お読みいただきありがとうございます

Antigravity Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • コピー&ペーストで使える実装コード付き
  • 毎日新しい上級ガイドを追加
  • ¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

Agents & Manager2026-03-20
Antigravity マルチモデル実践: Gemini × Claude × GPT-OSS の最適な使い分け戦略
Antigravity IDE で利用できる Gemini 3.1 Pro・Claude Opus 4.6・GPT-OSS 120B を場面ごとに最適に使い分ける実践ガイド。モデル特性の比較、AGENTS.md での制御方法、コスト最適化戦略を詳しく解説します。
Agents & Manager2026-06-15
Antigravity のマルチエージェントを本番で壊さない封じ込め設計 — 連鎖障害を止める3つの境界の実装メモ
Antigravity のマルチエージェント構成は単体では綺麗に動くのに、本番では小さな失敗が全体に波及します。連鎖障害を止めるための制御の階層化・信頼境界・観測と冪等性という3つの境界を、TOML 設定と相関IDラッパーの実装まで含めて整理しました。
Agents & Manager2026-05-22
Antigravity Agent のフォールバック階層設計 — モデル劣化・API障害・コスト超過を 4 段で受け止める Resilience アーキテクチャ
AI エージェントの本番運用で起きる『モデル応答劣化・API障害・コスト超過』を 4 段階のフォールバック階層で受け止める設計を、6 アプリ並行運用の実装ログとともに整理しました。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →