この記事で分かること／分からないこと
- 分かること: 用途ごとにモデル(あるいはLLMを使うかどうか)を切り替える際の判断軸の整理
- 分かること: 自社実装における、LLMを使わない処理とLLMを使う処理の切り分け方の実例
- 分からないこと: 他社モデルの料金比較(本記事では扱わない、裏取りをしていないため)
- 分からないこと: 特定のモデルがどの用途に最適かという個別の推奨
モデルの切り替えは、料金表の比較から始めない
用途ごとにモデルを切り替える話は、料金表を並べて安いモデルを選ぶ比較から始まりがちである。だが料金は提供元の改定で変わり続けるため、本記事では他社の料金を扱わない。代わりに、どの処理にどの能力の実行主体(LLMか、LLM以外の機械的な処理か)を割り当てるべきかという、設計上の判断軸を整理する。
判断軸1: そもそもLLMが必要な処理か
最初に確認すべきは、その処理が本当にLLMの推論能力を必要とするかである。自社の応答検査(Layer1)は、応答から事実主張を取り出し正規化して真実集合と機械的に照合するだけの処理で、LLMを一切使わない(実体: services/verifier/src/grounding-gate.ts)。大半の判定を無料の機械照合に任せ、幻覚候補として残ったものだけをLLMによる盲検(Layer2)に回す。まず「LLM抜きで済む処理」を切り出せないかを先に検討する価値がある。
判断軸2: 判定の重さと、複数モデルを使うかどうか
LLMを使う処理の中でも、単純な抽出・分類と、根拠の妥当性を判断する重い判定とでは求められる確からしさが異なる。自社のLayer2では、sonnetとopusの2モデルが独立に判定する構成を取る(出所: out/univ-demo.report.json、確認日2026-09-06)。単一の軽いモデルで済ませる処理と、複数モデルの判定を突き合わせる処理を分ける発想は、料金の比較とは独立に成立する判断軸である。
判断軸3: レイテンシ予算と致命度
同じ「LLMを使う」処理でも、応答までの許容時間(レイテンシ予算)が短い用途と後追いで検証すればよい用途とでは選べる構成が変わる。利用者を待たせる経路には重い判定を挟みにくく、事前のビルド時や事後の検証など待たせない経路に重い判定を寄せる方が無理がない。誤りが致命的になりやすい領域かどうかも、どこまで慎重な判定を挟むかを左右する。これらは対象の性質から決まり、料金表からは導けない。
よくある質問
Q1. モデルを用途ごとに切り替える際、最初に何を確認すべきか
その処理が本当にLLMの推論能力を必要とするかを最初に確認すべきである。機械的な照合で済む処理であれば、LLMを使わない構成に切り出せないか検討する価値がある。
Q2. なぜ本記事では他社モデルの料金を扱わないのか
料金は提供元の改定で変わり続ける情報であり、本記事では裏取りをしていないためである。料金比較ではなく、設計上の判断軸の整理にとどめている。
Q3. 複数モデルを使う構成はどんな場合に検討すべきか
根拠の妥当性を判断する重い判定で、単一モデルの判定だけでは確からしさに不安が残る場合に検討の余地がある。自社の盲検では2モデルが独立に判定する構成(出所: out/univ-demo.report.json、確認日2026-09-06)を取っている。
Q4. レイテンシ予算はモデル選定にどう影響するか
応答までの許容時間が短い経路には重い判定を挟みにくいため、事前のビルド時や事後の検証など待たせない経路に重い判定を寄せる方が無理がない。
近い発想で、まとめて処理できる作業の切り出しはバッチで処理できる仕事とできない仕事の記事、実行時にLLMを呼ばない設計は確定配信という選択の記事、レイテンシの測定地点はレイテンシ計測の記事を参照してほしい。RAGの運用コスト設計について相談したい方は、お問い合わせから編集部までご連絡いただきたい。
- ハブ記事: RAGサービス比較15選
- 関連記事: RAGのレイテンシ計測
- 関連記事: バッチで処理できる仕事とできない仕事
- 関連記事: 確定配信という選択