CloudflareのClefは、説明文ではなく判断を返す27Bのマルチモーダルモデルです。状況を表すstateと、答えてほしい質問を並べたquestionsを渡すと、あらかじめ定義した選択肢ごとの確率を返します。重みと推論コードはHugging FaceでApache-2.0ライセンスのもと公開されています。
面白いのは、回答を読む人ではなく、その先で分岐するコードに合わせた設計です。「この問い合わせは緊急か」「どの部署に回すか」を判断したいとき、説明文を生成してから値を取り出す工程を挟みません。
質問の型を先に決める
公開READMEでは、質問を次の型で指定します。
noul：真偽を問う質問。真である確率を返す。choice：名前付きの選択肢から選ぶ質問。選ばれた項目と、その確率、全選択肢の確率を返す。score：順序のある選択肢を使う質問。各段階の確率に加えて、段階のインデックスを確率で重み付けしたスコアを返す。
公式のサポート対応例では、決済エラーの状況に対して担当部署、緊急度、障害の有無をまとめて尋ねています。criteriaには選択肢の説明を入れ、何を区別したいのかを呼び出し側で定めます。
ここでscoreを「最もありそうな段階の番号」と読むと、実装を取り違えます。公開コードでは期待値を計算しているため、値は整数とは限りません。結果を業務の分岐に使うなら、返却値の意味まで確認しておきたいところです。
JSONを生成させる仕組みではない
ClefはQwen/Qwen3.8-27Bを追加学習したモデルです。バックボーンの最終隠れ状態を小さなTransformerの「joint schema head」が読み取り、各質問の選択肢をまとめて採点します。質問ごとのlogitにsoftmaxを適用すると、選択肢の確率になります。
READMEは、これを単一の順伝播で処理し、自由文の生成も出力のパースも行わないと説明しています。生成モデルに「JSONだけ返して」と指示する方式とは、出力までの仕組みが違います。ただし、形式が固定されることと、判断が正しいことは別です。確率を返すだけで業務上の正しさまで保証されるわけではありません。
公開モデルとホスト版の条件を混ぜない
自前で動かすためのREADMEには、H200を1基使い、torch 2.11とtransformers 5.10.2でテストしたとあります。これは動作確認環境の記述であって、最低要件ではありません。公開コードを読むだけの場合と、重みを読み込んで推論する場合では、必要な準備が違います。
Workers AIでは@cf/cloudflare/clefとして利用できます。ただし、公開実装で受け付ける入力を、そのままホスト版へ渡せるとは限りません。READMEは画像や動画フレーム配列を扱う一方、Workers AIの入力仕様には、画像は埋め込み形式で最大4枚、外部URLは受け付けないという制約があります。
入力長も同様です。公開実装のencode_recordはmax_lengthの既定値が16,384トークンで、Workers AIのモデルページにあるコンテキスト長65,536トークンとは区別が必要です。
まず試すなら、公式例のような担当部署の振り分けから始めるのがよさそうです。正解を付けた問い合わせで誤判定を調べ、人へ戻す条件を決める。Clefを採用する判断材料は、説明文の巧さではなく、その分岐を任せられるかどうかです。なお、本記事は公開資料とコードを確認したもので、推論の実測は行っていません。