企業のAIアーキテクトは今、5年前には存在しなかったシステムを設計しています。質問に答え、ワークフローを実行し、自律的に動く——それも数十の業務データソースを横断しながら、ガバナンスを保ち、コストを抑え、正確に。これはモデルやデータパイプラインの問題ではなく、インフラの問題です。

企業のAI活用がこの先スケールするか、それとも止まってしまうか。今、アーキテクトやIT部門のリーダーが下す判断こそが、その分かれ目になります。

ここでの核心的な判断は、大きく2つに分かれます。一つは、データソースごとにネイティブなMCP（Model Context Protocol）を内製し、アクセスとコントロールの基盤を整える道です。もう一つは、対象となる全データソースを横断して、マネージドMCPプラットフォームに外注する道です。この判断を左右する要因は、大きく3つ——求められるデータのコントロール・コンテキスト・接続性のレベル、非決定的・決定的・自律的という3種類のワークフローを同時に支える必要性、そしてトークン消費を抑えなければならないプレッシャーの強さです。

データソースごとのネイティブMCPで構築するアプローチは、一見シンプルで魅力的に見えるかもしれません。しかし実際に進めると、無視できないコストとトレードオフがすぐに表面化します。結果として、多くの企業AIアーキテクトやIT部門のリーダーは、中央管理されたMCPサーバーのアプローチへとたどり着くことになります。この記事ではまず、AIアーキテクトが担うべきインフラの目的を整理します。そのうえで、内製か外注かという意思決定のポイントを詳しく見ていき、根本的に異なる2つのアプローチの検討事項とトレードオフを解説します。MCPサーバーそのものの仕組みや構築・運用の実務をより広い視点で押さえておきたい方は、MCPサーバー構築・運用ガイドもあわせてご覧ください。

企業AIアーキテクトが果たすべきミッションとは？

企業がAIを活用するためのデータインフラ要件は、複雑に絡み合いながらも同時にすべて満たさなければならない条件の集合体です。スケーラブルな企業インフラを設計するにあたり、AIアーキテクトが両立させるべき核心的な目的は6つあります。

1. 幅広く、内容の濃い業務データソースへ、LLMに制御されたアクセスを提供する。 AIがビジネスにもたらす価値は、実際の業務データ——Salesforceのレコード、NetSuiteの財務データ、Jiraのチケット、BambooHRのプロフィール、Zendeskのケースなど——にどれだけアクセスできるかに比例します。しかもこうしたデータは、クラウドアプリケーション・独自のデータソース・オンプレミスのネットワークドライブに散らばっていることが多くあります。LLMがアクセスできれば、そのすべてに大きな価値が眠っています。すでに広く指摘されている通り、こうしたデータにアクセスできないモデルは一般論しか答えられません。一方、アクセスできるモデルは、具体性・一貫性・信頼性を実現します。

2. 完全なコントロール、監査可能性、強制力のあるガバナンスを実現する。 システムを横断して質問したりアクションを起こしたりできるのは、アクセスされ返されるデータがガバナンスされている場合に限られます。具体的にはアクセス制御、ポリシーの適用、監査ログ、そして「どのデータに」「誰が」「どれだけのコストで」触れたかを可視化することです。Gartnerの2025年AI倫理・ガバナンス・コンプライアンス調査によれば、自社のAIガバナンスに自信を持っているIT部門のリーダーは25%未満にとどまります。このギャップは現場でも表れています。69%の企業では、従業員が禁止されている生成AIツールを使ったり、データをスプレッドシートにコピーしたり、許可されていないAIシステムにアップロードしたりしているのです。

3. 非決定的・決定的・自律的なワークフローを、まとめて支える。 企業のAI活用は一枚岩ではありません。あるユースケースでは発見的な探索が重視され、精度を犠牲にすることなく予測不能な問い合わせに対応できる柔軟なアーキテクチャが求められます。その対極にあるのが決定的なワークフローです。こちらは本質的に予測可能・再現可能である一方、データソース内でのより深いアクセスとガバナンスが必要になります。さらに自律型エージェントの展開では、オープンエンドな探索力とビジネスルールへの理解の両方が健全な形で求められます。そのぶん、ガバナンス・コントロール・監査可能性のレベルもさらに高くなります。企業は日常的にAIの自律性における3つのモードすべてを必要としています。それぞれを同時に支えるアーキテクチャを用意しなければなりません。

4. 事業部門の「市民開発者」を前提に設計する。 AIの活用を求める各事業部門（BU）からの要望は、日々「このアイデアはどうか」という形でIT部門に押し寄せています。すべての要望に個別対応する負担を抱え込む必要はありません。AIアーキテクトやIT部門のリーダーは、事業部門自身がツールを自信を持って使いこなせる仕組みを設計すべきです。新しいユースケースのたびに中央のIT部門が関与する必要があるシステムでは、対応待ちの案件が際限なく積み上がってしまいます。理想的なインフラとは、コントロールとガバナンスは中央で維持しながら、構築自体は事業部門に委ねられる仕組みです。

5. LLMのコストとトークンのROIを管理する。 トークン消費には実質的なコストがかかり、しかもそのコストは急速に増加しています。未分析の生データセットをそのままモデルに送って要約させるのは、本来SQLクエリが数分の一のコストで用意できたはずの答えを、高くついた方法で得ているにすぎません。アーキテクトには、分析処理をデータソース側で済ませ、モデルが本当に必要とするコンテキストだけを返せる仕組みが必要です。

6. 何よりも正確さを担保する。 間違った答えを素早く返すことは、答えを返さないことよりも悪い結果を招きます。ガバナンスされた企業環境では、不正確なAIの回答は時間を無駄にするだけでなく、誤った情報にもとづく判断を後工程に連鎖させてしまいます。正確さは「あれば嬉しい」機能ではなく、他のすべての目的が成立するための前提条件です。そして複数ステップのワークフローやエージェントシステムが稼働し始めると、こうした不正確さは積み重なっていきます。たとえば5ステップのワークフローで各ステップの精度が業界平均の75%だとすると、最終的にすべて正しく完了するプロセスはわずか24%にとどまります。

このミッションを実現する2つの方法：内製か、外注か？

企業のAIデータインフラをまだ検討中のAIアーキテクトは、たいてい2つの選択肢を比較検討しています。

方法1：マネージドMCPプラットフォームに外注する。
マネージドMCPプラットフォームとは、あらかじめ用意されたコネクタとコントロールのセットを使って、業務データソースをMCPサーバー経由で選択したAIクライアントやモデルに公開する仕組みです。独自のコネクタ開発やデータパイプラインの構築、継続的なメンテナンスは必要ありません。スキーマの解決、セマンティックコンテキスト、アクセス制御、クエリの最適化、監査ログの記録を、単一の設定レイヤーから数百のデータソースにわたって処理します。AIツールやエージェント、自動化の仕組みは、個々のデータソースにではなく、ガバナンスされたセマンティックリッチなデータレイヤーに接続することになります。実際にどのベンダーのマネージドMCPプラットフォームを検討すべきかは、主要MCPベンダー7社の比較で特徴を整理していますので、選定の参考にしてください。

方法2：シングルソースMCPで内製する。
レガシーなSaaSベンダーがMCP標準を本格的に採用するまでには時間がかかりました。しかしSalesforceやAtlassianのような主要プロバイダーは、自社のネイティブなデータソース向けにMCPサーバーの提供を始めています。こうしたデータソースネイティブなMCPは、そのデータとAIクライアントを1対1で接続するものです。データソースごとの連携がそれぞれ個別のプロジェクトとなり、実装と保守が必要になります。あるいは、MCPサーバーを完全に自社開発する企業もあります。この場合、ガバナンス・アクセス制御・セマンティックな理解は、データレイヤーではなくアプリケーションレイヤーで管理することになります。そのぶん、追加のオーバーヘッドやツールが必要になりがちです。たとえば、データソースごとに個別構築したMCPを使って複数データソースにまたがるAIアプリケーションを実現しようとする場合を考えてみましょう。MCPゲートウェイやセマンティック検索レイヤーといった追加のツールを、自前で設計・実装・運用しなければなりません。

どちらのアプローチも、単独で見れば機能します。しかし実際の判断は、企業レベルでのいくつかの要因とトレードオフに左右されます。それを以下で詳しく見ていきましょう。

内製か外注かを分ける3つの軸とは？

マネージドMCPプラットフォームと、内製のシングルソースMCPとの違いは、構築を始めた時点では必ずしも見えてきません。シングルソースMCPには通常、直接的な価格タグは付いていません。しかしコストは別の形ですぐに表面化し、トレードオフが明らかになっていきます。ここからはコンテキスト・コントロール・接続性という3つの視点から、このトレードオフを見ていきます。コンテキスト（必要なデータを過不足なく効率的に取り込むこと）、コントロール（データアクセスと、人間またはエージェントによる操作をガバナンスすること）、そして接続性（対象のデータソースへ一貫してリアルタイムに、安全にアクセスすること）です。MCPの設計パターン自体をさらに掘り下げたい場合は、MCPの設計パターンと選定指針の解説も判断材料になります。

3つの軸で並べてみると、両者の違いは次のように整理できます。初期コストの差よりも、運用フェーズで積み上がる差のほうが大きいのが実情です。

コンテキスト

マルチソースのセマンティック連携 vs. シングルソースのデータパイプライン。 ネイティブMCPのアプローチは、一度に1つのデータソースを、そのデータソース固有の意味構造のまま公開します。一方フェデレーション型のプラットフォームは、すべてのデータソースを一貫したセマンティックモデルに正規化したうえで、まとめて公開します。営業アナリストがSalesforce・NetSuite・BambooHRにまたがる質問を投げかけたとしましょう。フェデレーション型のアプローチなら、システムごとに微妙に異なる（しかし放っておくと話がずれてしまう）用語の違いを踏まえたうえで、一貫した答えを返せます。この例では横断する対象が3つあり、それぞれにMCPを内製するなら実装も保守も3件分に増えます。横断するデータソースが3つ以上になるなら、マネージドプラットフォームを選ぶほうが現実的です。ネイティブなアプローチでは、あらかじめ用意したパイプラインか、あるいはスキーマの不一致をモデル自身に解決させるしかありません。これは信頼できる前提とは言えず、後述の通りコストのかかる選択肢になります。

ツール呼び出し：データソース由来のツール vs. 統一されたツールレイヤー。 ネイティブMCPでは、データソースのベンダーが公開を選んだツールしか、モデルに渡すことができません。CData Connect AIのようなマネージドプラットフォームなら、データソース固有のツールに加えて、データソースを横断した統一ツールを提供します。さらに、自社のワークフローに合わせたカスタムツールを追加することもできます。AIの能力がベンダー任せで決まるのか、それとも自社の意向も反映できるのか——ここが分かれ目です。

スキーマ、メタデータ、権限、リネージ——単なる生データ以上のもの。 AIモデルは、扱っているデータの中身だけでなく構造まで理解することで、より良く、より効率的な判断を下せるようになります。マネージドMCPプラットフォームは、行や列そのものに加えて、接続されたすべてのデータソースにわたるデータスキーマ、フィールドレベルのメタデータ、関連性のコンテキスト、権限構造までを提供します。

非決定的・決定的・自律的なワークフローを、まとめて支える。 先述の通り、理想的なAI基盤の設計は、この3つのワークフローモードすべてを支えるものです。データソースネイティブなMCPサーバーは、通常そのデータソースのシステム内に閉じた決定的なユースケースで最も力を発揮します。しかし、他の2つのモードを意味のある形で支えるための外部接続性とガバナンスのコントロールには欠けています。システム間の接続を橋渡しし、データをセマンティックに連携・正規化し、アクセスと操作の権限を中央で一元管理する。こうすることで、マネージドMCPサーバーは3つのモードすべてを同時に適切に支えるアクセス・コントロールの基盤を提供します。

コントロール

プラットフォームレベルのロールベースアクセス制御に、データソース由来の権限を重ねる。 ネイティブMCPは、認証済みユーザーやサービスアカウントの権限をそのまま引き継ぐことがあります。これは出発点としては悪くありませんが、ガバナンスのモデルとしては不完全です。マネージドプラットフォームなら、データソースのシステムを変更することなく、追加のコントロールを重ねて適用できます。具体的には、ロールベースアクセス制御（RBAC）、属性ベースアクセス制御（ABAC）、行レベルのポリシー、個人情報（PII）に対する列マスキングなどです。

データレイヤーでのポリシー適用。 規制の厳しい業界や機微な情報を扱う業界の多くでは、PIIのマスキング、データレジデンシーの要件、フィールドレベルの秘匿化を、データがモデルに届く前に済ませておく必要があります。こうしたポリシーをプロンプトやアプリケーションレイヤーで適用するのは脆く、一貫性を欠き、エンドユーザー契約に違反する可能性もあります。データアクセスのレイヤーで適用するほうが、信頼性が高く監査もしやすい方法です。こうしたガバナンス要件を体系的に整理したい方は、エンタープライズMCPガバナンス完全ガイドも参考にしてください。

読み取りと書き込みで異なるエージェントコントロール。 データソースのシステムに書き込みを行うエージェント型ワークフローには、読み取り専用のクエリとは異なるガバナンスが必要です。マネージドプラットフォームなら、エージェントごと、データソースごと、ワークフローごとに書き込み権限をスコープ化できます。あらかじめ定めたしきい値を超える書き込み操作には、人による確認を必須にすることもできます。内製のアプローチでは、こうしたロジックを各エージェントのコード内に持たせて管理し、手作業で見張り続ける必要があります。

スタック全体にわたる監査ログ。 ネイティブMCPの監査ログは通常、ツール呼び出しの記録にとどまります。マネージドMCPサーバーなら、データクエリ、ユーザーやユースケースごとのトークン消費量、ユーザーおよびエージェントのID、ポリシー判断の記録を、すべて一箇所でまとめて記録できます。

エージェントのアクセス用サービスアカウント。 人間のユーザーはIDプロバイダー経由で認証しますが、エージェントはサービスアカウント経由で認証します。この2つを、それぞれ別のガバナンスコントロールを持つ第一級のアクセスパターンとして扱えるプラットフォームこそが、エージェント型AIのために作られたものと言えます。ネイティブMCPに多く見られるような、人間のアクセスにしか対応していない仕組みは、そうではありません。

接続性

シングルソース vs. マルチソースの接続性。 「Salesforceで製品Xの未成約の商談をすべて探す」のように、1つのデータソースだけで完結するユースケースもあります。しかし問い合わせやエージェント型のワークフローは、複数のデータソース、複数のクラウドやオンプレミス環境を、次々と横断して接続することを求められるケースが増えています。シングルソースMCPは、その定義上、通常はクラウドベースのアプリケーション内に閉じた1対1の関係しか提供できません。マネージドMCPプラットフォームなら、ホスティング環境を問わずデータソースを横断した接続性を提供します。

データソース側でのトークンコスト最適化。 マネージドMCPの分析処理をデータソース側で実行すれば——Connect AI独自のセマンティックSQLレイヤーが要約済みの結果を返す形であれば——モデルは生データの塊ではなく、的確にチューニングされた答えを受け取ることになります。1万行のデータセットをそのままモデルに送って要約させるのは、SQLがすでに計算済みの3行の要約を送るのに比べて、トークンコストが大幅にかさみます。企業規模では、これはトークン消費とレイテンシーの両面で無視できないトレードオフになります。

メタデータと関連性のコンテキスト。 「過去30日間動きのない未成約の商談はどれか」という問いに答えるには、Salesforce内の商談レコード・活動レコード・タイムスタンプの関連性を理解する必要があり、単にテーブルから行を取得するだけでは足りません。データソースを理解したコネクタはこうした関連性を把握しており、セマンティックレイヤーはそれをデータソースを横断して連携させます。

MCPの長期的なメンテナンス。 ネイティブMCPサーバーは、データソースのベンダー側がメンテナンスを担います。SalesforceがMCPのエンドポイントを変更したり、NetSuiteがAPIを更新したり、Zendeskがツールを廃止したりするたびに、それぞれの接続が個別に壊れます。自社で構築した仕組みでは、すべてのデータソースにわたるメンテナンスを、各ベンダーのタイムラインに合わせてチームの誰か（多くの場合はチームまるごと）が担うことになります。マネージドプラットフォームなら、このメンテナンスを引き受けてくれます。接続や認証トークンは、プラットフォーム側が常に最新の状態に保ってくれるからです。

LLMとベンダーからの中立性。 特定のSaaSベンダーやLLMプロバイダーと強く結びついた仕組みは、モデルを取り巻く状況が変化したときに高くつくロックインを生みます。そしてこの2年間、モデルの状況は繰り返し変化しており、その勢いが弱まる気配はありません。モデルに依存しないMCPプラットフォームであれば、データレイヤーを作り直すことなく、ユースケースに応じて適切なモデルへクエリを振り分けたり、プロバイダーを切り替えたりできます。

CData Connect AIは3つの軸にどう応える？

CDataのConnect AIは、企業のAIデータインフラが接続性・コンテキスト・コントロールの3つを同時に満たさなければならないという認識のもとに作られています。この3つのうちどれか1つでも弱ければ、精度は損なわれてしまいます。自律的な推論モードにおいては、誰かが介入する前に不正確さがそのまま結果に影響します。

CDataのState of AI Connectivity Reportによれば、企業のテクノロジーリーダーはAIのデータ連携における優先事項として、リアルタイムの接続性42%、セマンティックデータレイヤー34%、ガバナンスとリネージ60%を挙げています。この3つの優先事項は、そのまま接続性・コンテキスト・コントロールに対応しています。つまり、現場の担当者が実際に感じているギャップは、マネージドMCPサーバーのアプローチによって埋められるギャップと同じものだと言えるでしょう。そしてそのギャップは、ネイティブMCPによる構築だけではしばしば埋まらないままなのです。

コンテキストと精度について。 Connect AIは、モデルが動く前にスキーマ・構造・関連性を解決したセマンティックレイヤーを提供します。モデルはフィールドの意味や2つのオブジェクトの関係を推測する必要がなく、あらかじめ教えられている状態になります。その結果として、回答精度の測定可能な向上、レイテンシーの低減、トークン効率の大幅な改善が直接もたらされます。これが企業規模での精度にどうつながるかの詳細な分析は、CDataのAI精度に関するホワイトペーパーにまとめています。

コントロールとセキュリティについて。 Connect AIはプラットフォームレイヤーで、アクセスポリシー、RBAC、PIIマスキング、監査ログを適用します。同時に、各データソースアプリケーションからユーザーおよびサービスアカウントの権限をそのまま引き継いで適用します。どのモデル・エージェント・インターフェースからのリクエストであっても、ガバナンスは変わらず維持されます。このコントロールレイヤーの詳細は、CDataのセキュリティベストプラクティスガイドにまとめています。

接続性とメンテナンスについて。 Connect AIは、カスタムフィールドやカスタムオブジェクト、複雑なリレーショナル構造まで含め、SaaSアプリケーション、データベース、オンプレミスシステム、クラウドプラットフォームにまたがる400種類以上の業務データソースへの接続を提供します。そのメンテナンスも、Connect AI側が引き受けます。コネクタライブラリの全リストはcdata.com/driversでご確認いただけます。

この基盤が実際に動く様子は、Microsoftとの共催ウェビナー「AIエージェントとデジタルワークの未来」でご覧いただけます。複数の業務システムを横断して動作する、実際のオーダー・トゥ・キャッシュエージェントのデモも含まれています。

基盤を作り直さないために、今何をすべきか？

判断に迷ったときは、次の4つの条件で切り分けてみてください。2つ目以降のどれかに当てはまるなら、マネージドMCPプラットフォームを前提に設計したほうが安全です。

• 接続対象のデータソースが1つだけで、用途も決定的なワークフローに限られる——シングルソースMCPの内製で足ります。

• 横断するデータソースが3つ以上ある、または今後12か月で増える見込みがある——データソースごとの実装と保守が積み上がるため、マネージドプラットフォームを選んでください。

• 書き込みを伴う自律型エージェントを1つ以上、本番環境に載せる予定がある——読み取りと書き込みを分けたガバナンスが必要になるため、プラットフォームレイヤーでの制御が前提になります。

• MCPの保守に専任で1人月以上を継続的に割ける体制がない——ベンダー側のAPI変更に追従できなくなるため、メンテナンスを引き受けてもらう前提で設計してください。

実際にこの判断を通った例があります。試薬や工業薬品を扱う国内の専門商社では、300社超のメーカーからそれぞれ独自のカテゴリ体系で届く5,100万件超の商品マスタを分析するために、基幹システムのHCL DominoとLLMをつなぐ必要がありました。ここで自作やコミュニティ版のMCPサーバーを使わなかった理由は3つです。REST APIの仕様差異をSQLインターフェースで抽象化してハルシネーションのリスクを避けられること、サーバー内で集計を済ませて不要なトークン消費を抑えられること、そしてSOC 2 Type II認定を含むセキュリティ基準を満たしていること。この記事で挙げたコンテキスト・コントロール・接続性の3軸が、そのまま選定理由になっています（専門商社での導入事例）。

シングルソースMCPサーバーは、企業レベルで使えるAI基盤を構築する道として、一見魅力的に見えます。プロトタイピングの段階では確かに適していることもあります。しかし、意味のある、スケールする企業AIの価値を生み出すためには、接続性の広さ、コンテキストの深さ、ガバナンスとコントロールの度合いが欠かせません。データソースネイティブなMCPによる構築は、その基準を満たせず、たいてい本番環境に到達する前で止まってしまう。

中央管理されたMCPプラットフォームに投資することで、AIアーキテクトや企業のIT部門のリーダーは、今を機能させながら将来にも備えることができます。このアプローチを採用すれば、ガバナンスされ、フェデレーションされ、セマンティックを理解した1つのデータレイヤーを、ビジネスに提供できます。AIは、あらゆるワークフロー、あらゆる自律性のレベルで、そのレイヤーの上で直接動けるようになります。新しいユースケースが登場するたびに、基盤を作り直す必要はありません。既存のシングルソースMCPからマネージドプラットフォームへ実際に移行を進める際の具体的なステップは、MCP移行を成功させる8つのステップで解説しています。

これこそが、AIのアクセス・コントロール基盤の本質です。そしてこれをどう構築するかという判断は、後から作り直そうとすると本当に難しく、コストもかかる、数少ない設計判断のひとつです。

よくある質問

MCPをソースごとに増やさず、一元管理する基盤へ

ソースごとにMCPを増やすたび、権限管理とスキーマ差異の吸収が積み重なります。CData Connect AIならセマンティックレイヤーで一元管理できます。

Connect AIの無料トライアルを今すぐ開始して、自社のデータソースを数分でセマンティックレイヤーに接続できるか確かめてみてください。