RAGの高速化・コスト削減にJevを使う ― ベクトル検索ではない「Corpus2Skill」と組む2層設計

RAG（社内文書などを検索してLLMに答えさせる仕組み）を速く、安くしたい。そのために、2026年9月に出た判定専用のAI「Jev」を試せないか。この記事は、そう考えている方に向けて書きました。

Jevは文章を書かず、決めた選択肢の中から答えを選んで、その確信度を返すモデルです。RAGに入れるなら、まず思いつくのは「質問をどの担当や資料群に振り分けるか」「検索で拾った文書が本当に関係あるか」の判定でしょう。ベクトル検索の前後に付ける使い方です。

ただ、Jevの性質が一番生きるのは、別の形のRAGかもしれません。ベクトル検索を使わず、AIに資料の「目次」をたどらせるCorpus2Skillという方式です。精度は高いのに遅くて高いのが弱点でしたが、その遅さの原因が、ちょうどJevの得意な判断なのです。この記事では、両者を組み合わせた設計と、1問あたりの費用の試算をまとめます。

この記事は設計案と試算です。この構成を本番で動かしたり、応答時間を実測したりはしていません。仕様と価格は2026年11月4日時点の公開情報で確認しています。Jevの基本は「確度付きIF文」として解説した記事に、Corpus2Skillの詳しい仕組みは4月の前編と自作した実践編に書いています。

ベクトル検索ではないRAG、Corpus2Skillという選択肢

一般的なRAGは、文書を細かく切り分けてベクトル化し、質問に近い断片を拾ってLLMに渡します。速くて安い一方、切り分けた時点で前後の文脈が抜け、答えに必要な部分を取りこぼすことがあります。

Corpus2Skillは、2026年4月にarXivで公開された論文（arXiv:2604.14572）の手法です。「Don't Retrieve, Navigate（検索するな、たどれ）」という言葉のとおり、断片を検索する代わりに、エージェントに目次をたどらせます。事前のコンパイルで文書群をクラスタリングし、LLMで要約して、階層ごとに SKILL.md（その枝の説明）と INDEX.md（配下の一覧）を作ります。原文は切らずに documents.json に置きます。質問が来たら、エージェントが目次を読んで次の枝を選び、最後に原文を読んで答えます。

精度ははっきり上がりますが、費用はベクトル検索のRAGの20倍ほどです。待ち時間も軽くありません。枝を1段降りるたびに、LLMが目次を読み、次の行き先を文章として書き出すからです。1問の平均は2.38ターンで、表の費用はプロンプトキャッシュを使った後の数字です。なお、費用の数字は論文の版によって違います。第2版ではキャッシュなしで約0.172ドル、キャッシュありで約0.089ドル、第3版とGitHubのREADMEではキャッシュなしで約0.302ドル、キャッシュありで約0.153ドルです。目次をたどるモデルを安いHaiku 4.5に替えると約0.09ドルに下がりますが、ターン数が増え、ハルシネーションも増えたと報告されています。私が実践編で作ったボットも、ツールを呼ぶたびにClaudeが1往復する作りでした。

目次をたどる1歩は「選択問題」だった

エージェントが目次の前でしていることを分解すると、「この質問は、どの枝の話か」「この文書は、質問に関係あるか」という判断の連続です。答えは選択肢の中にあり、自由な文章は要りません。

Jevは、まさにこの形の判断のためのモデルです。TypeSafe AIが2026年9月に公開したモデルで、文章を生成しません。状態（今回は利用者の質問）と質問を渡すと、選択肢ごとの確率や確信度が返ってきます。APIリファレンスによると、主な質問の型は次の3つです。

設計の上で効いてくるのは、1回のリクエストに複数の質問を混ぜられることです。公式のモデル説明では、状態を一度読み込み、すべての質問をそれに対して並列に評価すると書かれています。料金は入力100万トークンあたり0.042ドルで、出力は無料です。

Jevに合わせて、ツリーを広く浅く作り直す

LLMをJevに差し替えるだけでも効果はありますが、ツリーの形もJevに合わせた方が得です。choiceは一度に最大255の選択肢を比べられるので、1段あたりの分岐を大きくし、階層を浅くします。たとえば1万件の文書なら、第1層を約250のクラスタ、各クラスタの配下を約40件にすれば、2段で文書までたどり着けます。

公式ライブラリのコンパイル設定でこの形が作れるかは確認していません。実践編のようにツリーを自作する場合は、クラスタ数を決める処理を変えるだけで済みます。質問が来たときの流れは、次の3段階になります。

スマートフォンなど画面幅が狭い場合は、図を左右にスクロールできます。

1. 1段目：枝を選ぶ：質問を状態として渡し、約250のクラスタの説明を選択肢にしたchoiceで、行き先を1回で選びます。同じリクエストに、緊急度を測るscoreや、「社内規程の質問か」を確かめるnoulを混ぜておけば、振り分けも同時に済みます。
2. 2段目：文書を選ぶ：選んだクラスタの INDEX.md にある文書の要約を、1件ずつnoulの質問にして並べ、関係がありそうなものを抜き出します。1段目の確信度が低いときは、迷った上位2〜3のクラスタに同時に広げます。外れたときにやり直すより、少し多めに見る方が安くつくからです。
3. 3段目：回答を書く：選んだ文書の原文と質問だけを、Claude Haiku 5.5やSonnet 5.5のようなLLMに渡して回答を書かせます。LLMが目次を読む工程がなくなるので、渡す文章は回答に必要な分だけになります。

1問あたりの費用を試算する

1万件の文書、上の2段構成で試算しました。トークン数は文章量からの概算です。JevとClaudeではトークンの数え方が違い、日本語ではさらにずれるので、桁の目安として見てください。為替は1ドル150円にしています。

価格は、Jevが入力100万トークンあたり0.042ドル（出力は無料）、Claudeの料金表ではHaiku 5.5が入力0.10ドル・出力0.50ドル（10万トークン以下のプロンプト）、Sonnet 5.5が入力2ドル・出力10ドルです。月1万問なら、Haiku構成で約18ドル、Sonnet構成で約260ドルになります。

論文の約0.15ドルとそのまま比べるのは公平ではありません。論文はひとつ前の世代のSonnet 4.6（入力3ドル・出力15ドル）の価格で、ベンチマークも違います。それでも、目次をたどる工程にかかる費用が、Jevでは0.001ドルを下回る見込みになる、という桁の違いは読み取れます。探索の費用がほぼ消えるので、回答の品質に合わせてLLMを選ぶ余地が残ります。

応答時間も、探索の段でLLMが文章を書き出さないぶん短くなるはずです。TypeSafe AIは発表で、Jevの応答時間を70〜500ミリ秒としています（VKTRの報道）。ただし、これは同社が公表した値で、独立した検証はまだ見当たりません。APIドキュメントにも具体的な数値は載っていません。チャットに組み込むなら、日本からの回線と自分のデータで測ってから判断してください。

実際に動かす前に確かめたいこと

社内の言葉で、確信度がどこまで信用できるか

Jevの強みは、較正された確信度です。ただ、その較正がどの業務でも保たれるとは限りません。2026年10月に公開されたVals AIの独立評価では、有価証券報告書をもとにした主張の検証では較正誤差が12のシステム中で最も小さかった一方、法律の推論問題（LegalBench）では最も大きく、正解率も最下位でした。あるサブタスクでは33問すべてに「はい」と答えています。タスクが変われば、確信度の意味も変わりうるということです。

社内規程や社内用語は、Jevにとってなじみのない入力になりがちです。対策は2つあります。1つは、コンパイルで作る枝の説明に、その枝に入るもの・入らないもの、社内の略語の意味を具体的に書いておくことです。もう1つは、以前の記事でも書いたとおり、過去の質問を100〜300件ほど用意し、Jevの選択と正解を突き合わせて、確信度ごとの正解率を測ってから閾値を決めることです。

日本語では、閾値を保守的に

Jevの公式のモデル説明には、英語が主な学習言語で最も精度が高く、日本語を含むCJKも扱えるが同じ水準ではない、と明記されています。日本語の質問を扱うなら、1つの枝に絞り込む確信度の閾値を高めにとり、迷ったときは複数の枝に広げる設定を積極的に使います。枝の説明や文書の要約は、コンパイル時に英語で書いておく手もあります。日本語の質問と英語の説明の組み合わせでどこまで精度が出るかは、試して確かめる必要があります。

部署をまたぐ質問は、別の索引で補う

Corpus2Skillは、基本的に1つの文書を1つの枝に割り当てます。論文の第1版はこの「1つの経路への割り当て」を限界として挙げていました。第3版では、複数の話題にまたがる文書を別の枝からも参照できる仕組みが加わりましたが、それでも最上位の枝選びの誤りが失敗の大半を占めるとしています。案件名や製品名のように、いくつもの部署の文書に出てくる固有名詞の質問は、どれか1つの枝をたどるだけでは拾いきれません。

この弱点を補う考え方として、2026年9月に別のチームが公開したCorpusMapがあります。文書に出てくる固有名詞ごとのページを作り、そこから言及している文書へリンクを張る索引です。Corpus2Skillと組み合わせた実装例は見当たりませんが、「固有名詞は逆引きの索引で、話題はツリーで」と役割を分けるのは、設計としては筋がよいと考えています。

RAGを速くしたいなら、探索の形から見直す

RAGを速く、安くしたいとき、Jevをベクトル検索の前後に足して振り分けや選別を任せるのは、手堅い第一歩です。ただ、精度も一緒に上げたいなら、Corpus2Skillのように目次をたどる形も選択肢に入れてみてください。この方式の弱点だった遅さと費用は、行き先を選ぶ判断をJevに任せ、文章を書く仕事だけをLLMに残すことで、試算の上では探索1回あたり0.001ドルを下回るところまで小さくできます。

一方で、確信度の較正が社内の言葉や日本語でも保たれるかは、自分のデータで測るまでわかりません。次は、実践編のSQLite版ボットの探索部分をJevに差し替え、社内規程の質問で正解率と応答時間を測ってみるつもりです。

※2026年11月時点の公開情報に基づきます。価格や仕様は変更されることがあります。費用は記事中の前提による試算で、実測値ではありません。

確認した情報

• Sun et al.: Corpus2Skill（arXiv:2604.14572）、GitHub: dukesun99/Corpus2Skill — 構造、WixQAの結果、1問あたりの費用、限界。
• TypeSafe AI: API Reference、Models — 質問の型、選択肢の上限、並列評価、価格、対応言語。
• VKTR: ChatGPT co-creator launches TypeSafe AI with Jev — TypeSafe AIが公表したJevの応答時間（70〜500ミリ秒）。
• Anthropic: Pricing — Claude Haiku 5.5、Sonnet 5.5、Sonnet 4.6の価格。
• Vals AI: Independent evaluation of Jev — タスクごとの較正誤差と正解率。
• 特集「RAG×Jev ― Corpus2Skillで社内AI検索を高速・低コスト化」 — 本記事の設計を全5章で詳しく解説し、Python実装コードを掲載。
• Jeong et al.: Follow the Entities: A Corpus Map for Agentic Search（arXiv:2609.37226） — 固有名詞を軸にしたナビゲーション層。

各情報は2026年11月4日に確認しました。論文の数値は版によって異なるため、本文では版を明記しています（2026年11月4日、第2版の費用とJevの公表応答時間を追記）。