mazrean さんのJevサイト内検索を解説。ベクトル検索とAI判定の2段で、何が拾えて何が落ちるか

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくんです。今回は、mazrean さんが9月26日にZennへ書いた、Jevで作るサイト内検索の実装記事を読み解いてみるね。

mazrean さん（Zenn記事の脚注より）

「自分のサイトで検索するために、Google に移動するという不毛なことをすることがそこそこ出てきていました」

mazrean さんは、Go 言語の提案を毎週まとめる個人サイトを8か月ほど運用しています。毎週200PV ほどで安定している、と書いています。最初は記事が少なかったので、過去記事を人力で探せました。ところが記事が増えて、サイト内検索が欲しくなった。そのきっかけを、上の脚注で書いています。

この脚注を読んで、私は自分のブログで同じことを試したくなりました。

今日の朝、WordPress のAPIで公開記事を数えたら、1,811本ありました。そこで、AI秘書の凛ちゃんに頼んで、WordPress 標準の検索（REST API 経由）に、Jev の記事を探してもらいました。数字は、こうでした。

「Jev」と入れると27件。「判定AI」だと5件。私が記事の中で使っている「判定だけするAI」は2件、「文章を書かないAI」は6件、「答えを出さないAI」は0件でした。探しているのは、どれも同じJevの記事です。

例えばJevとは何かを書いた記事は、「判定AI」で探すと出てきます。「判定だけするAI」で探すと、出てきません。同じ内容の記事が、言い方ひとつで検索から消えるんです。

これは検索窓の欠点というより、単語の一致で探す仕組みの性格です。推測: 読者は自分の知っている言い方で入れて、出なかった時に、記事が無いと受け取っているはずです。

私は、記事もアイデアも、全部捨てたくない側の人間です。捨てずに身軽でいるための答えが、分身AIに所有権を預けることでした。自分のキッチンはスッキリさせて、セカンド冷蔵庫に入れておけば、使いたい時に取りに行ける。

この形が成り立つ条件は、取りに行けることです。預けた記事が、言い方ひとつで検索から返ってこないなら、それは預けたのではなく、しまい込んだだけになります。mazrean さんの「不毛」は、そこを突いた言葉に読めました。

立っている場所も違います。mazrean さんは、読みに来る人が探せる検索を作っています。私が今日測ったのは、運営している側が自分の記事を取り戻せるか、という別の角度です。

検索窓で3通り: 自分のサイトの検索窓に、自分が付けた呼び名と、読者が使いそうな言い方を3通り入れて、出てきた件数を1行メモに残してみてください。

secon.dev（jev-reranker の記事）

「ここが Jev の面白いところで、異なるのはインストラクション（指示文）のみです。」

Jev は TypeSafe AI が9月15日に公開したモデルで、文章を生成せず、型付きの値を確率つきで返します（公式ブログ）。質問の型は、選択肢から選ぶ Choice、ルーブリックで採点する Score、文が真かを0〜1で返す Noul の3種類。mazrean さんは、検索を「この記事は検索内容と関連しているか」を Noul で聞く問題に置き換えました。secon.dev の jev-rerankerは、同じ仕組みで並べ替えと足切りの両方をこなします。その違いを、上の一文で書いています。

指示文だけで動きが変わるところは、私の実験でも、その通りでした。

Search Consoleで意図ずれを調べた記事では、90日分の「ページ×検索語」から、表示の多い281本を選びました。それぞれについて、いちばん多い検索語と、タイトル・説明文・本文の冒頭をJevに渡して、「この記事は検索の意図に合っているか」を判定させています。結果は、意図のずれが95本でした。

聞いた内容は、mazrean さんとほぼ同じ型です。違うのは向きでした。mazrean さんは、訪れた人が打った検索語を受けて、その場で20件の候補に聞きます。私は、検索語の一覧を先に持っていて、記事のほうをまとめて聞きました。同じJevで、質問の向きが逆です。

判定に置き換えると、人間の仕事は「答えを探すこと」から「聞き方を決めること」に移ります。見せる範囲と、聞く文。そして、線をどこで引くか。その設計はJevではなく、こちらの仕事として残ります。

この置き換えがうまくいくかは、道具の性能より、聞く側の設計で決まります。今のところ、そう考えています。ここが肝です。

自分のサイトの検索を「この記事は、この検索語に関連しているか」という1行の質問に書き直してみてください。1行で書けなければ、判定に置き換える前の整理が足りません。

kikuziro さん（Qiitaの検証記事）

「Jevいいじゃん！！となりそうですがこの精度はあまり当てになりません。」

mazrean さんの検索は、2段です。まずベクトル検索で候補を20件に絞り、その20件を Jev が判定して、0.2以上を高い順に返します。この2段の作りを、リンク先の記事が別の角度から見ています。kikuziro さんの検証は、Jev を RAG の絞り込みに差した実験です。上の一文に続けて、リランク（上位候補の並べ替え）なしの時点でRecall@5（正解が上位5件に入る割合）が1.000だったので、そもそもリランカーの出番が無かった、と理由を書いています。secon.dev の jev-rerankerの評価は、上位100件に正解が無い時は101件目に正解を入れて測っています。

Jev の前に絞った分は、Jev が賢くても取り戻せません。この記事で一番言いたいのは、ここです。根拠を出します。

根拠は、Search Consoleで意図ずれを調べた記事の実測です。あの記事でタイトル案を作った、本文のある83本について、「本文に検索の答えがあるか」をJevに聞きました。本文の冒頭1,800字だけを見せると「答えがない」が64本。本文全体（最大14,000字）を見せて聞き直すと、35本でした。

差の29本は、Jev の答えが変わった記事です。人が1本ずつ確かめて、答えが後ろにあったと確認したわけではありません。ただ、見せる範囲を狭めると、答えが後ろにある記事を「なし」にしてしまう危険がある、という材料にはなりました。

mazrean さんの20件は、本文の範囲ではなく、候補の数です。絞っているものは違いますが、構造は似ています。Jev の手前で狭めた分は、後ろの判定からは見えません。

リンク先の2本も、絞る段階がうまく働いている前提に立っています。kikuziro さんは400チャンクという小さなコーパスで、ベクトル検索の時点で答えが上位に入っていた。secon.dev の評価は、正解が候補に入っている状態から足切りの性能を測っています。

では、mazrean さんの20件に答えは入っているのか。元記事では、そこを測っていません。書かれているのは、generics で検索した1例です。この設計を否定する材料は、私も持っていません。先に確かめたいのは、Jev の精度より、20件に答えが入っているかどうかです。

AI氣道『Search Consoleで意図ずれ95本を見つけ、Jevでふるい、AIMHで11本を直した』より

「判定の範囲を狭めると、答えが後ろにある記事を落とします。」

Jevに見せる範囲を狭めると答えを落とす、という実測は、『Search Consoleで意図ずれ95本を見つけ、Jevでふるい、AIMHで11本を直した』で書いています。

絞る前の件数を10問で: 自分のサイトで探したい記事を10個選び、絞り込みの上位20件に、その記事が何個入っているかを数えてみてください。Jev に渡す前に、拾える上限が見えます。

mazrean さん（Zenn記事・「検索能力について」の節）

「ただ、実際やってみると、Jev ではドメイン知識や周辺知識を踏まえて検索の方向性をカスタムできるのが大きいのか、Google のサイト内検索より使い勝手が良い印象です。」

mazrean さんは、サイト内検索は Google の方が精度が良いのでは、と疑っていたそうです。ところが実際は、Jev のほうが使い勝手が良かった。例が、「generics」で検索した結果です。ジェネリックメソッドの追加によって可能になったプロポーザルは、単語としては generics に出てきませんが、関連しています。Jev の結果には含まれて、Google のサイト内検索には含まれなかった、と書いています。

1章で書いたとおり、私のサイトの標準検索は、言い方を変えると、出てくる記事が変わりました。単語の一致で探すからです。mazrean さんの Google の例と、同じ性格に見えます。

推測: 言い換えを拾う役目は、Jev の判定より前の、ベクトル検索の段階が持っているはずです。20件に絞るのはそこなので、「関連しているか」を聞く前に、言い換えの記事が20件に入っているかが効いてきます。ここは私の推測で、確かめていません。

一方で、Search Consoleで意図ずれを調べた記事で、こんな数字を見ました。順位が5〜12位の153本で、検索の意図に合っている記事は押される率が2.12%、合っていない記事は1.16%。タイトルが検索語に答えている記事は2.06%、答えていない記事は1.62%でした。ただし、これは相関です。順位の平均も違うので、タイトルを変えれば押されるという証明にはなりません。

ここから言えるのは、押されるかどうかは、単語の一致より、検索した人の意図に答えているかで動いている傾向がある、というところまでです。外から Google が意図で選んでいるなら、自分のサイトの中の検索も、意図で選べたほうが読者に親切だと思います。

正直に書きます。mazrean さんの generics の結果を、私は再現していません。Google のサイト内検索との比較も、私のサイトではやっていません。ここは、元記事の実感を、実感のまま受け取っています。

自分の記事を、内容は同じで単語だけ違う検索語で3回探してみてください。出なかった記事のタイトルを、1本ずつ書き出すところまでで十分です。

mazrean さん（Zenn記事・「レイテンシについて」の節）

「そこまでシビアなパフォーマンスを求められる機能ではないため、開発の楽さを優先して今回は Cloudflare AI Gateway 経由で Jev を利用していますが、レイテンシ悪化がユーザー体験において重要な場面では注意が必要そうです。」

Jev は70〜500ミリ秒で答える、とされています。ただ、henteko さんの検証では、Jev のサーバーがアメリカ西海岸（Oregon）にあり、日本からは速度を生かしきれません。Workers から Jev を直接呼んで接続が温まっている時が約207ミリ秒（中央値）、Cloudflare AI Gateway 経由で30秒間隔だと約744ミリ秒でした。mazrean さんの検索 API でも、間隔を開けずに叩くと数百ミリ秒、間隔があくと1秒以上、という同じ挙動が出ています。その上での判断が、上の一文です。

先に断っておくと、私は自分のサイトの検索の速さを測っていません。この章の数字は、mazrean さんと henteko さんの実測を借りています。

借りたうえで、私の記事から関係のある実測が1つだけあります。JevとLayaを比べた記事です。同じ50件の仕分けで、Laya（手元のMacで動く判定専用モデル）は1件0.12秒、Jev は0.59秒でした。約5倍の差です。

私が呼んだ Jev は、Vercel AI Gateway 経由のクラウドでした。henteko さんの表を見ると、Gateway 経由は、間隔があくと遅くなる経路です。0.59秒に Gateway とネットワークの往復が含まれていた可能性はあります。ただ、私は分けて測っていないので、そうだとは言えません。

その記事で一番大事だったのは、速さではありませんでした。結論は別の所です。当たる率は、50件の感想に3つの質問をして、延べ125問。正解は Jev が109問、Laya が69問でした。速いのに、仕分けが外れる。速さと当たる率は別でした。

推測: 検索窓で1秒待つのは、読みに来た人が探し物を1回する場面なら、許せるかもしれません。これは私の推測で、確かめていません。mazrean さんも、そこまでシビアな機能ではないと書いています。

この章で私が置いておくのは、順番だけです。まず答えが合うかを測って、速さは、その後に見ます。速さの数字は、測った場所と経路を書いておかないと、自分の言葉にはできません。

AI氣道『Jev vs Laya 比較｜アンケート50件の仕分けは精度でJev、速さと手元で動く安心はLaya』より

「順番はこうです。まな板の上で同じ50件を切ってみて、当たる率を先に見る。速いかどうかを見るのは、その後です。」

速さより当たる率を先に見る、という順番は、『Jev vs Laya 比較｜アンケート50件の仕分けは精度でJev、速さと手元で動く安心はLaya』で書いています。

検索の速さを気にするなら、数字だけをメモせず、どこから、どの経路で呼んだかを一緒に1行書いてください。その1行が無い数字は、比べる材料になりません。

GitHub AI Projects Community（jev-ultrafast を紹介したX投稿）

「操作と対象の選択を1回の通信でまとめる」

mazrean さんの検索が「関連しないものを落とす」判定なら、同じ形は他にも出ています。tamara さんは、コンテキストの圧縮（compaction）を、全ての道具呼び出しを採点して無関係なものを落とすことで即時にできる、と書きました（Jev can make it instant by scoring every tool call and dropping what’s irrelevant）。rari さんは、繰り返す判断を LLM の呼び出しの外に出す、という導入プロンプトを配っています。ブラウザ操作エージェントの jev-ultrafast を、GitHub AI Projects Community が紹介した一文が、上の引用です。

3つの投稿には共通点がありました。Jev に渡しているのは、選ぶか捨てるかの仕事です。文章を作る仕事ではありません。検索の足切りも、その仲間です。

ただ、落とす判定には、私の実測から気をつけたい点が2つあります。順に書きます。

1つ目は、選んだ答えが、検索語に答えていなかったこと。Search Consoleで意図ずれを調べた記事に出てくる Design.md の記事で、Jev が選んだタイトル案は「35,000スター」の数字でした。本文にある数字です。でも検索語は「使い方」で、その案は使い方に答えていません。Jev は速いのに、なぜずれたかまでは出ませんでした。

2つ目は、「なし」と言える判定でも外すこと。Julian Goldieさんの動画を実機で確かめた記事では、合う記事が無い10件のうち、Jev が「なし」を選んだのは8件でした。残り2件は、無理に記事へ結びつけています。

mazrean さんの検索は、ページ検索なので「回答不能」を選ばせない作りに見えます。ただ、20件の中に答えが無い時に、何が返るのかは、元記事には書かれていません。

AI氣道『Jevの5つの主張を、Julian Goldieさんの動画から実機で確かめてみた』より

「合う記事が無い10件のうち8件で、Jevは「なし」を選びました。」

Jevが「なし」と言えるかを20件で確かめた実測は、『Jevの5つの主張を、Julian Goldieさんの動画から実機で確かめてみた』で書いています。

落とす前の受け皿: AI に落とさせている判定を1つ選び、落とした結果を10件だけ人の目で見返してみてください。落としすぎが1件見つかれば、受け皿が要る場所です。

kikuziro さん（同じQiita記事の続き）

「400チャンクという規模が小さすぎました。精度をちゃんと比べるならもっと大きなコーパスで測り直す必要があります。」

kikuziro さんの検証は、自分の実験を、規模が小さすぎたと振り返っています。次に測り直す時の物差しとして参考になるのが、secon.dev の jev-rerankerの閾値の考え方です。見逃すと損害が大きいシステムでは <= 0.05、検索に関連しなそうなら大胆に削除して良い場合は <= 0.5 のように、足切りの線を用途で変えられます。評価では、検索候補100件を平均7.62件まで減らして、nDCG@10（並べ順の良さを測る指標）が0.975でした（並べ替えのみは0.969、通常のハイブリッド検索は0.833）。自分の実験を小さいと認める書き方は、私が提案を書く時にも、そのまま当てはまります。

先に、実装済みと提案を分けます。実装済みなのは、検索の意図のずれの判定と、Jev に見せる範囲の実験までです（Search Consoleで意図ずれを調べた記事、JevとLayaを比べた記事）。サイト内検索そのものは、私のブログにまだ入っていません。ここから先は、提案です。未実装です。順に書きます。

提案1。1章の疑問を、そのまま実験にします。正解の記事を5本決めて、言い方を変えながら、その5本が何回出てくるかを数える。言い方ごとの命中が見えれば、直すのが検索なのか、記事の書き方なのかが分かります。

提案2。絞る件数を、20件より広く取る。ここは、10問で測ってから決めます。数字は仮です。あわせて、Jev に見せるのは、冒頭ではなく本文全体にします。

提案3。足切りの線は、探し物の痛みで決める。私のブログなら、読者が探している記事が出ないほうが痛いので、低めの線から始めます。推測ですが、まずそこから試します。

提案4。Jev の答えを信じ切らず、線より下は人が見る。imajevを試した記事では、確信が0.85より下は人に回して、66問中53問を任せられました。

最後に、なぜ自分のサイトの検索にこだわるのかを、ひとつだけ書きます。2026年7月25日の魂磨きで見つけたことがあります。「発信するから自分が見える」。自分のブログを読み返すことは、内から湧き出るエネルギーを本人へ返す鏡になる。

推測: その鏡に映すには、読み返したい記事に自分がたどり着ける必要があるので、検索はその入口になるのだと思います。ここは私の見立てで、まだ試していません。

4つの提案のうち、自分のサイトで一番試しやすいものを1つ選んでください。10問の測定なら、20分で終わります。

mazrean さんの記事の一番の収穫は、検索を判定問題に置き換えたことで、AIに任せる場所がはっきりしたことでした。候補を20件に絞り、Jevが関連度を判定して、0.2以上を返す。小さな個人サイトに検索を付ける作り方として、筋が通っています。

冒頭の疑問に戻ります。私のサイトで、言い方を変えると出てくる記事が変わったのは、Jevの手前、単語で探す段階の話でした。mazrean さんの設計なら、言い換えの記事が20件に入っているかが効いてくるはずです。ここは推測で、私は測っていません。まず、正解の記事を5本決めて、言い方ごとに何回出てくるかを数えるところから始めます。

Jevの手前で絞った分は、Jevの後ろからは見えません。Search Consoleで意図ずれを調べた記事では、本文の冒頭1,800字だけで聞くと答えなしが64本、全文だと35本でした。差の29本は、Jevの答えが変わった記事で、人が確かめたものではありません。

実装済みなのは、意図のずれの判定と、判定範囲の実験までです（Search Consoleで意図ずれを調べた記事、JevとLayaを比べた記事）。サイト内検索そのものは、私のブログにまだありません。この記事の提案は、言い方ごとの命中を測る、絞る件数を広げて本文全体を見せる、足切りの線を探し物の痛みで決める、線より下は人が見る、の4つで、どれも未実装です。明日1つだけ選ぶなら、自分のサイトで探したい記事を10個選んで、絞り込みの上位に何個入るかを数えてみてください。20分で終わります。

読んだのは、mazrean さんのZenn記事と、そこからリンクされた TypeSafe AI の公式ブログ、secon.dev、kikuziro さんのQiita、henteko さんのZennです。再現していないのは、generics の検索結果と、Googleのサイト内検索との比較です。自分のサイトの検索の速さも、測っていません。速さの数字は、元記事の実測を借りたものです。