元のアプリで開けなくなった文書でも、AIアシスタントが直ちに利用できなくなるとは限らない。検索索引が昨日のグループ所属を認めたままなら、質問によってその文書がモデルのコンテキストに入る。利用者がファイルの存在を知らなくても、要約や比較から内容の一部が漏れる可能性がある。
Amazon Quickが2026年10月7日に発表した設計は、この時間差を対象とする。生成前に候補文書をソースに照会し、索引内のアクセス制御リスト（ACL）と、二度目のライブ判断を組み合わせる。文書アクセスの最終決定者を変えるのであって、すべてのBedrockナレッジベースを実時間検証にしたり、検索フィルターをユーザー認証にしたりするものではない。
検索からモデルまでに二つの関門
一般的な取り込みでは文書と権限を検索索引へコピーする。問い合わせ時は意味的な関連性と保存されたACLメタデータで返す文章を決める。効率はよいが、権限のスナップショットは最後に同期が成功した時点のものであり、ソースの現在状態とは限らない。
Quickはこの高速な第一段階を残す。関連箇所を検索し、索引のACLで絞った候補だけをソースAPIで検証する。索引上で許可されていても、ライブ確認に失敗した文書は除外される。両方を通った文章だけが言語モデルに渡る。
ここでいう実時間とは、問い合わせ処理中の選択済み文書の確認であり、資料庫全体の全権限を常時同期することではない。候補の限定が遠隔呼び出し量と遅延を抑える。ただし最初の索引が候補になる文書を左右するため、最後の確認だけで検索漏れすべてが直るわけでもない。
Google Driveの例では、管理者提供のサービスアカウント資格情報からユーザーを代理する個別アクセストークンを取得する。現在の権限を決めるのはDriveのままだ。QuickのIDとGoogle Workspaceのユーザーが正しく対応する必要があり、委任資格情報、トークン処理、管理権限が検索経路の重要な安全要素となる。
SharePointのID経路は異なる。ACL有効のナレッジベースでは、保護された情報が関連した時点でQuickがサインインを求め、委任アクセスで各候補を確認する。AWSによれば通常は一度のサインインで、関連する更新トークンは約90日続く。すべてのアクセストークンの寿命が90日という意味ではない。
委任スコープにはサイト項目・ファイルの読み取り、基本プロフィール、承認済みアクセスの維持が含まれる。一方、管理者管理の取り込みアプリにはディレクトリやグループの読み取り、選択した、またはより広範なSharePointサイトへのアクセスが別途必要になりうる。取り込み承認とユーザー委任による検証は、異なるアプリと責任である。
さらにSharePointのACL管理はナレッジベース作成時に有効化する必要があり、後から変更できない。設定を忘れた場合は別のナレッジベースが必要で、再索引、展開計画、受け入れ試験に影響する。
権限のコピーが十分とは限らない理由
企業のアクセス権は単純な一覧ではない。SharePointにはサイト、グループ、継承、例外があり、Driveには個人ファイル、共有ドライブ、直接共有、グループ、組織全体の設定がある。Confluenceはスペース、ページ制限、継承アクセスを加える。単一索引への変換には、対応付けと鮮度の両方のリスクがある。
クロール直後に機密戦略グループから外された従業員を、複製メタデータは次の同期成功まで許可し続けるかもしれない。イベント駆動更新でも、受け取れないイベントには対応できない。AWSはConfluenceの一部のグループ所属変更では利用可能なイベントが必ずしも発生しないと指摘する。新しい共有方式がコネクターの解釈を追い越す場合もある。
RAGは複数の資料庫を横断して文章を合成するため、食い違いが深刻になる。公開の進捗に、制限された予算や人事判断を混ぜられる。生成後の除去ではモデルが既に情報を受け取っている。引用、追加質問、エクスポート、エージェントの操作にも生成前の境界が要る。
ソースによるライブ判断は、索引に全権限規則を正確に再現する負担を減らす。しかし元の過剰な許可は直せない。広く共有されたフォルダーの機密ファイルは実際のポリシーを通る。最小権限、資料庫の責任者、アクセスレビュー、退職時の権限回収は依然必要だ。
アクセスできる文書が安全な内容とは限らず、アシスタントを操る悪意ある指示を含むこともある。Bedrock Guardrails、根拠確認、安全ポリシー、ツール制限は別のリスクを扱う。組織の文書権限を自動理解するものではなく、正しいACLも間接プロンプトインジェクションを消さない。
製品名だけでは確認範囲が分からない
QuickはS3、Confluence、Google Drive、OneDrive、SharePoint、認証付きウェブコンテンツとの統合を文書化し、OAuthやサービスアカウントの方式も異なる。接続できることと、すべてのコネクター・構成が同じライブ確認をすることは別だ。発表はSharePoint、Drive、Confluenceを重視する一方、詳細フローはDriveとSharePointが中心である。
管理者管理、ユーザー管理、カスタム構成は分けて判断する必要がある。対応ソース名だけでは、使用ID、ライブか索引か、エラーが検索に及ぼす影響は確定しない。
Bedrockのカスタムデータソースはこの違いを明示する。ライブ照会ではなく顧客提供のACLメタデータを利用し、アプリが文書に許可・拒否項目を添付する。検索前に適用され、拒否が許可に優先する。正確さと鮮度は顧客の取り込み処理次第であり、コネクター自身が権限を定義するなら照会できる権威あるソースAPIがない場合もある。
同文書はACL対応フィルタリングが認証境界ではないとも警告する。Bedrockは呼び出しアプリが渡すIDコンテキストを検証できない。アプリ側で先に認証し、検証済みのIDを渡す必要がある。偽装や取り違えのIDに対する正確な権限照会でも、結果は安全とは限らない。
カスタムソースの障害は安全エラーでなく知識不足にも見える。ACLフィールドの大文字小文字、リスト欠落、メールアドレス不一致で、文書が黙って除外される場合がある。AWSはこの場合、認可例外ではなくアクセスを閉じる検索動作を説明する。ただし、これを全コネクターの全障害に対する保証へ一般化してはならない。
鮮度を得る代わりに増える運用依存
AWSは、同期に数時間・数日を待つ代わりに、権限撤回を短時間で反映できるとする。これは会社の説明であり、独立測定されたサービス水準保証ではない。ソースプラットフォーム、トークン状態、API可用性、コネクター設定、ナレッジベースのモードに依存する。
APIにはレート制限、一時障害、停止があり、同意撤回やトークン失効も起こる。権限が不明なら文書を除外するのが安全な既定動作だが、正規利用者の答えは不完全になりうる。合法的な根拠を頻繁に落とすことで漏洩を防いでも、知識製品としては失敗しうる。
追加呼び出しは性能とも引き換えだ。並列確認は待ち時間を短くするが要求の集中を増やし、逐次確認は同時数を抑えるが遅くなる。成功判断のキャッシュは高速化と引き換えに再び鮮度の窓を作る。公開資料には全キャッシュ、タイムアウト、再試行、レート制限方針や、漏洩率、遅延、API負荷、停止時の比較ベンチマークは示されていない。
運用記録では、回答と、提示ID、検証結果、除外理由を結び付けたい。ただし診断で機密文書名を漏らしてはならない。内容不存在、検索失敗、アクセス拒否の区別は、事故対応にも日常サポートにも重要となる。
顧客事例も独立安全試験ではない。AWSはMondelēz Internationalが4地域の35,000人超にQuickを展開したと説明する。同社M365イノベーションのシニア専門家Jamahl Wigginsは、ライブ制御が安全・コンプライアンス審査に役立ったと述べる。需要と組織内承認の信号であって、全条件での漏洩防止や性能の測定証拠ではない。
AWSのGenerative AI Lensも、メタデータで複雑なACLを再構成すると工数や権限の隙間が生じうると警告していた。問い合わせ時の確認はその一部に対応し、カスタム実装には多くの責任が残る。個人・チームのAIナレッジベースでも、共通の画面が情報境界を消すわけではない。
判断する場所が変わっても責任は残る
代表的な展開では、ログインから回答までを通し、アクセス撤回、グループ・継承変更、明示拒否、期限切れトークン、API障害、ナレッジベース再作成を確認する必要がある。認可精度だけでなく検索の完全性、追加遅延、更新失敗、レート制限、検証による未回答も重要だ。
慎重に同期したACL、安全領域別の索引、権限対応の企業検索、追加のソース呼び出しという選択肢もある。それぞれ鮮度、運用複雑性、検索の自由度、外部依存を異なる形で交換する。問い合わせ時認可が調達の基準になる可能性はあっても、この発表は既にそうなったと証明してはいない。
Quickの貢献は具体的な設計改善である。対応し正しく設定された環境では、文章がモデルへ入る前にソースが最後の権限判断を行う。その実力はコネクターごとの保証と観測可能な障害動作次第であり、「ACL対応」を完全な安全システムと扱うことではない。
出典と関連資料
AWS発表；発表の正規アドレス；SharePoint ACL設定；Quickデータ統合；個人・チームの知識ベースに関する関連解説；BedrockカスタムソースACL；AWS Generative AI Lens。