こんにちは。CData Software Japan の色川です。

先日公開した「こちらの記事」では、CData Connect AI とCData API Server を組み合わせることで、AI からオンプレミスデータアクセスを「よりコントローラブルに実現する」方法をご紹介しました。

CData Connect AI はCData が提供するフルマネージドなMCP プラットフォーム（MCP ゲートウェイ）で、AI を構築するチームに対してスピーディにガバナンスの効いたデータレイヤーを提供します。Connect AI は、多くのお客さまやユースケースにおける「確信できるAI を支えるデータレイヤー」として最適です。一方で、お客さまから「AI 推論もデータもアクセストークンも、自社が管理するテナント内で完結したい」というご相談をいただくケースもあります。そういったご相談は、規制の厳しい業種・業界のお客さまからいただくことが多く「AI 活用も既存のセキュリティ統制の枠組みに乗せて運用したい」ニーズがあるようです。

この記事では、そうしたシーンにおける構成パターンの一例として、CData API Server と Azure API Management を組み合わせて「自社が管理するテナント内（オンプレミスネットワーク + 自社Azure サブスクリプション）に閉じた自社統制型のMCP（Model Context Protocol）ゲートウェイを構築する方法」をご紹介します。

記事の背景（自社統制型のMCP ゲートウェイへのニーズ）

総務省の調査によると「生成AI 導入に際しての懸念事項」として他の国々がコストを最も懸念する中、日本においてはセキュリティリスクがより上位に挙がっているのが特徴的です。実際にお客さまからの「AI からのデータアクセスを自社が管理する境界内で完結させたい」というご相談も増えてきました。データ主権（データソブリンティ）、規制要件、既存のセキュリティ統制との整合など、背景はさまざまですが、共通しているのは「AI レイヤーにおいても、自社の管理境界や統制ポリシーに閉じた範囲での運用が最重要であり外せない要件」という点です。

たとえば、すでにMicrosoft Azure を自社のガバナンスポリシーで運用されているお客さまの場合、「AI 推論や、AI のためのデータアクセスゲートウェイも（Azure 以外の）外部SaaS への分散は避けたい」や「既に運用実績のあるセキュリティ統制（ID やアクセス管理・監査・ネットワーク制御）をAI のレイヤーにもそのまま適用したい」などはイメージしやすいニーズです。このようなケースにおいては、AI と業務データをつなぐために「自社管理のテナント内に閉じたMCP ゲートウェイ」を自社テナント内（オンプレミスネットワーク + 自社のガバナンスが効くAzure サブスクリプション）で構築するアプローチが有効な選択肢の1つになるかと思います。この記事では、このような「自社管理のテナント内に閉じたMCP ゲートウェイ」を検討される場面において「自社統制型MCP ゲートウェイを構成するAPI 公開レイヤとしてCData API Server を活用する方法」をご紹介していきます。

なお、オンプレミスネットワークなど「物理的にも論理的に自社で完結する環境」を想定して「セルフホスティング可能なAI ツール + ローカルLLM + CData API Server」の組み合わせを例に「AI データアクセスのAPI 基盤としてCData API Server を活用する方法」も「こちらの記事」でご紹介していますので、あわせてご活用ください。

CData API Server

この記事でご紹介する「CData API Server」は「あらゆるデータソースから完全にドキュメント化されたAPI を作成およびデプロイ」できるサーバーアプリケーションです。外部アプリケーション、Web バックエンド、モバイル、そしてAI エージェントなど、さまざまなクライアントから活用できる、柔軟でカスタマイズ可能なOData 準拠のAPI をノーコードで開発・運用することができます。API の「開発」のみならず、公開から運用・保守にいたるまでの全てのプロセスに必要となる機能を備えています。

CData API Server の主な特徴や機能は以下のとおりです。 API Server ではOData 準拠のREST API とともに、OpenAPI 3.0 形式の仕様を自動生成します。

• 豊富な対応データソース : 270 を超える業務データソース（RDB、SaaS、ファイル系など豊富なデータソース）に対応

• スキーマカスタマイズ : テーブル名・カラム名の別名（エイリアス）、データ型の変換、APIScript による高度なマークアップ

• API ガバナンス : ユーザー単位の認証・レート制限・アクセス制御（メソッド / オブジェクト / IP）・監査ログ

• OData 準拠の標準API : クライアント側のツール選択肢が豊富、自動ドキュメント（OpenAPI 仕様）を提供

この記事のシナリオ

この記事では「自社が管理するテナント」を、「自社のAzure サブスクリプション」と「自社のオンプレミス環境」の双方を包含するものとして整理しています。Azure API Management やAzure OpenAI Service はクラウドサービスですが、論理的な管理や統制は自社のサブスクリプション内に閉じます。つまり、物理的な基盤としてはクラウドサービスを利用しつつ、論理的なリソース所有、ID とアクセス管理、課金、ネットワーク経路の制御は自社のAzure サブスクリプションとポリシーに基づいて管理する、という構成です。なお、この記事ではCData API Server 自身と、API Server でAPI 公開するデータソース群はオンプレミスネットワーク側に構成しています。「論理的に自社で管轄するAzure 側のサービス」と「物理的・論理的に自社で管轄するオンプレミス側に配置したAPI Server とデータソース群」をつなぐネットワーク基盤としてはAzure Relay のHybrid Connection（ハイブリッド接続）を利用しました。

上記の図を整理すると「API Server を通じた、データソース群へのアクセスはオンプレミスネットワーク内に閉じて」おり、「AI 推論やレスポンスは自社のAzure サブスクリプション（Azure OpenAI Service のPrivate Endpoint）に閉じて」いる形になります。それぞれが「閉じた」状態を保ちつつ、Azure Relay のトンネルで橋渡しされる、というイメージです。

この記事のパターンは「自社が管理するテナント内に閉じた形で、社内データソースのAPI 公開層としてCData API Server を利用しつつ、Azure が提供するAI 基盤とAPI 統制層を活用」できる、バランスの取れた構成と言えるかと思います。

この記事のポイントは、Azure API Management のバックエンドとして「社内にあるさまざまなデータソースを"AI から使いやすい標準にそったAPI として公開するレイヤー"にCData API Server を利用する」点です。

API Management 製品 x CData API Server

AI に企業データを使わせる際、AI エージェントから企業の基幹となるデータソース群に直接アクセスさせるのは現実的ではありません。AI エージェントからの直接アクセスは、スキーマの過剰な露出、認可や監査、リソースコストなど多くの課題が生じます。それらを解決するために、AI エージェントからのデータ活用を支える「MCP ゲートウェイ」を設けるアプローチが有効です。この記事では、AI エージェントからのインタフェースとなる「MCP サーバー」は、Azure API Management が提供する機能が担います。

Azure API Management をはじめとしたAPI Management 製品と、CData API Server は、いずれも「API を扱う製品」として同じレイヤに括られがちですが、それぞれの機能性や役割は異なります。この記事の構成でいえば、CData API Server は「データソースからAPI を生成」する「API 公開層」であり、Azure API Management は「用意されたAPI のフロントに立ち認証・監査・流量制限等を提供」する「API 統制層」です。両者は競合関係ではなく、データソースからAI までの経路で相互補完的に協働する関係といえます。

• 公開層（CData API Server）: 270 を超える多様なデータソースから、OData 標準のREST API + OpenAPI 3.0 形式の仕様を公開します。データソースに近い側での統制（認証、レート制限、アクセス制御、API リクエストの監査など）を担い、使いやすいAPI を堅牢に公開する基盤として機能します。

• 統制層（Azure API Management）: 公開層が提供するREST API をMCP サーバーとして公開しつつ、AI クライアント側に対する統制（Entra ID 認証、AI レイヤー向けのレート制限、ツール単位のアクセス制御、Application Insights 連携など）を横断的に提供し、API Server が提供するAPI の利用を統制する基盤として機能します。

エンタープライズ企業の社内データソースはヘテロな（さまざまな種類のデータソースが混合で活用されている）ケースが多く、堅牢なアクセス制御も必要不可欠です。API 生成のツールや技術は複数存在しますが、エンタープライズユースにフィットするAPI 公開層として、CData API Server の機能性は強力です。この記事での役割分担では、データソースに近い側のアクセス制御（どのテーブル・カラム・メソッドにアクセスできるか）はAPI Server が担い、AI クライアント側のアクセス制御（どのAI クライアント・ユーザーがどのツールを呼べるかなど）はAzure API Management が担うことができます。結果として、どちらか一方での制御とくらべ、より堅牢に設計・運用いただけることが期待できます。このような構成は、Azure API Management に限らず、Apigee など他のAPI Management 製品においても有効なアプローチだと思います。

この記事の構成イメージ

この記事では基幹データソースをイメージしたOracle やDB2 for i と、それらのデータソースにアクセスしてAPI を公開するCData API Server はオンプレミスネットワーク側に構成しています。Azure API Management やAzure AI Foundry など、Azure 側のサービスと、オンプレミス側に配置したAPI Server をつなぐネットワーク基盤にはAzure Relay のHybrid Connection（ハイブリッド接続）を利用しましたが、ExpressRoute やSite-to-Site VPN なども構成や要件により選択いただけると思いますので、利用されている環境や要件に合わせてイメージしてください。利用しているAzure 側の各サービス（AI Foundry / Azure OpenAI Service / Azure API Management）は、Private Endpoint やVNet 統合により自社のAzure サブスクリプションのVNet に閉じられるため「データの経路は自社が管理するテナント内で完結」します。

この記事で実際に検証した環境は次のとおりです。

この記事では MCP クライアントとして Azure AI Foundry Agent を利用しましたが、業務シーンによってはMicrosoft Copilot Studio などを利用されるケースもあるかと思います。AI 推論モデルもこの記事では gpt-5.4 を利用しましたが、実際の検討シーンでは要件に応じたモデルを選択してください。API 公開するデータソースについても、CData API Server は Oracle DB やDB2 for i 等の基幹系DBMS から、多様なSaaS やファイルまで、270 を超えるデータソースに対応していますので、それぞれ利用されているデータソースやシステムに応じて読み替えてください。

なお、Azure Relay のHybrid Connection は、オンプレミス側からのHTTPS アウトバウンド接続のみで、Azure 側のサービスからオンプレミス内のサービスを呼び出せるようにするリバースプロキシ的な仕組みです。この「HTTPS アウトバウンドのみで実現するリバーストンネル」というアプローチは、CData Connect AI のConnect Gateway 機能が採用しているモデルと近いものです。CData 製品をご存じの方は、この記事におけるネットワーク構成としては「Azure 側にConnect AI のConnect Gateway に相当するリバーストンネル機能を持たせて、CData API Server をAzure API Management 経由で活用している」と捉えていただくと、イメージしやすいかもしれません。

この記事での認証フローとデータの流れとしては以下のようなイメージです。

Azure API Management x CData API Server での構成パターン

この記事の構成は広い範囲に渡りますので、ここからは各レイヤにおける設定のうちポイントになる部分を見ていきます。

CData API Server 側での事前準備

社内データソースのAPI 公開（API 化）を担うCData API Server の設定です。この記事では、オンプレミス環境にあるOracle Database をCData API Server のデータソースとしました。API Server 側では、ユーザーを作成してAuth Token を発行し、AI に公開するリソース（テーブル、ビュー、ストアドプロシージャ）として必要なものだけを選択してAPI 化しておきます。エンドポイントは http://{host}:{port}/api.rsc/、OpenAPI 仕様は /api.rsc/$oas で取得できます。なお、この記事では、Azure API Management でOpenAPI 仕様のURL からAPI を作成するために、AllowAuthtokenInURL を有効化しています。

オンプレミスにある基幹システム、とくにスクラッチ開発アプリケーションのデータストア等においては、「XXX_MST」という略式的なオブジェクト名や「XXX_CD」や「XXX_FLG」「XXX_DT」などの略式的なカラム名で構成されているケースも多いかと思います。AI エージェントがこれらのメタデータをそのまま取得した場合、略式的な名称しか見えず、「最近の受注実績を教えて」と質問しても、どのカラムが受注日を表すのか判断に困るでしょう。うまく判断に至れる場合も「判断がしにくい」ことによって推論コストが高くつくことは容易に想像がつきます。API Server がサポートする「スキーマのカスタマイズ機能」を利用すると、エンドポイント（テーブル名）を分かりやすい名称に変更したり、カラム名に分かりやすい別名（エイリアス）を設定したり、データ型を明示的に変換したり、と「AI が文脈（Context）を理解しやすい形へ整える」ことができます。この記事でもエイリアスをつけて、AI フレンドリーなエンドポイントとなるように構成しました。

これでオンプレミスデータを、Azure API Management のMCP サーバー機能を通じて AI Foundry から利用するためのAPI 化（API 公開）としては完了です。

Azure Relay とHybrid Connection Manager によるAzure : オンプレミス間接続

Azure Relay とHybrid Connection Manager を利用して、Azure とオンプレミスネットワークをつなぐ部分です。Azure ポータルでAzure Relay の名前空間とHybrid Connection（ハイブリッド接続）を作成し、接続文字列を取得します。

経路としてAzure Relay を利用する場合は、Azure API Management からAzure Relay 経由でオンプレミスにあるAPI Server を呼び出すための中継エンドポイント（プロキシ構成）が必要です。この検証では、Azure API Management から呼び出せるHTTP バックエンドとしてAzure Relay 経由の中継エンドポイントをAzure App Service のWeb アプリ（シンプルなリバースプロキシ実装）を用意する形で構成しました。Azure Relay ではそれを経由して、Hybrid Connection Manager を通じ、オンプレミスの API Server に到達するイメージです。

[Program.cs]

[appsettings.json]

オンプレミス側にHybrid Connection Manager をインストールして、取得しておいた接続文字列を設定すると、HCM がオンプレミス側から Azure Relay へ常時 HTTPS のリバーストンネルを張ります。

Entra ID アプリ登録

AI クライアント側の認証に関する部分です。Azure API Management がJWT トークンを検証するとき「このトークンはMCP ゲートウェイ向けに発行されたものか」を確認できるよう、Entra ID 上にアプリ登録します（mcp-gateway という名前で登録しました）。そのEntra ID アプリで定義したApp Role を、AI クライアントになるFoundry Agent のサービスプリンシパルに割り当てることで、認証チェーンが成立するイメージです。

Azure API Management のデプロイとポリシー設定

CData API Server が公開するAPI を統制して、AI エージェントにMCP サーバーとしてのインタフェースを提供するのが、この記事におけるAzure API Management の役割です。この記事では検証用として、API Management リソースはDeveloper SKU を利用しました。VNet 統合で構成し、運用・監査の観点からApplication Insights との連携も同時に有効化しています。Azure API Management のデプロイには少し（わたしが検証した時はおおむね30分程度）時間が掛かりますが、デプロイが完了すると通知が届きました。

API Management のバックエンドには、Azure Relay 経由のCData API Server を登録します。

API Management にCData API Server が生成するOpenAPI 仕様を取り込み、API Management 上で統制するAPI 操作として定義します。

API Management 側のポリシーでは、Entra ID トークンの検証やset-header によるAPI Server 用Auth Token の付与（名前付きの値で構成）を構成します。本番運用ではこのレイヤでAI クライアント向けのレート制限やクォータ設定、ツール単位のアクセス制御なども構成することができます。

最後に「MCP サーバー」機能で「API をMCP サーバーとして公開」します。API Server のOpenAPI 定義から取り込んだ、API Management 上のAPI 操作を「MCP プロトコルのツール」としてAI クライアントに公開します。

なお、この記事の時点でAzure API Management の「API をMCP サーバーとして公開する」機能は、API の操作をMCP ツールとして公開する機能です。MCP リソースやプロンプトはサポートされていない点には留意が必要です。

Azure AI Foundry Agent からの接続

AI クライアントとなる、Azure AI Foundry でプロジェクトを作成し、Azure OpenAI Service と接続します。この記事ではモデルにgpt-5.4 を利用しました。

Agent のツールとしてAPI Management が公開するMCP エンドポイントを登録すると、MCP tools/list 経由で、API Management 上の操作がAgent から認識できるようになります。

手順（Instructions）に業務の文脈や、典型的な絞り込み例などを記述しておくと、ユーザーの自然言語入力からAgent が生成するリクエスト（MCP ツールの引数）の精度を高めることができます。これらの引数はAPI Management の内部でOData クエリパラメータに変換され、CData API Server へと転送されます。

動作イメージ

ここまでのポイントを含めて各レイヤの構成が整うと、Foundry Agent から自然言語で問い合わせた内容が、API Management に統制された形で、Azure Relay を経由して、CData API Server が公開する基幹データソースへ接続するAPI に到達するようになります。プレイグラウンドで試してみると、MCP ツールとして利用できる状況などが確認できました。

なお、Azure API Management では、Application Insights やLog Analytics との連携を有効化することでリクエストログやメトリクス、エラー情報などをシームレスに収集できます。AI からのアクセスは通常の業務アプリケーションと比べてクエリパターンの予測が難しい面がありますが、このような点は監査・コンプライアンス対応の観点でも安心感のある運用につながります。ほかにも、AI クライアント向けのレート制限やクォータ設定、ルーティングなど、自社の要件に応じた制御を柔軟に組めるも統制層としてAzure API Management を利用する魅力の1 つかも知れません。

Azure API Management x CData API Server -「自社統制型MCP ゲートウェイ」の価値

「AI 推論もデータもアクセストークンも、自社が管理するテナント内で完結したい」場合に、Azure API Management x CData API Server の組み合わせで「自社統制型MCP ゲートウェイ」として利用する価値は「こちらの記事」と同じく、Connectivity / Context / Control の3つの観点で整理することができます。

• Connectivity（接続性）: MCP ゲートウェイでAPI 公開層をCData API Server が担い、Oracle やDB2 for i などを筆頭に270 を超えるエンタープライズユースのデータソースへのアクセスを、OData 標準のREST API + OpenAPI 仕様として提供します。

• Context（文脈）: CData API Server の豊富なスキーマカスタマイズ機能により、AI フレンドリーなエンドポイントを提供できるため、LLM の推論精度が上がり、ツール定義もシンプルになります。

• Control（統制）: API 公開を担うCData API Server がデータソースに近い認証・公開範囲・監査を担い、API 統制を担うAzure API Management がEntra ID 認証・AI クライアント向けの流量制御やアクセス制御・監査をポリシーとして集約します。

MCP ゲートウェイを構成するAPI 基盤を、API の公開層とAPI の統制層を分離することで、それぞれが独立した責務を持ち、独立して進化・改善できる点も、この構成パターンの価値の1つかも知れません。

CData API Server は単純なREST API ではなく、OData に準拠したAPI をOpenAPI 仕様とともに自動的に生成します。これにより、さまざまなAPI Management 製品で、API Server が提供するAPI を活用することができます。この記事では、AI クライアント向けのインタフェースとしてMCP（Model Context Protocol）を主軸において紹介してきましたが、Azure AI Foundry Agent やMicrosoft Copilot Studio など、最近のAI エージェント基盤では OpenAPI 3.0 仕様をそのままツール定義として取り込めるものも増えてきていると思います。MCP は多くのAI クライアントがサポ－トしており、仕様として急速に発展を続けていますが、OpenAPI 3.0 は枯れた仕様ですので、現時点において安定運用しやすい点は魅力かも知れません。いずれにおいても、CData API Server が提供する「標準にしたがった使いやすいAPI の公開」と「堅牢なAPI 運用」が、AI からの社内データ活用において価値を発揮することをイメージいただけたのではないかと思います。

まとめ

この記事では、CData API Server と Azure API Management を組み合わせて、自社が管理するテナント内（オンプレミスネットワークと自社のAzure サブスクリプション）に閉じた「自社統制型のMCP ゲートウェイ」を構成する方法についてご紹介しました。

この記事を通じて、Azure API Management をはじめとしたAPI Management 製品と、CData API Server が相互補完的に協働する関係にあるのもイメージいただけたのではないかと思います。

この記事では、Azure を利用されているシーンを想定して、Azure API Management との組み合わせを例にご紹介しましたが、他のプラットフォームやAPI Management 製品でも考え方としては同じ役割分担でガバナンスを組み上げていただけると思います。そういった意味では、既存のAPI Management 投資が活きる構成とも言えるでしょう。また、API 生成のツールや技術は他にも存在しますが、エンタープライズユースにフィットするAPI 公開層として、CData API Server の機能性は強力です。270 を超えるデータソースをサポートし、ヘテロ（異種混合）な社内データソース群を「OData 標準API + OpenAPI 仕様 + エンタープライズクラスの運用性」で扱える点は、他では代替が難しい価値かと思います。

CData API Server は、AI エージェントはもちろん、ビジネスアプリケーションやWeb システムのバックエンドなど豊富なツールから利用できるOData 準拠のAPI をノーコードで開発・運用できるAPI 基盤です。使いやすく堅牢なAPI を提供するAPI Server は、業種業界を問わず幅広く活用いただけます。ぜひ、[CData API Server](https://jp.cdata.com/apiserver/) を試してみてください。

製品を試していただく中で何かご不明な点があれば、テクニカルサポートへお気軽にお問い合わせください。

この記事では CData APIServer™ 2026 - 26.1.9595.0 を利用しています