課題
前回の記事で、このブログの記事を探す仕組みを作った。GoogleのEmbeddingGemma 2で質問に近い記事を拾い、判断用のAI「Jev」で並べ替える2段構えになる。結果を見る画面「PAGEの書棚」も作った。
ただ、作った時点で直したいところがいくつも残っていた。正解の記事を拾い漏らす、ときどき遅い、書棚が詰まって見づらい、といったところになる。
直していくと、数字を見れば分かる問題と、実際に画面を使ってみるまで分からない問題があった。
解決できるようにすること
AIに作ってもらった検索の仕組みや画面を直すときに、どこは数字で確かめればよく、どこは自分で使ってみないと分からないのかを判断できるようにする。あわせて、直す前と後の数字と、効かなかった案も持ち帰れるようにする。
先に結論
- 拾い漏れ・速さ・棚の分け方・結果の安定の4つは、数字を測れば原因が分かり、直した後も数字で確かめられた
- 一方、待ち時間の見せ方、書棚の見え方、画面の流れの3つは、数字では問題が出ていなかった。画面を使ってみて初めて気づいた
- 特に、AIが作った画面は「1段目が終わったら光り、少し待って★が付く」ように見えていたが、実際は結果がまとめて届いた後に0.7秒わざと待たせた演出だった。「本当に段階的に処理しているのか」という自分の質問で分かった
- 効かなかった案もあった。記事を短い文に分けて探すと、拾い漏れはかえって増えた
この記事でわかること
- 拾い漏れ、速さのばらつき、結果の揺れを、何を測ってどう直したか
- 数字では見つからず、画面を使って初めて気づいたこと
- 効かなかった案と、直したことで新しく出た弱点
ここで、こう思う人もいるかもしれない。
「数字がよくなったなら、画面もよくなっているのでは？」
今回はそうではなかった。数字が合格でも、画面の待ち時間は作り物だったし、結果が出た瞬間に書棚が画面の外へ流れて見えなくなっていた。
直す順番を決めた
自分が「まだ改善の余地があるよね」とAIに聞き、AIが直したいところを洗い出した。出てきたのは6つになる。
- 正解の記事を拾い漏らす
- ときどき遅い
- 書棚の棚がカテゴリ別で、1つの棚に記事が詰まりすぎている
- 同じ質問でも、Jevの確率が少し変わる
- 新しい記事を足す手順がない
- スマホで見づらい
直す前の数字を測ってから直す、という順番にした。あとで前後を比べられるようにするためになる。
数字で見つけて直したこと
拾い漏れは、候補を増やすと消えた
前回、12問の質問で比べたとき、正解23本のうち3本が1段目の候補（10本）に入っていなかった。調べると、3本は近さの順位で15位・15位・18位で、10本より少し下にあった。
まず、記事を短い文に分けて、文ごとの近さで探す方法を確かめた。ところが、こちらは逆効果だった。3本の順位は16位・32位・41位で、かえって下がった。
そこで、単純に1段目の候補を20本に増やした。
| 候補に入った正解 | 上位3本に入った正解の割合 | 1問あたりのJevの時間 | |
|---|---|---|---|
| 候補10本（直す前） | 23本中20本 | 90% | 約0.52秒 |
| 候補20本（直した後） | 23本中23本 | 92% | 約0.61秒 |
「前回の続きからAIに作業してもらうには」という質問では、拾い漏れていたCodex CLIの記事が、2番目のおすすめに入った。
代わりに、新しい弱点も出た。正解ではないのにJevが50%以上と判断した記事が、15本から19本に増えた。候補が増えれば、ぎりぎりの記事も増える。そこで、おすすめに選ぶ線を50%から60%に上げた。
| おすすめに選ぶ線 | 選んだ記事のうち正解の割合 | 落とした正解 |
|---|---|---|
| 50% | 26本中20本（77%） | 0本 |
| 60% | 24本中20本（83%） | 0本 |
| 80% | 20本中18本（90%） | 2本 |
ただし、この線は比べるのに使った同じ12問で決めたものになる。ほかの質問でも同じように効くかは、まだ分からない。
6.5秒かかったのは、GPUの取り合いだった
画面では、1段目に0.1〜6.5秒かかることがあった。比べるためのスクリプトでは約0.09秒なので、画面のほうで何かが遅くなっていた。
測ってみると、質問をベクトルにする処理を、Macの画像処理用のチップ（GPU）で動かしていたのが原因だった。続けて使えば約0.03秒と速いけど、15〜30秒あくと0.2〜0.3秒に遅くなる。6.5秒かかったのは、比べるスクリプトが同じGPUを使っていた時間帯で、取り合いが重なったと見ている。
質問1つをベクトルにするだけなら、普通の処理（CPU）でも0.06〜0.08秒で、しかも安定していた。画面のほうはCPUに変え、起動したときに1回だけ空打ちして準備しておくようにした。直した後は、毎回0.06〜0.08秒になった。
棚は、カテゴリではなく話題の近さで分けた
最初の書棚は、ブログのカテゴリ別に棚を分けていた。ただ、116本のうち74本が「AI活用術」なので、1つの棚に詰まりすぎていた。
そこで、記事のベクトルを話題の近さで8つのまとまりに分け、それを棚にした。棚の大きさは6〜30本になった。
棚の名前は、AIが各棚の題名を読んで案を付けた。あわせて、名前の候補から自動で選ぶ方法も試した。8つの棚のうち7つでAIの案と同じ名前になったけど、「有料プランと費用の比べ方」の棚は「Copilotを試す」になった。この棚にCopilotの記事が4本あるためになる。1位と2位の差が小さい棚も多かったので、名前はAIの案を使い、名前の無い新しい棚にだけ、自動の名前を「（仮）」付きで出すことにした。
自動の分け方には限界もあった。「画像生成したい！生成AIで画像生成を比較」の2本は、画像生成の棚ではなく「AIの始め方とGemini」の棚に入った。
同じ質問には、同じ答えを返すようにした
前回の記事で書いたとおり、Jevの確率は呼ぶたびに少し変わる。同じ質問をしても、並び順が入れ替わることがあった。
同じ質問と記事の組み合わせは、Jevの判断を覚えておいて使い回すようにした。2回目は一瞬で同じ並び・同じ確率になり、追加の費用もかからない。言い回しが違う質問なら、新しく判断する。
新しい記事を足したときに書棚を作り直す手順も、スクリプト1つにまとめた。116本で約1分半かかる。作り直すと覚えた判断は消える。記事の中身が変わると、古い判断が合わなくなるためになる。
使って初めて気づいて直したこと
「段階的に処理しているの？」で、作り物の待ち時間が分かった
画面の上のPAGEが瞬きしたり、書棚が順に光ったりする動きを足すことにしたとき、自分はAIにこう聞いた。
「この処理は画面に出ていない部分でも段階的に処理をしていますよね？」
返ってきた答えは、半分だけ「はい」だった。サーバーの中では、1段目→2段目の順に処理している。でも画面は、両方が終わってから結果をまとめて受け取り、0.7秒わざと待たせてから★を付けていた。1段目で光って、少し待って★が付く、という見え方は、実際の処理の進み方とは関係のない演出だった。
画面だけ見ていると、本物の段階と見分けがつかない。数字のほうも、正解の割合や時間は正しく出ていたので、ここからは見つからなかった。
そこで、サーバーが段階ごとに結果を送り、画面はそれをそのまま表示する形に作り直した。1段目が終わった時点で近い記事が光り、Jevの判断が1本返ってくるたびに、その記事が明るくなるか暗くなる。全部の判断がそろった時点で★が付く。
書棚を、背表紙が光る図書館の棚にした
棚を8つに分けたあとも、書棚には題名の札が116枚並んでいて、ぎっしりしていた。
自分は、こんな案を出した。書棚の背表紙まで1画面で読める必要はないので、ファンタジー風の図書館の書棚にして、背表紙が光ったり、つながったり、アイコンが付いたりするのはどうか。
AIがこれを形にした。記事1本を本1冊とし、背表紙だけを並べる。題名は本に触れたときだけ出る。質問すると、近い記事の背表紙が光り、Jevの判断で明暗が付き、おすすめの本には★が付く。似ている記事どうしは金の糸でつながる。今までの題名の一覧とは、ボタンで切り替えられる。
最初は本の高さや幅をばらばらにしていたけど、自分が見て「本のサイズは揃えましょう」と伝え、そろえた。
速すぎて、書棚が画面の外へ流れていた
もう1つ、使ってみて気づいたことがある。処理自体は約0.6秒で終わる。すると、書棚が光り始めた直後に、上におすすめの記事のカードが出て、書棚が画面の下へ押し出されていた。せっかくの動きが、ほとんど見えなかった。
そこで、流れを組み直した。
- 質問すると、書棚まで画面が動き、書棚の上に「PAGEが記事を読んでいます 11 / 20」のような進み具合が出る
- 届いた結果を順番に並べ、近い本が光るのも、Jevの判断で明暗が付くのも、1冊ずつ間をあけて見せる
- ★が付き終わって少し待ってから、カードを書棚の下に出し、そこへ画面を動かす
全体で約7秒になる。中身の処理は0.6秒なので、残りは見せるための間になる。ただし、さっきの作り物の待ち時間とは違って、光る順番も明暗も★も、実際に届いた結果をそのままの順に見せている。
こんな人に向いている
AIに検索の仕組みや画面を作ってもらっていて、「数字はよさそうだけど、本当にこれでいいのか」が気になっている人に向いている。
特に、処理の途中経過を見せる画面を作っている人には、「その段階は本物か」を一度確かめる意味で役に立つはず。
まとめ
| 項目 | 内容 |
|---|---|
| 結論 | 拾い漏れ・速さ・棚の分け方・結果の安定は、数字で見つけて直せた。待ち時間の見せ方・書棚の見え方・画面の流れは、使って初めて気づいた |
| 効かなかった案 | 記事を短い文に分けて探すと、拾い漏れはかえって増えた |
| 残った弱点 | 候補を増やすと、ぎりぎりの記事も増える。おすすめの線（60%）は同じ12問で決めたもの |
| 確認日 | 2026-10-09（MacBook Air M5、EmbeddingGemma 2、Jev 1.13.0） |
同じことを試すときのポイント
- 直す前の数字を測ってから直す。前後を比べられるし、逆効果の案にも気づける
- 拾い漏れは、候補の数を増やすのが一番効いた。その分、2段目で線を引き直す
- 遅いときは、どの処理をどの部品（GPUかCPUか）で動かしているかを確かめる。小さな処理はCPUのほうが安定することがある
- 途中経過を見せる画面では、「その段階は本当の処理の順番か」をAIに聞いて確かめる
- 動きを付けたら、実際に質問して、見せたいところが画面の中に残っているかを自分の目で見る
次に読むなら
この画面の元になった、EmbeddingGemma 2とJevの2段構えを比べた記録はこちら。どちらの段が何に効いたかを、12問の数字でまとめている。
この記事の紹介動画
この記事の内容を、ブログの案内役のPAGEと、SNSを担当しているLEAFが動画で紹介している。
この記事は、筆者が運営しているブログの記事検索の画面を直した作業記録（2026年10月9日）を基に、独自調整したAIが下書きを作成し、筆者が事実確認・編集を行った上で公開しています。画面のキャラクターの瞬きや口の絵の一部は、画像生成AIで作成しています。
