SalesforceとZendeskがAmazon Bedrockのナレッジソースに
AWSは、Amazon Bedrock Managed Knowledge BaseでSalesforceとZendeskをネイティブデータソースとして利用できるコネクターの提供を開始しました。
これにより、Salesforceのナレッジ記事、Zendeskのヘルプセンター記事やコミュニティ投稿を、Amazon Bedrockのマネージドなナレッジベースへ取り込めます。利用者は各サービスの認証情報を設定することで、データのクロール、メタデータ抽出、増分同期をコネクターに任せられます。
従来は、SalesforceやZendeskからデータを取得し、形式を変換して保存し、更新差分を検出して再取り込みする独自パイプラインを構築する必要がありました。今回の対応は、RAGアプリケーションやAIエージェントを業務システムのナレッジに接続する際の初期実装と運用負荷を下げるものです。
これまでの自作データ連携で必要だったこと
SalesforceやZendeskの情報をRAGで利用する場合、単にAPIから記事を取得するだけでは実用的な検索基盤になりません。一般的には、次のような処理が必要です。
- SalesforceやZendeskのAPIに接続する認証処理
- 記事本文、タイトル、カテゴリ、更新日時などの抽出
- HTMLやリッチテキストの不要な要素を除去する前処理
- 文書を検索しやすい単位へ分割するチャンク処理
- 埋め込み生成とベクトルストアへの登録
- 新規作成、更新、削除を検出する差分同期
- 取り込み失敗時のリトライ、監視、再実行
- APIのレート制限や認証情報の更新への対応
自作方式は柔軟性が高い一方、RAGの回答精度とは直接関係しないデータパイプラインの保守が継続的に発生します。記事の更新を取りこぼすと、AIが古い情報を根拠に回答するリスクもあります。
ネイティブコネクターでは、少なくともクロール、メタデータ抽出、増分同期に関する処理をマネージドサービスへ寄せられます。開発チームは、データ取得の実装よりも、検索設計、回答生成、評価、アクセス制御といったアプリケーション固有の課題に集中しやすくなります。
ネイティブコネクターと自作パイプラインの比較
| 観点 | ネイティブコネクター | 自作データ連携 |
|---|---|---|
| 初期実装 | 認証情報や接続設定を中心に構成できる | API接続から変換、格納まで実装が必要 |
| 同期 | 増分同期を利用しやすい | 差分検出や削除反映を自前で設計 |
| メタデータ | コネクターによる抽出を利用できる | 取得項目と変換ルールを設計 |
| 柔軟性 | 用意された取り込み方式の範囲で利用 | 独自項目や複雑な業務ルールに対応しやすい |
| 運用負荷 | パイプラインの保守を削減しやすい | 監視、リトライ、障害対応が必要 |
| コスト | マネージドサービスの利用料金が発生 | 開発・運用人件費と各種基盤費用が発生 |
| 権限設計 | 接続元の認証と検索側の制御を分けて設計 | 権限情報の取得・反映まで細かく実装可能 |
重要なのは、ネイティブコネクターが自作処理をすべて不要にするわけではない点です。業務固有の文書変換、複数システムの統合、独自の公開範囲判定、監査ログの要件がある場合は、追加の処理が必要になる可能性があります。
同期頻度は「リアルタイム」とは分けて考える
増分同期に対応することで、全データを毎回取り込むより効率的に更新を反映できます。ただし、増分同期はリアルタイム連携と同義ではありません。実際の反映タイミングは、同期ジョブの実行方式や設定、データ量などに左右されます。
サポートボットで利用する場合、次のような情報を整理しておくと設計しやすくなります。
- 何分、何時間程度の遅延まで許容できるか
- 記事の公開前後にどのような承認プロセスがあるか
- 更新直後の内容をすぐに回答へ反映する必要があるか
- 削除済み記事や非公開記事を検索対象から除外できるか
- 同期失敗をどのように検知し、再実行するか
価格情報やキャンペーン内容、障害対応手順など、古い情報が直接的な損害につながる領域では、同期状態を監視し、回答に記事の更新日時を表示する設計も有効です。
メタデータと権限管理が検索品質を左右する
RAGでは、本文の内容だけでなく、カテゴリ、製品名、対象顧客、更新日時、公開状態といったメタデータが検索精度に影響します。例えば、同じ「ログインできない」という問い合わせでも、対象製品や契約プランが異なれば参照すべき記事は変わります。
SalesforceやZendeskのデータを取り込む際は、次のようなメタデータをどのように検索や回答制御へ利用するかがポイントになります。
- 記事のタイトルと識別子
- 製品、カテゴリ、タグ
- 作成日時と更新日時
- 公開状態や対象ユーザー
- Salesforceの組織情報やZendeskのコミュニティ情報
- 元記事への参照先
また、接続元で閲覧できることと、AI利用者が閲覧してよいことは同じではありません。例えば、社内営業向けのSalesforce記事を顧客向けボットにそのまま公開すると、価格条件や内部手順が漏えいする可能性があります。
そのため、設計時には次の点を明確にします。
- SalesforceやZendeskに接続する認証情報の権限範囲
- ナレッジベースへ取り込む対象と除外対象
- 利用者やアプリケーションごとの検索範囲
- 文書単位・メタデータ単位のアクセス制御
- 生成回答に含めてよい機密情報の範囲
- 監査ログ、暗号化、認証情報の保管方法
ネイティブコネクターの導入後も、RAGアプリケーション側の認可を別途設計する必要があります。特に顧客向けと社内向けで同じナレッジベースを共有する場合は、用途ごとにデータを分離する方が安全なケースもあります。
サポートボットと営業支援アシスタントの使い分け
Zendeskを使ったサポートボット
Zendeskの記事やコミュニティ投稿を取り込めば、FAQやトラブルシューティングを根拠とする顧客向けアシスタントを構築しやすくなります。人間のオペレーター向けには、問い合わせ内容に関連する記事候補を提示する用途も考えられます。
ただし、コミュニティ投稿には誤情報や古い回避策が含まれる可能性があります。公式記事とユーザー投稿を同じ重みで扱わず、文書種別や承認状態をメタデータとして検索・回答に反映する設計が重要です。
Salesforceを使った営業支援アシスタント
Salesforceのナレッジ記事を利用すると、営業担当者が商談準備中に製品仕様、導入事例、社内FAQなどを検索するアシスタントを構築できます。担当者が自然文で質問し、関連する社内ナレッジを提示することで、情報検索の時間を短縮できます。
一方、営業情報や契約条件は機密性が高いため、顧客向けチャットへ直接接続する場合は注意が必要です。まずは社内利用に限定し、回答に参照元を示す構成から始める方が、評価と権限設計を進めやすいでしょう。
コストと運用負荷をどう評価するか
ネイティブコネクターの価値は、単純な利用料金だけで判断できません。比較すべきなのは、マネージドサービスの費用と、自作連携を維持するための開発・運用コストの合計です。
評価時には、次の費用を分けて見積もります。
- データ同期やナレッジベース利用に関するAWSの費用
- 埋め込み生成や検索、推論に関する費用
- SalesforceやZendesk側の契約・API利用条件に関する費用
- 自作する場合の開発、監視、障害対応の人件費
- 大量データの初回取り込みと継続的な増分同期の費用
- 評価環境と本番環境を分けるための基盤費用
記事数が少なく、頻繁な更新もない場合は自作処理でも成立するかもしれません。一方、複数の業務システムを継続的に同期し、担当チームがRAG基盤の保守に時間を割けない場合は、ネイティブコネクターの導入効果が大きくなります。
導入時の現実的な進め方
いきなり全社のナレッジを取り込むのではなく、用途を限定した小さな検証から始めるのが現実的です。
- サポートボットまたは営業支援など、対象ユースケースを一つに絞る
- 公式記事など品質が明確な文書だけで検索精度を評価する
- 更新反映までの時間と同期失敗時の運用を確認する
- メタデータによる絞り込みと、利用者ごとの権限を検証する
- 参照元を提示できる回答形式で、誤回答と根拠の妥当性を評価する
- 効果と運用コストを確認したうえで対象データを拡張する
評価では、単に「回答できたか」だけでなく、正しい記事を検索できたか、古い記事を参照していないか、権限外の情報を出していないかを確認する必要があります。
まとめ
SalesforceとZendeskのネイティブコネクター対応により、業務ナレッジをAmazon Bedrock Managed Knowledge Baseへ取り込む際のデータ連携実装を簡素化しやすくなりました。特に、増分同期やメタデータ抽出を含む処理をマネージドサービスへ寄せられる点は、RAGアプリケーションの立ち上げにおける大きな利点です。
一方で、同期頻度、検索品質、記事の公開状態、利用者ごとの権限、機密情報の扱いは、コネクターを設定するだけで解決する問題ではありません。ネイティブコネクターは、データ取得の負担を減らすための基盤です。その上で、どの情報を誰に、どのタイミングで、どの根拠とともに提示するかを設計することが、実運用できるAIエージェントを構築する鍵になります。
出典: AWS What’s New
