文章を書かないAI「Jev」を触ってみた：SEOのクエリ分類で、どこまで実務に使えるか

はじめに

今月、TypeSafe AI から Jev というモデルが出ました。

特徴が変わっていて、文章を生成しません。こちらが用意した選択肢から1つ選んで、確率を付けて返すだけ。ChatGPT のように文章で答えるのではなく、"COMMERCIAL" みたいな値が返ってきます。

最初に見たときは「それ、分類器では？」と思いました。ただ触ってみると、モデルが「この判定は自信がない」と自己申告してくれるという点が、実装する側としてはかなり違いました。

ちょうど手元に、Search Console から書き出した検索クエリが1,000件ありました。これを「情報収集なのか」「比較検討なのか」「申し込む気なのか」で分類したい。手でやると数時間かかります。かといって全部 GPT に投げるのも、この程度の判定には大げさな気がする。

というわけで、実データで試しました。この記事では、

• Jev が何をするモデルなのか
• 実際に1,000件分類させてどうだったか
• 実務のどこに使えそうか
• コストは具体的にいくら下がるのか

を書きます。

最後のコストについて先に言っておくと、SEOのバッチ処理では「安くなるから導入する」という判断は成立しませんでした。 ただし触っているうちに、このモデルが効くのはそこじゃないということも見えてきたので、そこまで書きます。

先に結論

速さと confidence は本物でした。ただしSEOのバッチ処理だと、その速さが活きません。

書いているうちに「これ、本命はチャットボットの前処理だな」と思ったので、後半でそっちも書きます。

Jev とは何か

生成しない

普通の LLM に分類させると、こうなります。

このクエリの検索意図は COMMERCIAL です。理由は「比較」という語が...

で、ここから COMMERCIAL を取り出すパースが必要になります。OpenAI の Structured Outputs を strict で使えばスキーマ違反は防げる（公式が保証しています）ので、そこは実際ほぼ問題になりません。今回も1,000件でパース失敗は0件でした。

違うのは、そもそも何を返すかです。GPT は生成した文字列をスキーマに沿わせているのに対し、Jev は最初から選択肢と確率を返します。分類に必要な情報が、生成物ではなくそのまま出てくる。

Jev はそもそも文章を作りません。返ってくるのは 必ず自分が定義した選択肢のどれか です。

3つの質問型しかない

聞けることは3種類だけです。

「要約して」「文章を書いて」はできません。判断だけをさせる道具です。

confidence が付いてくる

ここが今回いちばん効きました。

Jev は選択肢を1つ選んで終わりではなく、選択肢ぜんぶに確率を振って返してきます。天気予報と同じです。

明日の天気 ①   晴れ 80%   曇り 15%   雨  5%    → ほぼ晴れ。傘いらない
明日の天気 ②   晴れ 38%   曇り 34%   雨 26%    → 一応「晴れ」。でもほぼ勘

どちらも1位は「晴れ」ですが、信じていい度合いは全然違います。①なら傘を置いていくし、②なら持っていく。

実データにも両方ありました。クエリは伏せますが、こういう分布です。

confidence 1.00 →  NAVIGATIONAL 100%  INFORMATIONAL 0%  COMMERCIAL 0%  TRANSACTIONAL 0%
confidence 0.17 →  INFORMATIONAL 38%  COMMERCIAL 34%  TRANSACTIONAL 26%  NAVIGATIONAL 2%

下のほうは「INFORMATIONAL です」と返ってきますが、中身は 38対34対26 の団子です。これを鵜呑みにしたら事故ります。

この「どれくらい1つに絞れているか」を数字1個にしたものが confidence です。1つに集中していれば 1.0、バラバラなら 0 に近づく。モデルが迷っていることが、外から数値で読めるわけです。

計算式も公開されていて、選択肢が4つなら (4 × 最大確率 − 1) / 3 に一致します（実測でも一致しました）。4つが均等なら 0、1つに全振りなら 1 になるよう正規化しているだけです。

汎用 LLM にも「確信度も返して」と頼めます。ただあれは「0〜1で答えて」と自由に書かせた自己申告です。Jev のほうは、返ってきた確率分布から機械的に計算できる値で、こちらでも同じ式で再計算できます（実際に検算しました）。

もちろん、その元になる確率自体はモデルの推論結果です。TypeSafe は「校正された決定を返すよう訓練している」と説明していますが、そこを鵜呑みにするかは別の話。確かなのは「自己申告ではなく、分布から導ける」という点までです。

料金の形が変わっている

出力が無料です。返すのが数値だけなので、そこで課金しない設計なんだと思います。

制約

• テキストのみ（画像・音声は不可）
• コンテキストは64k（state + 最長の質問で32k）
• 英語が主な学習言語で、CJK は同等ではないと公式に明記されている

最後のやつが今回どう出たかは、後半の「ブランド名・表記混在のクエリで判定が割れた」で触れます。結論を先に言うと、この記述を裏づける結果にはなりませんでした。

とりあえず1回投げてみる

curl 一発で動きます。

curl https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "jev-latest",
    "state": "〇〇 料金 比較",
    "questions": {
      "intent": {
        "type": "choice",
        "instructions": "この検索クエリの、最も主要な検索意図はどれか。",
        "criteria": {
          "INFORMATIONAL": "情報収集。知識・手順・理由を知りたい。",
          "COMMERCIAL":    "比較・検討。購入はまだ決めていない。",
          "TRANSACTIONAL": "購入・申込・予約など、今から行動する意図。",
          "NAVIGATIONAL":  "特定のブランド・サイト・店舗に到達したい意図。"
        }
      }
    }
  }'

{
  "model": "jev-1.13.0",
  "answers": {
    "intent": {
      "type": "choice",
      "choice": "COMMERCIAL",
      "probabilities": { "COMMERCIAL": 1, "INFORMATIONAL": 0, "NAVIGATIONAL": 0, "TRANSACTIONAL": 0 },
      "confidence": 1
    }
  },
  "usage": { "input_tokens": 490, "output_tokens": 63 }
}

criteria に選択肢と説明を書いて、state に判定対象を入れるだけ。プロンプトエンジニアリングというより、設定を書いている感覚に近いです。

実データ1,000件でやってみる

使ったデータ

実案件の Search Console から書き出した 上位1,000クエリ（過去16か月・ウェブ検索）です。

ここは正確に書いておくと、これはサイト全体ではありません。同時に書き出した国別・デバイス別のCSVと突き合わせたところ、

クリックの約半分、表示回数の約3割しか見ていません。 残りはロングテールです。後半のSEO分析は、この範囲での話になります。

言語も混ざっていました。

国別を見ると中国16,778クリック・香港10,908・台湾3,330と中華圏の流入が実在していて、最上位のクエリも中国語でした。日本語だけのデータセットではありません。

比較対象

同じ1,000件を gpt-5.6-luna にも投げました。分類の定義文は 完全に同じものを共有 しています。プロンプトの書き方の差が判定の差になると、モデルの比較にならないので。

export const INTENT_CRITERIA: Record<Intent, string> = {
  INFORMATIONAL: "情報収集。知識・答え・手順・理由を知りたい。…",
  COMMERCIAL:    "比較・検討。商品やサービスを選ぶための情報を探している。…",
  TRANSACTIONAL: "購入・申込・予約・契約など、具体的な行動を今から起こす意図。…",
  NAVIGATIONAL:  "特定のブランド・企業・サービス・Webサイト・店舗施設…",
};

結果

両方ともエラー0件で完走して、1,000件中924件（92.4%）で同じ判定になりました。

分布もかなり近い。ただし 「一致した＝正しい」ではありません。 GPT を正解として扱っていないので、両方が同じように外している可能性は残ります。この点は記事の最後にもう一度書きます。

confidence が実務で効く

ここが今回いちばんの収穫でした。

confidence の帯ごとに、Jev と GPT の判定が一致した割合を出します。

きれいに単調です。confidence が下がるほど、2つのモデルの答えが割れます。

そして confidence 0.90以上は 全体の62.1% を占めていて、そこでは GPT と 620/621 件で一致しました。

だから、振り分けができる

これがそのまま実装になります。

const answer = res.answers.intent;
 
if (answer.confidence >= 0.9) {
  return answer.choice;          // 62.1%はここで確定
}
return await classifyWithGPT(query);  // 残りだけ汎用LLMへ

閾値ごとに、GPT の呼び出しがどれだけ減るかを全1,000件でシミュレートしました。

いちばん保守的な0.90でも、GPT への問い合わせが 6割減 ります。しかもその帯は、実際に GPT に投げても99.8%同じ答えになった帯です。

複数の判断を1回でまとめて聞ける

これは後から気づいた話ですが、実務ではここが効きそうです。

1つの state に対して、複数の質問を同時に投げられます。しかも state の読み込みは1回で済みます。

questions: {
  intent:       { type: "choice", instructions: "検索意図は？", criteria: {...} },
  is_branded:   { type: "noul",   instructions: "ブランド名を含むか。" },
  buying_stage: { type: "score",  instructions: "購買プロセスのどの段階か。",
                  criteria: ["未調査", "情報収集中", "比較中", "申込直前"] },
  needs_review: { type: "noul",   instructions: "意図が曖昧で人間の確認が必要か。" },
}

実際に15件×4問で、まとめて1回 と 1問ずつ4回 を比較しました。

分類だけでなく「ブランド名を含むか」「人間の確認が必要か」まで一度に取れるので、後段のワークフローを組み立てる材料が1回で揃います。ここは素直に便利だと思いました。

コストは実際いくら下がるのか

本題です。実測トークンから計算します。

1件あたりの単価

GPT は Jev の 3.25倍 です。Jev のほうが入力トークンを1.8倍使っているのに安いのは、単価が約5分の1だからです。

規模別の試算（定価ベース・150円/USD）

削減率で見ると、

• Jevのみ: 69.2%削減
• Hybrid 0.90: 31.3%削減
• Hybrid 0.60: 54.6%削減

率だけ見ると立派です。

でも、元は取れません

月10万件処理しても、削減額は 約1,000円 です。

実装を考えてみます。Jev のクライアントを書いて、リトライを入れて、confidence で分岐させる。フォールバック先の GPT クライアントと、途中で落ちたときの再開処理も要ります。真面目に書くと最低でも数時間です。

仮に 実装4時間（時給5,000円で2万円） とすると、

430万件処理して、やっと実装費の元が取れます。 月10万件なら3年半かかる計算です。

ただしこれは 「月1回のバッチ処理だから」 という側面が大きいです。 毎ターン走る処理に組み込むと前提が変わるので、それは後半で書きます。

速度は本物、ただし落とし穴つき

1リクエストの応答時間はこうでした（再試行の待ち時間は除く）。

p50で3.4倍、p95で4.3倍速い。 分布も締まっていて、Jev は p50 360ms に対し p95 546ms。GPT は p99 が6,265msまで伸びます。

ユーザーを待たせる処理に組み込むなら、この差は効きます。コストより、こちらのほうが導入理由になりそうです。

ただし。

1回は3.4倍速いのに、1,000件終わらせるのには3.7倍かかりました。

原因は後述の 529 です。公開直後で混んでいるだけだと思いますが、「1回360ms」だけ見て設計すると詰まります。

詰まったところ

APIキーが通らない

手元のキーで公式APIを叩いたら 401 でした。よく見たら vck_ で始まっています。Vercel AI Gateway のキーでした。

幸い Gateway が TypeSafe互換API を出していて、リクエスト／レスポンス形状が公式と同じです。ベースURLを差し替えるだけで動きました。

JEV_BASE_URL=https://ai-gateway.vercel.sh/typesafe
JEV_MODEL=typesafe-ai/jev

副産物として、Gateway は provider_metadata に 実請求額 と 定価 の両方を返してくれます。今回は無料クレジットが効いていたので、定価で比較するのに助かりました。

8並列で投げたら1割以上落ちた

公式のレート上限は1,200 req/min。余裕だろうと8並列で投げたら、100件中12件が再試行を使い切って失敗しました。

429 Too Many Requests
503 Service Unavailable
529 {"error_type":"system_overloaded", ...}

4並列でも10件中4件失敗。529 の中身は system_overloaded で、こちらの並列数ではなく TypeSafe 側の容量不足 でした。最終的に 2並列＋Retry-After 準拠の再試行 で0件になりました。

ブランド名・表記混在のクエリで判定が割れた

confidence 0.60未満（146件）を見ると、ブランド名を含むクエリ に集中していました。

意図を示す語がはっきり入っていれば、ほぼ揉めません。逆にブランド名が主役になると割れます。

ここは解釈に注意が必要でした。最も割れたのはラテン文字のみのクエリ（30.8%）で、日本語ではありません。 公式ドキュメントには「英語が主な学習言語でCJKは同等ではない」とありますが、今回の結果はそれを裏づけるものではなく、むしろ言語の種類より「意図を示す語があるかどうか」で割れ方が決まっているように見えます。

なお上位2つは母数が13件と11件しかないので、率だけを見て断定はできません。

SEO データとして見てみる

分類結果を Search Console の指標と結合しました。上位1,000クエリの範囲での数字です。

GSC の画面を眺めていても出てこなかった数字が出ました。

情報収集クエリは表示回数の84.4%を占めるのに、クリック比は56.1%にとどまります。 逆に指名検索は表示回数の4.3%しかないのに、クリックの31.3%を持っていく。表示回数あたりの効率で言えば約11倍の差です。

ただし「情報収集クエリがクリックされていない」わけではありません。実数では226,567クリックで、全intent中で最多です。効率が相対的に低い、という話です。

TRANSACTIONAL が27件（表示回数の0.2%）しかないのは気になります。ただ、そもそも上位1,000件しか見ていません。ロングテール側に申込系クエリが埋もれている可能性は残るので、ここは断定できません。

で、これで何がわかったのか

整理すると、このサイトは情報収集の検索で大量に表示されているが、表示シェアのわりにクリックシェアが伸びていない。一方で指名検索は、表示回数のたった4.3%で全体の31.3%のクリックを稼いでいます。

ここで注意が要ります。このCTR差を intent だけの効果と読むのは早計です。表示回数で重み付けした掲載順位を見ると、情報収集クエリが4.81位、指名検索が2.90位。順位が違えばCTRは当然変わります。指名検索はそもそもブランドを知っている人の検索なので、CTRが高いのは intent の性質というより検索者の状態の話でもある。intent・順位・検索者の状態が混ざった数字として読む必要があります。

これは GSC の画面を眺めていても出てきません。クエリを1行ずつ見て「情報系が多いな」とは思っても、それが表示の84%を占めていて、しかも CTR が全intent中で最低という構造までは掴めない。intent という軸を足して、はじめて見える形になりました。

しかも一度パイプラインを作れば、次からは月1回・数円で回せます。来月また分類すれば、構成比がどう動いたかが差分で見えます。

元々「Jev は SEO で使えるんじゃないか」と思って始めた検証ですが、この可視化に関しては素直に使えたというのが実感です。

月次で回すと何ができるか

今回は1回分のスナップショットですが、同じ分類基準で毎月かけると「構成の変化」が追えます。 検討層の比率が先月より落ちた、指名検索のシェアが伸びた、といった差分です。1,000件あたり数円なので、コストは実質無視できます。

もう一歩進めるなら、Search Console の API を使う手があります。CSV エクスポートだと「クエリ別」と「ページ別」が別々の集計で出てくるため、どのページがどの intent のクエリで流入しているかが分かりません。API なら query × page × date で取れるので、

• 比較検討系のクエリで入ってきているのに、中身が情報記事になっているページ
• 申し込み意図のクエリを拾えているページがそもそも存在するか

といった単位まで落とせます。そこまで来ると、リライト・比較ページの新設・内部リンクの張り直しといった施策の候補に直結します。今回はそこまでやっていないので、次の宿題です。

SEOよりチャットボットのほうが向いていそう

ここまで書いておいて何ですが、検証しながら「これ、もっと向いてる使い道があるな」と思いました。

SEOのクエリ分類は月1回のバッチ処理です。1,000件を30分かけて処理しても誰も困らないし、コスト差も月100円。つまり Jev の売りである速さと安さが、ほとんど効きません。

気になって公式ドキュメントの事例集を見たら、並んでいたのはこういうものでした。

全部、チャットボットの前後で毎回走る処理です。

社内のQAボットに置くとこうなる

たとえば社内Wikiに質問できるチャットボットを考えます。仕組みはだいたいこうです。

効いてくるのは真ん中の仕分けです。検索で12件拾っても、全部が質問に関係あるとは限りません。無関係な文書まで一緒にLLMへ渡すと、それを根拠に間違った回答が作られます。

だから渡す前に1件ずつ「これは質問に関係あるか」「答えの根拠になるか」を判定して、要らないものを捨てる。この仕分けが Jev の担当です。回答そのものを書くのは、後ろにいる強いモデルのほうです。

ここで前述の4問まとめが効きます。1つの文書につき4つ質問しても1リクエストで済むので、12件なら12回の呼び出しで終わります。

待ち時間に直結する

仮に1ターンで14回（文書12件＋入口と出口の検査2回）呼ぶとします。実測の応答時間を掛けるだけで、こうなります。

これは回答が出るまでの「下ごしらえ」の時間なので、まるごとユーザーの待ち時間になります。並列に投げれば縮みますが、差は残ります。

SEOのバッチ処理と何が違うのか

同じ「分類」でも、置かれる場所で意味がまったく変わります。

判断が人の待ち時間に乗って、しかも使われるほど回数が増える。 この2つが揃ったときに、速くて安い判断専用モデルが意味を持ちます。

SEOの分類で「速さもコストもどうでもいいな」と感じたのは、月1回のバッチ処理だったからでした。

向いていること・向いていないこと

今回触った範囲と、公式クックブックの構成から考えた整理です。実際に検証したのは検索意図の分類だけなので、チャットボット関連は「Jev の性質から考えてこうだろう」という推測を含みます。

そして 「Jev 単体で完結させる」のは今回のデータだと厳しい です。confidence 0.60未満の帯は GPT との一致率が66.4%まで落ちます。強いモデルの前後に置いて、判断の材料を作らせるのが現実的な使い方だと思いました。

まとめ

• Jev は文章を生成せず、型の付いた決定と確率を返すモデル。聞けるのは Choice / Score / Noul の3種類だけで、判断に特化している

• confidence が実装に効く：0.90以上の621件（全体の62.1%）では GPT と620件一致（99.8%）。信頼度でルーティングを組める

• GPT 呼び出しは62.1%削減できた（閾値0.90）。その帯は実際に投げても99.8%同じ答えだった

• 4問まとめて聞くとトークン47%削減・3.81倍速い。1件に複数判断が要るなら、ここは効く

• 速い：1リクエスト p50 360ms（GPTは1,218ms）。ユーザーを待たせる処理には向く

• ただし現状は不安定：22.4%が再試行を要し、1,000件の完走はGPTの約3.7倍かかった

• コスト削減は導入理由にならない：月10万件で削減額約1,000円。実装4時間の元を取るのに約430万件必要

• ブランド名が主役のクエリで割れる：ラテン文字のみで不一致率30.8%、日本語＋英字の混在で14.7%。逆に「とは」「方法」等を含むものは1.4%

• SEOの可視化には使えた：intent 別に割ると、情報収集クエリが表示の84.4%を占めるのにクリック比は56.1%、指名検索は表示4.3%でクリック31.3%。GSC の画面では見えない偏りが出た（ただし掲載順位の差も混ざっている）

• ただし速さと安さは活きない：月1回のバッチ処理だと、応答時間もコストも誤差。毎ターン走るチャットボットの下ごしらえに置くほうが、この2つは効いてきそう

元々は「Jev は SEO で使えるんじゃないか」という思いつきから始めた検証でした。答えとしては使えた、というのが結論です。ただし効いた理由は、速さでもコストでもありませんでした。

62.1%のクエリは GPT に聞き直しても答えが変わらず、残りだけ回せば済んだ。そして intent で割ってみたら、今まで見えていなかった流入の偏りが出てきた。効いたのはこの2つです。

触る前は「安くて速い分類器」だと思っていたんですが、実際に価値を感じたのは confidence でした。「自信がない」を数値で返してくれるから、どれを上位モデルに回すかをコードで書ける。速さと安さのほうは、今回の使い方ではオマケでした。

そのオマケが主役になる場所が、たぶんチャットボットの下ごしらえのほうなんだと思います。そっちはまだ試していないので、次の宿題にします！