はじめに
データベースアーキテクトの秋山澪です。
「プロンプトに例示（Few-shot）を含めれば精度が上がるのは分かっている。しかし、あらゆるパターンを網羅しようとすればトークン上限（Context Window）を圧迫し、コストは跳ね上がる」
大規模言語モデル（LLM）を組み込んだアプリケーション開発において、多くのテックリードやPMがこの壁に突き当たります。私もデータベース設計の現場で、効率的なデータアクセスとコストのバランスに常に頭を悩ませてきました。LLMにおけるコンテキスト管理も、本質的には「限られたリソース（トークン）の中に、いかにして最適な情報（データ）を配置するか」というデータベース設計の問題と同義です。
本記事では、月間1万件の問い合わせを処理するHR-Tech系SaaS企業「TalentFlow（仮称）」が、静的なプロンプト運用からベクトルデータベースを活用した動的Few-shot（Dynamic Few-shot）へと移行した180日間の軌跡を追います。
単なる成功事例として美化するつもりはありません。技術選定での対立、実装初期に発生した深刻なレイテンシ問題、そして精度のチューニングに費やした泥臭い試行錯誤のプロセスを、ありのままに記述します。これからRAG（Retrieval-Augmented Generation）や高度なプロンプトエンジニアリングの導入を検討されている方にとって、この記事が「転ばぬ先の杖」となることを願っています。
プロジェクト概要：静的プロンプト運用が限界を迎えた日
労務管理を自動化するSaaSのような複雑なドメインにおいて、AIチャットボットの実装は容易ではありません。特に、従業員からの多岐にわたる相談に正確に回答し続けるためには、スケーラビリティを考慮したアーキテクチャ設計が不可欠です。
問い合わせ1万件規模のSaaSで発生する「回答品質のブレ」
開発の初期段階では、一般的に「静的なFew-shotプロンプティング」が採用されます。これは、プロンプトの中に固定で5〜10個程度の「質問と理想的な回答のペア」を埋め込む手法です。最新のLLMにおいても、Few-shotは回答の形式やトーンを制御し、ドメイン特有の判断基準をモデルに示す上で非常に強力なアプローチです。
しかし、サービスが拡大し、対応する労務規定が複雑化するにつれて、この静的なアプローチには限界が生じます。育児休暇、介護休暇、残業規制、海外赴任時の税務処理……。ユーザーからの質問バリエーションが増えるたびに、エンジニアはプロンプトに新しい「例示」を追加する必要に迫られます。
結果として発生するのが、特定のトピック（例えば育休）に関する例示を増やすことで、コンテキストウィンドウ内での情報密度が変化し、他のトピック（税務など）の推論精度が下がるという現象です。これはLLMの「Lost in the Middle」現象（長いコンテキストの中間に配置された情報が無視されやすい傾向）や、コンテキスト長が長くなることによる注意機構（Attention Mechanism）の分散が主な技術的要因です。
トークン数制限とコストの板挟み
さらに深刻なのがコストの問題です。ChatGPT等の高性能なLLMを使用する場合、入力トークン数はそのまま従量課金コストに直結します。
精度を維持するためにプロンプトに数十個の例示を詰め込んだ結果、1回のAPIコールあたりのプロンプトサイズは肥大化し続けます。これにより、月間のAPIコストは予測を大きく上回ることになります。
「精度を上げれば赤字、コストを削ればクレーム」。この状況は典型的なトレードオフの罠です。データベースエンジニアの視点から分析すれば、ここで起きている問題の本質は技術的な負債というよりは、「静的なデータ構造で動的なコンテキストに対応しようとしている」というアーキテクチャの不整合であると言えます。
解決策の比較検討：なぜ「動的Few-shot」だったのか
この状況を打破するために、私たちは3つの技術的アプローチを比較検討しました。
ファインチューニング vs 長文コンテキスト vs 動的検索
まず議論に上がったのがファインチューニング（Fine-tuning）です。特定のタスクに合わせてモデル自体の重みを更新する手法です。
- メリット: プロンプトに例示を含める必要がなくなり、トークン消費を最小限に抑えられる。
- デメリット: 労務規定は頻繁に法改正が行われます。そのたびに再学習（Re-training）を行う運用コストとリードタイムは許容できませんでした。また、モデルがブラックボックス化し、なぜその回答をしたのか説明責任を果たしにくい点も、HR領域では致命的でした。
次に検討されたのが、超長文コンテキスト（Long Context Window）対応モデル（Claudeの最新モデルやGeminiなど）への切り替えです。
- メリット: すべてのドキュメントと例示をコンテキストとして入力するだけで済み、実装が容易。
- デメリット: 「Needle In A Haystack（干し草の中の針）」問題への懸念が残ります。数十万〜数百万トークンの中から正確に該当箇所を拾い上げる精度は向上していますが、コンテキスト量に比例してレイテンシとコストが増大します。特に、リクエストごとに膨大なトークンを処理させるコスト効率の悪さは、高頻度で利用される社内ツールとして看過できない課題でした。
そこで浮上したのが、ベクトルデータベースを用いた動的Few-shot（Dynamic Few-shot）です。
開発チームが重視した3つの評価軸：保守性、コスト、即時性
動的Few-shotとは、あらかじめ大量の「質問・回答ペア」をベクトル化してデータベースに格納しておき、ユーザーの質問が来た瞬間に、その質問と意味的に近い事例（Top-k）だけを検索してプロンプトに注入する手法です。
私たちは以下の評価軸でこの手法を採用しました。
- 即時性: 新しい事例や法改正があっても、データベースにレコードを追加・更新するだけで即座に反映される。再学習は不要。
- コスト効率: 常に最適な3〜5個の例示のみをプロンプトに含めるため、トークン消費を一定量（かつ最小限）に抑えられる。長文コンテキストモデルを利用する場合と比較して、ランニングコストを大幅に圧縮可能。
- 制御性（Controllability）: どの例示が使われたかがログに残るため、回答の根拠が明確になり、デバッグが容易。
データベースエンジニアの視点から見ても、これは「全件スキャン（静的プロンプト/長文コンテキスト）」から「インデックス検索（動的抽出）」への進化であり、システム設計として極めて合理的でした。
実装の裏側：ベクトルDB選定と検索ロジックの最適化
方針が決まれば、次は実装フェーズです。データベースエンジニアとして、特に議論を重ねたデータベース選定と検索ロジックの最適化について、技術的な詳細を共有します。
オープンソース vs マネージド：選定の決め手
市場にはPinecone, Weaviate, Milvus, Qdrantなど、優れたベクトルデータベースが多数存在します。TalentFlow社の要件——特に将来的なスケーラビリティとデータガバナンス——に照らし合わせ、最終的にPineconeとQdrantが候補に残りました。
- Pinecone: フルマネージドであり、インフラ管理の負担が少ない点が魅力です。スケーラビリティも確保されていますが、選定当時はメタデータフィルタリングのパフォーマンス特性や、コスト予測の難しさが議論の対象となりました。（※現在はアーキテクチャの進化により改善が進んでいます）
- Qdrant: Rust製で、リソース効率とパフォーマンスに定評があります。フィルタリング機能が強力で、オンプレミス（自社VPC内）での運用も選択可能です。セキュリティ要件の厳しいHRデータを取り扱う上で、データコントロール権を完全に保持できる点が決定打となりました。
最終的に、私たちはQdrantを選択しました。最大の決め手は「フィルタリング付き近似近傍探索（ANN）の効率性」です。
労務相談においては、「正社員か契約社員か」「東京拠点か大阪拠点か」といった属性情報（メタデータ）での絞り込みが必須です。Qdrantは、このフィルタリング処理をHNSW (Hierarchical Navigable Small World) インデックス探索と高度に統合するアーキテクチャを採用しています。
HNSWは、2025年以降もYugabyteDBなどの主要なデータベース製品で新たにサポートが追加されるなど、高次元ベクトル検索における信頼性の高い標準技術として定着しています。この技術的な堅牢性と、Qdrantの実装における最適化が、高負荷時でも安定したレイテンシを維持できると判断した理由です。
意味的類似度だけでは不十分？ハイブリッド検索の導入
実装初期の検証では、単純なコサイン類似度（Cosine Similarity）だけでは意図した事例を検索できないケースが散見されました。
例えば、「有給休暇の消滅」について問い合わせた際、ベクトル空間上では「有給休暇」という概念の重みが支配的となり、「有給休暇の付与」に関する事例が高スコアでヒットしてしまう現象が起きました。「消滅」と「付与」という、実務上は正反対の意味を持つ単語の違いが、ベクトルの海の中で埋もれてしまったのです。
この課題を解決するために、ハイブリッド検索（Hybrid Search）のアプローチを採用しました。
- Dense Vector Search: 意味的な類似性を検索。モデルにはOpenAIの最新の軽量埋め込みモデルを採用し、コストと精度のバランスを図りました。
- Sparse Vector Search (BM25): キーワードの出現頻度に基づく一致度を検索。特定の専門用語や「消滅」といった重要なキーワードを捉えます。
これら2つの検索結果を Reciprocal Rank Fusion (RRF) アルゴリズムを用いて統合しました。これにより、「文脈の意味」を捉えつつ、「キーワードの完全一致」も重視するという、人間的な検索感覚に近い挙動を実現しました。これは、従来のリレーショナルデータベースにおいて、複数のアクセスパス（インデックス）を用意してクエリプランを最適化するアプローチと通じるものがあります。
直面した「3つの壁」と乗り越え方
理論上は完璧に見える動的Few-shotシステムでも、本番環境への導入フェーズでは予期せぬトラブルに見舞われることが珍しくありません。ここでは、データベースアーキテクトの視点から、多くの導入プロジェクトで直面する「現場のリアル」な課題と、その論理的な解決策を提示します。
検索レイテンシによるUX低下の危機
最初の壁として立ちはだかるのがレイテンシの問題です。
LLMの推論自体に時間がかかる上に、その前段で「ユーザー入力のベクトル化 → DB検索 → プロンプト構築」という処理が挟まるため、システム全体の応答時間が数秒単位で遅延するケースが報告されています。チャットボット等の対話型インターフェースにおいて、この「もっさり感」はUXにとって致命的となりかねません。
推奨される対策アプローチ:
ボトルネックを解消するために、以下のようなキャッシュ戦略と並列処理の組み合わせが有効です。
- セマンティックキャッシュの導入: Redisなどを活用し、過去の質問と意味的に類似した（例：類似度0.98以上）質問に対しては、LLMを介さずにキャッシュから回答を返す設計が推奨されます。
- 非同期処理による最適化: ユーザー入力のベクトル化と、並行して実行可能なルールベースのチェック処理などを非同期で行うことで、全体の待ち時間を短縮できます。
- HNSWパラメータの調整: ベクトル検索の標準アルゴリズムであるHNSW（Hierarchical Navigable Small World）は、Qdrantなどの専用DBに加え、近年ではpgvectorを採用したYugabyteDBなどの汎用DBでもサポートが拡大しています。
mやef_constructionといったインデックス構築パラメータを適切にチューニングすることで、検索精度を維持しながら応答速度を大幅に改善することが可能です。
不適切な例示抽出（ポイズニング）への対策
次に課題となるのが、「質の悪い例示が選ばれてしまう」問題です。
データベース内に蓄積された過去の事例には、古い規定に基づく回答や、例外的な対応をしたレアケースが含まれている場合があります。これらが「意味的に近い」という理由だけでプロンプトに注入されると、LLMはその「悪い例」に引きずられ、誤った回答（ハルシネーション）を生成するリスクが高まります。これはRAG（検索拡張生成）における一種のデータポイズニングと言えます。
推奨される対策アプローチ:
データのクレンジングと、検索時の動的なスコアリング実装が不可欠です。
- 事例の品質スコアリング: 各事例データに「信頼度スコア」をメタデータとして付与します。法務担当者などが確認済みの「Golden Dataset」のみを高スコアとし、検索時にフィルタリングする設計が有効です。
- 類似度の閾値設定: 検索結果の類似度が一定基準（例: 0.75）以下の場合は、無理にFew-shotを行わず、汎用的なプロンプト（Zero-shot）に切り替えるロジックを実装します。「不適切な例を見せるくらいなら、例を見せない方がマシ」という判断基準を持つことが重要です。
埋め込みモデル（Embedding）のチューニング
3つ目の壁は、ドメイン固有語彙の認識不足です。
一般的な埋め込みモデルは、特定の業界用語や社内独自の略語（例: 法律用語の特殊な略称など）を正確にベクトル化できないことがあります。これにより、本来検索されるべきドキュメントがヒットしないという問題が発生します。
推奨される対策アプローチ:
モデル自体のFine-tuningはコストと運用負荷が高いため、まずは「クエリ拡張（Query Expansion）」での対応を検討すべきです。
LLMを使用して、ユーザーの質問に含まれる社内用語や略語を、一般的な用語に変換・補足してからベクトル化する処理を前段に挟みます。このアーキテクチャにより、汎用的な埋め込みモデルを使用しながらも、ドメイン特化の高い検索精度を実現することが期待できます。
成果とROI：精度向上とトークン削減の両立
180日に及ぶ開発とチューニングの結果、TalentFlow社のプロジェクトは大きな成果を上げました。
回答精度：60%から95%への飛躍的向上
法務チームによるブラインドテストの結果、回答の正確性は導入前の約60%から95%へと飛躍的に向上しました。特に、複雑な条件分岐を伴う質問（例：「入社3ヶ月目の契約社員が病気休暇を取った場合の給与計算は？」）において、類似の過去事例を参照できるようになった効果は絶大でした。
トークン消費量30%削減によるコストメリット
コスト面でも明確な成果が出ました。以前は静的に3,000トークンほど消費していたプロンプトが、動的Few-shotにより必要な情報だけを厳選して注入する形（約800〜1,000トークン）になったことで、1リクエストあたりのトークン消費量が平均で30%削減されました。
月間のAPIコストに換算すると数十万円単位の削減であり、ベクトルデータベースのインフラコストを差し引いても十分なROI（投資対効果）が出ています。
さらに定性的な成果として、エンジニアが「プロンプト職人」から解放されたことが挙げられます。以前はプロンプトの文言を微調整することに時間を費やしていましたが、現在は「良質な事例データをDBに追加する」という、より本質的なデータ運用にリソースを割けるようになりました。
担当者からの提言：これから導入するあなたへ
最後に、データベースアーキテクトとして、これから動的Few-shotやRAGの導入を検討しているテックリードやPMの方々にアドバイスを送ります。
「まずは小さく始める」ための推奨スタック
最初から大規模なベクトルDBクラスタを組む必要はありません。まずは以下の構成でPoC（概念実証）を行うことをお勧めします。この構成は、スケーラビリティを確保しつつ、初期コストを抑えるのに適しています。
- LLM: ChatGPT または Claudeの最新モデル（特に推論能力とコンテキスト処理に優れたモデルを選択）
- Vector DB: Qdrant（Dockerでローカル起動可能で開発体験が良い）または Pinecone（Serverlessプランでインフラ管理を最小化）
- Embedding: OpenAIの最新Embeddingモデル（text-embedding-3シリーズなど、コスト対性能比が高いもの）
- Orchestrator: LangChain または LlamaIndex（RAGパイプラインの実装を効率化）
ベクトルDB導入前に整備すべきデータ基盤
最も重要なのはツールではなくデータです。「Garbage In, Garbage Out（ゴミを入れればゴミが出る）」は、AI時代においても不変の真理であり、データベース設計の基本原則です。
動的Few-shotを成功させる鍵は、検索される対象となる「事例データ（教師データ）」の品質と構造にあります。
- データの構造化: 非構造化データであっても、質問、回答、背景コンテキスト、適用条件などのスキーマを定義しているか？
- 品質の担保: その回答は現在のビジネスルールや規定に照らして正確か？（法務やドメインエキスパートによるチェック済みか？）
- メタデータの付与: ベクトル検索だけでなく、フィルタリング（Pre-filtering）に利用できる属性情報（カテゴリ、対象ユーザー層、タイムスタンプなど）が付与されているか？
これらが整備されていない状態でベクトルDBを導入しても、期待する検索精度（Recall/Precision）は出ません。まずはExcelやスプレッドシートレベルで構いませんので、良質な「正解データセット」を100件作るところから始めてください。
動的Few-shotは、LLMアプリケーションを「実験的な試み」から「堅牢な実務システム」へと昇華させるための強力なアーキテクチャです。しかし、それを支えるのは魔法のようなAIモデルではなく、堅実なデータベース設計とデータガバナンスであることを忘れないでください。
皆様のプロジェクトが、「精度の壁」と「コストの壁」を突破し、真に価値あるシステムを構築できることを応援しています。
コメント