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

以前、ASCII で公開されているインタビュー記事『商談準備と後処理の時間が6分の1に！営業マンが実践する「AI×社内データ」フル活用術』で、AI エージェントに商談の準備からその記録までの一連の流れを依頼して、業務効率化を図った内容をお話したことがありました。

このインタビューにも通じる要素なのですが、AI エージェントが業務課題を解決するためには「コンテキスト」と「権限」という2つが欠かせない要素であると私は考えています。そして、この2つを組織全体で・時間が経っても成立させ続けるには、土台となる「ガバナンス」も重要です。

• コンテキスト：社内のデータや状況を AI が理解する力。過去の商談履歴や顧客情報を参照できなければ、AI は一般論しか返せない。

• 権限：AI が実際に手を動かす力。参照するだけでなく、SFA（営業支援システム）への登録やステータス更新のような操作。

• ガバナンス：コンテキストと権限を支える土台。個人の工夫では閉じない、組織展開のフェーズで初めて問われる観点。

この記事では、AI エージェントに企業の業務データを安全に扱わせるためのコンテキスト・権限の設計の考え方と、それを支えるガバナンス、そしてそれらを実現する Microsoft Foundry × CData Connect AI のリファレンスアーキテクチャを紹介します。

AI エージェントを企業に導入するアーキテクトの方はもちろん、自社で AI 活用を推進されている方にも読んでいただける内容にしています。

なぜAI エージェントプロジェクトは「 PoC」は動くのに、「本番化」できないのか？

さて、具体的な内容に入っていく前に、なぜ今回の記事を書くに至ったのか？ という経緯をざっくりお伝えしたいと思います。私は日々様々なお客様やパートナー様とAI プロジェクトに関してお話するのですが、そんな中で繰り返し耳にする言葉があります。

それは「AI エージェントの PoC はうまくいった。でも、本番環境には持ち込めていない」という話です。

個人検証やデモレベルでは AI エージェントは驚くほどうまく動きます。しかし、それを組織展開しようとした瞬間に足が止まる。「なぜか・・・？」、私がヒアリングをする中で、これは技術力が足りないからではなく、「どの AI に、何を、どこまでさせてよいか」という設計と実装が曖昧なまま、本番化を進めようとしていることが原因だと考えるようになりました。

多くの PoC では、RAG やプロンプトの工夫、業務マニュアルの読み込みといった形で「コンテキスト」を補い、AI が業務知識を踏まえて受け答えできる状態を作り込みます。この情報補完によって、精度の高い回答が返ってくる状態には、比較的早い段階で到達できます。

しかし、これはあくまで 「聞かれたことに答える」AI です。本番運用で目指すのは、その先の 「業務を任せる」AI です。

例えば、過去の見積データを参照して「適切な見積もりを評価する」ところまでは PoC でも実現できますが、本番で任せたいのはその先、「適切な見積もりを販売管理システムに登録する」ところまでです。

そうでなければ、ROI に直結したAI 導入というものは実現できません。

しかし、この一歩を踏み出した瞬間に、次のような要件が新たに問われ始めます。

• リアルタイム性（コンテキストの要件）：質問に答えるだけなら多少古いデータでも許容できますが、業務判断を任せるなら「今の状態」を見て動く必要があります。例えば、PoC でよく使われる RAG は、ドキュメントやFAQ を事前にベクトル化してインデックスを作る方式が中心で、多くの場合は日次・週次といった定期的な再インデックスを前提にしています。「今日時点でクローズ間近の商談はどれか」「現在の在庫数は」といった刻一刻と変化する問いには、インデックスが更新されるまで正しく答えられません。一方、データウェアハウスや業務システムへ直接クエリを発行するアーキテクチャであれば、常に「今の状態」を取得できます

• 正確性（コンテキストの要件）：単純な参照であれば多少の粗さも許容されますが、複雑な条件判断や書き込みの土台になる場面では、精度の低さがそのまま誤操作に直結します。実際、CData が実施したベンチマークでも、多くの MCP サーバーはクエリが複雑になるにつれて精度が15〜30ポイント低下する一方、データソースごとに最適化されたアーキテクチャは複雑度によらず高い精度を維持したという結果が出ています。

• 書き込み（権限の要件）：参照して答えるだけでなく、見積もりの登録や商談ステータスの更新のようなアクションそのものを代行する必要があります。参照だけであれば、多少見当違いの回答が返ってきても「もう一度聞き直す」だけで済みますが、書き込みは実際の業務データを直接変更するため、間違えばそのまま業務に影響し、元に戻すコストも参照の訂正とは比べ物になりません。だからこそ、書き込みには「そもそも実行してよい操作なのか」という権限の設計が、参照以上に重要になります

そしてこれらは、いずれも「AI にどこまでの理解・判断・実行を任せてよいか」という同じ問いに行き着きます。任せる範囲が広がるほど、間違った理解に基づく誤操作のリスクも、なりすましのリスクも大きくなるからです。つまり、「聞かれて答える」から「任せて動かす」へ踏み出した瞬間、コンテキストの設計はもちろん、「権限」をどう設計するかが避けて通れなくなります。

これは私個人の印象だけでなく、業界でも指摘されている構造的な問題のようです。OWASP の LLM Top 10（2025年版・LLM06:2025 Excessive Agency）では、過剰な権限付与（Excessive Agency） が主要リスクの一つとして挙げられています。その根本原因として、次のような例が具体的に示されています。

• データベースを読み取るだけの拡張機能が、SELECT だけでなく UPDATE・INSERT・DELETE 権限まで持ったアイデンティティで接続している（過剰な権限）

• 個々のユーザーのコンテキストで動作すべき拡張機能が、全ユーザーのデータにアクセスできる汎用的な高権限アカウントで下流システムに接続している（過剰な権限）

• ドキュメントを削除できるような高インパクトな操作が、ユーザーの承認なしに独立して実行されてしまう（過度な自律性）

そのため、前述の「コンテキスト」と「権限」、それらをうまくカバーしたアーキテクチャを目指すことが本番化において重要になるわけです。

「適切なコンテキスト」と「適切な権限」の要件

まず「コンテキスト」と「権限」が求められる背景について共有しましたが、もうちょっと深堀りしてみましょう。

この2つの要素をもう少し具体的に見ると、「コンテキスト」にも「権限」にも、それぞれ3つの要件があります。

コンテキストの要件

• 正確性：正しいデータ・正しい理解を返せているか？

• リアルタイム性：「今の状態」を反映しているか？

• 可視性：見せてよい範囲だけを見せているか？（先ほど触れた通り、これは権限と表裏一体です）

権限の要件

• 透過性：ユーザー本人の権限を、そのままエージェントが引き継いでいるか？

• コントロール性：エージェント固有の視点で、渡す権限をさらに絞り込めるか？

• 自律性：高インパクトな操作の前に、人間の確認を挟めるか？

なお、この2つの要件は、あくまで一人のユーザーが「今、この瞬間」に満たせているかどうかの話です。これを全社員・全部門が日常的に使う前提で、時間が経っても崩れないように設計しようとした瞬間、話は一気に難しくなります。個人の工夫では閉じない、アーキテクトが向き合うことになる組織全体の設計課題がここに生まれます。

つまり全体像は、「コンテキスト」と「権限」という2つの軸が横に並んでいるのではなく、この2つを土台として下から支える「ガバナンス」がある3層構造として捉えると整理しやすくなります。ただし、支え方は一様ではありません。安全性・認可の一貫性は、主に「権限」が時間の経過や組織展開の中で崩れていないかを継続的に確認する役割を担い、追跡可能性だけがコンテキスト・権限の両方を横断して記録します。詳しくは後ほど改めて整理します。

これらの要素が揃って初めて、AI エージェントは「便利なチャットボット」から「業務を代行するエージェント」へと進化すると言えるでしょう。そして、それを個人の工夫を超えて組織全体で成立させ続けるのが、土台としてのガバナンスの役割です。

ガバナンスは3つの軸で確保する

それでは先ほど、「コンテキスト」と「権限」を土台として支えるものと位置づけた「ガバナンス」を、具体的にどう捉えればよいのか？

ここで問われているのは、単に「AI に何をさせるか」という一点だけではありません。AI が自律的に動く世界であっても、人間が意図した範囲内で動く保証が必要です。これがガバナンスの本質だと考えています。PoC を本番化するにあたっては、次の3つの軸を確保する必要があります。

多くのプロジェクトが本番化でつまずくのは、この3つのうち「安全性」しか設計されていないことが多いからだと感じています。

PoC の検証環境では、少人数・限定的な操作範囲のおかげで安全性さえ確保しておけば大きな問題にはなりません。しかし本番化を目指すのであれば、「誰が何をしたか追跡できるか（追跡可能性）」と「本人の権限とAIへの認可がズレていないか（認可の一貫性）」も、最初から視野に入れておく必要があります。

それぞれの軸には、実務上の裏付けとなる考え方があります。

• 安全性：「とりあえずフルアクセス」ではなく「そのユースケースに必要な最小限」から設計するのが「最小特権の原則（PoLP：Principle of Least Privilege）」です。棚卸し→分類→ロール定義→検証→監査という順で進め、操作は「リスク × 可逆性」で分類し、高リスク・不可逆な操作ほど付与するスコープ自体を絞り込む、という考え方が実務では有効とされています（操作実行前に人間の承認を挟むかどうかは、前述した権限の要件「自律性」が担う役割です）。実際、MCP の最新仕様（2025-11-25 リビジョン）でも Scope Minimization として、最初は最小限のスコープだけを渡し、権限が必要な操作を試みたタイミングで都度追加スコープを要求する「段階的なコンセント」の仕組みが正式に取り入れられており、Least Privilege の考え方がプロトコルレベルでも標準化されつつあります。

• 追跡可能性：オブザーバビリティの業界標準（OpenTelemetry等）では、操作の種類・実行時刻・成否・エージェント間の委任関係を一貫した形式で記録する設計が広まりつつあります。一方でこうした標準は、個人データの最小化を重視する設計が主流であり、「誰の代理で実行されたか」という人間ユーザーの識別情報は、意図的に含めない設計になっていることが多いのが実情です。この「誰が」をどう補うかは、後述するリファレンスアーキテクチャで具体的に見ていきます。

• 認可の一貫性：AI エージェントは人間と違い、同じ指示でも毎回異なる判断をしうる「非決定論的」な性質と、人間の承認なしに次々とアクションを連鎖させる「自律的実行」という性質を持ちます。人間であれば都度の判断で問題なくできる操作でも、AI エージェントに同じ権限をそのまま渡すとリスクが増幅されるのはこのためです。また、エージェントの権限が特定の人間のオーナーに紐づいていない場合、そのオーナーが退職・異動しても権限がそのまま残り続けるという問題もあります（Agent Identity Security）

リファレンスアーキテクチャ ― Microsoft Foundry × CData Connect AI で「コンテキスト」と「権限」を担保する

以上にようにAI エージェントの PoC を「業務を任せられる本番化」するために必要なのは、適切なコンテキストの付与と適切な権限の付与、そしてその2つを支えるガバナンスの確保です。

これら要素をすべて自前でカバーすることは難しいですが、 AI エージェント基盤（Microsoft Foundry） と データアクセスレイヤー（CData Connect AI） を組み合わせたアーキテクチャで実現できます。

それではここからは、Microsoft Foundry と CData Connect AI を組み合わせたリファレンスアーキテクチャが、この「コンテキスト」と「権限」の両方、そして「ガバナンス」をどう実現するかを見ていきましょう。

なお、以降は権限→コンテキストの順で見ていきます。コンテキストの「可視性」は権限の「コントロール性」の仕組みと表裏一体のため、先に権限側を説明した方が理解しやすいためです。

Microsoft Foundry とは？

Microsoft Foundry は、AI エージェントの実行・運用を一元管理するマネージドプラットフォームです。モデルの呼び出しや MCP サーバーなどのツール呼び出しをオーケストレーションし、エージェントとしての振る舞いを実行します。

実行基盤としてだけでなく、組織的な統制の仕組みも備えています。Microsoft Entra ID による認証・RBAC で「誰がこのエージェントを使えるか」を制御し、高インパクトな操作の前には Tool Approval Workflow で人間の承認を挟めます。さらに Microsoft Agent 365 と連携させることで、組織内の全エージェントを一つのレジストリで可視化し、エージェント自身にも Entra Agent ID としてのアイデンティティを持たせた上で、定期的なアクセスレビューやライフサイクル管理（プロビジョニング・削除）を組み込めます。

CData Connect AI とは

CData Connect AI は、Salesforce・SAP・Dynamics 365・Snowflake・kintone など350種類以上のエンタープライズシステムに、1つのリモート MCP エンドポイントでリアルタイムに接続できるマネージド MCP プラットフォームです。各 API をリレーショナルインターフェースに標準化する SQL 仮想化により、LLM は標準 SQL でデータにアクセスできます。また getTables / queryData など12種類のシンプルな MCP ツールに集約されているため、LLM のコンテキストを無駄に消費しません。

またPer-User Authentication やコネクション権限、Workspace などセキュリティ・ガバナンス周りの機能も豊富に持っており、各層の制御が重なることで、より細かいAI のためのアクセス管理が実現できます。

実際の動きを見てみる ― AI Agent Portal デモ

まず実現したいことのイメージを実際に画面で確認できるデモアプリを作成したので見てみましょう。「AI エージェントはログインユーザーの権限の範囲でしかデータを返せない」ということを、直感的に理解できる1画面のデモです。

https://github.com/sugimomoto/AIAgentPortalDemo

• Microsoft 風のログイン画面からチャットで質問すると、回答が Markdown（表付き）でストリーミング表示されます

• 右パネルの「Inside the Agent」で、Entra ID → Foundry → CData Connect AI → Salesforce という認証・認可のフローをシーケンス図としてリアルタイムに可視化しています

• 初回の呼び出し時には CData OAuth のコンセント待ち状態になり、承認すると処理が再開します。このコンセントフローの詳細な仕組みは、このあとの「OAuth Identity Passthrough の仕組み」で改めて解説します

• 画面上部のユーザーを田中さん（営業担当）から山田さん（マネージャー）に切り替えて同じ質問を投げると、取得できる件数・データの範囲が変化する様子を確認できます

ここから先は、アーキテクトの方に向けて、この画面の裏側で何が起きているのかを具体的に掘り下げていきます。

全体構成

色々と複雑なことをしているように見えますが、接続の全体像はシンプルです。

「Microsoft Foundry Agent Service」のMCP Tool として、データレイヤーとなる「CData Connect AI」を登録し、そこから各種ビジネスデータにアクセスする構成としています。

Microsoft Foundry Agent Service
    │
    │  MCP Tool として登録
    ▼
CData Connect AI（リモート MCP エンドポイント）
    │
    │  350+ コネクタ経由でリアルタイム接続
    ▼
エンタープライズデータソース
（Salesforce / SAP / Dynamics 365 / Snowflake / kintone ...）

役割分担

Microsoft Foundry と CData Connect AI は、それぞれ得意な領域を分担します。

今回のアーキテクチャのコンテキスト・権限・ガバナンスの担当マトリクスを整理すると以下のようになります。それぞれが担当する領域と、両サービスがセットで担当する領域とに大きく分けられます。

凡例：● 主に担う／◐ 両者で担保 ／- 関与なし

適切な権限を実現するアーキテクチャのポイント

それではアーキテクチャのポイントをまずは権限の側から見ていきましょう。先ほど紹介した OWASP の Excessive Agency には、予防策も具体的に示されています。その中でも次の3つは、権限の3要件（透過性・コントロール性・自律性）とそれぞれ対応します。

• 「ユーザーの認可を追跡し、そのユーザー本人のコンテキストで操作を実行する（OAuth の活用など）」→「透過性」

• 「拡張機能に付与する権限を、必要最小限に絞り込む」→ 「コントロール性」

• 「高インパクトな操作の前に、ユーザーの承認を必須とする」→ 「自律性」。

つまりこれから紹介するリファレンスアーキテクチャは、独自の思いつきではなく、OWASP が推奨する予防策をそのまま具体化したものです。

OAuth Identity Passthrough の仕組み ― ユーザー権限はどう伝播するのか

先ほど挙げた「透過性：ユーザー本人の権限の伝播」を、Foundry は具体的にどう実現しているのでしょうか。

Foundry Agent Service が MCP サーバーに接続する方式は、大きく4種類に分かれます。

上の3方式は、いずれもエージェント自身やプロジェクトに紐づく固定の identity（いわばマネージドID・サービスアカウント）で動作するため、話しかけているのが誰であっても常に同じ権限でアクセスします。これに対して OAuth identity passthrough だけが、エージェントを呼び出しているユーザー本人の OAuth トークンをそのまま使って MCP サーバーにアクセスします。つまりエージェントは、そのユーザーが本来アクセスできる範囲のデータ・操作しか扱えません。

データアクセスレイヤーの必要性

次にポイントになるのが、なぜ権限要件を CData Connect AI のようなデータアクセスレイヤーでカバーする必要があるのか、という点です。

AI エージェントの権限コントロールというと、システムプロンプトやガードレールといったモデルレベルの統制を思い浮かべがちですが、これはプロンプトインジェクションによって回避されうる構造的な弱点を持っています。

一方で、MCP ゲートウェイのようなデータレイヤーの統制は、モデルへの指示内容に関係なくポリシーを強制でき、エージェントが万が一侵害されても機能し続けます。

この観点から、CData Connect AI はエンタープライズデータとエージェントの間に立つ MCP ゲートウェイとして、認証・認可・ロギングをモデルから独立して強制する役割を担います。

実はこの構成は、MCP の仕様そのものが求めている設計とも一致しています。MCP のセキュリティベストプラクティスでは、「Token Passthrough」――MCP サーバーが自分宛てに発行されたのではないトークンをそのまま下流の API に横流しする行為――は明確な禁止パターンとして挙げられています。

理由は、監査証跡が壊れる（誰のリクエストか区別できなくなる）ことと、下流サービス側のセキュリティ制御を回避してしまうことです。Foundry が Microsoft 向けに発行されたトークンを CData Connect AI にそのまま渡さず、CData Connect AI が自前の OAuth サーバーで改めてトークンを発行する構成になっているのは、まさにこの Token Passthrough を避けるための設計だと言えます。

それではCData Connect AI の各レイヤーで具体的にどんな機能でカバーするか見てみましょう。

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

CData Connect AI は、接続先データソースの権限設定の上に乗る形で動作します。つまり、Salesforce 側でアクセスできないオブジェクトやフィールドは、CData Connect AI 経由でもアクセスできません。CData Connect AI 側で許可した操作が Salesforce 側の権限を超えることはなく、データソース側の権限設定を正しく整備しておくことが、すべての制御の土台になります。

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

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

AI エージェントが動くとき、Shared Authentication であれば「サービスアカウントの権限」で、Per-User Authentication であれば「特定ユーザーの権限」でデータにアクセスします。今回の透過性（OAuth identity passthrough）は、この Per-User Authentication と組み合わさって初めて意味を持ちます。Foundry から引き継がれたユーザーの識別情報を、CData Connect AI が Per-User Authentication として実際に Salesforce への接続に反映する、という関係です。

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

各コネクションに対して、ユーザーごとに Select／Insert／Update／Delete／Execute の5種類の操作権限を設定できます。読み取りのみでよい用途であれば、AI が使うアカウントに Select のみを付与し、他を付与しない設定が有効です。これにより、AI はデータを参照することはできても、変更・削除は物理的に行えません。

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

コネクションのすべてのテーブルを AI に見せる必要はありません。Workspace（複数データソースのアセットをまとめて管理・公開する機能）と Derived View（必要なデータだけを抽出した仮想ビュー）を組み合わせることで、公開範囲を絞り込めます。AI エージェント専用の Workspace を用意し、元テーブルではなく必要なカラム・条件だけに絞った Derived View だけを配置する設計にすると、不要なデータへのアクセスを構造的に防げます。

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

ここが、AI 特有の制御として最も重要なレイヤーです。Toolkit は、AI エージェントに渡す MCP ツールを管理者が定義する仕組みで、以下のような独自のクエリに基づいたツールの提供ができます。

なお、Toolkit はあくまで AI 向けのエクスペリエンスであり、CData Connect AI を利用しているユーザー自身がデータソース元で個人情報などへのアクセス権限を持っていれば、そのユーザー自身は別の手段でデータを参照できてしまいます。実質的なアクセス制限を担っているのは Layer 1・2 だという点は意識しておく必要があります。

整理すると、CData Connect AI 側の Layer 2（Per-User OAuth） が、「透過性」 にあたります。Foundry の OAuth identity passthrough によってユーザーの識別情報が引き継がれ、CData Connect AI 側でそのユーザー本人の Salesforce 権限が適用される、という流れです。

透過性（OAuth identity passthrough）だけでも、AI エージェントは「そのユーザーが Salesforce 上で本来アクセスできる範囲」を超えることはできなくなります。しかし、これだけでは実はまだ十分ではありません。

例えば、営業担当者が「先月から動きのない案件のステータスを整理して」とエージェントに依頼したとします。エージェントが Salesforce への参照・更新権限を持っていた場合、「整理＝進捗のない案件を失注（Closed-Lost）に更新すること」とプロンプトを解釈し、本来はまだ商談中のレコードまで一括で更新してしまう、というリスクがあります。これは「そのユーザーの権限内」で起きている操作なので、透過性の仕組みだけでは防げません。AI は通常のアプリケーションと違い、指示を「解釈」して動くため、想定外の行動を取りうるからです。

重要なのは、AI が何かをしたくても物理的にできない設計にしておくことです。そして Layer 3〜5（コネクション権限・Workspace / Derived View・Toolkit） が、「データへのアクセスのコントロール」（コントロール性） にあたります。ユーザー本人が Salesforce 上で本来できる操作の中からさらに、「AI エージェントには渡さない操作」「見せないデータ」を絞り込む層です。

Layer 1（データソース側権限）は Salesforce 自体のプロファイル権限であり、CData Connect AI が直接コントロールする範囲ではありません。実質的に CData Connect AI が担っているのは Layer 2〜5、つまり「誰の権限で接続するか」から「AI にどのツール・データを見せるか」までの制御です。

二重の権限管理構造

ここまでの役割分担を、先ほどの3軸に当てはめてみると、Foundry 側と CData Connect AI 側で二重に権限管理の構造がかかっていることが分かります。

[Foundry 側]
  ├── Tool Approval Workflow（MCP ツール呼び出しの承認フロー）
  ├── Microsoft Entra ID / RBAC（誰がエージェントを使えるかの制御）
  └── Agent 365（組織内エージェントの一元管理・可視化）

[CData Connect AI 側]
  ├── Layer 1：データソース側権限（Salesforce プロファイル等）
  ├── Layer 2：認証モデル（Per-User OAuth / Shared）
  ├── Layer 3：コネクション権限（SELECT のみ等）
  ├── Layer 4：Workspace / Derived View（公開範囲の絞り込み）
  └── Layer 5：Toolkit（AI に渡すツールの定義・制限）

細かい実装を追わなくても、要点は「Foundry 側で『誰が使えるか』を、CData Connect AI 側で『何にどこまで触れるか』を、二重にチェックする」という構造だけ押さえていただければ大丈夫です。

認証チェーンは3層に分かれる

今回のアーキテクチャで実際に構成される認証チェーンは、以下の3層構造になります。

• Entra ID → Foundry：Foundry RBAC により、そもそも「誰がこのエージェントを使えるか」を制御します

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

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

ここで重要なのは、「Foundry → CData Connect AI」と「CData Connect AI → Salesforce」の認可サーバーが別々だということです。Foundry は Microsoft 向けに発行されたトークンを、Microsoft 認定外の MCP エンドポイント（CData Connect AI など）にそのまま渡すことを許可していません。そのため CData Connect AI 側に独自の OAuth サーバーを用意し、そちらで改めてユーザーのトークンを発行する構成になります。これは先ほど触れた MCP の Token Passthrough 禁止の原則にも沿った設計です。

初回のコンセントフロー

もうちょっと細かい機能の動作も見てみましょう。エージェントが初めて CData Connect AI の MCP ツールを呼び出す際、Foundry は以下のような 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 がそのユーザーのトークンを保管し、以降の呼び出しでは再コンセントなしに、自動的にそのユーザー本人のトークンが使われるようになります。

具体的な接続設定はここでは割愛しますが、大まかな流れとしては、CData Connect AI 側で Per-User OAuth 用の OAuth アプリを登録し、Foundry 側では MCP サーバーの認証方式として「OAuth ID パススルー」を選択して、発行された Client ID / Client Secret やエンドポイント情報を設定します。

Tool Approval Workflow の仕組み

さらに冒頭で挙げた「自律性」（高インパクトな操作の前に、人間の確認を挟めるか）を、Foundry は具体的にどう実現しているのでしょうか。

MCP ツールを Foundry に接続する際、require_approval というパラメータで承認方針を設定できます。

• always：すべてのツール呼び出しに承認が必要（デフォルト）

• never：承認不要

• {"always": [...]} / {"never": [...]}：ツールごとに承認要否を個別に設定

承認が必要なツールをエージェントが呼び出そうとすると、レスポンスに以下のような mcp_approval_request が含まれます。

{
  "id": "mcpr_68a619e1d82c8190b50c1ccba7ad18ef0d2d23a86136d339",
  "type": "mcp_approval_request",
  "name": "roll",
  "arguments": "{\"diceRollExpression\":\"2d4 + 1\"}",
  "server_label": "dmcp"
}

これは、先ほどの oauth_consent_request と同じ仕組みで、レスポンスの中の1アイテムとして返されます。アプリ側はこの内容（呼び出そうとしているツール名・引数）を人間に提示し、承認・却下を判断してもらいます。承認結果は、以下のような mcp_approval_response として次のリクエストに含めて送信し、処理を再開します。

{
  "type": "mcp_approval_response",
  "approve": true,
  "approval_request_id": "mcpr_682d498e3bd4819196a0ce1664f8e77b04ad1e533afccbfa"
}

デフォルトが always（毎回承認）になっているのは、Least Privilege の考え方とも一致します。運用が安定してきた操作から never に切り替えたり、ツール単位で承認要否を絞り込んだりすることで、実務上の負荷と安全性のバランスを取ります。

コンテキストの3要件はどう実現されるか ― 正確性・リアルタイム性・可視性

ここまでガバナンス・権限の実現方法を見てきましたが、冒頭で挙げた「コンテキストの要件」（正確性・リアルタイム性・可視性）についても、Microsoft Foundry とCData Connect AI のアーキテクチャがどう支えているかを見ておきます。

正確性：セマンティックインテリジェンスと標準化されたインターフェース

CData が実施したベンチマークでは、CRM・プロジェクト管理・データウェアハウス・ERP の4業務システムにまたがる378件のクエリを検証した結果、CData Connect AI は98.5%の精度を達成しました。

一方、他の MCP アプローチ（プラットフォーム公式 MCP、汎用コネクタフレームワーク、API への直接変換など）は平均65〜75%にとどまり、クエリが複雑になるほど15〜30ポイント精度が低下したのに対し、CData Connect AI は複雑度によらず高精度を維持しました（CData 社内テストによる）。

この差を生んでいるのが、次の3層構造です。

• データソースレベルのセマンティックインテリジェンス：自然言語のプロンプトを直接 API 呼び出しに変換するのではなく、各データソースのエンティティ間の関係（例：商談は関連付けを介して取引先担当者とつながる）、ビジネスロジック（会計カレンダーの定義、ワークフローの検証ルール）、プラットフォーム固有の慣習を深く理解します

• 標準化されたリレーショナルインターフェース：クエリを SQL ライクな操作に変換し、複数テーブルの関係や日付計算を伴う複雑なシナリオにも対応します

• 成熟したエンタープライズコネクタライブラリ：数十年にわたるコネクタ開発により、各プラットフォーム固有のスキーマ規則・慣習を熟知しています

正確性・メモリとナレッジによる業務理解のカバーリング

とはいえ、これに加えて、Foundry 側にも正確性を支える要素があります。Knowledge tools（Foundry IQ・File Search・Azure AI Search・Microsoft Fabric・SharePoint など）は、アップロードしたファイルや社内のインデックス化されたデータをベクトル検索で参照し、モデル単体の知識だけに頼らず、根拠のあるデータに基づいて回答を組み立てられるようにする仕組みです。

さらに、Foundry Agent Service のメモリ（プレビュー）は、セッションをまたいでユーザーの好みや過去のやり取りを保持する長期記憶の仕組みで、ユーザープロファイル・チャット概要・手続き型の3種類の記憶を抽出・統合・検索します。特に統合フェーズでは、矛盾する情報（例：更新されたユーザーの希望）を解消し、常に最新かつ一貫した記憶を保つ設計になっており、エージェントが古い前提のまま応答してしまうリスクを減らします。

これらの機能を使いながら、MCP ツールの呼び出しや手続きの安定性を担保するのが良いでしょう。

リアルタイム性：バッチではなく直接クエリ

多くの PoC で使われる RAG は、事前にベクトル化してインデックスを作る方式のため、日次・週次の再インデックスを前提にしていることは、先ほど触れた通りです。CData Connect AI は、queryData などの MCP ツールが呼び出されるたびに、業務システムへ直接クエリを発行します。事前のインデックス作成や同期処理を挟まないため、「今の状態」を都度取得できます。

可視性：Layer 1〜4 が担う

可視性については、実は先ほどのコントロール性「データへのアクセスのコントロール」を実現する Layer 1〜4（データソース側権限・認証モデル・コネクション権限・公開範囲の制御）がそのまま答えになります。見せてよい範囲を絞り込む仕組みは、権限のコントロールと表裏一体だからです。

ガバナンス ― 安全性・追跡可能性・認可の一貫性はどう実現されるか

ここまで権限とコンテキストの実現方法を見てきましたが、最後にガバナンスの3つの軸が、このアーキテクチャでどう担保されるかを整理しておきます。

安全性：Least Privilege の多層的な実装

安全性については、すでに見てきた内容がそのまま答えになります。CData Connect AI の Layer 3〜5（コネクション権限・公開範囲の制御・Toolkit）が、AI エージェントに渡す権限を業務に必要な最小限まで絞り込みます。Foundry 側でも、Microsoft Entra RBAC によって「誰がこのエージェントを使えるか」自体を制御しており、両者が組み合わさることで最小権限の原則を多層的に実現しています。

追跡可能性：Foundry のトレースと CData の監査ログを組み合わせる

追跡可能性については、実は Foundry 単体では完結しません。

Foundry のエージェントトレースは OpenTelemetry のセマンティック規約に準拠しており、Microsoft と Cisco Outshift が共同策定したマルチエージェント向け拡張により、エージェント間の委任・オーケストレーションも標準化された形で記録されます。実際に Foundry Agent Service が出力するトレースを確認すると、操作の種類（invoke_agent 等）・実行時刻・成否は記録されています。

しかし、Microsoft 自身のガイドラインは「個人データやその他の機微な情報は、テレメトリに到達する前に編集・最小化すること」を明記しており、「誰が（人間ユーザーの識別情報）」は意図的にトレースへ含めない設計方針になっています。

この「誰が」を補うのが、CData Connect AI 側の監査ログです。Per-User OAuth 接続では、どの業務ユーザーの権限でデータソースにアクセスしたかが記録されるため、Foundry のトレースと組み合わせて初めて「いつ・何を・誰が・どうなったか」を追跡できます。役割分担表で Foundry 側を「Observability」、CData 側を「監査ログ」としているのはこのためです。

認可の一貫性：権限を経年でズレさせないために

認可の一貫性は、本人の権限と AI への認可が、時間の経過や組織変化（異動・退職など）でもズレないようにする観点です。

これを支えているのが、前述の OAuth identity passthrough による3層の認証チェーンです。

Entra ID → Foundry（Foundry RBAC で「誰がこのエージェントを使えるか」を制御）→ CData Connect AI（OAuth identity passthrough で「そのユーザーとして」呼び出し）→ Salesforce（Per-User OAuth 認証で「そのユーザーの Salesforce 権限」を取得）という流れが、リクエストのたびに実行されます。権限を一度取得してキャッシュするのではなく、都度このチェーンを通してその時点の本人の権限を確認する構成のため、権限を静的にコピー・キャッシュする方式に比べてズレが生じにくい設計です。

まとめ ― アーキテクチャの各要素が担うもの

ここまで見てきた9つの要件が、それぞれどの機能で実現されるかを表で整理しておきます。

これらが組み合わさることで、PoC で動いた AI エージェントを、安全性・追跡可能性・認可の一貫性という3つの軸を満たしたまま本番運用へ進めることができます。

なお、CData Connect AI 側のコネクション権限や Toolkit は、最初から全権限を与えて後から絞るより、読み取り専用から始めて業務要件に応じて段階的に書き込み権限を広げていく方が、意図しないリスクを防ぎやすいというのが実務上の感触です。

おわりに

今回の結論をあらためて一言でまとめると、PoC を本番化するために必要なのは、適切なコンテキストの付与・適切な権限の付与、そしてそれを支えるガバナンスの確保です。

権限の付与はユーザー本人の権限をエージェントに伝播させること（透過性）と、データへのアクセスをエージェント固有の視点でコントロールするレイヤーを組み合わせること（コントロール性） という二段構えで実現し、コンテキストとガバナンスもあわせて Foundry（AI エージェント基盤）と CData Connect AI（データアクセスレイヤー） というアーキテクチャがまるごと担います。

安全性・追跡可能性・認可の一貫性という3つの軸を最初から視野に入れてガバナンスを設計していくことで、PoC から本番運用へと無理なく進めることができます。

長くなりましたが、このリファレンスアーキテクチャが皆さんのAI プロジェクトの役に立ってもらえると嬉しいです。

なにかわからないことがあれば、お気軽にサポートやお問い合わせからどうぞ。CData Connect AI のトライアルもぜひお試しください。

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