# クライアントは 1 つのモデル、ゲートウェイが自動で階層化

> モデル選択をクライアントから取り除く：公開するモデル名は 1 つだけにし、ゲートウェイが会話の状態（計画か実行か）で自動的に階層化。強いモデルが計画し、コスト効率の良いモデルが実行し、マシンごとの設定のずれもありません。

正規 URL: https://www.gatellm.io/ja/use-cases/automatic-model-tiering/

モデル選択を UI から取り除きます。クライアントは 1 つのモデル名だけを公開し、計画は強いモデル、実行はコスト効率の良いモデルへ。リクエストが元々通るホップ上で階層化します。

## コミュニティが実際に不満を言っていること
「全員が設定で別々のモデルを使うので、同じプロンプトでも 2 人で結果が違う」「最初の週に最も多い質問は、どのモデルを選べばよいか」「モデルを廃止するたびに全開発マシンの環境変数を編集する」。モデルの選択が、判断材料を最も持たない人に委ねられています。自分の支出も見えず、このリクエストが強いモデルに値するかも分かりません。
逆に全員を安いモデルにすると仕事の質が落ちます。計画やアーキテクチャ判断を小型モデルに任せると、手戻りのコストが削減額を上回ります。本当に重要な分岐は、このリクエストが計画をしているのか実行をしているのかという点で、クライアントはそれをゲートウェイに伝えてきません。

## GateLLM の実現方法
クライアントは 1 つのモデル名を保ちます。ゲートウェイの catch-all マッピング（「*」から）が要求された任意の名前を正規化するため、個人の設定を編集してもリクエストの着地点は変わりません。どのモデルを選ぶかを説明する必要もなくなります。
階層化のシグナルはすでに会話の中にあります。Claude Code のプランモードは開始時に Plan mode is active、終了時に Exited Plan Mode を注入します。before スロットのスクリプトが最後のメッセージから後方に走査し、最後に見たマーカーで現在の状態を判断して context.useModel() でルーティングを切り替えます。判断は文字列の位置比較で、別途の分類呼び出しも追加のネットワークホップもありません。
階層化は before スロットに置く必要があります。after スロットは翻訳後のアップストリーム本文を見るためクライアント注入のマーカーを読めず、after スロットの useModel は同じプロトコル内でのみ切り替わり、計画から実行への変更はモデルをまたぐルート変更だからです。request_payload ルール（prompt_cache_key など）は両方のモデルに設定する必要があります。エントリモデルは計画中は自身の設定を保ち、切り替え後は対象モデルの設定が適用されます。

## 実際に効果が出る 5 つのレバー
- 単一のイングレス名：クライアントは 1 つのモデル名だけを公開し、「*」からの catch-all マッピングが要求されたすべての名前を 1 つの着地モデルに正規化
- 自動階層化：before スロットのスクリプトが後方走査で最後のマーカーを取得。エントリのマーカーは履歴に永久に残るため、「含む」判定では常にプランモードと読めてしまう
- プロトコルガード：スクリプトが最初に context.sourceProtocol を確認し、Anthropic 以外のトラフィックは早期に返すため、複数クライアントを担当する 1 つのエントリモデルが誤ルーティングされない
- 可観測：ログのモデル列の SW タグがスクリプト切り替えを、MM が ID マッピングを示す。統計と課金は最終的なモデル名で配賦され、すべての階層化判断を監査可能
- クライアントの展開不要：設定変更にマシンごとの編集は不要で、マッピングはホットリロードされる（唯一の例外はスクリプトのヒープ上限 SCRIPT_MEMORY_LIMIT_MB で、再起動が必要）

## FAQ
### クライアントは今でも自分のモデルを選べますか？
選べますが、その選択はリクエストの着地点を決めません。catch-all マッピングが任意の要求名を正規化し、スクリプトの useModel は管理者が強制するルート変更で、クライアントの権限には縛られません。クライアントに 1 つの名前だけを公開することが、この問い自体をなくします。

### 専用のモデルルーターや分類器を使わないのはなぜですか？
レイテンシーと形のためです。別のルーターはホップを追加し、通常は分類呼び出しも追加します。ここでは階層化のシグナルは会話にすでにあるマーカーテキストで、判断はリクエストが元々通る経路上での最後のマーカー位置の比較です。プロトコル翻訳、認証、計測はすでにゲートウェイにあるため、階層化のために 2 つ目のコンポーネントで重複させる必要はありません。

### スクリプトが何も切り替えず、ログにもエラーが出ません。なぜですか？
多くの場合スクリプトの OOM です。各スクリプトは独自の QuickJS サンドボックス（ヒープ上限 SCRIPT_MEMORY_LIMIT_MB、既定 64MB）で動き、オーバーフロー時は既定の「ログして続行」モードが useModel を含むすべての副作用を黙って破棄します。Claude Code の数十個のツール定義が先にメモリを消費し、その下限はスクリプト層では取り除けないため、上限を上げてください（再起動が必要です）。ログのモデル列の SW タグで切り替えを確認できます。

- [詳細手順：プランモードによるモデル切り替え（docs）](https://docs.gatellm.io/en/howto/script-switch-model-by-plan-mode)

## 関連するユースケース
- [エージェントが実際に使うモデルを強制する：モデルを固定し、計画と実行を分離](https://www.gatellm.io/ja/use-cases/enforce-model-policy.md)

## 関連ページ
- [ホーム](https://www.gatellm.io/ja/index.md)
- [料金](https://www.gatellm.io/ja/pricing.md)
- [コスト計算ツール](https://www.gatellm.io/ja/calculator.md)
- [会社概要](https://www.gatellm.io/ja/about.md)
- [デモを予約](https://www.gatellm.io/ja/demo.md)
- [FAQ](https://www.gatellm.io/ja/faq.md)
- [AI ゲートウェイ比較](https://www.gatellm.io/ja/compare.md)
- [LiteLLM 比較](https://www.gatellm.io/ja/compare/litellm.md)
- [OpenRouter 比較](https://www.gatellm.io/ja/compare/openrouter.md)
- [Alibaba Cloud AI Gateway 比較](https://www.gatellm.io/ja/compare/alibaba-cloud.md)
- [Azure API Management 比較](https://www.gatellm.io/ja/compare/azure-apim.md)
- [Apigee 比較](https://www.gatellm.io/ja/compare/apigee.md)
- [Cloudflare AI Gateway 比較](https://www.gatellm.io/ja/compare/cloudflare.md)
- [Kong AI Gateway 比較](https://www.gatellm.io/ja/compare/kong.md)
- [Portkey 比較](https://www.gatellm.io/ja/compare/portkey.md)
- [LiteLLM vs Kong AI Gateway](https://www.gatellm.io/ja/compare/litellm-vs-kong.md)
- [LiteLLM vs OpenRouter](https://www.gatellm.io/ja/compare/litellm-vs-openrouter.md)
- [LiteLLM vs Portkey](https://www.gatellm.io/ja/compare/litellm-vs-portkey.md)
- [ユースケース](https://www.gatellm.io/ja/use-cases.md)
- [LLM コスト削減](https://www.gatellm.io/ja/use-cases/reduce-cost.md)
- [高可用性](https://www.gatellm.io/ja/use-cases/high-availability.md)
- [マルチテナント分離](https://www.gatellm.io/ja/use-cases/multi-tenant.md)
- [コンプライアンスと監査](https://www.gatellm.io/ja/use-cases/compliance-audit.md)
- [症状別トラブルシューティング](https://www.gatellm.io/ja/use-cases/troubleshooting.md)
- [マルチベンダー混合モデル構成](https://www.gatellm.io/ja/use-cases/mixed-model-stack.md)
- [Office 内での AI セルフホスト](https://www.gatellm.io/ja/use-cases/self-hosted-office-ai.md)
- [Token 使用量の可視化と帰属](https://www.gatellm.io/ja/use-cases/token-ops.md)
- [Token FinOps：AI コストの配賦と統制](https://www.gatellm.io/ja/use-cases/token-finops.md)
- [MCP ツールガバナンス](https://www.gatellm.io/ja/use-cases/mcp-tool-governance.md)
- [すべてのモデルに Web 検索を追加](https://www.gatellm.io/ja/use-cases/web-search-grounding.md)
- [マルチキーのローテーションと待機系](https://www.gatellm.io/ja/use-cases/multi-key-pooling.md)
- [接続クライアントの受付制御](https://www.gatellm.io/ja/use-cases/client-admission-control.md)
- [モデル利用ポリシーの強制](https://www.gatellm.io/ja/use-cases/enforce-model-policy.md)
- [1 つのプロトコルで、あらゆるモデル](https://www.gatellm.io/ja/use-cases/one-protocol-any-model.md)
- [Office / Microsoft 365 アドイン](https://www.gatellm.io/ja/office-addin.md)
- [用語集](https://www.gatellm.io/ja/glossary.md)
- [モデルカタログ](https://www.gatellm.io/ja/models.md)
- [SDK・フレームワーク連携](https://www.gatellm.io/ja/integrations.md)
- [AI コーディングエージェントとハーネス](https://www.gatellm.io/ja/coding-agents.md)
- [セキュリティとコンプライアンス](https://www.gatellm.io/ja/security.md)