はじめに

2026年9月、TypeSafe AIが「Jev」という新しいモデルを発表してから、Jev関連の記事が急速に増えている。多くは「爆速・激安・型安全」というスペック紹介や、汎用的な活用アイデア一覧にとどまっている印象がある。

この記事はそれらとは少し違う切り口で書きたい。筆者はLangGraphでエージェント的に動作するRAGチャットボットを開発しており、Hybrid検索とGraphRAG検索を組み合わせて社内の業務文書（手順書や過去の対応履歴など）を検索・回答させている。そしてこのRAGの品質評価という、地味だが避けて通れない課題に、日々頭を悩ませている。

先日、LangChainの公式ブログで公開された、Jevをエージェント評価（agent eval）に使う実験記事を読んだ（Daniel Shea氏・Seán Roche氏による記事）。きっかけになったのは、LangChain公式アカウントの次の投稿だった。

この記事を読みながら、「これは自分たちが今まさに困っているRAG評価の課題に刺さるのではないか」と思うところがあった。

ただし断っておくと、この記事は実際に検証した結果ではなく、まだ仮説の段階である。Jevはまだ早期アクセス段階のモデルで、筆者もまだ本格的に組み込んで検証したわけではない。あくまで「RAG/生成AIエンジニアとして、自分たちの評価運用のどこに当てはまりそうか」を考えた思考の整理として読んでもらえるとありがたい。

Jevとは何か（おさらい）

Jevは、TypeSafe AIが2026年9月15日に発表した「System One モデル」という新しいカテゴリのモデルである（公式ブログ）。

通常のLLMと決定的に違うのは、テキストを生成しないという点だ。Jevには「状態（state）」と「質問（questions）」を渡す。状態は評価対象のテキストやJSON、質問は次の3種類のいずれかで定義する。

質問タイプ	内容	返り値
`Noul`	Yes/Noの二値判定	0〜1の確率
`Choice`	選択肢から1つ選ぶ	選択結果＋各選択肢の確率＋confidence
`Score`	順序尺度上の位置を判定	連続値のスコア＋各段階の確率＋confidence

トークンを逐次生成するのではなく、定義した質問すべてに対して並列に確率分布を返す設計のため、TypeSafe社は「LLMに比べて最大200倍高速、400倍安価」と主張している（公式ドキュメント）。価格は入力100万トークンあたり$0.042で、出力トークンは無料である。

先述のLangChain公式ブログの実験では、5件の天気タスクに対するエージェントの応答を、Jev・GPT-5.6 Luna・GPT-5.6 Terra・Claude Sonnet 4.6の4つの評価者に100回ずつ繰り返し判定させ、人間の評価者のラベルをオラクル（正解）として比較している。結果は次の通りだった。

二値の合否判定の一致率：Jevは500回すべてで人間の判定と一致。Terraは99.8%、Lunaは96.4%、Claude Sonnet 4.6は80.0%
連続値スコアの分散（同じ入力に対するブレの少なさ）：Jevの平均分散が最小で、Lunaの1/433、Terraの1/913、Claude Sonnet 4.6の1/92
コストと速度：平均0.44秒、1回あたり$0.00035。500回の合計で$0.34（Claude Sonnet 4.6は$28.17）

この結果自体は「天気タスク5件」という狭い範囲での実験であり、著者らも「他のエージェントや本番環境で同じ結果が出るかは未検証」と明言している。とはいえ、判断が明確に定義できるタスクにおいて、Jevが低コスト・低分散な評価者として機能する可能性がある、というのは筆者の課題感と重なるところがあった。

課題設定：ゴールデンデータの無いRAG評価

筆者が携わっているRAGプロジェクトでは、回答の品質を次の4項目・5段階で評価している。総合評価は残り3軸を踏まえて評価者が最終的に下す評価という位置づけだ。

総合評価
回答の正確性
出典の正確性
出典の網羅性

理想を言えば、ドメイン知識を持つ専門家があらかじめ「模範解答」を用意し、それをゴールデンデータ（正解データ）として評価の基準にするのが王道だろう。しかし現実には、専門家の追加工数を確保できないプロジェクトは少なくない。筆者のプロジェクトも例に漏れず、その時間が取れなかった。

そこで採っている苦肉の策が、**「4軸すべてで5点だった回答を、暫定的にゴールデンデータとみなす」**という運用である。評価者が根拠つきで5段階評価を行い、その結果を使ってゴールデンデータ候補を後から選び出す、というボトムアップ的なアプローチだ。

この運用には明確な弱点がある。5段階評価はあくまで人間の主観であり、単一の評価者の見落としや解釈のブレをそのまま引きずってしまう。「4軸すべて5点」という条件だけでは、本当にその回答が模範解答と呼べる水準にあるのかを裏付ける材料が、人間の評価以外に何もない。

仮説①：出典検証をNoul単位に分解し、Jevを第二の審判にする

ここでJevの出番ではないかと考えた。

「出典の正確性」や「出典の網羅性」という評価軸は、実は単一の判断ではなく、複数の判断が積み重なった複合的な軸である。TypeSafe社自身が公開しているクックブックでも、まさにこの発想でRAGパイプラインを組んでいる。

一つはRAGパッセージ分類のクックブックで、検索で取得した各パッセージに対して「クエリと関連しているか」「回答に使える根拠を述べているか」「クエリの前提と矛盾していないか」「モデルへの指示（プロンプトインジェクション）を含んでいないか」という4つのNoul質問を投げ、その組み合わせをコード側の閾値判定でルーティングしている。

もう一つは引用チェックのクックブックで、LLMが生成した引用（claim＋quote）に対して、まず引用元の文章中にその引用が実在するかを文字列一致で確認し、実在する場合は「その文脈が主張を支持しているか／否定しているか／何も言っていないか」をChoice質問で判定させている。

これらのパターンを、自分たちの「出典の正確性・網羅性」評価に当てはめるなら、次のような質問分解ができそうだと考えている（上記は公式クックブックの設計パターンを参考に、筆者が自分たちの評価軸向けに独自に組んだイメージ例であり、公式が提供するコードそのものではない）。

questions = {
    "chunk_exists": Noul(
        instructions="引用されたチャンクIDは、実際に検索結果の中に存在するか"
    ),
    "supports_claim": Choice(
        instructions="このチャンクの内容は、回答中の主張をどう扱っているか",
        criteria={
            "supports": "主張を裏付ける内容が書かれている",
            "contradicts": "主張と矛盾する内容が書かれている",
            "says_nothing": "主張について何も述べていない",
        },
    ),
    "uses_only_chunk_content": Noul(
        instructions="回答の主張は、このチャンクの内容だけから導けるか"
        "（チャンク外の一般知識で補完していないか）"
    ),
}

こうして分解した機械的な判定結果を、コード側で重み付けして合成すれば、「出典の正確性スコア（機械版）」のようなものが作れるはずだ。これが今の人手評価に対するチェック機構として機能するのではないか、というのが1つ目の仮説である。

仮説②：人とJevの一致・不一致を、ゴールデンデータ昇格の判断材料にする

1つ目の仮説の狙いは、単に「機械的な評価軸を追加すること」ではない。本当に価値があるのは、人間の評価とJevの評価が一致するかどうかという「差分」そのものだと考えている。

人間の評価（根拠つき5段階）とJevの評価（分解された機械判定の合成値）が一致する場合、その回答の評価はより確からしい、と言えそうだ。ゴールデンデータ昇格の条件を「4軸すべて5点」だけでなく、「かつJevの機械判定も高スコア・高confidence」という二重ゲートにすれば、単一評価者の主観だけに頼るよりも一段階信頼性の高い出発点になるのではないか。
逆に一致しない場合は、そのケースこそレビューの優先度を上げるべき対象になる。限られたレビュー工数を、機械と人間の意見が割れているケースに集中投下できる。

これは、冒頭で紹介したLangChainの実験がやっていたこと（Jevの判定と人間オラクルの一致率を測る）を、そのまま自分たちの運用に取り込む発想でもある。

ただし、この仮説には重要な留保が要る。人間とJevの評価が一致することは、「その評価が正しいことの証明」にはならない。両者が同じ盲点を共有している可能性は常にある。例えば、検索対象のドキュメントが古い版のまま更新されていなかった場合、人間もJevもその古い内容を前提に判定してしまい、両者は一致するが、判定そのものは誤っている、というケースはあり得る。したがって、一致率の高いゴールデンデータ候補群からも、一定割合はランダムに人が抜き取って確認する仕組みは残しておく必要があるだろう。

まだわからないこと

仮説として魅力を感じている一方で、検証しないと判断できないことも多い。

Jevの精度・分散の低さは、TypeSafe社の自社ベンチマークや、天気タスク5件という狭い実験に基づくものであり、独立した第三者による再現検証はまだ無い。
多言語対応、特に日本語のような非英語圏の言語での精度は、公式には評価が公開されていない。筆者のRAGは日本語の業務文書を対象にしているため、これは特に確認が必要な点だ。
confidence（確信度）が、自分たちのドメイン（専門的な業務文書）でどれくらい意味を持つ数値になるかは、実際に自分たちのデータで試してみないとわからない。
Jevは早期アクセス段階のプロダクトであり、モデルのバージョンやAPIの仕様が今後変わる可能性がある。

まとめ

この記事で書いたのは、あくまで仮説である。「ゴールデンデータが無い」というRAGプロジェクトにありがちな制約に対して、Jevを人間の評価と併走させる第二の審判として使えば、評価の確からしさを底上げできるのではないか、という考察にとどまる。

次のステップとして、実際に自分たちのRAGのトレースデータの一部にJevを適用し、人間の評価との一致率を測ってみたい。結果が出たら、その検証結果は別記事として改めて報告する予定である。

同じようにRAG評価でゴールデンデータの確保に苦労している方がいれば、ぜひ意見交換したい。

参考文献

TypeSafe AI公式ブログ「Introducing System One Models & Jev」: https://typesafe.ai/blog/introducing-system-one-models-and-jev
TypeSafe AI公式ドキュメント「Quickstart」: https://docs.typesafe.ai/introduction/quickstart
TypeSafe AI公式クックブック「Classifying RAG passages」: https://docs.typesafe.ai/cookbooks/classifying_rag_passages
TypeSafe AI公式クックブック「Double-checking citations」: https://docs.typesafe.ai/cookbooks/citation_check
LangChain公式ブログ「Can Jev Be a Better Agent Evaluator?」（Daniel Shea, Seán Roche）: https://www.langchain.com/blog/jev-agent-evals-langsmith
LangChain公式アカウントによる紹介ポスト: https://x.com/LangChain/status/2101454284927959080
Valyu AI「How to Use Jev: A practical guide to TypeSafe's System One model」: https://dev.to/valyuai/how-to-use-jev-a-practical-guide-to-typesafes-system-one-model-g5e
Flavio Copes「A deep dive into Jev, TypeSafe's System One model」: https://flaviocopes.com/jev/