Jev 利用ガイド：判断のみを行い、文章を書かない AI モデルの使い方と活用領域

日常的に使われている大規模言語モデル（LLM）は、ChatGPTやClaude、各種コーディングAgentであれ、その中核となる役割は「書く」ことです。回答、コード、要約を生成します。

TypeSafe AI の最初のモデル Jev は別の道を選びました。コンテンツを生成せず、与えられた選択肢の中から判断することに特化しています。

雑談に応じることもなければ、文章を書くことも、直接コードを書くこともありません。使い方は極めてシンプルです。背景資料としてテキストを渡し、固定の選択肢が付いたいくつかの選択問題を提示すると、数百ミリ秒以内に解答を返し、どの選択肢を選ぶべきか、各選択肢の確率はいくつか、そしてその判断にどれほどの確信度（confidence）を持っているかを教えてくれます。

ソフトウェアの最も基本的な概念で例えるなら、通常の if 条件判定は固定された数値しか比較できません（例えば、注文金額が100より大きいか、ステータスが支払い済みかなど）。しかし、「意味を理解する」必要のある事柄――このDMの文面は怒っているのか、このコメントは広告に該当するのか、画面上のどのボタンをクリックすべきか――に直面した途端、固定されたルールは役に立たなくなります。

Jevが果たす役割こそが、まさに一般的な常識を備えたインテリジェントな if 分岐です。全体の処理フローは依然として既存のコードやAIが作成したスクリプトが制御し、意味の理解が求められるステップでのみJevが介入して、確信度を伴う判断を提供します。

Agentの文脈で捉えると、より明確になります。Agentは1つのループの中で動作します。LLMが何を行うかを決定し、ツールがそれを実行し、結果を判定し、タスクが完了するまでこのサイクルを繰り返します。小さな決定を下すごとにLLMを再度呼び出す必要があるため、処理が遅く、コストも嵩みます。Jevが引き受けるのは、まさにこうした小さな決定です。次にどのボタンを押すべきか、このコマンドは危険ではないか、このタスクは安価なモデルと強力なモデルのどちらに任せるべきか。推論や文章作成が必要な部分は、従来通りLLMに任せます。

Jev の主な機能と特徴

• 固定選択肢から意味に基づいて判断：背景情報と候補を与えると、内容に最も合う選択肢を選びます。分類、ルーティング、行動選択に利用できます。
• 確率と確信度を同時に返す：答えだけでなく判断の確かさも得られるため、自動実行、再観察、人への引き継ぎをプログラムで切り替えられます。
• 高頻度の小さな判断に特化：長文を生成せず「どれを選ぶか」に計算を集中し、Agent の観察・判断・実行ループに組み込みやすくなっています。
• 自然言語の条件を理解：感情、意図、リスク、画面要素、タスク難易度など、固定ルールにしにくい条件を選択問題に変えて判断させられます。
• コーディングAgentで導入可能：公式スキルが Codex や Claude Code に、インストール、API 呼び出し、問題設計、テストを案内します。開発者は選択肢と合格条件の設計に集中できます。

なぜ「System 1」と Jev と呼ばれるのか

TypeSafeは、これを全く新しいモデルカテゴリである System One（システム 1）モデル と定義しています。

この名称は、ノーベル経済学賞受賞者ダニエル・カーネマンの名著『ファスト＆スロー』に由来します。同書では、人間の思考を2つのシステムに分類しています：

• System 1（速い思考）：労力を必要とせず、直感と本能によって瞬時に下される判断。例えば、道路を歩いていて正面から走ってくる車を無意識に避けることや、相手の顔を見た瞬間に怒りを察知することなどです。
• System 2（遅い思考）：注意力を総動員し、手順を踏んで段階的に行われる深い推論。例えば、17 × 24 を計算することや、複雑なビジネスロジックを導き出すことなどです。

TypeSafeの区分に従えば、推論モデルが担当するのはSystem 2の仕事であり、JevはSystem 1の仕事、すなわち数百ミリ秒以内に下される迅速な判断を専門に行います。

Jev という名前は、19世紀のイギリスの経済学者ウィリアム・スタンレー・ジェヴォンズ（William Stanley Jevons）が提唱した「ジェヴォンズのパラドックス」に由来します。蒸気機関の効率が大幅に向上し、石炭1トンを消費するコストが劇的に低下した際、安価な動力がより多くの場所で利用されるようになったことで、石炭の総消費量はむしろ増加しました。TypeSafeは、知的な判断においても同様の現象が起きると考えています。1回の判断にかかるコストが1万分の1ドル未満、所要時間がわずか数百ミリ秒になれば、ソフトウェアの中には、これまでモデルの呼び出しなど考えもしなかったような判断ポイントが大量に出現することになります。

Jev を使い始める方法：4つのステップをすべて AI に任せる

インストール、設定、呼び出しコードの作成はすべて、お使いのプログラミングAgent（CodexまたはClaude Code）に任せることができます。必要なのは以下の4ステップだけです：

1. 公式サイトでウェイトリストへの登録を申請する：公式サイト typesafe.ai でwaitlistへの参加を申請します。基本的には申請当日に承認されます。
2. AIにTypeSafeスキルをインストールしてもらう：Codexに対して「npx skills add typesafe-ai/skills --skill typesafe-ai をインストールして」と指示します。Claude Codeを使用している場合は、公式プラグインの形式でインストールさせることも可能です。まず claude plugin marketplace add typesafe-ai/skills を実行し、続いて claude plugin install typesafe@typesafe-ai を実行します。どちらの方法を選んでも構いません。
3. API Keyを発行する：操作コンソール console.typesafe.ai にログインし、API KeysページでAPI Keyを生成します。
4. 作業を開始する：プロンプト（prompt）で “use the TypeSafe skill” と一言添え、あとは普段の言葉で要望を伝えるだけです。

API Keyを用意し、どのようなデータを処理したいか、どのように分類したいかを明確に伝えるだけで、その後のコード作成、フォーマット調整、実際のテスト実行はすべてAIが代行してくれます。

AI への一言の指示：実際のデモプロセス

「すべてAIに任せる」という流れが本当にスムーズに進むかを検証するため、コメントファイル comments.txt（私たちが作成した8件のサンプルコメントであり、実際の読者コメントではありません）のみを配置した空のディレクトリでClaude Codeを起動し、以下のプロンプト全文を入力しました。それ以外の操作は一切行っていません：

use the TypeSafe skill。カレントディレクトリにある comments.txt 内のコメント（1行に1件）を読み込み、Jevを使って各コメントを「質問」「ビジネス提携」「広告」「称賛」「批判・不満」「その他」に分類するPythonスクリプト triage.py を作成してください。さらに、そのコメントに自分自身で返信する必要があるかどうかも判定してください。分類の確信度（confidence）が0.6未満のものは「要手動確認」とラベル付けしてください。作成後、comments.txt で実際に実行し、結果を表形式で出力してください。API Keyは環境変数 TYPESAFE_API_KEY に設定済みです。カレントディレクトリ内でのみ操作してください。

Claude CodeはTypeSafeスキルの案内に従い、Pythonの標準ライブラリを使用して72行の triage.py を作成し、自ら実行して以下の表を出力しました：

実行完了後、Claude Codeは自発的に以下のような提案を行いました（原文ママ）：

把握しておくべき3つの点：

• 6つの分類はすべて正解で、7件目の皮肉（反語）の批判・不満も見分けられています。
• 今回は「要手動確認」が1件も発生しませんでした：8件すべての分類確信度が1.00付近でした。0.6未満を要手動確認とするロジックはスクリプトに組み込まれていますが、今回のコメント群はすべて判別が容易だったため、適用されませんでした。
• 「本人返信の要否」で2件、適切でないと判断されたものがあります：3件目のビジネス提携の依頼は0.38しか付かず、返信不要と判定されました。8件目のチュートリアル希望も0.41で、返信不要と判定されました。私からの提案は次の通りです：ビジネス提携のような分類は、モデルの判断に委ねず、コード上で「一律で本人返信必須」と直接ルール化することです。1行変更するだけで済みます。ご承諾いただければすぐに修正します。

この一連のプロセスは、Jevを利用する際の明確な役割分担を示しています。確定的なビジネスルールはコードに記述し、曖昧なセマンティクスの理解はJevに任せ、全体の統合作業はプログラミングAgentに任せる、ということです。

内部の仕組みを知りたい人へ：1回のリクエストの構造

これらのコードはすべてAIが代わりに書いてくれますが、ここでは内部で何が行われているかを理解するために説明します。1回のリクエストは、state（モデルに読み取らせる材料）と questions（モデルに答えさせる質問）の2つの部分だけで構成されます。以下は、サンプルのチケット（私たちが作成したもの）を用いて「どの部門に割り当てるべきか」という質問を実際に検証した例です：

{
  "model": "jev-latest",
  "state": { "ticket": "昨日注文したBluetoothイヤホン（注文番号 20260915-8831）について、2回二重に引き落とされていました。各299元です。過大請求された金額を至急返金してください。" },
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "`ticket`はどのチームに割り当てるべきですか？",
      "criteria": {
        "billing": "引き落とし、返金、請求書、クーポンなど金銭に関連する問題",
        "technical": "アプリやウェブサイトの不具合、クラッシュ、ログイン不可、機能エラー",
        "sales": "価格照会、大口購入、企業連携",
        "other": "上記のいずれにも該当しない、または分類が不明なもの"
      }
    }
  }
}

Jevが返した結果（実測値、この質問部分の抜粋）：

{
  "model": "jev-1.13.0",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "billing",
      "confidence": 1.0,
      "probabilities": {
        "billing": 1.0,
        "technical": 0.0,
        "sales": 0.0,
        "other": 0.0
      }
    }
  }
}

ここで注目すべき2つの重要な特徴があります：

1. 選択肢以外の回答を出力しない：Jevは1文字ずつJSONを生成するのではなく、定義された各選択肢それぞれの確率を直接算出します。そのため、回答が選択肢の範囲を超えることはなく、壊れたフォーマットが出力されることもありません（公式ではこれを「0% 型エラー」と呼んでいます）。ただし、これは常に正解を選ぶという意味ではなく、判断ミス自体は当然起こり得ます。
2. すべての質問に一度に回答する：すべての質問は同一の計算ラウンド内で並列に評価され、互いに影響を与えることはありません。

3つの基本問題形式

Jevにおいて、すべての判断は3つの基本問題形式に集約されます：

是非問題（Noul）

特定の記述が真か偽かを尋ねる形式です。0から1の間の確率値 noul を返します。 1に近いほど「はい」の可能性が極めて高く、0に近いほど「いいえ」の可能性が極めて高いことを示します。

• 注意点：0.5前後の値はモデルが確信を持てていないことを示しており、「中間的な度合い」を意味するわけではありません。
• 質問のコツ：主観的で曖昧な度合いを尋ねるのではなく、明確に検証可能な事実を尋ねるようにします。私たちが作成したサンプルの履歴書での実測では：
  • 「候補者のPythonスキルは高いですか？」と尋ねた場合、Jevは確率0.19を返しました（これでは次のアクションを判断できません）。
  • これを2つの事実を問う質問に変更しました。「履歴書に業務でPythonを使用した旨の記載はありますか？」と尋ねるとJevは0.04（明らかに無い）を返し、「履歴書にPythonで何らかの成果物を作成した旨の記載はありますか？」と尋ねると0.99（趣味でスクレイピングを行った記載があったため）を返しました。ビジネスコード側では、この2つの明確な事実に基づいて分岐処理を行う方が、曖昧な0.19を扱うよりもはるかに堅牢です。

単一選択（Choice）

固定された順序のない選択肢のグループから1つを選択する形式です。最大255個の選択肢に対応しています。 最も確率の高い選択肢 choice、すべての選択肢の完全な確率分布 probabilities、および総合的な確信度 confidence を返します。

• 注意点：「その他」という選択肢を追加する習慣をつけてください。フォールバックとなる出口を用意しておかないと、どのカテゴリにも該当しない内容に遭遇した際、モデルはいずれかの選択肢を無理やり選ばざるを得なくなります。
• 中国語でも利用可能：本記事のテストにおける質問と選択肢は、すべて中国語で作成しました。サンプルのチケットを用いた実測では、「アプリを開いて支払いページに行くとクラッシュしてしまい、今日は注文できません」という内容が、確信度1.0で技術的な問題と判定されました。公式によれば英語が最も高い精度を発揮し、多言語も処理可能ではあるものの英語には及ばないとされているため、本格運用の前には実際の中国語データでテストを行ってください。

スコア評価（Score）

明確な高低や順序が存在するスケール評価に使用され、2〜10段階のグレードに対応しています。 確率加重平均スコア score、各グレードの確率、および確信度を返します。

• グレードには度合いを表す形容詞だけでなく、具体的な状況を記述する必要があります。 私たちが作成したサンプルのバグ報告「Safariでエクスポートボタンをクリックしても反応がありません。Chromeでは正常に動作しますが、弊社の顧客の約3分の1はSafariしか使っていません」を用いて実測を行いました：
  • グレードに度合いを表す言葉のみを指定した場合（0: 軽微 / 1: 通常 / 2: 深刻）、Jevはスコア1.94、確信度0.91を返しました。一見すると非常に断定的に見えますが、このバグはクラッシュを引き起こすわけでもなく回避策も存在するため、この断定には十分な根拠がありません。
  • これを具体的な状況の記述に変更した場合（0: 見た目にのみ影響し機能は正常 / 1: 機能に支障はあるが回避策が存在する / 2: 業務を阻害する致命的な問題であり回避策が存在しない）、Jevが返したスコアは1.48となり、確信度は0.28に低下、グレード1の確率は0.52、グレード2の確率は0.48となりました。 これは現実の状況を忠実に反映しています。Chromeを使用しているユーザーにとっては回避可能ですが、Safariしか使えない顧客にとっては完全に業務が停止します。具体的な状況として記述することで、モデルはこの曖昧さをありのままに表現できるようになり、コード側でも「人間による確認に回すべき案件」だと判断できるようになります。

確信度と「すべてまとめて問い合わせる」

確信度（Confidence）：自分がいつ確信を持てていないかを認識する

一般的なLLMは選択問題に回答する際、確信度の出力を求めたとしても、根拠のない過信を示すことが多々あります。JevはTypeSafeが独自開発したRLCD（確率較正された決定に基づく強化学習）によってトレーニングされており、その中核となる目標は確率較正（キャリブレーション）にあります。すなわち、モデルが90%の確信度を示した判断は、多数の統計において実際の正解率も約90%であるべきだという考え方です。

公式が推奨する3段階の処理ロジック：

• 高確信度：システムがバックグラウンドで自動実行する。
• 中確信度：実行前にユーザーに確認を求めるか、要確認フラグを付与する。
• 低確信度：自動実行は行わず、直ちに手動対応ルートへ回す。

各区間の具体的な境界線は、直面するビジネスリスクによって完全に決まります。例えば公式のサンプルでは、一般的な意図ルーティングであれば0.5未満で手動に回すことが推奨されていますが、「送金承認」のような不可逆で高リスクな操作の場合、確信度の基準値は通常0.9以上に設定する必要があります。

私たちが作成したサンプルの2つの文面で実測を行いました。内容が明確な「口座の残高がいくら残っているか調べてください」に対しては、Jevは確信度1.0で残高照会と判定しました。一方、「前回のあのお金の件、対応しておいてください」という曖昧な文面に対しては、カスタマーサポートへの連絡と判定した確率が0.88だったものの、送金の確率も0.12存在し、確信度は0.82まで下落しました。システムはこの結果に基づいて、潜在的な誤操作を未然に防止することができます。

実際のデータによる別の検証結果も見てみましょう。ニュースフィードから取得した実際の中国語AIニュース見出し200件を、8つのカテゴリ（新モデル、新機能、論文、資金調達・ビジネス、オープンソースプロジェクト、チュートリアル・ノウハウ、業界の視点・オピニオン、その他）に分類しました：

• 10回のリクエスト（並列数6）で、200件すべての分類にかかった時間は合計 11.1秒、消費された入力tokenは42,498個でした。公式価格で計算すると、総費用はわずか 約0.001785米ドル（1円にも満たない額） でした。
• 確信度の中央値は0.78でした。そのうち確信度 ≥ 0.9 の見出しは66件、< 0.6 の見出しは63件でした。
• 閾値を0.6に設定した場合、137件が自動分類され、残りの63件が人間による確認に回されました。
• 人手による検証の結果、高確信度の項目は正確に分類されていることが確認されました。例えば、「Jina AIがjina-ocr-v1をリリース：3.4B MoEドキュメントパーサー」（Jina AI Releases jina-ocr-v1: A 3.4B MoE Document Parser With Built-In Speculative Decoding for Low-Budget GPUs）は新モデル（確信度0.96）に分類されました。一方、確信度が0.6を下回った項目の多くは、本質的に二面性を持つものでした。例えば、「Claude Code v2.1.276：プロキシ環境のエラーを修正」（v2.1.276）では、モデルが製品機能（0.50）とオープンソースツール（0.46）の間で揺れ動き、確信度はわずか0.44にとどまりました。

ヒント：判断が分かれる境界線上の項目では、複数回実行した際に数値にわずかな変動が生じる場合があります（実測において、2つの判定間で揺れていた同一のバグ報告のスコアは2回の実行でそれぞれ1.50と1.44となり、確信度は0.25と0.34でした）。確信度のフィルタリング閾値を設定する際は、必ず安全マージンを確保してください。

すべての質問を一度に尋ねる（Speculative Fan-out）

通常のLLMを使用する場合、コストと時間を節約するために、開発者は最初の質問をまず投げて、その回答を見てから2つ目の質問を呼び出すかどうかを決めるというアプローチを取りがちです。

Jevを使用する場合は、その正反対のアプローチを取ります。同一の材料を対象とし、互いに独立している質問であれば、1回のリクエストですべてまとめて尋ねます。前回の回答によって新しく取得すべき材料が決まる場合にのみ、2回目の問い合わせを行います。

サンプルのチケットでの実測結果：

• Jevに対して4つの質問（所属部門、返金希望の有無、緊急度、注文番号が含まれているか）を一度にまとめて尋ねた場合、エンドツーエンドの所要時間は 274ミリ秒、消費された入力tokenは603個でした。
• これを4回の独立したリクエストに分割し、直列に順次呼び出した場合、4つの質問の所要時間はそれぞれ268、271、276、296ミリ秒となり、合計所要時間は 1111ミリ秒 に達しました。また、入力tokenは1572個に増加しました（質問するたびにチケットのテキストを再送信する必要があるためです）。

すべてまとめて尋ねることで、所要時間が4分の3近く短縮されるだけでなく、tokenコストも62%削減されます。ある質問が最終的にビジネスロジックの分岐で使用されなかったとしても、1回のリクエストにまとめて含めるコストは、複数回呼び出しを行う際のオーバーヘッドに比べればはるかに低く抑えられます。

速度、コスト、精度

まず料金と実際のレイテンシを確認します：

• 公式価格設定：入力100万tokenあたり 0.042米ドル（すなわち10億tokenあたり42ドル）で、出力tokenは 完全無料 です。主要なフロンティアLLMにおける100万tokenあたり0.2〜10ドルという入力コストや、入力の数倍に設定されている出力の課金と比較すると、Jevの呼び出しコストは数分の一から百分の一以下に抑えられます。
• エンドツーエンドの所要時間：公式発表では70〜500ミリ秒とされており、評価は米国西海岸の環境で実施され、サーバーも同地域に配置されています（Flavioが伝えた公式の説明によると、大半は100ミリ秒前後とのことです）。小互が中国本土から太平洋越えのパブリックネットワークを経由して実測したところ、1回のリクエストのエンドツーエンド時間は概ね 0.25秒〜0.58秒 の間でした。

27問を同時に比較したデモでは、Jev は 0.114秒、費用 0.000081米ドル、GPT-5.6 Terra は 8.566秒、費用 0.013880米ドル でした。短く密度の高いチケット文は Jev に向いており、1問では回答も異なりました。この結果は判断型タスクでの速度とコストの差を示すもので、あらゆる用途に当てはまる倍率ではありません。

4つの完全なワークフローベンチマークでは、Jev のコストはおよそ2桁低い一方、判断の一致率は約68%で、GPT-5.6 sol の約74%、Opus 5 の約73%を下回りました。大量の小さな判断を低コスト・低レイテンシで処理し、確信度が低い場合や高リスクの場合は別の処理へ回す、という取捨選択です。

Jev は全体の請求額をどれだけ削減できるのか？

AI関連の請求額を半分以上削減することは可能なのでしょうか？技術ライターのFlavio Copesの回答は、「何にお金を使っているかによる」というものです。彼は大まかな計算式を提示しています：

請求額全体の削減率 ≈ 判断系呼び出しが請求額に占める割合 × その呼び出し自体の削減率

ある企業がAIに毎月10,000ドルを費やしていると仮定します：

• そのうち6,000ドルがテキスト分類、意図のルーティング、セキュリティ審査、コンテンツの初期フィルタリングに使用されており、Jevによってこの部分のコストを95%削減できるとすれば、毎月5,700ドルを節約でき、請求総額を57%削減できます。
• しかし、ビジネスの中核となる支出がすべて長文レポートの生成、コード記述、画像処理に集中しており、純粋な判断系の呼び出しが請求額の10%しか占めていない場合、判断の呼び出しをすべてJevに置き換えたとしても、月全体の請求額に対する削減効果は最大でも約10%にとどまります。

費用を計算する際は、パイプライン全体を考慮する必要があります。前段のフィルタリング、失敗時のリトライ、低確信度案件のLLMへの転送や人間による再確認のコストもすべて算入しなければなりません。

公式およびコミュニティの実例

以下の公開デモとオープンソースプロジェクトから、Jev がどのような判断タスクに向くかを確認できます。

公式デモ

Wikiracing（ウィキペディア・レース）：Wikipediaの「Baseball」ページを出発点とし、ページ内のリンクをクリックすることだけを繰り返して「Sun」のページを目指します。各ステップにおいて、数百から数千あるリンクの中から選択しなければなりません。Jevは0.419秒、3ステップを要し、費用は0.047セントでした。同じ条件で対戦したClaude Sonnet 5は3.724秒、4ステップ、3.310セントを要しました。GPT-5.6 Terraは9.453秒を要し、途中でページ上に存在すらしないリンクをクリックしてしまいました。なお公式は、ここで比較対象となっているのはLLMの非推論モードであり、推論機能を有効にしたLLMであればパフォーマンスは大幅に向上すると注記しています。

Jev による Doom プレイ：ゲームが現在の戦況をテキスト形式（武器のパラメータ、敵との距離、方角など）に変換してJevに送信し、Jevは毎秒約10回の判断を下します：射撃すべきか、現時点で最も優先すべき目標は何か（体力の回復など）、どちらの方向へ回避すべきか。公式の試算では1時間あたり約7ドルとされており、AIを用いない専用のアルゴリズムプログラムの方が上手くプレイできる可能性があることも認めています。このデモが意図しているのは、Jevが状況を理解し、指示通りに行動でき、そして十分な処理速度を備えていることを実証することです。

コミュニティでの実際のユースケース

メール仕分け（Ryan Vogel）：彼自身の実メール1500通を用いてテストを行い、「このモデルのメール分類能力は並外れて強力だ」と投稿しました。この投稿には3530件のいいねが付きました。動画に映っているのは彼自身が構築したメールダッシュボードです：各メールのカテゴリ、優先度、スパム判定、返信要否を判定しています。画面をキャプチャした時点で、1701通中1534通の処理が完了しており、並列数8、1通あたり平均193ミリ秒で、毎秒約40通を処理していました。

ブラウザ Agent（Kyle Jeong、Browserbase）：彼はJevにStagehand（AIにブラウザを操作させるためのオープンソースツール）を組み合わせてブラウザ自動化を構築し、今回のタスクにかかった費用は0.001ドルで、ほぼ瞬時に完了したと投稿しました。彼はそのループ処理を明確に説明しています：まずウェブページを確認し、ページの構造を材料とし、実行可能な操作を選択肢としてJevに渡し、Jevが次のステップを選択してStagehandがそれを実行します。動画内のタスクは「テスト用ECサイトにログインし、ヘッドライトをカートに入れ、カートを開いて、決済直前で停止する」というものです。Jevはステップごとに、ユーザー名の入力、パスワードの入力、ログインのクリック、カートへの追加、カートのオープンを順次選択していきました。途中、2回にわたって「操作の確信度が実行閾値を下回ったため、ページを再観察します」というログが表示されました。確信が持てない場合には無理にクリックせず、ページを再確認するという挙動をとっています。

同様のアイデアとして、Flavioが収集した初期のデモでは、航空券の予約処理が約7秒で完了していました。また、開発者のdaxがX上でJevとopencodeブラウザツールを組み合わせた速度プレビューを公開し、3725件のいいねを獲得しました。さらに、browser-useチームがオープンソース化したjev-ultrafastは、次にどこをクリックするかをJevが決定し、テキスト入力が必要な場合にのみLLMを呼び出す構成となっており、GitHubで5913個のスターを獲得しています。

トレーディングボット（Jarrod Watts）：彼はトレーディングボットを作成しました。Jevにある通貨ペアの価格データを渡すと、Jevが買いか売りかを判断し、Monadチェーン上のKuruのオーダーブックに発注を行います。300ミリ秒のブロックごとに1回判断を下す仕組みで、jev-trader.vercel.app でオンラインデモが公開されています。この投稿は4880件のいいねと110万回のインプレッションを獲得しました。投稿では実際の取引を実行すると述べられていますが、デモ動画のUI右上には「dry run」（シミュレーション実行）と表示されています。呼び出し時間は平均100ミリ秒で、すでに1840回の呼び出しが行われており、わずかな遅れによって「このブロックを見送った」ケースも散見されます。これはJevが各ブロックに追従できるほど高速であることを示すものに過ぎず、利益を上げられることを保証するものではありません。公式自身も、Jevは専門分野向けにトレーニングされたモデルではないと述べています。

タイプライター（TypeSafe Typewriter）：開発者のSteve Krouseが作成したオンラインデモで、typesafe-demo.val.run で実際に体験することができます。左側のエリアでテキストを入力すると、キーを1回叩くごとに1回の呼び出しが行われ、16個の質問が再評価されます：AIが書いたように読めるか、皮肉が含まれているか、論争を引き起こしそうか、誰かが返信してくれそうか、トーン、緊急性、検証可能な主張が含まれているか……。それに合わせて右側のバーグラフがリアルタイムに変化し、動画内では1回の呼び出しが318ミリ秒で完了していました。

フレームワーク側の対応：LangChain

LangChainは公式統合 langchain-typesafe をリリースし、解説記事の中でAgentにおけるJevの担当領域を明確に説明しました：Agentは1つのループの中で動作し、LLMが何を行うかを決め、ツールがそれを実行し、結果を判定し、タスクが完了するまでこのサイクルを繰り返します。小さな決定を下すごとにLLMを再度呼び出す必要があるため、処理が遅くコストも高くなります。Jevが引き受けるのは、まさにこうした小さな決定です。この統合には、すぐに利用できる2つのミドルウェアが含まれています：1つはタスクの難易度に応じてモデルを選択するもの（単純なタスクは高速なモデルに、複雑なタスクは強力なモデルに割り当てる）、もう1つはAgentがツールを呼び出す前にリスクを検査し、危険な操作を未然に遮断するものです。LangChainは記事の中で、Claude Code、Codex、Cursorといったプログラミングツールにはいずれも「実行前に危険性を判断する」分類器が備わっているものの、常にクローズドソースの内部に隠されてきたと言及しています。安価な判断モデルが登場したことで、あらゆるAgentにこの保護レイヤーを追加できるようになりました。

コミュニティの代表的なオープンソースプロジェクト

GitHub上のコミュニティリスト awesome-jev には、数十個のプロジェクトが収録されています（リストの作者は、収録は推奨を意味するものではないと明記しています）。代表的なものをいくつか紹介します：

• Claude Code 向けのモデル選定（jev-router）：複数の候補モデルの中からJevに選定させ、最も安価で要件を満たすモデルにタスクを割り当てます。
• 広告ブロッカー（typesafe-adblock / unclutter）：Webページ上の要素について「これは広告か、邪魔な要素か」をJevに順次問い合わせ、該当するものを削除します。
• 文章校正（Sniff Test）：各段落について、Jevに10個の正誤問題（曖昧な言葉の羅列、重複する締めくくり文、「XではなくY」構文など）を尋ねます。プロジェクト自称の中央値所要時間は182ミリ秒です。
• コミット前のセキュリティゲート（jev-git）：git commitやpushを実行する前に、変更内容の中にAPIキーや破壊的なコマンドが含まれていないかを1秒以内にスキャンします。別のプロジェクトであるDiffJuryは、リスクに応じて各PRを振り分け、割り当てるレビュアーを決定します。
• スマートホーム（HA-Jev）：Home Assistantプラグイン。家庭内の状況に関する質問に対して、確率、選択肢、またはスコアで回答します。
• コンテキスト圧縮（fast-jev-compaction）：Claude Codeプラグインで、GitHubで3467個のスターを獲得しています。コンテキストウィンドウが上限に近づいた際、要約を行うのではなく、どのツール呼び出しや実行結果が今後も必要かをJevに1つずつ判断させ、不要なものを削除して必要なものは原文のまま保持します。

私たち自身が検証したいくつかの活用法

以下に挙げるユースケースは、すべて私たちがJevを実際に動かして検証したものであり、呼び出しにかかった時間や返された数値はすべて実測値です。入力データの出典は個別に明記しています：「実データ」と表記されているものは小互のニュースフィードから取得した実際のニュースを使用しており、「サンプル入力」と表記されているものはデモのために私たちが作成したテキストであり、実際のユーザーデータではありません。

見出しの「釣りタイトル度」の採点（実データ）

ニュースフィードから取得した実際の中国語の見出し30件（大半は英語の元の見出しから機械翻訳されたもの）をJevに一度に渡し、各見出しについて2つの質問を提示しました：釣りタイトル度がどの程度高いか（スコア評価：ありのままの要約 / やや目を引くが事実と乖離していない / 誇張、脅迫、煽りでクリックを誘っている）、見出しの中に具体的な数字、名称、または事実が含まれているか（是非問題）。30件の見出しに対する合計60問の判定が1回のリクエストで完了し、所要時間は1.2秒、消費された入力tokenは4923個でした。

• スコアが最も高かったのは、「AIはエリート層による「犯罪ラッシュ」か？AI技術の濫用と権力集中を批判」（AI is an elite crime spree）で1.67、具体的な事実が含まれている確率はわずか0.13でした。
• 「AIは本当に私たちを皆殺しにするのか？よくある質問と回答」（Could AI really kill us all? Your questions, answered.）は1.32、具体的な事実は0.13でした。「DeepSeekの狂気の新規アーキテクチャ」（DeepSeek’s Insane New Architecture）は1.16でした。
• スコアが最も低かったのは、「AIOpsとは何か？AIが実現するIT運用保守」（What is AIOps?）の0.04（確信度0.94）と、「LLMモデル量子化フォーマットの徹底解説：GGUF、GPTQ、AWQ、EXL2の選び方」（GGUF vs GPTQ vs AWQ vs EXL2: LLM Model Formats Explained (2026)）の0.19（具体的な事実0.95）でした。

グレーゾーンに位置する見出しは全般的に確信度が低く、例えば「Google Geminiがセキュリティテストで偶発的に「脱獄」、実在する3社への侵入に成功」（Google's Gemini also accidentally hacked three real companies during security testing）はスコア1.21でしたが、確信度はほぼ0であり、モデルが判断に迷っていることを示しています。活用方法としては、スコアが1.5を超え、かつ具体的な事実が含まれていないものに「釣りタイトル」のタグを付与し、グレーゾーンのものは自動処理を行わない、という運用が考えられます。

LLM が作成した要約に根拠があるかの検証（原文は実際のニュース、検証対象の文章は私たちが作成したもの）

原文は、ニュースフィードにあった実際のニュースの要約です：「Qwenが次世代ネイティブ・オムニモーダルモデルQwen3.8-Omni-Flashを発表。テキスト、画像、音声、動画の入力および1M tokenのコンテキストウィンドウをサポート。29のベンチマークでの平均スコアはQwen3.5-Omni-Plusと比較して25%以上向上し、音声入力の1時間あたりの料金も引き下げられた。」私たちは意図的に4つの文章を作成し、Jevに1文ずつ検証させました。2文は正しく、1文は誇張、1文は原文に記載のない内容です。各文章に対して1つの選択問題を提示しました：原文が支持している / 原文の記述と矛盾している / 原文に言及がない。1回のリクエストの所要時間は293ミリ秒でした：

• 「コンテキストウィンドウは100万tokenである」→ 原文が支持（確信度 1.0）
• 「29のベンチマークにおける平均スコアは前世代モデルと比較して50%以上向上した」→ 原文と矛盾（確信度 1.0）
• 「モデルの重みがすでにオープンソースとして公開されている」→ 原文に言及なし（確信度 1.0）
• 「動画を直接入力することが可能である」→ 原文が支持（確信度 1.0）

活用方法：文章の生成はLLMが行い、チェックをJevが担当し、「矛盾」または「言及なし」と判定された文章にフラグを立てて人間が確認する、というパイプラインを組むことができます。

皮肉（反語）の検知（サンプル入力）

私たちが作成した3つの文面について、それぞれ3つの質問（皮肉を言っているか、この文章を書いた人は満足しているか、感情の激しさはどの程度か）を提示しました。

• 「こちらのサービスは本当に素晴らしいですね、3日経っても誰も返信してくれません。」→ 皮肉 0.96、満足度 0.03
• 「カスタマーサポートの方が10分で解決してくれました。本当に素晴らしい対応でした。」→ 皮肉 0.08、満足度 0.97
• 「注文履歴では配達完了になっていますが、まだ荷物が届いていません。」→ 皮肉 0.04、満足度 0.07

「本当に素晴らしいですね」のように、言葉の表面上は褒めているものの実際には不満を訴えているような文面は、キーワードベースのルールでは識別できません。ただし、これは3つの文面による小規模なテストに過ぎません。

チャット履歴からの最終確定日時の抽出（サンプル入力）

私たちが作成した3ターンの対話文：「水曜の午後は会議が入っていまして、木曜の午前はいかがでしょうか？」「木曜の午前は都合がつきません。金曜の午後3時はいかがですか？」「大丈夫です、では金曜の15:00にテンセント会議でお願いします。」コード側であらかじめ出現した3つの候補日時を抽出して選択肢とし（さらに「不成立」の選択肢を追加）、最終的に決定した日時はどれかをJevに問い合わせました。Jevは281ミリ秒で「金曜 15:00」を選択し、確信度は1.0でした。前2つの候補日時が却下された文脈を正しく理解していることが分かります。また、会議ツールについても確信度1.0でテンセント会議と判定しました。具体的なカレンダー日付の計算や予定表への書き込み処理は、コード側に委ねます。

Agent によるコマンド実行前のリスク判定（サンプルのコマンド）

一般的な6つのコマンドを1回のリクエストにまとめ、それぞれが読み取り専用か、可逆か、不可逆かを問い合わせました。所要時間は306ミリ秒でした：

• ls -la、git status → 読み取り専用（確信度 1.0、0.99）
• rm -rf node_modules → 可逆（確率 0.86、確信度 0.78、依存関係を再インストールすれば復旧可能なため）
• git push --force origin main、curl ... | sh、psql -c 'DROP TABLE users;' → 不可逆（確信度 0.98〜1.0）

活用方法：読み取り専用かつ高確信度のコマンドはそのまま実行を許可し、それ以外は実行前に人間に確認を求めます。Flavioは、導入初期はブロックを行わずログ記録にとどめ、十分な実例が集まった段階で自動化を広げていくことを推奨しています。LangChainを利用する場合、この処理はすでに既製のミドルウェアとして提供されています。

トピックの選定を複数の次元に分解して採点する（実データ）

モデルに最初から大雑把な総合スコアを出させるのではなく、複数の次元に分解してJevに個別に判断させ、コード側で重み付け合算を行います。ニュースフィードから取得した実際のニュース4件を用いてテストを行いました：明確に説明できる仕組みや手法が存在するか（スコア評価）、読者がすぐに活用できるか（スコア評価）、純粋な資金調達ニュースであるか（是非問題）。

• ルールはコード側に記述します：純粋な資金調達ニュース（確率0.5超）は即座に除外とし、残りの2つの次元を50%ずつのウェイトで合算します。
• Qwenの新モデルはスコア0.468を獲得して採択されました。Manusの資金調達は「純粋な資金調達」の確率が0.91となり、フィルタリングされました。
• Crusoeの資金調達ニュースはデータセンターに関する言及があったため、「仕組み」の次元で0.69が付きました。もし加重平均スコアだけを見ていれば2位に入り、Astra for Lawを上回ってしまうところでしたが、「純粋な資金調達 0.81」というルールによって適切に除外されました。

次元を分解しておくことで、各項目がなぜそのスコアになったのか、なぜ除外されたのかが明確に可視化されます。配分ウェイトを調整したい場合も、コード内の数値を1箇所変更するだけで済み、モデルを再呼び出しする必要はありません。

既知の弱点と使うべきではないケース

TypeSafeは、現行バージョンであるjev-1.13向けに「既知の制限事項」という専用ページを用意しています。私たちの実測結果と照らし合わせると、日常の開発で特に陥りやすいのは以下の点です：

計算やカウントを行わせないこと：Jevは計算機ではありません。英単語の羅列の中に「banana」が何回出現するかをカウントさせたところ（正解は4回）、正解を選びはしたものの確信度はわずか0.56で、「5回」に対しても0.40の確率を割り当て、確信度は0.45にとどまりました。公式によれば、数える対象の数が多くなるほど誤答率は高くなります。集計、大小比較、割引計算などは、すべてコード側に任せてください。

日付の直接比較を行わせないこと：私たちは2つのシンプルな例（注文日時がキャンペーン期間内であるか）を試したところ、いずれも正しく判定されました。しかし公式は日付の比較は信頼性に欠けると述べており、「先週の火曜日」のような相対的な表現やフォーマットが混在している場合にはエラーが発生しやすくなります。確実なアプローチは、Jevには年、月、日の抽出のみを行わせ（実測では月の抽出の確信度は1.0、日の抽出は0.97）、日付の比較自体はコード側で行うことです。

文章を書くことはできず、候補の中から選ぶことしかできない：文章の中から金額、メールアドレス、注文番号を抽出したい場合、Jevに「出力」させることはできません。あらかじめ候補を抽出して選択肢として提示する必要があります。実測において、399元、50元、349元、89元という4つの数字が含まれる苦情文に対し、まず正規表現を1行使って金額をすべて抽出して選択肢とし、顧客が返金を求めているのはどの金額かをJevに問い合わせたところ、Jevは249ミリ秒で89元の選択肢を選び、確信度は1.0でした。Flavioの言葉を借りれば、「トランプの束から1枚を選ばせることは得意だが、カードの名前を言わせることはできない」ということです。

質問は簡潔かつ率直に書くこと：Jevは記述された質問を文字通りに解釈し、書かれていない意図を補って解釈してくれることはありません。質問と選択肢の説明が矛盾している場合（例えば是非問題で「はい」が否定を意味しているようなケースなど）は、精度が著しく低下します。質問を作成する際は、新しく入ってきたインターンに業務を指示するときのように、明確で、直接的で、曖昧さのない表現を心がけてください。

肯定と否定の2つの質問の確率を足しても、必ずしも1になるとは限らない：「同一の注文で2回二重に引き落とされた」という同一のチケットに対し、「顧客は返金を求めていますか？」と尋ねると0.56となり、「顧客は返金以外のものを求めていますか？」と尋ねると0.30となり、合計は0.86となりました。2つの質問はそれぞれ独立して計算されるため、一方の結果からもう一方を推測することは避けてください。

無関係な材料を詰め込みすぎないこと：材料の中に質問と無関係な内容が多く含まれるほど、正解率は低下します（公式ではこれを「コンテキストの腐敗」と呼んでいます）。事前にフィルタリングを行い、今回の判断に直接関係するテキストのみを渡すようにしてください。

コードで判断できるものに、Jevを使わないこと：Flavioの言葉を借りれば、「コストのかからない if は、誤りを犯す可能性のあるモデルの呼び出しよりも常に優れている」ということです。また、文章の作成や多段階の論理推論が必要なタスクには向いていないため、そうしたタスクは従来通りLLMに任せてください。

段階的な導入への提言

自身の既存フローにJevを組み込む場合、安全なアプローチはまず「シャドー監視（並行観察）」から始めることであり、いきなり判断を任せてはいけません：

1. まずは固定ルールを維持する：既存の業務ロジックをそのまま維持します。
2. サイレント並行稼働でログを記録する：重要な判断ポイントにおいてJevの呼び出しを並行して実行し、その予測結果、スコア、確信度をログに記録します。この時点では本番稼働中の処理には一切影響を与えません。
3. 正誤を確認し、閾値を設定する：実際の記録を一定数蓄積し、異なる確信度においてJevがどの程度正解していたかを検証します。許容できるエラーのコストに応じて閾値を決定します（Flavioが生徒向けに出した課題では、正解ラベル付きのサンプルを最低20件用意することを求めています）。
4. スモールステップで自動化を許可する：まずは高確信度かつ低リスクな分岐から完全自動化を適用し、それ以外のケースは引き続き人間による対応やLLMによるフォールバックを維持します。

Flavioが提案する具体的な出発点は次の通りです：現在、固定ルールの記述や、頻繁にエラーを起こす正規表現で処理している小さな判断（振り分け、承認、スキップなど）を1つ選び、AIにTypeSafeスキルを使わせてJevの選択問題に置き換えます。既存のロジックと並行して1週間確信度をログ記録し、その精度を確認した上で、実際に判断を委ねるようにしてください。