Bedrock Chat を採用する前に読む: マルチテナント知識ベースと CDK デプロイの実際
AWS-native chatbot using Bedrock
ひと目でわかる
- これは何？
- aws-samples/bedrock-chat は Amazon Bedrock を土台にしたチャットボット基盤で、RAG 付きボットの作成とボットストアでの共有、エージェントによるタスク処理までを CDK で一括デプロイする。判断の分かれ目は、OpenSearch Serverless とリージョン依存、そして v3 移行時のボット互換性にある。
- 誰に向いている？
- 社内で AWS アカウントと Bedrock のモデルアクセスを既に管理しており、RAG 付きボットを複数チームに配りたい組織には向く。逆に、マルチクラウドやオンプレの LLM を併用したい場合、OpenSearch Serverless が使えないリージョンに本番を置く場合、v2 のボット資産をそのまま持ち込みたい場合は適さない。
- 商用利用できる？
- できます。MIT-0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Bedrock Chat が埋めるのは「モデルはあるが配り先がない」という隙間
Bedrock のモデルアクセスを有効にしても、そのままでは社内の誰も使えない。API を叩く手段と、会話履歴を保持する場所と、ユーザーごとの権限を分ける仕組みを自前で組む必要がある。Bedrock Chat はこの部分をひとつの CDK スタックにまとめたサンプル実装である。README は、チャット、知識を付けたカスタムボット（RAG）、ボットストア経由の共有、エージェントによるタスク自動化の 4 つを主要機能として挙げている。想定読者は、生成 AI の社内展開を AWS アカウントの中で完結させたいプラットフォーム担当者や、PoC を短期間で動く形にしたい開発チームである。SaaS のチャット UI を契約する代わりに、自分のアカウント内に同等のものを立てる、という発想のプロジェクトだと言える。
構成の実体は CDK と FastAPI、フロントは React
リポジトリの主言語は TypeScript で、トピックには fastapi、python、react、websockets、lambda、docker が並ぶ。つまり TypeScript の CDK がインフラを定義し、バックエンドの API は Python の FastAPI、フロントエンドは React、応答は WebSocket でストリーミングする、という分担が読み取れる。デプロイの入口は bin.sh で、README の手順は git clone の後に chmod +x bin.sh と ./bin.sh を実行するだけになっている。実行すると新規ユーザーか v3 からの継続かを尋ねられ、続いてパラメータの指定に進む。CloudFormation のスタック名は BedrockChatStack で、Outputs に AuthUserPoolId から始まる値が出力され、Cognito のユーザープール ID をここから参照する。認証は Cognito、権限は Cognito グループ、という素直な設計である。
ボット作成を許可制にしている点は運用上大きい
README は governance の理由から、カスタムボットを作成できるのは許可されたユーザーだけだと明記している。条件は CreatingBotAllowed というグループのメンバーであること。このグループはマネジメントコンソールの Amazon Cognito User pools から、あるいは aws cli で設定する。出力される AuthUserPoolId を使ってプールを特定する流れだ。ここは見落としやすい。デプロイ直後は誰もボットを作れず、管理者が明示的にグループへ追加したユーザーだけが作成できる。逆に言えば、ボット作成を全員に開放する設定は用意されていない。ナレッジベースの作成にはコストとクォータが伴うため、作成者を絞る判断自体は妥当だが、グループ管理を運用に組み込まないと「ボットが作れない」という問い合わせが管理者に集中する。
マルチテナント知識ベースはクォータ回避のための設計
Amazon Bedrock Knowledge Bases は、1 つの AWS アカウントで作成できる数が既定で 100 に制限される。ボットごとに 1 つのナレッジベースを割り当てる素直な設計では、ボットが 100 を超えた時点で作成できなくなる。Bedrock Chat はこれを multi-tenant モードで回避する。共通設定のナレッジベースを複数ボットで共有し、各ボットがアップロードしたファイルを Bot ID をメタデータとして付与してフィルタリングする仕組みである。新規作成のボットはこのモードが既定で有効になる。既存ボットを移行する場合は、ボットの知識設定を「Create a tenant in a shared Knowledge Base」に変更する。複数ボットを一括で移行するコマンドも README に載っており、DynamoDB に対して aws dynamodb execute-statement で BedrockKnowledgeBase.type='shared' と SyncStatus='QUEUED' を設定し、その後 aws stepfunctions start-execution で埋め込み処理を起動する。テーブル名は BotTableNameV3、Step Functions の ARN は EmbeddingStateMachineArn という変数で示されている。共有ナレッジベース方式はクォータを回避できる代わりに、メタデータによるフィルタが全ボットに一律で効いている前提に立つ。フィルタ設計を誤ると他ボットの文書が混ざる余地が生まれるため、ここは構成を理解したうえで使いたい。
v2 から v3 への移行はボットが使えなくなる前提で計画する
README の冒頭近くに警告があり、v3 へ更新する際は docs/migration/V2_TO_V3.md を注意深く確認するよう求めている。注意せずに更新した場合、v2 のボットは使用不能になると明記されている。これはサンプル実装としては珍しく強い表現で、データモデルかナレッジベースの持ち方が v3 で変わったことを示唆する。既存の v2 環境を運用しているチームにとって、アップグレードは単なるバージョン番号の更新ではなく、ボットの再作成や設定の移し替えを伴う作業になる。移行ガイドを読まずに bin.sh を流すのは避けたい。逆に新規に v3 から始める場合、この警告は自分には関係がない。判断は「既に v2 のボット資産があるか」の一点で分かれる。
OpenSearch Serverless が使えないリージョンでは選択肢が狭まる
ボットとナレッジベースを使う場合、OpenSearch Serverless と Ingestion API が利用できるリージョンにデプロイする必要がある。README は 2025 年 8 月時点の対応リージョンとして us-east-1、us-east-2、us-west-1、us-west-2、ap-south-1、ap-northeast-1、ap-northeast-2、ap-southeast-1、ap-southeast-2、ca-central-1、eu-central-1、eu-west-1、eu-west-2、eu-south-2、eu-north-1、sa-east-1 を列挙している。加えて bedrock-region パラメータには Bedrock 自体が利用可能なリージョンを選ぶ必要があり、デプロイ先とモデル提供リージョンが別々に効いてくる。データ所在地の要件が厳しい組織では、この 2 つの制約の積集合が思ったより狭いことがある。RAG を使わずチャットだけなら OpenSearch Serverless は不要だが、ボット機能を前提にするなら最初にリージョンを確定させるべきである。
エージェント機能と API 公開は別物として評価する
エージェント機能は、外部ツールから必要な情報を取得したり、タスクを複数ステップに分解して処理したりするために使うと README は説明している。単純な Q&A ではなく、手順を踏む問い合わせに向く。一方でカスタムボットはスタンドアロンの API として公開でき、docs/PUBLISH_API.md に詳細がある。社内チャットとして使うのか、他システムに組み込む API として使うのかで、見るべきドキュメントが変わる。既存の Amazon Bedrock KnowledgeBase をインポートする機能もあり、ナレッジベースを既に運用している組織は作り直しを避けられる。管理機能としては API 管理、ボットの必須マーク、ボット利用状況の分析が用意され、docs/ADMINISTRATOR.md にまとまっている。
向く組織、向かない組織、最初に確認する 3 点
代替として挙げるなら、AWS に寄せずモデルを差し替えながら自前で UI を組む構成、あるいはマネージドのチャットサービスを契約する方向がある。Bedrock Chat との差は明確で、前者はモデル選択の自由度と引き換えに認証、履歴、権限、ナレッジベースのクォータ管理をすべて自分で設計することになる。Bedrock Chat はそこを CDK と Cognito で埋めている代わりに、AWS と Bedrock のリージョン事情に縛られる。ライセンスは MIT-0 で、サンプルとして公開されている。MIT-0 は帰属表示を要求しない寛容な条件だが、これはライセンス条件の話であり、実際の利用可否や商用展開の判断については自組織の法務確認が必要になる。保守コストの面では、v3.17.0 が 2026 年 6 月、v3.16.0 が 2026 年 4 月と更新は続いており、追従する前提で運用するなら移行ガイドを都度読む工数を見込んでおきたい。導入検討の最初の一歩は、デプロイ予定リージョンが OpenSearch Serverless と Ingestion API に対応しているかを README の一覧で確認すること。次に Cognito の CreatingBotAllowed に誰を入れるかを決めること。そして v2 のボットが既にあるなら、V2_TO_V3.md を読んでから dynamodb execute-statement による一括切り替えを実行するか判断することである。
編集部の結論
社内で AWS アカウントと Bedrock のモデルアクセスを既に管理しており、RAG 付きボットを複数チームに配りたい組織には向く。逆に、マルチクラウドやオンプレの LLM を併用したい場合、OpenSearch Serverless が使えないリージョンに本番を置く場合、v2 のボット資産をそのまま持ち込みたい場合は適さない。導入前に確認すべきは 3 点で、第一にデプロイ先リージョンが OpenSearch Serverless と Ingestion API に対応しているか、第二に Cognito ユーザープールの CreatingBotAllowed グループに誰を入れるか、第三に既存ボットがあるなら docs/migration/V2_TO_V3.md を読んだうえで BedrockKnowledgeBase.type を shared に切り替える一括更新を実行するかどうかである。
コミュニティノート