モデル選定と運用の勘所 -- 最新モデルの動向を押さえ、現場で使えるモデル選定基準と運用ルールを固める
主要プロバイダーのモデルラインナップは半年単位で塗り替わります。ここでは2025年後半から2026年初頭にかけての状況を整理します。
| プロバイダー | モデル | リリース日 | 強み | Context Window | 位置づけ |
|---|---|---|---|---|---|
| OpenAI | GPT-5.2 | 2025年12月 | Instant/Thinking/Proの3バリアント、90%キャッシュ割引 | 400K | 汎用推奨 |
| GPT-5 | 2025年8月 | マルチモーダル、前世代の最上位 | 400K | 高精度 | |
| Codex | 2025年5月 | コーディング特化版 | 400K | コード生成 | |
| Anthropic | Claude Opus 4.6 | 2026年2月 | 最新最高精度、[SWE-bench] Verified 80.8% | 200K（1M extended可） | プレミアム |
| Claude Sonnet 4.6 | 2026年2月 | SWE-bench Verified 79.6%（Opus 4.6比1.2%差）、初の1Mコンテキスト対応Sonnet、コンピュータ使用大幅改善 | 1M (beta) | 汎用推奨 | |
| Claude Haiku 4.5 | 2025年10月 | 超高速、低コスト、大量処理向き | 200K | 高速処理 | |
| Gemini 3 Pro | 2025年11月 | 1Mコンテキスト、[SWE-bench] Verified 76.2% | 1M | 高精度 | |
| Gemini 2.5 Flash / Flash-Lite | 2025年9月 | 高速・低コスト、軽量タスク向き | 1M | 高速処理 | |
| Meta | Llama 4（Scout / Maverick / Behemoth） | 2025年4月 | MoEアーキテクチャ、ネイティブマルチモーダル、200言語対応、オープンウェイト | Scout: 10M / Maverick: 400K | 自社運用 |
| Mistral | Mistral Large 3 / Medium 3.1 | 2025年9月 | 41B active（675B total MoE）、欧州発、多言語対応 | 128K | コスト重視 |
| xAI | Grok 4（標準 / Heavy） | 2025年7月 | マルチエージェント推論（Heavy版）、1Mコンテキスト | 1M | 高度推論 |
| DeepSeek | DeepSeek R1 / V3.2 | 2025年1月 / 2026年初頭 | R1: 推論特化OSS。V3.2: 685B（37B active）MoE、128K、高コスト効率 | 128K | 推論特化 |
モデルを選ぶときに見るべき軸は4つあります。用途、コスト、速度、精度。これらの優先順位は案件ごとに変わりますが、意思決定の型は共通して使えます。
| 用途 | 重視する軸 | 推奨モデル例 | 理由 |
|---|---|---|---|
| 社内チャットボット | コスト 速度 | Claude Haiku 4.5 / Gemini 2.5 Flash | 大量リクエスト対応が必要で、単価の安さと応答速度が最優先です |
| コードレビュー補助 | 精度 速度 | Claude Sonnet 4.6 / GPT-5.2 Thinking | コードの正確な理解が必須です。開発者の待ち時間を減らすため速度も重要です |
| 契約書レビュー | 精度 安全性 | Claude Opus 4.6 / GPT-5.2 Pro | 法的文書はHallucinationが許されません。最高精度モデルで慎重に処理します |
| 大量データ分類 | コスト 速度 | Gemini 2.5 Flash-Lite / Claude Haiku 4.5 | 数十万件をバッチ処理するため、1件あたりの単価が決定的に効きます |
| 技術文書生成 | 精度 コスト | Claude Sonnet 4.6 / 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.6 | $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.6 | 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.6 | 0.3 - 0.8秒 | 50 - 90 | コード生成、文書処理 |
| Claude Opus 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 の組み合わせで多くのケースに対応できます。Fine-tuningが必要なのは、独自の文体や業界特有の表現が厳密に求められる場合に限られることが多いです。