Cloudflareは2026年10月1日、文章を生成する代わりに、あらかじめ用意した選択肢ごとの確率を返す意思決定モデル「Clef」と「Clef-flash」を発表した。Workers AIで提供するとともに、学習済みの重みをApache 2.0ライセンスで公開する。
一般的な大規模言語モデル（LLM）のように回答文を1トークンずつ生成するのではなく、「どの担当部署へ回すか」「処理を続けるか」「人に確認を求めるか」といった選択肢を直接評価する。AIエージェントが処理の分岐を決めるたびに、長い回答の生成を待つ時間を減らすことが狙いだ。
Cloudflareの測定では、軽量版Clef-flashの応答時間の中央値は38.8ミリ秒だった。ただし、評価項目によっては大型版Clefとの精度差が大きい。高速な判断を実際の業務へ組み込むには、どの仕事なら十分な精度を得られるのか、さらに顧客データを使った追加学習をどのような条件で利用できるのかを見極める必要がある。
文章を作らず、選択肢ごとの確率を返す
Clefに渡すのは、判断材料となる状況と、答えてほしい質問の組み合わせだ。
例えば、「購入手続きでエラーが続いている」という問い合わせについて、
- 緊急対応が必要か
- 請求担当と技術担当のどちらへ回すか
- 顧客への影響はどの程度か
といった複数の質問を一度に与えられる。
返ってくるのは説明文ではなく、あらかじめ定めた選択肢に対する確率や評価値だ。呼び出し側のプログラムは、その結果を使って担当部署へ自動で振り分けたり、処理を続けたり、人による確認へ戻したりできる。
質問には3種類の形式がある。真偽を判定するnoul、名前付きの候補から選択するchoice、順序のある段階を評価するscoreだ。
Cloudflareは、Typesafe AIの「Jev」が採用するSystem One APIと互換性があり、既存のJev向け実装から切り替えやすいとしている。
Cloudflareの技術説明によると、ClefはQwen3.8-27B、Clef-flashはQwen3.5-9Bを基盤としている。
通常のLLMは、入力を処理した後に回答を1トークンずつ生成する。一方、ClefはQwenを使って入力全体を処理した後、あらかじめ許可された選択肢を専用の機構で並列に評価する。
つまり、「理由を文章として生成してから答えを取り出す」のではなく、モデル内部で得られた情報から直接、各選択肢の確率を求める。文章を生成する工程を省くことで、判断までの時間を短くする仕組みだ。画像や動画を入力として扱う機能も備えている。
学習時には基盤となるQwenの重みを固定し、判断を行う部分と、少数の追加パラメーターでモデルを調整するアダプターを学習させた。
またCloudflareは、「モデルが80％と答えたものなら、実際にもおおむね80％正しい」といった形で、予測した確率と実際の正解率を近づける「確率の校正」にも取り組んだとしている。
これは、単に回答形式を固定するだけでなく、返された確率を「自動処理するか、人へ戻すか」といった業務上の判断にも使いやすくするためだ。
ただし、確率を出せること自体が、その判断の正しさを保証するわけではない。
速いClef-flashほど、任せる仕事を選ぶ必要がある
Cloudflareが公表した応答時間は、Clefが中央値209.3ミリ秒、Clef-flashが38.8ミリ秒、Jevが524.1ミリ秒だった。
遅い側の傾向を見る95パーセンタイルでも、Clef-flashが最も短い。
| 応答時間 | Clef | Clef-flash | Jev |
|---|---|---|---|
| 中央値 | 209.3ミリ秒 | 38.8ミリ秒 | 524.1ミリ秒 |
| 95パーセンタイル | 238.6ミリ秒 | 122.4ミリ秒 | 536.0ミリ秒 |
出典：Cloudflareの公表値。Cloudflare自身による評価であり、利用者の入力内容や実行環境で同じ応答時間が得られることを保証するものではない。
待ち時間をできるだけ短くしたい処理では、Clef-flashが魅力的に見える。
しかし、評価する仕事の種類を変えると、結果も大きく変わる。
発表に掲載されたCLINC150+OOSのmacro-F1では、Clefが97.43だったのに対し、Clef-flashは66.77だった。多数のカテゴリへ入力を分類するこの評価では、大型版Clefが大きく上回っている。
一方、BFCLの事例単位の完全一致率では、Clef-flashが98.76、Clefが98.47で、軽量版の方がわずかに高かった。
発表本文の抜粋表に掲載されていない評価でも、大きな差がある。
モデルカードの全結果によると、生成内容に含まれる誤りを検出するRAGTruthのF1はClefが79.4、Clef-flashが35.6だった。差は43.8ポイントになる。
これは2026年10月2日に確認した、CloudflareによるDecision Index 0.2.1の内部評価結果である。独立した第三者が再現した数値ではなく、公開表からは各課題の標本数や統計的な誤差も確認できない。
そのため、この43.8ポイントという差が、ほかの業務や日本語での利用でもそのまま現れるとは限らない。
それでも、AIエージェントが生成した内容に誤りがないか確認する役割までClef-flashへ任せるのであれば、この差は無視しにくい。
問い合わせを高速に振り分ける仕事で十分なモデルが、生成内容の誤りを見つける仕事でも十分とは限らないからだ。
必ず決められた形式で答えることと、その判断内容をどこまで信用できるかは別の問題である。
競合との比較でも、すべての評価でClefが優れているわけではない。
When2Callの正答率はJevが80.97、Clefが72.37、Clef-flashが65.58だった。
したがって、「最も速いモデルをすべての判断に使う」と決めるより、実際に任せたい仕事に近い評価を選び、自社のデータでも取りこぼしや誤判定を確認する方が導入判断には役立つ。
重みは公開、学習データは非公開
Workers AIの公式文書によると、入力100万トークンあたりの料金はClefが0.24ドル、Clef-flashが0.09ドルとなっている。
どちらも最大65,536トークンのコンテキストを扱える。これは2026年10月2日時点のモデル利用料金であり、周辺サービスや追加学習にかかる費用は含まない。
学習済みの重みが公開されているため、Workers AIを使わず、自社環境でモデルを動かすこともできる。
ただし、270億パラメーターのClefと90億パラメーターのClef-flashは、判断にかかる時間が短いからといって、動作に必要なGPUメモリーまで少ないとは限らない。
The Registerの取材に対し、CloudflareのAI Platform担当Michelle Chen氏は、64kのコンテキストを使い、同時に1件だけ処理する条件で、Clef-flashには41GB以上、Clefには85GB以上のVRAMが必要だと説明している。
これは特定の実行条件について示された値であり、短い入力や量子化したモデルでも同じ容量が最低限必要という意味ではない。
またMichelle Chen氏は、学習に使ったデータセットを公開していないことも同紙に認めている。
CloudflareはClefを「オープンソース」と表現しているが、Apache 2.0ライセンスで学習済みの重みを利用できることと、学習データを含めてモデルの作成過程そのものを再現できることは分けて考える必要がある。
つまり、モデルを自社環境で動かしたり改変したりできる一方で、Cloudflareがどのデータを使ってこのモデルを作ったのかまで完全に検証できるわけではない。
追加学習は、まずCloudflareのエンジニアと共同で進める
Cloudflareは、顧客固有の業務に合わせてClefを追加学習するサービスも発表した。
最初の段階では、CloudflareのForward-Deployed Engineer（FDE）チームが顧客と共同で追加学習を進める。その経験を基に、将来的には顧客自身がデータ収集から学習、再デプロイまで行えるセルフサービス型の仕組みを構築する計画だ。
つまり、モデル自体はすでに公開されているが、一般の利用者が画面上から自由に追加学習を始められるプラットフォームまで完成しているわけではない。
Cloudflareが示した構想では、同社がすでに提供している複数のAIサービスを組み合わせる。
AI Gatewayを通過するAIリクエストから顧客自身の学習用データセットを作成し、Workers AI上のClefを使って試行データを生成する。Containersを強化学習用の隔離環境として使い、AIエージェントの行動を採点したり再現したりする。
その結果を使って、新たに開発する「Trainer」でClefの重みを更新し、最終的には持ち込みモデルとしてWorkers AIへ再デプロイする構想だ。
Cloudflareは、これらの一部はまだ開発中だとしている。
単に汎用の意思決定モデルを提供するだけでなく、企業が持つ実際の判断データを使って、その企業専用の判断モデルへ作り替えるサービスにつなげようとしている。
現在の相談フォームでも、CloudflareのアカウントIDや契約プランに加え、具体的な用途や利用中のAI Platform製品について尋ねている。
現時点では、料金プランを選択して誰でもすぐに学習ジョブを開始できる一般向けサービスというより、具体的な用途を持つ顧客と共同で仕組みを作っていく段階と考えた方がよい。
通常の推論と追加学習では、データの扱いも異なる
顧客データをどのように扱うかについても、通常の推論と追加学習は分けて考える必要がある。
Cloudflareは、通常のClef利用では顧客から送られたリクエストや応答を読み取ったり、保存したり、モデルの学習に使ったりしないとしている。
ただし、顧客自身が追加学習サービスを利用する場合は別だ。
追加学習では、AI Gatewayを通過した顧客自身のリクエストや応答を学習用データセットとして利用する構想が示されている。
そのため実際に導入する企業は、どの通信記録を学習対象に含めるのか、個人情報や機密情報をどう除外するのかといった運用方針を決める必要がある。
Clefの次の焦点は、38.8ミリ秒という短い応答時間そのものではない。
実際の業務で使われる正解付きデータを与えたときに、必要な速度を維持しながら誤判定をどこまで減らせるかが重要になる。
その精度を基に、「この確率以上なら自動処理する」「この判断は人に戻す」といった基準を作れるようになれば、現在はLLMに任せているAIエージェントの細かな判断を、より高速な意思決定モデルへ置き換えられる場面が広がる可能性がある。
