Mistralの新モデル表から見える「統合型AI基盤」への移行｜2026年6月20日版
2026年6月20日（日本時間）時点で見るべき変化は、Mistral AIのモデル群が「用途別の単体モデル」から、推論・コーディング・エージェント実行を同じAPI面で扱う統合型モデルへ寄っていることです。
Mistralの公式モデル表では、Mistral Medium 3.5が「agentic and coding use cases」向けのフロンティア級マルチモーダルモデルとして掲げられ、Mistral Small 4は「instruct、reasoning、coding」を1つに統合するハイブリッドモデルと説明されています。開発者にとっては、単に新しいLLMが増えたという話ではありません。モデル選定、API設計、社内PoCの移行計画に関わる変更です。
今日の要点は次の3つです。
- Mistral Medium 3.5は、Devstral 2など一部旧モデルの移行先として公式表に出ている
- Mistral Small 4は、119B総パラメータ、6.5B active、256kコンテキストの効率型モデルとして提示されている
- API機能はチャット、関数呼び出し、Agents & Conversations、Structured Outputs、OCR、FIMなどを横断し、アプリ実装の単位が「モデル単体」から「実行基盤」へ移っている
重要ポイント早見表
| 項目 | 確認できる内容 | 日本の読者への影響 |
|---|---|---|
| Mistral Medium 3.5 | 2026年4月28日付。マルチモーダル、エージェント、コーディング用途向け。256kコンテキスト。 | 長文仕様書、コードベース、社内文書をまたぐAIアプリの候補になる。 |
| Mistral Small 4 | 2026年3月16日付。119B総パラメータ、6.5B active。instruct、reasoning、codingを統合。 | コストを抑えた推論・実装支援モデルとして検証しやすい。 |
| Devstral 2の扱い | 公式モデルカードでは2026年5月22日がdeprecation date、置き換え先はMistral Medium 3.5。 | 既存PoCでDevstral系を試している場合、移行計画が必要。 |
| API機能 | Function Calling、Agents & Conversations、Built-In Tools、Structured Outputsなどをモデルカード上で確認できる。 | 単発チャットより、業務フローに組み込む実装が主戦場になる。 |
何が起きたか
Mistralの公式ドキュメントでは、現在のフロンティアモデルとしてMistral Medium 3.5やMistral Small 4が並び、旧モデルの一部には代替先が明記されています。
Medium 3.5は「エージェントとコード」を前面に出した
Mistral Medium 3.5のモデルカードでは、同モデルは2026年4月28日付、Open v26.04、Modified MIT licenseのopen weightsとして説明されています。用途はマルチモーダル、エージェント、コーディングです。
確認できる主な仕様は次の通りです。
- コンテキスト長: 256k
- API価格表示: $1.5 / M tokens、$7.5 / M tokens
- 対応機能: Chat Completions、Function Calling、Agents & Conversations、Built-In Tools、Structured Outputs、OCR、FIMなど
ここで重要なのは、Mistralが「コード用モデル」「エージェント用モデル」を完全に別棚に置くのではなく、Medium 3.5へ吸収する方向を示している点です。実際、Devstral 2のモデルカードでは、Devstral 2のdeprecation dateが2026年5月22日、replacementがMistral Medium 3.5と記されています。
Small 4は効率型の統合モデル
Mistral Small 4は2026年3月16日付のOpen v26.03モデルです。説明文では、instruct、reasoning、codingを1つにまとめるハイブリッドモデルとされ、119B総パラメータ、6.5B activeという構成が示されています。
価格表示は$0.15 / M tokens、$0.6 / M tokens。Medium 3.5より軽い検証先として、チャットUI、社内検索、コード補助、簡単なワークフロー実行の試作に使いやすい位置づけです。
ここがポイント: Mistralの現在の見せ方は「大きいモデルほど賢い」という単純な比較ではなく、Medium 3.5とSmall 4を、エージェント実装・コード支援・長文処理の役割に応じて選ばせる形になっています。
なぜ重要か
この変化は、LLMアプリの作り方に直接関わります。
これまでの生成AI導入では、チャット、要約、コード補完、社内検索を別々のモデルや別々のサービスで試すケースが多くありました。しかし、Function Calling、Agents & Conversations、Structured Outputs、OCR、FIMが同じモデルカード上で並ぶと、開発者が見るべき単位は変わります。
モデル選定は「精度」だけでは足りない
Mistral Medium 3.5とSmall 4を比べると、見るべき軸は少なくとも4つあります。
- 長い入力を扱うか
- ツール呼び出しやエージェント実行を使うか
- コード生成だけでなく、既存コードの探索や編集まで任せるか
- 推論コストをどこまで許容できるか
たとえば、社内規程を読み込ませて回答するだけならSmall 4で足りる場面があります。一方で、複数ファイルのコード修正、長い設計書、OCR済み文書、外部ツール呼び出しを組み合わせるなら、Medium 3.5のような上位モデルを検証する理由が出てきます。
「推論モデル」の流れはMagistralから続いている
Mistralは2025年6月にMagistralを発表し、同社初のreasoning modelとしてMagistral SmallとMagistral Mediumを示しました。論文では、Mistral自身のモデルとインフラを使った強化学習パイプライン、テキスト上のRL、推論言語の制御などが説明されています。
2026年のMedium 3.5やSmall 4を見ると、その流れは「推論専用モデル」から「推論もコードもエージェントも扱う実装基盤」へ広がっています。これは研究上のモデル名より、プロダクトに組み込むときの実用性が前面に出てきたということです。
日本の開発者・企業利用者への影響
日本の読者にとっての論点は、Mistralを使うかどうかだけではありません。OpenAI、Google、Anthropic、AWS、Azure、国内クラウドを比較する際にも、同じ見方が必要になります。
開発者が確認すべきこと
まず見るべきなのは、モデル名ではなく運用条件です。
- APIで使うのか、自社環境へ寄せるのか
- 256kコンテキストを本当に使う設計か
- Structured Outputsで後段処理を安定させられるか
- Function CallingとAgents & Conversationsの責任範囲をどこで区切るか
- 既存のDevstral系検証がある場合、Medium 3.5への移行が必要か
特に業務アプリでは、長文を入れられることと、正しく処理できることは別です。256kの入力枠があっても、社内文書の分割、検索、権限管理、出力検証を組み合わせなければ、実運用では崩れます。
企業利用者が見るべきこと
企業側では、次の判断が現実的です。
- コスト重視の試作: Small 4を候補にする
- コードエージェントや長文業務: Medium 3.5を候補にする
- 旧モデル利用中: deprecation dateとreplacementを確認する
- 規制業種: 出力の根拠、ログ、権限、監査手順を先に設計する
Mistralのドキュメント上では、Medium 3.5もSmall 4もチャットだけでなく複数のAPI機能に接続されています。つまり、導入判断は「どのモデルが賢いか」ではなく、どの業務フローにどのモデルを置くかに移ります。
継続ウォッチ
このテーマで次に見るべき点は、かなり具体的です。
- Mistral Medium 3.5が、Devstral系の利用者にどこまで自然な移行先になるか
- Small 4の6.5B active構成が、実運用でどの程度の速度・品質・コストに落ち着くか
- Agents & ConversationsやBuilt-In Toolsが、社内システム連携でどこまで安定するか
- 競合モデルが、長文・推論・コード・ツール呼び出しをどのように統合してくるか
開発現場では、次のモデル発表を待つより、既存PoCの棚卸しが先です。モデル名、API、価格、deprecation date、代替先を一覧化すると、AI導入のリスクがかなり見えやすくなります。
今日のまとめ
Mistralの最新モデル表から見えるのは、LLMが単発のチャットモデルから、エージェント実行、コード支援、長文処理、構造化出力をまとめて担う基盤へ変わっていることです。
Medium 3.5は上位の統合モデル、Small 4は効率型の統合モデルとして位置づけられています。Devstral 2のような専門モデルがMedium 3.5へ置き換えられている点も、モデル統合の流れを示しています。
次に確認すべきなのは、新しいモデル名ではありません。自社のAIアプリが、どの入力を扱い、どのツールを呼び、どの出力を検証し、どの旧モデルから移行する必要があるのかです。