週2500回以上使われる社内チャットボットを支えるAmazon Bedrock Knowledge Basesで作るRAG

ツール導入前の課題：チャットボットの乱立とスケールの限界

もともと、セールスやカスタマーサクセスといったビジネスサイドのメンバーから、「プロダクトの仕様についてチャットで即座に確認したい」「お客様からのセキュリティチェックシートやRFI（情報提供依頼書）への回答作成を効率化したい」という強いニーズがありました。

当初は各チームが個別に工夫し、Notion上のFAQをn8nでつなぎこんだSlackチャットボットが乱立していました。しかし、当時の主流だったチャットボットは回答生成のたびにNotion上のFAQデータを全件取得してコンテキストに詰め込むという「力技」の実装でした。 そのため、「FAQが増えれば増えるほど動作が遅くなり、コストがかかり、精度が落ちる」というスケールしないアーキテクチャの限界を迎えていました。

目指していた状態

乱立したボットを統合し、裏側であらゆるデータソースをインデクシングした1つのRAGを参照する構成への転換を目指しました。 メンテナンスの手間をかけずとも、高い性能を維持したまま、データが増えても高速で安価に動作するシステムを目指しました。

• Dify
• Amazon Bedrock Knowledge Bases (S3 Vectors)
• Amazon Bedrock Knowledge Bases (OpenSearch)

• スケールできること: データ量や同時アクセスが増えても性能が維持できること。
• メンテが簡単であること: 簡単にデータソースを追加できること。
• 安価であること: 全社的に高頻度で利用してもコストが許容範囲であること。

• 「メンテナンスの容易さ」 フルマネージドサービスであるため、ベクトルデータベースの管理やインデックス作成のパイプラインを自前で構築・運用する必要がなく、データソース（S3）を更新するだけでRAGが維持できる点が決め手になりました。DifyはAPI経由でデータソースの追加することが可能ですが、自前で実装する部分が多かったりメンテナンスコストが高く選択肢としては外れました。
• 「高いコストパフォーマンス」 Amazon Bedrock Knowledge Basesのベクトルデータベースの主な選択肢としてはS3 VectorsとOpenSearchがあります。高度な検索機能を必要とするようなレイテンシの制約が高い操作には OpenSearchが向いてきますが、チャットボットであればLLMの推論時間が長く、RAGの検索時間のレイテンシはほとんど無視できるので今回はコスト面で優位性のあるS3 Vectorsを採用しました。

• 運用の集約と効率化: 乱立していたチャットボットを1つに統合し、開発・メンテナンスリソースを一箇所に集約できました。

• 検索体験の向上: Notion、Google Drive、Zendeskなどあらゆるデータソースを定期同期するRAGにより、データ量が増えても検索性能が落ちないスケーラブルな環境が整いました。

• 高い利用率: 2026年1月時点で週に約2,500回利用されており、特に入社歴の浅いメンバーの業務効率化に貢献しています。

回答の検証可能性（ハルシネーション対策）

生成AIは無関係なトピックを組み合わせて「もっともらしい嘘」をつく傾向があります。 利用者には入社直後のメンバーも多くいるため、誤った情報を正解と信じ込むリスクがありました。回答のソースとなるデータが即座に確認できない状態であり、いかに信頼性を担保するかが課題でした。

データソースのS3への集約パイプライン

Amazon Bedrock Knowledge Basesは、S3にデータを配置した後のベクトル化はフルマネージドで自動化されます。 一方で、その前工程である「データ収集」の段階において、Notion、Zendesk、Google Slidesなど社内に散らばるデータソースを、いかに低コストかつ高頻度でS3へ同期させるかが、RAGの性能を高く維持する上での鍵となりました。

チャットボットにとらわれず社内の生産性を高める上でさまざまな用途でRAGを利用できれば良いなと思っています。特にセールスメンバーのオンボーディングや継続学習する上でのコンテンツ作成等に役立てていきたいなと思っています。