生成AIといえば「賢いLLMに考えさせて、文章を書かせる」使い方が中心でした。ところが2026年9月、その流れとは逆向きの製品が立て続けに登場します。9月15日にTypeSafe AIが公開したJEV（Jev）と、9月29日（米国時間）にOpenAIがDevDay 2026で発表したDecisions APIです。どちらも、あらかじめ用意した選択肢から「どれにするか」だけを高速に返します。SNSやメディアでは「Decisions APIはOpenAIによるJEVへの回答だ」という見方も出ていますが、それは本当に「同じもの」なのでしょうか。

• 0ms
  Decisions APIの処理時間（OpenAIの公称値。測定条件は未公開）
• 0ドル
  JEVの入力100万トークンあたりの料金（出力は無料）
• 0日
  JEVの公開からDecisions API発表までの日数

user@sinyblog:~/article ❯ 01_digest.mdOpenAIから「Decisions API」が登場（90秒ダイジェスト）

記事の主題「Decisions APIは“OpenAI版JEV”なのか？」に対する、2026年9月30日時点での答えはこうです。狙っている用途はほぼ同じ。しかし「同じもの」ではなく、しかも現時点では公平に比較できるだけの情報がそろっていません。

1. 用途は重なっている。どちらも「質問」と「答えの候補」を開発者が先に決め、AIには候補から選ばせるだけのAPIです。OpenAI自身が、用途をコンテンツ分類・リクエストの振り分け・エージェントの次の行動選択と説明しています^[1]。JEVの用途もほぼ同じです^[9]。
2. 作り方の思想が違う。Decisions APIは既存の小型LLM「GPT-6 Luna」を土台にしています（OpenAIの表現は「powered by GPT-6 Luna」^[2]）。JEVは、TypeSafe AIが「新しいモデルアーキテクチャ」と独自の学習法RLCDで作った、判断専用モデルです^[9]。
3. 公開されている情報量に大きな差がある。JEVはAPIの仕様・料金・レート制限・コンテキスト長まで公開されています。一方Decisions APIは、2026年9月30日時点で「limited preview（限定プレビュー）」の段階です。料金、リクエスト形式、確率（confidence）を返すかどうかは、どれも未発表です^[1][8]。
4. 入力の種類が違う。Decisions APIはテキストと画像を受け付けます^[1]。公式JEVは現在テキストのみです^[14]。
5. 速度の比較には決着がついていない。早期テストで両方を試した米メディアEveryでは、Decisions APIが速かったケースとJEVが速かったケースの両方が報告されています^[8]。

そして、このニュースで一番大事なのはどちらが勝つかではありません。「深く考える部分は高性能LLM、瞬間的な判断は判断専用モデル」という役割分担が、大手とスタートアップの両方から同時に製品化され始めたことです。この記事の後半（第12章）で、AIエージェントの設計がどう変わりうるかを解説します。

user@sinyblog:~/article ❯ 02_what_is_decision_ai.mdそもそも「判断AI」って何？

ChatGPTのような普通のLLM（大規模言語モデル）は、文章を1トークン（単語の断片）ずつ順番に書いていく仕組みです。たとえ「billing」と一言だけ答えればよい場面でも、内部では「文章を生成する」処理が動いています。

これに対して、今回の2製品が採っているのは「答えの候補を先に渡して、どれを選ぶかだけ返させる」という考え方です。文章は書かないので、次のような利点が期待できます。

1. 速い：長い文章を書く必要がないので、応答までの時間が短くなります。
2. 形が崩れない：答えは必ず候補のどれかになるので、プログラムの側でパース（文字列の解析）に失敗しません。
3. 確からしさを数字で扱える：JEVの場合は、各候補の確率を返します（Decisions APIが返すかどうかは未発表）。

TypeSafe AIはこの種のモデルを「System One model（システム1モデル）」と名付けました。名前の由来は、心理学者ダニエル・カーネマンの著書『ファスト&スロー』にある「システム1（速い直感的な思考）」と「システム2（遅い熟考）」の区別です^[9]。人間も、道を歩くたびに熟考はしません。大半は瞬間的な判断で、じっくり考えるのは一部の場面だけです。AIでも同じ分担をしよう、という発想です。

System One modelとは、ソフトウェアがそのまま使える、速くて構造化された判断をするために作られた新しい種類のフロンティアモデルである。

"a new class of frontier models built to make fast, structured decisions that software can use directly."

TypeSafe AI公式ブログ「Introducing System One Models & Jev」^[9]

OpenAIはDecisions APIを「System One」とは呼んでいません。ただ、独メディアThe Decoderは「Decisions APIで、OpenAIはいわゆるSystem Oneモデルの分野に参入した」と位置づけています^[6]。これはあくまでメディアによる分類です。

user@sinyblog:~/article ❯ 03_jev_and_timeline.md2週間前に登場したJEVと、時系列の整理

JEVを開発したTypeSafe AI（TypeSafe AI, Inc.）は、サンフランシスコの会社です。創業者でCEOのDiogo Almeida（ディオゴ・アルメイダ）氏は、公式サイトによると、ChatGPTにつながった手法であるRLHFとInstructGPTの共同発明者で、以前はGoogle Brainに在籍していました^[19]。一部の二次記事には「Diego」と書かれていますが、公式ブログの署名は「Diogo」です。

DiogoはRLHFとInstructGPT（ChatGPTとGPT-4につながった手法）を共同発明した。以前はGoogle Brainに在籍していた。

"Diogo co-invented RLHF and InstructGPT, the methods that lead to ChatGPT and GPT4. Previously, he was at Google Brain."

TypeSafe AI公式 Teamページ^[19]

公式Teamページには、COOのSasha Sheng氏、CTOのErik Gafni氏も創業メンバーとして並んでいます^[19]。資金面では、DCVCがリードした4,000万ドルのシードラウンドを実施し、同時にステルス状態から姿を現したと発表しています（出典は会社のプレスリリース^[26]）。

時系列（確認できた範囲）

「OpenAIの回答」という表現は誰のものか

発表直後から、Decisions APIをJEVと結びつける論評が相次ぎました。ただし、OpenAI自身が発表の中でJEVやTypeSafeに言及した記録は、本記事の調査では見つかっていません。以下はすべて第三者の評価です。

The New Stackは「OpenAIはDevDayに間に合わせて発表を急いだのだろう」とも書いていますが、これも記者の推測です^[7]。本記事では、「OpenAIがJEVを真似した」「JEV対策として急いで開発した」といった因果関係は確認できていないものとして扱います。発表の時期が近いことは事実ですが、開発がいつ始まったかは外部からは分かりません。

user@sinyblog:~/article ❯ 04_decisions_api.mdDecisions APIの仕組み：分かっていること・未発表のこと

まず、OpenAI公式のDevDay 2026 Recapに載っている説明です。これが現時点で最も信頼できる一次情報です。

Decisions APIは、Lunaの知能を「ユーザーが定義した特定の質問」と「有限個のあらかじめ定義された答え」に集中させることで、リアルタイムの意思決定を可能にする。開発者はテキストまたは画像で文脈を渡し、コンテンツの分類、リクエストの振り分け、エージェントの次の行動の選択に使える答えを受け取る。

"Decisions API enables real-time decision-making by focusing Luna's intelligence on a specific set of user-defined questions with finite pre-defined answers. Developers supply context using text or images, and get back answers they can use to classify content, route requests, or choose an agent's next action."

OpenAI「DevDay 2026 Recap」^[1]

提供状況についても、同じページに「本日limited previewとして提供し、今後数日のうちに広く公開する予定」と書かれています^[1]。ただしEveryは「正式ローンチは数週間後の見込み」と書いており、報道によって時期の表現が食い違っています^[8]。本記事では公式の表現を優先します。

GPT-6 Lunaとの関係：「Lunaベース」の正確な意味

多くの記事が「Lunaベース」と書いていますが、OpenAIが公式に使っている表現は次の2つだけです。

1. "powered by GPT-6 Luna"（OpenAI Devs公式Xアカウント^[2]）
2. "focusing Luna's intelligence on …"（DevDay 2026 Recap^[1]）

通常のGPT-6 Lunaをそのまま呼んでいるのか、判断用にファインチューン（追加学習）した別モデルなのか、推論の仕組みだけを最適化したものなのかは、公式には説明されていません（未発表）。OpenAIのTibo氏（@thsottiaux）はXで「数百ミリ秒未満でエンドツーエンドの判断ができるよう"tuned"されている」と書いています^[3]。ただ、この"tuned"がモデルの重みの調整なのか、提供システム側の調整なのかは特定できません。一部の二次記事は「判断用に特化したLunaの派生モデル」と断定していますが、出典は示されていません。

参考までに、土台とされるGPT-6 Luna自体の公式仕様は次のとおりです。これは通常のAPI（Responses API等）で使うときの仕様で、Decisions APIの仕様ではありません。

出典：OpenAI API Docs「GPT-6 Luna」^[4]

公開されている仕様・未発表の仕様

user@sinyblog:~/article ❯ 05_jev_architecture.mdJEVの仕組み：System One・RLCD・Choice/Score/Noul

JEVのほうは、公式ブログと公式ドキュメント（docs.typesafe.ai）に仕様が細かく公開されています。公式トップページの見出しは「Decisions, not strings」（文字列ではなく、判断を）。すぐ下に「Typed outputs that software can act on（ソフトウェアがそのまま使える型付きの出力）」と続きます^[10]。

JEVは、フロンティア級の知能を持つ関数呼び出しだと考えてほしい。構造化されていない状態を入れると、型付きの確率的な判断が出てくる。

"Think of Jev as a frontier-intelligence function call: unstructured state in, typed probabilistic decisions out."

TypeSafe AI公式ブログ^[9]

「new model architecture」とparallel sampler

TypeSafeは、JEVが「新しいモデルアーキテクチャ」「効率を最大化するparallel sampler（並列サンプラー）」「RLCDという学習法」の3つでできていると説明しています。

自動化だけに焦点を当てた新しいスタックを作った。新しいモデルアーキテクチャ、効率を最大化する並列サンプラー、そしてReinforcement Learning for Calibrated Decisions（RLCD）と呼ぶ学習手法だ。

"We built a new stack entirely focused on automation: with a new model architecture, parallel sampler for maximum efficiency, and training method we call Reinforcement Learning for Calibrated Decisions (RLCD)."

TypeSafe AI公式ブログ^[9]

公式ブログは、並列サンプラーの意味を「トークンを1つずつ自己回帰的に生成する代わりに、すべての確率を並列に出力する」（"outputs all probabilities in parallel instead of autoregressively generating by token"）と説明しています^[9]。公式ドキュメントにも「すべての質問は同じstate（状態）に対して並列かつ独立に一度で評価される。質問を増やしても応答時間はほとんど変わらない」とあります^[29]。

一方で、内部構造の詳細（モデルの層構成、パラメータ数、論文）は公開されていません。TechCrunchは「transformerベースのモデル」と書きつつ、アルメイダ氏はアーキテクチャについて口が堅いと伝えています^[20]。「non-autoregressive（非自己回帰）」という言葉は第三者の解説記事に多く出てきますが、TypeSafe公式の文面では確認できませんでした。

なぜ「LLM」ではなく「System One」と呼ぶのか

公式ドキュメントは「LLMと同じように自然言語の入力を理解するが、生成したテキストではなく、型付きの判断と確率を返す」と説明しています^[14]。返信を書かない、コードを生成しない、推論の説明も書かない。「文章を生成しない」ことが、LLMと呼ばない最大の理由です。

RLCDとCalibration（較正）

RLCD（Reinforcement Learning for Calibrated Decisions）は、TypeSafe独自の学習法です。ChatGPTを生んだRLHF（人間のフィードバックによる強化学習）が「人間に好まれる文章」を目指すのに対し、RLCDは「確率が正直な判断」を目指します。ここで重要なのがCalibration（較正）という考え方です。

確率0.8が付いた結果は、およそ80%の割合で実際に起きるべきである。これは予測の集団についての割合であり、個々の答えを保証するものではない。

"Outcomes assigned a probability of 0.8 should occur about 80% of the time." / "These rates describe groups of predictions, not a guarantee about any single answer."

TypeSafe公式Docs「Machine learning primer」^[15]

たとえば天気予報で「降水確率80%」の日を100日集めたら、実際に雨が降ったのが約80日。これが「較正されている」状態です。LLMは自信満々に間違えることがありますが、較正されたモデルなら「確率0.6の答えは4割くらい外れる」と見込んで設計できます。

3つの質問タイプ：Choice／Score／Noul

JEVの質問タイプは3種類だけです。YES/NO専用の型は「Noul」という名前で、綴りはnoulです（NullやNoULの誤記ではありません）^[12]。

出典：TypeSafe公式Docs「Introduction」「API reference」^[29][12]。1回のAPI呼び出しに3タイプを混ぜて複数入れられます。質問数の明示的な上限は、公式Docsでは確認できませんでした。

公式Docsによると、confidenceは確率がどれだけ1つの候補に集中しているかから計算され、1つの候補に全部集まれば1.0、ばらけるほど低くなります（正確な計算式は非公開）^[16]。

「ハルシネーションしない」の正確な意味

公式ブログは「JEVは文字列生成を手放した代わりに構造化出力に最適化されており、ハルシネーションしようがない」と書いています^[9]。ただし、これは「答えが必ず候補のどれかになる（型が崩れない）」という意味で、「答えが必ず正しい」という意味ではありません。TypeSafe自身もベンチマークのグラフに付けた「0%」について、「この数字は実測ではない。スキーマの一致が保証されているので0%と書いた」と注記しています^[9]。

user@sinyblog:~/article ❯ 06_jev_vs_jev_omni.mdJEV・Jev-Omni・互換APIは別物

JEVの人気に便乗して、名前の似たモデルやサイトが短期間で大量に登場しました。比較記事を読むときに一番混乱しやすいポイントなので、先に整理します。

出典：TypeSafe公式Docs^[11][14]、Jev-Omni モデルカード^[22]

Jev-Omniのモデルカードには、TypeSafe公式との関係について次のように明記されています。

TypeSafe AIおよびそのJevモデルとは提携しておらず、承認・後援も受けておらず、派生したものでもない。Jevの出力で学習したものも一切含まれない。

"It is not affiliated with, endorsed by, sponsored by, or derived from TypeSafe AI or its Jev model, and nothing in it was trained on Jev output."

Jev-Omni モデルカード（作者による記述）^[22]

つまりJev-Omniは「公式JEVのオープンソース版」ではなく、「JEVと同じ質問形式（Choice／Score／Noul）を、Gemma 4をベースに独自に再現した別モデル」です。モデルカード自身も「typed-decisionインターフェースを実装した独立したオープンモデル」と説明しています^[22]。

JEV互換API・コミュニティ実装（すべてTypeSafe公式ではない）

1. Prem AI：「Jev互換の判断API」を独自モデルで提供（テキスト・画像・短い動画）と発表^[23]。第三者サービス。
2. openjev-sglang（GitHub）：Qwen系のオープンモデルでJEV互換のAPIを動かす実装。READMEに「TypeSafeへのリクエストは発生しない」と明記^[24]。コミュニティ実装。
3. 公式と紛らわしい情報サイト：「jev」を含むドメインの解説・プレイグラウンドサイトが複数あります。TypeSafe公式のドメインは typesafe.ai（docs／api／console等のサブドメインを含む）です。

なお、OpenRouterやVercel AI Gatewayは、公式Docsが接続方法を案内している経路です。これらは公式JEVを中継する第三者の配信サービスで、互換モデルではありません^[11][25]。

user@sinyblog:~/article ❯ 07_similarities.md両者はどこが似ている？

Decisions APIと公式JEVの共通点は、次の4つに集約できます。

1. 答えの候補を開発者が先に決める。OpenAIは「user-defined questions with finite pre-defined answers」^[1]、JEVは「typed questions」で候補を定義します^[12]。AIが自由に文章を書く余地はありません。
2. 速さを売りにしている。OpenAIは「リアルタイムの意思決定」、JEVは「エンドツーエンドで70〜500ms」を掲げています^[1][9]。
3. 想定用途がほぼ同じ。コンテンツ分類、リクエストの振り分け（ルーティング）、エージェントの次の行動選択。OpenAIが公式に挙げた3用途は、JEVのドキュメントやクックブックが扱う題材と重なります。
4. チャットやコード生成には使わない。TypeSafeは「JEVはClaude CodeやCursorの裏にいるLLMの代わりにはならない」と明言しています^[28]。Decisions APIも、決まった答えを返す以上、会話には使えません。

この共通点だけを見ると、「OpenAI版JEV」という呼び方にも一理あります。見た目の用途、つまり外から見たAPIの役割は、確かによく似ています。問題は、その内側です。

user@sinyblog:~/article ❯ 08_differences_table.md決定的に違うところ（全項目比較表）

公開情報をすべて突き合わせた比較表です。「不明」「未発表」は推測で埋めていません。JEVの列は公式JEV（TypeSafe AI）だけを指し、Jev-Omniや互換APIは含みません。

出典：Decisions API＝OpenAI公式^[1][2][4]、The Decoder^[6]、The New Stack^[7]。JEV＝TypeSafe公式^{[9][11][12][14][18]}。

表を眺めると、違いは3つの軸に整理できます。

1. 作り方：Decisions APIは「汎用の小型LLMを判断に集中させる」。JEVは「判断専用のモデルを最初から作る」。前者はLunaの知識や画像理解をそのまま活かしやすく、後者は速度・コスト・確率の正直さを設計目標にしています。
2. 確率の扱い：JEVは確率とconfidenceを返すこと、それが較正されていることを製品の中心に置いています。Decisions APIは、確率を返すかどうか自体がまだ公表されていません。判断結果を「何％の確からしさか」で後段の処理に使いたい場合、現時点で仕様として確かめられるのはJEVだけです。
3. 情報の公開度：JEVは料金もレート制限も公開済みで、今日から見積もりができます。Decisions APIは、プレビュー参加者以外は仕様を確かめられない段階です。

user@sinyblog:~/article ❯ 09_speed_accuracy_price.md速度・精度・価格を比較する

速度：数字はあるが、同じ土俵ではない

公開されている速度の数字は、出どころも測り方もばらばらです。

見てのとおり、第三者による直接比較の2件でも、速かったほうが入れ替わっています。「150ms」と「70〜500ms」を並べて「Decisions APIのほうが速い」と言うこともできません。前者はOpenAIが自社サービスで測った数字、後者はTypeSafeが米西海岸から測った数字で、入力も質問数もネットワーク経路も違うからです。レイテンシは、データセンターまでの距離、入力の長さ、混み具合で大きく変わります。日本から使う場合の速度は、自分で測るまで分からないと考えてください。

精度・ベンチマーク：共通のものさしがまだない

OpenAIはDecisions APIの精度やキャリブレーションの数値を公開していません。TypeSafeは自社サイト（evals.typesafe.ai）で、4種類の業務ワークフロー（セキュリティインシデント、エージェントのトレース監視、請求書処理、カスタマーサービス）の評価を公開しています^[17]。

出典：TypeSafe公式 Workflow evals^[17]。各モデルは提供元の既定の推論設定で実行。

この表には重要な注意点が3つあります。

1. 評価したのはTypeSafe自身。公式ブログも「モデル能力チームの個人が作ったので、多少のバイアスはありうる」「実際の効果より高めに出ている可能性がある」と注記しています^[9]。
2. 正解は他のLLMの答え。公式ブログによると、参照解はGPT-6 AstraとFable 5.1の平均です^[9]。人間が作った正解データではありません。
3. 表の「luna」は世代が明記されていない。evalsサイトは世代なしで「luna」と書いており、Decisions APIの土台であるGPT-6 Lunaと同じモデルかは確認できません。この行をDecisions APIの成績として読んではいけません。

第三者の比較はEveryの2件だけです。コンピュータ操作タスクでは、78ステップ中Decisionsが76問、JEVが73問で正しい操作を選びました。会話スレッドの分類では精度は「実質的に互角」でした^[8]。どちらもプレビュー期間中の少数の検証です。Accuracy、F1、Brier Score、ECE（期待較正誤差）といった標準的な指標で両者を比べたベンチマークは、2026年9月30日時点で見つかりませんでした。

価格：100万件の問い合わせを4分類したら？

依頼の多いシナリオで試算します。問い合わせ100万件を「billing（請求）」「technical（技術）」「sales（営業）」「fraud（不正利用）」の4つに分類するケースです。

もう一つ見落としやすいのがレート制限です。JEVの既定は1分あたり1,200リクエストなので、1件1リクエストで送ると100万件の処理には約833分（約14時間）かかります。同じ問い合わせに複数の質問（部署・緊急度・感情など）をまとめて1リクエストにすることはできます。公式クックブックは、13問を1回にまとめると約12倍安く、約10倍速くなった例を紹介しています^[27]。ただし、複数の問い合わせを1リクエストにまとめる方法は公式Docsで確認できませんでした。大量処理を急ぐなら、上位プランでのレート制限の引き上げを相談することになります^[11]。

user@sinyblog:~/article ❯ 10_same_task_three_ways.md同じ問い合わせを3つのAIに渡すと

具体例で比べます。問い合わせは「クレジットカードから二重請求されています」、候補は billing／technical／sales／fraud の4つです。

「二重請求」は面白い例です。単なる請求ミス（billing）かもしれないし、カードの不正利用（fraud）かもしれません。普通のGPTは多くの場合どちらか1つを言い切ります。確率を返すモデルなら、「billing 0.6／fraud 0.4のように割れたら、人間のオペレーターに回す」という設計ができます。判断が割れていること自体が有用な情報になるのが、確率を返す判断モデルの強みです。

JEVのリクエスト例

以下は、TypeSafe公式クイックスタート^[13]の形式に合わせて当サイトが作成した例です（公式サンプルそのものではありません）。エンドポイントは POST https://api.typesafe.ai/v1/systemone、認証はBearerトークンです^[12]。

{
  "state": "I was charged twice on my credit card for the same order.",
  "model": "jev-latest",
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "Which team should handle this",
      "criteria": {
        "billing": "Payment, invoice or subscription issues",
        "technical": "Bugs or integration problems",
        "sales": "Pricing or account questions",
        "fraud": "Unauthorized or suspicious charges"
      }
    },
    "is_urgent": {
      "type": "noul",
      "instructions": "The message conveys urgency or time-sensitivity"
    }
  }
}

レスポンスの形も、公式クイックスタートの例から分かります。以下は公式例（Stripe連携の問い合わせを billing／technical／sales に分類したもの）の一部をそのまま抜き出したものです。

{
  "model": "jev-1.13.0",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "technical",
      "confidence": 0.78,
      "probabilities": {
        "technical": 0.85,
        "sales": 0.0,
        "billing": 0.15
      }
    },
    "is_urgent": {
      "type": "noul",
      "noul": 1.0
    }
  },
  "usage": {
    "input_tokens": 392,
    "output_tokens": 65
  }
}

Decisions APIのリクエスト例は？

第4章のとおり、2026年9月30日時点で公式のリクエスト形式が公開されていないため、掲載しません。公式に分かっているのは「質問と答えの候補を定義し、テキストまたは画像で文脈を渡すと、答えが返る」という流れだけです^[1]。広く公開された時点で、この記事に追記する予定です。

user@sinyblog:~/article ❯ 11_why_not_plain_gpt.md普通のGPTにJSONで返させるのと何が違う？

初心者が一番疑問に思うところです。「4つから1つ選んでJSONで返して」とGPTに頼めば、同じことができそうに見えます。実際、The New Stackも「今日ほとんどのチームは、普通のチャットモデルと丁寧なプロンプトでこれをこなしている」と書いています^[7]。参考として、OpenAIのStructured Outputs（JSONスキーマ指定）で書くと次のようなイメージです。

{
  "model": "gpt-6-luna",
  "input": "Classify: I was charged twice on my credit card.",
  "text": {
    "format": {
      "type": "json_schema",
      "name": "route",
      "strict": true,
      "schema": {
        "type": "object",
        "properties": {
          "category": {
            "type": "string",
            "enum": ["billing", "technical", "sales", "fraud"]
          }
        },
        "required": ["category"],
        "additionalProperties": false
      }
    }
  }
}

これでも形式はきちんと守られます。では、何が違うのでしょうか。

ポイントは、JSONで返させる方法の本質は「文章生成の出口に型をはめる」ことで、判断モデルは「そもそも判断だけをする」ことという違いです。1回や2回なら差は小さく感じます。1日に何十万回も判断するシステムや、1つのタスクで何十回も判断を重ねるエージェントでは、速度・コスト・確率の有無が効いてきます。逆に、判断の理由を人間に説明する必要があるなら、普通のLLMのほうが適しています。

user@sinyblog:~/article ❯ 12_agent_architecture.mdAIエージェントで何が変わる？

判断モデルが最も効くと考えられるのが、AIエージェントです。エージェントは、次のループを何十回、何百回と回して仕事を進めます。

1. 状態を取得する：画面、検索結果、コードのテスト結果、ユーザーの返信など
2. 次の行動の候補を作る：使えるツールの一覧、画面上のボタン、選べる操作
3. 判断する：候補のどれを実行するかを選ぶ ← ここを判断モデルに任せる
4. ツールを実行する：検索、コード修正、ブラウザ操作、メール送信など
5. 新しい状態を取得する
6. 再び判断する：1に戻る

ステップ3で判断する内容は、たとえば次のようなものです。

「毎回高性能LLM」方式と「LLM＋判断モデル」方式

The Decoderも「強いモデルをオーケストレーター（指揮役）にして、速い判断モデルと組み合わせる形は有望に見える」と評しています^[6]。Everyの検証でも、Decisions APIとJEVの両方がコンピュータ操作タスクの「次にどの操作を選ぶか」で高い正答率を出しました^[8]。

user@sinyblog:~/article ❯ 13_strengths_usecases.md強み・弱みと、向いている用途

どちらが優秀かではなく、「どんな用途なら、どちらの設計思想が合うか」で整理します。Decisions APIの項目は、公開情報から考えられる範囲にとどめています。

ユースケース別の向き・不向き

1. 画像を見て判断したい（スクリーンショットからの操作選択、商品画像の分類、不適切画像の検知）→ 公式サービス同士ならDecisions API。公式JEVは画像非対応です。
2. 確率で後段の処理を変えたい（確信度が低いものだけ人間に回す、しきい値で自動承認）→ 仕様として確かめられるのは現時点でJEV。
3. 大量のテキスト分類を安く回したい（問い合わせの一次振り分け、ログの異常検知、請求書の仕分け）→ 料金が公開されているJEVはすぐ見積もれる。Decisions APIは料金発表を待って比較。
4. すでにOpenAIのAPIでエージェントを組んでいる→ Decisions APIが広く公開されたら、同じ基盤の中で試せる利点がある。
5. データを外部に出せない・自社サーバーで動かしたい→ どちらも不可。重みが公開されているJev-Omniなどのオープンモデルが候補になりますが、公式JEVとは別物です（第6章）。
6. 判断の理由を説明する必要がある（監査、顧客への回答文）→ どちらも理由は書かないので、普通のLLMと組み合わせる。

user@sinyblog:~/article ❯ 14_known_unknown.md現時点で分かっていること／分からないこと

情報源の信頼度の目安

1. OpenAI公式：openai.com、OpenAI API Docs、@OpenAIDevs。Decisions APIについては現状これが最優先。
2. TypeSafe公式：typesafe.ai とそのサブドメイン（docs／api／console／evals）、github.com/typesafe-ai。JEVの仕様はここで確認する。
3. Jev-Omni作者：Hugging Faceのモデルカード。公式JEVの情報源ではない。
4. 第三者サービス：JEV互換APIや解説サイト。公式と名前が似ていても別物。
5. 第三者メディア：The Decoder、The New Stack、Every、TechCrunchなど。実測や論評は貴重だが、条件と主語を確認する。
6. SNS投稿：速報性は高いが、揶揄や推測も多い。事実の根拠にはしない。

user@sinyblog:~/article ❯ 99_summary.mdまとめ

「OpenAI Decisions APIは“OpenAI版JEV”なのか？」という問いへの答えは、用途は同じ方向を向いているが、中身は別の設計で、しかも現時点では公平に比べられるほど情報がそろっていない、です。

1. 似ているのは「外から見た役割」。質問と答えの候補を先に決め、AIには高速に選ばせるだけ。分類・ルーティング・エージェントの次の行動選択という用途も重なります。
2. 違うのは「作り方」と「確率の扱い」と「公開度」。Decisions APIはGPT-6 Lunaを土台にし、画像入力に対応しますが、料金・形式・確率の有無は未発表です。JEVは判断専用の新アーキテクチャとRLCDで作られ、較正された確率を返し、料金も仕様も公開済みですが、テキストのみです。
3. 本当のニュースは「AIの使い方の変化」。これまでの生成AIは「賢いLLMに考えさせて文章を書かせる」ものでした。これからは「深く考える部分は高性能LLM、瞬間的な判断は判断モデル」という役割分担が広がる可能性があります。

Decisions APIは数日から数週間のうちに広く公開される見込みです。料金とリクエスト形式が発表されたら、この記事を更新します。試すなら、自分のデータ・自分の地域・自分の言語で速度と精度を測ることをおすすめします。公称値やベンチマークは、条件が違えば簡単にひっくり返るからです。