System One をめぐる競争
Jev vs OpenAI Decisions API
OpenAI の Decisions API は、Jev が広めた高速な限定選択型の意思決定領域に加わりました。どちらもコードが処理できる答えを選ぶためのものですが、違いは質問の定義方法、確信度の意味、受け付けるコンテキストにあります。
公開報道では、Decisions API は GPT-6 Luna を基盤とする限定 preview サービスとして説明されています。OpenAI が preview ドキュメントを公開するにつれて詳細は変わる可能性があります。このページでは報道された内容と現在の Jev API 契約を分けて説明します。
提供状況のお知らせ
OpenAI Decisions API はまだ一般公開されていません
この機能はまだ一般利用できません。ここで意思決定ワークフローを確認できますが、現時点では公開 OpenAI プラットフォームから API を呼び出すことはできません。
このカテゴリが生まれる理由
モデルの出力とアプリのアクションの間にある欠けたステップ
汎用モデルは可能性の説明が得意です。一方、ソフトウェアが許可するアクションをすでに把握していて、すぐに一つの分岐を選びたい場合は、意思決定モデルが役立ちます。
段落ではなく答えを返す
ルーターが必要とするのは billing、sales、support のいずれかであり、別のパーサーが読み直す段落ではありません。意思決定レイヤーはアクションの範囲を明確にし、応答を小さく保ちます。
境界を明示する
開発者が質問と有効な答えを定義します。これにより下流のコードを型付け、記録、テストしやすくなり、ポリシー外の結果を拒否できます。
制御ループを高速に保つ
Agent は強いモデルで計画を立て、ルーティング、許可、エスカレーション、次のツール選択のような小さな判断を低レイテンシーの意思決定モデルに渡せます。
概要
同じ目的:コードが使える意思決定
2 つの API は近い領域にありますが、約束しているものは異なります。preview の情報を明記しながら、現在公開されている内容を整理します。
エンジン
専用の非対話型意思決定モデル。
DevDay の報道によれば、GPT-6 Luna の専用バージョン。
主な役割
アプリケーションコードが処理できる、限定的な分類、スコア、Yes/No 判断を行う。
開発者が定義した答えから、分類、ルーティング、Agent の次のステップを素早く一つ選ぶ。
入力
テキスト状態:文字列、JSON オブジェクト、テキスト配列。
テキストまたは画像のコンテキスト。
答えの範囲
Choice は最大 255 個の選択肢に対応し、Score と Noul で別の一般的な形を表現できる。
有限個の事前定義された答え。preview 報道では公開上限は明らかにされていない。
質問の契約
Noul、Choice、Score の質問。複数の名前付き質問を並列実行できる。
有限の事前定義された答えを伴う質問。完全な公開リクエスト Schema はまだ発展中。
出力
質問タイプに紐づいた型付き答え、確率、確信度シグナル。
選択された答えと確信度スコア。
確信度
Jev は意思決定結果に対して校正された確率と確信度シグナルを説明している。
現在の報道ではモデルが生成するスコアとされ、独立した校正の詳細はまだ公開されていない。
速度
低レイテンシーの反復判断向け。ベンチマークはワークロードと比較対象に依存する。
報道では 150 ms の応答と、通常の GPT-6 Luna より約 10 倍の速度が示されている。
料金
現在の Jev 資料では従量制が説明されている。実運用ではプランとワークロードを確認する必要がある。
限定 preview の報道時点では料金は公開されていない。
提供状況
公開 API と Playground。
DevDay 2026 の報道時点では招待制の限定 preview。
上記の Decisions API の数値は DevDay 2026 前後の preview 期の報道に基づきます。普遍的な性能保証ではなく、自分の評価計画の出発点として扱ってください。
1 つのルーティング課題、2 つの契約
質問の形が重要になる
どちらのシステムでも請求チケットをルーティングできます。Jev は質問タイプを API 契約の一部にし、Decisions API は公開説明上、コンテキストと限定された答えの集合を使います。
Jev:名前付きの型付き質問
Choice で担当チームを選び、Noul で人による確認が必要かを尋ねます。
{
"model": "jev-latest",
"state": "I was charged twice and need a refund.",
"questions": {
"team": {
"type": "choice",
"instructions": "Which team should handle this?",
"criteria": {
"billing": "Payments and refunds",
"technical": "Product issues",
"other": "None of the above"
}
},
"needs_review": {
"type": "noul",
"instructions": "Does this need human review?"
}
}
}Decisions API:コンテキスト + 許可された答え
公開説明をもとにした概念的な形であり、保証された SDK リクエスト形式ではありません。
{
"context": "I was charged twice and need a refund.",
"question": "Which team should handle this?",
"answers": ["billing", "technical", "other"]
}参照した報道は完全で安定したリクエスト Schema を公開していない preview 製品を扱っているため、Decisions API の例は意図的に概念的なものにしています。
実用的な Agent パターン
意思決定モデルは高速なゲートであり、Agent 全体ではない
有効な構成はモデル同士を競わせることではありません。オープンな推論がタスクを整理し、意思決定モデルが限定された分岐を処理し、最終的な実行許可をコードが持つという役割分担です。
01
タスクを整理する
LLM や Agent でオープンな依頼を理解し、必要なツールを集め、コンパクトな意思決定コンテキストに変換します。
02
必要な状態だけを渡す
会話全体やツールの履歴を再生するのではなく、次の判断に必要なテキストまたは画像のコンテキストだけを渡します。
03
限定された質問をする
ルート、許可、ブロック、スコア、次のアクションなどの許可された結果を定義し、コードが期待する分岐を返してもらいます。
04
アクションを強制する
予約、支払い、送信、データ変更の前に、閾値、権限、レート制限、人の承認を決定論的なコードで適用します。
このパターンはツール選択にも使えます。オーケストレーターが Agent の目的を決め、高速な意思決定呼び出しが次の限定された動きを選びます。
どちらがいつ適しているか
限定された判断には Jev
繰り返し発生する明確な判断、1 回のリクエストで複数の質問タイプ、出力契約の一部としての確率シグナルが必要な場合に向いています。
Decisions API を検討する場面
テキストまたは画像のコンテキストが必要で、OpenAI のエコシステムに留まりたい場合。ただし契約が成熟するまで preview の提供状況を受け入れる必要があります。
2 つのモデルを組み合わせる
汎用モデルに情報の説明や変換を任せ、その後に意思決定モデルでルーティング、許可、スコア、エスカレーションなどの狭いゲートを処理します。
確信度スコアを安全の保証とみなさないでください。ラベル付きの実例で評価し、誤りのコストに応じて閾値を設定し、重大なアクションには決定論的なポリシー検査や人の確認を残してください。
本番前に
意思決定がアクションを起こす前にテストすること
高速な答えは境界を測定できて初めて役立ちます。モデル呼び出しは小さく保ちつつ、評価とポリシーのレイヤーを明示してください。
ラベル付きデータセットを作る
きれいなデモ prompt だけでなく、実例でルーティング精度、誤許可、誤エスカレーション、保留を測定します。
スコアを検証する
確信度の数字は自動的に校正された確率になるわけではありません。業務の閾値に対応させる前に、スコア帯と実際の結果を比較します。
敵対的な入力を試す
数値、日付、曖昧な指示、prompt injection、壊れた state、誤った分岐へ自信を持って誘導する入力をテストします。
安全なフォールバックを残す
不確実または影響の大きいケースでは一時停止して人の確認を求めるか、汎用ワークフローへ戻し、無理に選択させないようにします。