何が起きたか
Simon Willison氏が自身のリンクブログで、Doug Turnbull氏によるLLM分類のテクニックを取り上げました。氏のブログには過去にタグ付けされないまま残った記事があり、一方でタグの総数は1,856個。この規模になると「既存タグの一覧を渡して、この記事に合うものを選ばせる」という素直なプロンプトは現実的ではありません。
Turnbull氏の提案はこうです。まずモデルには既存の語彙を一切見せず、対象コンテンツに合うタグを自由に出力させる。次に、その「モデルが想像したタグ」をベクトル埋め込みに変換し、既存タグ群の中から意味的に最も近いものを引き当てる。つまり、幻覚（ハルシネーション）を排除するのではなく、検索の入り口として使ってしまう設計です。
なぜ重要か
分類タスクでLLMを使うとき、多くの現場は「選択肢を全部プロンプトに入れる」という素朴な実装から始めます。ところが選択肢が数百を超えた瞬間、コンテキスト長、コスト、そして選択肢が多いほど精度が落ちるという問題に同時にぶつかります。この手法は、その壁を「生成」と「検索」に工程分解することで回避します。LLMは意味を表現する役、ベクトル検索は正規の語彙に着地させる役。役割を分けたことで、タクソノミーが1,856個であろうと1万個であろうと、プロンプト側の設計は変わりません。
プロンプト設計の勘所
Turnbull氏は、タグの「形（shape）」の例をプロンプトに含めることを勧めています。例として示されているのは家具・ホームグッズ・ハードウェアの商品分類で、モデルには「これまで見たことのない新しい分類を作れ」と指示します。分類の例は Furniture / Living Room Furniture / Coffee Tables & End Tables / Coffee Tables や Baby & Kids / Toddler & Kids Bedroom Furniture / Kids Beds のような階層パス形式。検索クエリのサンプルは brown coffee table です。
ここが実務上のポイントです。語彙そのものは渡さないが、粒度と書式は渡す。「ざっくり1階層」なのか「4階層のパス」なのかをモデルが知らなければ、生成されたタグと既存タグのベクトル距離は比較にならないほどブレます。埋め込み検索の精度は、突き合わせる両者の表現形式が揃っているかにかなり依存する——例示は、その前提を安く満たすための仕掛けだと読めます。
応用の射程
記事の題材はブログのタグ付けですが、例示が商品分類とクエリ brown coffee table である通り、想定される用途はECの商品カテゴリ推定や検索クエリの意図分類に近い領域です。既存の分類体系があり、その体系が大きすぎてプロンプトに載らない、という条件を満たす業務であれば、そのまま同じ構造を持ち込めます。
💼 事業会社視点：これは自社にどう効くか
最も効くのはEC事業者です。商品カテゴリが数千規模になった自社ECやモール型で、新規出品の自動カテゴリ付与や検索クエリの意図判定に、この二段構えはそのまま適用できます。既存のカテゴリマスタを作り直す必要がなく、埋め込みインデックスを1本足すだけで済む点が実務的です。
SaaS各社にとっては、問い合わせの自動仕分け、ナレッジ記事のタグ付け、機能リクエストの分類などが該当します。既存の分類コードをLLMに丸暗記させる方向で投資してきたなら、方針の見直し余地があります。
受託開発・SIerには提案材料になります。「分類項目が多すぎてLLM化を断念した」案件が社内に眠っていないか、営業と一緒に棚卸しする価値があります。日本企業の場合、勘定科目、部門コード、JICFS分類のように数千件規模の既存コード体系が業務の中核にあり、まさにこの手法が刺さる領域です。
経営判断としては、生成AIの精度をモデル選定だけで語らないこと。Willison氏が紹介した1,856タグの例が示すのは、工程の切り分け方こそが精度とコストを決めるという事実です。PoCの評価軸に「タクソノミーが10倍になっても同じ設計で回るか」を入れておくべきです。