コーディングAIエージェントで「ネイティブ・マルチモーダル」が重要になる理由

最先端モデルの差は、単に「画像を受け取れるか」ではなくなりつつあります。重要なのは、視覚的な証拠がエージェントの推論サイクルで第一級の情報として扱われるかどうかです。

Moonshot AIのKimi K3は、長期にわたるコーディング、ナレッジワーク、視覚理解、推論向けのネイティブ・マルチモーダルなエージェントモデルとして位置付けられています。AlibabaもQwen3.8-Maxについて、視覚理解が計画、実行、検証を通して働くと説明しています。 1735

狙いは明快です。エージェントが何かを作り、実際に表示された結果を見て、違和感や不具合を特定し、修正する。その際、画像の観察結果を毎回テキストの報告書へ変換しなくてもよいようにすることです。

分かれ目は「視覚を完了判定に使うか」

テキスト中心の汎用モデルは、コード生成、長文脈の分析、ツール呼び出し、入出力と成功条件が文章で明確に定義された作業で、今も非常に有用です。一般的なツール型の構成でも、エージェントはOCRを呼び出し、DOMやアクセシビリティツリーを調べ、座標情報を取得し、あるいは別の視覚言語モデル（VLM）へスクリーンショットを渡せます。

文書からの文字抽出、構造化されたUIの確認、一度きりの画像質問なら、こうした分業型の構成は合理的です。

これに対し、ネイティブ・マルチモーダル学習は、テキスト、画像、動画、コード、エージェントの状態を一体として扱い、視覚情報が計画と修正に直接影響することを目指します。中国のモデル市場に関する報道では、Moonshot AI、Alibaba、ByteDanceがこの方向を追求する一方、当時のDeepSeek、Zhipu、Tencent Hunyuanの汎用リリースは比較的テキスト中心と整理されました。 15

ただし、これは企業間の恒久的な線引きではありません。DeepSeekのV4 FlashとV4 Proは当初テキスト専用でしたが、その後、実験的な視覚対応モデル「DeepSeek-V4-Flash-Vision-Exp」が導入されました。 134

モデルのラインアップは急速に変わります。また、各研究所がなぜその設計を選んだのか、とりわけByteDance、Zhipu、Tencentについての社内事情までを、提供された情報だけから断定することはできません。

「視覚をループに入れる」と何が変わるのか

Webページは、文言やDOM構造だけではありません。情報の階層、余白、整列、コントラスト、書体、要素の欠け、画像、各要素の見え方の関係まで含めて画面です。参照デザインに合わせる仕事では、まさにそれらが合格条件になります。

視覚を組み込んだ作業ループは、次のようになります。

1. 計画する：依頼内容、参照画像、コードベース、これまでの作業状態を解釈する。
2. 実行する：コードを追加・修正し、ブラウザやアプリを操作し、ビジュアル素材を編集する。
3. 観察する：レンダリング結果を表示し、スクリーンショット、動画フレームなどを確認する。
4. 検証し、直す：要求した結果と比較して不具合の箇所を推定し、元の成果物を修正して繰り返す。

Qwen3.8-Maxは、長期タスクで計画・実行・検証にまたがってネイティブな視覚理解を使い、閉ループで反復すると明示しています。ホスト型モデルは画像、テキスト、動画を入力として受け、テキストを出力します。 35 Kimi K3も、同一モデル内でテキスト、画像、動画を理解でき、100万トークンのコンテキストウィンドウを備えます。 25

利点は単に「モデルが見える」ことではありません。依頼内容、コード、視覚的な出力、更新され続ける作業計画を、同じエージェントが保ったまま反復できる点にあります。

OCRや外部VLMへの受け渡しが制約になる場面

外部の知覚ツールは有効ですが、「見ること」と「行動すること」の間にインターフェースを挟むことになります。

OCRは取り出せる情報が限られます。 画面上の文字は抽出できますが、ボタンが途中で切れていないか、レイアウトが不自然でないか、モーダルが本文を覆っていないか、視覚的な階層が参照デザインと違っていないかまでは、文字列だけで十分に伝わりません。

座標は構造化されていても、表現できる範囲は狭いものです。 「要素がx/y座標にある」という情報は自動操作に役立ちます。しかし、その要素が視覚的に重要か、意図したオブジェクトか、重なりや装飾に問題がないかまでは必ずしも分かりません。

長い連鎖では、繰り返す変換が複雑さを増します。 スクリーンショットを説明文や座標に変換するたび、文脈が失われたり、エージェント側で再構成が必要になったりします。不完全な説明を基にした修正は、新たな表示上の不具合を生み、次の観察サイクルを必要とすることがあります。

ネイティブ・マルチモーダルモデルでも誤りは起こり得ます。それでも、スクリーンショットの内容を文章要約だけに頼るのではなく、実装文脈と併せて扱えることが大きな違いです。これはフロントエンド開発、GUI自動化、ビジュアルリグレッションのデバッグ、画像編集、動画ワークフローで特に魅力となります。

Kimi K3の結果は「用途の証拠」であって、因果の証明ではない

Kimi K3の公開結果は、開発者がこの領域に注目する理由を示しています。Arenaによると、Kimi K3はFrontend Code Arenaで1,679ポイントを記録して首位となり、Kimi K2.6から17順位上昇しました。掲載されたフロントエンド7分野のうち6分野で1位でした。 32

別の報道では、ブラウザ開発プラットフォームのPuterが行ったテストで、Kimi K3は目標ページとレンダリング結果を比較し、意図的に仕込まれた5つの視覚的な差異を偽陽性なしで見つけたとされています。 28

これらは視覚的な検証の有意義な実演です。ただし、ネイティブな視覚能力だけが結果を生んだことを示すものではありません。モデル規模、学習データ、追加学習、プロンプト設計、ブラウザツール、エージェントの実行基盤、ベンチマークの設計はいずれも性能に影響します。

より慎重に言えば、視覚フィードバックは、テキストだけのテストでは見落とされる現実的な失敗の一群に対処する、ということです。

ネイティブ・マルチモーダルを優先すべきケース

完成の定義に視覚的な忠実度が含まれ、観察と修正を何度も繰り返すなら、ネイティブ・マルチモーダルなエージェントを優先する価値があります。

• Webページやアプリを参照デザインに合わせる
• 壊れたGUIの状態を復旧する
• レスポンシブ表示や視覚的リグレッションを確認する
• 被写体、構図、スタイルの条件を保ちながら画像を編集する
• シーン間の連続性が重要な長時間動画をレビューする

一方、低コストの抽出、バッチ処理、構造化テキストとUI状態だけが必要なワークフローでは、OCRや外部VLMを組み合わせる構成がより適している場合もあります。

問うべきことは、視覚が流行かどうかではありません。エージェントが繰り返し、**「この出力は、本当に見た目まで正しいか」**に答えなければならないかどうかです。

その種類の作業では、ネイティブ・マルチモーダルは知覚をたまのツール呼び出しから、エージェントの作業ループそのものへ変えます。Kimi K3とQwen3.8-Maxは、この方向を明示的に進めています。 1735