LLM・Embedding model・Jev・古典的なNLPをどう使い分けるか

Sat, 26 Sep 2026 20:30:00 +0900

検索も分類も比較も判断も、とりあえずLLMに渡せばよいという扱いを見かける。自然文で依頼すれば何か返ってくるし、次の質問もそのまま続けられる。その手軽さは実際に便利で、自分もつい何でも任せたくなる。だからこそ、LLMなら何でも解けるような感覚にもなりやすい。

一方、Jevのような判断モデルを使うときにも、向いていない仕事を渡してしまうことがある。まだ材料が集まっていないのに情報を探させたり、候補が決まっていないのに方針全体を考えさせたりするのは、限定された判断をする道具に調査まで求めている。既知の語を探すだけなら、そもそもモデルを呼ばずに文字列検索で終わる。

「頼めば何か返ってくる」ことと、その仕事に合った手段であることは別だ。似た資料を集めるならEmbedding modelも候補になるが、類似度だけで資料の正しさは決まらない。LLM、Jev、Embedding model、古典的な検索やテキスト処理について、自分が何を任せたいかを整理しておく。製品間の精度比較ではなく、まず入出力と仕事の種類の話である。

探すことと判断することを分ける

以下では、自分がよく扱う開発の例で考える。例えばテストが失敗して、「関係するコードを探したい」とする。この段階の答えはファイルや行の候補だ。一方、「この失敗は今の差分に起因するか」は、差分と失敗ログを見比べる判断である。「原因を調べて直す」は、追加の情報収集や実験まで含む作業になる。

似た文を入力しても、欲しい出力はそれぞれ違う。

手段	まず渡すもの	主な出力	自分が使いたい場面
ルール・文字列検索・BM25など	語、パターン、文書集合	一致箇所や検索順位	名前やエラー文が分かっている、候補を機械的に絞れる
Embedding model	検索文と文書	ベクトルと類似度による候補	言い換えが多く、語が一致しない資料も探したい
Jev	集めた証拠と型付きの質問	Yesの確率、選択肢、段階評価	候補と評価基準を決めた上で、小さな判断をしたい
LLM	問題、資料、必要ならツール	説明、仮説、コード、次の調査	問題を分解し、足りない証拠を集め、実装や検証を進めたい

この表は能力の限界を示すものではない。LLMに分類させることも、Embeddingを特徴量にして分類器を作ることもできる。ただ、素の類似度を判断の確率として読み替えたり、単純な検索をするたびにLLMを起動したりする必要はない、という区別である。

欲しい答えから作業を分ける

例えば、変更後にAPIのテストがタイムアウトしたとする。最初はテスト名やエラー文から関係するコードを探したいかもしれない。ログと差分が揃った後は「今回の変更が原因か」を判断したいし、原因が分からなければ追加調査が必要になる。同じ失敗でも、いま欲しい答えによって作業が変わる。

自分なら、ツール名から選ぶのではなく、まず「欲しい答えは何か」と「その答えを出す材料は手元にあるか」を確認する。以下はその流れで、四つを順番に全部使う手順ではない。

flowchart LR
START{"関連する資料やコードを<br/>探す段階か"}
START -->|はい| FIND{"語や条件で探せるか"}
FIND -->|はい| SEARCH["文字列検索・ルール・BM25<br/>手元: エラー名・関数名・検索条件"]
FIND -->|いいえ| EMBED["Embeddingとキーワード検索<br/>手元: 症状の説明・探す資料群"]
START -->|いいえ| RESOLVED{"手元の情報を読めば<br/>答えが確定するか"}
RESOLVED -->|はい| DONE["ここで終了"]
RESOLVED -->|いいえ| JUDGE{"証拠が揃い<br/>問いを閉じられるか"}
JUDGE -->|はい| JEV["Jevで限定された判断<br/>手元: ログ・差分・判断する選択肢"]
JUDGE -->|いいえ| LLM["LLMとツールで調査・実装<br/>手元: 問題と追加調査の手段"]

まず、必要なのが候補の発見なのか、手元の証拠を使った判断や実装なのかを分ける。候補を探す場合、エラー文、関数名、テスト名のような既知の語があれば文字列検索を使う。大量の文書を語で順位付けしたいならBM25も候補になる。見つかった箇所を読んで答えが確定するなら、そこで終わってよい。

候補が足りず、同じ事柄が別の言い方で書かれている資料を探したいならEmbeddingを検討する。ただし固有名詞やコード上の識別子までEmbeddingだけで探す必要はない。語による検索と併用し、得られた類似文書を「確認すべき候補」として扱う。

候補と証拠が手元にあり、「この差分は失敗に関係するか」「次に調べるならA、B、unknownのどれか」のように問いを閉じられるなら、Jevへ切り出せる。材料が欠けている状態でJevに選ばせても、欠けた情報は補われない。回答が出た後もコードやテストで確かめる。

原因候補すら定まらない、追加の観測が必要、修正して回帰テストまで進めたい、といった場合はLLMを使うエージェントの出番になる。調査中に識別子が判明したら検索へ戻り、比較したい候補が揃ったら必要に応じてJevへ小さな問いを渡す。LLMを選んだら他の手段を使わない、という分岐ではない。

また、外部APIへログやコードを送る構成なら、その内容を送ってよいかは選定フローとは別に確認する。答えの形が合っていても、送信できない情報を含むならその構成は使えない。

まず古典的なテキスト処理と情報検索

エラー名、テスト名、関数名が分かっているなら、最初はrgや構文に沿った検索でよい。TimeoutErrorがどこから返るか、特定のAPI名を使っている箇所はどこか、といった問いは、コードを実際に検索すれば答えが出る。ログにFAILEDがあるかどうかも、モデルに判定してもらう話ではない。