Jacky Kwok氏らの研究チームが、AIエージェントに与えられた行動や回答候補から適切なものを選ぶモデル「CLM-8B」を公開した。
現在の状況と選択肢を別々に処理して比較し、同じ選択肢については一度計算した結果を再利用できる。大規模言語モデルに毎回文章で回答させるのではなく、「与えられた候補のどれを選ぶか」に処理を絞ることで、高速な判断を狙ったモデルだ。
研究チームは、TypeSafeが開発する判断モデル「Jev」との比較で最大約9倍の高速化を報告している。コードと学習済みモデルはApache 2.0ライセンスで公開された。
ただし、「9倍」という数字はAIエージェントの仕事全体が9倍速くなるという意味ではない。どの部分をCLMに任せるのか、候補をどの程度使い回せるのか、速度と引き換えに選択精度がどこまで変わるのかによって、実際の効果は大きく異なる。
文章を生成せず、与えられた候補から選ぶ
CLMは「Contrastive Language Models」の略で、「対照学習」と呼ばれる方法を使う。
基本的な仕組みは、現在の状況と、その状況で選べる行動や回答候補をそれぞれベクトルに変換し、どの候補が現在の状況に最も合っているかを比較するというものだ。
学習では、正しい状況と行動の組み合わせが近くなり、誤った組み合わせが離れるように調整する。実際に使うときには、現在の状況と各候補の近さを計算し、最も高いスコアを得た候補を選ぶ。
例えば、顧客から届いた問い合わせを「請求担当」と「技術担当」のどちらへ送るかを判断する場合を考える。
問い合わせの文章は毎回変わるが、
- 請求担当：料金、請求書、返金を扱う
- 技術担当：不具合や障害を扱う
といった担当部署の説明はほとんど変わらない。
CLMでは、この候補側の説明をあらかじめ計算して保存しておける。新しい問い合わせが来るたびに、同じ「請求担当」「技術担当」の説明をモデルへ読み込ませ直す必要がない。
CLMの特徴は、現在の状況と選択肢を別々に処理できることにある。
基盤には80億パラメータのQwen3-8Bを使う。Qwen3-8B本体の重みは固定し、その上に「状態」と「行動」をそれぞれ処理する小さな射影ヘッドを追加して学習する。
射影ヘッドは、Qwen3-8Bが作った文章の表現を、状況と候補を比較しやすいベクトルへ変換する部分だ。
公開されたCLM-8Bは、約6000万件の質問・回答ペアで基礎を学習し、約3000万件の紛らわしい誤答を使って似た候補を見分ける能力を鍛え、さらに約100万件のAIエージェントの行動履歴で追加学習したという。
研究チームは、こうした高速な判断を担うモデルを「System One model」と呼んでいる。
重要なのは、CLM自身が新しい文章や解答案を作るわけではないことだ。
CLMが返すのは、与えられた候補の順位や確率である。候補そのものを作る必要がある場合には、大規模言語モデルなど別の仕組みを組み合わせる。
「最大9倍」は何を測った数字なのか
研究チームが公開したゼロショット評価、つまり各タスク向けの追加学習を行わない状態での比較では、CLM-8BはすべてのタスクでJevより短い応答時間を記録した。
一方、判断の正確さではJevを下回る項目もある。
| 評価タスク | CLM-8Bの待ち時間 | Jevの待ち時間 | CLM-8Bの成功率・成功数 | Jevの成功率・成功数 |
|---|---|---|---|---|
| T-Rex Game | 16.5ms | 149.8ms | 5/5 | 5/5 |
| ツール呼び出し（BFCL v4） | 76.8ms | 125.5ms | 95.2% | 99.2% |
| WikiRacing | 79.8ms | 225ms | 26/30 | 30/30 |
| Super Mario | 33.5ms | 132.6ms | 5/5 | 5/5 |
出典：研究チームのゼロショット評価。著者自身による測定であり、独立した第三者による追試結果ではない。
「最大9倍」という数字に相当するのがT-Rex Gameだ。
149.8msに対して16.5msなので、
149.8 ÷ 16.5 ≒ 9.08
となる。
ただし、BFCL v4ではCLM-8Bが95.2％、Jevが99.2％、WikiRacingではCLMが30回中26回成功、Jevが30回すべて成功している。
つまり、CLMが高速だったからといって、すべての用途でJevより良い結果を出したわけではない。
実際に利用する場合には、判断にかかる時間だけでなく、処理を高速化した結果として誤選択がどの程度増えるのかも見る必要がある。
T-Rexの「5/5」はモデル単体の成績ではない
ゲームの結果については、さらに注意が必要になる。
公開されているT-Rexの再現用実装では、Chromeの恐竜ゲームを模した環境で、恐竜を60秒間生存させる。
しかし、AIモデルだけで障害物を見てジャンプするタイミングを判断しているわけではない。
別の物理シミュレーターが、現在の速度や障害物との距離、モデルの応答時間などから、
- ジャンプ：安全
- しゃがむ：危険
- 走り続ける：危険
といった情報を事前に計算し、その結果をモデルへ渡す。
モデルの仕事は、その説明を読んで候補から選ぶことだ。
さらに、標準設定では安全機構も有効になっている。
モデルが物理シミュレーターによって「危険」と判定された操作を選んだ場合には、最も確率の高い安全な操作へ置き換える。また、衝突直前には緊急介入が行われる場合もある。
公開READMEも、ゲームの生存率はこうした補助機構を含めたシステム全体の成績であると明記している。
したがって、T-Rexで5回中5回成功したという数字を、「CLM自身がゲームを完全に理解して自律的に攻略した」と解釈することはできない。
測定環境にも違いがある。
CLMはRTX 4090を使ってローカルで動かしている一方、JevはTypeSafeのホスト型APIを利用しており、応答時間はクライアント側から測定されている。
つまり、モデル内部の純粋な演算速度だけを同じハードウェアで比較したベンチマークではない。
最大9倍という数字は、公開された実行環境を含めたエンドツーエンドの応答時間の比較として読む必要がある。
「コードを書く力」ではなく「候補から正解を選ぶ力」
DeepSWEとTerminal-Bench 2.1の結果は、ゼロショット評価とはさらに別の実験だ。
DeepSWEで報告された81.6％は、CLM自身が一からコードを書いて達成した数字ではない。
まずOpus 5が1つの課題に対して4つの解答案を生成する。その後、DeepSWE向けに追加学習したCLMが4候補を評価し、最も良いものを選ぶ。
学習に使用していない38課題で評価した結果、CLMが選んだ回答は31課題を解決し、
31 ÷ 38 ≒ 81.6％
となった。
同じ条件でJevに候補を選ばせた場合は71.1％だったと研究チームは報告している。
Terminal-Bench 2.1でも構造は同じだ。
こちらではFable 5が生成した5つの候補からCLMまたはJevが1つを選ぶ。学習に使用していない30課題で、著者が報告した結果はCLMが87.6％、Jevが83.1％となっている。
いずれも限定された評価用課題における結果であり、DeepSWEやTerminal-Bench全体でCLM単体がこの成績を出したという意味ではない。
選択処理の待ち時間については、DeepSWEでCLMが79ms、Jevが449ms、Terminal-Bench 2.1ではCLMが32ms、Jevが131msだった。
研究チームはH100上でCLMを測定したとしている。
ここで短くなっているのは、すでに生成された複数の解答案から1つを選ぶ時間だ。
Opus 5やFable 5が複数の候補を生成する時間や、そのために必要な計算量・API料金まで79msや32msに含まれているわけではない。
さらに、公開モデルのモデルカードでは、DeepSWEやTerminal-Benchの結果を再現するにはタスク向けの追加学習が必要だと明記されている。
Apache 2.0で公開されている基本モデルをそのまま実行すれば、81.6％や87.6％になるという意味ではない。
また、現時点で公開されている研究成果は、著者自身の技術資料とモデルカードを中心とするもので、査読済み論文によって確認された結果ではない。
候補を使い回せるほど高速化しやすい
CLMの構造が特に効きやすいのは、同じ候補を何度も評価する処理だ。
通常の生成モデルでは、現在の状況と選択肢をまとめて入力し、そのたびに回答を生成させる。
CLMでは現在の状況と候補を別々に処理するため、候補側の計算結果を保存して繰り返し使える。
例えば問い合わせの振り分けなら、「請求担当」「技術担当」「営業担当」といった候補はほとんど変わらない。そのため、一度作った候補のベクトルを再利用できる。
一方、毎回まったく異なる長い解答案を比較する場合には、それぞれを新しく処理する必要があるため、キャッシュによる利点は小さくなる。
研究チームが公開した別の測定では、固定した50候補をRTX 4090上で評価している。
毎回異なる状況を入力した場合、追加のベクトルキャッシュを有効にしても、サーバー側の待ち時間の中央値は28.8msから28.1msへの小幅な短縮だった。
一方、20種類の同じ状況を繰り返し訪れる条件では、2.0msから0.7msへ短縮したという。
これはJevとの比較ではなく、CLM内部でキャッシュを追加した場合の違いを測った実験だ。
状況そのものが毎回新しければ、その文章をQwen3-8Bで処理する必要がある。そのため、候補側をキャッシュしても計算のすべてを省けるわけではない。
逆に、状況や候補の両方を繰り返し利用できる処理では、キャッシュの効果が大きくなる可能性がある。
同じ「操作名」でも説明が変われば再計算が必要
候補をキャッシュできるかどうかは、単に操作の名前が同じかでは決まらない。
公開コードを見ると、選択肢に説明文が指定されている場合、CLMがベクトル化するのは操作名ではなく、その説明文だ。
例えば「実行する」という同じ操作名でも、
- このSQLを実行する
- このPythonコードを実行する
- このファイルを削除する
のように内容を毎回書き換えれば、候補の文章そのものが変わるため、新しく計算する必要がある。
そのため、部署の振り分けや固定されたツール一覧のように候補が安定している用途と、毎回異なる長い解答案を比較する用途では、得られる高速化の幅が違う。
CLMの「確率」は絶対的な正しさではない
CLMが返す確率の意味にも注意が必要だ。
候補Aが90％だったとしても、それは「現実世界でAが90％の確率で正しい」という意味ではない。
CLMは、与えられた候補同士のスコアにsoftmaxをかけ、その候補集合の中での相対的な確率を返している。
そのため、候補の内容や数を変えれば確率も変わる。
また、公開APIが返すconfidenceも、最も高い候補の確率から、それ以外の候補の平均確率を引いて計算した独自の指標だ。
高いconfidenceが返ったとしても、その操作が実際に安全で正しいことを保証するものではない。
自律的に処理を実行する場合には、一定以下の確信度なら人へ確認を求める、危険な操作は別のルールで止める、といった仕組みを組み合わせる必要がある。
「75MBのモデル」だけで動くわけではない
導入時には必要な計算環境にも注意が必要だ。
公開されているCLM用チェックポイントは約75MBだが、これはQwen3-8B本体ではない。状態側と行動側に追加する射影ヘッドなどのデータである。
実際にCLM-8Bを動かすには、その下で80億パラメータのQwen3-8Bも実行する必要がある。
公式の起動例では、vLLMでQwen3-8Bを埋め込みモデルとしてGPU上に立ち上げ、その上にCLMのAPIサーバーを配置する構成になっている。
また、標準の起動例では入力の上限を2048トークンとしている。
それを超えた入力は切り詰められるため、長い会話履歴や大量のログを判断材料として使う場合には、入力上限とGPUメモリーの設定を変更する必要がある。
候補選択そのものを高速化できても、判断に必要な情報が入力から落ちてしまえば意味がない。
どの処理ならCLMが効くのか
CLMの効果を評価するなら、まず自分のAIエージェントが繰り返している「短い判断」を探す必要がある。
例えば、
- 問い合わせをどの部署へ送るか
- 次にどのツールを呼び出すか
- 複数の検索結果からどれを採用するか
- 複数のAIが作った回答からどれを選ぶか
- 定型的な行動候補から次の操作を決める
といった処理だ。
候補がある程度固定され、同じ判断を大量に繰り返すほど、CLMの構造を生かしやすい。
一方、候補自体を毎回一から考える必要がある仕事や、長い推論を経なければ正解を判断できない仕事では、生成モデルを置き換えるものにはならない。
実際に導入する際には、CLMによって短縮できる判断時間だけではなく、候補生成を含めた処理全体の待ち時間と費用、誤選択率、判断を保留して人や別のモデルへ引き継ぐ割合まで測る必要がある。
その条件が合う用途では、CLMは大規模言語モデルに毎回短い判断文を生成させる代わりに、繰り返される「選ぶ仕事」だけを高速な専用モデルへ切り出す選択肢になり得る。
- AIの判断を毎回生成しない、CLM-8Bが行動候補の再利用で狙う高速化
- AIの「選ぶ仕事」を切り出すCLM-8B、ゲームとコード評価で見えた実力
- 最大9倍速い判断モデルCLM-8B、恐竜ゲームの評価を支える補助機構
