問い合わせが届く。まずは請求、技術、営業のどこへ回すかを決めたい。欲しいのは立派な返事ではなく、行き先ひとつだ。
ここに、毎回長い文章を書いてくれるAIを置く必要はあるだろうか。
2026年10月1日、Cloudflareが公開したClefとClef-flashは、そうした仕事を受け持つ「判断モデル」だ。状況と選択肢を渡すと、文章を生成せず、選択肢ごとの確率を返す。しかも、クラウドで呼び出すだけでなく、公開された重みを手元で動かす道も用意された。Cloudflareの発表
AIを、チャットの相手だけでなく、アプリの小さな判断係として使う。今回の発表は、その選択肢を広げるものだ。
「何と返すか」の手前に、「誰に回すか」がある
たとえばネットショップの窓口で、「お客さま全員が決済できない」と届いたとする。これは記事の説明用に作った例だ。金額の確認ではなく、システムの不具合を見てもらいたい場面だろう。
Clefに渡すのは、問い合わせの本文と、こちらで用意した質問だ。
どの担当へ回す？――請求・技術・営業。
急ぎの案件？――はい・いいえ。
影響はどの程度？――順序を付けた段階。
返ってくるのは、その質問に対応した答えと、各候補に割り当てられた確率。返信の下書きも、返金処理も、担当者への通知も、このモデルが勝手にしてくれるわけではない。そこは周囲のプログラムの仕事になる。
Clefの判断と、その先の実行を分けた概念図。タグ付けと人の確認は運用例で、実装済みの窓口システムではない。
公式の型は、はい／いいえのNoul、候補から選ぶChoice、順序付きの段階を扱うScoreの三つ。自由な返答文を読んで「つまり技術担当ということかな」と解釈し直すのではなく、最初からアプリが受け取りやすい形で返す。Workers AIのモデル仕様
もちろん、「技術82%」という数字が出ても、それだけで現実の正解率が82%になるわけではない。候補同士がどれくらい拮抗しているかを見る材料であり、業務で任せる線は、実際の問い合わせで確かめる必要がある。
速さの理由は、長い答えを書かないこと
一般的な文章生成モデルは、返答をトークン単位で書き足していく。Clefは、入力を読んだ後、指定された選択肢をまとめて採点する。Cloudflareは、この判断部分を非自己回帰の仕組みと説明している。
「請求担当に回すのが適切です。理由は……」と説明文を完成させる代わりに、請求・技術・営業の点数を出して終える。選ぶだけで足りる仕事なら、この割り切りが使いやすい。
ただし、速く返ることと、正しく選ぶことは別だ。Cloudflareの公開評価でも、項目によってJevのほうが高い結果がある。速さだけで、あらゆる判断を置き換えられると読む発表ではない。
大きいClef、軽いClef-flash。どちらも「書くAI」ではない
Clef：Qwen3.8-27B — 大きい側の判断モデル。必要な処理性能と、自分の仕事での結果を見たい。
Clef-flash：Qwen3.5-9B — 小さい側の判断モデル。手元で試す候補になるが、9Bでも導入は軽作業とは限らない。
両モデルの重みはApache 2.0で公開されている。Clef-flashの公式モデルカードは、文字・JSONに加え、画像や動画フレームの入力も案内している。たとえば「画像から長い説明を書いて」ではなく、「用意した候補のどれに当たる？」と聞く方向だ。Clefのモデルカード／Clef-flashのモデルカード
利用経路の違いには注意したい。Hugging Faceのローカル実装は動画フレームも扱う一方、今回確認したWorkers AIのAPI仕様では画像入力の案内が中心だ。同じ名前だから、どこでも同じ入力を受け付けるとは限らない。
Jevと互換。でも、判断の基準まで同じとは限らない
Cloudflareは、TypeSafe AIのJevとAPI互換だと説明している。状況と質問を渡し、型の決まった答えを受け取る――既存の組み立て方を活かしやすいのは魅力だ。
けれど、公式コードと現行ドキュメントを照合すると、気になる違いもあった。confidenceという同じ名前の数値でも、計算方法が違う。
Clefの公開ローカル実装では、Choiceのconfidenceは、選ばれた候補の確率そのもの。一方、TypeSafeの現在の説明では、候補が均等に割れた状態を0として補正する。同じ3択で、候補の確率が60%・30%・10%だった場合、前者は0.6、後者は0.4になる。
これは式に同じ数字を入れた説明用の計算で、両モデルに同じ問い合わせを投げた測定結果ではない。それでも、なぜ単純な差し替えでは困るかは分かる。「confidenceが0.5以上なら自動で回す」という既存の基準は、返答の形が同じでも、そのまま移植できないのだ。Clefの公開実装（確認した版）／TypeSafeのConfidenceの定義
チャットAIを小さくするのではなく、仕事を切り分ける
使い分けを考えるなら、こんな整理が分かりやすい。
金額を計算する、期限を比べる：計算や条件分岐を書く。意味の判断が要らなければ、AIを置かなくてもよい。
文面の意味から担当候補を選ぶ：判断モデルを候補に。選択肢と、人へ戻す運用を先に決める。
返信を書く、理由を説明する、案を広げる：文章生成AIの出番。判断モデルだけでは、欲しい説明文は出てこない。
たとえば、問い合わせの仕分けだけをClefに任せ、回答案は別の生成AIに頼み、最後に担当者が確かめる。そういう小さな組み合わせなら、何をどこに任せたかが見えやすい。
公開モデルなので、入力を外部の推論APIへ送らず、手元の環境で計算する構成も検討できる。ただ、ローカルに重みがあるだけで「安全な顧客対応システム」が完成するわけではない。モデルや依存関係の事前取得、外向き通信の確認、ログと端末の管理は別に必要だ。Hugging Faceのオフライン利用の説明
面白いのは、すべてを巨大なAIに丸投げする話ではないところだ。「ここでは文章はいらない。行き先だけ選んでほしい」と、仕事の形に合わせてAIを置ける。手元でも動く判断モデルは、その設計を試すための新しい部品になりそうだ。
この記事は2026年10月3日時点の公式情報を確認したニュース解説です。実機での速度と出力は、別のLAB記事で紹介します。
動画で見る、文章を書かないAIの役割
EDIFORCE NEWSの解説動画。動画内の速度はCloudflareの公表値で、私たちのMac・NVIDIA測定とは別のものです。
