10月8日、Telerikが「AI Model Selection Criteria」と題した記事を公開した。LLMを使ったアプリケーション開発で、モデル選定を「精度の高さ」だけで判断していないか。プロトタイプでは問題なく動いていたモデルが、本番環境では要件を満たさないケースは珍しくない。セキュリティレビューでリージョン境界をまたいだリクエストが禁止されたり、負荷テストでレイテンシ要件を満たせなかったりと、モデルの性能以外の制約が最終的な選定を左右する。本記事が提示する4つの判断基準——ワークロード確認・デプロイ構成・規制要件・最終選定の問い——はそうした実務的な落とし穴を体系的に回避するためのフレームワークだ。

まず「何をやらせるか」を明確にする

モデルを比較する前に、タスクの要件を具体化する必要がある。汎用ベンチマークのスコアが高くても、自分たちのドキュメント形式を処理できるか、バックエンドが期待するスキーマで構造化データを返せるかは別の話だ。

記事では、実際の入力サンプルで構成した評価セットを用意することを推奨している。各モデルに対して以下の4点を確認する：

• 有用かつ正確な出力を生成できるか
• 必要なコンテキスト長と言語に対応しているか
• アプリケーションが期待するスキーマに沿った構造化レスポンスを返せるか
• ツールコールで正しい操作と引数を指定できるか

ドキュメント分類のような単純なタスクであれば小規模モデルで十分なケースもある。一方、ツールを選択しながら処理を進めるエージェント構成では、より強力な推論能力が必要になる。候補を絞り込む入口としてHugging Faceのモデルカードが活用できる。モデルカードには想定用途・制限・ライセンス・公開評価結果が記載されており、自前評価の前段階として参照できる。

デプロイ構成の4パターン

モデルが要件を満たすと確認できたら、次は「どこで動かすか」だ。記事では推論（inference）の実行場所と運用責任の観点から、以下の4つの構成を整理している。

セルフホストを選ぶ場合は、モデルの重み（weights）——学習で得られた数値パラメータ——を意図する用途に対して利用可能なライセンスで取得できるか確認が必要だ。加えて、サービングソフトウェアの保守体制と、通常時・ピーク時のGPUキャパシティが確保できるかも確認しておく。

同一モデルでも、ホスト型APIとセルフホストではレスポンスタイムや総コストが異なることがある。実際に使う構成で候補を比較することが重要だ。

規制環境での追加要件

医療・金融など規制業界では、デプロイ構成の選定がさらに厳格になる。

医療分野では、HHSのHIPAAとクラウドコンピューティングに関するガイダンスにおいて、クラウドサービスを電子的保護医療情報の処理に使用する際、ビジネスアソシエイト契約（BAA）とHIPAAセーフガードの整備が必要とされている。金融分野では、FINRAのクラウドガイダンスにおいて、インフラをクラウドに移行してもブローカーディーラーの規制責任は変わらないとしている。

規制対象データを扱う前に確認すべき項目として、記事は以下を挙げている：

• プロンプトと出力はどこで処理され、プロバイダーがトレーニングに使用する可能性はあるか
• データの保持・削除ポリシーと、アクセス・監査ログのエクスポート可否
• プロバイダーおよびサブプロセッサーに適用される契約内容
• モデル変更の承認プロセスと、以前のバージョンへのロールバック可否

最終選定の4つの問い

ショートリストが絞れたら、以下の4点で最終判断を行う：

1. ワークロードを満たしているか ── 代表的な入力で品質閾値をクリアし、必要な機能を備えているか
2. 必要な境界内でデプロイできるか ── ライセンスと契約が意図する用途を許可し、データ処理が関連ポリシーを満たすか
3. ランタイム予算を満たせるか ── 通常時・ピーク時のトラフィックでレスポンスタイムとコストが予算内に収まるか
4. デプロイを維持運用できるか ── キャパシティ管理とモデル変更の責任が明確になっているか

この4点はそれぞれ、本記事が扱ってきた「ワークロード確認」「デプロイ構成」「規制・コスト要件」「運用責任」の各フェーズに対応している。回答を記録しておくと、なぜそのモデルを選んだかの根拠が残り、ワークロードやデプロイ環境が変わった際の再検討にも使える。精度ベンチマークだけでは見えなかった制約が事後に発覚するのを防ぐ、実務的な意思決定の記録としても機能する。

詳細はAI Model Selection Criteriaを参照していただきたい。