判断だけを行う超高速AI
「Jev」がRAGを変える

第2章では、Corpus2Skillが「高精度だが、探索のたびにLLMを呼ぶため遅くて高い」というジレンマを抱えていることを見ました（第2章を読む）。原因を突き詰めると、フォルダを1つ選ぶという単純な選択作業に、文章を書くための重い推論エンジンを使っていることに行き着きます。

この章では、その選択作業だけを肩代わりする新しい種類のモデル「Jev」を取り上げます。仕組み、速度と価格、得意なこと・苦手なことを整理したうえで、「RAGを速くしたいからJevを入れたい」と考えたとき、どこに組み込むのが最も筋が良いのかを比較します。

System 1とSystem 2

Jevを開発したのは、米サンフランシスコのスタートアップTypeSafe AIです。CEOのDiogo Almeida氏は元OpenAIの研究者で、同社はDCVC主導で4,000万ドルのシード資金を調達したと報じられています。Jevは2026年9月中旬にウェイトリスト制の早期アクセスとして公開されました。

同社はJevを「System One」モデルと呼んでいます。由来は、心理学者ダニエル・カーネマンが『ファスト&スロー』で広めた人間の2つの思考モードです。

直感の思考と熟考の思考

System 1は、顔を見て誰かを見分ける、簡単な足し算に即答するといった、速く無意識に働く思考です。System 2は、複雑な計算や文章の組み立てのように、意識的に時間をかけて進める思考です。

ChatGPTやClaudeのような大規模言語モデル（LLM）は、思考過程を文章として書き出しながら答えを導くため、System 2寄りの存在と位置づけられます。これに対してJevは、ソフトウェアの内部に組み込まれ、「この入力ならこちら」と瞬時に判断を返すSystem 1の役割に特化しています。Vercelはその性格を「ソフトウェアのための確率的な意思決定モデル」と表現しました。

文章を書かないから速い

LLMは回答を1トークンずつ順番に生成します。「次は人事フォルダを開きます」という短い一文でも、数十回の計算を繰り返すデコードループが必要です。Jevにはこのループがありません。入力を一度読み込み、あらかじめ定義された選択肢に対する確率分布を一回の計算で返します。

出力の選択肢がスキーマで事前に固定されているため、存在しないフォルダ名を答える、JSONの形式を崩すといった「形式上のハルシネーション」は構造的に起きません。ただし、これは形式の話であり、並んだ選択肢の中から誤ったものを選ぶ可能性は残ります。この区別は後の設計で重要になります。

Jevが返せる3つの判断

Jevへの問いかけは、型の決まった「質問」として定義します。テキスト用途で使うのは主に次の3種類です（画像内の位置を返す box 型も jev-1.14.0 以降で提供されています）。

重要なのは、複数の質問を1回のリクエストにまとめて送れることです。質問は並列に評価されるため、「どのクラスタか（choice）」と「緊急か（noul）」、さらに「候補文書30件それぞれが必要か（noul×30）」を同時に尋ねても、往復は1回で済みます。入力の上限は、状態と全質問の合計で6万4千トークン程度です。

実際の呼び出しは次のような形になります。ここでは当サイト運営でも利用している再販サービス経由の /api/v1/decide 形式を示します（公式API、Vercel AI Gateway、OpenRouterでもフィールド構成はほぼ共通です）。

{
  "model": "jev-1.13.0",
  "state": "出張先のホテル代は役員でも上限1万円ですか？",
  "questions": {
    "cluster": {
      "type": "choice",
      "instructions": "回答に参照すべき知識クラスタを選ぶ",
      "criteria": {
        "hr_travel": "出張・旅費・宿泊費・日当の規程",
        "hr_leave": "休暇・休職・勤怠の規程",
        "billing": "請求・支払い・インボイス",
        "other": "どれにも該当しない"
      }
    },
    "is_urgent": {
      "type": "noul",
      "instructions": "利用者は期限が迫った至急の対応を求めている"
    }
  }
}

{
  "model": "jev-1.13.0",
  "answers": {
    "cluster": {
      "choice": "hr_travel", "confidence": 0.91,
      "probabilities": {"hr_travel": 0.91, "hr_leave": 0.04, "billing": 0.03, "other": 0.02}
    },
    "is_urgent": {"noul": 0.12}
  },
  "usage": {"input_tokens": 182, "cost_usd": 0.0000764}
}

返り値はそのままプログラムの分岐に使える数値です。LLMの出力を正規表現で解析したり、JSONの崩れに備えて再試行したりする処理が要りません。本番ではモデル名を jev-latest ではなくバージョン固定にし、確信度の閾値がモデル更新で動かないようにするのが推奨されています。

速度と価格のインパクト

TypeSafe AIは、エンドツーエンドの応答時間を70〜500ミリ秒と公表しています。DataCampが紹介した同社の評価（セキュリティ対応、エージェント監視、請求書処理、カスタマーサービスの4業務。GPT-6 AstraとFableの平均予測を正解基準とする）では、次の結果が示されました。

コストは汎用LLMの数十分の一から数百分の一、応答時間は25〜95分の1程度です。独立した検証としては、ある開発者が約5,000回の呼び出しで費用約2ドル、応答の中央値約150ミリ秒・95パーセンタイル約350ミリ秒だったと報告しています。ただしこれは個人の報告であり、正式なベンチマークではありません。

Corpus2Skillの探索は選択問題

ここで、Corpus2Skillのサーブ時の動きを思い出してください。エージェントは鳥瞰ビューを読んでトップレベルのスキルを選び、配下のINDEX.mdを読んで次の枝を選び、最後に文書IDを特定して全文を取得します（スキルツリー構造の解説）。最終的な回答文を書く工程を除けば、すべて「示された候補からどれを選ぶか」という判断です。

255択がツリーを浅くする

Corpus2Skillの既定設定では、トップレベルのスキルは8個以内、各ノードの子は10個程度に抑えられます。LLMに一度に見せる選択肢が多すぎると判断が乱れやすく、要約を読む量も増えるためです。その結果、木は深くなり、1段降りるごとにLLMの呼び出しが1回増えます。

Jevのchoiceは1回で最大255の候補を扱えます。選択肢の数が増えても応答時間はほぼ変わらないため、木を「浅く広く」作り直せます。8×10×10の3段構造なら、同じ800前後の末端を、200程度のクラスタと各クラスタ配下の文書リストという2段構造に置き換えられます。探索の往復回数がそのまま減るのです。

ここで生まれるのが、探索と抽出はJevが担い、最後の回答文だけをLLMが書くという2層の分業です。人間が目次を順にめくるような直列の探索が、ほぼ2往復の判定に置き換わります。具体的な実行パイプラインは第4章で組み立てます。

RAGにJevを足す3つの型

「RAG Jev」で情報を探している方の多くは、すでにベクトル検索のRAGを運用していて、その遅さや精度の不満をJevで解消できないかと考えているはずです。考えられる組み込み方は大きく3つあります。

パターンAとBは導入が手軽で、すぐに効果を試せます。しかし、どちらも検索の対象はチャンクのままです。第1章で見た「ただし書きが別のチャンクに分かれて捨てられる」という断片化の問題（第1章）は残ります。Jevが速く賢く並べ替えても、そもそも候補に入っていない断片は救えません。

パターンCは、事前にコーパスをスキルツリーへコンパイルする手間がかかります。その代わり、Corpus2Skillが抱えていた唯一の大きな弱点である探索の遅さとコストを、Jevがそのまま打ち消します。精度の土台は原文全文、速度の土台はJevという組み合わせで、両者の長所だけが残ります。本特集が「RAGを高速化したいなら、Jevはベクトル検索の後ろではなくスキルツリーの道案内役に」と提案する理由はここにあります。

限界と使いどころ

Jevは万能ではありません。設計に入る前に、次の制約を前提として押さえておく必要があります。

理由を説明しない

Jevは確率を返しますが、なぜその選択肢を選んだかは説明しません。規制業種の監査のように判断の根拠を記録する必要がある場面では、Jevの判定だけでは足りません。確信度が高い判定だけを自動で通し、それ以外はLLMや人に回す運用が推奨されています。Corpus2Skillとの組み合わせでは、最終回答が原文を根拠にするため、探索経路のログと原文の出典を残せば説明責任の大部分は補えます。

多段の推論と自由な生成はできない

Jevには推論時の思考過程がありません。「AとBを比べてから、条件Cに当てはめる」といった多段の判断は苦手です。もちろん文章、コード、要約も書けません。選択肢があらかじめ分かっている問題に限って使う、という線引きが大切です。

速さの理由への異論

エンジニアのSean Goedecke氏は、Jevの高速性の多くはプロンプトの事前処理（prefill）の最適化や、1トークンだけに制約した出力など、既存の技術でも得られるものだと指摘しています。仕組みが革新的かどうかと、実務で使えるかどうかは別の問題ですが、ベンダーの宣伝文句をそのまま信じず、自社のデータで測ることが欠かせません。

日本語での実体験

当サイトの運営でも、日本語の解説ページを入力に、広告を置く位置の適否をJevで判定したことがあります。費用は1ページあたり約0.0004ドルと期待どおりでしたが、noulの値がどの位置でも0.65〜0.71の狭い範囲に固まりました。そこで絶対的な閾値で合否を決めるのをやめ、ページ内での相対的な順位で上位を採用する方法に切り替えています。確率値をそのまま信じるのではなく、分布を見てから閾値を決める姿勢が、日本語環境では特に重要だと考えています。