生成AI とエンタープライズデータを安全につなぐ：CData Connect AI の5層アクセス制御モデル

by 杉本和也 | May 15, 2026

こんにちは。CData Software Japan リードエンジニアの杉本です。

AI と社内データを連携させるプロジェクトが増えるにつれ、IT管理者・情シスの方から「AIに何をどこまでさせてよいか、どう制御するか」という相談が増えてきました。

今回はCData Connect AI が提供するアクセス制御、セキュリティの仕組みを5つの層に分けて整理し、設計パターンとともにご紹介します。

https://jp.cdata.com/ai/

AIのデータアクセスは「意図せず参照する」「意図せず壊す」リスクがある

通常のWeb アプリケーションでは、ユーザーがボタンを押した場合にのみ決まった操作が実行されます。一方、生成AIは与えられた指示を「解釈」して動くため、想定外の操作を自律的に行う可能性があります。

たとえば、営業担当者が「先月から動きのない案件のステータスを整理して」とAIに依頼したとします。AIがSalesforceにアクセスできる状態で、参照・更新操作の権限を持っていた場合、AIが「整理＝進捗なし案件を失注（Closed-Lost）に更新」と解釈し、他人が所有している商談や本来まだ商談中のレコードを一括で上書きしてしまう、というリスクがあります。

「そんなことをAIがするはずない」と思うかもしれませんが、AIはプロンプトの解釈次第で想定外の行動をとりえます。重要なのは、AIが何かをしたくても物理的にできない設計にしておくことです。

CData Connect AI では、以下の5つの層でこの制御を実現できます。

5層のアクセス制御モデル全体像

各層の制御が重なることで、より細かいアクセス管理が実現できます。今回はSalesforce をデータソースの例として、それぞれ見ていきましょう。

Layer 1：データソース側の権限

CData Connect AI は、接続先データソースの権限設定の上に乗る形で動作します。つまり、データソース・例えばSalesforce 側でアクセスできないオブジェクトやフィールドは、Connect AI 経由でもアクセスできません。

この点は設計上の重要な前提で、Connect AI 側で許可した操作がSalesforce 側の権限を超えることはありません。まずデータソース側の権限設定を正しく整備しておくことが、すべての制御の土台となります。

Layer 2：認証モデル — 「誰として」接続するか

Connect AI では、データソースへの接続に2種類の認証モデルが選択できます。

認証モデル	概要	適した用途
Shared Authentication	Connect AI 全ユーザーが同一のサービスアカウントで接続	読み取り専用・全員が同じデータを参照するケース
Per-User Authentication	Connect AI 各ユーザーが自分の認証情報で接続	規制対応・ユーザーごとにデータが異なるケース

https://docs.cloud.cdata.com/ja/Permissions

AI エージェントが動くとき、Shared Authentication であれば「サービスアカウントの権限」で、Per-User Authentication であれば「特定ユーザーの権限」でデータにアクセスします。

Salesforce など Per-User Authentication に対応しているデータソースでは、AI が特定ユーザーの権限の範囲内でのみ動くように設計できます。なお、Per-User Authentication はすべてのデータソースで利用できるわけではありませんが順次対応を進めていますので、このデータソースで使いたい、という要望があればお気軽にリクエストをください。

なお、コネクションのキャッシュ機能は Per-User Authentication と併用できない点にも注意が必要です。

https://docs.cloud.cdata.com/ja/Caching

Layer 3：コネクション権限 — 「何ができるか」を制限する

各コネクション（データソース接続）に対して、ユーザーごとに操作権限を設定できます。設定できる権限は以下の5種類です。

https://docs.cloud.cdata.com/ja/Permissions#table-access

権限	説明
Select	テーブルからのデータ取得
Insert	行の追加
Update	行の更新
Delete	行の削除
Execute	ストアドプロシージャの実行

この設定は、コネクション編集画面の Permissions タブ、または Users ページの Edit User 画面から行えます。Users ページでは、コネクション単位だけでなく Workspace 単位でも同様の権限設定が可能です。

AIエージェント向けの設計ポイント：読み取りのみでよい用途であれば、AIが使うユーザーアカウントに対して Select のみを付与し、Insert・Update・Delete・Execute は付与しない設定が有効です。これにより、AI はデータを参照することはできても、変更・削除は物理的に行えません。

Layer 4：公開範囲の制御 — 「何を見せるか」を絞る

コネクションのすべてのテーブルをAIに見せる必要はありません。CData Connect AI では、Derived Views と Workspace の機能を使って公開範囲を絞り込めます。

Workspace とアクセス権限

Workspace は、複数のデータソースのアセット（テーブル・ビュー・Derived View）をまとめて管理・公開する機能です。

https://docs.cloud.cdata.com/ja/Workspaces

Workspace 単位でもユーザーごとの権限（Select / Insert / Update / Delete）を設定できます。

AIエージェントには「AI 専用のWorkspace」を用意し、そこに必要なアセットのみを配置するアーキテクチャは、管理のしやすさという点でも整理しやすいです。

さらにDerived View（1つ以上のデータソースから必要なデータだけを抽出した仮想ビュー）を組み合わせることでより細かなコントロールが可能です。

例えば特定のカラムのみ、特定の条件のレコードのみを公開する形で作成できます。AI には元テーブルではなくWorkspace に配置したDerived View だけを見せる設計にすることで、不要なデータへのアクセスを防げます。

Layer 5：Toolkits — 「AIに渡すツール」を定義する

ここが、AI特有の制御として最も重要なレイヤーです。

Connect AI の Toolkits は、AI エージェントに渡すMCP ツールを管理者が定義する仕組みです。通常のMCP エンドポイントでは Connect AI の汎用ツール群がそのまま提供されますが、Toolkits を使うと公開するツールを細かく選択・制限できます。カスタムツールの設定は管理者ユーザーのみが行えます。

詳しくは以下の記事も参照してみてください。

https://jp.cdata.com/blog/cdata-connect-ai-toolkits

① Universal Tools の選択的有効化

queryData（データ取得）や executeProcedure（ストアドプロシージャ実行）など、Universal Tools は個別にON/OFFを切り替えられます。AI に必要な操作のみを有効化できます。

② Source Tools によるCRUD制御

Jira など対応データソースでは、「Get Issue」や「Create Issue」といったユースケース毎のツールを個別に有効化できます。更新ツールを有効化しなければ、AIはどのようなプロンプトを受け取っても更新操作を実行できません。これが冒頭の失敗シナリオへの直接的な答えです。

各ツールには AI Instructions を設定でき、「このツールは課題のチケットの参照専用です。」といった自然言語の指示をAIに伝えられます。

③ Custom SQL Tools で操作を特定クエリに限定

繰り返し実行するクエリを、パラメータ付きのカスタムSQLツールとして定義できます。AI は定義されたSQL 以外の任意クエリを実行できないため、操作の予測可能性が高まります。

-- 例：担当者IDを指定して商談を取得するのみ（汎用クエリは不可）
SELECT Id, Name, StageName, CloseDate
FROM Salesforce.Opportunities
WHERE OwnerId = @owner_id

④ Server Instructions による全体への境界設定

Toolkits 全体への指示（Server Instructions）を設定できます。「顧客データのみ参照すること。外部データは使用しない」といった制約をAI全体に伝えられます。

ただし、Server Instructions はあくまでAI へのガイダンスです。Layer 3 の権限設定や Source Tools のON/OFFによる制御と組み合わせて使うことが重要で、Server Instructions 単体を制御の主軸にするのは避けましょう。

⑤ Toolkits の注意点

Tooklit はあくまでAI 向けのエクスペリエンスとなるため、Connect AI を利用しているユーザー自身がどんなデータが参照でき、どんなデータを操作できるかどうかはまた別になります。

例えばToolkits で個人情報のカラムにアクセスできない「取引先情報参照ツール」を提供したとしても、ユーザー自身がデータソース元の個人情報アクセス権限を持っていれば、ユーザーはConnect AI やデータソース元のUIにアクセスしてデータを参照することが可能です。そのため実質的なアクセス制限は Layer 1・2 の権限設定が担っているということを意識しておきましょう。

推奨設計パターン

これまでの5層を踏まえた、用途別の設計パターンをいくつか例としてあげてみましょう。

ユースケース	認証モデル	コネクション権限	Toolkits 設定
読み取り専用AIエージェント	Shared	Select のみ	queryData のみ有効、Delete 系 Source Tool は無効
ユーザー別データ参照AI	Per-User	Select のみ	Custom SQL Tools で特定クエリのみ定義
データ登録を行うAI（慎重運用）	Per-User	Select + Insert	Custom SQL Tools でパラメータ付き INSERT のみ定義
汎用データ探索（管理者用途）	Shared	Select	Universal Tools を必要な範囲で有効化

初期段階では「読み取り専用AIエージェント」から始めて、業務要件に応じて書き込み権限を段階的に追加していくアプローチが無難ではあります。最初から全権限を与えて後から絞るより、必要なものだけを開放していく方が、意図しないリスクを防ぎやすいですね。

書き込みは開発環境やステージング環境で必ずテストしてから、本番のデータソースに接続を切り替えるように意識しましょう。

おわりに

CData Connect AI のアクセス制御は、データソース側の権限・認証モデル・コネクション権限・公開範囲・Toolkits の5層が重なる設計です。どの層で何を制御するかを理解しておくと、AIに「やってほしいことだけをやらせる」環境を整備しやすくなります。

最初から完璧な設定を目指す必要はありません。まず Layer 3 でユーザー権限を Select のみに絞り、Toolkits で書き込み・更新系ツールを無効にした状態から始めるだけでも、リスクを大きく下げられます。

ぜひトライアルで試してみてください。なにかわからないことがあれば、お気軽にお問い合わせからどうぞ。

https://jp.cdata.com/contact/

なお、各機能は利用できるConnect AI のライセンスが異なります。以下のプライスページも確認しておきましょう。

https://jp.cdata.com/ai/pricing/

ソリューションとユースケース CData Connect AI CData Connect AI MCP Toolkits AI RBAC Permission

CData は、AI を本番環境で機能させるデータレイヤーです。350 以上のソースへのライブコネクティビティとレプリケーション、セマンティックコンテキスト、組み込みガバナンスを提供。Databricks、Microsoft、Google、Palantir をはじめ、世界中の 10,000 以上のお客様の AI を支えています。

お問い合わせ

Blog