SharePoint、Azure、または社内ドキュメントに信頼できる情報源がある場合に音声AIのナレッジベースを最新に保つ方法
扱えます。しかもCopilot Studioにこれをやらせようとするのをやめれば、アーキテクチャはシンプルです。SharePoint、OneDrive、またはAzure Blobから正式なドキュメントをエージェントが所有するベクトルインデックスにミラーリングし、Microsoft GraphのwebhookとEvent Gridの通知で増分更新を駆動します。ソース側の編集は数分以内にエージェントへ反映されます。再アップロードは不要です。
多くのチームは、明白な方法を試した後にこの問題にぶつかります。Copilot StudioのSharePointコネクタは、ファイルが変更されても依然として自動更新されず、これは2025年7月にMicrosoftが確認した制限であり、執筆時点で修正されていません。Azure AI Searchはインデクサー経由でSharePointに到達できますが、インデクサーは条件付きアクセスの背後には配置できず、プレビュー段階では基本的なACLサポートしかなく、エージェント層は自分で構築する必要があります。本ガイドで説明するパターンは、音声層としてRetell AIを使用します。そのナレッジベースAPIが自前の同期ワーカーからの認証済みプッシュを受け付けるため、Microsoftの純正パスが課すあらゆる制限を回避できるからです。
プライベートコーパスの厳選されたミラーから回答する音声エージェントで、編集は5〜15分でエンドツーエンドに伝播し、イベントストリームが取りこぼしたものを捕捉する日次の照合パスを備えます。
完成すると、あなたのスタックは次のことを行います。
始める前に、次のものが必要です。
Sites.Selectedが望ましく、Sites.Read.Allはより広いフォールバック）それらのツールが別の仕事のために設計されたからです。Copilot Studioは、画面を読む人間向けにコンテンツを要約するために作られたもので、発話回答を組み立てるのに1秒未満しかない音声エージェントに供給するためではありません。Azure AI SearchのSharePointインデクサーはエンタープライズ検索向けに作られており、そこでは4〜6時間の更新ウィンドウで問題ありません。どちらの製品も、午前9時に編集された請求ポリシーが午前9時8分に発信者が聞く回答である必要があるという前提を中心に設計されていません。
3つの制約が音声をテキストから分けます。1つ目はレイテンシ予算です。検索呼び出しはライブの会話中に100ミリ秒未満で返す必要があるため、インデックスはエージェントと同じネットワーク上になければならず、チャンクはLLMのコンテキストウィンドウを吹き飛ばさずにインラインで埋め込めるほど小さくなければなりません。2つ目は障害許容度です。チャットボットが誤ったリンクを返せば、ユーザーはもう一度クリックします。音声エージェントが録音されたコンプライアンス通話で廃止されたポリシーを引用すれば、監査ログが付随した問題を抱えることになります。3つ目は鮮度への期待です。営業チームは火曜日に価格を調整します。サポートチームは金曜のインシデントレビュー後にポリシー更新をリリースします。先週の数値を引用するエージェントは、エージェントがまったくないよりも悪いのです。
だからこそ、このアーキテクチャは信頼できる情報源を検索層から分離します。SharePointは正本のまま保たれます。ベクトルインデックスは、同期パイプラインが最新に保つ派生物です。障害モードはサイレントではなく観測可能になります。
配線が最も簡単な場所ではなく、ドキュメントが作成される場所で選びます。各ソースは、コンテンツがどのように保守されるかについて異なることを示します。
SharePointドキュメントライブラリは、所有権が共同的でコンテンツが委員会レビューを通じて進化する場合に、適切なプライマリソースです。サービスカタログ、ポリシーマニュアル、社内wiki、営業プレイブックはここに存在する傾向があり、バージョン履歴、コメント、承認フローが付随します。その代償はメタデータの散乱です。典型的なサイトには、同じポリシーの4つのバージョン、2つの廃止されたドラフト、そして誰かのスクリーンショットフォルダが含まれます。
OneDriveが音声エージェントの適切なプライマリソースであることはめったにありません。一人のアカウントに紐付いたコンテンツは、その人が去るときに一緒に出て行ってしまいます。OneDriveは、個々の担当者がドラフトを作成し、レビュー後にSharePointライブラリへ昇格させるステージング領域としてのみ使用してください。
Azure Blobコンテナは、ドキュメントが上流システムによって生成される場合に適切なソースです。請求パイプラインから生成されたPDF、CLMツールが投入する契約書、エクスポートジョブからの明細書、録音システムからのトランスクリプトはすべてBlobに属します。ボリュームはより高く、鮮度を偽るのはより困難で、ファイル命名は生成システムが強制する規約に従うため、SharePointの自由形式の構造よりもミラーリングと同期がシンプルになります。
ほとんどのエンタープライズチームは両方を同期します。SharePointがポリシーと製品側を供給し、Blobが運用側と機械生成側を供給し、音声エージェントのナレッジベースが単一の検索APIの背後で両方をマージします。
Microsoft Entra IDにアプリケーションを登録し、アプリケーション権限をリクエストし、テナント管理者に同意を付与してもらいます。
アプリケーション権限はサービスプリンシパルの下で動作します。ワーカーはログインしたユーザーなしで夜通し動き続け、トークンは呼び出し間で一貫しています。一方、委任された権限はアクセスを実際のユーザーアカウントに紐付け、Microsoftが現在使用しているセキュリティライブラリに従っておよそ75分ごとに再認証を強制します。委任された権限は、Microsoft自身のSharePointインデクサーのドキュメントが記すとおり、ドキュメントレベルのACLを保持することもできず、これはコンプライアンスが誰が何を聞けるかを尋ねた瞬間に問題になります。
スコープは、ほとんどのチームが過剰共有する場所です。Sites.Read.Allを付与すると、アプリはテナント内のすべてのサイトを読み取れます。セットアップは速いですが、監査では擁護できません。より厳格な代替案はSites.Selectedで、テナント管理者が特定のサイトIDのみに対してアプリを事前承認します。ワーカーはエージェントが必要とするライブラリだけを見て、それ以外は見えません。初日からSites.Selectedを使用してください。後からサイトレベルのスコープを埋め戻すには再同意が必要で、たいていは予算に入れていなかったセキュリティレビューが必要になります。
Azure Blobの場合、同じサービスプリンシパルに特定のコンテナ上のStorage Blob Data Readerロールを割り当てます。コンテナレベルのスコープは、同じ理由でアカウントレベルのスコープに勝ります。
2つのMicrosoft Graphプリミティブを組み合わせます。webhookは何かが起きたことを教えてくれます。デルタクエリは何が変わったかを正確に教えてくれます。
webhookサブスクリプションは、ドライブを指すリソースパス（例えば/sites/{site-id}/drive/root）、updatedのchangeType、そしてワーカーのHTTPSエンドポイントに向けたnotificationUrlを持つ/subscriptionsへのPOSTです。通知本文は意図的に薄くなっています。リソースIDと変更タイプを運ぶだけで、それ以上はありません。これは設計によるものです。ワーカーは通知を、実際のペイロードが存在するデルタエンドポイントを呼び出すためのシグナルとして使用します。
デルタクエリは/sites/{site-id}/drive/root/deltaです。初回実行時、トークンなしで、完全な列挙と不透明な@odata.deltaLinkが得られます。そのリンクをそのまま永続化してください。それ以降のすべての実行で、それを再生するとGraphは前回の呼び出し以降に追加、変更、名前変更、削除された項目のみを返します。Microsoftのスキャンガイダンスは明確です。webhookとデルタの組み合わせが大規模ライブラリの推奨パターンです。純粋なポーリングではスロットルされ、純粋なwebhookではエンドポイントが遅い場合にデータを失うからです。
知っておく価値のある2つの経験則があります。同じ項目がデルタページに複数回現れることがあります。これは設計によるもので、Graphがフォルダ階層を展開し、同時変更をマージするからです。重複が現れたら、最後の出現を取ります。サブスクリプションも期限切れになります。締め切りではなく、最大ライフタイムの75%で更新してください。サイレントに失敗する更新ジョブは、以前動いていた同期が古いコンテンツへドリフトし始める最も一般的な理由であり、顧客が苦情を言ったときに気づくことになります。
リアルタイム通知にはEvent Grid、バッチ照合には変更フィードを使用します。これらは異なる問題を解決し、本番での答えは両方を実行することです。
Event Gridは、blobが作成、置換、削除された瞬間にイベントをプッシュします。ストレージアカウントでサブスクライブし、Microsoft.Storage.BlobCreatedとMicrosoft.Storage.BlobDeletedのeventTypeでフィルタし、ワーカーへルーティングします。Azure Data Lake Storage Gen2の場合、FlushWithCloseAPI呼び出しのフィルタを追加します。これにより、blobが完全にコミットされた後にのみイベントが発火することが保証されます。これをスキップすると部分的なアップロードを処理することになり、ファイル破損のように見えるが実はそうではない取り込みエラーが生じます。
変更フィードは、イベントの背後にある順序付けされた耐久性のあるログです。Microsoftのドキュメントによれば、$blobchangefeed/log/にAvroファイルとして永続化される保証されたトランザクションログを提供し、各変更から数分以内に書き込まれます。Event Gridはベストエフォートで、負荷下では通知を落とすことがあります。変更フィードは落としません。変更フィードを辿ってナレッジベースのマニフェストと照合する日次ジョブを実行すれば、リアルタイムパスの下にセーフティネットができます。
この組み合わせが重要です。Event Grid単独は速いですが取りこぼしがあります。変更フィード単独は信頼できますが遅いです。両者を合わせると、ハッピーパスで分単位の鮮度が得られ、アンハッピーパスでも朝までに完全な一貫性が得られます。
ワーカーがファイルをダウンロードし、正規化し、プラットフォームAPIへプッシュします。3つの操作、作成、更新、削除です。名前変更は削除プラス作成に折りたたまれます。
Retell AIのナレッジベースは、PDF、DOCX、PPTX、XLSX、CSV、TSV、TXT、MD、HTML、RTF、ODT、EPUBを含む長いリストのドキュメント形式に加え、メッセージ形式といくつかの画像タイプを受け付けます。知っておく価値のある制約は、ファイルあたり50MB、ベースあたり25ファイル、スプレッドシートで1,000行×50列です。ソース形式を制御できる場合はMarkdownが最もクリーンに取り込まれ、そのためチームはしばしば、作成されたWordドキュメントをプッシュ前にMarkdownへ変換する正規化ステップを実行します。
ファイル数が25を超えて増えたら、部門ではなくドメインでベースを分割します。「billing-policies-en」、「service-catalog-2026」、「exception-cases」にリンクされた請求エージェントは、検索類似度がベースごとではなくチャンクごとに計算されるため、3つすべてを横断してクリーンに検索します。一方、部門で分割すると誤った境界が作られます。同じ発信者の質問がしばしば2つの部門にまたがり、エージェントはそのうち一方からしか検索しないことになります。
運用側では、同じ通知が2回届いたときにあなたを救うのは冪等性です。各ファイルのコンテンツをハッシュ化し、そのハッシュをドキュメント識別子として使用します。変更されていないファイルの重複通知は、重複したインデックスエントリではなくノーオペを生成します。
純粋なテキスト抽出器は、実際のPowerPointや財務ワークブックの意味の30〜40パーセントをサイレントに失います。そしてエージェントは、生き残った60パーセントを自信満々に引用します。それが由来するテーブルなしでは意味をなさなくなった部分も含めて。
PowerPointは、スライドレイアウト、テーブルセル、画像ベースのコールアウト、発表者ノートに情報をエンコードします。Excelは、結合セルにまたがる列ヘッダー、他のタブを参照する数式、タブ順序に意味をエンコードします。素朴なテキスト抽出は、構造が剥ぎ取られた単語の平坦な文字列を返します。本番では2つのパスが生き残ります。
1つ目はレイアウト認識パースです。Unstructured、Azure Document Intelligence、LlamaParseのようなツールは、テーブルセルとスライド構造をMarkdownとして保持します。ドキュメントあたりのコストが安く、出力が予測可能です。欠点は、テーブルはうまく扱うがチャートは苦手なことです。
2つ目は、2025年半ば以降に注目を集めている画像ベース抽出です。各スライドまたはシートを画像にレンダリングし、Markdownを返す視覚対応LLMに通します。出力は、テキスト抽出器が見逃すテーブル、チャート、視覚的コールアウトを復元します。コストはドキュメントあたり高く、遅いため、これは実際に重要なドキュメントに適したパスであり、SharePointサイト内のすべてを一括取り込みするには不適なパスです。
持ちこたえる判断ルールは、ポリシードキュメントを安価なレイアウト認識パスにルーティングし、少数の高価値な視覚的ドキュメント（ワンページャー、経営陣が参照するスライドデッキ、営業チームが実際に使うレートカード）を画像ベースパスにルーティングすることです。すべてに1つのアプローチを使おうとしないでください。
512トークンで10〜20パーセントのオーバーラップの再帰的文字分割、デフォルト類似度で取得するチャンク3つ。そこから自分の通話データに基づいてチューニングします。
これは人気のある答えではありません。人気のある答えはセマンティックチャンキングで、より賢く聞こえますがベンチマークでは劣ります。2026年初頭に公開されたVectaベンチマークは、同じ50ドキュメントコーパスで、再帰的512トークン分割を検索精度69パーセント、セマンティックチャンキングを54パーセントとしました。NVIDIAの研究も同じ場所に着地します。ファクトイドクエリ（音声エージェントが受け取る種類）は256〜512トークンで最もパフォーマンスが良く、境界をまたいで文の文脈を保持するために10〜20パーセントのオーバーラップを使います。
同期における実用的な含意として、チャンクサイズや埋め込みモデルを変更すると、ベース内の既存のすべてのチャンクが無効になります。チューニングパス後に検索が突然パフォーマンスを落としたら、増分的にパッチを当てないでください。ベースをドロップし、ソースを再取り込みし、数時間の再処理コストを受け入れます。将来のすべての回答で得られる明瞭さは、やり直しに値します。
検索しきい値のチューニングは、通話データを得てから行うもので、その前ではありません。通話後分析から50〜100件の通話を引き出し、誤チャンクの失敗にタグを付け、問題のあるソースのチャンキングか類似度しきい値のいずれかを調整します。ほとんどのチームは最初に過剰チューニングします。デフォルト設定はユースケースの80パーセントで正しいのです。
ユニークでテスト可能なフレーズを使って、編集から発話回答まで追跡するクローズドループテストを構築します。これはパイプライン全体で最も有用な5分間のチェックです。
ドキュメントを1つ選び、その中のユニークな数値を編集します。「Premium tier discount: 12.5%」を「Premium tier discount: 14.0%」に変えます。SharePointで保存します。5〜15分以内（Graph通知、デルタ処理、埋め込み）に、変更がインデックスでライブになるはずです。その質問を尋ねるテスト通話を行います。エージェントが14.0%と言えば、ループは機能しています。
機能しないとき、障害はクリーンに切り分けられます。ワーカーはwebhookを受け取ったか？エンドポイントのログを確認します。デルタクエリはファイルを返したか？ワーカーのログを確認します。アップロードは成功したか？APIレスポンスを確認します。チャンクは検索に入ったか？通話後分析で通話の検索ログを確認します。各層はyes/noの質問に答え、10分未満で壊れた層を見つけます。
意味のあるパイプライン変更のたびにこのループを実行します。新しいチャンキング戦略、新しい埋め込みモデル、新しいソース、新しい同期ワーカーバージョン。ループが閉じれば、変更は安全にリリースできます。閉じなければ、バグの正確な再現があります。
3つの層を、この順序で適用します。ソースで刈り込む。プロンプトで制約する。通話で観測する。
ソースでの刈り込みは、ほとんどのチームがスキップして後で代償を払う層です。ポリシーが廃止されたら、ファイルを同期フォルダから移動します。最もクリーンなパターンは、同じSharePointライブラリ内のsynced/とarchive/のディレクトリ分割で、ワーカーはsynced/のみを監視します。同じポリシーの2つのインデックス化バージョンは自信満々な矛盾のレシピであり、競合するソースドキュメントからデバッグで抜け出すことはできません。
プロンプトでの制約が層2です。取得されたナレッジベースコンテキストからのみ回答し、利用可能なものがないときはエスカレートするようエージェントに指示します。公開ベンチマークは、グラウンド化されたRAGが非グラウンド化LLMに対してハルシネーション率を26〜43パーセント削減することを示しています。その向上は、検索が正しいドキュメントを浮上させたときにのみ保たれます。「回答が見つかりませんでした、おつなぎします」という応答は、自信満々な誤答よりもほぼ常に優れており、低類似度検索でトリガーされるエスカレーションルールは、エージェント内で最もレバレッジの高い設定の1つです。
通話での観測が層3であり、ループが閉じる場所です。すべてのミスにカテゴリでタグを付けます。ソース欠落、誤ったチャンクの取得、古いコンテンツ、モデルの誤解釈。各カテゴリには異なる修正があります。欠落したソースは次の取り込みパスに入ります。誤ったチャンクは通常、2つのドキュメントが似た話題を異なる語彙で論じていることを意味し、メタデータタグやソースの分割で修正します。古いコンテンツは、日次照合が捕捉すべきだったのに捕捉しなかったwebhookのギャップまで遡り、これはあなたの照合ジョブのバグです。
1回3分の通話を月5,000件扱うチームにとって、ナレッジベースの使用料は桁違いに最も小さい項目です。
Retell AIは基本通話コストとして1分あたり$0.07を課金し、ナレッジベースの使用料はその上に1分あたり$0.005です。各ワークスペースには無料ナレッジベースが10個含まれます。追加ベースは月$8です。月間15,000分の通話時間の場合、ナレッジベースの使用料は$75を追加します。基本通話コストは$1,050です。エージェントが相殺しているSDRまたはフロントデスクの給与と両方を比較すれば、計算は明白になります。料金は、ベースを1つ使おうと7つ使おうと一貫しており、その上にプラットフォーム料金はありません。
隠れたコストはMicrosoft側にあり、通常は小さいですが誤設定しやすいものです。Microsoft Graphは呼び出しごとに課金します。Azure Event Gridは100万操作ごとに課金します。どちらも典型的な同期ボリュームでは数セントです。これを本物の請求に変える方法は、webhookをサブスクライブする代わりに30秒ごとにSharePointをポーリングすることです。そのようなバグは、私が見た少なくとも1つのチームでAzure消費料金を50倍に急上昇させました。webhookとデルタは、ソースがどれだけ頻繁に変わっても請求をフラットに保ちます。
これらはデプロイ全体で十分な頻度で再発するため、チェックリストに値します。
webhookサブスクリプションの期限切れ。サブスクリプションは自分で更新しません。有効期限をアラートに追加し、最大ライフタイムの75パーセントで更新します。サイレントな期限切れは最も一般的なドリフト原因です。
削除処理。ほとんどのチームは作成・更新されたファイルを扱う同期をリリースし、削除されたものを忘れます。するとエージェントは3か月前に廃止されたポリシーを引用します。deleted変更タイプをエッジケースではなくファーストクラスのケースとして配線してください。
テナント全体の読み取りスコープ。セットアップ時にSites.Read.Allを付与するのは速いです。6か月後、監査人が音声サービスプリンシパルがどのサイトを見られるか尋ねたとき、「すべて」は誤った答えです。最初からSites.Selectedを使用してください。
50MB上限を超えるドキュメント。長いマニュアルは、ファイルあたりの制限を超えるとサイレントにアップロードに失敗します。過大なドキュメントを論理的な境界（章、セクション、製品ライン）で分割して前処理し、各部分を独自のドキュメントとしてアップロードします。必要に応じて検索が再結合できるよう、親子メタデータを保持します。
ステージングと本番のナレッジベース間のドリフト。チームはステージングベースに対して同期パイプラインを構築し、エージェント設定を本番にコピーし、本番エージェントがまだ前四半期の手動アップロードされたファイルを指していることを忘れます。デプロイ設定でナレッジベースIDを明示し、リリースのたびに検証してください。
はい。アーキテクチャは、Microsoft Entra ID経由のサービスプリンシパル認証、認証済みGraphチャネル越しに取得されたファイル、そしてHTTPS越しにナレッジベースAPIへプッシュされるアップロードです。ソースドキュメントは既存のACLとともにSharePointに留まります。ナレッジベースは通話中の検索にのみ使用されるインデックス化コピーを保持し、コンプライアンスが要求すればサービスプリンシパルを単一のサイトにスコープできます。
ハッピーパスでエンドツーエンド5〜15分です。内訳は、Graph webhook配信が数分以内、デルタクエリとダウンロードが1分未満、パースと埋め込みがドキュメントサイズによって1〜3分です。インデックス化されると、通話自体の間に検索が100ミリ秒未満を追加するため、発信者は間を感じません。
日次照合ジョブがデルタクエリを再生し、結果をナレッジベースのマニフェストと比較して、Event GridまたはGraphが見逃したものを捕捉します。リアルタイムwebhookと日次デルタスイープの組み合わせが標準パターンであり、これは通知がベストエフォートであるまさにその理由からMicrosoft自身のエンジニアリング記事で推奨されています。
はい。同じワーカーパターンは、Google Drive（Drive Activity API経由）、Amazon S3（S3 Event Notifications経由）、Confluence、Notion、そして変更イベントを発行するあらゆるソースに適用されます。ナレッジベースAPIはソース非依存です。変わるのは認証とイベントリスニングのコードだけです。
Copilot StudioのSharePointコネクタは、ファイルが変更されても自動更新せず、これは2025年半ばにMicrosoftが確認した制限であり、執筆時点で修正がリリースされていません。回避策には、手動更新をトリガーするPower Automateフローが含まれます。同期問題を超えて、Copilot Studioはチャット面向けに作られており、1秒未満の音声レイテンシを生み出しません。電話エージェントには、本ガイドのアーキテクチャが道です。
Retell AIは、SOC 2 Type II、セルフサービスBAA付きHIPAA、GDPRに加え、設定可能なデータ保持とPIIレダクションを備えています。ヘルスケアワークロードの場合、標準パターンはPHIがインデックスに触れる前にBAAをゲートすることです。特定の規制体制に対するコンプライアンス姿勢の検証はあなたの責任です。インフラレベルの認証はプラットフォームをカバーしますが、あなたのコンテンツ分類ポリシーはカバーしません。
はい。エージェントは複数のナレッジベースをリンクでき、各ベースは異なるソースパイプラインから引き出せます。一般的なパターンは、論理ドメイン（請求、サポート、製品仕様）ごとに1つのベースで、ソースをクリーンに分離することです。会話フローノードは、営業とサポートのパスが異なるコンテキストを必要とするとき、特定のノードに異なるベースをバインドすることもできます。
同期層にOAuthとwebhookに慣れたエンジニア1人、エージェント構築とプロンプトチューニングにオペレーションオーナー1人、そして同期フォルダに何が属するかを決めるコンテンツオーナーです。実践で機能する分担は、ITがワーカーと認証を所有し、オペレーションがエージェントを所有し、コンテンツチームがスコープ内のものを所有することです。このアーキテクチャは概念実証のための一人体制をサポートし、再アーキテクチャなしでスケールします。
Azure AI SearchのSharePointインデクサーは取り込みをうまく扱いますが、知っておく価値のあるハードな制限があります。条件付きアクセスが有効なテナントをサポートしません。ACL保持はGAではなくパブリックプレビューです。更新レイテンシは分単位ではなく時間単位で動きます。そしてその上に音声エージェント層を構築する必要が依然としてあります。純粋なエンタープライズ検索には、AI Searchで問題ありません。音声には、Retell AIへ同期するパターンのほうが運用的にシンプルで、デプロイが速いです。
10〜20パーセントのオーバーラップの再帰的512トークン分割です。これは2026年の評価全体でベンチマーク検証されたデフォルトであり、実際のドキュメントコーパスでセマンティックチャンキングを約15ポイント上回ります。デフォルト類似度で取得するチャンク3つ。変更を裏付ける50〜100件の実際の通話トランスクリプトを得てからのみチューニングしてください。
同期パイプラインは音声AIの地味な半分であり、デプロイがリリースされるか停滞するかを決める半分でもあります。「デモデータでは動く」がポリシーが変わった瞬間に倒れるパイロットは、この領域における典型的な障害モードであり、上記のアーキテクチャがその修正です。
ナレッジベースが堅固になれば、同じエージェントは同じデータ上で隣接するワークフローへ拡張します。インバウンドの質問向けのAIカスタマーサポート、アウトバウンド向けのリード選別、そのいずれにもルーティングする受付。1つのために厳選したコーパスが、それらすべての信頼できる情報源になります。
retellai.comで$10のクレジットで無料で始めましょう。
AI搭載の音声エージェントに切り替えることで、あなたのビジネスがどれだけ節約できるかをご確認ください。
Total Human Agent Cost
AI Agent Cost
Estimated Savings
Retell クリニックオフィスのデモ電話番号
Start building smarter conversations today.
.avif)
.avif)
