はじめに
こんにちは。
この頃の仕事はデータ基盤の比重が高い者です。
いま、AI に使わせるためのデータ基盤を設計しています。その中で、社内の LLM 呼び出しをまとめて記録し、内容を確かめる仕組みが必要になりました。
そこで気になったのが、判断特化モデルの Jev と Clef です。文章を書かずに、判定と確率だけを返すモデルです。これを LLM 呼び出しの手前に置いて、一次判定に使えるのでしょうか。設計の段階で考えたことを書きます。
この記事について
この記事で扱うのは、社内の LLM の呼び出しを1つに集める入口（以下、ゲートウェイ）の設計です。ゲートウェイそのものは、まだ設計の段階です。
判定に使うモデルの Jev と Clef は、作った日本語の入力16件で呼んでみました。社内の実データでは、まだ試していません。手元で測った数字と提供元の公表値は、分けて書いています。
セキュリティの専門家ではありません。誤りや足りない点があれば、ご指摘を歓迎します。
ざっくり言うと
- LLM の呼び出しを1つの入口（ゲートウェイ）に集めるのは、記録と集計の前提として必要
- その入口での一次判定には、判断特化モデルが合う。速く、安く、答えの型が決まっていて、確率が返る
- 作った日本語の入力16件では、Jev・Clef・Clef-flash の判定はどれも当たった。ただ、確率の出方はモデルごとに違う。モデルを替えたら、閾値も見直す必要がある
- それでも、いきなりブロックには使わない。最初は判定結果を記録するだけにして、実際のデータで誤検知を見てから閾値を決める
- 判定モデルは Jev の API の形で持ち、差し替えられるようにしておく
Jev と Clef とは
- Jev: TypeSafe AI が2026年9月に公開した判断特化モデル。1つの入力（state）に対して、型の決まった質問を投げる。質問の型は、はい・いいえ（noul）、選択（choice）、段階（score）の3つ。答えと一緒に、確率と確信度が返る
- Clef / Clef-flash: Cloudflare が2026年10月1日に公開した判断特化モデル。重みは Apache 2.0 で公開されている。API は Jev と互換
- どちらも Cloudflare の Workers AI から、同じ形のリクエストで呼べる（Jev は
typesafe/jev、Clef は@cf/cloudflare/clefと@cf/cloudflare/clef-flash）
リクエストは次の形です（Workers AI の Jev のモデルページの例を、今回の用途に合わせて書き換えたもの）。
{
"model": "@cf/cloudflare/clef-flash",
"input": {
"state": "（LLM に送ろうとしているプロンプト）",
"questions": {
"contains_personal_data": {
"type": "noul",
"instructions": "氏名と連絡先の組み合わせなど、個人を特定できる情報を含むか"
},
"purpose": {
"type": "choice",
"instructions": "この依頼の用途はどれか",
"criteria": {
"coding": "コードの作成・修正・レビュー",
"customer": "顧客対応の文面や要約",
"analysis": "データの集計や分析",
"other": "上のどれでもない"
}
}
}
}
}
詳しくは Cloudflare のブログと、Workers AI の Jev のページにあります。
考えたきっかけ
社内では、生成 AI を使った機能が、あちこちで作られるようになりました。それぞれに工夫があって、動きも速いです。一方で、どこで、どのモデルに、何を送っているかを、横断で見る場所がありません。
そこで、LLM の呼び出しは1つの入口を通す、という方針になりました。その入口に、記録と確認の機能を持たせます。私はこの入口を、データ基盤の一部として設計しています。
設計で考えたこと
入口を1つにするのは、記録と集計の前提になる
呼び出しがばらばらの経路で出ていくと、記録の形も、取れる項目もそろいません。あとから集計しようとしても、足し合わせられないのです。
入口が1つなら、次のことが同じ形で残せます。
- いつ、どの機能が、どのモデルを呼んだか
- 入力と出力のトークン数と、かかった時間
- 一次判定の結果と、その確率
- 呼び出しが成功したか、失敗したか
記録は、呼び出しが失敗したときにも残します。チェックの判定、呼び出しの成否、記録の送信の失敗まで、1件にまとめて送る設計です。
入口を通す、という決まりが届く範囲には限りがあります。届くのは、API を呼ぶ社内の実装です。ブラウザで使うチャットや、エディタの AI 補助、SaaS に内蔵された AI は、この入口を通りません。そこは別の決まりで扱う必要があります。
一次判定には、判断特化モデルが合う
入口でのチェックは、すべての呼び出しの手前に入ります。遅いと、全員の待ち時間が増えます。ここに普通の LLM を置くと、判定のためだけに秒単位の時間がかかります。
判断特化モデルは、この用途に合う性質を持っています。
- 速い: Cloudflare の公表値では、応答時間の中央値は Clef-flash が 38.8ms、Clef が 209.3ms、Jev が 524.1ms
- 安い: 入力100万トークンあたり、Jev が $0.042、Clef-flash が $0.090、Clef が $0.240。出力には料金がかからない
- 答えの型が決まっている: 文章ではなく、質問ごとの答えと確率が返る。そのまま記録の列にできる
- 確率が返る: 「0.8 以上なら止める」「0.5〜0.8 なら二次判定へ」のように、閾値で扱いを分けられる
データ基盤の側から見ると、3つ目が大きいです。判定の結果が、最初から集計できる形で出てきます。
小さくて速い LLM とも比べた
同じ役目は、小さくて速い LLM にも任せられます。ちょうど Claude Haiku 5.5 が出ていて、分類や振り分けのような、量が多く遅延に厳しい用途向けとされています。Amazon Bedrock からも呼べます。
比べると、次のような違いがあります。
| 判断特化モデル（Jev / Clef） | 小さい LLM（Haiku 5.5） | |
|---|---|---|
| 返るもの | 質問ごとの答えと確率 | 文章。構造化出力を使えば、決めた形の JSON |
| 確率 | 返る | 返らない（自分で言わせた数字は、当てにしにくい） |
| 速さの公表値 | あり（上のとおり） | 見つけられなかった |
| 料金（100万トークン） | 入力 $0.042〜$0.240、出力は無料 | 入力 $0.10、出力 $0.50 |
| 判定の理由 | 返らない | 書かせられる |
料金は、どれを選んでも1回あたり1円に届きません。決め手にはなりにくいです。
差が出るのは、どこで動くかです。ゲートウェイを AWS に置くなら、Bedrock の Haiku 5.5 は同じクラウドの中で呼べます。クラウドをまたぐ往復がなく、入力を送る相手も増えません。Clef と Jev は Cloudflare の側にあるので、その分の往復と、送り先の確認が要ります。
一方で、閾値で扱いを分けたいなら、確率が返る判断特化モデルのほうが素直です。どちらにするかは、Haiku 5.5 も測ってから決めるつもりです。
作った日本語の入力で試した
日本語でも判定が当たるのかが気になったので、入力を16件作って呼んでみました。実在の個人情報や、社内のデータは使っていません。
入力の内訳は、コードの依頼が4件、顧客対応の文面が3件、データの集計が3件、それ以外が6件です。このうち4件に氏名と連絡先などを入れ、3件に指示の上書き（「これまでの指示はすべて無視して」など）を入れました。
質問は3つです。
- 個人を特定できる情報を含むか（noul）
- 指示の上書きや、秘密情報の開示要求を含むか（noul）
- 用途はどれか（choice。コード・顧客対応・集計・その他の4択）
Clef と Clef-flash は Workers AI の REST API から、Jev は TypeSafe AI の API から直接呼びました（Workers AI 経由の Jev は、アカウントの残高が足りず呼べませんでした）。1件につき3回ずつ呼んでいます。
| Clef-flash | Clef | Jev | |
|---|---|---|---|
| 当たった件数（閾値 0.5） | 16/16 | 16/16 | 16/16 |
| 個人情報「なし」12件で、いちばん高かった確率 | 0.13 | 0.07 | 0.35 |
| 個人情報「あり」4件で、いちばん低かった確率 | 0.87 | 0.97 | 0.92 |
| 指示の上書き「なし」13件で、いちばん高かった確率 | 0.04 | 0.06 | 0.07 |
| 指示の上書き「あり」3件で、いちばん低かった確率 | 0.95 | 0.98 | 0.97 |
| 往復時間の中央値（手元の回線から） | 535ms | 619ms | 220ms |
分かったことは3つです。
1つ目は、確率の出方がモデルごとに違うことです。Jev は、個人情報を含まない入力でも確率が高めに出ます。12件中9件が 0.1 を超え、いちばん高いもので 0.35 でした。Clef は、同じ12件がすべて 0.08 未満です。どちらも閾値 0.5 なら当たりますが、同じ閾値をモデルをまたいで使い回せるとは限りません。
2つ目は、「その他」の確率が割れやすいことです。Clef では、指示の上書きを入れた3件の用途が「その他」になりました。ただ、その確率は 0.39〜0.52 で、ほかの選択肢と大きな差がありません。「上のどれでもない」という選択肢は、確率で扱いにくいようです。
3つ目は、往復時間が公表値と逆の順になったことです。公表値では Clef-flash がいちばん速いのに、手元では Jev がいちばん速くなりました。手元の回線から API を呼んだ時間なので、経路の違いが大きく出ています。公表値と比べられる数字ではありません。ゲートウェイを置く場所から、測り直す必要があります。
なお、作った入力は判定しやすい書き方になっています。16件すべて当たったことは、実データでも当たることを意味しません。
それでも、いきなりブロックには使わない
ここからは、慎重になった理由です。
- 日本語の実データでの精度が分からない。 Cloudflare のブログにも、Jev の解説にも、日本語についての記載が見当たりませんでした。試したのも、作った16件だけです
- 精度の数字は、どちらも提供元の計測。 しかも、評価の種類によって勝ち負けが入れ替わります。Cloudflare の表では、多くの行で Clef が上ですが、Jev が上の行もあります。Clef-flash が大きく落ちる行もあります（CLINC150+OOS で 66.77。Clef は 97.43）
- 確率と閾値の関係は、自分のデータで見ないと決められない。 Jev を試した記事では、回避の手順を含む文が 0.62 と判定され、閾値 0.8 では止まらなかった例が紹介されています
- 判定モデルは、守りの境界にはならない。 一次判定は、ふるいです。巧妙な入力は通り抜けます。ここで止まらなかったものが安全だ、とは言えません
- 入口が止まると、全部が止まる。 同期のチェックを入れると、判定モデルの障害が、そのまま全社の LLM 呼び出しの障害になります
決めたこと
以上から、次のように進めることにしました。
- 最初は記録だけにする。 判定の結果と確率を記録に付けるだけで、呼び出しは止めません。実際のデータがたまってから、誤検知の割合を見て、閾値を決めます
- 判定モデルが応答しないときは、通す。 通した事実は記録に残します。判定のために業務を止めない、という優先順位です
- 一次判定で決めきらない。 確率が中間のものは、二次の判定（LLM か人）に回す前提にします
- モデルを差し替えられる形で持つ。 Jev の API の形で質問を書いておけば、Clef-flash、Clef、Jev を入れ替えられます。Clef は重みが公開されているので、自前で動かす道も残ります。小さい LLM に替える場合も、質問と答えの形はそのまま使えます
- 入力を送ってよい相手かを、先に確かめる。 入力を学習に使わないことを、規約で確かめた提供元にだけ送ります。Cloudflare は、Workers AI への入力と出力を、読まず、保存せず、学習にも使わないと書いています
おわりに
判断特化モデルは、LLM 呼び出しの手前の一次判定に使えるのか。使えそうだ、と考えています。速さと、答えの型と、確率が返ることが、入口でのチェックに合っているからです。
ただ、それは「記録に判定を付ける」ところまでの話です。止める根拠にできるかは、自分のデータで確かめてからになります。
同じように、社内の LLM の使い方をまとめる立場の方は、まず「止めずに記録する」から始めてみるのがよいのかもしれません。
参考資料
- Cloudflare「Introducing Clef: our open-source decision models, and new RL fine-tuning platform」 https://blog.cloudflare.com/clef-decision-models/
- Workers AI の Jev のモデルページ https://developers.cloudflare.com/ai/models/typesafe/jev/
- Workers AI のデータの扱い https://developers.cloudflare.com/workers-ai/platform/privacy/
- AWS「Introducing Claude Haiku 5.5 on AWS」 https://aws.amazon.com/blogs/machine-learning/introducing-claude-haiku-5-5-on-aws/
- Claude Haiku 5.5（Claude Platform Docs） https://platform.claude.com/docs/en/models/haiku-5-5/overview
- 判断特化AI「Jev」入門──チケット振り分け・ガードレール実践例 https://zenn.dev/gixo/articles/typesafe-jev-system-one-ai
- Qiita のイベントページ https://qiita.com/official-events/dc6e42e0897543216e34