生成AIの選定では、「どのモデルが最も賢いか」という質問が繰り返される。
しかし、企業システムにとって本当に重要な問いは別である。
- この仕事に必要な精度はどれくらいか
- 何秒まで待てるか
- 1件当たりいくらまで払えるか
- 失敗した場合の影響は何か
- 外部ツールを使う必要があるか
- どのデータを扱えるか
- 人間の確認を入れるか
すべての処理を最上位モデルへ送れば、試作は簡単になる。しかし、利用量が増えると、費用、待ち時間、供給制約、ベンダー依存が問題になる。
AIの本番設計は、最強モデルを選ぶことではなく、仕事ごとに必要十分なモデルを割り当てることである。
モデルの性能は一つの数値ではない
モデル比較では、総合ベンチマークの順位が注目される。しかし実務で必要な能力は分かれている。
| 能力 | 影響する業務 |
|---|---|
| 文章理解 | 問い合わせ、文書分類、検索 |
| 推論 | 審査、分析、複雑な判断 |
| コーディング | 実装、修正、テスト生成 |
| 長文処理 | 契約書、議事録、調査資料 |
| ツール利用 | 検索、DB操作、業務実行 |
| 画像理解 | 書類、画面、図表、現場写真 |
| 応答速度 | 接客、音声、入力支援 |
| 出力安定性 | API連携、構造化データ |
| データ管理 | 機密情報、地域要件、監査 |
あるモデルが複雑な推論で優れていても、単純な分類では過剰である。低遅延が必要な音声応答と、数分かけてもよい調査では、最適なモデルが異なる。
「一番強いモデル」という表現は、業務条件を消してしまう。
最初は高性能モデルで基準を作る
コスト削減を急ぎ、最初から小型モデルだけで試すと、失敗の原因を切り分けにくい。
- モデル能力が不足しているのか
- 指示が曖昧なのか
- 参照データが悪いのか
- ツール設計が悪いのか
- そもそもAIに向かないのか
OpenAIのエージェント構築ガイドは、まず高性能モデルで性能基準を作り、その後、許容品質を保てる処理を小型モデルへ置き換える方法を推奨している。
順序は次である。
- 最も能力の高いモデルで試作する
- 業務評価セットで基準を測る
- タスクを分解する
- 単純な部分を小型・高速モデルへ置き換える
- 品質、費用、速度を再評価する
- 失敗時のフォールバックを追加する
最初から安さだけを最適化するのではなく、達成可能な品質を確認してから削る。
一つの業務にも複数の難度がある
問い合わせ対応を例にすると、すべての質問が同じ難度ではない。
低難度
- 営業時間
- 送料
- パスワード再設定
- 定型的な商品情報
中難度
- 複数条件を含む商品選定
- 注文状況と規約を組み合わせた回答
- 軽微なトラブルシューティング
高難度
- 返金可否の例外判断
- 契約解釈
- 不正利用の疑い
- 法的・安全上の問題
低難度の質問まで高価な推論モデルへ送る必要はない。一方、高難度の判断を安価なモデルだけに任せれば、誤りの費用が推論費用を上回る。
入力を分類し、難度、リスク、必要能力に応じて処理先を変えるのがルーティングである。
典型的なルーティング構成
実務では、次のような段階構成が使える。
- ルールで明確なケースを処理する
- 小型モデルで分類、抽出、定型回答を行う
- 不確実なケースを高性能モデルへ送る
- 高リスクケースを人間へ送る
例えば請求書処理なら、次のようになる。
| 処理 | 適した方法 |
|---|---|
| ファイル形式確認 | 通常のコード |
| 金額・日付抽出 | 小型モデルまたは専用OCR |
| 勘定科目候補 | 中程度のモデル |
| 規程例外の判断 | 高性能モデル |
| 高額・不審取引 | 人間承認 |
AIを一つの箱として扱うのではなく、業務工程の各部分へ異なる方法を割り当てる。
ルーター自身の誤りを評価する
ルーティングを導入すると、新しい失敗が増える。難しい質問を簡単と誤分類し、小型モデルへ送る可能性がある。
したがって、最終回答の精度だけでなく、ルーターの判断を評価する必要がある。
- 高難度を低難度へ送った割合
- 低難度を高性能モデルへ送りすぎた割合
- 人間へ送るべきケースを自動処理した割合
- 不要なエスカレーション率
- 再処理率
- ルーティング後の総費用
- ルーティングによる待ち時間
特に、高リスク業務では「迷ったら上位へ送る」設計が必要である。
信頼度スコアを真実として扱わない
モデルが返す信頼度や確率は、実際の正答率と一致するとは限らない。「95%確信しています」という文章に意味はない。
信頼度を使うなら、過去の評価データと照合し、校正する必要がある。
例えば、モデルが高信頼と判定したケース100件のうち、実際に何件正しかったかを見る。業務カテゴリ別に差があるなら、閾値も分ける。
より安全なのは、信頼度だけに頼らず、次を組み合わせることだ。
- 必須情報の有無
- 根拠資料の取得可否
- ルールとの矛盾
- 複数モデルの一致
- 出力形式の検証
- 高リスク語句や条件
- 人間承認の要否
フォールバックは障害対応だけではない
フォールバックとは、API障害時に別モデルへ切り替えるだけではない。
品質上のフォールバックも必要である。
- JSON形式に失敗したら再試行する
- 根拠がない場合は検索を追加する
- 小型モデルで不合格なら上位モデルへ送る
- 上位モデルでも不確実なら人間へ送る
- 外部ツールが失敗したら処理を止める
- 制限時間を超えたら簡易回答へ切り替える
重要なのは、失敗を隠して別の回答を作り続けることではない。どの条件で再試行し、どの条件で停止するかを決めることである。
コストはトークン単価だけで計算しない
安いモデルを使っても、精度不足で何度も再試行すれば高くなる。
見るべき総原価は次である。
総原価 = 推論費用 + 検索・ツール費用 + 再試行費用 + 人間確認費用 + 誤りの修正費用 + 事故リスク
高性能モデルの単価が高くても、初回成功率が高く、人間修正が減るなら総原価は低くなることがある。
逆に、単純な分類へ高性能モデルを使えば、品質差がほとんどないまま費用だけが増える。
単価比較ではなく、成功した業務1件当たりの原価を見る。
速度も利用者価値の一部である
高度な推論を使うほど、回答に時間がかかる場合がある。
利用者が画面の前で待つ業務では、数秒の差が体験を悪化させる。一方、夜間に実行する分析や、非同期の調査では、時間をかけて品質を上げられる。
処理を次のように分ける方法もある。
- まず高速モデルで受付と暫定回答を返す
- 裏側で高性能モデルが詳細を検証する
- 結果が変わる場合だけ通知する
- 長時間処理は非同期タスクへ移す
「高精度だが遅い」と「高速だが限定的」を競合させず、役割を分ける。
ベンダー分散には利点と費用がある
複数社のモデルを使えば、障害、価格変更、供給制限、特定能力への依存を減らせる可能性がある。
一方、完全な交換可能性を期待してはいけない。
モデルごとに次が異なる。
- プロンプトへの反応
- ツール呼び出し形式
- 構造化出力の安定性
- 安全制約
- コンテキスト管理
- キャッシュ
- 速度
- 監査機能
- データ保持条件
抽象化レイヤーを厚くしすぎると、各モデル固有の強みを使えなくなる。逆に直接依存しすぎると、切り替えが難しくなる。
現実的なのは、業務入力、期待出力、評価セット、ログ形式を共通化し、モデル固有部分をアダプターとして分離する方法である。
モデル構成を固定しない
モデルは更新され、価格と性能も変わる。現在の最適構成は半年後も最適とは限らない。
そのため、モデル名を業務ロジックへ直接埋め込むより、役割で指定する方がよい。
- fast-classifier
- standard-writer
- deep-reasoner
- code-agent
- vision-reader
- safety-reviewer
各役割へ実際のモデルを割り当て、評価結果に応じて変更する。
変更前後で同じ評価セットを実行し、品質、費用、速度を比較する。これにより、モデル更新を宣伝文句ではなく自社データで判断できる。
結論
AIモデル選定を一社、一製品、一ランキングの勝敗として考えると、本番システムは高価で硬直的になる。
業務には、簡単な分類、定型生成、複雑な推論、高リスク判断が混在している。必要な能力も、許容できる費用と待ち時間も異なる。
したがって、企業が持つべきなのは「採用モデル一覧」ではない。業務を難度とリスクで分け、適切なモデル、通常コード、人間判断へ振り分け、評価結果に応じて構成を変更できるルーティング能力である。
最強のモデルを買うことは戦略ではない。必要十分な知能を、必要な場所へ、必要な条件で配置することが戦略である。