Shuichiro Ogawa
English

ノート · updated 2026-09-21

Jev をどう使うか、どこで使わないか

TypeSafe AI の Jev は、判断を型づけられた質問に書き下せた範囲でしか働かない。公開から 6 日の時点でベストプラクティスと呼べる合意はまだなく、本ノートは公式が逐語で条件を添えたものと、追試できる形で公開された実装だけを採り、方法論のない優位主張と出所を確認できない報告は落とした。

目次（12）
  1. ベストプラクティスはまだない
  2. 質問を書くところで詰まる
  3. 公式が適用先を 10 種に絞っている
  4. criteria の書き方に作法が集中している
  5. 閾値は出発点だけが与えられている
  6. 何を採り、何を落としたか
  7. 効いているのは 6 つのパターン
  8. 実装が公開されている 4 つの事例
  9. 選ぶかどうかは、基準を先に書けるかで決まる
  10. 避けるべき型
  11. 本番に入れるときに外から課されるもの
  12. 信頼度の読み方

ベストプラクティスはまだない

Jev が公開されたのは 2026-09-15 で、本ノートの取得日はその 6 日後である。 この 6 日のあいだに、Jev を名指しした analyst レポートは 1 件も出ていない。 Gartner、IDC、Forrester、McKinsey、BCG、Deloitte のいずれにも言及がない。 公的機関と標準化団体の資料も同じで、名指しは 0 件だった。

独立した実装の記録は数件ある。 ただし標本は 60 件、50 件、12 件という規模で、著者自身が射程を限定しているものが多い。 業界の合意としての作法は、まだ形になっていない。

合意がない以上、ここに置けるものは 2 種類しかない。 公式が逐語で指示したものと、実装が公開されていて追試できるものである。

質問を書くところで詰まる

Jev を呼ぶコードは短い。 状態と質問を渡し、型づけられた答えを受け取るだけで、API は 1 本しかない。

詰まるのは手前である。 公式のエージェント向けドキュメントに、こう書いてある。 「Agents aren’t great at writing questions, so expect to edit collaboratively with them」。 コーディングエージェントに書かせても質問はうまく書けないので、一緒に直す前提で進めろ、という指示である。

実装記事の側も同じところで止まっている。 「来月以降の自動更新を停止してください」という日本語で解約意図の判定が揺れた例で、著者は原因をモデルの誤りではなく「質問や候補の曖昧さ」と結論づけた。

公式が適用先を 10 種に絞っている

docs の use case map は、当てる先を次の型に限っている。

  • Classification：「One known category should win」
  • Detection：「You need a probability that one property is present」
  • Scoring：「The answer belongs on an ordered rubric」
  • Routing：入力を処理先に振り分ける
  • Search / Retrieval / Ranking：候補の絞り込みと並べ替え
  • Verification：他のモデルの出力を点検する
  • ML Feature Extraction / Structured Data Extraction：判断を特徴量や構造化フィールドに落とす

外しているものも明示されている。 多段分析を要する拡張推論、相互に絡み合う多数の要因を 1 つの質問で扱うこと、そして自由記述の生成である。 生成については「Jev deliberately avoids this paradigm」と書かれている。

ローンチ記事の側の列挙も同じ範囲に収まる。 AI ワークフロー、条件分岐、大規模データへの map-reduce、レイテンシが効く実時間処理、そして LLM 出力の検証とガードレールである。

criteria の書き方に作法が集中している

質問の型は 3 つで、それぞれに公式の指示がある。

Choice は候補を省略しない。 「Give the model the full list of teams, categories, or products rather than a shortlist」。 候補は 255 まで置ける。 return_policy と return_status のように紛らわしい対は、what と not_for と examples のフィールドで書き分ける。

Score は度合いではなく状況を書く。 「Describe situations, not degrees」。 「moderately severe」ではなく「Broken or degraded feature, but workaround exists」と書け、という指示である。 理由も書かれている。 「Every level is evaluated separately… ‘worse than the previous level’ means nothing to it」。 各段階は独立に採点されるので、前の段階との相対で書いた記述は意味を持たない。 1 つの Score 質問に 1 つの次元だけを置き、段階は識別して書ける分だけ、最大 10 まで使う。

Noul は 1 問につき 1 つの真偽だけを問う。 高い値が yes になるように書き、「Is the message free of personal data?」のような否定形を避ける。 境界が曖昧なら true と false の両方の記述を criteria に置く。

3 つに共通するのは、最後に同じ指示が付くことである。 自分のデータで試して調整しろ、と書かれている。

候補の設計で落ちる穴も報告されている。 対応外の入力を受けたときに返す「該当なし」の候補を置かないと、既存の候補のどれかに寄せられる。 候補以外を生成しないことと、正しく判断することは別である。

閾値は出発点だけが与えられている

confidence は Choice と Score にしか付かない。 公式の定義では、答えがすでに与えている確率分布の形から計算される統計量である。

運用の出発点は docs に数字で書かれている。 confidence が 0.6 未満なら人に回し、0.6 から 0.85 なら利用者に確認を取り、0.85 を超えたら自動実行してよい、という 3 段である。 分類の粒度を切り替える例では 0.9 が使われ、意図判定の例では 0.5 未満を人へのエスカレーションに割り当てている。

ただし同じページが閾値を拘束していない。 「Start with conservative thresholds, test with your own data, and adjust as you observe results」。 confidence そのものも「convenient measure」と呼ばれており、別の指標のほうが合うなら乗り換えてよいと書かれている。

閾値をどこにでも付ける設計は、公式のほうが止めている。 最良の候補を選ぶだけの場面では閾値を使わず、単に最高 confidence を採る。 閾値は特定の統計的アルゴリズムのために取っておく、という書き方になっている。 質問と閾値の定数は一箇所に集め、人がレビューできる形にすることも求められている。

実運用側の自己流も公開されている。 0.05 未満を足切りし（ただし最低 1 件は残す）、0.8 以上なら単一候補に寄せ、0.5 未満は判断が割れているとみなす、という運用である。 60 件の手ラベルで操作リスクを判定したベンチでは、confidence が 1.000 だった 40 件がすべて正解で、誤答はすべて 1.000 未満だった。 同じベンチで、曖昧なケースだけを取ると正解率は 71.4% に落ちている。

何を採り、何を落としたか

以下に並べる配線は、次の 4 条件で選んだ。

  • 公式が理由か成立条件を逐語で添えているか：「推奨」とだけ書かれた項目は採らない。ファンアウトを採ったのは、公式が「Speculative questions only provide value when the overhead of including them is negligible compared to savings from avoiding follow-up requests」と条件を書いているからである。
  • 数値に方法論が付いているか：モデルのバージョン、質問数、状態のサイズ、比較対象のいずれかが欠けた数値は本文に置かない。バッチングの 12.2 倍を採れたのは、jev-1.12、13 問、54,000 字、比較対象は逐次送信、と全部書いてあったからである。
  • 追試できる形で公開されているか：コード、ベンチの手順、課金の実測のいずれかが公開されている実装だけを事例にした。
  • 同じ資料の中で失敗と限界が報告されているか：うまくいった話だけで閉じている記録は、単独では採らない。

落としたものも書いておく。

  • 「193.6x faster」「444.6x cheaper」「mathematically cannot hallucinate」：比較対象と測定条件が開示されていない。書き手自身が “potentially inflated” と留保している数値もある。コーパス側で marketing-claim として分離し、本文には置いていない。
  • ルーティングとカスケードのコスト削減率：85% 超や最大 98% という数字はあるが、出所は学術論文である。産業側に方法論つきの資料は 1 件もなかったので、実務の選定基準としては使えない。
  • 著者の権威を確認できなかった実装リポジトリ：ルーター実装を名乗るリポジトリは 1 つが 404 で、もう 1 つは運営組織の背景を確認できなかった。実行記録を伴わない概念まとめの gist も同じ理由で外した。
  • 自社ブログの「50〜90% のコスト削減」：ガードレールや評価ツールの販売元による自己申告で、標本も期間も書かれていない。事実と販促を分離できないため除外した。

効いているのは 6 つのパターン

公式と独立実装の双方で繰り返し出てくる配線は、次の形に整理できる。

投機的なファンアウト。 関係しうる質問を分岐の前に全部入れて 1 回で送り、コード側で必要な答えだけを読む。 質問は並列に評価されるので、足してもレイテンシはほとんど動かない。 公式は条件も付けている。 「Speculative questions only provide value when the overhead of including them is negligible compared to savings from avoiding follow-up requests」。

バッチング。 同じ状態に複数の質問を束ねる。 公式の cookbook は 12.2 倍安く 10.0 倍速いという数字を、方法論つきで出している。 jev-1.12、13 問（Noul 8、Choice 2、Score 3）、5 回反復、GDPR の Wikipedia 記事 約 54,000 字を状態に使った比較である。 比較対象は逐次送信なので、並行に単発で投げる設計と比べれば速度の差は縮む。

confidence によるルーティング。 「The answer tells you what; confidence tells you whether to act」。 何を、は答えが決め、実行してよいかどうかは confidence が決める、という 2 軸の使い方である。

複合スコアリング。 複雑な判断を独立した次元の Score に割り、正規化して重みを掛け、合算はコード側で行う。 重みが外に出ているので、結果が期待と違ったときに再調整できる。

カスケード。 安い側で先に処理し、Jev がフィールド単位で検証し、フラグが閾値を超えたときだけ高い推論モデルを呼ぶ。 公式の cookbook では、抽出に gpt-5.4-mini、検証に jev-1.12、再実行に gpt-5.5 を置き、any_flag の閾値を 0.7 にしている。 ここで書かれている設計理由が効いている。 「we do not use structured outputs, tool calls, or json mode, because: a schema following mistake is not the mistake we expect an LLM to make」。 LLM がやると見込んでいる失敗はスキーマ違反ではないので、スキーマを守らせる仕組みは検証にならない、という切り分けである。

入出力の両側でのガードレール。 「Run this TypeSafe check both on LLM inputs, and on LLM outputs, because even ordinary-looking prompts can lead to harmful generated replies」。 入力だけを見ても足りない、という理由が添えられている。

実装が公開されている 4 つの事例

評価の置き換え。 Langfuse は、LLM 出力に対する不満の検出を Noul 1 問で回した。 Claude Fable 5.1 の判定と 91.5% 一致し、100 万件あたり 160 ドルである。 同じ比較で Claude Fable 5.1 は 33,000 ドル、GPT-5.6 Luna は 400 ドル、DeepSeek V4.1 Flash は 260 ドルで 93.5% 一致だった。 閾値は 0.7 で運用し、tool loop で同じ利用者発話が続く生成は 1 ターンに畳み込んでいる。 同じ記事が限界も 2 つ書いている。 文脈が伸びると精度が落ちること（“Jev suffers from context rot”）と、棄権できないことである。 「It cannot abstain. A forced binary with no unknown or needs_review option makes Jev pick the least wrong answer」。

エージェントの関数選別。 typia のメンテナは、数百に及びうる controller 関数からターンごとに必要なものだけを選ぶ用途に当てた。 単発の Choice を使っていない。 「One turn may need several functions, and choice picks exactly one」。 1 ターンに複数の関数が要りうるので、候補ごとに独立した Noul を並べる形にしている。 関数が多すぎる場合は、グループを選んでから個別を選ぶ 2 段構成で、1 ターンあたり最大 2 リクエストに抑える。 同じ作者が実装上の失敗も残している。 独自の fetch クライアントと SDK ラッパーと条件付き型で約 550 行、テスト 1,000 行まで膨らんだあと、boolean から noul への変換 1 本に削り直した。 「The package’s whole reason to exist is one conversion」。

エージェントの操作リスク判定。 読み取り専用、破壊的、特権、持ち出しの 4 分類で 60 件を判定したベンチでは、正解率 91.7%、p50 421.6ms、p95 542.0ms、1 コール 約 $0.0000173 だった。 著者自身が、フロンティアモデルとの比較列は API キーがなく実施していないと書いている。

規則の一括点検。 Markdown で書いた 370 ルールを差分に対してバッチで走らせ、2 秒未満で完了した実装がある。 そこで実際に起きたのは max_tokens_exceeded で、原因はルール数ではなく差分の大きさだった。

選ぶかどうかは、基準を先に書けるかで決まる

汎用モデルの構造化出力と比べたときの差は、2 つの記事が同じ方向を指している。 型が合っていることと判断が正しいことは別だが、Jev の側には確率が付く。 天気の例では「単位が指定されているか」を 0.02 として返し、汎用モデル側では値を補ったのか指定されていたのかを区別できなかった。 分類の選択肢に無い値が出てくる問題と、1 回の推論に数十秒かかる問題を避けるために採用した、という動機も書かれている。

小型の分類器やルールベースと直接比べた実測は、今回の探索では見つからなかった。 埋め込みによる検索との比較は 1 例だけある。 typia の設計判断で、追加の LLM 呼び出しと、インデックスの維持が要りマルチインテントに弱い埋め込み検索を退けて Jev を採った、という記述である。

産業データの側は、選定の軸を 1 つだけ与える。 固定の性能水準に達するための推論価格の下落率は、ベンチマークによって年 9 倍から 900 倍まで開く。 タスクカテゴリ別の実利用でも、コストは 1 件あたり $0.036 から $34.965 まで約 1,000 倍の幅がある。 つまり安さは一律ではなく、どのタスクに当てるかで決まる。

このブログが使ってきた基準を当てると、判断は単価ではなく 1 タスク完了あたりのコストで下りる。 Jev の単価が 2 桁安いことは、誤った合格判定の手戻りが小さい作業でしか効かない。

引き合う条件は、公式と独立実装の双方から同じ形で出てくる。 基準を文章として先に書き切れること、判断が 1 つの次元に分解できること、誤りの手戻りが小さいこと、そして量が多いことである。

避けるべき型

公式が自分で並べているものと、実装記録から出たものを、1 つの表に集める。

  • 算術とカウントを任せる：「Jev is not a calculator」。コード側で計算する。
  • 日付の順序や期間を任せる：「Jev reads dates as text, not as ordered quantities」。Choice で構成要素を抽出し、演算はコードで行う。
  • 多段の推論を 1 問に詰める：hop を減らし、関連する状態を直接渡す。
  • 生成をさせる：Choice を連鎖させて文章を作る配線は「slow and ineffective」とされている。
  • 無関係な内容で状態を膨らませる：「Include only the context relevant to the current questions」。文脈が伸びると精度が落ちる挙動は独立実装でも報告されている。
  • 棄権の選択肢を置かない：unknown や needs_review が無い二択は、最もましな誤答を選ばせる。
  • 該当なしの候補を置かない：対応外の入力が既存の候補に寄せられる。
  • 質問どうしの算術的な整合を期待する：「P(noul) ≠ 1 - P(not_noul)」。
  • あらゆるルーティングに閾値を付ける：最良を選ぶだけなら最高 confidence を採る。
  • 統合コードを厚く書く：独自クライアントとラッパーを自作すると、変換 1 本で済む責務が数百行に膨らむ。
  • 出力が無料だから安いと見積もる：入力トークンは課金される。短い日本語文 48 回で 約 $0.0015 という実測がある。

本番に入れるときに外から課されるもの

Jev を名指しした公的資料は、今回の探索でも 0 件だった。 当てはめはすべて推論になるが、自動判断を業務に組み込む側の規範は既にある。

EU AI 法 Art 14(4) は、監督する人が出力を無視し、上書きし、覆すと決定できること、そして介入して止められることを求める。 Art 13(3)(b) は、精度指標と既知のリスクと監督措置を使用説明書に載せることを求め、Art 15 は精度指標の宣言そのものを義務にしている。 Art 26 は導入者にログの最低 6 か月保持と、対象者への告知を課す。

閾値の扱いにも対応する規範がある。 NIST AI 600-1 の GV-1.3-002 は、性能と保証基準の最低しきい値を定め、展開の可否判断の手続きの一部として審査することを求める。 同じ文書が、確信を持って誤った内容を提示する挙動を consequential decision making に組み込む場面では特に監視が要る、と書いている。

人に不利な決定を下す場合は、通知と異議申立の経路が要る。 OMB M-24-10 は、不利な影響を受けた個人への通知と不服申立権の情報提供、人による再検討と救済の経路、そして実行可能な範囲で人による代替への切替を求める。 カリフォルニアの ADMT 規則は、決定を覆す権限を持つ人間レビュアーへの申立方法を用意すればオプトアウト義務を免れるとし、そのレビュアーが出力を解釈できることを要件にしている。

禁止の側もある。 EU AI 法 Art 5(1)(d) は、プロファイリングのみに基づく犯罪リスク予測を禁じる。 Annex III の 8 分野に当たる用途は、プロファイリングを伴う限り軽量な除外を使えない。

信頼度の読み方

本ノートは 3 つのティアを混ぜていない。

  • T1v ベンダー一次情報：docs.typesafe.ai の patterns と primitives と cookbooks、ローンチ記事、Vercel と Netlify の公式ドキュメント。使い方と制約の一次権威として扱う。同じ資料内の「40x-200x faster」「444.6x cheaper」「mathematically cannot hallucinate」「up-and-left of every single model」はコーパス側で marketing-claim として分離した。
  • T2 公的機関と調査：Jev を名指しした analyst レポートは公開 6 日の時点で 0 件なので、隣接カテゴリの事実だけを置いた。ルーティングとカスケードのコスト効果を方法論つきで示す産業資料は 0 件で、該当する数字は学術論文の側にしかない。
  • T3 個人の私見と独立実装：typia のメンテナと Langfuse のエンジニアは権威を確認できた。dev.to と Qiita と Zenn の実装記事は、実名と実績はあるが外部から検証できる経歴が未確認なので、権威確度を medium 以下として扱い、単一の記録として読む。

一致しているのは、速度とコストの桁、そして質問設計が成否を決めるという点である。 割れているのは曖昧なケースの精度で、境界の近くでは独立実装のほうが低い数字を出す。

関連ノート: TypeSafe AI の Jev は何を保証し、何を保証しないか、判断が関数呼び出しになったとき、デザインの何が動くか、フロンティアモデルと廉価モデルの使い分け（Fable 5 と GPT-5.6 Sol）、LLM-as-a-Judge の最新潮流：中核研究53件の文献地図と創造性評価の独立章、エージェンティックコーディング：オーケストレーションパターンの現在地（2026）。

未検証事項

  • 要一次検証 https://typesafe.ai/pricing は 404。価格はローンチ記事の記述で代替確認した。
  • 要一次検証 公式 Python SDK の README に直接到達していない。
  • 要一次検証 docs の cookbook 群 14 本（consistency_noul、rerank、semantic_find、function_calling ほか）は存在のみ確認で未取得。使い方の追加事例を含む可能性が高い。
  • 要一次検証 docs の各ページの最終更新日。付いているのは model-jaggedness（2026-09-17）だけで、他は取得日時点の内容として記録した。
  • 要一次検証 バッチングの 12.2 倍と 10.0 倍は jev-1.12 での自社計測であり、比較対象は逐次送信である。並行単発との比較ではない。
  • 要一次検証 confidence=1.000 の 40 件が全て正解という結果は、標本 60 件の単一ベンチであり、著者の経歴も外部から確認できていない。
  • 要一次検証 Langfuse の一致率とコストは、自社 eval 製品の文脈で公表された数字である。
  • 要一次検証 EU AI 法の条文は転載サイト経由での確認で、EUR-Lex 原文との逐語照合をしていない。コロラド州法の原文は 403、CPPA の規則 PDF と AI 事業者ガイドラインの PDF はテキスト抽出ができなかった。
  • 要一次検証 Gartner のプレスリリースと Tokenomics Model の原文書は 403 またはサブスク限定で、単位が記事内で揺れている。
  • 要確認 ルーティングとカスケードのコスト削減効果を方法論つきで示す産業側の資料は 0 件だった。該当する数値（RouteLLM の 85% 超、FrugalGPT の最大 98%）は学術文献の側にあり、本ノートの範囲では採っていない。
  • 要確認 小型分類器およびルールベースと Jev を直接比較した実測は見つからなかった。

参照文献

すべて 2026-09-21 にアクセス。仕様と精度の一次出典は TypeSafe AI の Jev は何を保証し、何を保証しないか に完全な形で載せてある。

ベンダー一次情報（T1v）

公的機関と調査（T2）

独立実装と個人の私見（T3）

書いた人：小川 修一郎（Design Researcher / Consultant） 経歴を見る →