AWSとSalesforceのゼロコピー統合を権限設計で読む

業務データをAIに利用させる方法のひとつに、別の環境へデータをコピーして使う設計があります。

検索や応答を速くするための工夫です。

ただしコピーが増えるほど、元のシステムで決めていた閲覧・更新のルールを、コピー先でも同じように保てているかを確かめる手間が増えます。

AWSとSalesforceが2026年9月15日に発表した提携拡大には、このコピーを減らす方向の機能拡張が含まれています。

本稿では、そのうちデータの置き方と権限に関わる部分を取り上げ、導入を検討するときに何を確認するとよいかを整理します。

何が発表されたのか

中心になるのは、Salesforce Data 360の「ゼロコピー」の対象が広がったことです。

Data 360は、社内外のデータを組み合わせて業務やAIで活用するためのデータ基盤です。

今回、ゼロコピーの対象として、AWS Glueが管理するApache Icebergテーブル、S3上のApache Icebergテーブル、Amazon Aurora、Amazon RDS、SageMaker Lakehouseが加わったと説明されています（Amazon RedshiftとAmazon S3は従来から対象とされています）。

以降は、これらをまとめて「AWS側のデータベースや保存サービス」と呼びます。

あわせて、Amazon QuickとSalesforceをつなぐ連携も発表されています。

Amazon QuickはAWSの業務向けAIアシスタントで、この連携により、SalesforceのCRM（顧客情報や商談、問い合わせを管理するシステム）の情報を、Quickから調べたり更新したりできるようになるとされています。

接続には、AIアプリが外部のデータや機能を利用するための共通規格であるMCP（Model Context Protocol）が使われています。

このほか、AWSのAIエージェントをSlackの中から使えるようにする連携も含まれていますが、本稿では扱いません。

ゼロコピーで減るもの、残るもの

Salesforceのゼロコピー連携は、外部にあるデータを、あらかじめData 360へ複製せずに参照・利用するための仕組みです。

一方で、処理を速くするために外部データを一時保存する「キャッシュ」を使う構成も用意されています。

そのため、ゼロコピーという名称だけを根拠に、利用側にデータが一切残らないと判断することはできません。

独立した複製先を減らせれば、その保存先で行っていた同期や権限管理の負担を減らせる可能性があります。

私たちはその利点を評価したうえで、接続時のアクセス制御と、取得したデータの管理を別途確認することを重視しています。

導入するときは、採用する方式で何がどこに保存され、どの条件で更新・削除されるかを確認することになります。

コピーしたデータでもアクセス制御を維持する

そもそもなぜ、コピーが権限管理の論点になるのでしょうか。

例えば、担当営業とその上長だけに閲覧を認めている顧客情報を、同じ内容のまま別のデータベースへコピーしたとします。

そこでも同じ閲覧制限が必要なのに、部門全員が見られる設定になっていれば、意図したアクセス制御が維持されていません。

この例で問題なのは、コピーしたデータに必要なアクセス制御が適用されていないことです。

コピー先でも同じ制限を設定し、権限の変更も反映される仕組みがあれば、コピーがあること自体が問題になるわけではありません。

元データを直接参照する構成でも、接続に作業で必要な範囲を超えた権限を与えれば、意図しない範囲にアクセスできてしまいます。

データの更新が反映されるかどうかとは別に、権限変更の反映も確認が必要です。

元のシステムでアクセス権を取り消しても、コピー先で別途付与した権限がそのまま有効であれば、そちらではアクセス権が残った状態になります。

保存先が増えるほど、こうした確認箇所も増えていきます。

接続ごとに、誰が何をできるかを確かめる

データを利用するときは、誰がアクセスしているかを確かめることと、その人やシステムに何を許可するかを判断することの両方が必要です。

前者を認証、後者を認可と呼びます。

OWASPのAuthorization Cheat Sheetも両者を区別し、認証された利用者が、システム上で技術的に可能なすべての情報や操作へのアクセスを許されるわけではない、と説明しています。

この区別を踏まえると、今回の発表に含まれる二つの連携は、それぞれ別に確認する対象だと分かります。

Amazon Quickとの連携については、製品説明が公開されています。

Salesforceのアプリ配布サイトに掲載されたAmazon Quickの製品説明では、すべての操作が利用者本人のSalesforce権限と共有ルールのもとで実行されること、そして書き込み操作は実行前に利用者の確認と承認を求めることが説明されています。

一方、Data 360とAWS側のデータベースや保存サービスをつなぐ連携では、認証方法とアクセス制御は接続先と接続方式に応じて設定するもので、各コネクタの設定手順で確認することになります。

QuickからSalesforceを利用する連携と、Data 360からAWS側のデータを利用する連携では、接続の仕組みが異なるため、それぞれの仕様と設定を確認します。

その際、アカウントの種類だけで安全性を判断しないほうがよいと私たちは考えています。

利用者本人のアカウントで動く場合でも、その人が持つすべての権限が、その作業に必要とは限りません。

システム用のアカウントを使う場合でも、利用できる対象を限定して運用することはできます。

確かめたいのは、どのアカウントで処理が実行され、どの操作を許可し、その制限をどこで適用しているかです。

導入前に確認したい5項目

以下はMIFが提案する確認項目です。

自社の業務、扱うデータ、適用されるルールに合わせて具体化してください。

確認項目	具体的に確認すること
誰の権限でアクセスするか	利用者本人のアカウントか、システム用のアカウントか。どの情報・操作を許可するかは、どこで確認されるか
何を許可し、いつ承認するか	読むだけか、作成・更新も許すか。承認が必要な操作と、その承認者を設定できるか
誰が何をしたかを追えるか	いつ、誰の依頼で、どの処理が、何にアクセス・変更したか。承認と実行結果を結び付けて確認できるか
権限変更と保存データをどう扱うか	権限の取り消しがいつ反映されるか。取得結果やキャッシュはどこに残り、いつ更新・削除されるか
問題が起きたときにどう止めるか	利用者・エージェント・接続先ごとに停止できるか。誰が停止・再開を判断するか

四つ目を入れているのは、ゼロコピーであっても方式によっては一時的な保持が生じうるためです。

元データへの以降のアクセスを止めることと、すでに保存されている取得結果やキャッシュをどう扱うかは、分けて整理する必要があります。

公開されている仕様を読むだけでなく、権限の異なる利用者でのアクセス、権限変更後の動作、操作記録の追跡を、実際の環境で試して確かめることをお勧めします。

まとめ——データの置き方と、利用条件をあわせて決める

ゼロコピーは、データを利用するための複製や同期を減らす選択肢です。

採用するときは、取得したデータの保存先や、閲覧・更新を許可する範囲もあわせて確認します。

私たちが重視しているのは、製品の機能や精度を比べる段階から、AIに見せる情報、許可する操作、人の承認が必要な場面まで具体化することです。

連携ごとの公開仕様を確認し、自社の設定へ反映する。

そのうえで、権限変更後の動作、操作記録、問題が起きたときの停止方法を確かめる。

本稿の5項目を、そのための出発点として使ってください。

情報確認について

本記事は2026年9月22日に確認した次の資料をもとに作成しています。

Amazon公式プレスセンターが2026年9月15日に公開した発表記事「AWS and Salesforce Put CRM Data, AI Agents, and Model Choice into the Tools Teams Use Every Day」。

Salesforceのゼロコピー連携に関する解説ページ「Why Data 360’s Zero Copy Makes Business and Technical Sense」。

Salesforceのアプリ配布サイトに掲載された「Amazon Quick」の製品説明。

OWASP Cheat Sheet Series「Authorization Cheat Sheet」。

このうち発表記事・解説ページ・製品説明は、いずれも提供各社による説明であり、第三者による検証結果ではありません。

提供状況は発表時点の記載に基づくもので、発表内には提供範囲が地域や契約条件により異なる旨の注記があります。

機能の詳細・提供時期は今後変更される可能性があります。

本稿における論点の整理と確認項目の一覧は、これらの公開資料をもとにしたMIFの分析です。