Amazon Bedrock Managed Knowledge Base でマルチテナント型チャットアプリ構築

大規模顧客から頻繁に寄せられる要望の一つが、マルチテナント対応のエージェント型チャットアシスタントです。その中でも特に需要が高いのが、文書ベースのチャット機能です。

ユーザーは契約書や報告書、製品マニュアルなどをアップロードし、直近または将来に向けてそれらに関する調査や質問を行います。会話インターフェース自体は比較的簡単に構築できますが、その背後にあるマルチテナント対応のエージェント型検索システムはそうではありません。

各テナントの文書は他テナントと完全に隔離されなければなりません。また、この境界線はクライアントから送信される値ではなく、検証されたアイデンティティに基づいて強制される必要があります。エージェント型検索はこの課題をさらに複雑にします。エージェントは質問をサブクエリに分解し、複数の検索を実行しますが、そのすべてのステップでテナントフィルタが適用されなければ、隔離が破綻してしまいます。

さらに必要となるのは、ベクトル検索と全文検索エンジン、そして複数のモダリティを解析・埋め込むインジェストパイプライン、同期されたインデックスです。この機能をリリースするチームにとって、これらを構築し、セキュリティを確保し、運用することは相当なインフラストラクチャの負担となります。

Amazon Bedrock Managed Knowledge Base を利用すれば、差別化の難しいインフラ管理作業を軽減できます。このサービスは、データ取り込み（ingestion）、保存、埋め込み（embedding）、検索ランク付けをすべて管理するため、リソースのプロビジョニングや容量監視の手間が不要です。インフラ管理を超えて、反復的な計画立案と多段階の検索（multi-hop retrieval）を活用したネイティブなエージェント型検索機能を提供し、複雑な質問にも対応します。また、各検索ステップでアクセス権限を厳格に適用します。

カスタムコネクタを通じた直接取り込みでは、アプリケーションからドキュメントがそのまま知識ベースへ送信され、数秒以内に検索可能になります。

本稿では、Amazon Bedrock Knowledge Bases を基盤としたマルチテナント対応のエージェント型ドキュメントチャットアプリケーションのアーキテクチャを紹介します。このソリューションには、ドキュメント取り込みと対話形式での情報取得という 2 つのデータフローがあります。これらに加え、非同期インデックス処理のライフサイクル、ユーザーごとのデータ分離機能、および大規模運用におけるベストプラクティスについて解説します。また、本稿に付随するリポジトリも提供しているため、ご自身の AWS アカウントでコードをすぐにデプロイ可能です。

ソリューション概要

このソリューションは、導入部で指摘した課題に対応しています。各ユーザーが独自にドキュメントをアップロードし、即座に根拠のある質問ができるマルチテナント対応のドキュメントチャット体験を実現します。チーム側では、検索スタックの構築や、あるユーザーのコンテンツと他者のコンテンツを分離するロジックの実装といった手間は一切不要です。

ユーザーが質問を投げかけると、アプリケーションは Amazon Bedrock Knowledge Bases 上のエージェント型検索 API を呼び出します。この API は、質問への回答方法を判断するエージェントワークフローを実行します。単純な参照が必要な場合は単一の検索を実行し、複雑な多段階の質問に対しては、質問をサブクエリに分解して複数の検索を実行した上で回答を生成します（マルチホップ検索）。

どちらの場合も、回答は取得されたパッセージに基づき、出典が明記されます。このアーキテクチャが運用しやすいのは、検索と生成に関わるコンポーネントを知識ベース自身が管理している点にあります。具体的には、何を参照すべきかを判断する計画ステップ、ベクトルインデックス、ランク付け機能、そして最終的な回答を生成するモデルです。アプリケーション側で担当するのは、アップロード体験やチャット UI、認証、ユーザーごとの分離、独自のビジネスロジックなど、製品固有の部分のみとなります。

本ソリューションは以下の主要コンポーネントで構成されています：

• Amazon Bedrock Managed Knowledge Base：マルチモーダルコンテンツのクロール、解析、保存、検索を行います。テキストやベクトル、メタデータに加え、CSV や Excel ファイルなどの構造化コンテンツに対する検索インフラをプロビジョニング・管理します。また、管理されたパース処理、埋め込み（embedding）、インデックス化も提供します。カスタムコネクタデータソースでは、ユーザーからのアップロードを直接取り込むことができます。

• Amazon API Gateway と AWS Lambda：ドキュメントのアップロード、ステータス確認、チャット機能のエンドポイントを公開し、アプリケーションロジックを実行します。

• Amazon Cognito：ユーザー認証を行い、各ユーザーの文書を分離するためにアプリケーションが利用する検証済みアイデンティティを提供します。

• Amazon Simple Queue Service（Amazon SQS）：アップロードと取り込み処理を非同期化し、急増するアップロードリクエストを吸収します。また、繰り返し失敗したメッセージはデッドレターキューへルーティングします。これにより、取り込み側の負荷に関わらずアップロードエンドポイントの応答性を維持できます。

• Amazon DynamoDB：各ドキュメントのインデックス作成ステータスを追跡し、ユーザーに対してドキュメントが利用可能になったタイミングを通知します。

• Amazon Simple Storage Service（Amazon S3）：インライン制限を超えるサイズのファイルを一時保存し、シングルページアプリケーションを Amazon CloudFront の背後にホストします。

以下の図は、本ソリューションのアーキテクチャを示しています。

Figure 1: Architecture of the multi-tenant document chat solution

ワークフローは、図と番号が一致する以下の手順で構成されています。

• ユーザーは Amazon Cognito を通じてサインインし、ドキュメントをアプリケーションにアップロードします。すべてのリクエストにはユーザーの JSON Web Token（JWT）が含まれており、Amazon API Gateway がこれを検証します。アプリケーション側では、クライアントから送信された値を信頼するのではなく、サーバー上でユーザーのアイデンティティを導出します。

このアプリケーションは、検証済みの JWT からユーザーの身元情報を抽出し、ドキュメント（またはその S3 参照先）とともに SQS メッセージに含めます。処理はバックグラウンドで実行されるため、ブラウザがブロックされることなく即座にレスポンスを返します。6 MB までのファイルは API リクエスト内でインライン送信されます。それより大きいファイルはまず Amazon S3 にアップロードされ、SQS メッセージには Amazon Bedrock が直接ファイルを読み込めるよう S3 URI が格納されます。

ワーカー Lambda 関数がキューからメッセージを読み取り、ドキュメントに user_id というメタデータ属性を追加します。この値は、呼び出し元の Amazon Cognito の sub に設定されています。認証済みアップロードハンドラーがその値をメッセージに付与しています。その後、ワーカーは IngestKnowledgeBaseDocuments API を呼び出し、Amazon Bedrock が非同期でドキュメントのチャンク化、埋め込み、インデックス化を行います。

各ドキュメントの状態は Amazon DynamoDB に記録されます。ブラウザはステータスエンドポイントをポーリングし、DynamoDB からデータを読み取って UI を更新します。ユーザーはページをリフレッシュすることなく、ドキュメントが「受信」から「処理中」、そして「準備完了」へと移行する様子を確認できます。

質問をする際は、ユーザーはその内容をアプリケーションに送信します。

質問への回答では、アプリケーションは user_id に対して明示的な等値フィルターを指定して AgenticRetrieveStream API を呼び出します。このフィルター値は、検証済みの JWT からサーバー側で構築されるため、リクエスト本文から取得されることはありません。これにより、ユーザーは自分自身のドキュメントのみを検索可能になります。知識ベースが一致するパッセージを返すと、ファウンデーションモデルが引用付きの回答を生成し、アプリケーションがそれをストリーミングしてユーザーへ返します。

ソリューションの概要

以下のセクションでは、リクエストがソリューション内をどのように流れるかを追跡します。具体的には、取り込みパス、インデックスのライフサイクル、ユーザーごとの分離、そして検索の詳細について掘り下げていきます。

ユーザーアップロードの直接取り込み

ユーザーがアプリケーション稼働中にドキュメントをアップロードする場合、本番環境では S3 コネクタではなく、カスタムコネクタデータソースを経由して直接取り込みを行います。S3 コネクタは、スケジュール同期で定期的に更新される大量のドキュメントを一括取り込むために設計されており、その同期プロセスによってユーザーが直近で追加したドキュメントが上書きまたは削除されてしまうリスクがあります。

一方、IngestKnowledgeBaseDocuments API を介して直接取り込む場合、同期処理は行われません。そのため、明示的に削除するまでドキュメントは永続的に保持されます。また、ユーザーごとに独自のドキュメント ID を割り当てることで、個別の管理や更新作業を簡素化できます。知識ベースには、各オリジナルファイルのコピーが保存されており、GetDocumentContent API を使用していつでも取得可能です。その結果、別途ドキュメントストアを運用する必要がなく、ユーザーは回答の背後にあるソースファイルを直接開くことができます。

本アプリケーションでは、ファイルサイズに応じて2つの取り込みパスから自動的に選択します。6 MB のインライン制限以内のファイルは、API コール内でバイトデータとして送信されます。これは、一般的なテキストドキュメント、契約書、報告書などをカバーする範囲です。それより大きいファイル（テキストの場合最大 50 MB）については、一旦 Amazon S3 にステージングし、S3 URI を参照して取り込みを行います。

このサイズ判定ルールはサーバー側で適用されるため、ユーザーにはその経路が透明化されており、どちらのパスを選んでも最終的に同じ知識ベースに統合されます。

設計において重視すべき API の挙動が 2 つあります。まず、ドキュメント ID を自分で設定できる点です。同じ ID でドキュメントを再インデックスすると、重複を作成するのではなく既存のドキュメントがその場で更新されます。これはユーザーがファイルを置き換える際に望ましい動作です。

アプリケーション側で、ユーザーのファイルとドキュメント ID の対応関係を管理する必要があります。参考実装では、インデックス化ステータスを追跡するための DynamoDB テーブルに、(user_id, filename) → document_id というマッピング情報も格納されています。そのため、ユーザーがファイルを再アップロードした際にも、アプリケーションは既存の ID を参照して再利用します。

（注：部分的な更新機能はありません。）

編集は完全な再取り込みを意味します。第二に、1 回の IngestKnowledgeBaseDocuments コールで最大 10 件のドキュメントを受け付けるため、ワーカーは複数の取り込みジョブを 1 つのリクエストにまとめて実行できます。この使い方はベストプラクティスセクションで詳しく解説します。

ドキュメントのインデックス作成ライフサイクル

IngestKnowledgeBaseDocuments API は非同期処理です。呼び出し直後に STARTING ステータスで即座に返答しますが、Amazon Bedrock が文書の解析、埋め込み、インデックス化を完了するまで、その文書は検索・利用できません。各文書は以下の表に示す通り 5 つの状態を経て進み、最終的に INDEXED ステータスになった時点で初めて完全な照会が可能になります。

インデックス作成にかかる時間は、ドキュメントの種類によって異なります。以下の表は、アイドル状態の知識ベースに対して小規模なドキュメント（5 MB 未満）で実施したテストで確認した値です。

ただし、実際の所要時間はドキュメントのサイズや内容の複雑さ、リージョン、および知識ベースへの負荷状況によって変動します。これらの数値はサービスレベルの保証ではなく、設計時の目安として捉えてください。

負荷がかかると、ドキュメントは処理スロットを待つ間 PENDING 状態となり、インデックス化されるまでの時間は取り込みキューの深さに比例して長くなります。 （原文の技術表記: INDEXED）

本アプリケーションは、GetKnowledgeBaseDocuments API をポーリングし、各ドキュメントの状態を DynamoDB に記録します。UI 上では、この状態が「受信済み」「処理中」「準備完了」として表示されます。ドキュメントが TEXT_INDEXED ステータスに達した時点で検索可能となるため、その段階で即座に「準備完了」マークを付け、待機する必要はありません。

INDEXED。この 2 つの状態の違いは、PDF やその他のマルチモーダルコンテンツにおいてのみ意味を持ちます。TEXT_INDEXED の状態では、テキストチャンクが照会可能となり、検索ニーズの大部分をカバーします。

INDEXED 状態では、PDF 内の画像や表などのマルチモーダル要素も検索可能です。ただし、ドキュメントがまだインデックス化されている最中（STARTING）に「検索可能」として扱われると、その時点でのクエリは空の結果を返すことになります。

メタデータフィルタリングによるユーザーごとのデータ分離

マルチテナントアプリケーションでは、あるユーザーのドキュメントが別のユーザーの結果に混在してはなりません。この境界線を確保するには、主に 2 つの方法があります。

一つ目は各テナントごとに個別のナレッジベースをプロビジョニングする方法です。もう一つは単一の共有ナレッジベースを使用し、すべてのクエリを呼び出し元のユーザーにスコープさせる方法です。後者の共有アプローチでは、サービスが評価するメタデータフィルターまたはドキュメントレベルのアクセス制御リスト（ACL）を通じて各クエリのスコーピングを行います。

エンドユーザー数が多数いるアプリケーションの場合、共有ナレッジベースが最適な選択肢となります。これは、アカウントごとのナレッジベース制限を回避でき、多数の小規模なインデックスによる基本コストを抑え、サインアップ時にナレッジベースを作成する際のプロビジョニング遅延も解消できるためです。

Amazon Bedrock のナレッジベースは、単一の呼び出しで複数のナレッジベースにクエリを実行できます。この機能は、1 人のユーザーに対して異なる知識ドメインを組み合わせることを意図したものであり、テナント同士を分離させるためのものではありません。ただし、少数の大規模なテナントを持ち、厳格な分離要件がある場合は、テナントごとのナレッジベースを採用する意義があります。

ユーザーレベルでのマルチテナンシーにおいては、共有ナレッジベースの方がスケーラビリティに優れ、設定の手間も少なくて済みます。

ワークフローに示されている通り、ワーカーは各ドキュメントに user_id メタデータ属性を付与し、アプリケーション側では同じ属性に基づいてすべてのクエリをフィルタリングします。このフィルタ値は、検証済みの JWT を用いてサーバー側で生成されます。このサーバーサイドでの導出がセキュリティの境界線となります。

なお、ナレッジベースは質問の文言からフィルタを推論することも可能ですが、これは関連性の向上機能であり、アクセス制御ではありません。真の分離を実現するには、認証されたアイデンティティに基づいてアプリケーション側で明示的なフィルタを構築する必要があります。

防御の多層化の一環として、リファレンス実装では各リクエスト前にフィルタが呼び出し元に限定されていることを確認し、user_id が一致しないチャンクはすべて破棄します。

認証されていないリクエストには HTTP 401 を返し、認証済みでも sub の解決ができない場合は HTTP 403 を返します。サービス自体がアクセスを制御する必要がある規制対象のワークロード向けに、ナレッジベースではクエリ実行時に userContext を評価してドキュメントレベルのアクセス制御リスト（ACL）をサポートしています。これにより、権限管理のロジックをアプリケーションコードから切り離すことが可能です。

検索と応答生成

検索フローのうち、より直接的な手法が「Retrieval」です。AgenticRetrieveStream API は、1 回の呼び出しでチャットの一巡（ターン）を完結させます。

この API は質問をサブクエリに分解し、各クエリに対してユーザー固有のフィルタを適用しながら検索を実行します。また、generateResponse を有効化すれば、根拠のある回答を引用付きでストリーミング配信できます。チャットインターフェースとの親和性が高く、検索と生成のオーケストレーションを手動で行わなくても、最初のトークン到達までの時間を短縮できます。

なお、Managed Knowledge Base では RetrieveAndGenerate API はサポートされていません。

テナントごとにカスタムプロンプトや特定のモデルなど、より細やかな制御が必要な場合は、Retrieve API を使用してパッセージを取得し、同じユーザーごとのフィルタを指定して Converse API を直接呼び出してください。引用元のソースを表示する必要がある場合は、GetDocumentContent API を利用して、プレビューまたはダウンロード用の元文書を取得できます。

ベストプラクティス

以下のプラクティスは、利用規模が拡大してもこのフローを安定させるために役立ちます。

アップロードと取り込みをキューで分離する。 低負荷のワークロードであれば、アップロードハンドラーから直接 IngestKnowledgeBaseDocuments を呼び出すことができます。ただし、複数のユーザーからの並列なアップロードを想定するアプリケーションでは、アップロードエンドポイントと取り込み処理の間に Amazon SQS キューを設置してください。

アップロードエンドポイントはファイルを受け取ると、取り込みジョブをキューに書き込んで即座にレスポンスを返すため、ブラウザが取り込み処理でブロックされることはありません。一方、ワーカー Lambda 関数がキューからメッセージを読み取り、1 つの IngestKnowledgeBaseDocuments コールあたり最大 10 ドキュメントをまとめてバッチ化します。

これは、アップロードが集中した際に取り込みスループットを最大化するための主要な手段です。例えば、500 人のユーザーがほぼ同時にドキュメントをアップロードした場合でも、ワーカーは 500 個のキューイングされたジョブを約 50 回のバッチ API コールに変換します。

繰り返し失敗したメッセージは調査用のデッドレターキューへ転送されます。この設計により、突発的なアクセスバーストを吸収でき、取り込み呼び出しのレート管理を一箇所に集約できます。また、下流側の負荷（バックプレッシャー）に関わらず、アップロードエンドポイントの応答性を維持することも可能です。

現在の取り込みスループット制限については、Amazon Bedrock のクォータドキュメント をご参照ください。

インデックス作成の上限ではなく、データ取り込み（ingestion）の上限を計画してください。 データ取り込みと検索はスケールする特性が異なります。Retrieve API は、1 キオレッジベースあたり 25 クエリ/秒（QPS）のバーストまたは 10 QPS の持続的な処理をサポートしており、会話ワークロードには十分すぎるほどです。そのため、検索能力がボトルネックになることは稀です。一方、データ取り込みのスループットは対話型のアップロードには十分ですが、既存のリポジトリを一括移行する際には飽和してしまう可能性があります。そのようなケースでは、S3 コネクタを使用してスケジュールされた同期を行うことをお勧めします。これは大規模なコーパスの一度きりの読み込みに設計されており、リアルタイムのユーザーアップロードと競合しません。

並列処理の制限は再試行可能な条件として扱ってください。 並列処理の上限を超えると、Amazon Bedrock は ThrottlingException ではなく ValidationException を返します。スロットリング時のみ再試行するロジックでは、これを致命的なエラーとみなしてドキュメントを破棄してしまう可能性があります。

ボトルネックを示すシグナルを監視してください。 データ取り込みの成功率を追跡し、