Cloudflare Clef-omni、マルチモーダルな意思決定を拡張するも、精度が依然として限界を規定
Cloudflareは10月9日、音声、動画、画像、テキストを単一の意思決定パイプラインでネイティブに処理するClef-omniを発表した。同社はClef-flashの価格も引き下げ、ホスト型Clef推論を最大2.0倍高速化した。これらの変更により、登場からまだ1週間のモデルファミリーは、開発者が現在自動化された意思決定に用いている多段階システムに対する、より幅広い選択肢となる。
重要な変化は、単に別のモデルがメディアを受け付けるようになったことではない。汎用モデルはすでにそれを実現している。Cloudflareは、自由形式の文章を生成するのではなく、許可された回答に対する確率を返す、制約付きの意思決定サービスとしてマルチモーダル理解を提供している。
この違いにより、CloudflareはTypeSafeのJev、ならびに文字起こし、視覚、言語、分類の各コンポーネントを接続する、より定着したアーキテクチャパターンと競合することになる。Clef-omniは、その連鎖を1回のモデル呼び出しで置き換えるよう開発者に促す。このアプローチはオーケストレーションの削減を約束するが、Cloudflare自身のベンチマーク結果は、コンポーネントが少ないことが自動的に優れた意思決定を意味しない理由も示している。
Cloudflare Clef-omni、4種類の入力を1つの意思決定に統合
Cloudflare Clef-omniは、すべての入力を先にテキストへ変換することなく、混在するメディアを直接評価するよう設計されている。
このモデルはテキスト、画像、WAVまたはMP3の音声、MP4またはWebMの動画を受け付ける。リクエストでは、モデルが答えるべき質問を記述したスキーマとともに、複数の入力を組み合わせられる。応答は物語的な回答を生成するのではなく、許可された選択肢に信頼度を割り当てる。
Cloudflareは、このパターンを機器検査で例示している。開発者はラベルの写真、機械の録音、ファンの動画を送信できる。モデルはその後、ラベルが見えているか、機械の音が正常か、ファンが動いているかを判断できる。
このワークフローには通常、複数の段階が必要となる。あるモデルが音声を書き起こし、別のモデルが動画をサンプリングまたはキャプション化し、アプリケーションコードがそれらの出力を結合する。最後に分類器または言語モデルが、蓄積した証拠を意思決定へ変換する。
これに対しClef-omniは、メディアを1つの統合シーケンスへマッピングする。Cloudflareによれば、同期された音声と映像フレームは共同処理のために維持される。モデルは中間的な文字起こしやキャプションを生成せず、その結合表現からすべての有効な回答を採点する。
これは、変換の過程で文脈を失うシグナルにとって意味のある違いだ。文字起こしは話された言葉を保持できる一方、声色、背景雑音、タイミング、音と動作の関係を捨ててしまう可能性がある。一連の動画キャプションは可視の物体を説明できても、機械故障と同時に音が発生したかどうかを見落としかねない。
Cloudflareは、このモデルをMixture-of-Experts基盤であるQwen3-Omni-30B-A3B-Instruct上に構築した。Mixture-of-Expertsモデルは、すべての計算でネットワーク全体を有効化する代わりに、異なる入力を選択されたパラメーター群へルーティングする。Cloudflareは基盤モデルの理解バックボーンを維持しつつ、テキスト読み上げ出力コンポーネントを取り除いた。
同社は続いてQwen3バックボーンを凍結し、LoRAモジュールと呼ばれる低ランクアダプターを学習させた。LoRAは、基盤モデルの大部分を変更せずに、追加されたより小規模なパラメーター群を更新する。Cloudflareはさらに、ラベルスムージング付き交差エントロピー学習と、予測確率が実測結果とどれほど一致するかを測るBrierスコア較正を適用した。
このアーキテクチャにより、Clefのマルチモーダルモデルは、単にメディアに対応したチャットボットではなくなる。これは、アプリケーションが回答すべき質問をすでに把握している用途のために構築された、スキーマに拘束されるスコアラーだ。その焦点は中心的な制約も生む。スキーマ、証拠、許可された選択肢が現実の問題を捉えている場合にのみ、このシステムは有用な意思決定を行える。
Clefのマルチモーダルモデル、パイプラインの複雑さを狙う
Cloudflareが競っているのは、他のモデルベンダーだけではなく、接続されたモデルパイプラインのコストと脆弱性でもある。
多段階のメディアワークフローは運用上の依存関係を生む。音声認識はアクセントや雑音の多い録音で失敗する可能性がある。動画サンプリングは関連するフレームを飛ばすことがある。キャプションモデルは、後になって重要だと判明する詳細を省くかもしれない。最終的な意思決定システムが見るのは、上流で導入されたすべての誤りを含む、変換後の出力だけだ。
各段階には独自のレイテンシー、可観測性、スケーリング特性、障害対応もある。開発者は、失敗した文字起こしを再試行するのか、部分的な証拠で続行するのか、リクエスト全体を停止するのかを決めなければならない。最終判断がタイミングに依存する場合は、タイムスタンプ、動画フレーム、派生テキストの間のリンクも保持する必要がある。
Clef-omniの直接処理は、こうした引き渡しを減らす。Cloudflareによると、ホスト型モデルによるテキストのみの意思決定は、中央値で約130ミリ秒のレイテンシーとなる。画像リクエストは約150ミリ秒、音声入力は数百ミリ秒を要する。
同社の例では、音声を含む21秒の動画は、およそ1.5秒でスコアを受け取る。これらは独立した保証ではなく、Cloudflareによる測定値である。実際のレイテンシーは、ペイロードサイズ、ネットワーク距離、同時実行性、アプリケーションが質問を構成する方法に左右される。
それでも潜在的な利点は明確だ。サポートプラットフォームは、顧客による文章説明、製品写真、音声録音を1回のリクエストで評価できる。セキュリティワークフローは、画面キャプチャ、音声ナレーション、構造化されたインシデントデータを組み合わせられる。品質管理アプリケーションは、可視の動作と機械音を比較できる。
出力形式は入力形式と同じくらい重要である。Clefモデルはスキーマに制約された確率を生成するため、アプリケーションは会話的な文章を解析せずに応答を利用できる。モデレーションシステムは許可されたカテゴリーを要求でき、ルーティングシステムは複数の宛先を採点できる。
これはアプリケーションロジックをなくすものではない。チームには依然として、信頼度の閾値、エスカレーションルール、監査記録、重大なケースに対する人間のレビューが必要だ。確率分布は正確性の保証ではないため、不確実な結果への方針も必要となる。
この変化は、統合として捉えるほうが適切だ。開発者は、個別の認識と分類の段階を維持する代わりに、1つのエンドポイントがワークフローの十分な部分を処理できるかを検証できる。モデル自体がすべての評価で最高の性能を発揮しなくても、インフラ作業を減らせる可能性がある。
同じ原則は、個人情報を扱うワークフローにも当てはまる。会議、文書、キャプチャしたメディアを組み合わせるシステムには、依然として信頼できる検索とコンテキスト管理が必要だ。knowledge blendingを中心に構築されたツールは、ユーザーに手作業で文脈を再構築させることなく、異種情報を接続したいというより広範な需要を示している。
Cloudflareは、開発者が自動化された意思決定パスの内部でも同様の統合を求めていると見込んでいる。Clefのマルチモーダルモデルが有用なメディア横断の証拠を保持できるなら、より単純なアーキテクチャは競争優位となる。ドメイン固有のシグナルを見逃すなら、チームは余分な複雑さを抱えてでも専門コンポーネントへ戻るだろう。
高速化したClef推論、デプロイの方程式を変える
Clefのアップデートは一部でサービングインフラの物語であり、報告された中央値の最大高速化は2.0倍に達する。
Cloudflareは、オリジナルClefモデルの高速版について新しい重みを公開していない。同社によれば、改善は主にホスト型サービング層によるものだ。つまり、セルフホストユーザーが既存モデルを再ダウンロードしても、同じ向上を自動的に得られるわけではない。
800トークン前後の入力では、Cloudflareは中央値レイテンシーが262ミリ秒から152ミリ秒へ低下したと報告している。報告された95パーセンタイルのレイテンシーは438ミリ秒から351ミリ秒へ移行した。これは中央値で1.7倍の改善に相当する。
約3,400トークンでは、中央値レイテンシーは616ミリ秒から305ミリ秒へ低下したとされる。95パーセンタイルは777ミリ秒から531ミリ秒へ下がった。これはCloudflareが最大2.0倍の中央値高速化を報告したワークロードである。
16,000トークン前後の入力では、同社は中央値が2,721ミリ秒から1,635ミリ秒へ減少したと報告している。95パーセンタイルの数値は3,250ミリ秒から1,805ミリ秒へ低下した。このサイズにおける中央値の改善は1.7倍だ。
意思決定モデルは別の操作の内部に置かれることが多いため、これらの測定値は重要である。ルーティング判断は、エージェントがツールを選ぶ前に行われるかもしれない。安全性スコアは公開を阻止する可能性がある。セキュリティ分類は、イベントが即時の注意を受けるかを決める可能性がある。
こうした位置でのレイテンシーは積み重なる。エージェントループの中でモデルを繰り返し呼び出すアプリケーションでは、数百ミリ秒が目に見える遅延になり得る。ユーザーが体験するのは中央値のリクエストだけではなく遅いリクエストであるため、テールレイテンシーも重要だ。
Cloudflareは、Clef推論速度の改善の一部を、言語モデルおよびマルチモーダルモデル向けのオープンソースサービングフレームワークであるSGLangへの移行に帰している。同社はプロジェクトと協力し、アップストリームのSGLang contributionを通じてClefサポートを追加した。
この協力はホスト型サービス以外でも重要だ。ハードウェアや構成によって結果は異なるものの、セルフホストユーザーにサポートされたサービング経路を提供する。また、モデル性能は推論ソフトウェアと切り離して評価できないことも示唆している。
高速化したホスト型モデルは、Cloudflareのプラットフォーム論を強化する。Workers AIを利用する開発者は、モデル実行、アプリケーションコード、AI Gatewayの制御を同じプロバイダー内で組み合わせられる。レイテンシーの低下は、既存のWorkerへ意思決定ステップを挿入する際の負担を減らす。
ただし、インフラ最適化はモデルの判断を改善しない。半分の時間で返された誤答は、依然として誤答である。そのため開発者は、Clefが精度と較正の要件を満たすか、Cloudflareのサービング層がレイテンシー目標を満たすかという、2つの評価問題を分けるべきだ。
この区別により、見出しを飾る高速化がアプリケーションリスクを覆い隠すのを防げる。高速なモデレーションモデルはより多くのコンテンツを処理できるが、誤検知も拡大し得る。高速なルーティングモデルはエージェントを加速できるが、信頼度推定が不十分なら、より多くのリクエストを誤ったツールへ送る可能性がある。
低価格化したClef-flash、より小さいホスト型コンテキストを伴う
Cloudflareは、ホスト型コンテキストウィンドウを大幅に短縮するという明確な製品上のトレードオフを受け入れ、Clef-flashのコストを引き下げた。
同社によれば、Clef-flashは現在、最も直接的な意思決定モデルの比較対象であるJevよりも低価格となっている。正確な商用価格は変動し得るため、購入者はローンチ発表を恒久的な料金表として扱うのではなく、最新のドキュメントを確認すべきだ。
より持続的な事実は、コンテキストの削減である。ホスト型Clef-flashは以前、64,000トークンのウィンドウを掲げていた。現在、Workers AIを通じて受け付ける上限は24,000トークンとなっている。
Cloudflareによると、観測されたClef-flashリクエストのうち新たな上限を超えたものは0.24%にとどまった。この利用状況を基に、同社はホスト型の上限を引き下げ、サービスコストを削減することを選んだ。より大規模なClefモデルは、64,000トークンのホスト型コンテキストを維持する。
ダウンロード可能なClef-flashの重み自体は変更されていない。Cloudflareによれば、これらの重みはセルフホスト時に256,000トークンのコンテキストをサポートできるよう学習されている。これは、モデルの理論上の能力と、マネージド製品に設定された上限との間に明確な差を生む。
多くの分類タスクでは、24,000トークンでも十分だ。顧客チケット、ポリシーの抜粋、インシデントの要約、短いエージェントトレースは、無理なく収まる。長文ドキュメント、長時間のトレース、大量の証拠集合を処理するチームは、新たな境界を前提に計画する必要がある。
入力を切り詰める、要約する、関連する箇所だけを取得する、より大きなClefサービスを使う、あるいはClef-flashをセルフホストする、といった選択肢がある。いずれもシステムに変更を加える。切り詰めでは決定的な証拠を取り除くリスクがあり、要約では別のモデルと新たな誤差要因が加わり得る。
検索・取得は入力サイズを抑えられるが、結果は取得レイヤーが何を選ぶかに左右される。セルフホストではより多くのコンテキストを維持できる一方、キャパシティ計画、更新、セキュリティ対応、推論エンジニアリングが必要になる。
だからこそ、より安価なClef-flashという話は、単なる値下げではない。Cloudflareは、現在観測しているリクエストの圧倒的多数に合わせて最適化している。異例に長い入力を扱う顧客は、移行やアーキテクチャ変更という形でコストを負担することになる。
この判断は、製品ファミリー内での位置付けも明らかにしている。Clef-flashは、比較的限定されたコンテキストで頻繁に行われるレイテンシー重視の判断を対象とする。フル版のClefは、より大規模または要求の厳しいケースを処理する。Clef-omniは、決定的な情報がテキスト、音声、画像、動画にまたがるワークフローに対応する。
階層型ルーティングのパターンは自然に導かれる。アプリケーションはClef-flashから始め、長いケースや不確実なケースを別のモデルへエスカレーションできる。ただし、このパターンには慎重なキャリブレーションが必要だ。汎用ベンチマークで妥当に見える信頼度の閾値も、企業固有のデータでは異なる振る舞いをする可能性がある。
開発者は、平均的な入力長ではなく、完全な本番環境の例を用いてコンテキスト制限をテストすべきだ。24,000トークンを超える稀なリクエストは、コンテキスト欠落が最も大きな損害を招く複雑なリクエストである可能性も高い。
Cloudflare Clef-omniは依然として精度の検証を要する
Cloudflareが公開した結果は有能なモデルを示しているが、タスクやモダリティを問わず普遍的に優れたモデルであることを示すものではない。
Cloudflareのベンチマークセットでは、Clef-omniは複数のテキスト中心評価で強い結果を記録している。BFCLのcase exact matchでは98.2、スコープ外の例を含むCLINC150ではマクロF1で97.7に達した。BANKING77でもマクロF1で94.8を記録している。
ただし、このモデルは複数のテストでClefファミリーの別モデルを下回る。フル版Clefは、ToolRet、家電の意思決定、When2Call、BRIGHT、PhishNChipsでより高いスコアを出している。Clef-flashは、BFCL、API-Bank、家電評価で首位に立つ。
Jevにも優位性は残る。Cloudflareの表では、When2CallとBRIGHTでJevが先行している。これらの結果は、入力の幅広さを自動的な優位性と見なすべきではないことを示している。
同じく評価が分かれる状況は、ワークフロー評価にも見られる。公開されたdecision model evalsでは、Clef-omniは請求書処理でフル版Clefを下回る。また、カスタマーサービスの完全一致アクションとエージェントトレースの主要アクションではClef-flashを下回っている。
セキュリティインシデントでは、Clef-omniは完全一致アクションでClef-flashおよびJevと並ぶ一方、フル版Clefを下回る。ビジネスワークフローでは通常、複数の正しい選択を組み合わせるため、こうした差異は重要だ。モデルは主要アクションを正しく選べても、コンプライアンスやフォローアップに影響する副次的なアクションを見落とす可能性がある。
ベンチマークは、新しいモダリティに関する証拠も限定的にしか提供していない。掲載された評価の多くは、テキスト分類、検索・取得、ツール利用、構造化ワークフローに焦点を当てている。多様な本番環境において、同期された発話、音、動き、画像をまたいでClef-omniがどの程度信頼性高く推論できるかは、確立されていない。
Cloudflareはマルチモーダルのレイテンシーを報告しているが、ローンチ資料には音声および動画の精度に関する同様に詳細な公開内訳はない。ノイズの多い録音、複数話者、カメラの動き、圧縮動画、重なり合う音、モダリティ間で矛盾する証拠については、依然として疑問が残る。
この検証上の隔たりは、導入判断に反映すべきだ。工場検査を評価するチームは、現実的な背景雑音の下で正常音と異常音の両方を含む例を作成すべきである。サポート組織は、さまざまなアクセント、デバイスのマイク、不完全な顧客録音をテストする必要がある。
セキュリティチームは、偽陽性と偽陰性を分けて測定すべきだ。単一の精度スコアは、最も一般的なクラスを優先することで良好に見えるシステムを隠しかねない。下流の自動化は信頼度の値が実際のエラー率に対応しているかどうかに依存することが多いため、キャリブレーションも検証に値する。
Cloudflareの急速な開発スケジュールは、独立評価の必要性を高めている。同社によれば、当初のClefプロジェクトは社内決定からローンチまで1週間未満で進んだ。反復の速さは印象的だが、幅広い外部テストの代わりにはならない。
オープンな重みは助けになる。研究者はテストを再現し、挙動を調べ、セルフホストの結果をWorkers AIと比較できる。しかし、公開されているからといってベンチマークが中立になるわけではない。報告される数値は依然として、Cloudflareによるモデル、プロンプト、インフラ、指標の選択を通じたものだ。
最も妥当な結論は、ローンチ時の表現よりも限定的だ。Cloudflare Clef-omniは、マルチモーダルな意思決定のための信頼できる単一呼び出しアーキテクチャを提供する。実際のワークフローを改善するかどうかは、ローンチ時のベンチマークがまだ示していないドメイン固有の証拠にかかっている。
開発者が次に注視すべきこと
次の段階を決めるのは、機能一覧ではなく、独立したマルチモーダルテスト、本番導入、競合の対応だ。
最初のシグナルは評価範囲である。開発者は、特に音声と動画のシグナルが食い違う場合に、それら両方からの証拠を必要とする公開テストを探すべきだ。有用なベンチマークなら、機械が映像上は正常に稼働している一方、音声には断続的な故障が表れていることをモデルが認識できるかをテストするだろう。
そのような結果は、文字起こしやキャプション生成で失われる情報を、統合パイプラインが保持するというCloudflareの主張を強める。結果が弱ければ、ネイティブ入力は便利ではあっても、特化コンポーネントより必ずしも正確ではないことを示唆する。
2つ目のシグナルは本番環境での挙動だ。Cloudflareはすでに、スパム問題の解決、フィッシングを対象としたプラグインライブラリのモデレーション、個人情報の可能性の特定、悪意あるドメインの検出における社内Clef導入事例を説明している。これらは重要な分類を伴う事例だが、主に利用状況を示すものであり、測定された信頼性を示すものではない。
開発者に必要なのは、持続的なトラフィック下でのエラー率、キャリブレーション結果、エスカレーションのパターン、テールレイテンシーだ。また、チームがClef-omniを真にモダリティ横断の意思決定に採用するのか、それとも主としてテキストと画像のスコアラーの一つとして使うのかも注視すべきである。
3つ目のシグナルは競合の対応だ。ClefはJevのAPI形式をサポートし、Cloudflareも繰り返しJevをベンチマーク比較対象としているため、Jevは最も明確な直接比較対象であり続ける。互換性は乗り換えの摩擦を下げるため、TypeSafeは精度、経済性、レイテンシー、または特化ツールによって自社の立場を守る必要がある。
汎用マルチモーダルモデルの提供者も、システムを意思決定モデルとして提示していなくても重要だ。構造化出力、制約付きデコーディング、専用分類エンドポイントは、運用上の差を縮める可能性がある。ドメイン精度がパイプラインの単純さを上回る領域では、特化した音声・ビジョンシステムが引き続き魅力的だろう。
開発者にとって実践的な次の一歩は、実例を使った統制評価である。統合モデルを既存パイプラインと比較し、完全なアクションの精度、キャリブレーション、レイテンシー、障害処理を測定する。平均値は運用リスクを左右するケースを隠しがちなため、稀な長文入力と低品質なメディアも含めるべきだ。
モデルが4つのモダリティを理解するか、という問いから始めてはならない。それらのモダリティから、許容可能なエラー率で正しい限定的な判断を下せるかを問うべきだ。そのうえで、不確実な場合、矛盾する証拠を受け取った場合、ホスト型のコンテキスト上限を超えた場合に何が起きるかをテストする。
Cloudflareは実験を実行しやすくした。しかし、実行する必要性をなくしたわけではない。Cloudflare Clef-omniの価値は、一つのエンドポイントが技術的にあらゆるファイル形式を受け取れるかではなく、より単純なアーキテクチャが混沌とした本番データに直面しても機能するかどうかに最終的には左右される。
