ChatGPT共同発明者が新AIモデルを発表：System Oneは文章を生成せず、意思決定に特化
かつてOpenAIでChatGPTとRLHFを共同発明したDiogo Almeida氏が、System Oneモデルパラダイムと初の公開モデルJevを発表した。自由なテキストを生成せず、コードであらかじめ定義された構造の範囲内で確率的な意思決定のみを返す。
「System Oneモデル」とJevとは何か？
かつてOpenAIでChatGPTと人間のフィードバックによる強化学習（RLHF）を共同発明したDiogo Almeida氏が、まったく異なる新たなモデルカテゴリである「システム1」（System One）モデルを打ち出し、このパラダイムにおける初の公開モデル「Jev」をリリースした。
既存の主流な大規模モデルは対話を得意とする一方で、コード内で自動化処理を安定して実行させることは困難である。Jevの核となるトレードオフは、一語一語の自由なテキスト生成を放棄し、事前定義された構造におけるカテゴリ、スコア、確率、および信頼度の出力に特化することにある。チャットや文章作成を担うもう1つのモデルではなく、プログラムの制御フローに組み込める高速な意思決定コンポーネントとなることを目指している。
「System One」の名は、ダニエル・カーネマンの『ファスト＆スロー』に由来する。システム1は、長時間の演繹を必要とするシステム2に対置される、迅速で直感的な判断を表している。TypeSafeはこの名称を用いて、低遅延な応答を要する大量の分類、スコアリング、ルーティングの課題を解決するものであることを強調している。一方、「Jev」という名称は、経済学の「ジェボンズのパラドックス」（Jevons paradox）に由来する。蒸気機関の効率が向上した結果、石炭の総消費量がむしろ増加した現象である。この名称が表現している製品としての判断は、インテリジェントな意思決定1回あたりのコストと遅延が数桁低下すれば、ソフトウェアにおける知的判断の需要も飛躍的に増大するという点にある。
なぜこのようなモデルが登場したのか。それは、人間とマシンの対話向けに設計された自由テキスト生成メカニズムと、自動化パイプラインが求める低遅延、固定インターフェース、制御可能な分岐との間に明確なギャップが存在するためである。
過去数年間、大規模モデルはオープンエンドな対話や長文作成において目覚ましい成果を上げてきたが、決定論的なロジックを必要とするエンタープライズのバックエンドコードへの導入は、しばしば期待を下回ってきた。主流の大規模モデルは主にRLHFによってアライメントされており、その中核目標は人間のレビュアーの好みに合致した自然言語を出力することである。対話に適応させるため、モデルは任意の文字列を自由に生成する能力を備えていなければならないが、この仕組みをコードパイプラインに組み込むと、エンジニアリング上の3つの致命的な弱点が露呈する：
応答遅延が大きすぎる：従来のLLMは自己回帰によるトークン単位の直列生成を採用している。TypeSafeが引用した最先端ベンチマークによると、エンドツーエンドの応答時間は多くの場合3秒から329秒に及ぶ。画面の前にいる人間のユーザーにとっては許容範囲内であっても、多段階のカスケード呼び出しを必要とするプログラム内部では、数十秒の待機時間が急速に累積し、実用不能に陥る。TypeSafeは「100倍高速」という言葉で製品のセールスポイントを要約している。同社が提示するJevのエンドツーエンドの所要時間範囲は70ms〜500msであり、実際の倍率は比較対象のモデルや具体的なタスクによって異なる。
型システムが極めて脆弱である：大規模モデルがネイティブに出力するのは文字列であり、プロンプトでJSON出力を指示したとしても、本質的には下流のコードによるデシリアライズと検証が必要となる。余計なプレフィックスの付加、フォーマットの破損、予期せぬ応答拒否が発生すれば、下位層での1回のパース例外によってビジネス呼び出しチェーン全体がクラッシュし中断してしまう。
直接依拠できる信頼度推定の欠如：対話モデルは好みの調整（アライメント）を経ることで過信に陥りやすく、自己評価が前後で矛盾することが多い。モデルがいつ確信を持っており、いつ盲目的に推測しているのかをシステムが判断できなければ、下流のプログラムは自動通過の閾値や人手による介入・フォールバックを安全に設定することができない。
人間の認知において、システム1は本質的に信頼性を意味するものではなく、素早い直感も同様に誤りを犯し得る。TypeSafeの技術的な主張は、モデルから自由テキスト生成を切り離し、型安全と確率のキャリブレーションに特化させることで、少なくともインターフェースの構造上はフォーマットエラーやパース例外を排除できるという点にある。意味的な判断が正しいかどうかは、依然として別次元の問題である。
既存のモデルと何が違うのか？
Jevは既存の大規模モデルをファインチューニングして縮小したものではなく、デコードメカニズムから学習パラダイムに至るまで全面的に再構築された独立したモデルスタックである。
従来のLLMアーキテクチャ：
[非構造化入力] ──> [自己回帰デコーダ（トークン単位の直列生成）] ──> [自由形式の文字列（外部検証が必要、解析エラーとハルシネーションのリスク）]
System One (Jev) アーキテクチャ：
[非構造化状態] ──> [Parallel Sampler（ハードウェアアクセラレーションによる単一フォワードパス）] ──> [事前定義された強い型の確率（数学的ゼロ型エラー、キャリブレーション済み信頼度を内包）]
| 比較項目 | 2つのモデルの主な違い |
|---|---|
| 生成メカニズム | 対話モデルは自己回帰によるトークン単位の直列デコード。Jevはハードウェア対応のParallel Samplerを使用し、1回の計算ですべての数値出力を算出。 |
| 出力形式 | 対話モデルは自由形式の文字列を返し、パースと検証が依然として必要。Jevは事前定義されたSchemaで許可された離散確率またはスケール数値のみを返し、インターフェース層で型の一致を保証。 |
| 応答速度 | TypeSafeが引用する最先端対話モデルのベンチマークは3〜329秒。Jevの公式エンドツーエンド公称値は70〜500ms。TypeSafeは「100倍高速」と主張しているが、4つのワークフロー平均において精度が近いTerraは約25倍遅い。 |
| 呼び出しコスト | 対話モデルは通常、入力トークンと出力トークンの両方に課金。Jevの早期アクセス価格は入力が1Mトークンあたり$0.042、出力は無料。TypeSafeは「100倍安価」と主張しているが、4つのワークフロー平均においてTerraのコストは約76倍高い。 |
| 確率と信頼度 | TypeSafeはRLHFモデルが過信に陥りやすいと考えている。JevはRLCDを用い、「より高い信頼度がより高い精度に対応する」ことを最適化目標としているが、現時点で公開された独立したキャリブレーション曲線は存在しない。 |
| 適用タスク | 対話モデルはオープンな対話、テキスト作成、複雑な推論を得意とする。Jevはデータルーティング、離散分類、セキュリティガードレール、構造化抽出向けであり、自由なテキスト生成は担わない。 |
Jevにおける最も重要なアーキテクチャ上の選択は、自由テキスト生成の完全な放棄にある。従来のLLMは自己回帰（Autoregressive）メカニズムを採用しており、新しいトークンを1つ生成するごとに直前のトークンに依存する必要があるため、計算は時間軸上で高度に直列化されている。これに対しJevは、クエリを発行する前に呼び出し側があらかじめ出力構造を定義し、モデルは順伝播の過程でハードウェアを考慮したParallel Samplerを通じて、全次元の数値出力を1回で計算する。TypeSafeは、これによりエンドツーエンドの応答時間が70msから500msに短縮され、同社の公称値において従来のLLM比で数十倍から百倍以上の高速化を実現したとしている。
このアーキテクチャの再構築は、同時にインターフェース層における型構造のエラーを排除している。従来のLLMの出力空間は自然言語の語彙全体をカバーしているのに対し、Jevの出力空間は推論前に事前定義されたSchemaによって完全に制限されており、出力側は離散カテゴリやスケールの数値確率へと直接マッピングされる。そのため、構造と型の一致はインターフェース自体によって保証される。ただし留意すべき点として、これは出力フォーマットが事前定義された構造に従うことを保証するに過ぎず、モデルの意味的な判断が必ず正しいことを証明するものではない。
学習アルゴリズムにおいて、現在の産業界では主に2つのアプローチが採用されている。1つは人間の読書傾向に合わせて最適化するRLHFであり、人間に迎合するためにモデルが過信に陥りやすい。もう1つは検証可能な報酬を対象とする強化学習（RLVR）であり、コードのユニットテストによって低コストで検証可能な目標（数学的証明やコードのコンパイルなど）に依存しているが、決定論的なテストケースが存在しない現実のビジネスシナリオでは汎化能力が不足しがちである。
これに対し、TypeSafeは「キャリブレーションされた意思決定のための強化学習」（RLCD：Reinforcement Learning for Calibrated Decisions）を提案した。RLCDはテキスト表現の生き生きとした豊かさを評価するのではなく、最適化の目標を「キャリブレーションされた意思決定」（calibrated decisions）に設定している。公式の発表によれば、その目標は「より高い信頼度がより高い精度に対応する」（higher confidence means higher accuracy）ようにし、認識論的に誠実な確率分布を出力することであるという。もっとも、公式資料では具体的な学習実装の詳細や独立したキャリブレーション曲線は公開されていない。設計上の構想によれば、曖昧または判断の難しい境界領域のサンプルに対しては、モデルはより平坦で分散した確率分布を出力し、下流のエンジニアリングコードが閾値を設定して分岐の切り替えやフォールバックによる遮断を行えるようにするという。
TypeSafeは、Jevが従来のLLMと比較して100倍高速で100倍安価であり、出力トークンは無料であると主張している。同社が公表した早期アクセス価格によると、Jevは入力100万トークンあたり0.042ドル（10億トークンあたり42ドルに相当）で、出力側は確かに無料と記載されている。しかし公式側も、この価格設定が長期的に持続可能かどうかは時間による検証が必要であることを明確に認めており、100倍のコスト削減という主張も公式の4つのワークフロー実測においてタスクごとに異なっている（同等の精度比較において、Terraのコストは約76倍高い）。
主な用途は何か？コード内の「インテリジェントな判断ノード」となる
実際のエンジニアリングシステムにおいて、ハードコードされたルールのみに依存するのは極めて脆弱であり、一方でプロセス全体を単一のLLMに委ねるのも制御不能に陥りやすい。Jevの中核的な位置づけは、通常のコード制御フローに組み込まれる「曖昧なセマンティクス判断ノード」である：コードが全体の制御フローを司り、モデルは確率を伴う局所的なセマンティクスの判定のみを担当する。
その最も直接的な用途は、コード内でルールを網羅することが困難な「インテリジェントなif-else」の代替である：リクエストのルーティングや分類、リスク・満足度・適合度のスコアリング、非構造化入力からの制約付きフィールドの抽出、あるいは特定のステップで人手による介入が必要かどうかの判断などを行う。低遅延であるためリアルタイムなインタラクションにも適用でき、低単価であるため大量のレコードのバッチ処理にも適している。また、固定された候補と確率出力により、他のLLMの前後に配置するセキュリティガードレールとしても機能させることができる。
公式SDKおよびオープンソースのアダプターにおいて、基盤となるセマンティクスの意思決定は3つの標準的な型のプリミティブとして抽象化されている：
Noul（ブール値判定）：非構造化テキストと判定条件を入力し、その命題が成立する確率を出力する。二値判断の処理に使用される。
Choice（離散分類）：明確に定義された候補集合の中から単一の選択を行い、すべてのカテゴリをカバーする完全な確率分布と総合的な信頼度スコアを返す。システムはネイティブで最大255カテゴリの選択に対応している。より大規模な候補集合を扱う場合、システムはまず並列でスコアリングを行ってから離散的な選択を行う。
Score（順序付きスコアリング）：あらかじめ設定された連続スケールまたは順序付きルーブリック（Rubric）に基づいて採点を行い、現在のスコア値、各段階の離散分布、および信頼度を返す。重大度、感情的な満足度、または適合度の定量化に適している。
企業の日常的な従業員の経費精算審査を例にとると、2つのパラダイムの違いが明確にわかる。
従来のLLMによるアプローチでは、開発者は通常すべての業務規定を1つの長いプロンプトに詰め込む：「各経費精算には領収書の添付が必要。領収書が判読できない場合は差し戻す。飲食費、出張費、備品購入費のいずれに該当するかを判断する。飲食費の申請が75ドルを超え、かつ明細と申請説明が一致しない場合はマネージャーの承認が必要。その他は直接承認する。」このようなモノリシックなプロンプトは、モデルが思考の連鎖の中で最終アクションを一度に演繹することを要求するため、多段階のロジックが混在して演繹のドリフトが極めて発生しやすくなる。
これに対しSystem Oneアーキテクチャでは、この業務は決定論的なコードとセマンティクスのプリミティブが協調して構成する計算グラフへと分解される：
[経費精算の申請と領収書を受領]
│
▼
[Q1: Noul] 領収書の画像または文字は鮮明で読み取り可能か？
/ \
(いいえ / 低確率) (はい / 高確率)
/ \
[再アップロードを求めて差し戻し] [Q2: Choice] 支出の種類はどれか？
│
┌───────────┼───────────┐
▼ ▼ ▼
[出張] [備品] [飲食]
│ │ │
│ │ ▼
│ │ [Pythonネイティブコード]
│ │ 金額は > $75 か？
│ │ / \
│ │ (いいえ) (はい)
│ │ │ │
│ │ │ ▼
│ │ │ [Q3: Noul] 領収書の明細と
│ │ │ 申請内容は一致しているか？
│ │ │ / \
│ │ │ (一致) (不一致)
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
[ システムが自動承認 ] [ マネージャーの二次承認をトリガー ]
このアーキテクチャでは、数値比較 amount > 75 をPythonランタイムに直接処理させることで、モデルが数値を読み違えるリスクを根絶している。領収書の鮮明さやセマンティクスの一致度は、NoulノードとChoiceノードに委ねて個別に演算させる。このパターンは、システムの核となる理念である「決定論的ロジックはコードに委ね、意味理解はモデルに委ねる」という考え方を如実に示している。
開発者が既存のLLMを移行してテストしやすいよう、公式からPythonアダプターライブラリ system-one-adapter がオープンソースとして公開されている。公式のREADMEには現在、Noulの実際の呼び出し例のみが記載されている（ChoiceとScoreのコンストラクタ引数のシグネチャはREADMEではまだ完全には公開されていない）：
from system_one_adapter import SystemOneAdapterClient, Noul
# クライアントを初期化し、構造化出力と確率の正規化を有効化
client = SystemOneAdapterClient(
structured_outputs=True,
llm_answer_mode="probabilities",
normalize_probabilities=True,
)
# 処理対象の非構造化コンテキストとNoulのブール型の質問を渡す
response = client.system_one(
state="本書は印刷が美しく内容も充実しているが、外装がひどく破損しており表紙に折れ目がある。",
questions={
"is_positive": Noul(instructions="全体的な評価はポジティブな高評価に該当するか？"),
},
provider="openai",
model="gpt-4o-mini",
)
# レスポンス結果は自動的に強い型のオブジェクトにカプセル化され、所要時間と確率診断が含まれる
print(response.answers)
print(response.usage.latency)
どのような効果が得られるのか？公式ベンチマークとプロトタイプデモ
コード統合環境におけるモデルのパフォーマンスを評価するため、TypeSafeは従来の公開された学術ベンチマークを採用せず、独自にワークフロー評価を構築した。チームは、公開ベンチマークはテストセットに対する過剰適合を招きやすく、モデルが業務コンポーネントとしてシステムに組み込まれた際の実際の挙動を直接反映できないと考えている。
公式は「ワークフローベンチマーク」（Workflow Evals）を構築し、固定されたコード計算グラフ内でモデルのパフォーマンスをテストした。これには4つの典型的なエンタープライズシナリオが含まれている：
セキュリティインシデントのアラートトリアージ（Security Incidents）：エンドポイントやサーバーがセキュリティアラートを発報した際、マシンの履歴プロファイルと照合して、自動クローズ、人間のアナリストへの引き継ぎ、またはネットワーク隔離の実施を判定する。
Agent軌跡の可観測性（Agent Trace Observability）：カスタマーサポートエージェントが顧客チケットを処理した後、全コンテキストとツール呼び出しログを走査して、人間の介入が必要かどうか、およびその緊急度を判定する。
サプライヤー請求書の照合（Invoice Processing）：請求書の記載情報、発注書、および入庫伝票を突き合わせ、支払いを直接承認するか、確認のために保留するか、あるいは差し戻すかを決定する。
カスタマーサービスの動的ルーティング（Customer Service）：ユーザーとの複数ターンの対話コンテキストとアカウントのリアルタイムステータスに基づき、エージェントが次に実行すべき具体的なアクションを決定する。
現実のビジネスセマンティクスには本質的に唯一のグラウンドトゥルース基準が存在しないため、評価ベンチマークでは最先端モデルであるGPT-6 AstraとClaude Fable 5.1の2つがHigh Thinkingディープ推論モードを有効にした際の判定平均値を、デファクトの参照コンセンサスラベルとしている。その他のモデルはすべてデフォルトの推論設定でテストに参加している。
評価からは明快な結論が得られた：これら4つのサンプルタスクの等加重平均において、テスト対象となった各モデルを構造化ワークフローに分解した場合、同一モデルに単一のモノリシックなプロンプトで全プロセスを実行させるよりも、高精度、低コスト、かつ高速であった。この結論はこのハーネスとサンプルタスクに限定されたものであり、すべての業務に直接外挿することはできない。
同等のワークフロー設定において、TypeSafe公式が発表した4項目の等加重平均の概要は以下のとおりである。すべての精度はチームが独自に構築した「コンセンサスラベル」に対する相対値であり、外部で公認された真値ではない。また2つの参照モデルを除き、テスト対象モデルは各プロバイダーのデフォルト推論設定を使用している。
| モデル | 平均精度 | ワークフローあたりのコスト | ワークフローあたりの所要時間 |
|---|---|---|---|
| Jev | 67.8% | $0.0004 | 0.4秒 |
| Terra | 67.9% | $0.0304 | 10.1秒 |
| Sol | 74.1% | $0.0836 | 23.3秒 |
| Opus 5 | 73.1% | $0.1761 | 37.8秒 |
公式評価で公表された4つのワークフロー等加重平均の概要において：Jevの総合精度は67.8%、平均所要時間は0.4秒、1回あたりのコストは0.0004ドルであった。これに対し、精度が近いOpenAI Terraは精度が67.9%、所要時間は10.1秒、コストは0.0304ドルを要した。直接再計算可能なこの総合比較において：同等の精度のもとでTerraはJevと比較して所要時間が約25倍（10.1秒対0.4秒）、コストは約76倍（$0.0304対$0.0004）となっている。
上記の4つのワークフロー等加重平均の概要に加え、公式評価ページではさらに4つの個別ワークフロー：セキュリティインシデント（Security Incidents）、エージェント軌跡の可観測性（Agent Trace Observability）、請求書照合（Invoice Processing）、カスタマーサービス（Customer Service）が順次掲載されている。公式データによると、Jevは遅延とコストを大幅に削減しながらも、主流の最先端大規模モデルに匹敵する意思決定クオリティを維持している。
2つのプロトタイプデモ：高頻度の意思決定と制約付き候補選択
低遅延と強い型の特性を活かし、公式は従来のLLMでは対応が困難であったいくつかのプロトタイプシナリオを披露した：
Doomリアルタイム制御：公式デモにおいて、エンジニアはクラシックゲームDoom実行中のリアルタイムな状態を構造化データとして抽出しJevに入力した。モデルは毎秒10回（10 queries/s）の頻度で次のアクションを出力し、TypeSafeによるとこのゲームエージェントを駆動する1時間あたりの全体的な呼び出しコストは約7ドルであるという。
Wikiracing（ウィキペディアレース）の挑戦：ウィキペディアのある項目からスタートし、項目内のハイパーリンクのクリックのみを経由して指定された項目に到達するというルールである。各ステップの操作では、膨大な数の候補リンクに直面することが多い。従来の生成モデルは自由形式でテキストを出力する際に、ページ内に存在しないリンクを捏造してしまう可能性がある。一方Jevでは、候補集合が厳格な型とSchemaの制約を受けている（与えられた正規の候補リンク集合内でのみスコアリングと選択を行う）ため、構造的に不正なリンクの生成を根絶している。公式はより少ないステップ数で経路探索を完了したとしているが、これは候補集合が型で制約されているという構造的な保証によるものであり、あらゆるセマンティクスレベルでハルシネーションがゼロであることを意味するわけではない。
現時点での限界は何か？
公式ベンチマークのパフォーマンスは優れているものの、システムの選定や実際の導入にあたっては、その背後にある技術的前提と境界条件を慎重に評価する必要がある。 「信頼性」における3層のエンジニアリング境界：システムの選定においては、局所的なメカニズムからプロセス全体の正しさを安易に推論することを避けるため、以下の3つのレベルの「信頼性」を明確に区別しなければならない：
- Schemaと型安全（Type Safety）：Jevの型エラーゼロは、出力空間が事前定義されたSchemaに直接バインドされており、出力側が離散カテゴリまたはスケール数値に直接マッピングされ、インターフェースが構造的にJSONの破損やフォーマットドリフトを排除していることに起因する。これは現時点でメカニズム上保証できる唯一の構造的信頼性である。
- 確率キャリブレーション（Probability Calibration）：RLCDは「より高い信頼度がより高い精度に対応する」ことを学習の最適化目標としており、モデルが確信度を誠実に反映した確率分布を出力することを目指している。しかし、これはモデルの学習目標および公式の主張に過ぎず、現時点では十分な学習の詳細や独立したキャリブレーション曲線は公開されていないため、検証済みの絶対的事実と同等に扱うことはできない。
- ビジネスセマンティクスの正当性（Semantic Correctness）：型のフォーマットがどれほど安全で、信頼度がどのように調整されていようとも、モデルの推論は本質的に統計的確率に属するものであり、ビジネスロジックの判定が絶対に正しいことを保証するものではない。本番環境への導入においては、ユーザー自身が業務に特化した評価ベンチマーク（eval）を独自に構築し、厳格な意思決定閾値と人手による介入・フォールバックメカニズムを設定することが依然として不可欠である。
ベンチマークと環境に関する考察：公式が公表したサブセカンドレベルの遅延は、主に米国西部のデータセンターと同一地域の開発環境でテストされたものであり、多国籍または長距離呼び出しを行うチームにとっては、物理的なネットワーク往復遅延（RTT）が総所要時間のかなりの割合を占めることになる。さらに、超低価格戦略が長期的に持続可能かどうかは商業的な検証が必要であると公式も認めている。また、AstraとFable 5.1を評価の参照軸としていることも、客観的に特定のモデルファミリーの論理的傾向に偏る要因となっている。
アーキテクチャの適用境界：Jevが放棄したのは自由な文字列の生成能力であるため、自由な対話、オープンエンドな質問応答、テキスト作成を直接担うことはできない。高スループットなセマンティクスルーティングゲートウェイ、リアルタイムインタラクションロジック、あるいは決定論的システム内の特徴抽出器として機能させることに適している。
システムアーキテクトにとって、Jevの価値は従来のLLMを置き換えることではなく、インテリジェントアーキテクチャの階層的な進化を促した点にある：極めて高速で安価なシステム1モデルが大半の決定論的なデータフローと境界防御の処理を担当し、高コストで深い思考を得意とする長い思考の連鎖（CoT）を持つ大規模モデルを、最も重要で演繹が求められる専門家レベルのノードに温存するのである。
よくある質問（FAQ）
Jevは既存の大規模モデルを軽量化のために枝刈り（プルーニング）または蒸留しただけなのか？
そうではない。Jevは軽量化された小型モデルでもなければ、従来の意味での自己回帰型の大規模言語モデルでもない。出力空間、サンプラー、学習アルゴリズムのすべてが再構築されており、分類と確率キャリブレーションのタスクに特化しているため、従来のLLMのパレートフロント曲線から脱却している。
公式が一般的な公開学術ベンチマーク（MMLUなど）のスコアを公表しないのはなぜか？
公式は、一般的な公開リーダーボードがプロンプトの過学習を招きやすく、モデルが関数コンポーネントとして本番コードに組み込まれた際の実際のパフォーマンスを反映できないと考えているためである。チームは、ユーザーが自社の業務ワークフローに合わせて評価を構築し、型の安定性とキャリブレーション精度を直接検証することを推奨している。
Jevの学習データはどこから来ているのか？
TypeSafeはデータが社内で独自に作成されたものであるとしており、顧客から渡されたデータを用いて学習することはないと表明している。