Jev入門：文章生成の外側にある、型付き意思決定

何を学ぶのか

Jev は「もっともらしい文章を返す相手」として使うと、その強みが消える。TypeSafe の公開ドキュメントでは、Jev を System One の旗艦モデル、すなわち状態と型のある質問を受け取り、ソフトウェアが消費できる構造化回答と確率を返すモデルとして位置付けている。公式の概要を読むと、狙いは会話の置換ではなく、プログラムに欠けている意味的な小判断を部品化することだと分かる。

例えば問い合わせを受けるシステムなら、文字列一致で決められる「契約プラン」はコードで扱い、文章の含意を読む必要がある「緊急度」「どの候補の意図に近いか」だけを判断器へ渡す。返った値は UI に文章として貼るためのものではなく、次の関数、検索、レビュー・キューを選ぶ入力になる。この境界があるため、結果を再利用、比較、監査できる。

1. 1観測された状態
2. 2候補をコードで列挙
3. 3型付きの狭い質問

1. 1狭い質問
2. 2分布と回答
3. 3閾値・権限をコードで確認
4. 4実行／保留／人へ

メンタルモデル：意味はモデル、責任はコード

System One に渡す state は「いま判断に必要な事実」である。本文、チケットの履歴、候補一覧、現在のポリシー、対象の ID を JSON の名前付きフィールドにする。state に無い候補は選べない。したがって候補生成はまず決定論的に行う。全文検索、正規表現、DB の権限フィルタ、在庫照会、日時計算は既存コードの仕事であり、ここをモデルに再推論させる理由はない。

質問は一つの意味に絞る。「この文書は顧客に返金を要求しているか」と「返金額はいくらか」は別問題で、後者は候補文字列を正規表現で抽出してから選ばせる方が検証可能である。一方、「この事故報告を安全・品質・物流のどの担当へ送るか」は、限定された選択肢に対する意味的な分類なので一つの判断として自然だ。

重要なのは型が真実を保証しないことだ。型はインターフェースを保証するだけで、state の欠落、曖昧な基準、古い方針、モデル誤りは防がない。だから「モデル出力 → 実行」を直結しない。ID の存在、権限、金額上限、最新状態、冪等性をコードで確認してから、可逆な低リスク操作だけを自動化する。

最小設計の手順

1. 画面または API が最終的に何を選ぶかを一文で書く。例は「問い合わせを 6 種の既存ハンドラに送る」。
2. 選択肢をコード上の enum として固定し、unknown または needs_review を最初から含める。候補集合を後から言語モデルに発明させない。
3. 各選択肢の意味、除外条件、境界例を criteria に書く。質問 ID は実装識別子であってモデルには意味を伝えないため、指示本文は単独で読める必要がある。
4. state の各フィールドを「観測事実」「ユーザー入力」「推測」に分ける。推測を事実のように混ぜると、誤りの原因が追えない。
5. 回答、分布、入力のバージョン、質問のバージョン、後続の実行結果を保存する。個人情報や秘密値は目的に必要な最小限にし、API キーは必ずサーバー側に置く。

何が変わるか、何が変わらないか

生成 AI の一回の自由文プロンプトでは、出力をパースし、候補外の値を弾き、失敗理由を後追いする実装が増えやすい。Choice/Score/Noul のような小さな質問に分割すると、アプリの契約が先に決まり、重みや閾値をコード側で変えられる。複数の独立質問を同じ state でまとめて投げる設計も可能で、公式の parallel questions cookbook はその計測例を公開している。ただしその数値は特定デモの値であり、自分の遅延・費用・精度を約束しない。

代償もある。候補と基準を書く作業は必要で、選択肢が漏れれば正しく選べない。質問を細かくし過ぎれば関係が失われ、粗過ぎれば評価不能になる。意味のある比較対象が無い創作や長文説明には、生成モデルや人間編集の方が適する。Jev を「判断器」に限定することは弱点ではなく、失敗面を小さくする設計判断である。

演習：安全な読書メモ分類器

ローカルの架空メモ 30 件だけで、research、implementation、idea、needs_review を選ぶ分類器を設計する。最初は実行を伴わせず、表示用タグだけ変える。各ラベルを 10 件ずつ人が付け、候補外の内容、複数ラベルに見える内容、情報不足の内容を必ず含める。次節の confidence を使う前に、入力と質問を固定して、誤りを「候補不足」「基準不足」「state 不足」「意味の取り違え」に分けて記録しよう。これが後で閾値を動かすための基準線になる。

擬似 API を避ける：オフラインで実行できる境界コード

SDK 呼び出しを「たぶんこうだろう」という形で載せると、学習者に架空の API を実装させてしまう。ここでは公開 JavaScript SDK の型一覧を参照先に残しつつ、ネットワークも API キーも不要なオフライン実行可能コードだけを示す。これは Choice のモデル推論を代替しない。固定 fixture を受け、モデル境界で必ず必要な候補検証と副作用分離をテストするコードである。実際の request payload は導入時の公式 quickstart と現行 SDK 型定義で確認する。

// offline-fixture.ts: tsc/Node で実行できる、API を呼ばない境界テスト
const candidates = ["research", "implementation", "idea", "needs_review"] as const;
type Label = (typeof candidates)[number];
type ChoiceFixture = { value: string; probabilities: Record<string, number>; confidence: number };
function toDisplayTag(fixture: ChoiceFixture): Label {
  if (!(candidates as readonly string[]).includes(fixture.value)) {
    throw new Error("invalid Choice label");
  }
  return fixture.value as Label;
}
console.assert(toDisplayTag({ value: "research", probabilities: {}, confidence: 0.9 }) === "research");
// A fixture with value "invented" must throw; a real `needs_review` value remains valid.

この例でも入力長、保存期間、本人の同意、アクセス制御は別に実装する。候補がコードの tuple と UI の表示で食い違うと、型付き出力でも事故は防げない。needs_review を単なるエラー表示にせず、理由と入力バージョンを残して、人が候補追加・質問修正を判断できるキューにする。なお TypeSafe の現在の公開 docs/skill では yes/no primitive を Noul と呼ぶ。本稿はその名称を使い、将来ドキュメントで Predicate 等の名称・API が変更された場合は、更新ノートで発表日と取得日を分けて差し替える。

評価用データの作り方

CSV または JSONL を一行一ケースとし、id、input_text、expected_label、allowed_labels、risk、annotator_a、annotator_b、adjudicated_label を持たせる。二人の注釈者が一致しない行は消さず、曖昧さとして保存する。学習済みモデルを改良するためのデータではなく、質問・候補・運用を評価するためのデータである。時系列または作成者単位で分け、同じ文章の要約と原文が別 split に入らないようハッシュで検査する。

失敗例を先に用意する。「実装していないのに将来計画を具体的に書いた」「研究メモだが実装の TODO を含む」「本文が空で題名だけ」の三種は、単純なキーワード分類が誤りやすい。出力を見てから正解ラベルを変えることは評価の漏洩なのでしない。変更ごとに新しい holdout を残し、旧セットの点数だけで前進と判断しない。

2024〜2026年の文脈: 構造化出力はインターフェースであり真実判定ではない

OpenAIのStructured Outputs発表（2024-08-06）はschema適合を明示的なAPI目標にしました。有効なenumは応答がインターフェースに合うことだけを示し、選んだlabelが真実、完全、認可済み、最新根拠に基づくことは示しません。RouteLLM（2024-06-26投稿）はroutingを学習された費用／品質選好問題として扱います。評価設計の歴史であり、自動的なprovider置換を追加する理由ではありません。

TypeSafeの2026-09-15 System One/Jev記事はearly access、RLCD、parallel samplingをベンダー主張として説明します。これを限定実験に変えます。4候補labelを固定し、state欠落・矛盾を含む敵対的holdoutを作り、型付き判断を決定論的ruleとブラインド人手labelに比較します。コードは契約外labelを拒否しなければなりません。needs_reviewは列挙候補として実際に返った場合だけ有効で、壊れた出力を黙って置換するものではありません。

2026-09-18のLocalLLaMAスレッドはarchitectureとinterfaceを議論しています。未検証のコミュニティ議論であり、architectureの同一性や新規性の証拠ではありません。直近の境界は、9月記事を2026-10-04に確認したことです。アカウント可用性、benchmark、独立性能結果は測定していません。

意味判断の前に決定論的な事実を置く

質問を書く前に境界表を作ります。process exit code、署名済みrole、現在の公開権限、既存FAQ ID、quotaはコードが所有する事実です。Jevの前に検証し、欠ければ名前付き原因で失敗させます。「許可済みFAQ intentのうち、曖昧な表現に最も近いものはどれか」がより狭いJevの問いです。利用者入力の指示は公開権限を付与したり、roleを変えたり、candidateを追加したり、決定論的拒否を上書きしたりできません。

offline labではinvented labelを契約違反fixtureとして試し、throwすることを確認します。needs_reviewは有効な列挙出力として別に試験します。前者を後者に写像してはいけません。黙った置換はprovider/schema不一致を隠し、後のincidentを診断不能にします。保留項目ごとにcandidate tuple版、question版、state hash、policy結果を記録します。reviewerはモデルに新しい能力を与えずcandidate網羅性を修正できます。