大量のタグ付けでLLMに「選択」させるのは間違い？「自由に生成させて後から照合する」プロンプトエンジニアリングの逆転発想

日々蓄積される大量のブログ記事やWebサイトのコンテンツ、あるいは社内のドキュメント。これらを綺麗に整理するために「タグ付け」を行いたいと考えたことはありませんか？

長年サイトを運用していると、既存のタグが数百〜数千個にまで膨らんでしまうことがあります。例えば、あるWebサイトに「1,856個」の既存タグが存在しているとしましょう。

「せっかく最新の生成AI（大規模言語モデル：LLM）があるのだから、記事の本文を入力して『この1,856個のタグの中から、記事に合うものを選んでタグ付けして』と頼めば自動化できるはずだ」

そう考えるのはごく自然なことです。しかし、実際にこれをプロンプト（AIへの指示文）として組み込もうとすると、すぐに大きな壁にぶつかります。選択肢が多すぎてAIに指示を読み込ませることができなかったり、APIの利用料金が跳ね上がったり、AIが選択肢の多さに混乱して適切な返答をしてくれなくなったりするのです。

この問題をスマートに解決するのが、プロンプトエンジニアリングにおける逆転の発想、「Don’t classify. Hallucinate!（分類させるな、自由生成させよ）」というアプローチです。

この記事では、大量のデータ分類に悩む開発者やマーケター向けに、このアプローチの基本的な考え方から、実務でのプロンプト設計、システム構築のステップ、そして運用時の注意点までをわかりやすく解説します。

大量データの自動分類で壁にぶつかっていませんか？

プロンプトエンジニアリングとは、生成AIから望む出力結果を得るために、AIへの指示文や入力データの渡し方を工夫・最適化する技術のことです。

多くの人がAIに分類タスクを行わせる際、以下のようなアプローチをとりがちです。

1. プロンプトの中に「すべての選択肢（例：1,856個のタグ）」をリストとして書き込む。
2. 「以下の文章を読み、上記のリストの中から合致するものをすべて選び出してください」とAIに指示する。

一見すると論理的な手法に見えますが、実務においては3つの重大な問題が発生します。

1. 入力制限（トークン数）とコストの肥大化

AIが文章を処理する際、文字や単語の単位を「トークン」という単位で計算します。1,856個ものタグリストを毎回プロンプトに含めると、それだけで膨大なトークン数を消費します。AIの利用料金は処理したトークン数に応じて課金されるため、記事1本を分類するたびに高額なコストが発生してしまいます。また、AIが一度に受け取れる入力の上限を超えてしまうリスクもあります。

2. 処理速度の低下

入力するデータ量が大きくなればなるほど、AIが回答を生成し始めるまでの時間（レスポンスタイム）が長くなります。何千本もの記事をバッチ処理で自動分類したい場合、この遅延がボトルネックとなります。

3. 目的の選択肢を見落とす（注意力の低下）

長大なプロンプトを与えられたAIは、文章の中央付近にある情報を軽視したり、見落としたりする傾向があります。1,856個ものリストを与えても、すべての選択肢を公平に吟味して正しく選べるとは限らないのです。

では、この「選択肢が多すぎてAIに分類（Classify）させられない」という問題を、どのように解決すればよいのでしょうか。

「分類させるな、自由生成させよ」：プロンプトエンジニアリングの逆転の発想

そこで登場するのが、海外の著名なソフトウェアエンジニアであるサイモン・ウィリソン（Simon Willison）氏が提唱する「Don’t classify. Hallucinate!」という設計パターンです。

ここでいう「ハルシネーション（Hallucinate）」とは、直訳すると「幻覚」という意味です。通常、AIの分野におけるハルシネーションは「AIが存在しない事実や偽の情報を、まるで本当のことのように堂々と作ってしまう現象」を指し、克服すべき課題として扱われます。

しかし、この手法ではあえてAIの「自由に言葉を作り出す性質」をポジティブに活用します。

アプローチの根本的な違い

従来の「分類（Classify）」アプローチと、今回の「自由生成（Hallucinate）」アプローチの違いを整理してみましょう。

• 従来のアプローチ（分類）

  • プロンプト：「1,856個のタグリスト（超長文）をあげるので、この文章に合うものをこの中から選んでください」
  • 負担のかかる場所：プロンプトの入力サイズ、AIの文脈理解

• 新しいアプローチ（自由生成＋システム照合）

  • プロンプト：「この文章に合う適切なタグを、思いつくまま自由に5つ作ってください（選択肢のリストは与えない）」
  • 負担のかかる場所：生成後のプログラム側でのデータ照合処理

つまり、「AIに大量の選択肢から選ばせる」のし、「AIには知識に基づいて自由にタグを生成させ、出てきたタグを後からプログラムで既存のデータベース（1,856個のリスト）と突き合わせる」という二段階の構成にするのです。

なぜこのアプローチが強力なのか？

1. プロンプトが劇的に軽くなる プロンプトには記事本文と数行の指示文を入れるだけで済みます。1,856個のリストを載せる必要がないため、トークン消費量を数十分の1に削減でき、APIコストを大幅に抑えられます。

2. AIが最も得意な処理をさせられる 生成AIは「膨大な制約文の中から条件に合うものを探す」ことよりも、「与えられた文章の文脈を理解して、関連するキーワードを自由に言語化する」ことの方がはるかに得意です。AIの強みを素直に生かせる設計になります。

3. 新しいタグの発掘につながる 既存のタグリストに縛られないため、時代に合わせた新しいキーワードや、人間が思いつかなかった分類表現をAIが提案してくれる副次的なメリットもあります。

実務での導入とシステム設計の具体ステップ

この「自由生成＋照合」パターンを実際の業務システムやWebサイトの管理ツールに組み込むための、具体的な設計ステップを解説します。

全体像は「プロンプトによる自由生成フェーズ」と「プログラムによるデータ照合フェーズ」の2ステップで構成されます。

ステップ1：プロンプト設計（生成フェーズ）

まずはAIに指示を出すためのプロンプトを作成します。ここでは既存のタグリストを一切見せず、記事の内容に集中させます。

【プロンプトの設計例】

1
2
3
4
5
6
7
8
9

以下の記事本文を読み、内容を適切に表す具体的なタグ（キーワード）を3〜5個生成してください。

# 記事本文
[ここに記事のテキストを入力]

# 出力フォーマット
- タグ1
- タグ2
- タグ3

このように、プロンプトは非常にシンプルで済みます。AIはこの指示を受けて、記事の内容に応じたタグ（例：「人工知能」「データ分析」「自動化」など）を自由に生成して返してくれます。

ステップ2：プログラムによる既存データとの照合（照合フェーズ）

AIから返ってきた文字列を受け取ったら、バックエンドのシステム（PythonやJavaScriptなどのプログラム）で、既存の1,856個のタグリストと突き合わせを行います。

照合には以下のような複数のレベル（手法）を組み合わせて利用します。

1. 完全一致検索（Exact Match） AIが生成したタグが、既存のタグデータベースにそのまま存在するかを確認します。

   • 例：AI生成「データ分析」 ＝ 既存タグ「データ分析」（一致！）

2. 表記揺れの吸収・正規化 大文字・小文字の違い、全角・半角の違い、余計な記号などを取り除いて比較します。

   • 例：AI生成「Python」 ＝ 既存タグ「python」（正規化して一致！）

3. 類似度判定（ベクトル検索 / エンベディング） AIが出した言葉と既存のタグが「意味的にどれくらい近いか」を計算します。 「エンベディング（Embedding）」という技術を使うと、言葉の意味を数字の列（ベクトル）に変換できます。これにより、文字としては一致していなくても意味が近いタグを探し出すことができます。

   • 例：AI生成「人工知能」 ≒ 既存タグ「AI」（意味が非常に近いと判定して紐付け！）

4. 同義語・シソーラス辞書の利用 社内用語や業界用語の言い換えルールを事前に辞書として用意しておき、置き換えを行います。

このように照合処理をプログラム側に寄せることで、正確かつ高速に既存タグとのマッチングを完結させることができます。

導入時の注意点と限界：未確認事項とリスクの管理

この手法は非常に強力ですが、実際に運用するにあたってはいくつか知っておくべき注意点と限界が存在します。

1. マッチング処理（照合）の実装コストがかかる

単純に「AIのAPIを呼び出して結果をそのまま画面に表示する」だけでは完結しません。AIが生成したテキストを既存データベースと照合するロジック（完全一致やベクトル類似度検索など）を自社システム側に実装する必要があります。

2. 類似度の閾値（いきおい）の設定とチューニング

ベクトル検索などで意味の近さを判定する場合、「どれくらい似ていたら同じタグとみなすか」という基準値（閾値）の設定が必要です。 基準を緩くしすぎると、無関係なタグが紐付いてしまい、基準を厳しくしすぎると、既存タグがあるにもかかわらず「一致するタグなし」と判定されてしまいます。実運用をしながらチューニングを行う期間が必要です。

3. 未確認事項について

今回参照した一次情報（Simon Willison氏のブログ記事）においては、1,856個のタグを持つ自身のブログ記事の整理という具体的な文脈が示されているものの、具体的にどのベクトル検索ライブラリ（Chromaやpgvectorなど）を使用したのか、また処理速度や照合成功率などの定量的（数値的）なベンチマーク結果については記載されておらず未確認です。

そのため、自社システムへ本格導入する際は、小規模なデータ（数万文字〜数十記事程度）でプロトタイプを作成し、照合精度やコストの削減効果を検証（PoC）することを強く推奨します。

まとめ：プロンプトエンジニアリングの幅を広げる設計思考

AIを活用したシステム開発において、すべてをプロンプトの中だけで解決しようとする（＝AIにすべてをやらせる）のは、必ずしも最善策とは限りません。

今回の「Don’t classify. Hallucinate!」というアプローチから学べる最大の教訓は、「AIが得意なこと」と「従来のプログラミングが得意なこと」の役割分担を明確にするということです。

• AI（LLM）の役割：非定型な文章を読み解き、文脈に沿ったキーワードを自由かつ柔軟に生み出すこと（生成・ハルシネーション）
• 従来のシステム・プログラムの役割：大量のデータから正確な一致を検索し、ルールに基づいて高速にデータを整理すること（照合・正規化）

「大量の選択肢からAIに選ばせるのが難しい」と感じたら、ぜひ「AIに一度自由に作らせて、後からシステムで照合する」というプロンプトエンジニアリングの設計パターンを試してみてください。

タグ付けだけでなく、問い合わせの自動カテゴリ分類、ECサイトの商品属性付与、ドキュメントの自動整理など、大量のデータ分類が必要とされるあらゆる実務シーンで活用できるはずです。

参考資料

• Don’t classify. Hallucinate! - Simon Willison’s Weblog