Cloudflareがマルチモーダル意思決定モデル「Clef」をオープンソース化:音声・動画を認識し直接判断

AlibabaのQwen3-OmniをベースにしたClef-omniは、テキスト・画像・音声・動画を組み合わせて選択肢をスコアリングします。Flashの値下げやClefの高速化も含め、省略された処理ステップ、実際のコスト計算、モデルの選び方を解説します。

著者:Cloudflare10-10 · 8分

カスタマーサポートのチケットを誰に割り振るべきか?機器から異音はしていないか?これらは、Agentのワークフローで繰り返し発生する細かな判断です。Cloudflareのオープンソース意思決定モデル「Clef」は、入力データをあらかじめ設定された選択肢の確率へと変換し、次の処理をプログラムに委ねることに特化しています。

今回、CloudflareはClefファミリーに対して以下の3つの主要なアップデートを発表しました:

  1. マルチモーダル意思決定モデル「Clef-omni」のリリース:Alibabaがオープンソース化したQwen3-Omni-30B-A3B-Instruct Mixture-of-Experts(MoE)モデルをベースに改良され、テキストと画像に加え、音声(WAV/MP3)および動画(MP4/WebM)の入力をネイティブでサポートします。
  2. Clef-flashの大幅な値下げ:Workers AIホスティングの入力単価が$0.038 / M tokensへと引き下げられ(57.8%の値下げ)、ホスト版のコンテキストウィンドウは24,576 tokensへと縮小されました(オープンソースの重み自体は学習時に256kまで対応)。
  3. Clefホスティング版の大幅な高速化:モデルの重みはそのままに、サービス層の最適化によって、3段階のテストにおける所要時間の中央値が約40%—51%短縮されました。

先に入力を理解し、直接選択肢をスコアリングする

修理依頼票を例に考えてみましょう。システムは「緊急かどうか」「どのチームに割り振るか」「影響はどの程度深刻か」を同時に問いかけ、各質問に対して許可された回答候補を提示します。

生成AI(LLM)は通常、まず資料を理解してからトークンごとに順次回答を出力しますが、Clefはその後のステップを省略します。入力を理解担当のバックボーンネットワークに通した後、小型のスコアリングモジュールに渡します:まず各候補の選択肢が入力から関連する証拠を抽出し、続いて異なる質問の情報を組み合わせることで、すべての選択肢を一括してスコアリングします。これが2段階のアテンションルーティングです。各質問のスコアはその後、確率へと変換され、業務プログラムはその確率に基づいて自動割り振りや担当者へのエスカレーションを決定します。

1つの判断、2つの計算アプローチ

違いは答えの出力方法にあり、入力の理解には依然としてモデルの計算が必要です。

生成モデル回答を生成
状態 + 質問

チケットやモデルが対応するメディアを入力し、返すフィールドを指定。

↓
入力を理解 → トークンごとに順次生成

入力を読み終えてから順次回答を生成。構造化出力で形式を制限可能。

↓
新しい内容を生成可能

例:理由の説明、返信の作成、構造化データの生成。業務上の意味の検証は依然必要。

Clef 意思決定モデル選択肢をスコアリング
状態 + 質問 + 有効な選択肢

部門:技術 / 決済 / 営業、緊急:はい / いいえ。

↓
入力を理解 → 統合スコアリングヘッド

各選択肢が入力から証拠を抽出し、フィールド間を統合処理して全質問の選択肢を一括スコアリング。

↓
用意した選択肢ごとの確率を返す

文字ごとに回答を生成せず、プログラムが確率を取得してルーティングや有人対応を決定。

省略されるのはトークンごとに回答を順次生成するステップ

入力が長くなるほど、またメディアが増えるほど、入力理解自体の処理は遅くなる可能性があります。有効な選択肢の中から誤った選択をする場合もあり、確率のキャリブレーションは学習と評価の課題であって出力形式だけで保証されるものではありません。

学習時、Cloudflareはバックボーンを凍結し、LoRAアダプタパラメータとスコアリングモジュールのみを訓練することで、選択肢の判断精度を高めつつ、Brier損失を用いて確率キャリブレーションを改善しています。ただし、スコアを確率に正規化するSoftmax自体は、「0.8と出力された判断が80%の正解率を持つこと」を保証するものではありません。フォーマットが正当であっても、誤った選択肢を選ぶ可能性はあります。

また、分類タスクごとに専用モデルを学習する手間も削減されます。今日は問い合わせを決済、技術、営業に分類し、明日は投稿を質問、フィードバック、広告に分けるといった場合でも、リクエスト内の質問と選択肢の説明文を変更するだけでテストでき、ラベル体系が変わるたびに専用の分類器を訓練し直す必要はありません。

Omniはどのように画像と音声を同時に処理するのか?

設備の巡回点検を例に挙げると、音声書き起こしは「人が何を話したか」を残せても、モーターの摩擦音などをテキスト化できるとは限りません。また、映像は部品の状態を伝え、音声は稼働状態の手がかりを提供します。映像と音声を直接組み合わせることで、連携させる外部サービスを減らせるだけでなく、テキスト化の際に失われがちな手がかりを保持できる可能性もあります。これらのメディアに対応した汎用マルチモーダルLLMでも直接入力を処理できますが、Omniの特徴は、それらの情報を制約された選択肢のスコアリングに特化して活用する点にあります。

単一のAPIによって、呼び出し側の書き起こし、分割、結合といった処理が簡素化されますが、モデル内部では依然としてメディアのエンコードと動画フレームのサンプリングが行われます:

  • 動画は2 fpsでサンプリングされるため、一瞬の点滅などの過渡的な事象は見落とされる可能性があります。
  • 同一リクエスト内のすべての動画に音声トラックが含まれている場合のみ、動画の音声が同時に解析されます。
  • 推論ではQwen3-Omniの理解バックボーンと音声・視覚エンコーダのみを使用します。音声生成用の重みはオープンソースリポジトリに含まれていますが、ロードも使用もされません。

Cloudflareが公表したテストによると、純粋なテキストによる意思決定の所要時間の中央値は約130 ms、画像入力は約150 ms、音声クリップは約数百ミリ秒でした。また、21秒の音声付き動画のスコアリングには約1.5秒を要しました。

より多くの入力を受け取れるからといって、全タスクで優れているとは限らない

3つのモデルにはそれぞれ異なる強みがあります:Flash(9B 稠密)は低コスト重視、Clef(27B 稠密)は精度と長めのコンテキスト重視、Omni(30B-A3B MoE)は音声・動画入力への対応です。モデルの選定はパラメータ数だけで判断するのではなく、具体的なタスク要件に応じて行う必要があります。

タスクが変われば、優位なモデルも変わる

Cloudflare社内テスト:同一行内でのみ比較可能、異なる指標を単純合算してランク付けすることは不可。

Clef-omni (30B MoE)
Clef (27B 稠密)
Clef-flash (9B 稠密)
Jev (TypeSafe参照)
When2Call 呼び出しタイミング
選択肢判断 Accuracy (%)
Omni
63.3
Clef
72.37
Flash
65.58
Jev
80.97
請求書処理 (Invoice Processing)
アクション集合の完全一致率 (Exact actions %)
Omni
60.2
Clef
64.7
Flash
57.1
Jev
61.8
スマート家電指示シミュレーション
制御指示完全一致率 (Case exact %)
Omni
69.3
Clef
83
Flash
97.7
Jev
52.3
BANKING77 意図分類
多クラス分類 Macro-F1 (%)
Omni
94.8
Clef
94.2
Flash
90.9
Jev
79.7
Omniは入力範囲が広いものの、これらのベンチマーク結果は全タスクにおける優位性を証明するものではなく、音声・動画専用の精度と見なすこともできません。BANKING77とCLINC150ではClefに近いスコアを記録していますが、家電シミュレーション、When2Call、RAGTruthでは異なるトレードオフが見られます。

Cloudflareの社内テストにおいて、OmniはBANKING77およびCLINC150+OOSの意図分類で、macro-F1がそれぞれ94.8%と97.7%を記録し、Clefに近い性能を示しました。しかし、スマート家電の指示シミュレーションでは、Flashの97.73%に対してOmniは69.30%と大幅に下回りました。また、ツール呼び出しのタイミングを判断するWhen2Callでは、Jevがリードしています(80.97%、Omniは63.30%)。これらは主にテキストと指示に関するテストであり、音声・動画専用の精度と見なすことはできません。

さらに、評価指標が何を求めているかにも注意が必要です。Omniの請求書処理では、主要アクション正解率(Primary action %)が82.0%であるのに対し、完全なアクションセットの一致率(Exact actions %)は60.2%にとどまります。前者は重要アクションのみを評価し、後者は一連の全アクションが完全に一致することを求めます。業務で一連の処理全体の正確性が必須となる場合、82%をプロセスの成功率と見なすことはできません。

どれだけ安くなり、コンテキストはどれだけ減ったのか?

Workers AIにおける現在提供されている3モデルのホスティング仕様と単価は以下のとおりです(いずれも出力トークン費用は無料):

モデル ホスト版のコンテキスト(tokens) 100万入力tokensあたり
Clef-flash 24,576 $0.038
Clef 65,536 $0.24
Clef-omni 64,000 $0.15

Flashの値下げに伴い、ホスティングウィンドウは64kから24kへと縮小されました。Cloudflareが示した根拠は、同社のオンラインリクエストにおいて24k tokensを超えるものはわずか0.24%だったという点です。オープンソースの重み自体に変更はなく、学習時は256kウィンドウに対応しています。長いコンテキストが必要な場合は、Clefを検討するか、ハードウェア要件に応じてFlashをセルフホストするという選択肢があります。

1回あたり1,000入力tokensで100万回呼び出すと仮定すると、Flashのモデル利用料は90ドルから38ドルへと低下します。ここでの単価の単位は100万tokensであり、100万回の呼び出しではない点に注意してください。

マルチモーダル入力に関して、Workers AIではメディアをBase64 data URLとして送信することが求められており、リモートURLは受け付けていません:

  • メディアのクォータ:1回のリクエストにつき画像最大4枚、音声最大4トラック(1トラックあたり≤300秒)、動画最大2本(1本あたり≤60秒、2 fpsフレーム抽出)。その他、ファイルサイズや解像度の制限については、Workers AIのメディア仕様を参照してください。
  • Token換算:音声は時間換算で約13 tokens/秒(780 tokens/分)。480p動画の映像部分は1分あたり約8,600 tokensを消費します(最高画質では約15,400 tokens/分)。前述の音声トラックの条件を満たす場合、音声部分は別途音声として換算されます。
  • 上限超過とトランケーション規則:メディア換算Tokenとquestionsは合算してコンテキストウィンドウにカウントされ、この2つの合計が上限を超えた場合はリクエストが即座にエラーで拒否されます。メディアと質問の合計が上限内で、テキストのstateを加えた全体が上限を超過する場合に限り、テキストのstateが自動的に切り捨てられます。

入力を変更してコストとウィンドウのトレードオフを確認

100万回の同一リクエストとして入力費用を試算。モダリティとトークン上限のみを検証し、モデルの出力品質は評価しません。

入力例を選ぶ
テキストと質問の合計(トークン数) 800 tokens
画像枚数(1枚あたり最大1,024トークンで試算) 0枚
音声1本(約13トークン/秒) 0秒
無音声動画1本(480p、約144トークン/秒) 0秒
テキストと質問のトークン数:800
画像の換算トークン数:0
音声の換算トークン数:0
動画の換算トークン数:0
1リクエストあたりの総入力トークン数:800
⚡ Clef-flash 上限内
$0.038 / M 入力
ホスティング上限:24,576 tokens
同じ入力で100万回の費用:約 $30.40
🎯 Clef (27B 稠密ベースライン) 上限内
$0.24 / M 入力
ホスティング上限:65,536 tokens
同じ入力で100万回の費用:約 $192.00
🌐 Clef-omni (30B-A3B MoE) 上限内
$0.15 / M 入力
ホスティング上限:64,000 tokens
同じ入力で100万回の費用:約 $120.00

計算式:1回あたりのトークン数 × 呼び出し回数 ÷ 1,000,000 × 100万トークンあたりの単価。画像は上限、メディアは概算値で試算。ここでの動画には音声トラックを含みません。アップロードバイト数、質問の長さ配分、その他のサービス費用は含まれていません。ウィンドウ超過時は試算を停止します:メディアと質問の合計が超過するとリクエストは失敗し、それ以外の場合はテキストのstateが切り捨てられる可能性があります。実際の入力を事前にご確認ください。

たとえば、3分間の音声(約2,340 tokens)に800 tokensのテキスト質問を付加したリクエスト(合計3,140 tokens)を評価する場合、Clef-omniの単価$0.15 / Mで計算すると、100万回呼び出しの純粋な推論費用は約471ドルとなります(メディアのストレージや転送帯域幅など、その他のクラウドインフラコストは含まれません)。

重みを変えずにClefが高速化できた理由は?

今回のClefの高速化はサービス層の改善によるものです。Cloudflareは3段階の入力規模における所要時間の中央値を公開しています:

入力規模 最適化前の所要時間の中央値 最適化後の所要時間の中央値 中央値での高速化倍率
~800 tokens 262 ms 152 ms 1.7×
~3,400 tokens 616 ms 305 ms 2.0×
~16,000 tokens 2,721 ms 1,635 ms 1.7×

モデルの重みは変更されておらず、SGLangへの移行が最適化の1つです(CloudflareはPR #42721を提出しており、SGLang 0.5.22で正式サポートされる予定です)。

セルフホスト運用の注意点

重みはApache 2.0ライセンスで公開されていますが、自前でホストする場合はハードウェアコストの計算が必要です。Omniの30Bは総パラメータ数であり、アクティブパラメータは1回あたり3Bですが、これは3B分の重みだけをロードすればよいという意味ではありません。モデルカードに記載されたbfloat16バックボーンのVRAM要件は約64 GB(テストではH200を使用)であり、さらに入力データ、キャッシュ、実行用ワークスペースのメモリを確保する必要があります。ClefにはすでにSGLangを使う起動方法が用意されていますが、Omniのモデルカードではその方法はまだ「coming soon」と記載されています。

既存のワークフローにどう組み込むか?

インターフェースでは、stateに判断対象の材料を配置し、questionsで質問と回答候補を定義します。修理依頼票の3つの問いは、以下の3つの問題タイプに対応しています:

  • noul:緊急かどうか?「はい」となる確率を返します。
  • choice:どのチームに割り振るか?1つの選択肢および各選択肢の確率を返します。
  • score:影響はどの程度深刻か?0から始まる順序付けられたスケールに基づき、確率で重み付けされた期待スコアを返します。

ClefはJev / SystemOneのインターフェースと互換性があり、AI Gateway経由のアクセスにも対応しています。すでに互換性のあるワークフローを運用している場合は、モデルを切り替えて置き換えテストを行うことが可能です。誤判定率、所要時間、判定しきい値を再測定した上で、どの分岐が自動処理に適しているかを判断するとよいでしょう。

Cloudflareはすでにどこで活用しているのか?

Cloudflareが公表したClefファミリーの社内導入事例には、ドキュメントリポジトリにおけるスパムIssueの検知と自動クローズ、EmDashにおけるプラグインライブラリのフィッシングリスク審査、DLPチームによる身分証などの個人識別情報(PII)のスキャン、脅威インテリジェンスチームによる悪意あるドメインの特定などが含まれます。ただし、これらの事例すべてでOmniが指定して使われているわけではありません。

意思決定モデルにより、ルールを網羅的に記述することが難しい細かな判断をプログラムで処理できるようになります。低リスクで検証済みの信頼できる分岐は自動化し、不確実なケースや高リスクな状況は人手による確認へと委ねます。自由な文章生成やオープンエンドな計画策定が必要な場面では、引き続き生成モデルがその役割を担います。

出典
Introducing Clef-omni with full multimodality, plus a faster Clef and a cheaper Clef-flashMichelle Chen、Alex Reneau、Kevin Jain / Cloudflare·原文を見る
↑ 本文ここまで
✓ この記事は全文無料です

メンバーは全文 Markdown のコピー・保存に加え、自分の AI に購読・質問させることができます。

原文を読む ↗
📮 新着解説をメールでいち早く

役に立ちましたか?メールを登録すると、新着解説を公開と同時にお届けします。解除はいつでも。