【ITニュース解説】Multi-Tenant Help Center Retrieval with Node.js and 3 Citation Checks (and Why)

マルチテナントSaaSのヘルプセンターでは、多数の顧客（テナント）が共有するシステムから、それぞれのテナントに特化した正確なサポート情報を提供する必要がある。ユーザーの質問に対し、適切な情報を探し出す「情報検索（Retrieval）」の設計は、サービスの品質を左右する重要な要素だ。この記事では、特に情報の「鮮度（Freshness）」、「アクセス制御（Control）」、「引用元明示（Citation）」という三つの観点から、情報検索システムの構築方法とそのトレードオフについて解説する。

情報検索システムの基盤となるのは、「取り込み（Ingest）」「インデックス作成（Index）」「検索（Query）」「引用（Cite）」という四つの段階からなるパイプラインだ。まず情報源がシステムに取り込まれ、検索しやすい形に加工されてデータベースに保存される（インデックス作成）。次に、ユーザーの質問に応じて関連情報が検索され、最終的な回答にはその情報源が明示される（引用）。この各段階でログ、カウンター、アラートを設定することで、問題発生時に迅速に原因を特定できる。例えば、誤った回答が報告された場合、どの段階で情報が不適切になったのかをすぐに把握できるため、AIモデルの品質を巡る不毛な議論を避けられる。

検索対象となる情報の最小単位、すなわち「検索単位」を明確に定義することは非常に重要だ。これは段落でも記事全体でも、バージョン管理されたセクションでも良い。この検索単位には、「テナントID」「ドキュメントID」「地域」「有効なタイムスタンプ」といったメタデータを含める必要がある。特にテナントIDは必須であり、検索時にこのメタデータでフィルタリングすることで、他のテナントの情報を誤って提供する「データ漏洩」のリスクを完全に排除できる。テナントの範囲外の情報を返してしまうことは、セキュリティ上許されない。最終的な回答は、回答文、引用元のリスト、そしてリクエストを特定するIDで構成され、引用元はテナントID、ドキュメントID、チャンクID、アプリケーションが生成した安定したURLやアンカーを含むべきだ。言語モデルが引用元URLを勝手に生成することは避ける必要がある。

情報の鮮度、インデックス作成のコスト、引用元の追跡という観点から、検索経路を適切に選択することが求められる。頻繁に更新されない、かつ編集審査を経た情報（公開されたトラブルシューティング記事、APIリファレンス、リリースノートなど）には、「耐久性のあるベクトルインデックス」の利用が効率的である。これは、情報の意味内容を数値のベクトルに変換して保存し、意味的に類似したものを高速に検索する仕組みだ。一方、ヘルプセンターに即座に反映されるべき、リアルタイムで変化するコンテンツには、「ライブ検索」や「スクレイピング」の経路を設ける必要がある。これらを組み合わせ、まず耐久性のあるインデックスから情報を取得し、その上でライブ検索で最新情報を補完するという方法も考えられる。

この二つのアプローチには明確なトレードオフが存在する。インデックスの再構築頻度を上げれば鮮度は向上するが、大規模になるほどインデックス作成やベクトル埋め込みのコストが増大する。ライブ検索は古いコンテンツを減らせるが、リクエスト処理時の遅延が増え、システムに新たな依存関係が生まれる。引用元の追跡は、IDが安定している耐久性のあるチャンクの方が容易だ。ライブページの場合、引用したテキストを後から再現できるように、取得した時点のバージョンやコンテンツのハッシュ値を記録しておく必要がある。

引用の正確性を担保するには、検索によって返された情報と、最終的に回答で引用された情報が、同じテナントに属し、実際に検索結果の中に存在していたかを検証する仕組みが不可欠だ。記事では、validateCitationsという関数による契約チェックの例が示されている。これは、検索結果に含まれる「ヒット」情報と、最終的な「引用」情報を比較し、引用が正当なものかを検証する。このようなチェックは、リリース前のテストだけでなく、本番環境でのメトリクスとしても活用されるべきである。

情報検索に使用する「ベクトルデータベース」にはいくつかの選択肢がある。それぞれに強みと、コストや制御に関するトレードオフが存在する。「Pinecone」はマネージドなベクトル特化サービスで運用が比較的容易だが、周辺データに対する制御は限定される。「Weaviate」はベクトル検索とスキーマ指向のデータベース機能を組み合わせるが、新たな運用サービスが必要となる。「Elasticsearch」は既存の全文検索機能と連携しやすく、フィルタリング機能も強力だが、ベクトル検索のチューニングが他の検索処理とリソースを共有する。「Postgres」に「pgvector」という拡張機能を追加する方法は、アプリケーションに近い場所でデータと権限を管理できる利点があるが、インデックスの最適化やスケーリングといった運用作業の多くを開発チームが担う必要がある。

複数のバックエンド機能を、単一の統一されたREST APIインターフェースで提供するサービスも存在する。記事中で例示されている「Infrai」のようなサービスは、異なる種類の検索能力を同じAPI契約の下で利用できるようにする。これにより、複数の異なるSDKや認証フローを管理する手間を省き、システム全体の監視（Observability）を簡素化できる可能性がある。ただし、この場合でも、テナントごとのアクセス制御ポリシーや引用の検証はアプリケーション側でしっかりと設計・実装する必要がある。

システムを本番稼働させる前には、そのパイプライン全体が「可観測性」を備えていることが重要である。各段階で構造化されたイベント（ログ）を発行し、テナントID、リクエストID、ドキュメントのバージョン、検索候補の数、選択されたチャンクID、引用検証の結果といった情報を記録する。機密情報でない限り、記事本文をログに含めることは避ける。引用漏れ、フィルタリングの不一致、検索候補数の急激な変動など、具体的な異常に対してアラートを設定することで、漠然とした「回答品質」の低下よりも早く、具体的な問題に対処できるようになる。

新しい情報検索システムを導入する際には、段階的なアプローチが推奨される。まずは既存のシステムと並行して新しい検索機能を「シャドーイング」（裏側で実行し、結果を比較する）し、事前に用意した評価用の質問セットで性能や引用の失敗を検証する。その後、一部のテナントグループに限定して新機能を公開し、徐々に利用範囲を広げていくのが安全な方法である。どちらがよりコスト効率が良いか（再インデックス頻度を上げるか、ライブ検索を利用するか）は、システムのトラフィックパターンや鮮度に関する要件、インデックス作成にかけられる予算によって異なるため、実際の環境で測定して判断すべきだ。

運用の所有権も重要な選択基準となる。コンプライアンス要件によりインデックスを自社でホストする必要がある場合や、データベースレベルのクエリプランの調整、カスタムランキングコードが必要な場合は、Postgres + pgvectorやElasticsearchのような自社運用が可能なソリューションを選ぶべきである。一方で、複数のバックエンド機能を単一の認証情報と一貫したHTTPインターフェースで利用したい場合は、統一APIを提供するサービスが賢明な選択肢となり得る。ただし、この場合でもテナントごとのフィルタリングや引用の検証はアプリケーションが責任を持つ必要があることを忘れてはならない。マルチテナント環境における情報検索システムの設計は、単なる技術選定に留まらず、セキュリティ、信頼性、運用効率といった多角的な視点から慎重に検討されるべき複雑な課題だ。