はじめに
以前、Zennにて「Claude Code CLIをGLM/Z.AIで代替した話」という記事を公開しました。
この記事は、Claude Code CLIの通信先をZ.AI（GLM）に切り替えることで、コストを大幅に抑えつつ開発を進める手法を紹介しました。実際に運用してみると、Z.AI Pro（GLM-5.1）はコストパフォーマンスが非常に高く、日常的な開発タスクの多くを十分にこなしてくれます。
しかし、運用を続ける中で「Z.AIだけでは不十分な場面がある」ことに気づきました。具体的には、使用量の上限に達してしまうケースや、エラーで開発フローが止まってしまうケースです。
そこで本記事では、ローカルプロキシを使ってMiniMax Plusをフォールバック（予備系）として組み込み、7層の守りで安く堅牢にLLMを運用する戦略について解説します。
なぜフォールバックが必要なのか（3つの理由）
Z.AI（GLM）をメインに据えた運用は非常に快適ですが、単一プロバイダーに依存する以下の3つの課題がありました。
理由1: 使用量オーバーフロー対策
Z.AIのプランには使用量上限があります。
| プラン | 月額料金 | 使用量（Claude Pro比） |
|---|---|---|
| Lite | $18/月 | 約3倍 |
| Pro | $72/月 | 約15倍 |
| Max | $160/月 | 約60倍 |
開発に没頭していると、いくら使用量がClaudeの約3倍あっても、上限に達することもあります。問題は、上限に達した時のデフォルトの挙動です。何も設定していなければ、Claude Code CLIは本来の通信先であるClaude APIにフォールバックしてしまいます。
Claude APIは最高性能ですが、その分高額です。月額$200の請求が来るリスクは、コスト最適化の観点からは本末転倒です。
ここでMiniMax Plus（月額$20）に逃がすことで、安価なまま開発を継続できます。
理由2: エラーレジリエンス
どんなプロバイダーも、一時的な障害は起きます。GLMが一時的に応答できない場面は稀ですが、ゼロではありません。
実際に運用していて、1ヶ月に数回程度はタイムアウトやサーバーエラーに遭遇しました。頻度は高くないものの、開発フローが止まるとストレスになります。特に調子よくコーディングを進めている最中にエラーで手が止まるのは、コンテキストの観点でも痛手です。
自動的にMiniMaxに切り替えることで、エラー発生時も開発の継続性を担保できます。
理由3: タスクの重み付け
3つ目の理由は、やや異なる観点です。全てのタスクに高性能モデルは不要だということです。
開発作業の中には、以下のような「簡単な定型処理」が含まれます。
- テストコードの生成
- 翻訳
- フォーマット変換
- ドキュメントの自動生成
- Lintエラーの修正
これらは、コーディング性能スコアが少し低くても十分にこなせるタスクです。
| モデル | SWE-bench Pro |
|---|---|
| Claude Opus 4.7 | 64.3% |
| GLM-5.1 | 58.4% |
| MiniMax M2.7 | 56.2% |
一方で、以下のような「複雑な推論」には高性能なモデルが必要です。
- 設計判断
- バグの原因調査
- アーキテクチャの決定
- リファクタリングの方針検討
コストに見合ったモデル振り分けを行うことで、効率的な開発が可能になります。
7層フォールバックチェーン
Claude Code CLIは、API通信先を環境変数で切り替え可能な仕組みを持っています。これを利用して、以下のような7層のフォールバックチェーンを実現しました。
┌─────────────────────────────────────────────────────┐
│ ① 正常時 → Z.AI（GLM-5.1） │
│ ② ピーク時間帯（13-19時）→ MiniMax M2.7 │
│ ③ 429エラー → GLM-4.7 → MiniMax │
│ ④ 500/502/503エラー → MiniMax【追加: 2026-05】 │
│ ⑤ タイムアウト（1200s）→ MiniMax【追加: 2026-05】│
│ ⑥ 接続エラー → MiniMax【追加: 2026-05】 │
│ ⑦ MiniMaxもエラー → 503返す │
└─────────────────────────────────────────────────────┘
どこかで障害が起きても、MiniMaxが最期まで守り抜きます。Claude Codeを再起動する必要すらありません。
关键技术：ローカルプロキシ
このフォールバックチェーンを実現しているのが、本地に立てたPython製プロキシです。
主な特徴は：
- リクエストを捕获: Claude Codeからのリクエストをlocalhost:8787で受け付ける
- 使用量トラッキング: 5時間ウィンドウの使用量を監視し、80%超えると下位モデルに切替
- 時間帯判定: ピーク時間帯（13-19時）にMiniMaxに自動切替
- ⑦全エラー対応: 429だけでなく、500/502/タイムアウト/接続エラー時もMiniMaxにフォールバック
核心となるコード:
async def _handle_upstream_error(self, method, path, headers, orig_body, original_error):
"""Handle non-429 errors from ZAI by falling back to MiniMax."""
if not self._config.minimax_api_key:
return error_response(original_error)
fb_model, _ = self._router.get_fallback()
body = self._replace_model(orig_body, fb_model)
resp = await self._upstream.request_minimax(method, path, headers, body)
return web.Response(status=resp["status"], body=resp["body"])
実際の運用構成
現在の運用構成は以下の3層構成になっています。
┌─────────────────────────────────────────┐
│ Layer 1: Z.AI Pro（GLM-5.1） │
│ 用途: 複雑なタスク・通常開発 │
│ 月額: $72 │
│ API: $1.40入力 / $4.40出力 │
├─────────────────────────────────────────┤
│ Layer 2: MiniMax M2.7 │
│ 用途: ピーク時間帯・エラー時・定型処理 │
│ 月額: $20 │
│ API: $0.30入力 / $1.20出力 │
│ （GLM比78%安い） │
├─────────────────────────────────────────┤
│ Layer 3: Claude API（最終保護） │
│ 用途: どうしようもない時だけ │
│ 月額: 従量課金（$200リスクあり） │
└─────────────────────────────────────────┘
体感として、Layer 1で全体の70〜80%、Layer 2が15〜25%を担い、Layer 3は月に数回程度しか発動しません。この構成により、コストを抑えつつ開発継続性を高いレベルで担保できています。
おわりに
フォールバック戦略により、単一プロバイダーの課題（使用量上限・エラー・コスト）を解決しつつ、開発体験を損なうことなきまま運用できています。
「安いLLMを使う = 品質を下げる」ではなく、「タスクに応じて適切なモデルを選ぶ = コストと品質のバランスを最適化する」という考え方で取り組んでいます。
ローカルプロキシはGitHubで公開していますので、興味の方はぜひ試してみてください。
関連記事
この記事を読んで興味を持った方へ
MiniMaxを試してみたい方は、以下の紹介リンクから登録できます。紹介コード使用で10%オフになります。
👉 MiniMax Token Plan — 紹介リンク（10%オフ）
紹介リンク経由で登録すると，你是10%オフ、筆者にAPIボーナスが付与されます
本記事は個人Zennでも公開しています。