Basedonthepolicy,{“refund”:true}
LLMは、大量の文章から学んだ言語モデル。説明文や、形式を指定したデータも作れる。
JEV / SYSTEM ONE
判断を、ソフトウェアの部品にする。
「これは返金の依頼か」「誰に回すか」。
Jevは、こうした問いに決まった形式と確率で答えるAI。
その確率を、どこまで仕事の判断に使えるのか。
判断の材料（STATE）返金をお願いできますか？
決まった形式の答え返金を求めている確率0.800.80 = 80% ／ 説明用の例
01 / ORIGIN
会話が上手なAIを、
仕事を動かすAIへ。
“Models have been superhuman at chat for years, so where is all the automation?
Diogo Almeida / TypeSafe 創業者趣旨：会話はこれほど上達したのに、なぜ仕事の自動化は進まないのか。
- InstructGPT 論文Diogo Almeidaは共著者。OpenAIで、人の指示に沿って答えるモデルを研究。
- 非公開で2年間開発開発期間はTypeSafeの公表による。プログラムが判断を受け取る仕組みを設計。
- Jevの早期提供を開始判断と確率を返す「System One」モデルの第1弾。人間の直感になぞらえた名称で、提供はまだ初期段階。
会社発表と論文記載に基づく経歴。利用経験を示すものではありません。
02 / THE BITTEREST LESSON
最重要なのは、
何を学ばせるか。
TASK›DATA›COMPUTE›ALGORITHMS
課題、学習データ、計算資源、計算方法の順で考える。
TypeSafeが重視するのは、文章の上手さだけでなく、「80%」と予測したら実際に約8割当たるように学ばせること。
これは TypeSafe の設計哲学であり、一般に証明された定理ではない。
03 / SAME TICKET, DIFFERENT INTERFACE
同じ返金の問い合わせでも、
欲しい答えは文章とは限らない。
「飛行機が欠航しました。返金してもらえますか？」
NOUL返金依頼？.80
CHOICE担当は？請求担当
SCORE苛立ちは？1.4
開発者が問いと回答形式を決める。Jevは複数の独立した問いに、判断と確率を返す。
上の2カラムは説明用の例。表示値・アニメーションは実測ではありません。
汎用LLMでも、生成を省いて判断用の確率を返す仕組みは作れる。
Jevでは、確率をどう学ばせるかと、どんな問いを使えるかに注目したい。
04 / THREE PRIMITIVES
「どれ？」「どの程度？」「YesかNoか？」
プログラムから呼ぶための基本的な問いを、TypeSafeはprimitive（プリミティブ）と呼ぶ。
Choice
どれ？候補の中からどれを選ぶか。例：問い合わせをどこへ回す？
請求担当.74
アカウント.18
技術担当.08
Score
どの程度？順序のある段階で評価する。例：顧客の苛立ちはどのレベル？
0 · .101 · .402 · .501.4
Noul
Yes / No？条件が当てはまる確率を返す。例：返金を明示的に求めている？
YES.80
0 ← probability → 1説明用の例。実測データではありません。Scoreの1.4は各段階の確率を重みにした平均（期待値）。confidenceは後の「較正」の画面で説明します。
04-A / SemIfは確率をどう取り出す？
文章にする前の「候補の点数」を、
判断に使う。
LLMは、単語や文字の一部にあたる「トークン」を順に選び、文章を作る。SemIfはその直前の計算結果を利用する。以下はSemIfの仕組みで、Jevの内部方式を説明したものではない。
候補ごとの点数
logits（ロジット）
次のトークンの候補ごとに、モデルが計算した点数。値は負にもなり、そのままでは確率ではない。
SemIfでは「A＝必要」「B＝不要」「C＝情報不足」のように、答えを1トークンの文字に割り当てる。点数を確率に直す
softmax（ソフトマックス）
点数を、合計が1になる正の値に変換する計算。高い点数ほど、大きな確率になる。
SemIfはA・B・Cなど、指定した選択肢の点数だけに適用する。選択肢の間でどれを選びそうか比較するために使う。文章を待たず、確率を使う
「答えはBです」という文章を作らせる必要がない。入力をモデルに1回通したら、選択肢ごとの確率を取り出して終わる。
複数の問いでは、共通の入力を読んだ計算結果を再利用し、まとめて処理する。softmaxは数値を確率の形に整える計算。その数値が現実の正答率と合うことまでは保証しない。
04-B / 答えの一致と確率の一致
選ぶ答えが同じでも、
確率の付き方は違う。
確率が最も高い選択肢を選ぶ操作が argmax（アーグマックス）。今回は、JevとSemIfが同じ答えを選んだかを見るために使う。.90という値を取り出すのではなく、「不要」という選択肢を取り出す。
実測（2026-09-20、Claude が手元で測定）／ 変更チケットが必要かを判定| モデル | 必要 | 不要 | 情報不足 | 選ぶ答え（argmax） |
|---|---|---|---|---|
| Jev | .08 | .90 | .02 | 不要 |
| SemIf / 4bit | .060 | .937 | .003 | 不要 |
今回試した小さな比較では、選ぶ答えはすべて一致した。ただし、表のように候補ごとの確率の配分（分布）は違う。
答えを1つ選ぶだけならargmaxで足りる。人に確認するかどうかまで確率で決めるなら、確率の数値を信頼できるかが問題になる。
SemIfでは、別の曖昧な例で選択肢の順序を反転すると「情報不足」が .003 → .119 に変化した。最高確率が高いことだけで、正しさは保証できない。
05 / TRAINING OBJECTIVE
何を良い答えとして学ばせるか。
Jevは、判断の確率を重視する。
較正は、予測の確率と実際の割合を近づけること。今回、その良さの直接比較は未実施。実測（2026-09-20、Claude が手元で測定）今回の比較では、汎用モデルを使うSemIfと、最も確率の高い答えは一致した。別の公開評価では、一部の102件で精度は Jev .883 / SemIf（BF16）.845。BF16は手元の4bitより高い保存精度。ただし、この精度比較だけでは較正の良さは分からない。
RLHF人が好む応答を学ぶRLVR正否を検証できる課題で学ぶRLCD判断の確率が現実と合うように学ぶ
いずれも、言語を学んだモデルを追加で訓練する方法。RLCDはTypeSafeによる説明で、学習方法の詳細や内部構造は公開されていない。
06 / CALIBRATION
「80%」と言った予測は、
本当に8割当たっているか。
p = .80→≈ 80 / 100
pは確率を表す記号。「返金の依頼だ」という予測に .80 を付けた案件を100件集める。実際に約80件が返金の依頼なら、確率と現実の割合が合っている。
- 個別案件の正しさを保証しない
- この100点は説明用で、測定結果ではない
実測（2026-09-20、Claude が手元で測定）同じ曖昧な入力を8回送ると「いいえ」の確率は 0.80–0.88 に動いた。処理を分ける境目（閾値）を .85 にすると、同じ入力でも進む先が変わる。.85は説明用の例。
confidenceとは？Choice / Scoreでは、確率の配分全体から求める補助指標。最大の確率と同じ数値ではない。Noulにはこの指標は付かない。confidenceも、個々の答えの正しさを保証する値ではない。
07 / CODE STAYS IN CONTROL
コードで進める工程に、
AIの判断を差し込む。
CODE決めたルールで確認金額・権限・条件・実行確認
→JEV意味を読み取る判断決まった形式で確率を返す
→CODE閾値・分岐誤りの影響に応じて分岐
→LLM / HUMAN生成・例外への対応LLMで文章や計画、人が確認
0処理を分ける境目 .80（例）1
ROUTE人が確認する閾値未満のため自動処理しない
説明用の例。閾値も入力も架空で、実測・推奨値ではありません。支払い処理は行いません。境目の近くは人が確認するなど、確率の揺れを考慮する。
08 / ARCHITECTURE
次に何をするか。
AIに選ばせるか、コードで決めるか。
LLM agent
モデルが次を選ぶ↔AI-powered software
コードが手順を決める
モデルが次を選ぶ↔AI-powered software
コードが手順を決める
09 / COMPANY EVALUATION
自社評価の速さを、
そのまま実務に当てはめない。
193.6× 高速 / 444.6× 低コスト
TypeSafeによる自社評価。4つの業務手順で、処理のつながりを揃えて比較した。
- 同社自身が、実際の改善幅はここまで大きくない場合があると注記
- 比較基準は高性能LLM 2種の予測の平均。人が確認した正解データではない
- LLM側は確率を答えさせる追加の仕組みを使う。その処理時間も含む
- どの仕事でも同じ倍率で速く、安くなるわけではない
実測（2026-09-20、Claude が手元で測定）Jevの利用量報告にも「出力トークン数」がある。Yes/No判定は1問=21 / 4問=72 / 6問=106、8択では73。接続サービスVercel AI Gatewayの報告値。通信込みで1問 586ms / 6問 478–519ms。何をトークンとして数えているかは非公開。
訂正：数が報告されることと、料金がかかることは別。TypeSafe公式は出力無料と説明。実用では、確率の品質と、1回の呼び出しで何問答えられるかを比べたい。
10 / WHERE IT FITS
問いを絞って、繰り返し判断する。
Jevはそんな仕事の候補になる。
担当へ振り分けるChoice
段階評価するScore
照合するNoul / Choice
実測（2026-09-20、Claude が手元で測定） 測定は1日だけで例数も少ない。SemIfは4bitに軽量化したモデル、日本語は各1例のみ。
「System One / Two」は直感的な判断と熟考になぞらえた呼び方。人間の思考と同じ仕組みという意味ではない。
11-A / DISCUSSION · 既存システムを見直す
陶山が今、洗い出しているのは、
LLMの前後に足せる小さな判断。
既存のAIシステムの実コードを確認し、法務・債権管理・事業計画のAIから候補を抽出。現在は設計・評価準備の段階。Jev導入による改善効果はまだ測っていない。
「基準を満たすか」を項目ごとに確認
LLMが作った回答を、別のLLMが採点している。その評価をJevでも行い、人や既存の評価とどこで食い違うか調べる案。
最終的な法的判断を任せる話ではない。まず評価用データで試す。その警告は、元の数字と話に合っているか
会計やExcelのレビューで出た指摘を1件ずつ確認する。会話で解決済みの話や、実際の数値に根拠がない指摘を見分けたい。
計算の間違いはコードで確認。Jevには意味の取り違えを問う。会話から取り出した金額・日付を照合
LLMが抽出した金額は、会話中の別の金額ではないか。入金予定日は明記されているか。項目ごとにJevへ問い、結果を記録する案。
まず既存処理と並走し、処理結果は変えずに比較する。これを「シャドー評価」と呼ぶ。話したい問い：「文章を作るAI」に、確認や振り分けまでまとめて任せている箇所はどこか？
11-B / DISCUSSION · 新しい事業の入口
「何でも判断するAI」から、
誰の、どの確認作業に絞るか。
Flow Studioで、最初に顧客へ届ける狭い用途（wedge）を検討中。Jevが判断を担う中心技術になれるか、既存の方法と比較して確かめる。
例外のある返信を、責任者に回す
複数社のAI業務を運用する代理店向けの案。顧客ごとのルールと返信案を照合し、「例外的な値引きを約束していないか」などをJevに問う。コードが確認先を決め、人が承認する。
Jevが担えるのは、毎回の意味判断。承認画面を作るだけで買ってもらえるかは、別に確かめる必要がある。曖昧な商品名を、カタログの候補と照合する
見積依頼から取り出した商品名を、承認済みの商品候補と照合する。品番の完全一致はコード、表記の違いや曖昧な照合はJevの候補。判断しきれないものは人に戻す。
公開募集を確認して提案文を準備した段階。価格は承認済みデータから取得し、AIに作らせない。現在の方針：汎用サービスの先行開発を見直し、まず業務1本の比較テストと実装を納品する案へ。営業は未送信・未受注。Jevの採用も未確定。
話したい問い：Jevを呼ぶことではなく、どの確認作業を減らすことにお金を払ってもらえるか？
11-C / DISCUSSION
判断を安く呼び出せるなら、
どの確認作業から試す？
既存システム
回答・警告・抽出値の確認新しい事業
返信や商品照合の確認先次に測ること
見逃し・確認時間・総費用
回答・警告・抽出値の確認新しい事業
返信や商品照合の確認先次に測ること
見逃し・確認時間・総費用
番組側の仮説：判断が安くなれば、これまで省いていた確認を増やせる。
まず業務1本で、既存の処理と並べて試す。
続けて話す問いオープンモデルで同じ形の判定が 0.23–0.28 秒で返るなら、
何にお金を払う？ 確率の信頼性・問いの使いやすさ・運用の手間・日本語の精度
実測（2026-09-20、Claude が手元で測定）M4 Pro / 4bit の小規模測定。日本語の優劣は未検証。