LiteLLMは、アプリケーションとLLM（大規模言語モデル）のあいだを橋渡しするオープンソースのLLM Gatewayです。MITライセンスで公開されていて、100以上のモデルプロバイダーへの接続を1つのOpenAI互換エンドポイントにまとめられます。DockerやKubernetesへのデプロイ自体は手早く済み、Netflix・NASA・Ramp・Oktaといった企業での導入実績もあります。LLMの基盤ツールとしてはコントリビューターの活動が特に活発なプロジェクトの1つで、モデル側のゲートウェイとして完成度の高い製品です。

CData Connect AIが担うのは、それとは別の層です。AI GatewayとMCP Gatewayを組み合わせたマネージドプラットフォームで、モデルプロバイダー間の振り分けではなく、AIエージェントが業務データにどう届くかを統制します。対象はkintone・Salesforce・Oracle・ServiceNow・各種SQLデータベースなど数百種類の業務システムです。

土台には、CDataが15年にわたって築いてきたデータ接続の基盤があります。両ゲートウェイの背後では、「自動学習するコンテキストエンジン」（限定提供）が、データの意味づけをセマンティックマップとして保持しています。対象は、項目の意味・データソース同士の結合方法・ARRなどの指標の定義です。エージェントはスキーマを総当たりせずにこのコンテキストを先に検索し、訂正や新たな接続が加わるたびに精度が上がっていきます。

整理すると、LiteLLMが扱うのは「AIからモデルへの接続」で、Connect AIが扱うのは「AIから社内データへの接続」です。M365 CopilotやClaudeといった既製のAIクライアントから、Model Context Protocol（MCP）経由で社内データを参照する構成を検討している方も多いのではないでしょうか。その構成で稟議の論点になるのは、モデルの切り替えよりも、エージェントが誰の権限で社内データを読むかです。

この記事では両者の得意分野と限界を順に見たうえで、自社の課題がどちらの層にあるのか、あるいは両方を組み合わせるべきかを判断する材料をお渡しします。

MCPとMCPゲートウェイは何をする？

MCP（Model Context Protocol）とは、AIクライアントが社内のデータやツールを呼び出すための共通の接続規格です。MCPゲートウェイは、その呼び出しの入口に立つ仕組みです。どのツールを誰に使わせるかという権限と、誰が何をしたかという監査をまとめて管理します。

MCPに対応したAIクライアントは、MCPサーバーが公開する「ツール」を呼び出して、検索・参照・更新といった操作を行います。社内にMCPサーバーが増えてくると、接続先ごとに認証情報（クレデンシャル）や権限を設定する手間が膨らみます。そこで入口を1つにまとめ、権限と監査を一元化する層としてMCPゲートウェイが置かれるようになりました。接続方式を選ぶ際の評価軸とセキュリティ項目は、組織でのMCP導入・接続方式の選び方にまとめています。

LiteLLMとConnect AIはどちらも「MCPゲートウェイ機能を持つ」と説明されます。ただし、2つが担う範囲は異なります。LiteLLMはゲートウェイとして入口で呼び出し元を確認し、認証情報を中継します。個人のIDがデータソースまで届くかどうかは、その先のMCPサーバーの実装に委ねられます。Connect AIはデータソースへのコネクタとクエリ実行の層まで自前で持つため、個人のIDをデータソースまで運ぶ役割を自分で担います。この「個人のIDをデータソースまで運ぶ責任を誰が持つか」が、以降の比較の中心になります。MCPゲートウェイと従来のAPI Gatewayで入口の役割がどう変わるかは、API GatewayとMCP Gateway：特徴と選定基準を解説で整理しています。

ひと目でわかる比較表

CData Connect AIの機能は提供状況が分かれているため、表では「提供中」「限定提供」「予定」を書き分けています。

LiteLLMは何が得意？

LiteLLMが得意なのは、多数のLLMプロバイダーを1つのOpenAI互換インターフェースにまとめ、トークンの追跡・レート制限・予算管理まで面倒を見ることです。MITライセンスでGitHubに公開されています。各サービスがプロバイダーごとのSDKに個別に依存しなくて済むようになり、すべてのモデル呼び出しのコストと稼働状況を1か所で把握できます。LLMゲートウェイの基本やモデルコストの管理方法から確認したい場合は、LLM GatewayとAPI/AI Gatewayの違いを解説した記事が参考になります。

複数のLLMを直接呼ぶと何が困る？

アプリケーションから各社のLLMを直接呼び出す構成では、モデルが増えるほど次のような負担が積み上がります。

• 呼び出しのコードがプロバイダーごとのSDKに分かれ、実装が分散する

• モデルを切り替えるたびにアプリケーションの改修が必要になる

• モデルごとの利用料が別々の請求に散らばり、全体のコストが見えにくい

• 各社のAPIキーが複数のサービスに配られ、管理と失効の手間が増える

LiteLLMはこれらをモデル側の入口を1つにまとめることで解消します。一方、エージェントが社内データにどう届くかという問題はこの入口の外に残ります。モデル側の層はLiteLLM、社内データ側の層はConnect AIという2層で考えると、以降の比較が整理しやすくなります。

運用面の準備も整っています。Dockerコンテナで配布され、KubernetesにはHelmチャートで展開できます（EKS・GKE・AKSの手順が公開済み）。2026年9月時点でGitHubのスター数は約58,000、コミット数は46,000を超えており、開発が止まる心配はまずないでしょう。

ルーティングの選択肢も豊富です。レイテンシー基準・コスト基準・使用量基準での振り分けに加え、会話を同じプロバイダーに固定するセッションアフィニティや、プロバイダーグループをまたぐフォールバックにも対応します。2026年7月のv1.94.0で登場したAuto-Router v2では、独自のルーティングロジックをプラグインとして追加できるようになりました。

トークン予算とレート制限は、キー・ユーザー・チーム・組織の単位で上限を設定でき、超えた時点で止められます。可観測性の連携先もLangfuse・Langsmith・Datadog・OpenTelemetry・Honeycombなど20種類以上あります。プロバイダー横断のコストとレイテンシーを自前で作らずに見たい開発チームにとっては、実用的な機能です。

OSS版はRedis・Qdrant・Valkeyを使ったセマンティックキャッシュにも対応しています。ただしLiteLLM自身のドキュメントによれば、この機能は単発のプロンプトを前提にしています。複数ターンの会話やエージェントの処理では古い応答を返してしまうことがあるため、長時間動くエージェントの前段に置く場合は注意が必要です。有償のEnterprise版では、こうしたOSSの機能にSSO・RBAC・監査ログが加わります。

業務で使うとLiteLLMに何が足りない？

業務データを扱うエージェントの基盤として見ると、LiteLLMには3つの課題があります。個人のIDをデータソースまで運ぶ役割をMCPサーバーに委ねていること、業務システムへの接続機能を持たないこと、そしてSSOや監査ログが有償版に限られることです。

個人のIDをデータソースまで運ぶ責任は、MCPサーバー側に残ります。LiteLLMはv1.80.18でMCPゲートウェイ機能を追加しました（MCPプロトコルのバージョンは2025-11-25）。AIクライアントからの要求を上流のMCPサーバーへ転送するプロキシとして動き、既定の構成では通信の段階で認証情報を差し込み、ツールにはサーバーごとの名前空間を付けます。アクセスは仮想キー・チーム・組織の単位でゲートウェイ側から制御できます。

LiteLLMには、クライアント側の認証情報をMCPサーバーへ転送する構成（true_passthrough・oauth_delegate）もあります。ただし、その先のデータソースに呼び出した個人のIDが届くかどうかは、MCPサーバーがその認証情報をどう扱うかで決まります。LiteLLMにはデータソースへのコネクタがなく、行レベルのセキュリティや項目単位の権限、データソース側のロールベースのアクセス制御（RBAC）を適用する層も持ちません。既定の構成（仮想キー＋サービスアカウント）では、データソースから見えるのはサービスアカウントで、要求を出した個人ではありません。たとえばその構成でLiteLLMのMCPプロキシ経由でSalesforceを読むエージェントは、依頼した本人に見る権限があるかどうかに関係なく、サービスアカウントが見られるデータをすべて見られます。セキュリティ審査で最初に確認される点の1つです。

業務システムへの接続機能はありません。LiteLLMが扱うのはAIの通信です。Salesforceのコネクタ・Oracleへのブリッジ・JDBCやODBCの層のいずれも持たないため、業務システムをリアルタイムに照会する接続がありません。ドキュメントには、データ接続と誤解されやすい連携が2つあります。

1. Snowflakeプロバイダーは、プロンプトをSnowflake CortexのLLMに送るための推論エンドポイントです。データを照会する層ではなく、Snowflakeのテーブルは読みません。

2. Scalekitのチュートリアルに出てくるSalesforceとの「連携」は、エージェントのツール呼び出しで使うOAuthの認証情報を第三者のサービスに委ねる仕組みです。LiteLLMがSalesforceのコネクタを提供しているわけではありません。

CRM・ERP・データウェアハウス・オンプレミスのシステムをエージェントに読ませたいなら、そのアクセスを担うのはLiteLLMではなく別の層です。

SSO・RBAC・監査ログには有償ライセンスが必要です。OSS版にも仮想キーと基本的なロールはあります。しかしSSO・企業向けのRBAC・改ざんできない監査ログは、いずれも年間契約で個別見積もりの有償版の機能です。SSOはOkta・Microsoft Entra ID・SAML 2.0に対応しており、v1.95.0で追加されました。有償版を使わない場合、共有キーで済ませるか、LiteLLMの外にSSOの仕組みを自前で用意することになりがちです。

CData Connect AIは何を提供する？

CData Connect AIは、MCPを土台にしたマネージドのAIゲートウェイです。AIエージェントと業務システムのあいだに入り、Salesforce・Oracle・ServiceNow・NetSuite・各種SQLデータベースなど数百種類のデータソースへ、データを移動・複製せずにリアルタイムでアクセスさせます。アクセスにはガバナンスが効きます。LiteLLMがアプリケーションとモデルプロバイダーのあいだの通信を扱うのに対し、Connect AIが扱うのは業務データへの接続です。エージェントが業務で使えるよう、データとそのコンテキストをAIにつなぎます。

Connect AIは、CDataのデータ接続基盤の上に載るゲートウェイの層で、個人のIDを踏まえたMCPのガバナンス・業務用語の意味を扱うセマンティックコンテキストの層・規制の厳しい業界を想定した統制機能を加えています。実際に、ヘルスケア分野の専門商社の導入事例では、CDataのMCP Serverを通じて社内の膨大な商品マスタをLLMで自動分類し、開発なしで市場特性に基づく分析を実現しています。

提供状況は機能によって異なります。MCP Gatewayは現在提供中です。AI Gateway・Context Engine・Policy Engineは限定提供の段階にあります。検討の際は、必要な機能がどちらに当たるかを先に確認しておくと手戻りを防げます。

MCPの権限管理はどう違う？

違いは、個人のIDをデータソースまで運ぶ責任を、どの層が持つかです。LiteLLMはゲートウェイとして呼び出し元を確認し、認証情報を中継するところまでを担います。その先のMCPサーバーとデータソースへ個人のIDが届くかどうかは、MCPサーバーの実装に委ねられます。Connect AIはコネクタとクエリ実行の層まで自前で持つため、呼び出した個人のIDをデータソースへ届ける役割を自分で担います。

LiteLLMのMCPゲートウェイは、既定の構成では認証情報をゲートウェイの段階で差し込みます。エージェントは仮想キーでLiteLLMに認証し、MCPサーバー用の認証情報はLiteLLMが保持します。クライアント側の認証情報をMCPサーバーへ転送する構成（true_passthrough・oauth_delegate）もv1.93.0で追加されています。ただし、これは認証情報を転送する仕組みであり、データソースに個人のIDを届ける仕組みではありません。届くかどうかは、受け取ったMCPサーバーがその認証情報を使ってデータソースに問い合わせる実装になっているかに左右されます。開発者向けのツールや社内の自動化のように、サービスアカウントの権限がちょうどよい範囲であれば、既定の構成で問題なく動きます。接続先が少なく、個人単位の認証に対応したMCPサーバーを用意できる場合は、LiteLLMの転送構成だけで足りることもあります。行き詰まるのは、多数のデータソースにまたがってデータソース側のRBACを守らなければならない場面です。MCPサーバーごとに、個人のIDが届くかどうかを実装し、検証する必要があるからです。

CData Connect AIは、データソースへのコネクタとクエリ実行の層を自前で持ち、パススルーID（呼び出した個人のIDをそのままデータソースに渡す方式）を採っています。ゲートウェイは要求ごとに呼び出した本人を特定し、接続先のシステムそれぞれでその人の権限を適用します。営業担当者に代わってエージェントがSalesforceを照会すれば、Connect AIはその担当者として要求を送り、担当者は自分に権限のある範囲だけを見ます。同じエージェントに上長が同じ質問をすれば、より広い結果が返ります。アクセス制御を実施するのはデータソース自身なので、ゲートウェイ側に権限設定を二重に持つ必要はありません。

これに加えて、信頼レベルの上限（Low・Medium・High）という2段目の統制があります。ログインのときだけでなく、ツールを呼び出すたびに確認される点が特徴です。

• Low：読み取りのみ

• Medium：作成と更新も許可

• High：削除などの破壊的な操作も許可

各ツールは機能に応じて自動的にいずれかのレベルに分類され、管理者がツールごとに上書きできます。審査では「誰の権限で動くか」「何ができるか」「記録を本人までたどれるか」の3点が問われます。この2段の統制は、前の2点に対応します。記録の面は、比較表のとおり監査ログが対応しています。MCPをインフラの段階で安全に運用する方法は、安全なMCPサーバーの構成を扱った記事で詳しく解説しています。MCPの導入形態を広く比べたい場合は、MCPゲートウェイと統合型MCPプラットフォームの比較もあわせてご覧ください。

国内の社内システムやオンプレにもつながる？

Connect AIは数百種類のデータソースに対応しており、クラウドから直接届かないシステムにはオンプレミスエージェントを使って接続します。オンプレミスエージェントを使えば、ファイアウォールの内側にある閉じたネットワークのシステムにも、受信用のポートを開けずに到達できます。

国内企業でエージェントに読ませたいデータは、海外の事例とは顔ぶれが少し異なります。SaaSとして広く使われているkintone、部門ごとに管理されているExcelファイル、文書が集まるSharePointがまず挙がります。営業管理のSalesforceや、基幹系のSAP・Oracleも候補になります。日々の商談でお客様から伺う話を踏まえても、AI活用の検討は「既存の社内システムにつながるか」という問いから始まることが少なくありません。

ここで挙げたのは接続先の例です。お使いのシステムが対応コネクタに含まれるかどうかと、パススルーIDによる個人権限の適用が使えるかどうかは、接続先ごとに異なります。ドキュメントで確認するか、CDataにお問い合わせください。データを社外に一切出せない要件がある場合は、CDataのデータ接続ドライバー（ODBC・JDBC・ADO.NETなど）を完全にオンプレミスで動かし、データの移動を自社のインフラ内に閉じる選択肢もあります。

LiteLLMは業務データにつながる？

前述のとおり、LiteLLM単体では業務データにつながりません。LLMプロキシが中継するのは、アプリケーションからモデルのAPIへの要求です。SalesforceやSnowflake、OracleのERP、オンプレミスのSAP、SharePointにどんなデータがあるかは、プロキシの扱う範囲に入っていません。多くのAIゲートウェイ比較が触れていないのもこの点です。ここからは、Connect AIの位置づけと、ウェアハウス側のゲートウェイとの違いを見ていきます。

Connect AIはスタックの別の位置にいます。複製を使わずに数百種類の業務データソースへリアルタイムに届く接続の層が土台です。Salesforceと、SQL Serverにある財務データベースをまたぐ質問をエージェントが受けると、Connect AIは照会の時点で両システムを結合します。結果を返す前に、それぞれのアクセス制御も適用します。モデルが受け取るのは、権限を通して整えられたデータセットです。複数のデータソースの生のテーブルを渡されて、モデル自身が突き合わせに頭を悩ませる必要はありません。

ウェアハウス側でもMCPへの対応が進んでいます。2026年にはSnowflakeとDatabricksがそれぞれMCPゲートウェイの機能を発表しました。Snowflakeは7月28日のBlack Hatで、Databricksは6月のData + AI Summitでの発表です。どちらも外部のMCPサーバーを中継し、その上にガバナンスを加えます。

ただし統制が最も強く効くのは、それぞれの基盤にすでにあるデータです。Snowflakeのゲートウェイは自社のデータに、Databricksのゲートウェイはレイクハウスに強みがあります。基盤の外にある2つのシステムで「顧客」の定義をそろえる用途や、ウェアハウスと並んで動く業務システム全体への到達は、主な守備範囲ではないと考えられます。データがSnowflakeやDatabricksに集約されているチームなら、基盤に組み込まれたガバナンスで足りる場合もあるでしょう。一方でSalesforce・Oracle・ServiceNow・NetSuiteなど多くのシステムをウェアハウスと並行して動かしているなら、それだけでは足りません。

Context Engineは何を解決する？

Context Engineは、エージェントが業務用語を毎回ゼロから解釈し直す問題を解決します。ステートレスなゲートウェイは、要求のたびに何も覚えていない状態から始まります。エージェントは「エンタープライズセグメント」が何を指すかを毎回推測し、自社の期がいつ始まるかを知らず、財務チームが本当に信頼している数字がSalesforceのどの項目にあるかもわかりません。CData Connect AIのContext Engineはこうした意味を保存し、エージェントが毎回探し直さなくて済むようにします。なお、Context Engineは現在限定提供の機能です。コンテキストが欠けたゲートウェイがなぜ誤答を招くのかは、AI Gatewayに足りない3つのコンテキストで設計面から解説しています。

限定提供で使える機能

Connect AIは、すでに使われているツールから既存のセマンティックモデルを取り込みます。取り込み元はdbt・Power BI・Microsoft Fabric・Snowflake・Databricks・LookMLです。分析チームが「売上」や「エンタープライズセグメント」をすでに定義していれば、その定義がそのままConnect AIに引き継がれ、エージェントは分析担当者と同じ意味で用語を解釈します。エージェントの答えとダッシュボードの数字が食い違うという、現場でよく聞く不信感を減らせるはずです。

取り込んだ定義の上に、複数のシステムをまたいで1つのモデルとして照会できるクロスソースの仮想スキーマとセマンティックビューも定義できます。CRM・請求システム・サポート基盤を結合した「アクティブな顧客」のような概念を、パイプラインを作らずに1つのエンティティとして扱えます。セマンティックレイヤーをまだ持っていないチームには、データソースのメタデータとサンプルデータを分析して定義案を提示します。

2026年第4四半期に予定されている機能

エージェントの利用状況から語彙と訂正を学習する機能と、利用者をまたいで組織の知識を共有する機能が予定されています。学習の積み重ねを個々のセッションではなくエージェントより下の層に蓄える設計です。

運用・セキュリティ審査ではどう違う？

大きな違いは、運用を誰が担うかです。LiteLLMは常にセルフホストで、運用の責任は自社にあります。Connect AIはマネージドサービスで、閉じたネットワークのシステムにはオンプレミスエージェントで届きます。

LiteLLMを本番で動かすには、次の3つを自社で抱えることになります。

• キャッシュとレート制限に使うRedisのクラスター

• 利用ログを記録するPostgreSQLのデータベース

• その両方を健全に保つインフラ

コミュニティ版にSLAはありません。Enterprise版のライセンスでサポートが付き、運用上のリスクはある程度下がりますが、デプロイの保守は引き続き自社の仕事です。

立ち上げにかかる時間にも差があります。LiteLLMはDockerイメージの取得こそすぐ終わりますが、Redis・PostgreSQL・各プロバイダーのキー・最初のルーティングルールを設定するまでに、数時間から1日ほどかかるのが一般的です。Connect AIはサインアップしてデータソースを接続すれば、数分でMCPエンドポイントが設定され、照会できる状態になります。用意するインフラも管理するクラスターもありません。MCP経由のガバナンス付きデータアクセスが自社の用途に合うかを評価したい開発者にとって、この差は小さくないでしょう。MCPの導入パターンとベストプラクティスは、MCPサーバーの導入を扱った記事にまとめています。

認証・データの所在。CData Connect AIはSOC 2 Type IIとISO 27001の認証を取得しています。データの所在地を制御する機能や、データを保持しない方針のプロバイダーへ振り分ける機能も備えています。LiteLLM側の認証状況は、同社の公開情報で確認してください。審査に向けてMCPのガバナンス項目を洗い出す際は、エンタープライズMCPガバナンス完全ガイドも役立ちます。

海外拠点がある場合の参考：EU AI法。EU AI法では、利用者がAIと対話していることの開示を求める第50条の透明性義務が2026年8月2日に適用されました。高リスクAIに関する規定の本格適用は2027年12月2日からです。EU域内で規制対象のデータにMCPツールを使うエージェントは対象になりうるため、操作ごとの記録と人による監督は、後付けではなく設計段階から組み込んでおく必要があります。

サプライチェーン。2026年3月、TeamPCPと呼ばれる攻撃キャンペーンでLiteLLMのPyPIパッケージが侵害されました。2,500を超える組織の約43万4,000のCI/CDパイプラインが影響を受けたとされ、問題はすでに特定・対処されています。マネージド型であれば、パッケージを更新する接続はベンダー側の管理されたリリース手順と公開されたセキュリティ証明のもとに置かれます。各チームの更新管理に頼らずに済む点は、審査で比較される論点の1つになるでしょう。

LiteLLMが向いているのはどんなとき？

主な課題が、モデル側の通信におけるLLMのルーティングとコスト管理にあるなら、LiteLLMが適しています。具体的には次のような場合です。

1. 多数のプロバイダーを1つのOpenAI互換インターフェースで扱い、それを自社で運用したい

2. アプリケーションが扱うデータはプロンプト内で完結し、業務システムをリアルタイムに照会しない

3. 接続先のデータソースが少なく、呼び出した個人の認証情報を扱えるMCPサーバーを自社で用意・検証できる

4. アプリケーションのコードを変えずに100以上のプロバイダーを使い分けられる、モデルの柔軟性を最優先したい

5. マネージドのSLAよりも、デプロイを完全に自社で制御できることを重視する

6. ガバナンスはスタックの別の層で担っており、ルーティングの層は軽く保ちたい

LiteLLMを選んだ場合でも、社内データへの接続は別に用意できます。たとえば、アプリケーションやエージェントからのモデル呼び出しはLiteLLMの単一エンドポイントに集め、kintoneやSalesforce、社内データベースへのアクセスはConnect AIのMCPエンドポイント経由にする構成です。閉じたネットワークのシステムにはオンプレミスエージェントで届くため、モデル接続とデータ接続を役割で分けて併用できます。

Connect AIが向いているのはどんなとき？

モデルの振り分けだけでなく、ガバナンス付きのデータアクセスまでが課題に含まれるなら、Connect AIが適しています。具体的には次のような場合です。

1. CRM・ERP・データベース・SaaS・オンプレミスのシステムに、エージェントがガバナンス付きでリアルタイムにアクセスする必要がある

2. 監査とIDを個人までたどれる必要があり、データソース側のRBACを守るためのMCPサーバーごとの実装と検証の負担を避けたい

3. MCPのガバナンスを、仮想キーの単位だけでなくツール呼び出しの単位の信頼レベルで効かせたい

4. SSO・SCIM（System for Cross-domain Identity Management）によるプロビジョニング・RBACが、情報システム部門やセキュリティ部門の必須要件になっている（各機能の提供状況は導入前にご確認ください）

5. 社内のセキュリティ審査で、アクセス権の範囲・操作ログ・データの所在を説明する必要がある

6. エージェントによる業務システムへの書き戻しを見据えており、それを安全に行うガバナンスの基盤が必要

LiteLLMとConnect AI、どちらから始める？

主な必要性ごとに、最初に検討する製品を整理しました。モデル接続の課題はLiteLLM、データ接続の課題はConnect AIが受け持ち、両方の課題があれば併用も選択肢になります。

個人の権限で社内データにAIをつなぐ

CData Connect AIのMCP Gatewayは現在提供中です。データソースを接続し、お使いのMCPクライアントをゲートウェイのエンドポイントに向けるだけで、モデルが動く前にどのデータが誰の権限で解決されるかを確かめられます。まずは自社の業務データで、パススルーIDと信頼レベルの統制を試してみてください。

無料トライアルを始める

よくある質問