Decision API 決定API Jevに乗り遅れるな

問い合わせを担当部署へ振り分ける。検索結果から、回答の根拠になる文章を選ぶ。AIエージェントが、処理を続けるか、人へ引き継ぐかを決める。

こうした場面で、アプリケーションが欲しいのは、選択肢と、それを選んでよいと判断するための情報だ。自然言語を理解してほしい場面は多い。そのすべてで、自然言語の回答まで生成する必要があるわけではない。

この需要に正面から向き合うのが、判断に特化したDecision API、そしてTypeSafe AIのモデル「Jev」だ。状態と質問を渡すと、コードで扱える型付きの回答や確率が返る。AIの能力を、小さな判断としてソフトウェアの内部へ組み込むためのインターフェースである。1

注目したいのは、判断を呼び出す費用と待ち時間が下がることで、アプリケーションの設計をどこまで変えられるかだ。

判断をAPIで呼び出す動きが広がっている

Jevの登場後、この領域では複数の企業が製品を公開している。

2026年9月15日　TypeSafe AI
Jevを公開。System One Modelと呼ぶ判断モデル。2

2026年10月1日　Cloudflare
判断モデルClefとClef-flashを公開。JevのAPIとの互換性を掲げる。3

2026年10月6日　OpenAI
Decisions APIをベータ公開。対応モデルはgpt-6-luna。4

2026年10月9日　Microsoft
Microsoft-Decision-1を発表。Microsoft Foundryなどで提供。5

OpenAIはその後、10月22日にDecisions APIの一般提供を開始した。4

本稿では、判断を返すAPIという用途を指して「Decision API」と呼ぶ。具体的なAPIの形式や対応モデルは提供元によって異なり、Jevはその中の一つのモデルだ。

この動きを見ると、AIアプリケーションの競争を、チャットや文章生成の性能だけで捉えるのは狭いと感じる。処理の途中で何度も呼び出される「判断」も、独立した製品として最適化され始めている。

Jevには、状態と判断基準を渡す

Jevの入力は、大きく分けて三つある。

• model：利用するモデル。

• state：判断の対象となる文章や構造化データ。

• questions：何を判断してほしいか、その質問と回答の条件。

テキストに対する基本の質問型は、Choice、Score、Noulの三つだ。6

Choice
尋ねること：用意した候補のうち、どれに当たるか
返るもの：選択肢、候補ごとの確率、confidence
利用例：問い合わせを技術・請求・その他へ分類する

Score
尋ねること：定義した評価段階のどこに位置するか
返るもの：スコア、段階ごとの確率、confidence
利用例：不具合の影響を、軽微・重大・致命的などの基準で評価する

Noul
尋ねること：ある条件が真であるか
返るもの：真であるとモデルが推定する確率
利用例：人間の担当者による対応を求めているかを判定する

たとえば、Noulが返す0.8は、質問した条件が真であるとモデルが推定する確率を表す。「緊急度が80点」という量の大きさを意味するわけではない。強さや程度を測りたいなら、その段階を定義したScoreを使う。7

この区別には実務上の意味がある。「顧客が怒っているか」と「どの程度の事業上の損失が発生しているか」を一つの曖昧な評価にすると、何を基準に対応したのかが分かりにくくなる。それぞれを別の質問にすれば、業務上の優先順位をコードで組み立てられる。

また、Choiceの候補には、必要に応じて「その他」や「判断材料が不足している」を用意できる。入力が既知の分類に収まらない場合を、回答空間の設計に含められる。6

速さを支えるのは、判断に合わせた出力の設計だ

TypeSafeは、Jevが自由文をトークンごとに生成する処理を行わず、複数の判断に必要な確率を並列に出力すると説明している。学習も、同社がRLCDと呼ぶ、判断と確率の較正を目的とした方式で行うという。2

同じ状態について「担当部署」「緊急性」「人への引き継ぎ希望」を知りたいなら、一つのリクエストにまとめられる。先に部署を聞き、その返答を待ち、続いて緊急性を聞く、という往復を減らせる。

さらに、後で使うかもしれない質問を先にまとめて評価し、不要だった結果をコードで使わない設計もできる。TypeSafeはこれをSpeculative fan-outとして紹介している。各質問は独立に評価されるため、ある回答を得てから追加のデータを取得する必要がある場合には、次のリクエストを組み立てる。8 6

ここで、Structured Outputsとの関係も整理しておきたい。既存のLLMにも、指定したJSON Schemaに沿って出力する機能はある。OpenAIの公式ガイドも、独自の構造を持つオブジェクトや説明文を生成する用途にはStructured Outputs、決まった形式の判断を得る用途にはDecisions APIという使い分けを示している。9

判断APIが魅力的なのは、回答空間の制約、確率の取得、複数質問の処理、費用や待ち時間を、一つの用途に合わせて設計している点だ。

100万回のリクエストを、費用から考える

Jevの公開価格は、入力100万トークン当たり0.042米ドル。出力トークンの料金は無料だ。TypeSafeのモデル資料とCloudflareの掲載価格で同じ単価を確認できる。10 11

状態、質問、選択肢の説明などを含めて、1リクエストの入力を2,000トークンと仮定すると、料金は次のようになる。

1万回：0.84米ドル
入力トークンの合計：2,000万

10万回：8.40米ドル
入力トークンの合計：2億

100万回：84.00米ドル
入力トークンの合計：20億

これは単価からの試算である。再試行、検索、データベース、他のモデル、人による確認などの費用は別に発生する。また、一つのリクエストに複数の質問を含められるため、リクエスト数と判断の数は一致しない。

外部の測定結果もある。2026年9月29日に公開されたボン大学などの研究者によるプレプリントでは、Jev 1.13.0を37データセットで評価し、主評価の346,009リクエストにかかったAPI費用を9.15米ドルと報告している。平均入力は630トークンで、32並列でのクライアント側平均応答時間は0.36秒だった。12

この数字から、大量の短い判断を試すための費用がかなり小さいことは読み取れる。対象データや通信経路が変われば結果も変わるので、実際のアプリケーションでは自分の処理単位で測定したい。

TypeSafeが掲げる「193.6倍高速」「444.6倍低コスト」という数字は、同社の特定ワークフロー評価によるものだ。比較条件や評価の選び方について、同社自身も留保を付けている。製品の採用判断には、自分のデータで得られる改善幅のほうが役に立つ。2

Jevという名前に含まれた、需要の見方

Jevという名前は、経済学者William Stanley Jevonsに由来する。TypeSafeは、知能の利用コストが下がることで、新しい用途が増えるという期待をこの名前に込めている。2

ジェヴォンズは『石炭問題』で、効率の改善が利用範囲を広げ、資源の総消費を増やし得ることを論じた。13

判断APIにも、この見方を当てはめられる。

たとえば、これまで一部の問い合わせだけを分類していたシステムで、全件に細かな属性を付けられるようになるかもしれない。生成された回答の一部を抜き取って点検していた仕組みで、各回答を複数の基準から評価する余地が生まれるかもしれない。

利用単価が下がると、「何回まで呼べるか」という予算上の制約が緩む。その結果、今まで人がまとめて行っていた判断や、実装自体を見送っていた判断を、処理の途中に置けるようになる。

もちろん、利用量の増加が必ず起こると決まっているわけではない。判断の価値が、その費用や誤りへの対応費用を上回る場面で、新しい需要が生まれる。ここに、Decision APIを単なる料金改定以上の変化として見る理由がある。

RAGとエージェントは、どこが変わるのか

RAGでは、検索した文章を判断してから渡す

RAGで考えてみよう。検索結果に関連語が多く含まれていても、その文章が質問への回答を支えているとは限らない。たとえば「アクセストークンの有効期限」と「署名鍵の有効期限」は、似た語を含んでいても、答えている問題が違う。

そこで、検索した文章と質問を組にして、「質問に関係するか」「回答に使える情報があるか」「質問の前提と矛盾するか」といった判断を加える。TypeSafeの公式Cookbookにも、このような処理を検索と回答生成の間に置く例がある。14

この設計では、検索が候補を集め、判断モデルが候補を評価し、コードが渡す資料を決め、LLMが回答を書く。

評価段階を分けると、検索で失敗したのか、資料の選び方で失敗したのか、回答生成で失敗したのかを調べやすくなる。判断の費用が低ければ、この段階を追加する採算も変わる。ただし、関連性の判定には誤りがあるので、資料の選択を変えた結果として、最終回答の品質が改善したかまで確かめる必要がある。

エージェントでは、進行中の小さな判断を分ける

エージェントにも、文章生成を必要としない判断がある。入力がどの処理に該当するか、得られた結果が次の処理に使えるか、追加の推論が必要か、利用者が人による対応を望んでいるか、といった判断だ。

これらを個別の質問にし、コードが処理の経路を選べる形にする。たとえば、定型処理の条件を満たした案件をそのまま扱い、説明文が必要な案件をLLMへ渡し、判断材料が不足した案件を確認へ回す。TypeSafeも、意図の判定から適切な処理へ振り分けるパターンを公開している。15

設計上の利点は、各段階の役割と評価対象が明確になることだ。モデルを変更するときにも、その判断に関する正解データを使って比較できる。処理全体の都合を、一つの長いプロンプトだけで調整する必要が減る。

リクエストを見ると、使い方が分かる

TypeSafeのHTTP APIでは、POST https://api.typesafe.ai/v1/systemoneへ状態と質問を送る。次は、問い合わせの担当部署と、人による対応の希望を尋ねるリクエスト本文の例だ。16

{
  "model": "jev-1.13.0",
  "state": {
    "message": "注文画面でエラーが出ます。担当の方に代わってください。"
  },
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "`message`に対応する窓口を選んでください。",
      "criteria": {
        "technical": "機能の不具合や操作中のエラー",
        "billing": "料金、請求、支払いについての問い合わせ",
        "other": "どちらにも当てはまらない問い合わせ"
      }
    },
    "wants_human": {
      "type": "noul",
      "instructions": "`message`は、人間の担当者による対応を明示的に求めていますか。"
    }
  }
}

応答のanswers.department.choiceには選択した窓口が入り、answers.wants_human.noulには質問に対する確率が入る。ここから先の振り分けはアプリケーションのコードで行う。

この例ではモデルをjev-1.13.0に固定した。安定版を指すjev-latestとプレビューのjev-previewは、どちらも10月14日公開の1.14.0を指す。評価した版を指定しておけば、モデル更新の影響を確認してから切り替えられる。10

確率を使って、自動処理の範囲を設計する

判断APIの価値を引き出すには、確率をどう処理へつなぐかまで設計したい。

たとえば、「この問い合わせは障害報告である」という確率について、見逃しを減らしたいなら、低めの値から確認対象へ回す考え方がある。一方、誤って処理を始める損失が大きい場合は、自動処理の条件を厳しくする。最適な境界は、誤判定の種類と、その結果生じる費用によって変わる。

ここで、ChoiceやScoreのconfidenceは、返された確率分布の集中度などを要約した統計量である。選択肢の確率や、実際の正答率とは区別して読む必要がある。Noulには独立したconfidenceフィールドがなく、返される確率から判断する。17

外部評価でも、しきい値の設定が結果を変えている。前述のプレプリントでは、契約条項を分類するUNFAIR-ToSにおいて、訓練・検証用の事例で質問ごとのしきい値を調整すると、micro-F1が0.499から0.748へ改善した。確率が返ることで、その使い方をアプリケーション側で調整できる。12

また、型安全であることは、指定した回答形式や候補を守る性質である。候補の中から正解を選ぶ能力は、別に評価しなければならない。外部研究では、選択肢の名前と説明の対応を意図的に衝突させると、型エラーがないまま判断が変わる現象も報告されている。18

まずは、次の指標を一緒に見ると、導入の効果を判断しやすい。

自動処理率
全案件のうち、追加確認なしで処理できる割合

自動処理した案件の誤り率
自動化した範囲の品質が許容水準を満たすか

見逃しと誤検知
業務上の損失が大きい誤りを増やしていないか

p50・p95の応答時間
典型的な待ち時間と、遅い側の待ち時間

総費用
API料金、追加モデル、人による確認などを合わせた費用

たとえば、自動処理率が80％あっても、その範囲の誤りが業務上の許容値を超えていれば、しきい値や質問の設計を変える必要がある。自動処理率を50％に下げることで、確認作業を十分に減らしながら品質を保てるなら、その構成には採用する価値がある。数字は説明のための例だが、こうした関係を自分のデータで測ることが重要になる。

日本語の業務へ導入する場合も、実際の文面で確認したい。TypeSafeは英語で最も精度が高いと説明し、他言語での性能が同等とはしていない。また、Jev 1.13には数値計算、日付比較、複雑な参照、敵対的な入力などの弱点を明記している。正確な計算や権限の確認はコードが担い、Jevには文面の意味に関する判断を受け持たせる構成が考えられる。10 19

Jevに乗り遅れないために、判断を一つ取り出す

最初の実験には、すでに人やLLMが行っていて、正解を確認できる判断が向いている。問い合わせの振り分け、検索結果の評価、処理結果の点検などから一つを選び、実データと正解をそろえる。

次に、既存の方法とJevを同じデータで比較する。質問やしきい値の調整に使うデータと、最終評価に使うデータは分けておく。最初は現在の処理と並行して判定だけを記録すれば、利用者への動作を変える前に、費用、待ち時間、誤りの傾向を確認できる。

そこで得られるものは、モデルの順位だけではない。どの判断なら安く繰り返せるか、どの境界では追加の推論が必要か、何をコードで確定すべきかという、自分のシステムについての理解だ。

その理解と評価データがあれば、後からJevの新しい版や、別のDecision APIを比較するときにも役立つ。

AIが出す文章の品質に加えて、ソフトウェアの途中に置く判断の質と量を設計する。その発想を試すための道具が、すでにそろい始めている。

Jevに乗り遅れたくないなら、まずは一つ、判断をAPIへ切り出してみる。その実験から、自分のアプリケーションで何が可能になるのかを確かめていきたい。

参考資料

1. TypeSafe, System One

2. TypeSafe, Introducing System One Models & Jev, 2026年9月15日

3. Cloudflare, Introducing Clef: our open-source decision models, and new RL fine-tuning platform, 2026年10月1日

4. OpenAI, API Changelog, 2026年10月6日・22日の項目

5. Microsoft, Introducing Microsoft-Decision-1, our model for fast decision-making, 2026年10月9日

6. TypeSafe, Primitives

7. TypeSafe, Noul

8. TypeSafe, Speculative fan-out

9. OpenAI, Decisions

10. TypeSafe, Models

11. Cloudflare, Jev

12. Deußer et al., Evaluating and Benchmarking the System One Model Jev, 2026年9月29日、プレプリント

13. W. S. Jevons, The Coal Question, Chapter VII, 1866年版

14. TypeSafe, Classifying RAG passages

15. TypeSafe, Intent routing

16. TypeSafe, Quick start

17. TypeSafe, Confidence

18. Sun et al., Type-Safe Is Not Error-Free: Typed Decision Models Follow the Option Name, Not the Definition Bound to It, 2026年10月8日改訂、プレプリント

19. TypeSafe, Jev 1.13 jaggedness