何が出たのか
Deepseekが公開した「Deepseek-V4-Flash-Vision-Exp」は、既存のテキストモデルV4-Flashに画像処理を追加した実験版です。同社によれば、推論と世界知識におけるベースモデルのテキスト性能は維持したまま、画像入力を扱えるようになっています。用途としては、画像の説明、スクリーンショットからのテキスト抽出、図表の解析が挙げられています。
同社の内部ベンチマーク（マルチモーダルエージェント系）では、この視覚版がOpus 4.8に近いスコアを出し、場合によっては上回るとされます。あくまで自社計測である点は差し引いて読む必要がありますが、Deepseekが公開した比較画像もその主張に沿った内容です。
「見えるモデル」ではなく「エージェント部品」として設計されている
注目すべきは、Deepseekがこのモデルを画像認識APIではなく、エージェント用途の部品として位置づけている点です。複数のエージェントフレームワークで動くことを前提に、視覚理解とツール利用を組み合わせる設計になっており、同社のHarnessフレームワークもバージョン0.1.1で新モデルを標準サポートしました。
この意図は、既存エコシステムへの接続方法にも表れています。OpenAIのChat Completions APIとResponses API、さらにAnthropicのMessagesエンドポイントに対応しており、既に他社SDKで組んだエージェントの接続先を差し替えるだけで試せる形になっています。独自APIで囲い込まず、既存実装の乗り換えコストをゼロに近づける——これは性能表よりも実務的に効く仕様判断です。
仕様から読み取れる「安く大量に見る」という設計思想
画像の渡し方は3通り。Base64での直接埋め込み、公開URL（最大32MiB）、そして新設された無料のFiles API（最大64MiB）です。Files APIは一度アップロードしたファイルをIDで何度も参照でき、同じ画像を複数リクエストで使い回す処理では転送量が丸ごと消えます。
コスト設計はさらに割り切っています。モデルはアスペクト比に応じて画像をおよそ800×800ピクセルに自動正規化し、元の解像度が何であれ1枚あたり最大384トークンに収まります。細部が不要な場面ではdetailフィールドで512×512に縮小してさらにトークンを節約できます。料金はV4-Flash準拠です。
制約も明快です。1リクエストにつき最大600枚、画像はuserメッセージにしか置けません。辺の最大長は8,192ピクセルですが、1リクエストに15枚以上を含めると4,096ピクセルに下がります。フォーマットはJPEG、PNG、GIF、WebPに対応し、拡張子や申告されたMIMEタイプではなくファイルの中身から判定する仕様です。ユーザーがアップロードするファイルの拡張子が当てにならない現場を前提とした、実装者にはありがたい挙動と言えます。
1枚384トークン上限と600枚という組み合わせは、「1枚を精密に読む」より「大量の画面・帳票・棚をまとめてスキャンする」ワークロードに寄った設計です。エージェントが画面を見ながら操作を繰り返す用途では、1ステップごとに画像が積み上がるため、この上限の有無がコスト構造を決めます。
💼 事業会社視点：これは自社にどう効くか
効いてくるのは、画像を「大量に、繰り返し」見る現場です。ECなら商品画像の不備チェックや競合サイトの棚のスクリーンショット監視、SaaSならサポートに届くエラー画面の一次切り分け、受託開発ならRPAが詰まる帳票・請求書の読み取り。いずれも従来はOCR＋ルールで作り込み、例外処理に工数が溶けていた領域です。1枚最大384トークン・1リクエスト600枚という上限は、この手の処理の単価見積もりを一気に立てやすくします。
経営判断として重要なのは2点です。第一に、OpenAIのChat Completions／ResponsesとAnthropicのMessagesに対応しているため、既存のエージェント実装を捨てずに接続先だけ差し替えて検証できます。PoCの承認を待つほどのコストはかかりません。まず社内の1業務で、既存の精度とトークン単価を並べて比較させるべきです。
第二に、これは実験版（Exp）であり、優位性の根拠はDeepseekの内部ベンチマークです。基幹業務や顧客に直接出る出力に即採用するのは早い。日本企業の場合、中国企業のAPIに業務画像——請求書、社内画面、顧客情報が写り込むスクリーンショット——を送る是非は、性能とは別の意思決定です。データの取り扱いポリシーを法務と先に固めた上で、非機密の画像から試すのが現実的な順序になります。