改めて Jevとは何か？判定専用AIを2週間・約2,900回使って分かった、業務での向き不向き

Last updated at 2026-10-09Posted at 2026-10-09

はじめに

Jev は、用意した質問に「はい・選択・段階」で答え、その確率だけを JSON で返す判定専用の AI です。文章は生成しません。

私は Jev を 2026-09-28 から約2週間、自分の業務と Claude Code に組み込みました。API の呼び出しは約2,900回で、費用は合計約19円です。前半で Jev とは何かを整理し、後半で使ってみた結果をまとめました。先に結論です。

向いていたのは、要件1件ずつの「ある・無い」と、複数案の順位付けです
向かなかったのは、ツール結果を削る判断と、依頼の行き先の判断です
費用は約2週間で合計約19円でした。1回あたり1円の100分の1以下です
数字の検算と、送信・削除などの最終判断は、Jev に任せていません

Jev とは何か

Jev は、米国の TypeSafe AI が 2026年9月15日に公開したモデルです。同社はこの種類のモデルを「System One Model」と呼び、Jev はその最初の公開モデルにあたります。名前は、経済学者の William Stanley Jevons にちなみます。

呼び出しは、判断材料の state と質問の questions を1回の HTTP リクエストで送るだけです。質問の型は次の3つから選びます。

型	聞けること	返る値
noul	はい・いいえ	「はい」の確率（0〜1）。confidence は返らない
choice	選択肢から1つ選ぶ。最大255択	選んだ答え・confidence・全選択肢の確率
score	段階で評価する。基準は低い順の配列	段階に応じた連続値・各段階の確率・confidence

1回に送る質問の数は自由で、全質問が並列で処理されます。質問を増やしても速度はほぼ変わりません。state は文字列か JSON で、画像は送れません。

choice と score の答えには、confidence（信頼度）が付きます。確率の分布から計算され、答えを集団で見たときに合うよう校正された値です。1件ごとの答えの正しさは保証しないので、人に戻す閾値は使う側が決めます。

私は choice の信頼度が0.50未満なら、画面に「人が決める」と表示しています。noul には信頼度が無いので、確率0.30〜0.70を「分からない」として人が見ます。影響の大きい送信や削除には判定を直結させず、最初は結果を表示するだけにしました。

料金は入力トークンにだけ掛かり、出力トークンは無料です。約2週間の実測は次の表のとおりで、1回あたり約0.0066円でした。

項目	値
料金	入力100万トークンあたり0.042ドル
呼び出し回数	2,870回（質問7,165問）
費用合計	18.846円
応答時間の中央値	0.22秒

LLM との違いを「完了報告のチェック」で比べる

LLM＋AI エージェントでは AI が次の手を選び、Jev＋コードでは AI が確率を返して次の手はコードが選びます。例は、私が毎日使っている「Claude Code の完了報告に、検査の証拠があるか」という判断です。

Claude Code は作業を終えると「修正しました」と報告します。ところが、ファイルを変えたのに lint もテストも走らせないまま、完了と報告するターンがあるのです。私はこのターンだけを止めたいと考えました。

LLM に任せるなら、最終メッセージと作業の履歴を渡し、「検査の証拠はあるか、無ければどうするか」を聞きます。LLM は履歴を読み、次の手順を文章で返します。

（説明用の模式例）
1. 最終メッセージは「修正しました」と、作業の完了を報告している
2. 履歴を見ると、ファイルを3件変えたあとにテストを実行していない
3. 検査が足りないので、テストを1つ実行してから報告し直すよう求める

この方式では、何を確かめ、どこで止め、次に何をさせるかを LLM が文章の中で決めます。柔軟な反面、止める線がどこにあったかは、返ってきた文章を読まないと分かりません。

Jev の方式では、数える仕事と聞く仕事と決める仕事を分けます。変更したファイルと検査コマンドの数はコードが履歴から数え、Jev には「最終メッセージは、作業が完了したと報告しているか」の noul 1問だけを聞きます。返るのは、質問と同じ名前の下に入った確率の数字です。次の JSON は 2026-10-09 に実際に送った1問の応答で、質問は「このコマンドは元に戻せないか」ですが、返る形は完了報告の質問でも同じです。

{
  "model": "jev-1.13.0",
  "answers": {
    "irreversible": {"type": "noul", "noul": 0.85}
  },
  "usage": {"input_tokens": 354, "output_tokens": 22}
}

応答のどこにも、理由の文章はありません。返ってきた0.85をどう扱うかは、受け取った側のコードが決めます。完了報告の場合、私は次の条件で止めています。

# done_prob は Jev の noul（完了主張の確率）。残りはコードが履歴から数えた値
if changed_files > 0 and checks == 0 and done_prob > 0.70:
    block("変更のあとに検査が走っていません。検査を1つ実行してから報告してください")

約2週間の本番運用で、この条件で止めたターンは11件でした。止めたときの完了主張の確率は0.76〜0.97で、どれも閾値を越えています。2つの方式の違いを、私の運用に当てはめると次の表になります。

観点	Jev＋コード	LLM＋AI エージェント
AI が返すもの	質問ごとの確率の数字	文章・手順・ツールの呼び出し
次の手を決めるもの	コードの if と、先に決めた閾値	LLM が履歴を読んで選ぶ
止めた理由の追い方	ログの確率と閾値を見る	返ってきた文章を読む
同じ入力での揺れ	確率が動く（choice の信頼度は±10%）	手順や文面そのものが変わる
向く判断	毎回同じ形で起きる判断	一回きりの判断、理由や文章が要る判断

揺れの例もあります。同じ入力で再実行した choice の信頼度が55%から46%に動き、「人が決める」の線をまたぎました。LLM にも確率を含む JSON を出させることはでき、出せる情報だけを比べれば両者はほぼ同じです。違いは、Jev が判定の出力だけを返すように作られ、速く安く動く点にあります。

2つの方式の違いは、次の手を決める責任をコードに置くか、AI に置くかです。この見方は、nasuvitz さんの「Jevとは何か？従来型LLMやAIエージェントとの違いを理解する」が先に整理しています。

curl で試す

最小の呼び出しは次のとおりです。API キーは TypeSafe AI のコンソールで発行し、環境変数 TYPESAFE_API_KEY に置きます。仕様は公式ドキュメントで確かめてください。

curl -s https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "jev-1.13.0",
    "state": "これから実行するコマンド: rm -rf ./build",
    "questions": {
      "irreversible": {
        "type": "noul",
        "instructions": "このコマンドは、実行すると元に戻せないか",
        "criteria": {"true": "ファイルを削除・上書きし、元に戻せない",
                     "false": "読み取りだけか、元に戻せる操作"}
      }
    }
  }'

応答は先に載せた JSON で、answers の下に質問と同じ名前の irreversible が返ります。noul なので、answers.irreversible.noul に「はい」の確率0.85が入りました。criteria には true と false の状態をそれぞれ具体的に書き、「高い数字＝はい」の向きにそろえています。

model には jev-latest も指定できますが、私は jev-1.13.0 と版を書いています。新版が出ると応答する版が変わり、決めた閾値の意味も変わるからです。期間中に返ってきた版は jev-1.13.0 だけでした。

2週間で試した15用途

約2週間で試した15用途は、Jev の結果で何をするかで、止める・振り分ける・採点する・検収するの4つに分かれました。「止める」は作業を止めるか確認に回す用途、「振り分ける」は行き先や種類を選ぶ用途です。「採点する」は複数案に順位を付け、「検収する」は成果物が条件を満たすかを見ます。数字はいずれも 2026-10-09 時点の運用ログの値です。効果の列は私の評価で、◎は期待以上で今後も使う、◯は使える、△は人の判断が要るか検証の途中、×は向かないを表します。

分類	何を判定したか	結果	効果
止める	完了報告に検査の証拠があるか	本番で11件を止めた	◯
止める	Bash コマンドの危険度（記録のみ）	1,887件中35件が閾値超え	△
振り分ける	ツール結果の各部分が要るか（記録のみ）	削減率の中央値0.0%	×
振り分ける	依頼を本体と子エージェントのどれに回すか（5択・記録のみ）	信頼度0.5未満が49.2%	×
振り分ける	通知の返信要否と振り分け先	合成6件中6件が期待どおり	△
振り分ける	上位記事のタイトルの型	17本を5.8秒で分類	◎
振り分ける	受け取った返信が承認か	例文40例×3回で誤反映0	◯
採点する	実装方式4案	信頼度91%・人の推奨と一致	◎
採点する	記事候補10本	10回で約0.13円	◯
採点する	記事タイトル5案	A案61%（信頼度54%）を採用	◯
採点する	営業文面18案	18回・6.8秒・0.26円	△
採点する	サービス名称15案	総合の信頼度34%で人が決めた	△
採点する	事業案（11案・4案・14案の3回）	選んだ案75%（信頼度66%）	◯
検収する	公開前の記事の文面	第2稿の信頼度40%で人が決めた	△
検収する	画面ワイヤーが要件を満たすか	48要件で「無い」が6件から0件	◎

Bash コマンドの危険度は記録のみで運用し、閾値を超えた分は1件ずつ目視してから確認に回すかを決めます。採点する6用途では Jev の結果を順位の材料にとどめ、決めたのは毎回人です。承認判定の40例は検証用の例文なので、実運用の誤反映率はまだ言えません。

一番良かったところ

一番良かったのは、AI が「全部入っています」と言った成果物を、Jev で要件1件ずつ疑えたことです。要件48件を聞き直すと「無い」が6件出て、費用は約0.35円でした。

場面は教育系アプリの案件です。顧客から届いた要件概要書をもとに、受講者向けの画面ワイヤーを12画面作りました。流れは次の4段です。

Claude が「受講者が触れる要件は12画面に全部入り」と結論した。根拠は、画面ごとに Jev へ聞いた確認と Codex のレビュー
私が、要件1件ずつ Jev に聞き直すよう頼んだ。質問は「ワイヤーのどこかに、この要件に対応する画面要素があるか」の noul を48問
確率70%以上を「ある」、30%未満を「無い」とすると、「無い」が6件、間の「人が見る」が13件出た
読み直して見つけた欠け5種類を Codex が直し、全件を流し直すと「無い」は0件になった

欠けの5種類は次のとおりです。

最終目標（ある試験の合格）を書いた文言が、どの画面にもない
学習段階の正式名とテーマ文がなく、画面には短縮名しかない
PC・タブレットでも使える旨の注記がない
動画を使う単元を限る文言がない
模擬試験の詳細が未確定である旨の注記がない

途中で漏れが1つありました。再採点で直した14件だけを聞き直したところ、初回に「無い」だった1件を入れ忘れていたのです。手順をスクリプトにして全件を流し直したときに、この漏れも見つかりました。

画面単位で「主要な要件があるか」と聞くと全部通り、要件単位で聞くと欠けが出ました。問いの粒度で、同じワイヤーでも結果が変わります。AI が自分で「全部入っている」と言ったときは、別の目で要件を1件ずつ聞くのが私の結論です。12画面のワイヤー1本で、Jev の呼び出しは約60回・約1円でした。

向かなかったところ

向かなかったのは、ツール結果を削る判断、依頼の行き先の判断、読み手の感じ方を問う質問、画像の4つです。

判断	結果	私の対応
Claude に渡す前のツール結果から、要らない部分を削る	123件中100件が削減0%（合成データでは97%）	やめるかを判断中
依頼を本体と別のエージェントのどちらに回すか	179件中88件が信頼度0.5未満	助言に使わない
営業文面が読み手にどう受け取られるか	126問中27問が信頼度0.5未満	人が見る
画面の参考スクショの選別	画像は送れない	キャプションだけ採点し、画像は目視

状況を書いた基準の問いは安定しましたが、「返信したくなるか」のように読み手の受け取り方を問う質問は揺れました。この種の判断は人に残しています。

止める用途にも限界があります。止めた11件のうち、その後を追えた7件で検査が実際に走ったのは3件でした。止めた後に検査を走らせるのは、Jev ではなく Claude 側の動きです。

業務に当てはめるなら

挟む場所は、人が毎回読んで判断している工程です。その判断を質問1つに切り出し、質問の書き方・閾値・人に戻す条件の3つを先に決めます。私が使った中で、ほかの業務にも当てはめやすい型は3つあります。

1つ目は、届いた文章を選択肢に振り分ける型です。choice で聞き、選択肢には「その他」を必ず入れます。自動で先へ進める前提なら閾値は高めに置き、私の承認判定では承認の確率0.8以上だけを承認として扱いました。「その他」が選ばれたときと、信頼度が足りないときは人に戻します。

2つ目は、要件1件ずつ「ある・無い」を聞く型です。質問は要件ごとの noul です。instructions には要件書の言葉をそのまま入れ、state には確認したい成果物の文言を入れます。次の JSON は、API に送る questions の部分だけです。

{
  "最終目標": {
    "type": "noul",
    "instructions": "画面の文言のどこかに、要件「最終目標は資格試験の合格である」に対応する要素があるか",
    "criteria": {"true": "要件と同じ意味の文言・ボタン・説明が画面に具体的に現れている",
                 "false": "対応する要素が無いか、違う意味の要素しか無い"}
  }
}

閾値と合格の線は、教育系アプリの例と同じです。「無い」が1件でもあれば直し、全件を流し直して「無い」が0件なら合格にします。

3つ目は、複数案に順位を付ける型です。基準ごとの score と、最後に1つ選ばせる choice を組み、choice の信頼度が線を下回れば人が決めます。表の実装方式4案は信頼度が高く人の推奨と一致し、サービス名称15案は低かったので人が決めました。

Jev に任せるのは「止める」「確認に回す」「順位を付ける」までです。文章や案や理由を書くのは Claude で、回数上限・集計・閾値での分岐と数字の検算はコードです。送信・支払・公開・削除などの取り消せない操作は、人が行います。理由が要る判断と一回きりの判断では、Jev を呼びません。

外部の API なので、顧客の社名・人名・金額は送る前にマスクしています。新しい用途は記録のみで始め、閾値と件数を見てから動作につなげました。

おわりに

次に測ることは3つです。1つ目は、Bash コマンドの危険度判定で確認に回るはずだった16件の目視です。10/12 に1件ずつ見て、記録のみの運用から実際に確認を出すかを決めます。2つ目は、依頼の行き先の判定と、実際の行き先との一致率です。

3つ目は、ツール結果を削る判定をやめるかどうかで、事前に決めた基準は「削減の中央値が10%未満ならやめる」でした。3つとも材料は記録のみで残した確率と件数のログで、閾値を動かすときは版を jev-1.13.0 に固定したまま測ります。

参考文献

TypeSafe AI 公式ブログ「Introducing System One Models & Jev」
TypeSafe AI 公式ドキュメント「API」「Primitives」「Confidence」
nasuvitz「Jevとは何か？従来型LLMやAIエージェントとの違いを理解する」（Qiita）
第1本「Claude Code の「完了しました」を信用しない。判定専用AI「Jev」をフック3本に挟み、4日間1,519判定・約5.6円で止めた話」（Qiita）

ノンズ株式会社代表

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

改めて Jevとは何か？ 判定専用AIを2週間・約2,900回使って分かった、業務での向き不向き