Cloudflare が Clef を公開 — 「判断だけをする」オープンソースモデルと RL ファインチューニング基盤

要約

Cloudflare は 2026-10-01、decision models（判断モデル）の系列 Clef を公開しました。

「decision models」という呼び方が、この発表の中心です。 公式の定義は、自由文を返すのではなく「確率付きの型付き回答」（typed answers with probabilities）を返すモデルです。目的は、エージェントが人間の確認を挟まずにプログラム的な分岐を行えるようにすることです。

なぜ専用のモデルが必要なのかを整理します。

LLM に分類をさせる実装は、すでに広く使われています。 「この問い合わせは返品・交換・それ以外のどれか」を汎用 LLM に聞き、返ってきた文章から答えを取り出す。この実装には3つの弱点があります。

1つ目は、出力形式の不安定さです。 「返品です」と返ってくることもあれば、「おそらく返品に該当すると思われます」と返ってくることもあります。取り出す側にパース処理が必要になり、想定外の形式で落ちます。 structured output で緩和できますが、根本的にはモデルが文章生成器であることに由来します。

2つ目は、確信度が取れないことです。 「返品」と返ってきたとき、それが明らかに返品なのか、迷ったうえでの返品なのかが分かりません。迷っているケースだけ人へ回すという設計が組めません。

3つ目は、コストとレイテンシです。 分類は本来軽い処理ですが、汎用の上位モデルに聞くと、生成トークンぶんの時間と費用がかかります。

Clef は、この3つに対する回答として設計されています。 型付き出力なのでパースが不要、確率が付くので閾値で分岐でき、分類専用なので速い。

モデルは2つです。 Clef（Qwen 27B ベース、精度重視）と Clef-flash（Qwen 9B ベース、レイテンシ重視）。いずれも 64k コンテキストで、画像分類用の vision encoder を内蔵します。公式は vision encoder の内蔵を競合 Jev との差分として挙げています。

公式が示した数値。 Jev Decision Index ベンチマークで首位、レイテンシ中央値は Clef 209.3ms / Clef-flash 38.8ms（Jev は 524.1ms）。

ライセンスが重要です。両モデルは Apache 2.0 で完全にオープンソース化され、Hugging Face で配布されるとともに Workers AI でホスト提供されます。つまり、Cloudflare を使わずに自前で動かすこともできます。

あわせて、強化学習（RL）によるファインチューニング製品が発表されました。当初は forward-deployed engineer チームによるハンズオン提供で、将来はセルフサービス化し、「データ取得 → ファインチューニング → 再デプロイ」を Cloudflare 上で完結できるようにするとしています。

価格は本発表では開示されていません。

何が変わったか

• decision models（確率付きの型付き回答を返すモデル）の系列 Clef を公開
• モデルは2つ
  • Clef: Qwen 27B ベース、精度重視。レイテンシ中央値 209.3ms
  • Clef-flash: Qwen 9B ベース、レイテンシ重視。レイテンシ中央値 38.8ms
  • いずれも 64k コンテキスト、画像分類用の vision encoder 内蔵
• 競合 Jev のレイテンシ中央値は 524.1ms。公式は Jev Decision Index で首位としている
• Apache 2.0 で完全オープンソース化。Hugging Face 配布 + Workers AI でホスト提供
• RL（強化学習）によるファインチューニング製品を発表
  • 当初は forward-deployed engineer チームによる伴走型提供
  • 将来はセルフサービス化し、データ取得 → ファインチューニング → 再デプロイを Cloudflare 上で完結
• 価格は未開示

業務インパクト（一般企業向け）

この発表が効くのは「AI に分類させている処理」を持っている組織です。

自社にその処理があるかの見分け方を書きます。 次のどれかに当てはまるなら該当します。問い合わせの自動振り分けをしている。文書を種類別に仕分けている。入力内容が規程に違反しているかを判定している。エージェントの途中で「次にどの処理へ進むか」を LLM に決めさせている。

こうした処理の多くは、汎用の上位モデルで実装されています。 理由は単純で、他に選択肢がなかったからです。Clef のような専用モデルが出ると、ここを置き換える検討ができます。

検討の軸を3つに分けます。

1つ目は、確信度を使った設計です。ここが最も価値が大きいと考えます。

現在の分類処理の多くは、「分類結果だけ」を受け取っています。 その結果、迷った判定と明確な判定が同じ扱いになります。 自動処理に回すか人が見るかの境目が引けないため、「全部自動」か「全部人が確認」の二択になりがちです。

確率が付くと、三段構えにできます。 確率が高いものは自動処理、低いものは人へ、中間はログに残して後で精度を検証する。この設計は、自動化の範囲を段階的に広げることを可能にします。最初は閾値を高く設定して自動化率を低く抑え、実績を見ながら下げていく。自動化の導入で最も揉める「どこまで任せるか」を、数字で動かせます。

2つ目は、レイテンシです。

Clef-flash の 38.8ms は、対話の途中に挟める水準です。 従来、分類を挟むと数百ミリ秒から1秒程度かかるため、ユーザーが待つ処理の中には入れにくいという制約がありました。数十ミリ秒なら、入力の検証や意図判定をリアルタイムに挟めます。

ただし、公式のレイテンシ数値は条件が明記されていません。 入力長、同時実行数、ホスティング先（Workers AI か自前か）で変わります。自社の条件で実測してから設計に組み込むべきです。

3つ目は、Apache 2.0 であることです。これは統制の観点で大きいです。

「外部の API にデータを送れない」という制約で止まっている案件は、どの組織にもあります。 個人情報を含む問い合わせの分類、機密文書の仕分け。Apache 2.0 で Hugging Face 配布されるなら、自社環境で動かせます。 27B と 9B というサイズは、自前ホスティングが現実的な範囲です（9B なら単一 GPU で動く規模）。

この選択肢があることの意味は、交渉の余地が生まれることです。 情報セキュリティの審査で「外部送信は不可」と言われたときに、「では自社内で動かします」と返せるかどうかで、案件が止まるか進むかが変わります。

一方で、慎重に扱うべき点を2つ書きます。

1つ目は、価格が未開示であることです。 Workers AI 上での価格が出ていないため、マネージドで使う場合のコスト評価ができません。 現時点でできるのは「技術的に使えるか」の検証までで、コストを含めた導入判断は価格公開後になります。この区別を曖昧にしたまま稟議を書くと、後で数字が合いません。

2つ目は、ベンチマークの読み方です。 「Jev Decision Index で首位」は、Cloudflare が自社モデルについて述べた主張です。ベンチマーク自体が競合の名前を冠している点も含め、第三者による検証ではありません。 分類タスクは自社データでの精度が唯一の判断材料であり、ベンチマーク順位は参考程度に留めるべきです。自社の実データ100件程度で現行実装と比較すれば、十分な判断ができます。

RL ファインチューニングについては、現時点では「将来の選択肢」として記録しておく段階です。 当初は伴走型提供のため、自社だけで進められません。 セルフサービス化を待つか、Cloudflare との商談に乗るかの判断になります。ただし**「分類モデルを自社データで鍛える」という方向性自体は押さえておく価値があります。** 汎用モデルのプロンプト調整で精度を上げる作業には上限がありますが、ファインチューニングは別の上限を持ちます。

副業・個人活用視点

個人開発や小規模な受託で、Clef が効く場面は明確です。「分類にお金をかけたくない」ケースです。

個人のプロジェクトで分類処理を入れると、コストが読めません。 上位モデルに1件ずつ分類させると、件数が増えた分だけ費用が増えます。無料枠で始めたツールが、使われ始めた途端に赤字になるのは、個人開発で頻出の失敗です。

Clef-flash は 9B ベースなので、自前ホスティングが現実的な範囲です。 Apache 2.0 なので、自分のマシンやレンタル GPU で動かせます。 分類だけなら、これで足ります。「APIコストが読めないから機能を入れない」という判断を変えられます。

具体的な使いどころを2つ挙げます。

1つ目は、投稿やコメントの事前判定です。 個人で運営するサービスに投稿機能を付けると、不適切な内容のフィルタが必要になります。 全件を上位モデルに通すのは高く、キーワードフィルタでは抜けます。分類専用モデルで確率を出し、高確率のものだけ止め、中間は保留にするという設計が、コストを抑えて組めます。

2つ目は、自分用の自動仕分けです。 受信したメール、保存した記事、撮ったスクリーンショット。vision encoder 内蔵なので画像も同じモデルで扱えます。 自分用のツールなら精度が完璧でなくてよく、確率が低いものは「未分類」に置けば済みます。

受託の文脈では、「外部に送れないデータの分類」が提案材料になります。

地方の中小企業や、医療・士業・自治体関連の案件では、「クラウドの AI に送れない」が最初に出る制約です。 この制約があると、多くの AI 提案はそこで終わります。Apache 2.0 のモデルを自社環境で動かすという選択肢を提示できると、話が続きます。

ただし、提案する前に自分で動かしてから持っていくべきです。 「オープンソースなので自社内で動かせます」と言った後に、実際のセットアップで GPU 要件やメモリに詰まるのは最も避けたい展開です。9B モデルがどの構成で動くかを自分で確認してから提案してください。

もう1つ、提案時に正直に言うべきことがあります。保守の問題です。

自社環境でモデルを動かす構成は、作った後の面倒が増えます。 モデルの更新、推論サーバーの運用、障害時の対応。マネージドなら Cloudflare が持つ部分を、自社で持つことになります。 「外部に送らずに済む」という利点と引き換えに運用負担が発生することを、提案の時点で伝えるべきです。伝えずに作ると、半年後に「誰も面倒を見られない」という状態になります。

学習の観点では、「decision models」というカテゴリの切り出し方に注目する価値があります。

**汎用 LLM は「何でもできるが、何に対しても生成器として振る舞う」**モデルです。分類は本質的に生成ではありません。 選択肢の中から選ぶ処理に、文章を生成するモデルを使っていたのは、他に選択肢がなかったからです。

この「汎用モデルで無理に代替していた処理が、専用の形に戻る」という動きは、今後も出てくると考えられます。 分類、ランキング、抽出、スコアリング。汎用モデルの便利さに慣れると、処理の性質を考えずに全部を同じ道具でやるようになります。 専用モデルが出てきたときに「これは本来どういう処理か」を考え直せるかどうかは、設計者としての差になります。

確率を返すという設計も、同じ観点で見る価値があります。 「答え」だけを返す仕組みは、使う側から判断の余地を奪います。 確率が付いていれば、閾値を自分で決められます。自分が作るものでも、「答えだけ返す」か「確信度も返す」かは意識して選ぶべき設計判断です。