【Jev vs Gemini】BigQuery分類でコスト41%削減と2倍高速化を実証

• 検証結果：Stack Overflow分類でJevはAccuracy 86.5%を達成しGeminiと同等精度を記録
• コスト・速度差：Gemini 2.5 Flash-Lite比で推論費用は約41%安く、中央レイテンシは2倍高速
• 現場への影響：BigQueryでのRemote Function運用時はLIMIT先行評価や重複実行の課金リスクに注意が必要

深夜、データ基盤のバッチ処理アラートで叩き起こされ、コンソールを開くと見慣れない桁のBigQueryスキャン・推論費用が請求額に積み上がっている――そんな悪夢を経験したデータエンジニアは私だけではないはずだ。BigQueryの「AI.GENERATE」をはじめとするSQLネイティブなAI関数の登場は、アナリストやエンジニアが数十万行のテキストデータを1行のクエリで分類・抽出できるという圧倒的な開発生産性をもたらした。しかし、その裏にあるのはトークン従量課金という冷酷な現実である。10万行のテーブルに対して単純なプロンプトを投げるだけでも、推論は10万回走り、処理対象が日次で数百万行に達するメガベンチャー規模の基盤では、ちょっとした分類処理が月末のクラウド破産を引き起こしかねない。

「そもそも、20個の選択肢から1つを選ぶだけの単純なカテゴライズに、長文の論理展開までこなせる汎用巨大言語モデルを呼ぶ必要があるのか？」という疑問に、我々は常に直面してきた。そこで突如として脚光を浴びているのが、TypeSafe社が開発しVercel AI Gateway等からも利用可能な意思決定特化型モデル「Jev」である。Jevは一般的なチャットモデルのように長大な文章を生成するのではなく、「選択肢から1つを選ぶ」「数値を割り振る」といった判断タスクだけに特化して極限まで軽量化されたモデルだ。価格設定も入力100万トークンあたり0.04ドル、2026年9月25日までは出力無料と、既存の軽量LLMの相場をさらに破壊する水準に設定されている。

万能な巨大モデルを盲信して全データを突っ込む時代は終わり、ワークロードの性質に応じて極小モデルへルーティングする設計思想が現実味を帯びてきた。データ基盤の現場において、このJevがBigQueryと組み合わさった際にどれほどの実利をもたらすのか、技術コミュニティに身を置く者として詳細な検証データを紐解いていきたい。

今回の検証では、BigQuery Public Datasetsに格納されているStack Overflowの投稿データ（bigquery-public-data.stackoverflow.posts_questions）から上位20タグ・単一タグの質問200件（各タグ10件）を抽出し、質問文（最大4,000文字）から正しいプログラミング言語・技術タグを1つ推論させるタスクが設定された。「javascript」「python」「java」といった明確な区分だけでなく、「ios」と「iphone」、「sql」と「mysql」、「.net」と「c#」のような極めて紛らわしい近接カテゴリが意図的に含まれており、分類モデルの識別能力を試すには申し分ない設計だ。

BigQueryからRemote Function、Cloud Runのアダプター、そしてVercel AI Gatewayを経由して各モデルを呼び出す同一条件下で実行されたベンチマーク結果は、驚くべき実用性を示している。

注目すべきは、JevがGemini 2.5 Flash-Liteの86.0%をわずかに上回る86.5%の正解率（Accuracy）を叩き出しながら、推論コストを約41%削減している点だ。200件中182件で両者の予測は完全に一致しており、Jevのみ正解が9件、Geminiのみ正解が8件と、精度の質的差はほぼ存在しない。それどころか、行単位の中央レイテンシ（p50）はJevが368msに対しGemini 2.5 Flash-Liteは736msと、約2.0倍の圧倒的な高速性を示した。95パーセンタイル（p95）でも677ms対1,013msと明確にJevが優位である。

10万件換算で4.52ドルというJevのコストは、月間数千万行を処理するETLパイプラインにおいて決定的な差となる。さらに最新鋭のGemini 3.1 Pro Previewは最高精度の87.0%を記録したものの、正解数の増加は200件中わずか1件に過ぎず、コストはJevの約61倍（10万件あたり275.42ドル）に跳ね上がる。明確な選択肢が存在する分類タスクにおいて、無暗にフロンティアモデルを投入することがいかに費用対効果を損なうかが、数字によって如実に証明されたと言える。

現場のアーキテクトであれば、「軽量モデルで粗く分類し、確信度の低い曖昧なレコードだけをProなどの強力なモデルへ渡す二段階判定（カスケードルーティング）」を誰もが思いつくだろう。しかし、今回の検証ではその安易な最適化が手痛い罠となることが浮き彫りになった。

誤分類の約8割が「ios / iphone」「sql / mysql」などの近接カテゴリに集中していたため、予測結果がこれら15タグに該当したレコードをGemini 3.1 Proに再判定させる二段階構成が試みられた。結果は無残なもので、Jev起点では正解が4件増えた一方で5件が悪化（Accuracy 86.0%へ低下）、Gemini 2.5 Flash-Lite起点でも8件修正に対し10件が悪化（Accuracy 85.0%へ低下）し、いずれも全件Pro単体（87.0%）より低い精度に沈んだ。200件中148件が再判定に回ってしまい、コスト削減の恩恵も吹き飛んでいる。モデルの「近接カテゴリ」という静的ルールだけでルーティングを行うと、モデル固有の推論バイアスが衝突し、かえって判定を濁らせるという教訓だ。実戦で二段階構成を組むならば、信頼度スコア（Confidence）や複数回サンプリングの不一致度など、動的な不確実性を捉える指標が不可欠となる。

さらに、BigQuery Remote Functionを用いた実装には、クラウドアーキテクチャ特有の落とし穴が潜んでいる。開発時の疎通確認でありがちな「SELECT … LIMIT 1」を実行した場合、BigQueryのクエリプランナはLIMIT処理の手前でRemote Functionを200件すべて先行評価してしまうケースがある。実際、検証ログではクエリをキャンセルするまでにGemini 3.1 Proの呼び出しが313回発生し、意図せぬ0.87ドルの無駄遣いが発生した。また、Remote Functionは内部的な再試行によって外部APIを重複実行するリスクを常に孕んでいる。データ基盤に外部推論を組み込む際は、事前に少量の物理テーブルを切り出すこと、リクエストIDによる冪等性を確保すること、推論結果を中間テーブルへキャッシュして同一行の再計算を防ぐ防壁を組むことが鉄則である。

Jevが示した「意思決定特化型極小モデル」の価値は、単なるAPI単価の安さやレイテンシの低さにとどまらない。それは、これまで生成AIの文脈で語られがちだった「LLMによる自動化」を、古典的かつ堅牢な「データエンジニアリングのコンポーネント」へと引き戻した点にある。長文のハルシネーションや不規則なJSONフォーマット崩れに怯えながら高価なトークンを消費する時代から、選択とスコアリングだけに責任を持つ専用マイクロモデルをパイプラインの適材適所に配置するアーキテクチャへのシフトである。

OpenAIやGoogle、Anthropicといったメガテックも、今後は同様の意思決定・ルーティング特化の極小エンドポイントを追従して提供してくる可能性が高い。いずれはBigQueryネイティブな組み込み関数としてJevのようなアーキテクチャが直接選べる日が来るだろう。しかし、我々エンジニアが今すぐ問われているのは、そうした新技術の登場をただ待つことではなく、「自社のデータ基盤におけるタスクの解像度をどこまで上げられているか」というエンジニアリングの本質である。

あなたが今日実行しようとしているそのクエリは、本当に100万トークンあたり数ドルの巨大モデルを呼ぶ必要がある処理だろうか。不要な文脈までプロンプトに詰め込み、毎行の推論で富豪的なコンピュートリソースを浪費していないだろうか。明日からの実務において、まずはバッチ処理で行っているテキスト分類やルーティングのタスクを棚卸しし、Jevのような特化型モデルへの置き換えや、入力トークン数の厳密なプロファイリングから着手してみてほしい。万能な巨人に頼るのをやめ、最小の計算資源で最大の精度を叩き出す職人技を取り戻すことこそが、これからのAIエンジニアリングを生き抜く武器になるはずだ。