Jevとは？「判断を生成するAI」の仕組みと、企業での使いどころ

返ってくるのは、説明文ではなく決められた形の答え

Jevには、判断材料を「state」として渡し、それについて質問します。現在の入力はテキストで、文字列、JSON形式のデータ、テキストの配列を扱います。画像・音声・動画は非対応です。[5] たとえばスキャンした書類を使うなら、別の処理で文字に変換し、読み取り誤りも確かめる必要があります。

出力は自由文ではなく、事前に決めた形式に収まる「型付き」の値です。質問の形式は、答えに何を求めるかで三つに分かれます。[14]

Jev、LLM、ルール、人は何を受け持つのか

「System One」という名前は、速く直感的なSystem 1と、遅く熟慮するSystem 2という人の思考の区別に着想を得ています。[5][16]

この対比でJevをSystem 1型、LLMをSystem 2型と説明するのは、あくまで設計上の比喩です。LLMが人と同じ熟慮を行うという分類でも、長く考えさせれば論理的に正しくなるという保証でもありません。

業務の分担としては、次のように整理できます。

LLMにも、出力形式を制約して分類に使う方法があります。「LLMは文章しか返せず、業務の分岐には使えない」という違いではありません。[16] Jevは、型付きの判断と確率を直接返すことに設計の重点を置いています。[14]

返事の文章まで作るならLLMが候補になります。「どの受付箱に置くか」だけなら、説明文を毎回生成する必要はありません。さらに、顧客がフォームで部署を選び、振り分けが一意に決まるなら、AIを使わずコードだけで済みます。四者すべてを組み込むことが目的ではなく、その判断に必要なものを選びます。

低価格が変えるのは、判断を入れられる場所

2026年9月18日参照の公式料金は、100万input tokensあたり$0.042、output tokensは無料です。課金の単位はリクエスト件数ではなく、入力token数です。[13]

一回のAPIリクエストで課金対象の入力が合計1,000 tokensになると仮定すると、推論費は次のように計算できます。

これは米ドル建てのAPI推論費だけの試算です。入力の整備、評価データ作り、連携開発、監視、保守、通信・保存、税や個別契約の費用は含めていません。

リクエスト数と判断数も同じではありません。Jevは、一つのstateに対する複数の質問を、一回のAPI呼び出しで並列に評価できます。[14] 表は「各リクエストの入力合計が1,000 tokens」という仮定であり、質問を増やしても総入力や費用が必ず変わらないという意味ではありません。

この単価が業務に合う精度とともに得られるなら、まとめて一度だけ判定する運用から、細かな変化のたびに判定し直す運用を検討できます。営業案件全体を週に一度評価する代わりに、顧客の返事が来るたびに「追加説明を求めているか」を判定し、担当者の確認一覧を更新する、といった使い方です。

一件の効果が小さく、AIを呼び出す費用に見合わなかった箇所にも試す余地が生まれます。ただし、判定のたびに通知まで増やせば、確認の負担が勝ってしまいます。採算を見るときは、推論費の節約だけでなく、判定後の仕事が減るか、必要な対応を拾えるかまで確かめます。

Jevonsの名前に込められた期待と、その条件

Jevの名前は、19世紀英国の経済学者William Stanley Jevonsに由来します。TypeSafeは、蒸気機関の効率化が石炭需要を増やしたという「Jevons paradox（ジェボンズのパラドックス）」になぞらえ、知能の費用低下が用途を増やすと期待しています。[16]

起点は、Jevonsが1865年の『The Coal Question』で示した議論です。効率が上がって一回あたりの資源使用が減っても、利用が十分に増えれば、全体の消費はかえって増えうるという見方です。[11]

ここからは知式の整理です。全体の資源消費は、一回あたりの平均使用量と利用回数の積です。効率化で前者が減っても、後者がどれほど増えるかによって総消費は変わります。価格低下に需要がどれほど反応するか、つまり需要の価格弾力性が関わるため、利用が多少増えただけで総消費まで増えるとは言えません。「安くなれば必ず需要が増え続ける」という普遍法則としては扱えません。

企業のAI利用に当てはめるなら、導入障害と補完投資も考える必要があります。社外へデータを出せない、既存システムと接続できない、結果を確認する人がいない。こうした条件が残れば、推論だけが安くても用途は広がりません。

安価な基盤は、同じ推論予算で試せる回数を増やします。それを新しい用途につなげるには、データ整備や評価、担当者の運用にも投資が要ります。TypeSafeの期待を、企業の利益増加がすでに証明された話として読むことはできません。

一般企業では、どんな仕事が候補になるか

以下はすべて、技術の特性から組み立てた適用仮説です。Jevの公開導入実績や知式の顧客成果ではありません。2026年9月18日までに確認した資料では、一般企業の公開顧客成果は確認できていません。

ここからの業務の切り分けと導入設計は知式の整理であり、各社のデータと基準で適否を確かめる前提です。

1. 問い合わせの振り分け：内容から担当部署の候補を選ぶ。
2. 見積依頼の確認：用途や使用条件の説明を評価し、不足する確認項目を選ぶ。
3. 保守報告・障害連絡の整理：記述された業務影響を評価し、人が読む順番をつける。
4. 仕入先メールの確認：納期変更や供給不安を示す記述を拾う。
5. 経費申請の確認順：申請理由の分かりにくさを評価する。承認・却下は規程と人が決める。
6. 契約書・規程の確認補助：条項と、事前に決めた確認テーマとの関連を判定する。法的な適否は確定しない。
7. 営業案件のフォロー：商談メモから、追加説明や条件調整が必要な兆候を分類する。
8. 商品レビュー・アンケートの整理：苦情、要望、使い方の誤解などに分ける。
9. 取引先・商品マスタの整備：名前や説明の似た候補が同一対象らしいかを評価する。統合は確定しない。
10. 在庫例外メモの調査：差異の理由として書かれた内容を分類する。数量はコードで計算する。
11. LLMが作った文章の点検：禁止された断定や要確認表現を拾う。唯一の安全対策にはしない。
12. 社内検索の絞り込み：検索結果と質問の関連度を評価する。閲覧権限や文書の有効な版は別に確認する。

代表的な四件について、入力と出力、任せない範囲まで具体化します。どれも、材料不足や通信失敗、確率・confidenceが保留域に入る場合には、人の確認へ戻す設計を前提にします。

手書きのif文を減らしても、業務ロジックは残る

「急ぎ」「至急」「困っています」を見つけるたびに条件を追加する方式では、言い換えや否定表現への対応が増えます。Jev型のモデルは、文面の意味を拾うために書いていたif文を減らす候補になります。

一方、「支払額が上限を超える」「この担当者には変更権限がない」「同じ処理は二重に実行しない」といった条件は、意味を推測する問題ではありません。閾値・権限・計算・監査・副作用はコードに残します。副作用とは、送信、支払い、登録内容の変更など、外の状態を変える操作です。

構成は、入力の形式と権限をコードで確認し、必要な材料だけをJevへ渡す形が考えられます。返り値を受けたコードは、業務別の閾値と他の条件を照合し、低リスクの処理、人への確認、保留へ分けます。実行する操作は事前に許可した範囲に限り、実行記録と二重実行の防止を組み込みます。

途中で説明を整えるためにLLMを使うことはできます。ただし、Jevは判断理由の自由文を生成しません。[5] 後からLLMが作った理由を、Jevが実際に判断した根拠として表示してはいけません。

通信エラーや応答待ちの期限超過も想定します。呼び出せないときは通常の受付へ戻すなど、モデル停止時の手順を用意しておけば、業務全体を依存させずに試せます。

最初は、一業務の一判断だけを試す

最初に承認するのは全面導入ではなく、限定したpilot（試行）の予算と範囲です。問い合わせ業務全体ではなく、「請求に関する連絡かどうか」だけを対象にする、といった絞り方をします。

1．正解と責任者を先に決める

何を判定し、どんな誤りを避けたいかを業務責任者と決めます。現場の二人が別の正解をつけるなら、モデル評価の前に基準をそろえます。「材料不足で人が確認する」も正当な結果として扱い、無理に全件を自動分類しません。

2．過去データで、今の方法と比べる

利用許可を得て必要に応じて匿名化した過去データを使い、人がつけた正解と比較します。典型例だけでなく、誤字、複数用件、否定、情報不足、誘導的な記述も含めます。質問を調整するデータと、最後に評価するデータは分けます。

比較相手は現行の人手、既存ルール、必要ならLLMです。平均的な正解率だけでなく、重大な見逃し、人へ戻る割合、確認時間を比べます。ルールだけで十分なら、置き換える必要はありません。

3．shadow modeで、実際の流れを変えずに観察する

shadow modeは、実際の入力で判定しながら業務処理には反映しない試行です。担当者は従来どおり動き、裏側の判定との差を記録します。後から訂正された案件も含めて評価し、「人の最初の答えと一致した」だけを正解としません。

判定待ち時間や入力作成の手間も測ります。高精度でも、確認の負担や対応の遅れが増えるなら、そのまま自動化へ進めません。

4．誤りの損害に合わせて閾値を決める

受付箱への仮置きと、重大障害を通常扱いにする判定では、失敗の影響が異なります。一つの基準を全業務へ流用せず、実データで誤りの損害と人の確認量を比べ、対象ごとに閾値を決めます。

ChoiceとScoreでは確率分布とconfidenceを検討材料にし、Noulではnoulの値に対して閾値と保留域を設けます。金銭、契約、安全、権利に関わる判断は、値の高さとは別に、人の承認を残します。

5．モデルの版を固定し、変更時には再評価する

確認時点の公式ドキュメントにあるモデルはjev-1.13.0です。jev-latestなどの別名は、新しい版の公開に伴って参照先が変わるため、同じ呼び出しでも答えが変わり得ます。[13]

評価したmodel versionを固定し、質問・評価基準・閾値も版管理します。新しい版へ移るときは、保存した評価データで再確認します。部署再編や規程変更も見直しの契機です。

6．結果と訂正を残し、続ける条件を確認する

ログには、入力を追跡できる識別子、モデルと質問の版、返り値、コードが選んだ処理、人の訂正を残します。機密情報を無制限に保存せず、閲覧範囲と保存期間も決めます。

自動処理の割合だけを追わず、許容できない誤り、確認時間、総費用を定期的に見直します。基準を満たさなければ対象を狭めるか止める。その条件を試行前に決めておけば、新技術への期待だけで利用を続けずに済みます。

「hallucination-free」でも、判断は間違える

TypeSafeはJevを「hallucination-free」と表現していますが、その説明は、自由文を生成せず、定義した型や構造から外れないことに重点があります。[16] 公式ドキュメントも、較正は一件の正しさを保証しないと説明しています。[5]

「請求」「技術」「営業」の三つしか返さなくても、本来は技術の問い合わせを請求と判定することはあります。型違反を防ぐことと、判断が正しいことは別です。

TypeSafe自身も、jev-1.13には数値の精密な扱い、日付・時刻の比較、カウント、複雑な間接推論、無関係な情報を多く含む長いstate、敵対的な入力などの弱点があると公開しています。[17] 数量や期限はコードで確かめ、指示を紛れ込ませたメールなども試験対象にします。

同社の「193.6倍高速」「444.6倍安価」は、販売元が作ったワークフローによるvendor benchmarkです。比較の参照値には他モデルの予測を用いており、顧客業務の正解や成果を直接測った評価ではありません。同社も、改善幅は実運用の上限寄りで、評価を作ったチームによる偏りもあり得ると明記しています。[16]

価格についても、補助されていないことや長期的な持続可能性は、現時点では証明できないと同社は認めています。[16]

これらの公表値は、あらゆる企業で同じ効果が出るという独立実証ではありません。実際の入力と通信環境で性能・費用を確認し、料金や提供条件が変わったときの代替手段まで考えて採否を決めます。

業務データを送る前には、保存場所・保存期間、学習利用、削除、アクセス権限、障害時の対応条件を契約と仕様で確認します。安価であることは、機密情報を送ってよい根拠にはなりません。

「任せたい業務」から、一つの判断を取り出す

Jevが広げうるのは、人との会話よりも、システムの中で意味を確かめる機会です。読み流していた連絡や、まとめてしか確認できなかった変化にも、小さな判断を置ける。その先の行動が改善して初めて、低い推論単価が業務の価値になります。

検討を始めるなら、担当者が毎日読んで振り分けているものを一つ選びます。「何を見て、どの候補から選び、間違えたら何が起きるか」を書き出し、ルールだけで足りるか、Jevの意味判断が役立つか、LLMの文章生成が必要か、人に残すべきかを比べます。

曖昧な意味判断をモデルへ切り出しても、業務ルールと責任は会社に残ります。一判断の効果と戻し方を確かめてから隣へ広げる。その順序なら、AIの採用を先に決めずに、低価格が本当に役立つ場所を探せます。