はじめに

こんにちは。
この頃の仕事はデータ基盤の比重が高い者です。

いま、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