エンタープライズデータへ安全につなぐ Production-ready なエージェント設計 ― AI × MCP リファレンスアーキテクチャ ― #AIDevDay

AIエージェントの PoC を本番に持ち込めない理由は、「どのAI に、何を、どこまでさせてよいか」の設計と実装が曖昧なことにあります。本セッションでは、エンタープライズデータへの安全なアクセスを実現するために必要なAI のガバナンス設計を「安全性・説明責任・権限の一貫性」の3軸で整理。Microsoft Foundry と350 以上のデータソースにリアルタイム接続できる CData Connect AI のMCP を組み合わせたリファレンスアーキテクチャを提示し、PoC から本番運用への移行を見据えた具体的な設計パターンをお届けします。

https://aidevday.com/sessions/kazuya-sugimoto

Transcript

1. エンタープライズデータへ安全につなぐ Production-ready なエージェント設計 AI × MCP リファレンスアーキテクチャ AI Dev Day 2026 CData Software Japan Kazuya Sugimoto
2. 登壇者紹介 杉本 和也 CData Software Japan リードエンジニア／エバンジェリスト Microsoft 製品関連の SIer でエンジニア・プリセールスを経験後、CData にジョイン。API・MCP を専門領域とし、200種類以上の API の検証・調査 を実施。技術発信・ウェビナー登壇・パートナー支援を担当。 Microsoft MVP for Business Applications 2017‒2021 X: @sugimomoto GitHub: sugimomoto LinkedIn: sugimotok エンタープライズデータへ安全につなぐ Production-ready なエージェント設計 Facebook: sugimomoto
3. CData Software Japan 紹介 CData は、300以上のデータソースに接続可能なデータ連携ソリューションを提供して います。 CData Connect AI SaaS・データベースなどあらゆるデータソースと生成AI・AIエージェントをノーコードでつなぐデータレイヤ ー。今回紹介するアーキテクチャでは、AIエージェントに安全に「コンテキスト」と「権限」を渡す役割を担 います。 • リモート MCP サーバーとして、AI エージェントに構造化データへのアクセスを提供 • Per-User 認証・5層アクセス制御を備え、企業利用に耐えるセキュリティを実現 エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
4. SECTION 01 イントロダクション 「コンテキスト」「権限」、それを支える「ガバナンス」
5. Claude はチャットから解約・返金できるって知ってた？ エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
6. きっかけになった、営業現場の話 以前、ASCII のインタビュー記事 『商談準備と後処理の時間が6分の1に！営業マンが実践 する「AI×社内データ」フル活用術』 で、AI エージェントに商談の準備から記録までの一連 の流れを任せて、業務効率化を図った事例を公開 1/6 商談準備・後処理の時間が短縮 https://ascii.jp/elem/000/004/397/4397049/ エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
7. AI エージェントに「業務」を任せるには 何が必要だったのか？ エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
8. 業務課題を解決するために必要なAIエージェントの要素 コンテキスト 権限 の商談履歴や顧客情報を参照できなければ、AI テータス更新のような操作を代行して初めて、 社内のデータや状況を AI が理解する力。過去 は一般論しか返せない エンタープライズデータへ安全につなぐ Production-ready なエージェント設計 AI が実際に手を動かす力。SFA への登録やス 業務時間の削減・効率化につながる
9. このセッションので伝えたいこと AI エージェントに企業の業務データを安全に操作させるための 「コンテキスト・権限の要件とそれを支えるガバナンスの考え方」 そしてそれらを実現する 「AI エージェント基盤とデータアクセスレイヤーのリファレンスアーキテクチャ」 を紹介 エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
10. SECTION 02 なぜ「PoC」から 「本番化」できないのか？
11. 「聞かれて答える」から「任せて動かす」へ 多くの PoC では、RAG やプロンプトの工夫、業務マニュアルの読み込みといった形で「コンテキス ト」を補い、精度の高い回答が返ってくる状態には比較的早い段階で到達できる。しかし、これはあく まで「聞かれたことに答える」AI。「任せて動かす」AI に至らなければ、ROI に直結した AI 導入は 実現できない。 PoC でも実現できる 本番で任せたいのはここ 過去の見積データを参照して 適切な見積もりを 「適切な見積もりを評価する」 販売管理システムに登録する 顧客に提示する エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
12. この一歩を踏み出した瞬間に問われる様々な壁 コンテキストの要件 コンテキストの要件 権限の要件 リアルタイム性 正確性 書き込み RAG は日次・週次のインデックス 複雑な条件判断や書き込みの土台に 参照は聞き直せるが、書き込みは実 更新が前提。「今日時点でクローズ なる場面では、精度の低さがそのま データを直接変更するため、間違え 間近の商談は」に正しく答えられな い。 ま誤操作に直結する。 エンタープライズデータへ安全につなぐ Production-ready なエージェント設計 ば業務に影響し、元に戻すコストも 参照の訂正とは比較にならない。
13. 業界でも指摘されている構造的な問題 OWASP LLM Top 10（2025年版・LLM06:2025 Excessive Agency）では、過剰な権 限付与（Excessive Agency）が主要リスクの一つとして挙げられている。 根本原因 • データベースを読み取るだけの拡張機能が、SELECT だけでなく UPDATE・INSERT・ • 個々のユーザーのコンテキストで動作すべき拡張機能が、全ユーザーのデータにアクセスでき • ドキュメントを削除できるような高インパクトな操作が、ユーザーの承認なしに独立して実行 DELETE 権限まで持ったアイデンティティで接続している（過剰な権限） る汎用的な高権限アカウントで下流システムに接続している（過剰な権限） されてしまう（過度な自律性） エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
14. 本番化・組織展開には「コンテキスト」と「権限」 そして「ガバナンス」を土台としたアーキテクチャを目指す ことが重要になる エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
15. SECTION 03 ガバナンスは3つの軸で確保する
16. 「適切なコンテキスト」と「適切な権限」の要件 コンテキストの要件 権限の要件 正確性 透過性 リアルタイム性 コントロール性 可視性 自律性 正しいデータ・正しい理解を返せているか 「今の状態」を反映しているか 見せてよい範囲だけを見せているか エンタープライズデータへ安全につなぐ Production-ready なエージェント設計 ユーザー本人の権限をそのまま引き継いでいるか エージェント固有の視点でさらに絞り込めるか 高インパクトな操作の前に人間の確認を挟めるか
17. コンテキストと権限のためにガバナンスで確保する3つの軸 安全性 追跡可能性 認可の一貫性 壊さない・漏らさない。AI が「 誰が何をしたか追跡できる。障 本人の権限と AI への認可がズ ない設計にする る証跡を残す にも追従する 想定外の操作」を物理的にでき 害・監査・顧客説明に耐えられ レない。異動・退職などの変化 意思決定の権限は誰にあるのか、その決定は何に基づいて行われるのか、暴走や不正をどう防ぐのか、結果に対して 誰が説明責任を負うのか──こうした構造を設計し、機能させることがガバナンスの本質 エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
18. 2軸ではなく、ガバナンスが支える3層構造 コンテキスト 正確性・リアルタイム性・可視性 ガバナンス（土台） 安全性・追跡可能性・認可の一貫性 エンタープライズデータへ安全につなぐ Production-ready なエージェント設計 権限 透過性・コントロール性・自律性
19. SECTION 04 リファレンスアーキテクチャ Foundry × CData Connect AI で「コンテキスト」と「権限」を担保する
20. Microsoft Foundry × CData Connect AI リファレンスアーキテクチャ AIエージェント基盤（Foundry）とデータアクセスレイヤー（Connect AI）で 「コンテキスト」と「権限」、そして土台となる「ガバナンス」を確保するアーキテクチャ エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
21. Microsoft Foundry とは？ Microsoft Foundry（Foundry Agent Service）は、AI エージェントの実行・運用を一元管理 するマネージドプラットフォーム。モデルの呼び出しや MCP サーバーなどのツール呼び出しを オーケストレーションし、エージェントとしての振る舞いを実行する基盤。 Entra ID 認証・RBAC Tool Approval Workflow Agent 365 連携 誰がこのエージェントを使えるか 高インパクトな操作の前に人間の レジストリ・Entra Agent ID・ラ を制御 承認を挟む イフサイクル管理 エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
22. CData Connect AI とは Salesforce・SAP・Dynamics 365・Snowflake・kintone など350種類以上のエンタープラ イズシステムに、1つのリモート MCP エンドポイントでリアルタイムに接続できるマネージド MCP プラットフォーム。 350+ 12 SQL 仮想化 エンタープライズシステムへ接 種類のシンプルな MCP ツール 標準 SQL でデータにアクセス 続 エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
23. 5つの層でAI エージェントのコンテキストと権限を最適化 エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
24. SECTION 05 実際の動きを見てみる AI Agent Portal デモ
25. Microsoft Foundry × CData Connect AI デモ # 在庫チェック CData Connect AI で kintone の在庫管理を確認して Q-2026-0101の見積品目（FV-200A × 2、SV-40A × 5、DPT-500B × 1）の 在 庫状況と納期見込みを教えて。 エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
26. SECTION 06 適切な権限を実現する アーキテクチャのポイント
27. OWASP の予防策をそのまま具体化する これから紹介するリファレンスアーキテクチャは、独自の思いつきではなく、OWASP が推奨する予防策 をそのまま具体化したもの。次の3つは、権限の3要件とそれぞれ対応する。 ユーザーの認可を追跡し、そのユーザー本人のコンテキストで操作を実行す る（OAuth の活用など） → 透過性 拡張機能に付与する権限を、必要最小限に絞り込む → コントロール性 高インパクトな操作の前に、ユーザーの承認を必須とする → 自律性 エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
28. Foundry の4つの MCP 接続方式 方式 ユーザーごとのコンテキス ト 用途 Key-based 保持しない API キー・PAT による共有認証 Entra（agent identity） 保持しない エージェント単位の Entra 認証 Entra（project managed identity） 保持しない プロジェクト単位の Entra 認証 OAuth identity passthrough 保持する ユーザーごとの個別認証（Per-User） 上の3方式は固定の identity（マネージドID・サービスアカウント）で動作するため、話しかけているのが誰であ っても常に同じ権限でアクセスする。OAuth identity passthrough だけが、ユーザー本人の OAuth トークンを そのまま使う。 エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
29. 透過性だけでは、まだ十分ではない 営業担当者が「先月から動きのない案件のステータスを整理して」と依頼。 エージェントが「整理＝進捗のない案件を失注に更新」と解釈し、 まだ商談中のレコードまで一括更新してしまう ̶̶ という被害シナリオ。 これは「そのユーザーの権限内」で起きている操作なので、透過性の仕組みだけでは防げない。 AI は 指示を「解釈」して動くため、想定外の行動を取りうる。エージェントに渡す拡張機能・ツールそのも のを、業務に必要な最小限に絞り込んでおくコントロール性の設計が別途必要になる。 エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
30. データアクセスレイヤーの必要性 モデルレベルの統制 データアクセスレイヤーの統制 システムプロンプトやガードレール。プロンプト MCP ゲートウェイ。モデルへの指示内容に関係 弱点を持つ れても機能し続ける インジェクションによって回避されうる構造的な なくポリシーを強制でき、エージェントが侵害さ ※ MCP のセキュリティベストプラクティスでも「Token Passthrough」（自分宛てでないトークンの横流し）は禁止パターンとして明記されている エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
31. 5つの層でコントロールする Layer 1 データソース側の権限：Salesforce 側でアクセスできないものは、Connect AI 経由でもアクセスでき ない Layer 2 認証モデル：Shared Authentication／Per-User Authentication（＝透過性と接続） Layer 3 コネクション権限：Select／Insert／Update／Delete／Execute を個別に設定 Layer 4 公開範囲の制御：Workspace・Derived View で見せるデータを絞り込む Layer 5 Toolkit：AI に渡す MCP ツールを定義。更新系ツールを無効化すれば書き込み自体が不可能に エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
32. 二重の権限管理構造 Foundry 側 CData Connect AI 側 「誰が使えるか」を制御 「何にどこまで触れるか」を制御 • Microsoft Entra ID / RBAC Layer 1：データソース側権限 • Tool Approval Workflow（自律性） • Agent 365（一元管理・可視化） Layer 2：認証モデル（＝透過性） Layer 3〜5：コネクション権限・公開範囲・ Toolkit（＝コントロール性） 要点は「Foundry 側で『誰が使えるか』を、CData Connect AI 側で『何にどこまで触れるか』を、二重にチェックする」構造だけ押さえれば大丈夫。 エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
33. デモ ・CData Connect AI での営業アシスタント用MCPエンドポイントの構成 ・Microsoft Foundry でのツールの追加・OAuth Identity Passthrough の構成 ・MCP を使って見積作成依頼を行う エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
34. SECTION 07 OAuth Identity Passthrough の仕組み ユーザー権限はどう伝播するのか
35. 認証チェーンは3層に分かれる 1 Entra ID → Foundry 2 Foundry → CData Connect AI 3 CData Connect AI → DataSource Foundry RBAC により「誰がこのエージェントを使えるか」を制御 OAuth identity passthrough により「そのユーザーとして」MCP エンドポイントを呼び出す Per-User 認証により「そのユーザーの DataSource 権限」でデータを取得 「Foundry→CData」と「CData→DataSource」の認可サーバーは別々。CData Connect AI 側に独自の OAuth サーバーを用意し 、そちらで改めてトークンを発行する（Token Passthrough 禁止の原則に沿った設計） エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
36. AI Agent Portal デモ エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
37. 全体構成 エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
38. 認証チェーンフロー図① エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
39. 認証チェーンフロー図② エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
40. 初回のコンセントフロー エージェントが初めて CData Connect AI の MCP ツールを呼び出す際、Foundry は以下のような oauth̲consent̲request をレスポンスとして返す。 { } "type": "oauth̲consent̲request", "id": "oauthreq̲xxx", "consent̲link": "https://...consent.azure-apihub.net/login?data=xxxx" アプリ側はこの consent̲link をユーザーに提示し、ユーザーは CData Connect AI の OAuth 画面でサイ ンイン・コンセントを行う。完了後は Foundry Agent Service がトークンを保管し、以降は再コンセントな しに自動的に本人のトークンが使われる。 エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
41. Tool Approval Workflow の仕組み require̲approval パラメータで承認方針を設定： • always：すべてのツール呼び出しに承認が必要（デフォルト） • never：承認不要 • {always:[...]} / {never:[...]}：ツールごとに承認要否を個別に設定 mcp̲approval̲request mcp̲approval̲response { "type": "mcp̲approval̲ request", "name": "roll", "server̲label": "dmcp" } { "type": "mcp̲approval̲ response", "approve": true, "approval̲request̲id": "mcpr̲..." } デフォルトが always（毎回承認）なのは Least Privilege の考え方と一致。運用が安定してきた操作から never に切り替え、負荷と安 全性のバランスを取る。 エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
42. SECTION 08 コンテキストの3要件はどう実現されるか 正確性・リアルタイム性・可視性
43. 正確性を支える3層アーキテクチャ データアクセスレイヤーとしてREST API をそのままMCP として利用するのではなく、データ仮想 化・セマンティックレイヤーを構築し直し、AI 向けのエクスペリエンスへ最適化 • データソースレベルのセマンティックインテリジェンス：エンティティ間の関係・ビジネスロジッ ク・プラットフォーム固有の慣習を深く理解 • 標準化されたリレーショナルインターフェース：クエリを SQL ライクな操作に変換し、複雑なシ • 成熟したエンタープライズコネクタライブラリ：数十年にわたるコネクタ開発により各プラットフ ナリオにも対応 ォームのスキーマ規則を熟知 エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
44. 正確性：CData Connect AI のベンチマーク 98.5% 65〜75% 15〜30pt CData Connect AI の精度 他の MCP アプローチの平均精度 複雑クエリでの他社精度低下幅 CRM・プロジェクト管理・データウェアハウス・ERP の4業務システムにまたがる378件のクエリを検証。 CData Connect AI は複雑度によらず高精度を維持した（CData 社内テストによる）。 エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
45. 正確性：公式MCPとCData Connect AI の比較 kintone公式MCPとの実測比較： 比較項目 公式kintone MCP CData Connect AI 単純な取得・フィルタ・書き込み 差なし 差なし 集計タスク（GROUP BY・SUM等）のコスト 約3倍 基準 集計の正確性 0〜33% 100% トークンのコスト（同一タスク） ¥481（誤答） ¥29 平均トークン数 244,075 70,926（1/3.4） 公式MCPは全件をAI側に流し込 んで集計するためトークンが爆 発。CData Connect AIはサー バー側でSQL集計し、必要最小 限の結果だけを返します。 エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
46. 正確性を補強する Foundry のもう一つの要素 Knowledge tools メモリ（プレビュー） Foundry IQ（File Search・Azure AI Search・ セッションをまたぐ長期記憶（ユーザープロファイ Microsoft Fabric・SharePoint など）アップロ ル・チャット概要・手続き型）。統合フェーズで矛 照し、モデル単体の知識だけに頼らず根拠のあるデ クを減らす。 ードしたファイルや社内データをベクトル検索で参 ータに基づいて回答を組み立てる。 エンタープライズデータへ安全につなぐ Production-ready なエージェント設計 盾する情報を解消し、古い前提のまま応答するリス
47. リアルタイム性：バッチではなく直接クエリ 多くの PoC で使われる RAG は、事前にベクトル化してインデックスを作る方式のため、日次・週次の再イン デックスを前提にしている。CData Connect AI は、queryData などの MCP ツールが呼び出されるたびに、 業務システムへ直接クエリを発行。事前のインデックス作成や同期処理を挟まないため、「今の状態」を都度 取得可能。 エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
48. 可視性：Connect AI の Layer 1〜4 が担う 先ほどのコントロール性を実現する Layer 1〜4（データソース側権 限・認証モデル・コネクション権 限・公開範囲の制御）がそのまま答 えに。 見せてよい範囲を絞り込む仕組みは、 権限のコントロールと表裏一体。 エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
49. SECTION 09 ガバナンス 安全性・追跡可能性・認可の一貫性はどう実現されるか
50. 安全性：Least Privilege の多層的な実装 Foundry 側 CData Connect AI 側 Microsoft Entra RBAC によって「誰がこの Layer 3〜5（コネクション権限・公開範囲の エージェントを使えるか」自体を制御する 制御・Toolkit）で、AI エージェントに渡す権 限を業務に必要な最小限まで絞り込む 両者が組み合わさることで、最小権限の原則を多層的に実現する。 エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
51. 追跡可能性：トレースと監査ログを組み合わせる 追跡可能性は、実は Foundry 単体では完結しない。 Foundry のトレース：OpenTelemetry 準拠（Microsoft・Cisco Outshift 共同策定のマルチエージェ ント拡張含む）。操作の種類・実行時刻・成否は記録される。 しかし： Microsoft 自身のガイドラインが「個人データは編集・最小化する」ことを明記しており、人間 ユーザーの識別情報は意図的にトレースへ含めない設計方針 この「誰が」を補うのが、CData Connect AI 側の監査ログ。Per-User OAuth 接続で、どの業務ユー ザーの権限でどんなデータにアクセスしたかが記録される。 Foundry のトレース ＋ CData の監査ログ ＝ 「いつ・何を・誰が・どうなったか」 エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
52. 認可の一貫性：権限を経年でズレさせないために 本人の権限と AI への認可が、時間の経過や組織変化（異動・退職など）でもズレないようにする観点 Entra ID → Foundry → CData Connect AI → データソース OAuth identity passthrough による3層の認証チェーンを、リクエストのたびに通す。権限を一度取得してキ ャッシュするのではなく、都度その時点の本人の権限を確認する構成のため、静的にコピーする方式に比べてズ レが生じにくい。 エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
53. SECTION 10 おわりに
54. コンテキスト・権限・ガバナンスの担当マトリクス カテゴリ コンテキスト 権限 ガバナンス 要素 Foundry CData Connect AI 正確性 ◐ ◐ リアルタイム性 - • 可視性 - • 透過性 ◐ ◐ コントロール性 - • 自律性 • - 安全性 ◐ ◐ 追跡可能性 ◐ ◐ 認可の一貫性 ◐ ◐ 凡例：•主に担う ／ ◐両者で担保 ／ -関与なし エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
55. まとめ ― 9つの要件をどう実現するか カテゴリ コンテキスト 権限 ガバナンス 要件 実現する機能 正確性 CData のセマンティックインテリジェンス／Foundry の Knowledge tools・メモリ リアルタイム性 CData の直接クエリ（queryData） 可視性 CData のデータアクセスレイヤー（Layer 1〜4） 透過性 Foundry の OAuth passthrough ／ CData の Per-User OAuth コントロール性 CData のデータアクセスレイヤー（Layer 3〜5） 自律性 Foundry の Tool Approval Workflow 安全性 CData の Layer 3〜5 ＋ Foundry の Entra RBAC 追跡可能性 Foundry のトレース ＋ CData の監査ログ 認可の一貫性 OAuth 都度確認 ＋ Entra Agent ID ライフサイクル管理 これらが組み合わさることで、安全性・追跡可能性・認可の一貫性の3軸を満たしたまま本番運用へ進められます。 エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
56. CData Connect AI ビジネスパートナー募集中！ CData ブースはこちら！ ぜひ話に来てね！ 本日の資料Blog版 エンタープライズデータへ安全につなぐ Production-ready なエージェント設計
57. Claude × CData Connect AI ハンズオン開催！ https://jp.cdata.com/resources/claude-kintone-handson-2026/ エンタープライズデータへ安全につなぐ Production-ready なエージェント設計