会話・推論・画像理解・コーディングを1つのモデルに — Mistral Small 4 が実現した「統合MoE」の中身

チャットにはPixtral、推論にはMagistral、コーディングにはDevstral。Mistralのモデルを使い分けている開発者なら、この面倒さに覚えがあるだろう。タスクごとにモデルを切り替え、APIキーを管理し、プロンプトの書き方を変える。できれば1つにまとめたい、と思っていたはずだ。

Mistral Small 4は、まさにその「1つにまとめた」モデルだ。

119Bの中身 — 128人の専門家、動くのは4人

Mistral Small 4はMixture-of-Experts（MoE）アーキテクチャを採用している。総パラメータは119B。だが実行時にアクティブになるのはそのうち4つのエキスパートだけで、約6B（埋め込み・出力層を含めて8B）相当の計算量で動く。

128のエキスパートから4つを選ぶ仕組みが、このモデルの設計の核心だ。密度6Bの軽いモデルと同じ推論コストで、119Bの知識の幅にアクセスできる。

統合されている能力は4つ。

会話（Instruct） — Pixtral相当の自然言語理解。日常的なチャットや指示応答をこなす。

推論（Reasoning） — Magistral相当の深い思考。数学や論理的分析が必要なタスクで、推論の深さをreasoning_effortパラメータで動的に調整できる。低レイテンシの軽い応答から、時間をかけた深い推論まで、APIの1パラメータで切り替わる。

マルチモーダル（Vision） — テキストと画像の両方を入力として受け付ける。ドキュメント解析、スクリーンショットの読み取り、図表の理解に使える。

コーディング（Agentic Coding） — Devstral相当のコード生成・デバッグ能力。SWE-BenchやLiveCodeBenchで高スコアを記録している。

この4つを、モデルの切り替えなしに1回のAPI呼び出しで使えるのがSmall 4の価値だ。

料金とライセンス — ここが一番の売り

Apache 2.0ライセンス。完全オープンソースだ。

つまり、セルフホストすればAPIコストはゼロ。H100×4枚以上の環境があれば、自社サーバーで自由に動かせる。商用利用も制限なし。微調整も自由。

APIで使う場合は、Mistral公式プラットフォーム経由で入力$0.15/出力$0.60（per 1Mトークン）。これはGPT-5.5の入力$5/出力$30と比べると33倍安い。Claude Sonnet 4.6の入力$3/出力$15と比べても20倍のコスト差がある。

もちろん性能も20倍違うかというとそんなことはない。Small 4は名前の通り「Small」であり、Opus 4.8やGPT-5.5のような最先端フラグシップとは正面から競合しない。だが、6B相当の推論コストで得られる品質としては、率直に言ってかなり良い。

コンテキストウィンドウは256Kトークン。長い文書の一括処理にも対応する。

ローカルで動かす

Ollamaがインストール済みなら、コマンド1行で始められる。

ollama run mistral-small-4

ネットワーク接続もAPIキーも不要。手元のマシンで完結する。

ここが正直、一番刺さるポイントだと思う。ローカルLLMを試したい層にとって、「チャットもコードもビジョンも推論も全部入り」のモデルが1本で済むのは大きい。これまでは用途ごとに別のモデルをダウンロードしていた手間が消える。

ただし、119Bのフルモデルをローカルで快適に動かすにはGPUメモリが必要だ。量子化版を使えばメモリ要件は下がるが、精度とのトレードオフになる。M4 MacのようなユニファイドメモリのマシンならQwen3あたりと同じ感覚で試せるが、8GBメモリのノートPCでは厳しい。

Mistral Medium 3.5 との使い分け

Mistralには現在、Small 4の上位にMedium 3.5（128B、密度モデル）がある。Medium 3.5はLe Chatのデフォルトモデルで、長時間のコーディング作業やリモートエージェント向けに設計されている。

正直なところ、用途が被る部分は多い。目安としては、短めの応答やツール呼び出しが中心の「軽い仕事」はSmall 4、長時間のエージェント的な作業やコードベース全体にまたがるリファクタリングはMedium 3.5、という棲み分けが自然だろう。コストを最小化したいならSmall 4、品質を最大化したいならMedium 3.5という選び方になる。

何が変わるか — 1モデル統合の可能性

Small 4の本質は「3つのモデルを1つにした」ことではなく、「モデルの切り替えコストをゼロにした」ことにある。

たとえば、AIエージェントを構築する場合を考える。ユーザーの質問を理解する（Instruct）→ 画像を分析する（Vision）→ ロジックを推論する（Reasoning）→ コードを生成する（Coding）という一連のフローを、すべて同じモデルで処理できる。コンテキストを維持したまま、タスクの種類が変わっても同じ推論パイプラインの中で完結する。

LangChainやDifyのようなワークフロー基盤と組み合わせれば、ステップごとにモデルを切り替える複雑な設定が不要になる。エージェントの構成がシンプルになれば、デバッグも保守も楽になる。

もうひとつ、コスト面のインパクトが大きい。APIコスト$0.15/$0.60でこれだけの統合能力を持つモデルは、プロトタイピングの敷居を大幅に下げる。アイデアを素早く形にして検証し、スケールが必要になったら上位モデルに切り替える — という使い方が現実的になる。

Mistralの「統合」戦略が成功するかは、これからのベンチマーク推移とコミュニティの実使用報告次第だ。だが少なくとも、「用途ごとにモデルを使い分ける」時代の面倒さに対する、一つの明確な回答にはなっている。