どの大規模言語モデルをエージェントに使うかは、プロジェクトの中でも最も重要な技術的決定のひとつです。

この選択は、エージェントのパフォーマンス、運用コスト、そして時間をかけてどれだけ安定した動作をするかに影響します。

絶対的に優れたモデルはありません。最適な選択は、目標、予算、出力に対するコントロールの必要度によって異なります。

この決定を急ぐと、後で後悔することがよくあります。重要なのは、早い段階でテストし、優先順位を明確にし、特定のベンダーや構成に縛られないことです。

良いLLM戦略は、主に4つの質問に答えます：

1. どのモデルを使うのか、そしてその理由は？
2. どのくらいの頻度で他の選択肢をテストするか？
3. あなたのユースケースで重要なのはスピードか、それとも性能か？
4. モデルが失敗したり品質が落ちた場合のバックアッププランは？

これらをひとつずつ見ていきましょう。

モデル選びは“有名さ”ではなく“適合性”が大切です。速くて安価なモデルもあれば、遅いけれど複雑な推論が得意なモデルもあります。

短い顧客対応が主な用途なら、レイテンシやコストが深さよりも重要になるかもしれません。

複数ステップの推論や詳細な要約が必要な場合は、性能が最優先になるでしょう。

早期かつ頻繁なテストによって、モデルがあなたのデータでどう動くかを把握できます。LLMにはそれぞれ癖があります。指示の理解が得意なもの、トーンの一貫性や精度に優れるものなどさまざまです。これは実際のワークフローで試してみて初めて分かります。

バックアップの計画も同じくらい重要です。最も安定したAPIでも、時には挙動が変わったり、品質が落ちたり、ダウンすることがあります。必ずバックアップ用のモデルと、パフォーマンスが基準を下回ったときに切り替えるルールを決めておきましょう。（または、Botpressのようにデフォルトのバックアップオプションを提供するエージェントビルダーを利用しましょう）

Terminal Roastでは、会計担当のRossがコスト計算を担当しています。チームは、エージェントがコーヒーやペストリーに関する簡単な顧客チャットを遅延なく対応できることを重視しています。いくつかの選択肢をテストした結果、Gemini 2.5 Flashを採用することにしました。これは速くて安価で、カジュアルな顧客対応には十分な推論力があります。

バックアップとして、レイテンシやエラー率がしきい値を超えた場合にセカンダリモデルへ自動で切り替えるよう設定しています。この選択により、ユーザー体験はスムーズで、運用コストも予測しやすくなります。

Rossは、将来的にエージェントの対応範囲が広がった場合には、モデルの選択を見直すことも考えています。

モデル選択はビジネス上の決断でもあります。誤った選択は運用コストを倍増させたり、ユーザー対応に不要な遅延を生むことも。適切な選択は、提供したい体験に合わせてパフォーマンスとコストのバランスを取ります。

柔軟性も同じくらい重要です。ひとつのモデルに依存しすぎると、後で切り替えるのが困難になります。複数モデルに対応した抽象化レイヤーやベンダーを利用し、状況の変化に適応できるようにしましょう。

この柔軟性が、システムの強靭さを保ち、特定のプロバイダーのロードマップや価格モデルに依存しない状態を実現します。

実践的なLLM戦略を作るには、次の3点を文書化しましょう：

• 主要モデルと、その選定理由
• 切り替えを検討するためのパフォーマンスとコストの基準値
• バックアップモデルと、その発動ルール

これらの決定は少なくとも四半期ごとに見直しましょう。LLMの進化は非常に速く、新しいモデルがより低コストで既存モデルを上回ることも多いです。一度きりの設定ではなく、継続的な見直しが必要です。

Terminal Roastがスピードと予測可能性を重視した決断は、最初の導入を持続可能なものにしています。顧客満足度を維持し、コストを抑え、技術的な不安定さなく実データを集めることができます。

このバランス――適切なモデル選択、変化への備え、柔軟性の確保――が、実験的なプロジェクトと本番運用を分けるポイントです。

LLM戦略は、常にビジネス目標を支えるものであり、ビジネス目標に縛られるものではありません。

アクション： どのモデルを使う予定か、あなたのユースケースで最も重要なのは何か（スピード、コスト、深さ）、そしてバックアップの選択肢は何かを書き出しましょう。利用データを集めながら、これらの選択を定期的に見直してください。

‍