Mistral Large 4の133エージェントによるDjangoデモ：Djangoがすでに修正していたバグを再現した

Mistral AIがLe Chonkと名付けた1.05兆パラメータのオープンウェイトモデル、Mistral Large 4は、2026年11月4日にエンドツーエンドのセキュリティ研究者として発表された。Mistralの公式Xアカウントの投稿は、このモデルが「重大な脆弱性を見つけ、それを証明し、修正できるか」と問いかけ、その後、133体のエージェント、Djangoのコードベース、90倍速のタイムラプスで答えた。その投稿はCVEを名指ししていない。パッチも公開していない。実行時間、トークン数、誤検知数、技術記事へのリンクも示していない。

タイミングが候補を絞り込む。Djangoのセキュリティチームは前日、2026年11月3日に、6件のCVEに対する修正を6.1.3、6.0.10、5.2.19でリリースしていた（1件は5.2向けのパッチが記載されていない）。もしそのバッチが対象だったなら——そしてそれはその週にニュースになった唯一のDjango CVEバッチだ——、デモが未知の脆弱性を発見したはずはない。6件すべてが動画公開前に公開済みで修正済みだったからだ。また、重大な脆弱性でもなかった。1件は中程度の評価で、残り5件は低と評価されていた。

それはデモを無価値にするわけではない。発見の主張ではなくワークフローの実演にするのであり、その区別は、オープンウェイトモデルがセキュリティチームのトリアージキューに一席を得られるかどうかを判断する誰にとっても重要だ。

Mistralが実際に見せたもの

投稿は短い。「Mistral Large 4 は重大な脆弱性を見つけ、証明し、修正できるか？ 最近の Django CVE で試してみた。133 のエージェントがコードをマッピングし、欠陥を探し、攻撃シナリオをテストし、バグを確認する。その後 Le Chonk がパッチを当てる。トリアージ、再現、パッチ。90倍速で表示。」執筆時点で、540 件のいいね、94 件のリポスト、107 件の返信、約 21,000 回の表示があった——立派な製品投稿であり、脆弱性の開示ではない。

Mistral自身のリリースノートは、同じワークフローをより詳細に説明している。オープンウェイトの発表では、「サイバー脆弱性トリアージ」エージェントが挙げられており、届いた脆弱性報告を読み、隔離されたサンドボックス内でその欠陥を再現し、パッチを作成して反復し、「カナリアエクスプロイトが機能しなくなるまで」続けるとされている。これは動画より前に書かれた、モデルの文書化された機能である。133体のエージェントによる実行は、その公開デモンストレーションだ。

90×という数字は再生速度であり、結果ではありません。元動画の長さや実行の実時間がなければ、それを継続時間に換算することはできません。2時間の実行の90×タイムラプスと2日間の実行の90×タイムラプスは、タイムライン上では同じに見えます。

Djangoバッチ、そしてなぜ「critical」は当てはまらないのか

Djangoの11月3日のアドバイザリは異例なほど具体的で、だからこそ対照として役立つ。6件の問題を列挙しており、それぞれにCVE、報告者、影響を受けるブランチの範囲、修正コミットが付されている。深刻度はcriticalには程遠い：

• CVE-2026-111362 — 中程度。GeoJSON ジオメトリの crs メンバーにより、検証・保存・クエリの際に GDAL がネットワークリクエストを発行したりローカルファイルを読み取ったりする可能性がある。SSRF およびローカルファイル読み取りの経路となる。

• CVE-2026-108147 — 低。Base64エンコードされたマルチパートアップロードが、アップロードハンドラーの実行前にバッファリングされていたため、FILE_UPLOAD_MAX_MEMORY_SIZEがバイパスされ、メモリ枯渇が発生する可能性がありました。

• CVE-2026-111211 — 低。無効なジオメトリフォーム値に含まれる制御文字がエスケープされずに記録されていたため、ログインジェクションや偽造が可能でした。

• CVE-2026-113593 — 低。Vary ヘッダー値が欠落している場合と空の場合で同じキャッシュキーが生成され、プライベートなキャッシュ済みレスポンスが露出するおそれがありました。

• CVE-2026-113733 — 低。閲覧のみの権限を持つ管理者ユーザーが、特定のカスタムユーザーモデルにおいて完全なパスワードハッシュを閲覧できる可能性がありました。

• CVE-2026-114582 — 低。SpatialReference 文字列の入力により、GDAL の URL 取得やファイル読み取りが引き起こされる可能性があります。完全な保護には GDAL 3.9 以降が必要です。

6件すべては同じ日に修正された。それがDjangoの通常のプロセスだ。アドバイザリ、パッチ、CVEレコードは一緒に公開される。1日後に「バグを確認した」とするモデルは、修正がすでにリポジトリにあり、再現手順が公開レポートにあるバグを確認しているにすぎない。報告されたバグを再現することはトリアージキューの最初の仕事であり、それは実際の作業ではある — しかし、バグを見つけることとは同じではない。

MistralはCVEを特定していないため、その主張を特定のアドバイザリと照合して確認することはできない。対象が11月のバッチ外であった場合、その投稿には対象を特定し、日付を確定し、生成されたパッチを上流の修正と比較する方法が示されていない。パッチ自体も公開されていない。

133エージェントはオーケストレーション数です

エージェント数は設計上の選択であり、スコアではない。パイプラインが133個のエージェントを使えるのは、ファイルごとに1つ、仮説ごとに1つ、攻撃経路ごとに1つへとファンアウトするからだ。同じ作業は、5個のエージェントとより多くのターンでも実行できる。数によって変わるのはコスト、レイテンシ、独立した試行の数であり、モデルのトークンあたりの能力ではない。

数値を意味のあるものにする指標こそが欠けている。候補となる欠陥が何件挙がったか、そのうち何件が誤検出だったか、確定した1件のバグにつき何体のエージェントが必要だったか、そしてその実行にトークンでいくらかかったかだ。実際のバグを1件確定するために候補を200件挙げるシステムは、3件挙げて1件を確定するシステムとは別の製品であり、どちらも「133エージェント」と正直に表現できる。

Mistralの公表した説明は、自由奔放な探索というより、狭くて検証可能なループを示唆している。サンドボックスで再現し、パッチを反復し、カナリアエクスプロイトが失敗したら停止する。そのループこそ、Djangoデモが示しているものだ。それは良いループだ。また、人間のトリアージ担当者がデバッガーとテストスイートを使って回すループでもある。

Mistralが実際に公開しているセキュリティ数値

Mistralのオープンウェイトに関する投稿では、ベンダー作成のグラフにおいてMistral Large 4がArtificial Analysis Cyber Indexで51%を示し、MiMo-V2.6-Proが56%、DeepSeek-V4.1-Flash 1017が57%、Kimi K3が41%、GLM-5.3が36%となっている。この指数は、モデルがコードベース内の脆弱性を発見し、それらを再現・検証し、修正できるかどうかを試すもので、デモと同じ3つの動詞を用いている。

同じ投稿は、悪意のあるサイバーリクエストに対する平均拒否率を96.6%と報告している。Mistralはこれを、オープンモデル間で同社が測定した中で最高だとしている。また、B3エージェントセキュリティベンチマークでの攻撃耐性は97.1%で、プレビュー時の93.3%から上昇した。10月のプレビューページには、Mistral独自の脆弱性再現・修正テストで82%というスコアと、40件のCybenchチャレンジの93%という結果も記載されていたが、オープンウェイトの投稿ではどちらの数値も繰り返されていない。

これらはすべてベンダーによる報告です。いずれも独立に再現されたものではなく、Cyber Indexのチャートはリーダーボードのキャプチャではなく、Mistralによるサードパーティ指標の描画です。だからといって数値が間違っているわけではありません。それは数値を主張に変えるのであり、デモ動画も同じ系列のもう一つの主張です。

ポジショニングには実際の緊張関係がある。悪意あるサイバーリクエストの96.6%を拒否するよう調整されたモデルが、エクスプロイトを再現しパッチを書く能力でも販売されている。Mistralの答えは、ペネトレーションテストとレッドチーミング向けの specialised variant であり、審査と、所有または認可されたシステムに限定する契約上の制限によって提供が制限されている。オープンウェイトのチェックポイントは汎用モデルであり、ホストが調整できるガードレールを備えている — まさにそれが、デュアルユースの問いがAPIではなく重みに付きまとう理由である。

デモを証拠に変えるには何が必要だろうか

信頼できるエンドツーエンドの主張には6つの要素が必要だ。どれも奇抜なものではないが、そのすべてがこの投稿には欠けている。

• CVE 番号が付与されたもの、または公開レポートのないバグ — 読者が発見と再現を区別できるように。

• 脆弱なコミットと修正済みコミット。これにより差分をレビューできます。

• 同一環境での修正前と修正後の再現（失敗したエクスプロイトと成功したエクスプロイトを含む）。

• 偽陽性の数：エージェントが候補をいくつ挙げてから、1つが生き残ったか。

• 実行全体の実時間とトークンコストであり、再生倍率ではありません。

• Mistral 以外の人物による独立した再実行。

それらを公開すれば、論旨は変わる。それまでは、正直な説明は「Mistralは公開されたDjangoのバグでトリアージエージェントを実演した」であり、これは有用な製品デモではあるが、投稿の最初の文よりはるかに小さい主張だ。

自分のコードベースでこのパターンを実行する

オープンウェイトは、セキュリティチームにとって重要な部分です。Mistralは2026年10月29日に、Mistral Ecosystem Open-Weight Licenseの下でチェックポイントを公開しました。これは修正MITライセンスで、使用、改変、ファインチューニング、商用化を許可しますが、モデル・アズ・ア・サービス事業を運営する者には別途ライセンスを要求します。チェックポイントは1.05兆パラメータで、トークンあたり490億がアクティブ、100万トークンのコンテキスト、Blackwell GPU向けのNVFP4版があります。セルフホストするにはクラスタ購入が必要で、ラップトップにダウンロードするものではありませんが、ソースコードと調査結果を自組織の境界内に保持できます。これが、セキュリティチームがAPIではなくこれを選ぶ理由です。

ワークフローはモデルよりも移植性が高い。コードをマッピングし、候補となる欠陥を生成し、攻撃をシミュレートし、サンドボックスで再現し、パッチを当て、そのうえでエクスプロイトがもう発火しないことを検証する。あらゆる実装において弱点となるステップは検証器だ。パッチを書いた同じモデルは、そのパッチを判断するには適していない。異なるファミリーの第二のモデルに差分と再現結果を与えると、最初のモデルが擁護するような不良パッチの相当な割合を捕捉する。

そこで役立つのがルーティングだ。Mistral Large 4 は OrcaRouter のカタログにはない。Mistral 自身の API で提供され、セルフホスティング用にダウンロードすることもできる。だが OrcaRouter は200 以上の他のモデルを 1 つの OpenAI 互換キーの背後に、プロバイダー定価に対する 0% のマークアップ、自動フェイルオーバー、そしてセカンドオピニオンの検証器を同じ呼び出しに組み込めるルーティング DSL とともにまとめている。トリアージのパイプラインに必要なのは、1 つのモデルが何でもこなせることではない。パッチを書く側とパッチをレビューする側が別であることであり、そこへ到達するには 2 社との契約よりも 1 つのキーのほうが安く済む。

注目すべき主張

Mistralには、信頼に足るセキュリティ製品の構成要素が揃っている。オープンウェイト、文書化されたトリアージループ、強力な拒否指標、そして適切な動詞を測るベンチマークだ。公に欠けているのは、モデルがまだ修正されていない問題を発見した事例である。次のデモでは、そのバグを名指しし、diffを公開し、他の誰かに実行させるべきだ。それまでは、133エージェントの動画はオーケストレーションの実演であり、発見の証拠ではない——そして「critical」という語は、Djangoのバッチが裏付ける以上に重い意味を担わされている。