0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

月間27億トークンを処理したLLMルーティングの実運用レポート(1ヶ月の振り返り)

0
Last updated at Posted at 2026-10-13

はじめに

これまで、Zennで2つの記事を公開してきました。

  1. Claude Code CLIをGLM(Z.AI)で代替した話(コスト大幅削減の実測)
  2. Claude Code CLIにMiniMaxをフォールバックとして組み込んだ話

第1弾ではコストの比較、第2弾ではフォールバックの仕組みを解説しました。しかし、「実際に使い続けてどうだったのか」という実運用の生の声については、十分に触れられていませんでした。

本記事では、1ヶ月間の実運用データをもとに、振り返りをお届けします。

運用構成のおさらい

現在の運用構成は以下の3層です。

┌─────────────────────────────────────────────┐
│  Layer 1: Z.AI Max(GLM-5.1)              │
│  月額: $160  使用量: Claude Proの約60倍      │
│  用途: 通常タスクの80〜90%                   │
├─────────────────────────────────────────────┤
│  Layer 2: MiniMax Plus                      │
│  月額: $20                                  │
│  用途: GLM失敗時・大量処理(10〜19%)        │
├─────────────────────────────────────────────┤
│  Layer 3: Claude API(最終保護)             │
│  月額: 従量課金                              │
│  用途: 月数回未満                            │
└─────────────────────────────────────────────┘

合計月額 $180(約28,000円) で、Claude Code Max(20x)の$220より安く、かつ使用量は大幅に多い構成です。

WSL2 Ubuntu上のClaude Code CLI環境で、ローカルレートプロキシ経由でZ.AI APIに接続しています。

1ヶ月の数字

トークン消費量

Z.AIのダッシュボードから確認した30日間の実績です。

項目 数値
30日間トータル 2,738,002,646 トークン(約27.4億)
1日あたり平均 約9,100万トークン
1日のピーク 約3.9億トークン

1日あたり9,100万トークンというのは、Claude Code Pro(ベースプラン)の月間使用量を毎日消費している計算です。この規模の開発を行う場合、Claude公式プランでは到底追いつきません。

コスト効率

構成 月額 27.4億トークンを処理できるか
Claude Code Max(20x) $220 ❌ 上限到達の可能性大
Z.AI Max 単体 $160 ⚠️ ピーク月は429のリスク
Z.AI Max + MiniMax $180 ✅ フォールバックで安心

$180/月で27億トークンを処理できているのは、マルチプロバイダー構成ならではの結果です。

レイヤー別の使用割合

体感ベースですが、おおよそ以下の割合で分散しています。

レイヤー 割合 主な用途
Layer 1(GLM-5.1) 85% 通常開発・設計判断・コード生成
Layer 2(MiniMax) 14% 使用量上限時・GLMタイムアウト時
Layer 3(Claude API) 1%未満 実質ほぼ使わず

GLM-5.1が8〜9割を担い、MiniMaxが残りをカバー。Claude APIはセーフティネットとして存在するだけで、実際にはほぼ発動しませんでした。

トラブル事例と対策

1ヶ月の運用で遭遇したトラブルと、どう解決したかをまとめます。

トラブル1: 429レートリミット(約3時間の停止)

最大のインシデントは、Z.AI Maxのレートリミット到達による約3時間の完全停止でした。

Z.AI Maxプランの制限は「5時間ウィンドウ1,600プロンプト」「週間8,000プロンプト」です。開発に没頭していると、特にピーク時間帯(15:00〜19:00 JST)はGLM-5.1が通常の3倍の消費量になるため、あっという間に上限に達します。

Claude Code CLIにはAPIレベルのフォールバック機構がありません。429が返ると、開発フローが完全に停止します。

対策: ローカルレートプロキシ(glm-rate-proxy)を開発・導入しました。

Claude Code → localhost:8787(プロキシ)→ Z.AI API / MiniMax API

このプロキシは、Z.AIの使用率に応じて自動的にモデルを切り替えます。

使用率 モード モデル 消費
<80% Normal GLM-5.1 3x(ピーク)/ 2x(オフピーク)
80-95% Economy GLM-4.7 1x
>95% Emergency GLM-4.7-Flash 無料

使用率が高くなると、自動的に消費の少ないモデルに切り替わり、429到達を未然に防ぎます。429が発生した場合でも、GLM-4.7-Flash(無料枠)→ MiniMax M2.7 の順でフォールバックするため、開発が止まることはなくなりました。

結果: プロキシ導入後、429による停止はゼロです。

トラブル2: プロキシ起動失敗時の通信断

プロキシはClaude Codeのセッション開始時にフックスクリプトで起動しますが、まれに起動に失敗することがありました。この場合、ANTHROPIC_BASE_URLがlocalhost:8787を指したままプロキシがいないため、全ての通信が失敗します。

対策: フェイルセーフ機構を実装しました。

  • プロキシ起動成功 → settings.jsonのURLをlocalhost:8787に変更
  • プロキシ起動失敗 → settings.jsonをZ.AI直結URLのまま保持(変更しない)

これにより、プロキシが起動しなくてもZ.AI直結で動作し続けます。

トラブル3: MCPツール定義のコンテキスト圧迫

LLMルーティングとは直接関係ありませんが、運用上の大きな課題でした。

7つのMCPサーバーが提供するツール定義が、会話コンテキストの約10%(21.4kトークン)を占有していました。これにより、長時間のセッションではコンテキスト不足に陥りやすくなります。

対策: 使用頻度の低いMCPサーバー(linear, sentry, supabase, tavily, stripe)を削除し、6サーバーに削減。約35kトークンの節約になりました。

また、設定ファイルが2つ(~/.claude.jsonと~/.claude/settings.json)存在し、両方がマージされてロードされることに気づかず、削除が反映されないトラブルも経験しました。Claude Code CLIのclaude mcp removeコマンドで両ファイルから一括削除できるため、手動編集よりCLIの利用をおすすめします。

月間の開発実績

この構成で1ヶ月間に達成した開発成果です。

項目 実績
GitHub公開プロジェクト 14(非公開含めると23)
テストコード 4,862テスト以上(pytest)
コードレビュー 3プロジェクト・30ファイル・7軸評価
リファクタリング 20項目(3プロジェクト横断)
Zenn記事 7本公開
Obsidian SSOTレコード 323件

27億トークンの多くは、コード生成・テスト実行・リファクタリング・ドキュメント作成に使われました。GLM-5.1は複雑な設計判断でも十分に実用的で、日常的な開発の大部分を支えてくれました。

コストに見合っているかの判断

$180/月(約28,000円)で、これだけの開発成果を出せているのは費用対効果が非常に高いと判断しています。

同じことをClaude公式プランで行う場合、Max(20x)の$220でも使用量が不足する可能性があります。従量課金で補完すると、月に$500〜$1,000以上かかることも珍しくありません。

個人開発者にとって「いくら使っても月額固定」の安心感は、開発の継続性に直結します。「コストを気にしてAIに任せるのをためらう」という状況をなくすことが、最も大きな効果だったと感じています。

今後の改善予定

1ヶ月運用して見えた課題と、今後の改善予定です。

レートプロキシの安定性監視

現在、プロキシのステータス確認は手動(curl http://127.0.0.1:8787/proxy/status)です。将来的には、自動的なヘルスチェックとアラートを組み込む予定です。

トークン使用量の可視化

Z.AIダッシュボードで全体の使用量は確認できますが、「どのプロジェクトでどれだけ消費したか」の内訳は把握できていません。プロジェクト別の使用量トラッキングを導入したいと考えています。

MiniMaxの自動委譲の強化

現在はGLMがタイムアウトした際にMiniMaxにフォールバックしていますが、「要約・テスト生成・フォーマット変換」のような定型処理は、最初からMiniMaxに振り分ける方がトークン単価的に効率的です。タスクの性質に応じた事前ルーティングの導入を検討しています。

まとめ

1ヶ月間、27億トークンを処理したLLMルーティングの実運用から、以下が分かりました。

  • マルチプロバイダー構成は有効: 単一プロバイダーの429や障害に強い
  • ローカルレートプロキシが鍵: 使用率に応じた自動モデル切替で429を予防
  • $180/月で十分な開発が可能: 個人開発の規模なら、公式プランより安く済む
  • フェイルセーフ設計が重要: プロキシが壊れても直結で動き続ける設計が必須

「安いLLMを使う」は単なるコスト削減ではありません。マルチプロバイダーのレジリエンス、タスク別の最適化、そして開発の継続性という観点で、単一プロバイダーにはない優位性があります。

関連記事

この記事を読んで興味を持った方へ

Z.AI(GLM)を試してみたい方は、以下の紹介リンクから登録できます。

👉 Z.AI Coding Plan — 紹介リンク

紹介リンク経由で登録すると、筆者にボーナスが付与されます(あなたの料金は変わりません)

MiniMaxを試してみたい方は、以下の紹介リンクから登録できます。紹介コード使用で10%オフになります。

👉 MiniMax Token Plan — 紹介リンク(10%オフ)

紹介リンク経由で登録すると、あなたは10%オフ、筆者にAPIボーナスが付与されます


本記事は個人Zennでも公開しています。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?