「安いモデル」と「高いモデル」の使い分けは、3つの型で考える：AWS・Microsoftの自動ルーターと、OpenAI・Anthropicの選び方の指針を、公式資料で確かめる

この記事は、実際に使って確かめた記録ではありません。この記事は公式の文書を読んでまとめたもので、実際に使って確かめた記録ではありません。情報は2026年10月16日に確認し、10月22日に読み直しました。モデル名や数字は変わることがあります。

先に結論

• 「モデルの振り分け（ルーティング）」とは、1回ごとの頼みごとを見て、どのモデルに渡すかを決める仕組みです。目的は、品質を保ったまま、費用や待ち時間を減らすことです。
• 公式の文書から読み取れる設計の型は3つです。①クラウドのルーターに任せる（AWS、Microsoft）。②自分のコードや設定で決める（OpenAI、Anthropicの選び方の指針）。③強いモデルと安いモデルを役割分担させる（Anthropicの2つの型）。
• 3つとも、効果は「その人の仕事」で変わります。OpenAIとAnthropicの文書は、自分の用途で試してから決めるように書いています。数字だけ見て決めないのが基本です。

3つの型を並べる

型①：クラウドの自動ルーター

Amazon Bedrock

AWSの文書によると、Intelligent Prompt Routingは、同じモデルの系統の中で、1回ごとの頼みごとを見て、各モデルの返事の品質を予測して、送り先を決める仕組みです。返事には、使われたモデルの情報が入ります。

設定は2種類あります。既定のルーター（Amazon NovaまたはMeta Llamaのモデルを使う。リージョンによる）と、自分で作るルーターです。後者は、モデルを2つ（コンソールの場合）と、基準になる「フォールバックモデル」、それに「品質の差」の基準を決めます。基準を満たさない場合は、指定したフォールバックモデルに送られる、と書かれています。

読んだ範囲で、はっきり書かれている制限は次のとおりです。

• 英語のプロンプトのみ最適化されている。
• アプリごとの成績データを見て振り分けを直すことはできない。
• 特殊な用途では、うまく振り分けられないことがある。

料金と待ち時間は、このページには書かれていませんでした。

Microsoft Foundry（Model router）

Microsoftの文書によると、Model routerは、頼みごとの複雑さや種類を見て、適したモデルに送る、学習済みのモデルです。ほかのモデルと同じようにデプロイ（設置）して使い、modelにはデプロイの名前を指定します。使われた相手は、応答のmodel欄で分かります。

Microsoftの文書は、「バランス」（既定）、「コスト」、「品質」の3つのモードを説明しています。品質差の割合の数字は「例」であって固定の基準ではない、と書かれています。各モードの細かい挙動は、公式ページで確認してください。

重要な制限もあります。

• 文脈の長さ（一度に読める量）は、振り分け先のうち一番小さいモデルに制限される。
• 画像は受け付けるが、振り分けの判断は文章だけで行う。
• 振り分け先に推論モデル（考えてから答えるモデル）が選ばれると、temperatureなどの一部の設定は無視される。
• 連続した頼みごとで同じモデルに当たらないと、プロンプトキャッシュ（同じ前置きを安く読み直す仕組み）の節約は保証されない。

見立てです。自動ルーターの強みは、「自分では振り分けの基準を作らなくてよい」ことで、弱みは「基準が中で見えず、振り分け先が変わりうる」ことだと思います。Microsoftの文書にも、自動更新を選ぶと振り分け先のモデルの組が変わりうる、と書かれています。

型②：自分で決める

OpenAIの指針

OpenAIのModel selectionの文書は、3つのモデル（Astra、GPT-6.1 Sol、Luna）を取り上げ、モデルごとに推論の深さ（Low、Medium、Extra high）の選択肢を挙げています。例として、Astraは3段階すべて、GPT-6.1 SolはMediumとExtra high、LunaはLowとExtra highが並んでいます。モデルごとの向き不向きの細かい説明は、僕らの記録に残っていないため、ここでは書きません。

選ぶときに見る点として、4つの要素が挙がっています（個々の中身は、僕らの記録に残っていません）。そして、「基準を満たす中で一番軽い設定」を残すように、と書かれています。この文書には、評価（evals）や、小さいモデルへの切り替えの具体的な手順は載っていませんでした。

別の文書（Latency optimization）は、もう少し設計寄りです。小さいモデルは、狭くて決まった作業に向く。開かれた返事は大きいモデルに残す。モデレーションのような「ほぼ一方の結果になる確認」は、確認と本命の処理を同時に始め、確認の結果が予想と違えば本命を取り消す、という方法がある、と書かれています。同時に、作業を分けると返事が悪くなる場合の仮定の例も載っていて、分け方は本番に近い例で試すように、とあります。

OpenAIのCost optimizationの文書も、費用を下げる基本として、頼みごとの回数を減らす、トークンを減らす、精度が保てるなら小さいモデルを選ぶ、の3つを挙げています。Batch APIや、遅くなったり使えなかったりすることがあるFlex processingも紹介されていますが、このページには割引の数字は書かれていませんでした。どの作業にどのモデルを当てるかの対応表も、ありませんでした。

Anthropicの指針

Anthropicの「Choosing a model」は、選ぶ軸を、能力、速さ、費用、effort（考える量）の4つとしています。さらに、同じモデルの中で「effort」（考える量の設定）を調整するほうが、モデルを替えるより効くことが多い、と書いています。

出発点は2つです。効率優先は、小さいモデル（Haiku 5.5）から始めて、足りない所だけ上げる。能力優先は、強いモデル（Opus 5.5）から始めて、設定やモデルを徐々に下げる。どちらでも、最も大事な手順は、自分の用途のテストを作ることだと書かれています。

型③：組み合わせる

Anthropicの「Optimizing for cost and intelligence」は、組み合わせ方を2つに分けています。

大事なのは、これが「万能の節約術」として書かれていないことです。下の測定例にも、組み合わせが効かなかった例が並びます。

設計の判断基準（見立て）

ここからは僕らの見立てです。公式の文書を踏まえて整理しました。

1. まず「1つのモデルの設定を振る」。 Anthropicは、モデルを替える前にeffortの設定を見るように書き、OpenAIも、基準を満たす中で一番軽い設定を残すように書いています。振り分けは、そのあとに足す層です。
2. 振り分けの基準が、見えるか。 自動ルーターは手間が減りますが、基準を変えられない・見えにくい面があります。自分で決める型は、手間が増える代わりに、理由を説明できます。
3. 失敗を、安いほうに寄せない。 安いモデルの失敗が、取り返しにくい作業（送信、削除、支払い）で起きると、節約より損が大きくなります。そういう場面は、強いモデルに固定するか、人の確認を入れる、と考えます。
4. ルーター自体の費用と遅れを足して比べる。 振り分けの判断にも時間がかかります。「小さいモデルの判断を1回挟む」ぶんが、節約を超えないか確かめます。
5. ログに、どのモデルが答えたかを残す。 品質が下がったときに、原因をたどれるようにするためです。Microsoftは応答のmodel欄、AWSは応答に使われたモデルの情報が入る、と書いています。

よくある落とし穴

• 平均だけで判断する。簡単な問いは安いモデルで十分でも、難しい問いの失敗が目立つことがあります。問いの種類ごとに結果を見ます。
• 日本語で使えるか確かめない。AWSの自動ルーターは、英語のプロンプトのみ最適化されている、と書かれています。日本語での振り分けの質は、読んだ文書からは分かりません。
• 文脈の長さを忘れる。Microsoftのルーターは、一番小さいモデルの上限に引っ張られます。
• キャッシュを失う。モデルが切り替わると、前置きのキャッシュが効かず、思ったほど安くならないことがあります。
• 1回の測定で決める。Anthropicの数字は社内の測定で、公式自身が「方向を示すもの」と書いています。

気をつけること

• この記事は、実際に使って確かめた記録ではありません。内容は公式の文書の記載です。この記事にはコードを載せていません。
• 公式ページは、WebFetchという取得の仕組みで読みました。この仕組みは要約を返すので、細部を取りこぼしている可能性があります。Anthropicの「Optimizing for cost and intelligence」は、10月22日に末尾まで読みました（末尾は、プロンプトキャッシュの時間の測定の話でした）。
• AWSの文書は、料金、待ち時間、品質差の数値の単位を書いていません。「品質差」の設定値の意味は、API仕様で確認してください。また、例にはClaudeのモデルが出てきますが、一覧表の対応モデルにはありません。使うモデルが対応しているか、確認してください。
• Microsoftの文書は、料金の説明が、読んだ2ページで違う書き方でした。どちらが正しいかは、確認できていません。
• OpenAIのModel selectionは、評価（evals）の手順を書いていませんでした。「書かれていない」とは断定できません。
• Googleのモデルの振り分けの公式の案内は、今回は読んでいません。この記事の範囲は、AWS、Microsoft、OpenAI、Anthropicです。
• モデル名、対応リージョン、料金、効果の数字は、変わることがあります。Anthropicの測定は社内の数字で、僕らの用途で同じになるとは限りません。
• 見立ての部分（判断基準、落とし穴の一部）は、公式の指示ではなく、僕らの整理です。

出典

• Intelligent prompt routing（Amazon Bedrock User Guide、AWS、10月22日確認）
• Model router for Microsoft Foundry（概念、Microsoft Learn、Microsoft、10月22日確認）
• Model router for Microsoft Foundry（使い方、Microsoft Learn、Microsoft、10月22日確認）
• Model selection（OpenAI API、OpenAI、10月22日確認）
• Latency optimization（OpenAI API、OpenAI、10月22日確認）
• Cost optimization（OpenAI API、OpenAI、10月22日確認）
• Choosing a model（Claude Platform Docs、Anthropic、10月22日確認）
• Optimizing for cost and intelligence（Claude Platform Docs、Anthropic、10月22日確認）

更新履歴

• 2026年10月25日 書き方を直しました。

  • 前：運営者が使っていないと読める書き方 → いま：「この記事は、実際に使って確かめた記録ではありません」。公式の資料を読んでまとめた記事で、使い心地は書いていない、という意味に直した

• 2026年10月22日 公式の資料を読み直して、次の点を直しました。

  • 前：リージョン数の32と23は、どちらがどの種別か確認できていない → いま：Global Standardで32、そのうちData Zone Standardでも使えるのが23
  • 前：GPQA Diamondで助言役を付けると、費用は12%と25%増え、内訳は不明 → いま：Haiku 5.5の組み合わせで12%、Sonnet 5.5の組み合わせで25%
  • 前：OpenAIのModel selectionは、3つのモデルに推論の深さの選択肢がある、とだけ → いま：Astraは3段階、GPT-6.1 SolはMediumとExtra high、LunaはLowとExtra highと例示
  • 前：Microsoftの料金は、実際に使われたモデルの費用の合計 → いま：振り分け先の基になるモデルで生じた費用の合計
  • 前：Anthropicの「Optimizing for cost and intelligence」は、末尾の約9,000字が未読 → いま：末尾まで読んだ（プロンプトキャッシュの時間の測定の話）