10年前、私はある「作り直し」を最前列で見ていました。企業が拠点間をつなぐ高価な専用線を外し、その通信をインターネットに移していった時期です。通信の中央には新しい技術が導入され、パケットごとに行き先と許される操作、かかるコストを統制できるようになりました。ネットワーク業界はこれをSD-WAN（Software Defined Wide Area Network）と呼んでいます。

私はCiscoで7年間、この移行にさまざまな立場で関わりました。どの企業でも関心があるトピックは同じでした。最初に出るのはコストの話です。次はセキュリティ。社員が誰も想定していなかった使い方を始めたからです。そして最後に、中央に入った制御の層がネットワーク業界でも有数の大事業になりました。新しい技術（SD-WAN）を、責任を持って安全かつ効率的に使いこなす手段を企業に与えたからです。

それを可能にしたのは見える化です。すべての通信を1つのゲートウェイに通したことで、何がどこへ送信され、いくらかかっているかが見えるようになりました。処理を可視化できれば、何を許可して何を止めるか、何を最適化してどのように速く届けるかを決められます。制御は見える化のあとからついてきます。これは昔から変わりません。

いま、私はこれによく似た映画をもう一度観ています。ネットワークの通信を「AIモデルに送られるプロンプト」に、インターネットで通信を行うアプリケーションを「企業のシステムに入り込むAIエージェント」に置き換えてみてください。企業の課題は同じ3つで、その順番まで同じです。コストをどう最適化するか、どう安全に進めるか、そして主導権を握るのは誰か、という問いです。

ただし、AIにはSD-WANになかった前提が1つあります。ゲートウェイの先にあるデータから正しい答えが返ってこなければ、どれだけ見えていても制御する意味がない、という点です。本日、私たちはConnect AI Gatewayを発表します。お客様から繰り返し問い合わせをいただいてきた「AIのコストが膨らむ」「答えが業務で使える精度に届かない」「AIに検索はさせても実行は任せられない」という3つの課題を、データとつながる層（データレイヤー）でまとめて解決するためのものです。ここからは、それが何なのか、なぜCDataが作るべきなのか、そしてこの先どこへ向かうのかをお話しします。

CDataがゲートウェイを作るのはなぜ？

CDataは、製品を単独で作ってきた会社ではありません。いつもお客様と一緒に作ってきました。数十年にわたり、それは業務データが実際に置かれているシステムへのリアルタイム接続を意味していました。SAP、Workday、NetSuite、Salesforce、データウェアハウスやデータベースなど、数百のデータソースです。kintoneのような国内で広く使われるSaaSやオンプレミスの基幹システムもこれに当たります。この接続性（コネクティビティ）は他社が製品を作る土台になり、いまではSalesforce、Google、Palantirの製品の中でも活用されています。

お客様がこのデータ接続を使ってAIを動かし始めると、同じ接続をMCP経由で使いたいという声が上がりました。そこで私たちはマネージドMCPプラットフォームを作りました。システムごとにMCPサーバーを手作りするのではなく、認証・権限・監査を1か所で扱える仕組みです。すでに自前のMCPサーバーを運用しているというお客様には、それらも同じガバナンスの下に置けるようにしました。

そして最近は、お客様と話すたびに冒頭で触れた3つの課題を耳にします。1つ目は、AIのコストが誰の見込みよりも速く膨らんでいることです。2つ目は、答えがそのまま行動に移せるほど信頼できないことです。3つ目は、ガバナンスがAIに検索はさせても実行はさせられない作りになっていることです。

3つの課題の根っこには、欠けている層が1つあります。それがゲートウェイです。お客様のAI変革（AX）に伴走することは、私たちにとって販売戦略ではなく企業文化であり使命です。Anaqua社はその好例です。同社は、業務システム間にまたがるデータへAIツールがユーザー単位で統制されたアクセスを行えるコントロールプレーンを構築しました。その過程で「統制されている」とは何を意味すべきかを、私たちに厳しく問い続けてくれました。

Connect AI Gatewayは何をする？

Connect AI Gatewayは、エージェントと社員、モデルとデータの間に入ります。モデル向けのゲートウェイとMCP向けのゲートウェイを1か所にまとめ、ルーティング、ガードレール、可観測性、ポリシーエンジンを備えています。人とエージェントのID（アイデンティティ）は、リクエストの入口から出口まで途切れずに引き継がれます。現在は早期アクセスのお申し込みを受け付けている段階です。AI Gatewayそのものの役割やAPI Gatewayとの違いから整理したい方は、AI Gatewayとは？コストと権限を一元管理するための仕組みも参考になります。

正直に言えば、これらは単体で見れば珍しい機能ではありません。大事なのは、それが何の上に作られているかです。

正しい答えはどこで決まる？

答えの正しさは、データとつながる部分で決まります。接続性はAI Gatewayの機能の1つではなく、そのゲートウェイを信頼できるかどうかを決めるものだからです。私たちは、生のレコードを山ほどモデルに渡して、計算はうまくやってくれと祈るようなことはしません。データソース側のシステムのスキーマ・リレーション・検証ルールを理解したうえで、答えをデータレイヤーで計算し、最終的な答えだけをモデルに返します。

CData Labsは、この差を数字で確かめました。CRM・プロジェクト管理・データウェアハウス・ERPにまたがる実業務で使用するプロンプト378件を、5種類のMCP接続方式で実行した検証です。CData Connect AI経由の正答率は98.5%で、他の方式は65〜75%にとどまりました。

5ステップの処理を任せるエージェントにとって、この差は決定的です。1ステップあたりの正答率が75%なら、5ステップすべてを正しく終えられるのは4分の1に届きません（0.75の5乗はおよそ24%）。ホワイトペーパーとテストハーネスは公開していますので自社のデータで試してみてください。MCPサーバーの設計によって精度がどう変わるかは、MCPサーバーの設計を実証比較した記事で詳しく解説しています。

安いモデルでも同じ答えは出せる？

データレイヤーがビジネスロジックを担っていれば、安価なモデルでも正しい答えを出せます。AI Gatewayの売り文句は「簡単なプロンプトは安いモデルに回そう」で、それに対して決まって返ってくる反論は「それでは精度も安全性も落ちるのでは」です。CData Labsはこの点も検証しました。エコノミーモデルから最上位のフロンティアモデルまで22モデルを使い、CRM・データウェアハウス・ITサービス管理のリアルタイムデータに対して1,034回実行しています。

データレイヤーがビジネスロジックを担った場合、エコノミーモデルは、検証対象の中で最も高価なフロンティアモデル（Fable 5）と同じ正しい答えを、178分の1のトークンコストで返しました。データレイヤーがない場合は、最も優秀なモデルでも正答率は40%でした。

精度と安全性をデータレイヤーで担保すれば、モデル選びはほぼコストの判断に変わります。さらにゲートウェイはレコード一式ではなく答えにあたるデータだけを返すため、モデルが読むコンテキストは97.6%減ります。トークンが減り、再試行が減り、往復の回数も減ります。答えは安くなるだけでなく、速く返ってきます。

エージェントの操作は誰の名前で残る？

エージェントは、使っているユーザー本人と同じ権限だけで動きます。その権限はデータソース側のシステムの中で、レコード単位まで強制されます。リクエストには1件ごとに委任されたIDが付き、エージェントは名前のある特定のユーザーの代理として動きます。誰が使ったのか追えない共有のサービスアカウントで動くことはありません。アクセス制御をどう層に分けて考えるかは、Connect AIの5層アクセス制御モデルで紹介しています。

書き込みは、確定する前にそのシステム自身のビジネスルールで検証されます。前述の22モデルの検証では、統制されたツール経由の場合、22モデル中20モデルが正しいレコードだけを書き込みました。一方、生データを直接扱わせた場合は、最悪のケースで数千件の誤った値が書き込まれています。

すべての答えは、その背後にあるプロンプト・モデル・ツール・レコード・ポリシーまでさかのぼれます。稟議やセキュリティ審査で「誰が、どの権限で、何を実行したのか」を問われても、記録をもとに答えられるということです。支出もチーム・エージェント・モデル・ツール別に把握できます。だからこそ、AIの取り組みに上限をかけて抑え込むのではなく、成果を見て予算を投じる判断ができるようになります。成果をどう測るかについては、AI Gatewayの成果測定を3層フレームワークで整理した記事が手がかりになります。

コンテキストはどこに蓄積する？

ゲートウェイを通るプロンプトには、その会社が自分たちの業務をどう表現しているかという情報が少しずつ含まれています（なぜコンテキストの欠落が誤答につながるのかは、AI Gatewayに足りない3つのコンテキストで解説しています）。「売上」と言ったときにどの項目を指すのか。Salesforceの顧客とNetSuiteの顧客がどう対応するのか。日本の現場なら、kintoneアプリの取引先と、基幹システムの得意先マスタ、Excelの管理表にある顧客名がどう結びつくのか、といった話です。

コンテキストエンジンは、こうした情報を集めます。出発点は、リアルタイム接続がすでに把握している情報です。そこに、これまで整備してきたセマンティック定義を取り込み、SOP（標準作業手順書）やチャットのやり取り、社員の頭の中にある暗黙知を加えていきます。

どの機能よりも重要な設計判断が2つあります。1つはコンテキストをデータのコピーではなく、稼働中のシステムの上に構築することです。もう1つは、蓄積した記憶をモデルの側ではなくCDataのデータレイヤーに置くことです。そのため、エージェントが学んだことはどのモデル・どのクラウド・どのデータストアに移っても一緒に持っていけます。コンテキストの構築をモデルやクラウド、データストアの提供元に任せる選択肢もありますが、その場合は蓄積したコンテキストが提供元の環境に紐づき、乗り換えのたびに作り直すことになりがちです。一度作れば、あとは自由に選べます。それが私たちの設計です。

この1年で何が変わる？

これは私個人の予測ではありません。CDataは自社のAI変革をかなり進めており、以下は自社での利用とお客様の現場の両方で見えてきているニーズです。チームはすでに、それに向けた開発を進めています。

• ルーティングは賢くなります。いまは人が質問するケースが中心ですが、来年はエージェントが複数ステップのワークフローを実行するのが当たり前になるでしょう。ルーティングはステップごとに、コストだけでなく意図とコンテキストにもとづいて、モデル・ツール・データの経路を選ぶようになります。

• ガバナンスは自然になります。コードとしてのポリシー（Policy as Code）はすでに実現しています。次に来るのは、自然言語としてのポリシーです。

• コンテキストは業務とより密接に対応し、共有されるようになります。ただし、選び分けながらです。あるチームがエンジンに教えた内容の一部は組織全体の共通認識になり、一部はあえてそのチームの中にとどめます。

• エコシステムは広がります。セキュリティ、ID管理、可観測性で優れた仕組みを持つリーダー企業の機能を、私たちが作り直すことはしません。市場をリードする企業とのセキュリティ分野の提携をすでに進めており、さらなる提携も検討しています。

そしてゲートウェイは、そこを通過するものから学び続けます。私が最も期待している部分であり、同時に最も言い過ぎたくない部分でもあります。大きな声で語るのは、実際に動いているところをお見せしてからにします。

AI変革を一緒に進めるには？

私がこれまで経験したプラットフォームの転換には、どれも避けて通れない経営課題が伴っていました。モバイルへの対応を迫られた時期がありました。SaaSへの移行を迫られた時期もありました。そしていまはAI変革です。いくつかのAPIをMCPで包んで、あとはエージェントを好きに走らせるという計画なら、うまくはいかないでしょう。

企業に必要なのは、データに深く根ざし、その道のりに、正確さ・効率・安全性を両立させながら責任を持って伴走するパートナーです。それこそ私たちが数十年にわたり、お客様と共に、お客様のために、一層ずつ積み上げてきたことです。ゲートウェイは、その次の一層です。

実際の課題をぶつけて私たちをここまで連れてきてくれたAnaqua社とすべてのお客様、そしてそれを製品に仕上げたCDataのチームに感謝します。AI変革をこれから考えている方、始めたばかりの方、まさに取り組んでいる最中の方で、コスト・精度・速度・統制のどれかに悩んでいるなら、ぜひ意見を交換させてください。

Connect AI Gatewayについてよくある質問

AIに任せる前に、データレイヤーから整えませんか

答えの精度も、権限も、監査証跡も、AIがデータに触れる層で決まります。まずは自社の業務データで、どこまで正しい答えが返るかを確かめるところから始めてみてください。早期アクセスはjp.cdata.com/aiで受け付けています。