AIを業務へ組み込むとき、最初は一つの高性能モデルへすべてを任せたくなります。選択肢が一つなら実装は簡単で、モデルごとの差も考えなくて済むからです。しかし、要約、分類、検索、企画、コードレビュー、顧客向け回答を同じモデルで処理していると、やがて費用と待ち時間の両方が気になり始めます。反対に、安さだけを理由に軽量モデルへ寄せると、重要な判断まで不安定になります。
ローカルLLMの構成やAIワーカーの分け方を考える中で、私は「どのモデルが最強か」よりも、どの仕事を、どの条件なら、そのモデルへ渡せるかを決める方が重要だと考えるようになりました。モデル選定はランキングではなく、仕事の編集です。
なぜ高性能なAIモデルをすべての仕事に使うと無駄が増えるのか
AIへ渡している仕事は、見た目以上にばらばらです。受信メールを三分類する処理と、契約条件の矛盾を洗い出す処理では、誤りが起きたときの損失が違います。数語のタグを返す処理と、複数資料を横断して提案を作る処理では、必要な文脈量も違います。
それでも「高性能なモデルなら全部うまくいく」と一括処理すると、簡単な仕事にも高い単価と長い応答時間を払うことになります。一方で、最上位モデルであっても、入力が欠けていたり、参照先が間違っていたりすれば正解は返せません。モデルの大きさは、設計不備を埋める万能薬ではありません。
Microsoft Foundryの公式資料では、モデルルーターは入力の複雑さ、推論の必要性、タスク種別を見て、軽量モデルと高性能モデルを振り分けます。Amazon Bedrockにも、要求ごとの応答品質を予測し、同一ファミリー内のモデルを選ぶ仕組みがあります。大手基盤にもルーティングが用意されているのは、すべての要求に最大モデルを使うことが合理的ではないからです。
AIモデルの使い分けは「タスクの失敗コスト」から決める
最初に見るべきなのは、ベンチマークの順位ではなく、その処理が間違えたときに何が起こるかです。私は次の五つで仕事を分類します。
| 判断軸 | 軽量モデルへ寄せやすい条件 | 高性能モデルへ寄せる条件 |
|---|---|---|
| 失敗コスト | 人がすぐ直せる下書き・分類 | 顧客回答、契約、意思決定に直結 |
| 複雑さ | 出力形式と正解条件が明確 | 複数資料の統合、曖昧な推論 |
| 処理量 | 同形の要求が大量に続く | 件数は少ないが一件が重要 |
| 待ち時間 | 即時応答が必要 | 数十秒待っても精度を優先 |
| 機密性 | 外部送信可能な情報 | 社外へ出せない情報を含む |
ここで大切なのは、表の右側をすべて同じクラウドモデルへ送ることではありません。たとえば機密性が高い処理は、社内環境のモデルや匿名化工程を選ぶ理由になります。一方、長い資料を高精度に統合する仕事は、利用規約とデータ処理条件を確認した上で、高性能なクラウドAPIを選ぶ方が現実的な場合があります。
まずは業務を「軽い／重い」の二択にせず、失敗時に人が戻せるか、利用者へ直接届くか、正解を機械的に検査できるかまで書き出します。この分類が、モデル名より長く使える設計資産になります。
ローカルLLMとクラウドAPIはどの業務へ割り当てるか
ローカルLLMには、入力を自分の管理下に置きやすく、繰り返し処理のAPI従量費を抑えられる可能性があります。定型分類、文書からの項目抽出、検索前のクエリ整形など、正解条件を定義しやすい処理は候補になります。
ただし「ローカルなら無料で安全」という理解は危険です。GPUや電力、監視、モデル更新、アクセス制御、障害対応には費用がかかります。モデルを何本も常駐させればメモリを圧迫し、必要時に読み込めば初回応答が遅くなります。機密情報も、ログや権限が雑なら内部から漏れます。
クラウドAPIは、高度な推論、長い文脈、更新速度、運用負担の軽さで優位になりやすい一方、入力可能な情報、単価、レート制限、提供元への依存を確認する必要があります。したがって選択は思想ではなく、総費用、データ境界、品質、待ち時間を同じ表で比較する作業です。
LLMルーターは三段階で設計する
最初から学習型の賢いルーターを作る必要はありません。実際の入力分布が分からない段階で自動判定を高度化すると、なぜそのモデルが選ばれたのか分からない仕組みが一つ増えるだけです。私は、まず静的なルールから始める方がよいと考えています。
1. 入力を分類する
タスク種別、入力長、機密区分、利用者、求める出力形式を取得します。軽量モデルで分類する案もありますが、初期は画面やAPIごとに種別を固定するだけでも十分です。分類自体の誤りが新しい障害になるためです。
2. 必要十分なモデルへ渡す
「短文分類はモデルA」「社内文書の抽出はローカルB」「顧客へ届く提案はモデルC」のように、選択理由を人が説明できる表にします。出力トークン上限も同時に決めます。待ち時間や費用はモデルだけでなく、入力と出力の長さにも左右されるからです。
3. 失敗時に強いモデルへ切り替える
形式違反、根拠不足、低い確信度、タイムアウトを検知したら、強いモデルか人へ戻します。Microsoftのモデルルーターも複数モデルによるフェイルオーバーを前提にしています。重要なのは、切り替えを隠さず、最初のモデル、失敗理由、再実行先をログへ残すことです。
モデル切替で品質を落とさない評価方法
ルーティングは導入時より、変更時に壊れやすい仕組みです。モデル更新や料金改定のたびに経路を変えるなら、最低限、次を同じ条件で比較します。
- 代表的な実入力を匿名化して評価セットにする。
- 正解率だけでなく、根拠の有無と形式遵守を採点する。
- 一件当たりの費用と応答時間を記録する。
- 最初のモデルで完了した割合と、再実行率を分ける。
- 失敗が利用者へ届く前に検知できた割合を見る。
- 品質が基準を割ったら、以前の経路へ戻せるようにする。
RouteLLMの研究と公式実装も、強いモデルへ送る閾値を、自分の入力分布に合わせて調整する考え方を示しています。公開ベンチマークで良いルーターでも、自社の短い定型文や専門用語で同じ結果になるとは限りません。評価セットは、華やかなデモではなく、実際によく来る地味な入力から作るべきです。
さらに、自動ルーター自体にも推論時間と費用がかかります。要求が一種類しかない小さな機能なら、固定モデルの方が速く、説明もしやすい。ルーティングは複雑さを減らす道具であり、複雑さを見せるための機能ではありません。
最強モデルを選ぶより、役割を編集できる構造を持つ
AIモデルの更新は速く、今日の最適解を固定しても長くは続きません。だから私は、モデル名を業務コードへ直接書き込むより、「この処理には、どの品質条件と制約が必要か」を設定として残したい。モデルが変わっても、仕事の条件は比較的残るからです。
最初の一歩は小さくて構いません。現在AIへ渡している仕事を十件ほど並べ、失敗コスト、機密性、複雑さ、量、待ち時間を記入する。軽量モデルで完了させる処理、高性能モデルへ直送する処理、失敗時だけ切り替える処理の三つに分ける。そして、経路ごとのログを取る。
一つのAIに依存しないことは、モデルを大量に契約することではありません。仕事を観察し、必要な能力を分解し、結果を見ながら割り当てを変更できる状態を持つことです。最強のモデルを探し続けるより、役割を編集できる仕組みを作る。その方が、変化の速いAIを、長く使える道具に変えられると考えています。
