Jev をどこに置くか

Jev は「文章を書かず、選ぶ・採点する・はい/いいえの確率を返す」ことだけに絞った、判断専用の高速モデルです。life の秘書ハーネスは、振り分け・公開可否・モデル層の選択といった小さな判断のほぼすべてを、LLM が Markdown の規則を読んで決めています。ここが Jev の入りどころです。ただし、お金・税・契約のような人生の意思決定そのものは Jev に渡さず、Opus に残すのが妥当だと考えます。理由は後半で数字とともに書きます。

観測日: 2026-09-30。外部情報は Web の一次情報・二次報道・独立検証記事で、出典を本文と末尾に分けて書きます。life 側の事実は棚卸しで読んだファイルの行番号つきです。

Jev とは何か

特色を一言で

TypeSafe AI が 2026-09-15 に出した「System One モデル」という新しい種類の第 1 号です。名前は、カーネマンの「速い直感の思考（システム 1）」から取っています。次のトークンを 1 つずつ書いていく LLM とは違い、状態（テキスト）と質問を受け取り、型の決まった答えと確率を 1 回の処理で返します。公式は「frontier-intelligence function call: unstructured state in, typed probabilistic decisions out」と説明しています。

3 種類は 1 回の呼び出しに混ぜられ、質問同士は互いに独立に評価されます（ドキュメントには「質問を増やしても応答時間はほとんど変わらない」とあります）。1 つの状態に対して独立な質問を並べる「ファンアウト」が想定された使い方です。

仕様の数字（出典つき）

既存の LLM とどう違うか

「193 倍速く 445 倍安い」をどう読むか

この数字はベンダー自身のワークフロー評価で、独立には確かめられていません（Tom's Hardware の記事本文は取得できず、根拠となるベンチマークは読めていません）。ベンダーは自分で「実世界の上限側」と書いています。独立検証の記事では、同じ 3,080 件で Jev の中央値 245ms、比較した 80B モデルは 249ms とほぼ同じでした。速さの優位は、比べる相手が「長く考える大きなモデル」のときに出る数字で、軽いモデルとの比較は未測定です。life で意味があるのは倍率ではなく、自分のハーネスで測った応答時間と精度です。

独立検証で見えた限界

Towards Data Science の検証記事（Banking77 の銀行問い合わせ 3,080 件、比較相手は Qwen3-Coder-Next-80B）から、life の設計に効くものだけを選びます。

life ハーネスの現状

棚卸しの結果（読み取りのみ、2026-09-30）です。行番号は表に付けています。

実測の数字（2026-09-16 の運用調査より）

人生の意思決定に Jev を使わない理由

ご提案の「意思決定の領域だけ Jev」は、意図はよく分かります。判断のコストを下げたい、という発想ですね。ただ、life の規則がすでに答えを出しています。モデル層の表では、判断を間違えたときのコストが非対称な領域（お金・税・契約・住宅・行政手続・事業の Go/No-Go）は Opus と決めています（.claude/rules/model-routing.md:41-46）。Jev の特性と突き合わせると、次の 4 点が噛み合いません。

• 理由を出せない。判断の根拠を後から読み返す用途（asset・myhome・spec-guard の出典つき判断）に合わない
• 算術・日付・個数が苦手。税・ローン・期限の判断はここが核心
• 範囲外でも 0.99 で答える。「どの選択肢でもない」が最も危険な場面（想定外の制度・契約）で沈黙しない
• 二段構えは悪化した。独立検証で、Jev 高確信度なら採用・低ければ LLM に回す構成が単独より悪くなった

整理すると、Jev は「判断のための下ごしらえと門番」、Opus は「判断そのもの」という分担です。LangChain の解説も同じ分担を勧めています（「open-ended reasoning and generation は LLM、fast structured decisions along the way は Jev」）。

組み込み案

効果・リスク・「Jev でなくてよいか」の 3 点で並べます。「先に決定論」は、Jev を入れる前にコードだけで足りるものです。

組み込み後の構成

発話
 └─ フック（手元）: 禁止語・危険な操作の正規表現 ← 常に先に通す床
      └─ Jev（外部）: 領域の Noul ×N ＋ 急ぎ度 ＋ 行政手続か
           └─ 注入: 「領域: asset 0.93 / myhome 0.71 / 行政手続 0.88 …」1 行（助言）
                └─ 秘書（LLM）: 起動する専門を決める ← 最終判断は LLM
                     ├─ PreToolUse フック（手元）: Agent に model があるか検査
                     ├─ 専門エージェント（Opus / Sonnet / Haiku）
                     │    └─ 検索: LIKE → 剪定 → Jev が関連度を採点 → 上位だけ読む
                     └─ 結果は原文のままファイルへ → Jev が持ち越す断片を選別（再開メモ）

決定論の検査を先に、Jev の確率を助言として後に、判断は LLM に、という並びです。Jev が落ちても遅くても、フックが 0 を返して何も注入しないだけで、会話は止まりません（今の在庫フックと同じ、常に終了コード 0 の作り）。

導入の進め方と、合格の条件

未確認のことは、そのまま実測の作業に落とします。合格の値は提案の初期値で、最初の実測を見て決め直します。「落ちるべきときに落ちる」条件（範囲外・機微・障害）を先に置きます。

1 と 2 は Jev の契約とは無関係に価値があるので、先に進められます。3〜6 は早期アクセスの鍵が手に入ってからです。

費用の見積もり（単価からの算術）

公式の単価 $0.042/100 万トークン（入力のみ）から計算した値で、実測ではありません。領域の定義を含めて 1 回 2,000 トークンとすると、1 回 約 $0.000084、1,000 ターンで約 $0.084 です。一方、秘書 SKILL.md の 16,449 トークンを Opus の入力単価 $5/100 万で読むと 1 回約 $0.082（キャッシュが効けば下がる）。ただしフックでは秘書 SKILL.md を読まない選択はできないので、これは節約額ではなく、単価の桁の比較です。秘書の分割（運用調査の推奨 2）と組み合わせて初めて、載せる量が減ります。

出典