JevとLlamaを比較！100本の論文仕分けで判明した3倍高速化の実効性

• 事実と背景：競馬論文100本の仕分けにおいて、構造化データ特化型モデルJevとLlama 3.3 70Bの速度・コストを実測比較。
• 技術的変革：Jevは文章生成をせず確率付き構造化データを直接返すため、Llama比で中央値約3倍の高速化と高い判定安定性を実現。
• 現場への影響：JSONパースエラーから解放される一方、入力トークン増によるコスト増に注意し、前処理パイプラインへ戦略的に導入すべき。

開発現場でLLMを使ってデータを分類・構造化しようとしたとき、我々エンジニアが必ず直面するのが「JSONパースエラー」という悪夢だ。プロンプトにどれだけ「JSON形式でのみ出力してください」と懇願しても、LLMは気まぐれに余計な前置きを出力したり、閉じ括弧を忘れたりして、深夜のバッチ処理を容赦なくデッドロックさせる。この「生成AIの気まぐれ」を制御するために、どれほどのエンジニアがスキーマ定義やリトライ処理というスパゲッティコードを量産してきたことか。

こうした不毛な開発者体験に対する強力なアンサーとして登場したのが、TypeSafe AIが提供する「Jev」である。Jevは、一般的なLLMのように「文章を生成する」というプロセスを一切踏まない。与えられたテキスト（state）に対し、事前に定義した質問（questions）への回答を、yes/no（noul）、択一（choice）、段階評価（score）といった構造化データとして、確率付きで直接返す仕組みだ。

私はこのアプローチを極めて合理的だと考える。なぜなら、我々が実務でやりたいことの多くは、自由な文章生成ではなく、データの「仕分け」や「フィルタリング」だからだ。個人開発者が競馬の学術論文100本を収集し、そこから「実際にバックテスト可能な売買ルールが書かれているか」を判定するパイプラインを構築した事例は、Jevのポテンシャルを証明する格好のユースケースである。キーワード一致による単純なルール（heuristic）では、100本中87本を「実装可能」と過大評価してしまったのに対し、Jevは文脈を読み解き、真に価値のある5本（あるいは閾値を下げた14本）へと見事に絞り込んだ。この精度と安定性こそ、構造化特化型モデルがもたらす最大のブレイクスルーなのだ。

では、Jevは実際の開発現場において、一般的なLLMと比べてどれほどのパフォーマンスを発揮するのだろうか。Workers AIでホストされている高速モデル「Llama 3.3 70B fp8-fast」と、Jevを同一環境（Cloudflare AI Gateway経由）で直接対決させた実測データは、我々に極めて興味深い事実を突きつけている。

まず、速度面においてはJevの圧倒的な勝利である。所要時間の中央値は、Llama 3.3 70Bが1,441ミリ秒（1.44秒）かかったのに対し、Jevはわずか484ミリ秒（0.48秒）と、約3倍の高速化を達成した。さらに注目すべきは「遅延の安定性」だ。Llamaは15回中1回、14.8秒という巨大なスパイク（遅延）を発生させ、すべての呼び出しで1秒を超えた。これに対し、Jevは初回のコールドスタート（3.7秒）を除けば、すべて356〜909ミリ秒の範囲に収まっている。APIのタイムアウトやユーザー体験の低下を防ぐ上で、この「最悪値の低さ」はインフラエンジニアにとって何よりも心強い。

しかし、コスト面においては意外な逆転現象が起きている。1本あたりの処理コストを比較すると、Llamaが$0.00030であるのに対し、Jevは$0.00045と、約1.5倍高価なのだ。Jevは出力トークンが無料であるにもかかわらず、入力トークン数がLlamaの約1.6倍（1,080トークン vs 681トークン）に膨らんだことが原因である。これは、Jevがリクエスト時に送信する質問定義（特に選択肢のcriteriaなど）を内部で展開してカウントしているためと推測される。

以下に、実測された詳細なスペック比較をテーブルで示す。

この結果から私が導き出す結論は、Jevの真の価値は「コスト削減」ではなく、「超高速かつパースエラーが原理的に発生しない堅牢なパイプラインの構築」にあるということだ。1万本の処理でもコスト差はわずか1.5ドル程度であり、開発者がJSONのパースエラー処理やリトライロジックを書く人件費を考えれば、Jevを選択する合理性は極めて高い。

しかし、技術的にどれほど優れたパイプラインを構築しようとも、我々エンジニアが最終的に直面するのは「現実のデータ」という冷徹な壁である。Jevによって100本の論文から14本に絞り込み、その中から実際にバックテスト可能と判断された「騎手の連勝効果」に関する論文（Falveyら、2024年）を、2011〜2025年のJRA実データで検証した結果は「不合格」であった。事前に定義した厳格な売買ルールに合致する騎手が1人も現れず、賭け自体が一度も発生しなかったのだ。

この結果は、我々に重要な教訓を与えている。AIによる仕分けや要約は、あくまで「前処理の高速化」に過ぎず、ドメイン知識に基づく仮説検証の泥臭いプロセスを代替するものではない。Jevを使って1万本の論文を数ドル・数時間で仕分けたとしても、その後に控える「原著の精読」「データ構造の不一致の解消」「バックテストコードの記述」という本質的なエンジニアリングのボトルネックは依然として残る。

我々エンジニアは、明日からどう行動すべきか。まず、何でもかんでも「生成AI（LLM）」に丸投げし、プロンプトの微調整に時間を溶かす「生成信仰」から脱却することだ。データの分類や構造化抽出といったタスクには、Jevのような「非生成型・確率出力モデル」をパイプラインの前段に戦略的に組み込むべきである。そして、浮いた時間とリソースを、ドメインデータの整備や、バックテスト環境の構築といった「人間にしかできない本質的な検証作業」に集中させること。

最後に、業界全体へ痛烈な問いを投げかけて本稿を締めくくりたい。我々はAIの進化によって「仮説を検証するスピード」を劇的に向上させた。しかし、その手元にある「検証対象のデータ」や「ドメイン知識」は、AIのスピードに追いついているだろうか。ツールがどれほど高速化しても、インプットするデータの質と、それを評価する人間の仮説構築力が貧弱であれば、我々はただ「高速にゴミを生産している」だけに過ぎないのではないか。