TypeSafe AI の「jev」公式アーキテクチャパターン4選

はじめに

昨今、TypeSafe AI が公開した「判断」を返すモデル jev が注目を集めています。 公式ドキュメントには、jev をシステムに組み込むためのアーキテクチャパターンが 4 つ紹介されています。

今回は、これらを実際のプロダクト構築に取り入れようと、4 つのパターンを実際に API で動かし、入力と出力を確かめました。

検証の例題には、架空の 「朝採れ卵の直売」における広告審査システム を採用しています。各パターンの動作イメージを確認できるよう、動くデモ画面も用意しました。

※ なお、本記事のデモ画面は jev を呼び出していません。コストの観点から、2026 年 9 月 23〜24 日に記録した jev の API レスポンスを再生する仕組みにしています。

（出典: Patterns、2026-09-24 確認）

jev について

1. jev とは（System One モデル）

jev は、TypeSafe AI が開発した判定特化型のモデルです。 製品カテゴリー名にある「System One」とは、ダニエル・カーネマンの著書『ファスト&スロー』に登場する「直感的で速い思考（System 1）」に由来しています。

これまでの一般的な LLM（Claude や ChatGPT など）は、テキストを 1 トークンずつ生成しながら回答を作成しています。それに対して、jev は文章の生成を一切行いません。

プログラムから渡された情報に対して、あらかじめ定義された型に従って「判断（分類や評価）」を返します。

■ 構造について

jev の仕組みは非常にシンプルで、2 つの入力を与えると2 つの出力が返ってきます。

• 入力（2 つ）
  1. 状態 (state): 審査対象のコンテキスト（テキスト、または JSON のオブジェクトや配列）
  2. 型の付いた質問 (questions): 判定したい質問群（例: 「公序良俗に反するか」など）
• 出力（2 つ）
  1. 型の付いた値（choice / score / noul）: 判定結果（Choice なら選んだ選択肢 choice、Score なら段階上の位置 score、Noul なら「はい」の確率 noul）
  2. 確率(probabilities)と確信度(confidence): 選択肢や段階ごとの確率 probabilities と、その分布を 1 つの値にまとめた確信度 confidence（Choice と Score のみ。例: 0.73）

■ メリットについて

従来の LLM で判定を行うと、生成された文章から JSON を抽出・パース（構造化）する処理や、出力形式の揺れを考慮した例外処理などが必要となりました。

一方 jev は最初から「型の付いた値」として結果が返されるため、パース処理を書く必要がなく、プログラム側でそのまま if 文の条件分岐やスコア順の並べ替えに利用できるのが最大のメリットとなります。

（出典: Introduction、System One、2026-09-23 確認）

2. 2 つの入力（state と questions）について

■ 状態（state）とは

state とは、jev を利用して判断したいコンテキストを指します。

■ 型の付いた質問（questions）とは

questions とは state に対して投げかける質問を指します。

・ 質問の 3 つの型

質問の型	訊き方	返る値
Choice	用意した選択肢から 1 つ選ぶ	選んだ選択肢、確率、confidence
Score	決めた段階で採点する	点数、確率、confidence
Noul	文が正しいかを判定する	正しい確率（0〜1）

これら 3 つの型は、1 回のリクエストに混ぜて渡すことができます。

なお、すべての質問は同じ state に対して並列かつ独立して評価されます。そのため、質問 A の答えを前提に質問 B を判定したい場合は、コード側で API をもう一度呼び出す必要があります。

（出典: Introduction、Primitives、2026-09-24 確認）

3. 2 つの出力（型の付いた値と、確率と確信度）について

■ 型の付いた値（choice / score / noul）とは

判定結果として返ってくる、型定義された値そのものを指します。質問の型（Choice / Score / Noul）に応じたフォーマットで返却されます。

■ 確率（probabilities）と確信度（confidence）とは

判断結果の「確かさ」を表す指標です。

• 確率 (probabilities): 各選択肢や段階に対して割り振られる分布データです。特定の 1 つに数値が集中していれば確かな判断、広く散らばっていれば迷っている判断と言えます。
• 確信度 (confidence): 確率の分布状態を 0〜1 の単一数値にまとめたものです。1 に近いほど判断の不確実性が低く、0 に近いほど不確かであることを示します。

・ 出力の具体例（レスポンス構造の対応表）

jev に質問（Choice 型）を投げた際、実際のレスポンスに含まれるデータ項目（キー）と具体的な値の対応は以下のようになります。

• 例: 広告の掲載可否を判断した場合（確信度が中程度の場合）
  • state（入力）: 「朝採れ卵、10個 480円。スーパーより新鮮です。直売所で毎週土曜に配ります。」という「チラシ」の文面と、「HPの広告」の内容
  • questions（入力）: 「『チラシ』の掲載可否はどれか」を、safe / needs_review / unsafe の 3 つから 1 つ選ぶ（Choice 型）

データの項目（キー）	レスポンスの値	説明
型の付いた値（Choice 型の場合）	“safe”	選ばれた選択肢
確率（probabilities）	“safe”: 0.82, “needs_review”: 0.14, “unsafe”: 0.04	各選択肢の確率表示
確信度（confidence）	0.73	safe に確率が集まっているが、確信度は中程度の値

※ なお、Noul 型 には confidence が付与されません。Noul は「文が正しい確率（0〜1）」そのものを返すため、数値が 0.5 に近いほど不確実な判断であることを意味します。

・ 確信度（confidence）に応じた制御のアイデア

適切な閾値は扱う業務領域やモデルの精度特性によって調整することになりますが、公式ドキュメントでは、この confidence の値に応じてシステムの振る舞いを動的に切り替えるパターンが示されています。

• 高い（例: 0.9 超）: 人の手を介さず自動で処理を完了する
• 中程度: ユーザーに「こちらの内容でよいですか？」と確認を挟む
• 低い（例: 0.5 未満）: 自動処理をスキップし、人間のオペレーターによる確認に回す

（出典: Confidence、Primitives、2026-09-24 確認）

4 つのアーキテクチャパターン

公式ドキュメントで紹介されているパターンは以下の 4 つです。 いずれも 「判断自体は jev からまとめて受け取り、その後の分岐処理はプログラム（コード）側で制御する」 という設計思想に基づいています。

1. Speculative fan-out（先回りしてまとめて訊く）

使うかどうか分からない質問も含め、想定される質問をすべて 1 回のリクエストに詰めて投げるパターンです。

前述の通り、jev は複数の質問を並列かつ独立して評価するため、質問数を増やしても応答時間がほとんど変わりません。また、出力トークンは課金されないため、後で使うかもしれない判定もコストを抑えて先回りで取得できます。

• 注意点: 質問文のテキスト自体は入力トークンとして課金対象になります。
• 使いどころ: 広告審査のように、チェックすべき判定項目があらかじめ複数定義されているケース。

以下のデモ画面では、「掲載可否」、「断定的な表現」、「完成度」に加えて「HPの広告」との「整合性」、「トーン」、「想定年齢層」といった計 6 つの質問を 1 回のリクエストでまとめて判定しています。

背景直売所の朝採れ卵を宣伝する「チラシ」と「HPの広告」の2つに食い違いがないかを審査している場面です。state には、「チラシ」の文面と「HPの広告」に記載されている内容を入力します。

状態（State）：判断したいコンテキスト

「チラシ」: 朝採れ卵、10個 480円。スーパーより新鮮です。直売所で毎週土曜に配ります。 「HPの広告」: 自家飼育のニワトリの卵を、毎週土曜の朝に直売所で販売。1パック10個480円。予約不要。

型の付いた質問（Questions）：state に投げかける質問

質問名	型	訊いていること（選択肢・段階）
brand_safety	Choice	「チラシ」の掲載可否はどれかsafe / needs_review / unsafe
prohibited	Noul	「チラシ」は景品表示法で問題になりうる断定的な表現を含むか
quality	Score	「チラシ」の広告コピーとしての完成度低い / 普通 / 高い / 非常に高い
hp_match	Noul	「チラシ」の内容は「HPの広告」の内容と食い違っていない
tone	Choice	「チラシ」のトーンはどれか親しみ / 高級 / 煽り / 事務的
target_age	Choice	「チラシ」が主に想定している年齢層はどれか20代以下 / 30〜40代 / 50代以上 / 特定できない

jev-1.13.0実行

型の付いた値・確率・確信度（Response）※ jev は呼び出していません（2026-09-24 12:44 JST の記録を再生）

「実行」を押すと、ここに応答が表示されます

（出典: Speculative fan-out、2026-09-23 確認）

2. Confidence-gated routing（confidence で振り分ける）

choice や score で選ばれた「答えの中身」と、その答えの「confidence（確信度）」を分けて評価するパターンです。

「何と判定されたか」だけでなく「confidence が高いか」も合わせてコード側でチェックすることで、処理を自動で進めるか、人間の確認へ回すかを振り分けることができます。

• 閾値（しきい値）の決め方: 誤判定が起きた際のリスクによって変えます。取り返しのつかない処理ほど閾値を高く設定し、confidence が閾値に達しなければ人間の確認へと回します。
• 使いどころ: 広告の掲載可否のように、誤って通した場合の損害が大きなケース。

以下の画面では、健康効果をうたう広告の掲載可否を訊き、返ってきた confidence をコード側の閾値と比べて振り分けています。

背景健康効果をうたう広告の掲載申請が届いた場面です。jev に掲載判断（allow / review / block）を訊き、返ってきた confidence がコード側の閾値に届くかどうかで、そのまま実行するか人の確認に回すかを決めます。

状態（State）：判断したいコンテキスト

朝採れ卵を毎日食べれば、病気知らずの体に。直売所で毎週土曜に販売。

型の付いた質問（Questions）：state に投げかける質問

質問名	型	訊いていること（選択肢・段階）
decision	Choice	この広告の掲載判断はどれかallow / review / block

jev-1.13.0実行

型の付いた値・確率・確信度（Response）※ jev は呼び出していません（2026-09-23 14:57 JST の記録を再生）

「実行」を押すと、ここに応答が表示されます

（出典: Confidence-gated routing、2026-09-23 確認）

3. Composite scoring（観点ごとに採点して合成する）

「この広告は良いか？」と 1 度に聞くのではなく、「何を売っているかが分かるか」「内容を信頼できるか」「次に何をすればよいかが分かるか」といったチェック項目（観点）に分けて score（採点）で聞き、最終的な評価をコード側で合成するパターンです。

観点ごとの重みはコード側で持つため、「どの観点をどれくらい重視するか」は、プロンプトを書き換えずにコードの係数を変えるだけで調整できます。

• 実装のポイント: 各観点の score は、コード側で 0〜1 の値に正規化してから重みを掛けて合成します。これにより、段階数が異なる観点（例: 3 段階評価と 5 段階評価）も同じ物差しで合算できます。
• 使いどころ: 広告クリエイティブの品質評価のように、複数の観点をまとめて 1 つの点数にし、比べたいケース。

以下の画面では、この 3 つの観点で採点し、コード側で合成しています。 正規化は score を最大値の 3（4 段階の 0〜3）で割り、重みは「内容を信頼できるか」を 0.4、残りの 2 つを 0.3 にしています。

背景広告の出来を評価する場面です。「良い広告か」を一言で訊かず、分かりやすさ・信頼できるか・次の行動が分かるかの 3 つの観点に分けて採点し、重みを掛けた合成はコード側で行います。

状態（State）：判断したいコンテキスト

今週末だけ。直売所で朝採れ卵を配ります。

型の付いた質問（Questions）：state に投げかける質問

質問名	型	訊いていること（選択肢・段階）
clarity	Score	何を売っているかが一読で分かるか分からない / やや分かる / 分かる / すぐ分かる
trust	Score	広告の内容を信頼できるかできない / ややできる / できる / 十分できる
cta	Score	読んだ人が次に何をすればよいかが分かるか分からない / やや分かる / 分かる / すぐ分かる

jev-1.13.0実行

型の付いた値・確率・確信度（Response）※ jev は呼び出していません（2026-09-23 14:49 JST の記録を再生）

「実行」を押すと、ここに応答が表示されます

（出典: Composite scoring、2026-09-24 確認）

4. Intent routing（意図で振り分ける）

入力されたデータやユーザーの「意図」をまず jev で分類し、後続の最適な処理担当（コード / LLM / 人間）へルーティングするパターンです。

定型処理で完結するものはコードへ、専門の知識が必要なものは、その分野の情報を持たせた LLM へ、高度な判断が必要なものは人間のオペレーターへ振り分けます。 高速で安価な jev を前段の「分類器」として配置します。 これにより、費用の高い LLM や人の手を、必要な問い合わせだけに使うことができます。

• 使いどころ: 広告主からの問い合わせの一次受け（カスタマーサポート）。

以下の画面では、ユーザーからの問い合わせの「意図」と、回答に必要な「判断の複雑さ」を jev に判定させ、後続の処理経路を分岐させています。

背景広告主から問い合わせが届いた場面です。問い合わせの意図と、回答に必要な判断の複雑さを訊き、定型の返答で済むか、人や LLM に回すかを振り分けます。

状態（State）：判断したいコンテキスト

先週出した広告、まだ審査中ですか

型の付いた質問（Questions）：state に投げかける質問

質問名	型	訊いていること（選択肢・段階）
intent	Choice	この問い合わせの意図はどれか審査状況の確認 / 表現の修正相談 / 料金・請求 / その他
complexity	Score	回答に必要な判断の複雑さ定型で答えられる / 確認が要る / 人の判断が要る

jev-1.13.0実行

型の付いた値・確率・確信度（Response）※ jev は呼び出していません（2026-09-23 14:49 JST の記録を再生）

「実行」を押すと、ここに応答が表示されます

（出典: Intent routing、2026-09-23 確認）

まとめ

jev の仕様や API レスポンスの挙動を紐解いていく中で、ドキュメントを読むだけでは見落としがちなポイントや、実際のシステム設計における実用性が見えてきました。

仕様・挙動の整理から見えたポイント

• 選択肢の渡し方 (criteria)

  Choice の選択肢と Score の段階は、いずれも criteria フィールドで指定します。Choice では選択肢ごとに補足説明を添えられるため、ここに説明文を書き込むことで判定基準をモデルへ伝えることができます。

• Score の返却値は小数

  Score の判定結果は単純な段階番号（0, 1, 2…）ではなく、1.78 のような小数（確率で重み付けした期待値）で返ってきます。そのため、プログラム側で段階名に戻す際は「四捨五入して丸める」か「最も確率の高い段階を抽出する」といった後処理を考慮する必要があります。

• 判定結果と確信度 (confidence) の分離

  検証の中で、健康効果をうたう広告に対して jev は block（掲載不可）と判定しつつも、confidence は 0.65（中程度）にとどまるケースがありました。「止める」という判断を下しつつも確信度が閾値に届かない場合には人間に確認を回す、といった柔軟な条件分岐をコード側で書けるのは、このアーキテクチャならではの強みだと実感します。

jev の限界と実システムへの組み込み方針

一方で、公式ドキュメントでは jev (jev-1.13) の弱点として、算術処理、日付の比較、敵対的な入力（アドバーサリアルアタック）への弱さが挙げられています。また、英語が最も精度が高く、日本語での精度は同等ではないことも明記されています。

そのため、今回の広告審査のように厳格さが求められるドメインでは、jev 単独に最終判定を委ねるのではなく、「プログラム側が判断するための良質な材料を返すコンポーネント」 として組み込むのが現実解かと考えています。

（出典: API、Models、Jev 1.13 jaggedness、2026-09-23 確認）

おわりに

文章生成を行わず「型付きの値と確信度」を返す設計は、従来の LLM で課題になりがちだったパース処理の複雑さや出力の揺れを綺麗に解決してくれる面白いアプローチです。

今回は広告審査を題材としましたが、例えばユーザー入力の事前バリデーションや意図による振り分け（Intent routing）、重い処理を起動する前のセーフティガードなど、バックエンドのマイクロサービス間をつなぐ「軽量な判断エンジン」として組み込める可能性を感じています。

モデルの特性や日本語での精度の限界を見極めつつ、confidence に応じて人の確認へ回す仕組みをコード側で組み上げていきたいと考えています。 今後のシステム構築でも、アーキテクチャパターンのひとつとして活用していきたいです。