1. 推論強度を変えられる：Highは強い。でも常用はしない
Medium 3.5ではreasoning_effortを設定できる。
"none"ならレスポンス重視。
"high"にすると、より多くの計算を使って問題を考える。
コードを書かせると、この違いはわりと分かりやすい。
補完や関数の説明、原因がある程度見えている小さなバグ修正なら、個人的にはLow寄りで十分だと思った。
Highにすると待ち時間は増えるが、毎回それだけ回答が良くなるわけではない。
逆に、複数ファイルにまたがる修正や依存関係の追跡になると、Highの価値が出てくる。
実際、複数ファイルにまたがる問題を試したとき、最初の段階ですでにエラー原因は見つけていた。
ところがHighではそこで止まらず、さらに一段深く依存関係を追い始めた。
最終的な修正は確かに良くなった。
でも、待ち時間もはっきり長くなった。
そこで少し腑に落ちた。
Highは必ずしも「急に頭が良くなる」モードではない。どちらかというと、「簡単には答案を提出しない」モードに近い。
難しい仕事なら、それが効く。
毎回必要かと言われると、たぶん違う。
2. 画像対応：単体では普通、コードと一緒になると便利
Medium 3.5は画像も直接扱える。
UIのスクリーンショット、フローチャート、数式が入った画像などを読み取れる。
ここだけを見ると、それほど驚きはない。
このクラスのAIモデルなら、画像対応はかなり一般的になった。
面白いのはコードと同じモデルで扱えることだ。
たとえばフロントエンド開発なら、完成イメージのスクリーンショットとコードを一緒に渡せる。
デバッグでも、エラー画面、構成図、関連ファイルをまとめて見せられる。
こうなると画像認識は独立した機能ではなく、Agentが状況を理解するための入力手段のひとつになる。
自分はこの使い方のほうがずっと実用的だと思う。
3. Function CallingとAgent：ここでMedium 3.5の狙いが分かる
Function Callingと構造化JSON出力に対応している。
256Kの長いコンテキストと組み合わせれば、コード、過去の操作、ツールの実行結果を残しながら長めの処理を続けられる。
Mistral自身もMedium 3.5をVibe Coding Agentで使っている。
CLIやLe Chatからクラウド上のコーディングセッションを開始し、コード変更、依存関係のインストール、テスト実行、Pull Requestの作成まで複数ステップで進められる。
ここで、このモデルの設計が急に分かりやすくなる。
256Kコンテキストは、Agentがコードと作業履歴を抱えるため。
reasoning_effortは、難しいステップだけ計算量を増やすため。
Function Callingは、モデルに外部ツールを触らせるため。
画像対応は、UIやスクリーンショットまで作業ループに入れるため。
ひとつひとつは珍しくない。
でも全部並べると、Mistralが考えていることはかなり見えてくる。
「Coding Agentが途中で崩れずに仕事を続けるには何が必要か？」から逆算して作った感じがする。
自分がMedium 3.5で一番面白いと思ったのは、ここだ。
4. Mistral Medium 3から何が変わった？
Medium 3からMedium 3.5への変化は、「3.5」という名前から想像するより大きい。
まず画像を扱えるようになった。
Medium 3は基本的にテキスト中心だったが、3.5ではネイティブの画像理解が入っている。
コンテキストも128Kから256Kへ倍増した。
普段のチャットでは128Kでも256Kでも大差を感じないかもしれない。
大きなコードベースや長いAgent処理を扱うと、この差が効いてくる。
指示追従、推論、コーディングもひとつのモデルにまとめられた。
さらに、Function Calling、ツール利用、長いコンテキスト、画像、コーディングが以前より自然につながっている。
SWE-Bench Verifiedも77.6%まで伸びた。
ただ、自分はこの数字より別の変化のほうが大きいと思う。
Medium 3は「コードも書ける汎用モデル」だった。Medium 3.5は「Coding Agentを作る前提のモデル」にかなり近づいた。
ここが一番の進化だ。
コメント（0件）