モデル選定と運用の勘所 -- 最新モデルの動向を押さえ、現場で使えるモデル選定基準と運用ルールを固める
主要プロバイダーのモデルラインナップは半年単位で塗り替わる。ここでは2025年後半から2026年初頭にかけての状況を整理する。
| プロバイダー | モデル | 強み | Context Window | 位置づけ |
|---|---|---|---|---|
| OpenAI | GPT-5.2 | Instant/Thinking/Proの3バリアント、90%キャッシュ割引 | 400K | 汎用推奨 |
| GPT-5 | マルチモーダル、前世代の最上位 | 400K | 高精度 | |
| Codex | コーディング特化版 | 400K | コード生成 | |
| Anthropic | Claude Opus 4.6 | 最新最高精度、SWE-bench 74.4%相当 | 200K（1M extended可） | プレミアム |
| Claude Sonnet 4.5 | コスパ良好、速度と精度のバランス | 200K（1M extended可） | 汎用推奨 | |
| Claude Haiku 4.5 | 超高速、低コスト、大量処理向き | 200K（1M extended可） | 高速処理 | |
| Gemini 3 Pro | 1Mコンテキスト、SWE-bench 74.2% | 1M | 高精度 | |
| Gemini 2.5 Flash / Flash-Lite | 高速・低コスト、軽量タスク向き | 1M | 高速処理 | |
| Meta | Llama 4（Scout / Maverick / Behemoth） | MoEアーキテクチャ、ネイティブマルチモーダル、200言語対応、オープンウェイト | Scout: 10M / Maverick: 400K | 自社運用 |
| Mistral | Mistral Large 3 / Medium 3.1 | 41B active（675B total MoE）、欧州発、多言語対応 | 128K | コスト重視 |
| xAI | Grok 4（標準 / Heavy） | マルチエージェント推論（Heavy版）、1Mコンテキスト | 1M | 高度推論 |
| DeepSeek | DeepSeek R1 | 推論特化、オープンウェイト、高コスト効率 | 128K | 推論特化 |
モデルを選ぶときに見るべき軸は4つある。用途、コスト、速度、精度。これらの優先順位は案件ごとに変わるが、意思決定の型は共通して使える。
| 用途 | 重視する軸 | 推奨モデル例 | 理由 |
|---|---|---|---|
| 社内チャットボット | コスト 速度 | Claude Haiku 4.5 / Gemini 2.5 Flash | 大量リクエスト対応が必要で、単価の安さと応答速度が最優先 |
| コードレビュー補助 | 精度 速度 | Claude Sonnet 4.5 / GPT-5.2 Thinking | コードの正確な理解が必須。開発者の待ち時間を減らすため速度も重要 |
| 契約書レビュー | 精度 安全性 | Claude Opus 4.5 / GPT-5.2 Pro | 法的文書はHallucinationが許されない。最高精度モデルで慎重に処理 |
| 大量データ分類 | コスト 速度 | Gemini 2.5 Flash-Lite / Claude Haiku 4.5 | 数十万件をバッチ処理するため、1件あたりの単価が決定的に効く |
| 技術文書生成 | 精度 コスト | Claude Sonnet 4.5 / Gemini 2.5 Pro | 品質は要るが毎日使うので極端な高コストは避けたい |
| 自社データ完結型 | 安全性 自由度 | Llama 4 Maverick / Mistral Large 3 / DeepSeek R1（自社ホスト） | データが外部に出せない場合、OSSモデルの自社デプロイが唯一の選択肢 |
PoCなしで本番導入したプロジェクトの半数以上が後からモデル変更を迫られる。最低でも実データ100件でのテスト評価は必須と考えるべき。
2026年2月時点でのおおよその料金帯。各社頻繁に改定するため、最新値は公式ドキュメントを必ず確認すること。
| モデル | Input | Output | コスト帯 | 備考 |
|---|---|---|---|---|
| GPT-5.2 | $1.75 | $14.00 | 中 | 90%キャッシュ割引、3バリアント構成 |
| GPT-5 | $1.25 | $10.00 | 中 | 前世代最上位、安定運用向き |
| Claude Opus 4.6 / 4.5 | $5.00 | $25.00 | 中 | Batch APIで50%割引、キャッシュで0.1x入力 |
| Claude Sonnet 4.5 | $3.00 | $15.00 | 中 | Extended Thinking対応、コスパ良好 |
| Claude Haiku 4.5 | $1.00 | $5.00 | 低 | 大量処理向き、最速クラス |
| Gemini 3 Pro | $2.00-$4.00 | $12.00-$18.00 | 中 | コンテキスト長で料金が変動 |
| Gemini 2.5 Pro | $1.25 | $10.00 | 中 | 思考トークン含む場合は要注意 |
| Mistral Large 3 | $2.00 | $5.00 | 中 | 675B MoE、コスト効率が高い |
| Mistral Medium 3.1 | $0.40 | $2.00 | 低 | 軽量タスク向き |
| Llama 4 / DeepSeek R1（自社運用） | GPUコスト依存（$1-3/h目安） | 変動 | オープンウェイト、利用量次第でクラウドAPIより安価に | |
| シナリオ | 月間処理量 | Claude Opus 4.5 | Claude Haiku 4.5 | 差額 |
|---|---|---|---|---|
| 社内FAQ応答 | 100万回（avg 500 in + 200 out tokens） | 約$7,500/月 | 約$1,500/月 | 5倍の差 |
| コードレビュー | 1万回（avg 3K in + 1K out tokens） | 約$400/月 | 約$80/月 | 5倍の差 |
| 文書要約 | 5千回（avg 10K in + 2K out tokens） | 約$500/月 | 約$100/月 | 5倍の差 |
精度要件を満たすなら安いモデルを選ぶのが正解。「とりあえず最高性能モデル」は予算を食いつぶす典型的な失敗パターンになる。Batch APIやキャッシュ割引を活用すれば、同じモデルでもコストを大幅に圧縮できる。
ユーザー体験を決めるのは精度だけではない。応答が返ってくるまでの「待ち時間」が体感品質を左右する。レイテンシを理解するための2つの指標を押さえておく。
| モデル | TTFT（目安） | TPS（目安） | 適合ユースケース |
|---|---|---|---|
| GPT-5.2 Instant | 0.2 - 0.6秒 | 70 - 120 | 対話型、リアルタイム応答 |
| GPT-5.2 Thinking | 0.5 - 2.0秒 | 40 - 80 | 推論を要する複雑なタスク |
| Claude Sonnet 4.5 | 0.3 - 0.8秒 | 50 - 90 | コード生成、文書処理 |
| Claude Opus 4.5 / 4.6 | 0.8 - 2.5秒 | 30 - 50 | 高精度タスク（速度は犠牲） |
| Claude Haiku 4.5 | 0.1 - 0.4秒 | 100 - 150+ | 大量バッチ処理、低レイテンシ必須 |
| Gemini 3 Pro | 0.4 - 1.5秒 | 50 - 90 | 高精度タスク、長文コンテキスト |
| Gemini 2.5 Flash | 0.1 - 0.4秒 | 100 - 150+ | リアルタイム処理、ストリーミング |
| Llama 4 Maverick（A100x2） | 0.5 - 1.5秒 | 20 - 40 | オンプレ環境、データ秘匿 |
思考モデル（GPT-5.2 Thinking, Gemini 3 Pro等）は内部で推論チェーンを生成するため、TTFT・TPSともに従来モデルより遅くなる傾向がある。ただし最終的な回答精度はその分高い。速度と精度のトレードオフを用途に応じて判断する必要がある。
モデルをどこで動かすかは、コスト構造とセキュリティ要件で決まる。3つの形態を比べる。
モデルを導入した後に問題が起きるのは、運用ルールを決めていなかったケースがほとんど。導入前に下記を潰しておく。
1つのモデルに全てを任せる時代は終わった。用途や負荷に応じてモデルを使い分ける戦略が主流になりつつある。代表的な3パターンを解説する。
| 戦略 | コスト効率 | 実装難度 | 精度向上 | 適用場面 |
|---|---|---|---|---|
| Routing | 高い | 中 | 中 | 多様な問い合わせが混在するチャットボット |
| Cascade | 高い | 中 | 高い | 大半が簡単だが稀に難しいケースがある処理 |
| Ensemble | 低い | 高い | 最高 | ミスが許されない重要判定（契約審査等） |
LLMの出力を自社用途に最適化する方法は3つある。安易にFine-tuningに飛びつくのはアンチパターン。まずPrompt Engineeringから始めて、それでも足りなければRAG、それでもダメならFine-tuningという順で検討する。
| 観点 | Prompt Engineering | RAG | Fine-tuning |
|---|---|---|---|
| 導入コスト | 低 | 中 | 高 |
| データ準備 | 不要 | 文書の収集・前処理 | 高品質な学習データセット数百件以上 |
| 知識の鮮度 | プロンプト更新で即反映 | 文書更新で即反映 | 再学習が必要 |
| 得意なこと | 出力形式の制御、トーン調整 | 社内固有情報の参照、根拠付き回答 | 特殊な文体、ドメイン特化の振る舞い |
| 弱点 | Context Windowの制約 | 検索精度に依存、構築コスト | 学習コスト大、過学習リスク |
| 推奨場面 | PoC段階、小規模利用 | 社内ナレッジ活用、ドキュメント検索 | 大量処理で一貫した品質が必要 |
実務では Prompt Engineering + RAG の組み合わせで8割のケースをカバーできる。Fine-tuningが必要なのは、独自の文体や業界特有の表現が厳密に求められる場合に限られることが多い。