Jev-sample

September 17, 2026 · View on GitHub

TypeSafe AI の Jev に対して「同じ判断を、4択で1回聞く」か「前提条件4問に割って1リクエストに並列で入れる」かだけを変えて、正解率・レイテンシ・コスト・confidence の校正を測った実験のコード一式と、生ログ全件です。

2026-09-18 に実行。モデルは jev-latest（実体 jev-1.13.0）。合計 2,320 リクエスト、入力 1,486,076 トークン、$0.0624、エラー0件。

結果の要約

日本語・雑談なしの120シナリオで

  • 4択の Choice を1回投げる（direct）: 48.3%
  • 前提条件4問の Noul に割ってコード側で合成（decomposed）: 98.3%

同じモデル、同じ判断材料。個別の Noul を単独で聞いたときの正解率は 120/120、120/120、120/120、112/120 だったので、条件そのものはほぼ完璧に読めている。詳細は results/RESULTS.md。

何を測ったか

題材は コーディングエージェントのハーネス選択。作業依頼の文面を読んで、4つの実行先のどれに渡すかを決める。

  • haiku_inline 小さく機械的な変更。軽量モデルにその場で直させる
  • opus_subagent 実装方針そのものを選ぶ判断が要る。上位モデルのサブエージェントへ
  • external_harness 複数箇所にまたがるか作業量が大きい。長時間動く外部ハーネスへ
  • ask_user 情報が足りない、または取り消しの効かない操作を含む。依頼者に確認

シナリオは5属性（情報の有無 / 不可逆操作の有無 / 設計判断の有無 / 変更範囲 / 作業量）の全組み合わせから決定論スクリプトで120件を生成し、正解ラベルはルールで確定させています。モデルにも LLM にも作らせていません。各ラベル30件ずつの均衡設計で、日本語版・英語版・無関係な雑談を1〜2文混ぜた版を同じシナリオから作りました。

ファイル

  • scenarios.py — シナリオ生成器。正解ラベルを決めるルールは decide() の10行だけ
  • jev.py — 標準ライブラリだけの API クライアントと、質問文・合成ルールの定義（compose()）
  • run.py — 実験ランナー。JSONL に追記して、既存キーはスキップして再開できる
  • analyze.py — 集計。正解率・混同・校正・閾値ごとの保留率・コスト
  • make_figures.py — 記事用の図版
  • logs/*.jsonl — 生ログ全件（route_mac / route_cloud が各960件、latency_* が各200件）
  • results/RESULTS.md — 結果の全文と、この実験の限界
  • results/analysis_output.txt — analyze.py の出力そのまま

動かし方

Python 3.10 以上。依存パッケージなし（図版だけ matplotlib が要ります）。

mkdir -p ~/.typesafe
printf '%s' 'sk-...' > ~/.typesafe/key
chmod 600 ~/.typesafe/key

python3 scenarios.py | head -3          # シナリオを見る
python3 run.py latency --site mac --n 50
python3 run.py route   --site mac --all --workers 8
python3 analyze.py mac

--site はログの名前を分けるだけのラベルです。route --all$ は 120シナリオ \times 日英 \times 雑談あり/なし \times 2方式 = 960リクエスト。途中で止めても、同じコマンドで続きから走ります。$TYPESAFE_API_KEY を環境変数で渡してもかまいません。

自分のタスクに移すとき

書き換えるのは3か所です。

  1. scenarios.py の属性と decide() — 自分のドメインの判断ルール
  2. jev.py の CHOICE_CRITERIA_* と NOUL_* — 質問文
  3. jev.py の compose() — 返ってきた確率をラベルに変える合成ルール

run.py と analyze.py はそのまま使えます。

この実験の限界

  • decomposed の4問は、シナリオ生成に使ったルールと同じ分解です。 分解がタスク構造と一致している理想ケースなので、有利になるのは設計上そうなります
  • 質問文の長さが揃っていません。 direct の質問部分が325字、decomposed が664字（入力トークンで 640 対 854）。条件を割った効果と、説明を厚く書いた効果は分離できていません
  • 合成シナリオであって本番ログではありません
  • n=120 のタスク1つです。他ドメインで同じ比になる保証はありません

詳しくは results/RESULTS.md の末尾を読んでください。

ライセンス

MIT。ログとシナリオも同条件で使ってかまいません。