Cloudflare Clefが100万トークン0.09ドルで実現する、生成しないAIの超高速判定

• 事実と背景：Cloudflareが文章を生成せず選択肢の確率のみを返すオープンウェイトの意思決定モデル「Clef」を公開。
• 技術的変革：Qwenベースのモデルに軽量なheadとLoRAを組み合わせ、prefillのみで並列スコアリングを行うため出力トークンは常に0。
• 現場への影響：ECの問い合わせ分類や画像判定をミリ秒単位かつ超低コストで実行可能になり、高価なLLMの無駄遣いを防ぐ。

深夜2時、Slackの障害通知で叩き起こされる。原因は、ユーザーからの問い合わせを分類するために呼び出していたLLMが、指定したJSONフォーマットを無視して「はい、喜んで分類します！」などと余計な枕詞を出力したことによるパースエラーだ。我々エンジニアは、これまでLLMに「判定」をさせるためだけに、どれほど多くのプロンプトエンジニアリングを費やし、どれほど多くの無駄なトークン料金を支払ってきたことだろうか。

こうした「判定タスクに生成AIを使う不条理」に終止符を打つべく登場したのが、Cloudflareが2026年10月1日に発表した意思決定モデル「Clef」および「Clef-flash」である。Clefは、従来のLLMのように次の単語を予測して文章を紡ぎ出すことはしない。入力されたテキストや画像を読み込み、あらかじめ定義された選択肢の中から最適な答えを「確率」として返すことに特化したモデルだ。これは、先行するクローズドな判定モデル「Jev」の代替として名乗りを上げたオープンウェイトモデルであり、Hugging Faceでも公開されているためローカル環境での実行も可能となっている。

我々が日々直面する「この問い合わせはどの部署に回すべきか」「この画像は規約違反か」といったタスクにおいて、長々と文章を生成させる必要は一切ない。必要なのは、確実な分類と、その判断の「確信度（confidence）」だけだ。Clefは、まさにこのエンジニアの切実なニーズに1点突破で応える、極めて実用的なアーキテクチャなのである。

Clefの技術的なアプローチは非常に合理的だ。ベースモデルには実績のある「Qwen3.8-27B」（Clef）および「Qwen3.5-9B」（Clef-flash）を採用し、その重みは完全に凍結（フリーズ）されている。その上で、入力全体を1回だけ読み込む「prefill」処理を行い、ベースモデルの上に追加された小さな「head」と呼ばれるネットワークが、各選択肢のスコアを並列で計算する。学習時に更新されたのは、このheadとLoRA（Low-Rank Adaptation）の重みだけだ。

この構造がもたらす最大の恩恵は、推論時に「生成（generation）」のフェーズが存在しない点にある。つまり、出力トークン数は常に「0」だ。Cloudflare Workers AIの料金体系を見ても、課金対象は入力トークンのみ。100万入力トークンあたりClef-flashがわずか$0.09、上位モデルのClefでも$0.24という、既存のLLM APIと比較して桁違いの低コストを実現している。ここで、ClefとClef-flashのスペックおよび料金を整理しておこう。

実際の検証において、日本国内からCloudflareのWorkers AIを経由してリクエストを投げた際の往復時間（RTT）は、Clef-flashで平均166ミリ秒、Clefで406ミリ秒であった。ネットワークのオーバーヘッドを含めてもこの速度だ。ミリ秒単位のレスポンスが要求されるエッジ環境において、このレイテンシは強力な武器になる。デッドロック寸前の重いLLMパイプラインを、この軽量な判定モデルに置き換えるだけで、システム全体のボトルネックが一気に解消されることは想像に難くない。

「オープンソースの判定モデルは、日本語だと精度が落ちるのではないか」という懸念を抱くかもしれない。しかし、実際の検証結果はその懸念を払拭するものだった。ECサイトの問い合わせを想定した「配送（shipping）」「返品（returns）」「請求（billing）」の3分類タスクにおいて、問い合わせ文と質問の双方が日本語であっても、ClefおよびClef-flashは100%の精度で正しい担当を導き出した。さらに、日本語入力によるトークン数の肥大化もほぼ見られず、英語と同等の効率性を示した。

また、実務で極めて重要なのが「選択肢の順序バイアス」の排除だ。多くのLLMは、プロンプト内で最初に提示された選択肢を選びやすいという致命的な弱点（順序バイアス）を持つ。しかし、Clefは内部的に選択肢（criteria）をoption idの文字列順にソートしてからモデルに渡すため、APIに渡す順番を変えても出力される確率は小数点以下4桁まで完全に一致する。この決定論的な挙動は、本番環境での予測可能性を担保する上で極めて価値が高い。

さらに、Clefの真骨頂は「noul」形式の質問にある。1つの問い合わせに「商品が壊れていた（返品）」と「二重課金されている（請求）」という複数の用件が含まれる場合、単一選択の「choice」では確率が分散してしまい、どちらか一方しか検知できない。しかし、質問タイプを「noul」（yes/noの判定）にし、各担当への用件が含まれるかを個別に並列で問い合わせることで、1回のリクエストで複数のフラグを同時に、かつ正確に立てることができる。

一方で、マルチモーダル（画像判定）に関しては、まだ発展途上と言わざるを得ない。きれいな画像であれば「色の違い」や「破損」を検知できるが、手ぶれやノイズが加わると、特に軽量なClef-flashでは「破損」を見落として「注文どおり」と判定してしまうケースが散見された。画像を用いた厳密な検品タスクなどに投入するには、まだ慎重な検証が必要だろう。

我々エンジニアは、いつの間にか「何でもLLMに喋らせる」という思考停止の罠に陥っていなかっただろうか。ユーザーの入力を受け取り、それを分類し、次のアクションを決定する。この一連のフローにおいて、高価で、遅く、挙動が不安定な生成AIをフルスタックで使い続けることは、技術的な負債を自ら抱え込むようなものだ。Cloudflare Clefが提示したのは、AIの「役割分担」という極めて現実的な処方箋である。

明日からの開発において、我々が取るべきアプローチは明確だ。まず、ユーザーからの入力を受け取るゲートウェイ部分にClefを配置する。ここで「スパム判定」「モデレーション」「意図（インテント）の分類」をミリ秒単位かつ超低コストで終わらせるのだ。Clefが「これは複雑な生成タスクが必要だ」と判定したリクエスト（例えば、個別具体的な回答文の作成など）のみを、GPT-4oやClaude 3.5 Sonnetといった重量級のLLMにルーティングする。

この「判定と生成の分離」を徹底することで、APIコストは劇的に削減され、システムの応答速度は向上し、何よりも「LLMの気まぐれな出力によるシステムダウン」という悪夢から解放される。しかし、ここで一つの問いを投げかけたい。オープンウェイトで公開され、エッジでもローカルでも動く「意思決定モデル」が普及した世界において、我々がこれまで必死に書き溜めてきた「プロンプトによる条件分岐コード」の価値はどこへ行くのだろうか。モデル自体が構造化された判断を直接下せるようになった今、アプリケーションレイヤーの設計思想そのものが、根本的な再考を迫られているのではないだろうか。