Cloudflare Clefが38.8msを記録！意思決定モデルでAPI分岐を爆速化する手法

• 事実と背景：Cloudflareが意思決定モデル「Clef」を発表し、レイテンシ38.8msという驚異的な高速化を達成。
• 技術的変革：テキストを1トークンも生成せず、1回の推論で選択肢の確率分布を返すことで、パース処理や遅延を完全に排除。
• 現場への影響：開発者はエージェントの条件分岐やガードレールに導入することで、APIコストを削減しつつ応答速度を極限まで高められる。

開発現場でLLMをエージェントのルーティングやガードレール、JSONの構造化出力に使おうとして、遅延（レイテンシ）やパースエラーに悩まされた経験はないだろうか。私も深夜の障害対応で、LLMが想定外のマークダウンを出力してシステムがデッドロックした苦い経験がある。従来のLLMは、1トークンずつ逐次的にテキストを生成するオートリグレッシブ（自己回帰）な仕組みであるため、どうしても出力完了までに数秒の時間を要し、かつ出力のパース処理という不確実性を孕んでいた。

この「生成の遅さ」と「出力の不安定さ」という開発者の頭痛の種を、根本から解決するアプローチとして登場したのが「意思決定モデル（Decision Model）」だ。このモデルは、テキストを1トークンも生成しない。入力されたコンテキストと型定義された質問に対し、選択肢ごとの確率分布を「1回の推論」で直接出力する。つまり、LLMを巨大な分類器として機能させるのだ。

これにより、従来のテキスト生成型LLMで必須だった「JSONスキーマの強制」や「正規表現によるパース」といった泥臭いボイラープレートコードが一切不要になる。エージェントの条件分岐、セキュリティガードレール、チケットの自動振り分けといった、これまでLLMの遅延がボトルネックになっていたクリティカルなパスにおいて、この意思決定モデルはゲームチェンジャーとなる可能性を秘めている。我々エンジニアが長年求めていたのは、冗長な解説テキストではなく、システムを次に進めるための「YesかNoか」の確実な1ビットの判断なのだ。

この意思決定モデルの分野において、Cloudflareが発表した「Clef」および「Clef-flash」は、まさに既存の勢力図を塗り替える破壊的なスペックを引っ提げて登場した。先行するTypesafe AIの「Jev」が火付け役となったこの市場に、Cloudflareはオープンウェイト（Apache 2.0）という強力なカードを切ってきた。

Clefは「Qwen3.8-27B」、Clef-flashは「Qwen3.5-9B」をベースにポストトレーニングされたモデルであり、驚くべきことにClefは画像入力にも対応し、コンテキストウィンドウは64kに達する。特筆すべきはその圧倒的なレイテンシだ。Cloudflareの自社評価によると、レイテンシの中央値はClefが209.3ms、Clef-flashにいたっては38.8msという、従来のLLMの常識を覆す数値を叩き出している。Jevのレイテンシ中央値が524.1msであることを考えると、Clef-flashの38.8msは実に13倍以上の高速化を達成していることになる。

ベンチマーク集「Decision Index」においても、BANKING77やCLINC150+OOSといった実務的なタスクでJevを上回るスコアを記録している。一方で、GPQA DiamondやMMLU-Proといった高度な推論を必要とするタスクではJevに軍配が上がっており、モデルの特性に応じた使い分けが必要であることも示唆している。

さらに、Liquid AIも「d1」と呼ばれる意思決定モデルをAPI経由で提供開始した。d1は「noul（はい/いいえの確率）」、「choice（複数選択肢の確率分布）」、「score（ルーブリックに基づく確率加重位置）」という3つの直感的なAPIタイプを提供しており、開発者は「d1:free」モデルを用いて即座にプロトタイピングが可能だ。これらの選択肢の登場により、意思決定モデルは単なる研究段階の技術から、実生産環境に耐えうる実用的なコンポーネントへと進化を遂げたと言える。

一方で、APIの利用料金やベンダーロックインを懸念するエンジニアにとって、オープンソースコミュニティの動向は見逃せない。特に、推論エンジンとしてデファクトスタンダードの地位を確立しつつある「vLLM」に、テキスト拡散型言語モデル「DiffusionGemma」をJevのような意思決定モデルとして動作させる構造化生成モードがマージされたことは極めて重要な意味を持つ。

Matt Mastracci氏が主導したこの実装は、指定された構造化出力フォーマットでキャンバスの位置を固定し、トークンとlogprobs（対数確率）を提供するようモデルに要求することで、最も可能性が高い回答とその信頼度を1回の推論で抽出する。このアプローチの美しさは、高価なプロプライエタリなAPIに依存することなく、自前のインフラ上で意思決定モデルを完全制御できる点にある。

実際のテスト環境（DGX Spark 1台を使用）において、32並列時に毎秒54リクエスト（約162判断/秒）を処理できたというデータは、自社運用（オンプレミスやプライベートクラウド）における実用性を十分に証明している。これは、秒間数百リクエストが押し寄せる大規模なWebアプリケーションのバックエンドであっても、適切なハードウェアリソースを割り当てれば、意思決定モデルをインフラのボトルネックにすることなく統合できることを意味する。我々インフラやプラットフォームを設計するエンジニアにとって、この「制御可能性」と「スループットの予測可能性」は、APIの応答速度と同等以上に価値がある。

我々エンジニアは、これまで「LLM＝テキストを生成するもの」という固定観念に囚われすぎていたのではないだろうか。チャットUIの流行によって、何でもかんでもテキストで会話させようとした結果、システムの複雑性は増し、APIコストは跳ね上がり、レイテンシは悪化した。意思決定モデルの台頭は、そうした「生成の呪縛」に対する強力なアンチテーゼである。

しかし、ここで我々が直面する未解決の問いがある。それは、「すべての判断をブラックボックスの確率分布に委ねて本当によいのか」という点だ。従来のLLMであれば、思考プロセス（Chain of Thoughtなど）をテキストとして出力させることで、なぜその結論に至ったのかをデバッグすることができた。しかし、1回の推論で確率だけを返す意思決定モデルでは、その「思考の過程」が完全に隠蔽される。これは、金融取引の不正検知や医療トリアージといった、説明責任が強く求められる領域において、致命的な技術的・倫理的懸念となり得る。

明日から我々が取るべき実践的な処方箋は、システムのアーキテクチャを「ハイブリッド型」に再設計することだ。ユーザーとの対話や複雑なレポート生成には従来のLLM（ClaudeやGPT-4など）を使い、エージェントの内部ルーティング、入力ガードレール、単純なステータス遷移といった「ロジックの分岐」には、Clefやd1のような意思決定モデルを徹底的に配置する。この役割分担こそが、コスト、速度、そして信頼性を両立させる唯一の道である。

あなたは、自社のシステムに未だに「JSONを出力させるための重厚なLLMプロンプト」を書き続けてはいないだろうか。その無駄なトークン生成に支払っているコストと時間は、本当に必要なものなのだろうか。