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

最近、社内向けの業務エージェントを検討されているお客様から「エージェントにどういった権限やアプローチで社内データを触らせるのが適切か？」というご相談をいただくことがありました。

業務課題を解決するAI エージェントを社内展開する場合、MCP やRAG などで社内データを絡めたアプローチは必須です。

しかし、「API キーや共有クレデンシャルでデータアクセスをするエージェント」として動かしてしまうと、ログを見ても「誰が」「なんの権限で」その操作をしたのか分からなくなってしまいます。

例えば、その操作でAI エージェントが見積を作成したとしたら、普段見積を作成することができないユーザーに代わって操作できてしまう可能性もあります。

そこで今回は、この課題に対する Microsoft Foundry の機能である OAuth identity passthrough を使い、Foundry 上のエージェントが Salesforce のデータに「ユーザー本人の権限」でアクセスする構成を、CData Connect AI と組み合わせてセットアップする手順を紹介したいと思います。

対象読者・前提知識

この記事は Microsoft Foundry でエージェントの構築経験がある方、OAuth の基本的な用語（Client ID、Authorization URL、Token URL など）に馴染みのある技術者の方を対象にしています。

なお、今回ご紹介する構成は 社内従業員が同一の Entra テナント内でエージェントを利用するケースを前提としています。

MCP サーバー・OAuth identity passthrough とは

まず前提となる仕組みを簡単に整理しておきましょう。

https://learn.microsoft.com/ja-jp/azure/foundry/agents/how-to/mcp-authentication

Microsoft Foundry のAgent Service が MCP サーバーに接続する方式は、大きく分けて次の4種類があります。

https://learn.microsoft.com/ja-jp/azure/foundry/agents/how-to/mcp-authentication#supported-authentication-methods

このうち OAuth identity passthrough だけが「ユーザーごとのコンテキスト」を保持します。

つまり、エージェントはログインしているユーザー本人の OAuth トークンを使って MCP サーバーを呼び出すため、そのユーザーが本来アクセスできる範囲のデータしか取得できません。

今回は CData Connect AI を MCP サーバーとして、この仕組みを実際に構成していきます。

全体アーキテクチャ

まずはイメージをつかんでいただくために、全体の流れを簡単な図にしてみました。

例えば、Azure Web Apps でFoundry Agent Service とMCP（CData Connect AI）を使ったエージェントを構成する、という想定する場合、以下のようなアーキテクチャになります。

社内ユーザーがエージェントに話しかけてから Salesforce のデータが返ってくるまで、途中の Foundry や CData Connect AI は「そのユーザー本人として」動作します。共有アカウントで一括アクセスするのではなく、常に本人の権限の範囲内でしかデータを取得できない、というのがこの仕組みの核心です。

これをもう少し技術的に分解すると、今回構成する認証チェーンは以下の3層構造になっています。（※Entra ID で認証している前提で）

• ① Entra ID → Foundry：Foundry RBAC により、そもそも「誰がこのエージェントを使えるか」を制御します（Foundry User ロール以上が必要です）

• ② Foundry → CData Connect AI：OAuth identity passthrough により、「そのユーザーとして」CData Connect AI の MCP エンドポイントを呼び出します

• ③ CData Connect AI → Salesforce：CData Connect AI の Per-User OAuth 認証により、「そのユーザーの Salesforce 権限」でデータを取得します

ポイントは、② と ③ の認可サーバーが別々だということです。Foundry から Microsoft 系以外の MCP サーバー（CData Connect AI など）へ接続する際、Entra ID のトークンはそのまま使われません。

Foundry は Microsoft 向けに発行されたトークンを非公式（Microsoft 認定外）の MCP エンドポイントへ渡すことを許可していないためです。そのため CData Connect AI 側に独自の OAuth サーバーを用意し、そちらでトークンを発行する構成になります。

ちなみに、Foundry からSalesforce に対してOAuth Identity Passthrough で直接接続する構成も取ることは可能です。ただし、Basic 認証などOAuth で接続できないデータソースに対してユーザーの認証を紐づけることができませんので、そういった意味でもこのCData Connect AI を介した接続はメリットがあります。

それでは実際に環境構築をしてみましょう。

必要なもの

今回の構成に必要な環境は以下のとおりです。

• Microsoft Foundry プロジェクト（Foundry User ロール以上のアカウント）

• CData Connect AI アカウント

• Salesforce の Connected App（またはユーザー認証情報）

• 同一 Entra テナントに所属する検証用ユーザー（複数用意できると権限分離の確認がしやすいです）

ちなみに今回のBlog 記事ではWeb Apps は省略し、Microsoft Foundry のエージェント開発画面のチャットを用いて、試してみます。

ステップ1：CData Connect AI 側の準備

Salesforce データソース接続の作成

まずは CData Connect AI の管理画面から、Salesforce をデータソースとして接続します。

接続には Salesforce の認証情報を使用しますが、今回のように「ユーザーごとに Salesforce の権限を分けたい」場合は、共有クレデンシャルではなく User Credential（Per-User 認証） を選択します。

CData Connect AI では Shared Credential と User Credential の2種類の認証パターンに対応しており、後者を選ぶことでユーザーごとに異なる Salesforce 権限でデータアクセスできるようになります。

Per-User OAuth 用の OAuth アプリを登録する

次に、Foundry から CData Connect AI へ接続するための OAuth アプリを CData Connect AI 側に登録します。

Settings のOAuth Apps から「＋ Create App」で追加しましょう。

設定値は以下の通りです。Callback URL は後ほどFoundry にCData Connect AI のMCP サーバーを追加した後、表示されるので今回は仮の値を設定しておきます。

登録が完了すると、ClientId ＆ ClientSecret が発行されます。これらは後ほど Foundry 側の設定で使用するので控えておきます。

ステップ2：Foundry での MCP 接続設定

続いて Foundry 側で CData Connect AI を MCP サーバーとして登録していきます。Foundry ポータルでプロジェクトを開き、ツールから「ツールを接続」をクリックします。

ツールの選択では「モデル コンテキスト プロトコル（MCP）」を選択しましょう。

認証方式には OAuth ID パススルー を選択し、先ほど CData Connect AI 側で発行した値を入力します。

設定を保存すると、Foundry 側からリダイレクト URL が払い出されます。このリダイレクト URL を CData Connect AI 側の OAuth アプリ設定に登録する必要があるので、忘れずに反映しておきましょう。Foundry → CData → Foundry という少し循環した設定になるため、ここは見落としやすいポイントです。

ステップ3：エージェントの設定とコンセントフロー

MCP サーバーの接続が完了したら、Foundry の対象のAgent にこの MCP ツールを追加します。

ここからが OAuth identity passthrough の本題です。エージェントが初めて CData MCP ツールを呼び出す際、Foundry のAPI は以下のような oauth_consent_request をレスポンスとして返します。

{
  "type": "oauth_consent_request",
  "id": "oauthreq_xxx",
  "consent_link": "https://logic-swedencentral-001.consent.azure-apihub.net/login?data=xxxx"
}

アプリ側はこの consent_link をユーザーに提示し、ユーザーは CData Connect AI の OAuth 画面でサインイン・コンセントを行います。

コンセントが完了すると、Foundry Agent Service がそのユーザーのトークンを保管します。以降の呼び出しでは再コンセントは不要で、自動的に本人のトークンが使われるようになります。

実際にエージェントを動かしてみると、ちょっとわかりにくいですが、以下のように自身のデータアクセスの権限に基づいて結果が取得できます。

おわりに

このように Foundry の OAuth identity passthrough と CData Connect AI の Per-User OAuth を組み合わせることで、AI エージェントに「ユーザー本人と同じ権限」でデータへアクセスさせる構成を実現できます。共有クレデンシャルでエージェントを動かすのに比べて、権限の一貫性と説明責任（誰が何にアクセスしたかの追跡可能性）を両立できるのが大きなメリットです。

社内向けのエージェント活用を検討されている方は、ぜひ CData Connect AI のトライアルで試してみてください。

なにかわからないことがあれば、お気軽にサポートやお問い合わせからどうぞ。

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