ClefとDecisions API：自動振り分けの基準をどう決めるか

問い合わせ文などを分類するとき、生成した文章から判定を取り出す代わりに、選択肢ごとの確率を直接受け取る方法があります。

確率やスコアを返し、基準値と比べて分類する設計そのものは、従来の機械学習でも使われてきました。

2026年10月1日、Cloudflareは、判定の対象となる文章などと、回答の形式を指定した質問を受け取り、選択肢ごとの確率を返す「決定モデル」Clef（クレフ）とClef-flashを公開しました。

Perplexityも、2026年10月に、同じく確率で答えを返すDecisions APIの提供を始めています。

こうした確率を使って、自動処理と人による確認を分ける際には、基準値となる「閾値（しきいち）」を設定します。

本稿では、サポートチケット（問い合わせを1件ずつ管理する記録）の振り分けを例に、業務上の条件と自社のデータをもとに閾値を選ぶ方法を考えます。

扱うのは、少数の選択肢から選ぶ判定タスクです。

CloudflareのRL（強化学習）を使った微調整サービス、画像入力の性能、ツール選択のような別用途は対象外とします。

2社が公表している機能と提供形態

共通点：回答形式を指定した質問を渡し、確率で受け取る

Cloudflareは、決定モデルを、確率にもとづく分類によって、エージェントの次の行動や人への引き継ぎの判断を支援するモデルと説明しています。

ブログの例では、サポートへの問い合わせ文と一緒に、「このリクエストは緊急か」というyes/noの質問と、「どのチームが担当すべきか」という選択式の質問（請求・技術・営業の3択）などを渡しています。

返ってくるのは文章ではなく、それぞれの質問への答えと確率です。

Perplexityのドキュメントも構造はほぼ同じです。

yes/no、選択式、あらかじめ定めた評価基準に沿った採点の3種類の質問を、1回のリクエストに複数まとめて渡せます。

選択式では、指定した選択肢ごとの確率に加えて、モデルの確信度（confidence）も返ります。

Perplexityのドキュメントは、モデルが返信文を書かず、判断の理由も説明しないと明記しています。

Cloudflareも、文章を生成させず確率だけを出力させる設計だと説明しています。

違い：提供形態と料金

Cloudflareは、両モデルの学習済みパラメーター（重み）をApache 2.0ライセンスでHugging Faceに公開したと説明しています。

自社の環境で動かすことも、Cloudflareが運用するWorkers AI上で利用することもできます。

一方、PerplexityのDecisions APIは、同社のサービスを呼び出して使う形です。

2026年10月8日に確認した公式料金ページでは、pplx-decider-v1.1-27b と pplx-decider-v1-27b の2つが並び、どちらも入力100万トークンあたり0.02ドル、出力は無料と案内されています。

Cloudflareのブログには料金の記載がありませんが、Workers AIの公式モデルページでは、Clefは入力100万トークンあたり0.24ドルと案内されています（2026年10月8日確認時点）。

たとえば仮に1件あたりの入力が1,000トークンで100万件なら、Perplexityの確認時点の単価で約20ドルという単純計算になります（この1,000トークンには、問い合わせ文だけでなく質問や選択肢の分も含めて数えます）。

ただし、これはAPIの入力料金だけです。

業務で見積もるべきなのは、単価に加えて、再試行、前後のシステム処理、人による確認や修正まで含めた総コストです。

Cloudflareの公開評価と、自社業務での評価を分ける

Cloudflareは、Clefが「Jev Decision Index」という評価でリーダーであり、比較対象の決定モデルJevを開発するTypesafe社自身の評価スイートでも、4つの業務領域のうち3つでJevを上回ったと説明しています。

以下の数値はCloudflareが実施・公表した評価結果であり、MIFが再測定したものではありません。

同じ表の中でも、すべての項目でClefが首位というわけではありません。

たとえば、いつツールを呼ぶべきかを判定する評価（When2Call、正解率）では、Jevが80.97で、Clefの72.37を上回っています。

ClefとClef-flashの間でも、課題によって差の出方は違います。

範囲外の問い合わせを含む意図分類（CLINC150+OOS）では、Clefが97.43、Clef-flashが66.77と大きな差が出ています。

この指標はmacro-F1で、分類ごとの評価を同じ重みで平均したものです。

件数の少ない分類の結果も、同じ重みで反映されます。

単純な正解率とは計算方法が異なるため、ほかの指標の数字とそのまま比べるものではありません。

なお、Cloudflareの説明では、ClefはQwen3.8-27B、Clef-flashはQwen3.5-9Bを基にしています。

規模だけを変えた比較ではないため、この表だけでは、差の原因をモデルの大きさで説明することはできません。

Cloudflareは、Clef-flashの遅延の中央値が38.8ミリ秒だったとも示しています。

これは同社の評価条件での値で、チケットの取得、API通信、結果の記録、担当の変更まで含めた業務の処理時間とは分けて考える必要があります。

ここから先は私たちの見解です。

こうした公開評価は、候補のモデルを絞り込む材料にはなります。

ただ、自社の問い合わせ文と自社の分類基準でどれだけ正確に分類できるかは、自社のデータで測って初めて分かります。

予測・対応方針・実行を分ける

モデルは、たとえば「この問い合わせは請求関連である確率が高い」という予測を返します。

その結果を受けて、担当チームを仮に割り当てるか、候補を示して人に選んでもらうか、特別な確認窓口へ回すかを決めるのが、対応方針の決定です。

決めた方針に従って、チケット管理システムの担当欄を書き換えるのが実行です。

この操作には、対応方針とは別に権限や承認条件を設定できます。

機械学習ライブラリscikit-learnの公式ドキュメントも、分類を「確率を予測する問題」と「その予測にもとづいて行動を選ぶ問題」に分けて説明しています。

私たちは、そこに「選んだ処理を、どの権限と承認条件で実行するか」を加え、3つを分けて設計するのがよいと考えています。

この区別が効くのは、たとえば返金です。

「請求関連の問い合わせだ」という予測から、「返金してよい」という結論は出ません。

返金には、対象の取引、契約条件、本人確認、金額、承認の有無といった別の判断材料が要ります。

返金の実行や契約上の判断は、この分類結果だけでは許可しない、というのが3つを分ける意味です。

なお、確率を受け取るからといって、必ず自動処理用の閾値が必要になるわけではありません。

すべてを人が確認する使い方もあり、以下は確率を使って自動処理と人の確認を分ける場合の話です。

閾値は、業務の条件を先に決めてから実測で選ぶ

閾値は、担当者の感覚だけで決める数字ではありません。

まず、自動化する業務の範囲、許容する誤り、人が1日に確認できる件数、閾値の採用を承認する担当者を決めます。

その条件を満たす閾値の候補を、検証データから選びます。

評価の指標や誤りのコストを指定して閾値を計算・調整する仕組みは、scikit-learnなどの機械学習ライブラリにも用意されています。

ツールを使う場合も、採用する条件と、変更の責任者は決めておきます。

誤りの重さは同じではない

サポートチケットでは、次の2つの誤りは同じ重さではありません。

• 通常の問い合わせを、本来とは別の担当チームへ誤って回す。
• 緊急の障害連絡を、通常の問い合わせとして後回しにする。

「最上位の確率が高いか」と「緊急案件を見逃していないか」は、別々に確認したい指標です。

部署分類の確率が高いからといって、緊急性がないとはいえません。

また、振り分けそのものは元に戻せても、誤った担当先に振り分けられていた間の対応の遅れまでは取り消せません。

取り消しやすさだけでなく、誤りに気づいて訂正するまでの時間と、その間の影響も見ておく必要があります。

確率の校正は、質問の形式によって確かめ方が違う

確率が返ってくることと、その確率が実際の当たりやすさと一致していること（確率の校正）は別の話です。

Cloudflareは、確率の校正を改善するための損失関数（Brier loss）を学習に使ったと説明しています。

ただし、それが自社の問い合わせで成り立つかは、ブログの説明だけでは確認できません。

確かめ方は、質問の形式によって変わります。

• yes/noの質問では、予測確率の確率帯（0.7〜0.8などの区間）ごとに、実際にyesだった割合を見ます。たとえば「緊急である確率」が0.2前後のチケット群なら、その中で本当に緊急だったものが約2割かを確認します。
• 選択式の質問では、最上位の確率について、確率帯ごとに、その選択が正しかった割合を見ます。

どちらも、確率帯ごとの件数と予測確率の平均値をあわせて見ます。

少ない事例で高い一致率が出ただけでは、十分な確認とはいえません。

さらに、校正がよいことと、自動化してよいことも別です。

0.9前後の予測が実際に約9割当たると確認できても、残る約1割の誤りを業務上許容できるかは、別に判断が要ります。

Perplexityのドキュメントには、運用上の注意もあります。

同じリクエストでも小数第2位がまれに変わることがあるので、閾値には余裕を持たせるように、とされています。

また、選択式のconfidenceは最上位の確率そのものではなく、2位との差が小さいと下がる値だと説明されています。

「人の判断」を、そのまま正解にしない

導入前には、既存の業務を続けながら、モデルの判定だけを並行して記録し、人による判定と比較する方法があります。

モデルの判定を実際の業務処理に反映させない、この方法を「シャドーモード」と呼びます。

ただし、担当者ごとに分類の基準が違っていたら、測っているのは正しさではなく「その担当者との一致」です。

比較に使う正解は、業務上の分類基準に沿って確認し、判断が分かれた事例は整理しておく必要があります。

特に、請求と技術の両方に関係する問い合わせなどは、どちらを正解とするのか、複数の部署を認めるのかを先に決めておかないと、評価結果を解釈できません。

進め方の一例

ここまでを踏まえた、私たちの提案する進め方の一例です。

1. 対象業務と評価基準を決める。分類先、緊急案件の扱い、正解の判定基準、自動処理してよい範囲を整理する。
2. 業務へ反映せずに評価する。実際の処理は既存の方法で続け、モデルの判定だけを並行して記録する。通常の例に加え、複数部署にまたがる例、情報不足の例、対象外の問い合わせも確認する。
3. 閾値の候補を比較する。自動振り分けの正しさ、緊急案件の見逃し、人が確認する件数を比べる。閾値を調整したデータだけで評価を終えず、別に確保しておいたデータでも確認する。
4. 範囲を限定して導入し、継続的に確認する。人に回した案件だけでなく、自動処理した案件も抜き出して確認する。問い合わせの傾向、分類基準、モデルや質問文が変わった場合は再評価する。

叩き台：上から順に確認する振り分け表

以下は、サポートチケットを担当チームへ振り分ける業務を想定した、MIFが提案する一例です。

自社の評価結果に基づいて調整してください。

記号は次の意味で固定します。

最上位の選択肢の確率を p1、2位の確率を p2、確率の基準値を T、上位2つの差の基準値を M とします。

表は上から順に確認し、最初に当てはまった行の対応を採用します。

確認の順序	条件の例	対応	主な実装先
1. 自動振り分けの対象外か	事前に人が扱うと決めた案件（返金・契約・法的な問い合わせなど）、緊急対応が必要な案件	指定した担当者・窓口へ回す	社内規程・権限設定、チケット管理システムのルール
2. 判定に必要な情報や結果に、不足・問題があるか	情報不足、分類基準の対象外、APIエラー、自社で決めた「要確認」の条件に当たる不確かな判定（緊急性のyes/noが0.5付近など）	「要確認」として担当者が確認する	自社システム側のルール（モデルの外）
3. 自動振り分けの条件を満たすか	p1 ≥ T かつ p1 − p2 ≥ M で、ほかの業務条件にも合う	許可した範囲で担当チームを仮割り当てする	チケット管理システムのルール
4. それ以外	1〜3のいずれにも該当しない	候補を示し、人が振り分ける	担当者の画面、社内の運用ルール

T と M の値は、前の節の手順で自社の評価結果から選びます。

確率と差の両方を使うこと自体も一例で、この組み合わせが常に最適という意味ではありません。

判定が不確かなときに、「該当なし」と確定させないことも大切です。

たとえば3択の確率が0.34、0.33、0.33だった場合、それは候補の間で差が小さいという意味で、「どれにも当てはまらない」と判定したわけではありません。

yes/noの0.5付近も、その問いへの不確かさを示すもので、第三の答えではありません。

「その他」「対象外」を業務上の分類として使いたい場合は、それを選択肢や別の確認条件として明示し、評価の対象に含めます。

最上位の確率が高いことだけで、対象外の入力を見抜けるとは限りません。

選択肢にない問い合わせを、既存の候補のどれかに強く割り当ててしまう可能性も、検証に含めておきたいところです。

同じく、1行目の「緊急対応が必要な案件」を、どの情報で見つけるかも別に評価が必要です。

記録と見直し

判定を後から追跡できるよう、問い合わせの識別情報、使用したモデル、質問・分類基準と閾値の版、出力された確率や判定結果、採用した処理、実行結果、人による修正を記録します。

問い合わせには個人情報や認証情報、契約情報などが含まれるため、入力の本文を保存する場合は、保存範囲、個人情報などを伏せる処理（マスキング）、閲覧権限、保持期間を決めます。

再評価用のデータも、同じ条件に従って管理します。

セキュリティの実践資料として広く参照されるOWASPのLogging Cheat Sheetも、機微な情報をそのまま記録しないことや、閲覧権限・保持期間の管理を挙げています。

設定した閾値が、実際の結果でも業務条件を満たしているかの確認は、定期的に、またモデルや質問を変えたときに行い、その担当者と責任者を事前に決めておきます。

モデルや判定条件の変更に備え、再評価と切り替え手順を決める

閾値は、そのときのモデルと質問の組み合わせに合わせて選んだ数字です。

新しいモデルに切り替えたまま、閾値だけを古い値に戻しても、以前と同じ判断になるとは限りません。

また、確率の出方は、モデルだけでなく、質問文、選択肢の定義、入力の作り方を変えたときにも変わる可能性があります。

これらも再評価の対象です。

そのため私たちは、モデル、質問と選択肢、前処理、必要に応じた確率の補正、閾値、業務上の分岐ルールを、どの組み合わせで評価・採用したか分かる形で管理することを勧めています。

PerplexityのDecisions APIは、呼び出しのたびにモデル名を指定する形です。

確認時点のドキュメントでは、pplx-decider-v1.1-27b と pplx-decider-v1-27b の2つが使えると案内されていました。

私たちは、どの版で評価したかを記録し、版を変えるときは再評価してから切り替えることを勧めます。

古い版がいつまで使えるのかは、今回確認した資料からは分かりませんでした。

モデル名の版番号だけでは、その版をいつまで利用できるか、動作が固定されているかまでは判断できません。

Cloudflareのモデルは重みが公開されているので、自社の環境で版を固定して動かす選択肢もあります。

いずれの場合も、検証済みの構成へ戻せるなら切り戻し、難しい場合は自動処理を止めて、人や既存の手順へ切り替える方法まで決めておくのが現実的です。

シャドーモードへ戻すことは、AIの判定を業務に反映しなくすることなので、その間のチケットを誰が処理するのかも、あわせて決めておく必要があります。

まとめ

私たちMIFは、モデルの予測、対応方針の決定、実際の操作を分けて設計することを重視しています。

自動振り分けに確率を使う場合は、対象業務と許容する誤りを先に決め、その条件を満たす閾値を自社のデータで検証します。

自動振り分けの正しさに加え、緊急案件の見逃し、人による確認が必要な件数、判断できない場合の対応も評価します。

採用したモデル、質問・分類基準、閾値の組み合わせを記録し、変更時には再評価します。

業務条件を満たさなくなった場合に、検証済みの構成へ戻すか、自動処理を止めて既存の手順へ切り替える方法も決めておきます。

情報確認について

本記事は2026年10月8日確認時点で、Cloudflareの公式ブログ「Clef decision models」（2026年10月1日公開）、Hugging FaceのClefモデルカード、Cloudflare Workers AIのClefモデルページ、PerplexityのDecisions APIドキュメント・公式変更履歴・料金ページを主要な参照元として作成しています。

確率の予測と行動の選択の区別、確率の校正の確認方法については、scikit-learnの公式ドキュメントを、ログの扱いについてはOWASPのLogging Cheat Sheetを参照しました。

製品の機能・料金・公開評価の紹介は各社の公表内容に基づくもので、MIFがAPIの性能を独自に検証したものではありません。

閾値の決め方、振り分け表、記録と切り替えの手順は、MIFによる設計の提案です。

料金、対応モデル、提供形態は変更される可能性があります。

利用前に、各社の最新の公式情報をご確認ください。