概要 / concept

System One

System One モデルは、ソフトウェアがそのまま使える「速くて構造化された判断」を返すための AI モデルのクラスです。Jev は TypeSafe のフラッグシップであり、最初の System One モデルです。

名前の由来
LLM との違い
3つのアーキテクチャ
学習方法 RLCD
較正とは
ワークフローの中での位置

名前の由来：速い思考と遅い思考

「System One」は、ダニエル・カーネマンが『ファスト＆スロー』で広めた概念から来ています。人の思考には、速くて直感的なシステム1と、遅くて熟慮的なシステム2がある、という考え方です。

Jev が担当するのはシステム1の側——「十分な文脈を与えられた詳しい人なら、数秒で下せる判断」です。長い推論が必要な問いは、小さな判断に分解してコードで組み合わせるか、推論モデル（システム2）に任せます。

役割分担

system 1速い・直感的「このメッセージは緊急か？」
「どの部署の案件か？」
→ Jev の担当

system 2遅い・熟慮的「このメッセージを分析して最善の対応方針を決めよ」
→ 分解するか、推論モデルへ

目安：その判断は、詳しい人が1秒〜数秒で下せるか？下せないなら質問を分解する合図です。

LLM との違い

入力は同じ自然言語。違うのは出力の契約です。

	LLM（チャット／推論モデル）	System One（Jev）
入力	自然言語のプロンプト	自然言語を含む state ＋型付きの質問
出力	生成されたテキスト	型付きの判断と確率分布
答えの範囲	自由（スキーマ外の値も出うる）	あなたが定義した選択肢・レベルの中だけ
不確かさ	文面からは分からない。自信ありげに間違えることがある	確率と confidence として数値で返る
複数の判断	1プロンプトに詰めると互いに干渉し、文脈が劣化しやすい	質問ごとに独立・並列。足しても他の結果は変わらない
やらないこと	—	返信文の作成、コード生成、推論過程の説明
向いている場所	人との対話、文章生成、長い推論	無人で大量に回る自動処理の中の判断

3つのソフトウェアアーキテクチャ

System One は「エージェント」を作るためのものではなく、AI 搭載ソフトウェアを作るためのものです。コードを生成したり、次の行動を自分で選んだりはしません。

従来のソフトウェア

if / else

関数・ルール

DB 参照

信頼できるプリミティブを積み上げた巨大な決定木。確実だが、非構造データの「意味」は扱えない。

LLM エージェント

LLM が次の手を決める↻ ループ

ツール実行

結果を読んでまた決める↻ ループ

人が見守っているうちは強力。ただしループのたびに脱線の機会が増える。

AI 搭載ソフトウェア

コードが制御フローを持つ

判断が要る所だけ Jev原子的で制約された問い

コードが答えを合成して実行

決定的な仕事はコード。モデルは「プログラム可能な常識」が要る場所にだけ現れる。

学習方法：RLCD（較正された判断のための強化学習）

事前学習済みの言語モデルは、これまで主に2通りの方法で仕上げられてきました。TypeSafe は3つ目の道を加えています。

RLHF は InstructGPT / ChatGPT の学習に使われた手法で、TypeSafe 共同創業者の Diogo Almeida 氏はその共同発明者の一人です。

RLCD の出力契約

モデルはテキストを生成しない
判断と確率を返す
確率が高いほど、その答えが正しい見込みが高くなるよう最適化されている

なぜ RLHF では足りないのか

RLHF は「人が好むこと」を言うようにモデルを鍛えます。チャットには最適ですが、人にとって説得力のある出力と、無人の自動化で信頼できる出力は別の最適化目標です。また特定の文体に確率が偏る「モード・ドロッピング」も起こします。

Machine Native Intelligence TypeSafe の賭けは、大規模な AI 自動化では人との対話は1%程度にとどまり、99% は機械同士のやり取りになる、というもの。だから「読んで心地よい応答」ではなく、構造・信頼性・可観測性・テスト容易性・速度・一貫性・低コストというソフトウェア的な性質を設計目標にしています。標語は “Building prod, not God”。

「較正されている」とは

よく較正されたモデルでは、多数の予測を集めたときに、言った確率と実際に起きた割合が一致します。

確率 0.2 を付けた事柄は、およそ 20% の割合で起きる
確率 0.8 を付けた事柄は、およそ 80% の割合で起きる
確率 1.0 を付けた事柄は、100% 起きる

これが成り立つから、確率を「しきい値」としてコードに書けます。0.9 以上なら自動実行、という設計が意味を持つのは、0.9 が本当に 9割を意味するときだけです。

注意較正は予測の集団についての性質で、個々の答えの正しさを保証するものではありません。型付きの出力が保証するのはインターフェースであって、真実ではない。対象ドメインで必ず自分のデータで検証してください。

概念図：較正曲線

対角線に近いほど「言った確率どおりに当たる」。下に垂れる曲線は、0.9 と言いながら実際は 6割しか当たらないような過信を表します（実測値ではなく説明用の概念図）。

ワークフローの中での位置：返金リクエストの例

Jev は単体で完結するものではなく、普通のソフトウェアの中に「判断の部品」として埋め込みます。

step 1 · codestate を組み立てる顧客のメッセージ、該当する取引、返金ポリシーをまとめる

step 2 · jev独立した質問を同時に聞く返金を求めているか？ / 二重請求を示す証拠か？ / ポリシーは返金を支持するか？

step 3 · code決定的なチェックと合成金額上限などのルールと組み合わせ、実行するかレビューに回すかを決める

呼び出しは SDK の system_one() か POST /v1/systemone。model フィールドでモデルを選び、ドキュメントの例と SDK の既定値は jev-latest です。次は State と質問設計へ。