AI実装録 / モデル選定と多層構成
モデル選定と多層構成 — 用途ごとの適所配置
最終更新: 2026年7月30日

「どのモデルを使うか」は、AI を業務に組み込む際の最初の設計判断です。 最上位のモデルですべてを賄えば品質は安定しますが費用が見合わず、最安のモデルに寄せれば品質が業務要件を割り込みます。
本稿では、モデル選定の判断軸と、複数のモデルを役割で使い分ける多層構成について整理します。
選定の三軸
モデル選定は、次の三軸の均衡で判断します。
- 性能:業務の合格基準(評価と品質 参照)を満たすか。ベンチマークの数値ではなく、自社の評価サンプルでの結果を基準にします。
- 費用:単価はモデル間で桁が変わります。また同じモデルでも、入力トークンと出力トークンで単価が数倍異なる料金体系が一般的です。「何回呼ぶか × 1 回あたり何トークンか」まで含めて見積もります。
- 応答速度:対話用途では応答の開始までの時間が体感を決めます。バッチ処理では速度より単価と品質を優先できます。
この三軸は独立に動きます。 「高性能・低単価・高速」をすべて満たすモデルは存在しないため、用途を分割し、用途ごとに軸の優先順位を決める ことが実務の出発点になります。
多層構成の基本形
当社では、処理を次の三層で捉えます。
- 上位モデル(重い判断・生成):品質が最優先で、実行回数が少ない処理。長文の編纂、複雑な判断の下書き、コードの実装。
- 軽量モデル(大量・定型):分類、抽出、要約、一次判定など、単純だが回数の多い処理。上位モデルの前処理として置くことで総費用を抑えます。
- モデル以外(機械的検証):スキーマ検証、禁則語彙の判定、形式チェックは、LLM ではなく通常のプログラムで行います。最下層にモデルを置かない ことが、費用と再現性の両面で効きます。
当社が運営する京都の街コンテンツ配信基盤(プロンプト管理と回帰 の具体例と同じ案件)では、次の配置を採っています。
- 編纂本体は上位モデルの単発実行:1 件あたりの生成は重いものの、対象は通り数十件・更新は週次〜月次で、実行回数が少ない。品質最優先の判断です。単価の高いモデルでも、実行回数が少なければ総費用は小さく収まります。
- 生成後の検証はモデルを使わない:JSON スキーマ適合、京都弁語尾の非出現、出典ライセンス表記の有無は、すべて機械的なバリデータで判定します。
- 人間の目視は月次サンプリング:全件レビューはせず、月次で数件を確認します。
「上位モデル + 機械検証 + 人間サンプリング」の三層で、モデルの多段呼び出しをせずに品質と費用を両立させた構成です。
モデルは差し替え可能に保つ
モデルの世代交代は数ヶ月単位で起きます。 特定モデルを前提にした実装は、次の世代への移行費用を高くします。
- モデル ID・生成パラメータは設定として外部化し、コードから分離します。
- 切替時は回帰サンプル集で検証してから移行します(プロンプト管理と回帰 参照)。
- 切替の判断と結果は判断ログに残します。
「最上位モデルで全部」は品質面の安心と引き換えに、利用量が増えた時点で費用が跳ねます。 逆に「最安モデルで全部」は、導入時の見積りは通りやすいものの、品質が業務要件を割り込み、結局人間の後処理コストとして跳ね返ります。
どちらの失敗も、原因は同じです。用途を分割せず、一つのモデルにすべての軸を負わせていることです。
まとめ
モデル選定は「どれが一番良いモデルか」ではなく、「この用途では何を優先するか」の設計です。 上位モデル・軽量モデル・モデル以外の三層で処理を配置し、差し替え可能な形を保つことが、費用と品質を長期に両立させる基盤になります。
運用開始後の費用監視については 信頼性と運用 で扱っています。