モデル選定とコストガバナンス：「全部最強を使う」からタスク別階層化へ

なぜ「統一して最強モデルを使う」がコストの罠なのか

モデル能力は階層化されています。フラッグシップモデルは長い連鎖推論、複雑なコード、多数の制約付き指示が得意です。軽量モデルは分類、抽出、フォーマット変換、短い Q&A ではしばしば十分です。そして両者の単価差は10倍以上に達することがあります。

Anthropic の現在の価格ページと OpenAI の [API pricing](https://developers.openai.com/api/docs/pricing) はどちらも自社モデルを複数のティアに分けています。Anthropic が公開している [pricing](https://claude.com/pricing) を例にすると、Opus、Sonnet、Haiku の3ティアは異なる強度のタスク向けで、単価差は明らかです。毎日数十万件の単純な分類までフラッグシップモデルに任せるのは、最も見落とされやすい無駄です。

タスク階層化をコードに落とし込む

1. システム内の LLM 呼び出しを「タスク種別」ごとに列挙します（分類 / 抽出 / 要約 / 生成 / 推論 / コード）。
2. 各タスク種別にデフォルトティアを選び、あちこちに散らばったモデル名ではなく設定に書き込みます。
3. 各タスク種別に50〜200件の固定評価サンプルを用意し、典型的な難例を含めます。
4. まずデフォルトティアでベースラインを実行し、その後ダウングレードを試して精度/フォーマット準拠率を比較します。
5. 品質損失がしきい値を下回る場合にのみダウングレードを維持し、そうでなければ前のティアに戻します。

段階的ルーティング：安いものから高いものへ

実用的なパターンは「安いものから高いものへ」です。まず軽量モデルで処理し、以下のシグナルが出たらフラッグシップモデルに昇格します——

• 出力がパースできない（JSON が壊れている、フィールド欠落）。
• モデル自身が不確実と表明する、または信頼度がしきい値を下回る。
• 業務側の品質チェックに引っかかる（例：生成された SQL が実行できない）。
• リクエストの複雑度指標がしきい値を超える（入力長、参照ドキュメント数）。

こうすることで大部分のトラフィックは安いティアに留まり、本当に難しい部分だけがフラッグシップティアに課金されます。昇格回数を監視に含めることに注意してください。昇格率が長期的に高いなら、選定を再評価すべきサインです。

ベンダー間切り替え前に確認すべきこと

異なるベンダーは同じタスクに対する出力スタイル、ツール呼び出し形式、拒否ポリシーが一致しません。あるタスク種別をベンダー A から B に切り替える前に、少なくとも以下を確認します：

• 構造化出力：JSON mode / 厳格な schema のサポート程度が一致するか。
• ツール呼び出し形式：パラメータ構造、並列呼び出し、エラー返却方式。
• コンテキスト長と切り捨て挙動：超長入力はエラーか、それとも黙って切り捨てか。
• コンテンツポリシーの差異：同じ入力があるモデルでは拒否され、別のモデルでは正常。

同じゲートウェイ内で階層化する

Admesh は外部に対して OpenAI 互換プロトコルを維持し、モデルは namespace/model の形式で公開されます（例：anthropic/…、openai/…、deepseek/…）。つまりタスク階層化は設定内に「タスク種別 → モデル」のマッピング表を1つ維持するだけで済み、コード側では常に model パラメータを変えるだけです。

ルーティングは同じ public_model のチャネルプール内でのみ行われるため、あなたの anthropic/xxx が黙って他社モデルに置き換わることはありません——階層化はあなたが明示的に選ぶものであり、ゲートウェイが代わりに決めるものではありません。

モデル一覧 API を見る →