「結局、どのモデルを使えばいいのか」——生成AIの導入を具体化する段階で、必ず出てくる問いです。結論から言うと、業務で使う生成AIモデル（LLM）の選定は「一番賢いモデルを1つ決める」作業ではなく、精度・コスト・速度・データの扱いという4つの軸を業務ごとに比べ、さらに『あとから乗り換えられる形』にしておく設計の問題です。
モデルは短い周期で新しいものが出ます。今日の最適解が半年後も最適である保証はありません。だからこそ、選定そのものと同じくらい、選び直せる状態を作っておくことが重要になります。
この記事では、モデル選定の4つの軸、どこで動かすかという提供形態の選択、タスクごとの使い分け、乗り換えられる設計、そして評価セットから始める進め方までを、FDE（Forward Deployed Engineer／フォワードデプロイドエンジニア）として現場の実装まで伴走する DeploAI が整理します。
具体的なモデル名・価格・性能は短期間で変わります。この記事では変わらない判断の軸を扱い、個別の数値は選定時点の提供元の公式情報で確認することを前提にします。
なぜモデル選定は「一番賢いものを選ぶ」で終わらないのか？
業務でのモデル選定が難しいのは、評価の指標が1つではなく、業務ごとに重みが違うからです。 ベンチマークで上位のモデルが、自社の業務では過剰であることも、逆に力不足であることもあります。
よくあるつまずきは次の3つです。
- 最上位モデルを全業務に使ってしまう：品質は問題ないものの、コストと応答時間が要件に合わない。社内問い合わせの一次応答に数秒待たされる、といった形で使われなくなります（AIツールを導入したのに使われない）。
- デモの印象だけで決めてしまう：数件の手元の例では差が出ず、実データで初めて差が出ます。自社データでの検証を省くと、本番投入後に「思ったほど当たらない」となります。
- 1つ選んで作り込み、動かせなくなる：モデル固有の書き方に依存した実装をすると、新しいモデルが出ても乗り換えの検証コストが高くつき、古いまま塩漬けになります。
モデル選定は技術の優劣を決める作業ではなく、業務要件との適合を見る作業です。 何を・どこまで・いくらで・どれだけ速く実現したいのかが決まっていないと、比較そのものが成立しません。要件の整理は生成AIの要件定義はどう進める？を参照してください。
LLM選定の4つの軸——精度・コスト・速度・データの扱い
モデルを比べるときは、次の4つの軸に分解すると判断がぶれません。 どれか1つで決めるのではなく、対象業務でどの軸が効くかを先に決めます。
LLM選定の4軸。どの軸を優先するかは業務ごとに変わる
1. 精度——「高いほど良い」ではなく「足りているか」
精度は絶対値ではなく、対象タスクで必要な水準を満たしているかで見ます。 問い合わせの一次分類なら、人のダブルチェックを前提に十分な水準があれば足ります。契約書の条項抽出のように誤りの代償が大きい業務なら、より高い水準と人の確認プロセスが必要です。
重要なのは、汎用のベンチマーク順位ではなく自社データでの結果で見ることです。業界特有の用語、社内の略語、文書の書式——こうした条件は公開ベンチマークには含まれていません。
2. コスト——件数が多い業務ほど効いてくる
多くのサービスは処理量（トークン量）に応じた従量課金です。1件あたりの差は小さく見えても、業務の件数を掛けると無視できない差になります。 月に数十件の企画書作成支援なら上位モデルでも問題ありませんが、月に数万件の問い合わせ分類なら、モデルの選択がそのまま運用コストを左右します。
コストを抑える工夫は、モデル選定だけでなく、入力の与え方や処理の分け方でも効きます（生成AIのコストはどう抑える？）。
3. 速度——精度より優先される場面がある
対話型の用途では、応答速度が体験そのものを決めます。 社内チャットで質問して10秒待たされるなら、多少精度が落ちても2秒で返るほうが使われます。一方、夜間バッチで大量の文書を処理する用途なら、応答時間はほとんど問題になりません。速度の要件は「人が待っているかどうか」で大きく変わります。
4. データの扱い——ここで選択肢が絞られることが多い
実務では、この軸が最初に効いてくることが少なくありません。 確認すべきは主に次の点です。
| 確認項目 | 何を見るか |
|---|---|
| 学習利用 | 入力したデータがモデルの学習に使われない条件になっているか |
| 処理・保存の地域 | データがどの国・地域で処理され、保存されるか |
| ログの保持 | 入出力ログの保持期間と、保持しない設定の可否 |
| 認証・権限 | アクセス制御や監査ログが業務要件を満たすか |
これらは提供元・プラン・契約形態によって異なり、条件自体も変わります。選定時点の公式ドキュメントと契約条件で必ず確認してください。 全社ルールとしての整理は生成AIの社内利用ガイドライン、セキュリティ全般は企業の生成AI活用、セキュリティはどう担保する？にまとめています。
どこで動かすか——API・クラウド・自社環境の選択
モデルの選定は「どのモデルか」だけでなく「どこで動かすか」とセットです。 同じ系統のモデルでも、提供形態によってコスト構造・運用負荷・データの扱いが変わります。
| 形態 | 特徴 | 向いている場面 |
|---|---|---|
| APIを利用する | 最新モデルをすぐ使える。運用負荷が小さい | まず立ち上げたい。利用量が読めない段階 |
| 自社のクラウド環境で動かす | データの処理範囲を自社管理下に置きやすい | 監査・統制の要件が明確にある |
| 自社サーバー・端末で動かす | データを外に出さない。利用量が増えても費用が跳ねにくい | 機密性が特に高い。大量・定常的な処理 |
選択肢の詳細は生成AIを自社環境で動かすには？、手元で動かす構成はローカルLLMとは？で扱っています。また、モデルの大きさ自体も選択肢です。範囲の定まったタスクなら、軽量なモデルで十分な品質が出ることがあります（SLM（小規模言語モデル）とは？）。
タスクごとに分けて選ぶ——「1社1モデル」にしない
業務全体で1つのモデルに統一する必要はありません。 タスクの性質が違えば、必要な水準も違います。実務では、次のように役割を分けるのが現実的です。
| タスクの性質 | 求められるもの | モデル選定の方向 |
|---|---|---|
| 分類・抽出・定型変換 | 形式の安定・低コスト・高速 | 軽量モデルで足りることが多い |
| 要約・下書き作成 | 自然さと文脈の理解 | 中位のモデルで品質とコストを両立 |
| 複雑な推論・長文の読解 | 高い推論力・長い文脈の扱い | 上位モデルが必要になりやすい |
| 外部ツールを使う自律動作 | 指示への忠実さ・出力形式の安定 | ツール利用の安定性で選ぶ |
たとえば社内の問い合わせ対応なら、「質問の分類」は軽量モデル、「回答の生成」は中位モデル、「判断が難しい案件の要約と引き継ぎ」は上位モデル、という組み合わせが成立します。1つの業務の中でも、工程ごとにモデルを分けられるという発想を持つと、コストと品質の両立がしやすくなります（社内問い合わせ対応はAIで自動化できる？、AIエージェントを業務に組み込むには？）。
なお、精度が出ないときに真っ先にモデルを変えたくなりますが、原因がモデル側ではないことも多い点には注意が必要です。社内情報を参照させる仕組み（RAG）の検索精度や、渡している文脈の設計が効いている場合があります（RAGの精度が上がらないのはなぜ？、コンテキストエンジニアリングとは？）。手段の使い分けは自社データをAIに使わせるには？を参照してください。
「選ぶ」より難しい「選び続ける」——乗り換えられる設計にする
モデルは更新され続けます。だから重要なのは、いま最良のモデルを当てることより、あとから差し替えられる構造にしておくことです。 乗り換えの検証が数日で済む状態と、作り直しになる状態では、事業としての選択肢がまったく変わります。
具体的には、次の4点を最初から押さえておきます。
- 呼び出し部分を分離する：業務ロジックの中に直接モデルの呼び出しを埋め込まず、1か所に集約します。差し替えの影響範囲を限定できます。
- 出力の形式を固定する：後続の処理が受け取る形（項目名・構造）を決めておき、モデルが変わっても後続を壊さないようにします。
- プロンプトをモデル固有に寄せすぎない：特定モデルのクセに依存した書き方は、乗り換え時にそのまま使えません。業務要件として何を求めるかを素直に書きます。
- 評価セットで回帰を見る：モデルを替えたときに、これまでできていたことができなくなっていないかを機械的に確認できるようにします。
そして、モデルのバージョンは固定して使うのが原則です。提供元が自動で更新する設定のままだと、ある日突然、出力の傾向が変わることがあります。更新は「検証してから切り替える」という運用に乗せます。監視と改善の仕組みは生成AI・AIエージェントの本番運用でつまずかないために、動きの可視化はAIエージェントのオブザーバビリティとは？で扱っています。
選定はどう進める？——評価セットを先に作る
モデル選定の進め方で最も効くのは、比較を始める前に「自社データでの評価セット」を作ることです。 評価の物差しがないまま候補を触ると、印象論で決まり、あとで覆ります。
実務では、次の順序で進めます。
- 対象タスクを1つに絞る：「生成AIを導入する」ではなく「問い合わせメールを5分類する」まで具体化します。
- 評価セットを作る：自社の実データから 30〜100 件程度を選び、期待する出力（正解）を人が用意します。難しい例・間違いやすい例を必ず含めます。
- 合格ラインを決める：どの水準なら業務に載せられるか、誤ったときに何が起きるかを先に決めます。
- 同じ条件で候補を比べる：同じプロンプト・同じ入力で複数モデルを走らせ、精度・コスト・応答時間を並べます。
- 運用条件を確認する：データの扱い・提供条件・上限などを、公式情報で確認します。
- 小さく本番に載せ、測り続ける：一部業務から始め、実際の入力で品質を継続的に確認します。
評価セットの作り方と測り方は生成AIの評価（Evals）はどうやる？で詳しく扱っています。この評価セットは、選定のためだけのものではありません。 モデルを乗り換えるとき、プロンプトを直すとき、RAGを改善するとき——毎回「良くなったか」を判断する物差しとして使い続ける資産になります。
FDEはモデル選定にどう関わるか
モデル選定は、カタログを比べれば答えが出る作業ではありません。「この業務で何を・どこまで求めるのか」という要件と、コスト・運用・データの制約を、現場の実データに突き合わせて初めて決まります。
DeploAI の FDE（Forward Deployed Engineer）は、この工程を現場に入って一緒に進めます。評価セットを業務データから作り、候補を同じ条件で比べ、乗り換えられる構造で実装し、運用に載せてからも測り続ける——「選んで終わり」にせず、モデルが変わっても成果が続く状態まで伴走するのが役割です。作るか買うかの判断から整理したい場合は生成AIは「作る」か「買う」か、進め方の全体像はAI導入がPoC止まりになる本当の理由もあわせてご覧ください。
まとめ：モデルは「決める」ものではなく「替えられる」ようにするもの
-
業務での生成AIモデル選定は、精度・コスト・速度・データの扱いの4軸を、業務ごとの重みで比べる作業。最上位モデルが常に正解ではない。
-
どこで動かすか（API／自社クラウド／自社サーバー）とモデルの大きさも選択肢に含まれる。機密度と処理量で現実的な候補は絞られる。
-
業務全体を1モデルに統一する必要はなく、工程ごとに使い分けるほうがコストと品質を両立しやすい。
-
モデルは更新され続けるため、乗り換えられる設計（呼び出しの分離・出力形式の固定・バージョン固定・評価セットでの回帰確認）が、選定そのものと同じくらい重要。
-
進め方の起点は自社データでの評価セット。物差しを先に作れば、選定も、その後の改善も同じ土俵で判断できる。
-
測り方の詳細: 生成AIの評価（Evals）はどうやる？
-
軽く動かす選択肢: SLM（小規模言語モデル）とは？
-
自社環境で動かす: 生成AIを自社環境で動かすには？
-
データの使わせ方: 自社データをAIに使わせるには？
「自社のこの業務にはどのモデルが妥当か」を、実データで具体的に見極めたい方は、FDE（Forward Deployed Engineer）サービスの資料請求・無料相談からお気軽にご相談ください。評価セットの設計から実装・運用定着まで、現場に入って伴走します。
