Google DeepMind でAI Developer Experience を担当するPhilip Schmid 氏が、モデルコンテキストプロトコル（MCP）サーバー構築の1ヶ月間を振り返った投稿「One Month in MCP」（reddit.com、x.com）が話題になっています。この投稿では、実際の開発で直面した課題や見えてきたパターンが率直に語られており、ツール拡張型エージェントに取り組む開発者コミュニティで活発な議論を呼び起こしました。この投稿を読んで印象的だったのは、Philip 氏が指摘した課題の多くに、CData のアプローチがすでに対応できていたことです。
CData では2025年5月1日に最初のMCP Servers をリリースしており、ローカル環境向けのインストール型MCP Servers（stdio：標準入出力ベース）と、クラウド環境向けのCData Connect AI（ストリーミングHTTP ベース）の両方を提供しています。Philip 氏の指摘を読みながら、私たちは何度もうなずいていました。彼が挙げた課題は、私たちが製品開発の初期段階で直面したトレードオフそのものだったからです。そして、彼の考察は、私たちがMCP 製品を成熟させる過程で下してきたアーキテクチャ上の判断が正しかったことを裏付けてくれました。
本記事では、個人での実験段階からチーム全体で使える本格的なツール環境へとスケールアップする方法について、CData の経験に基づいた実践的な知見を共有します。
stdio は最初は便利だが、すぐに限界が訪れる
Philip 氏が指摘するように、stdio はシンプルでわかりやすい仕組みです。ローカル環境での開発やデバッグには最適で、すぐに始められるのが魅力です。だからこそ、CData のインストール型MCP Servers でもstdio をデフォルトで採用しています。
ただし、stdio には明確な限界があります。「新しい機能を作る時間」よりも「プロセスを再起動したり、状態を同期したりする時間」の方が長くなってきたら、それはレベルアップのサインです。実際、長時間稼働するワークフローや、複数エージェント間の連携、クラウド環境でのアクセスが必要になると、リモート接続の方がはるかに安定して快適に動作します。
CData Connect AI では、ストリーミングHTTP 経由でリモートMCP Server を提供しています。面倒な手動セットアップは不要で、プロセス管理に煩わされることなく、本来の目的である「ツールの活用」に集中できます。
ローカルファーストからリモートMCP へ
個人プロジェクトであれば、ローカル環境のセットアップで十分です。しかし、チームメンバーとツールを共有したり、複数の環境で作業したり、より多くのユーザーに対応する必要が出てくると、ローカルファーストのアプローチでは限界が見えてきます。
Connect AI は、初めからリモート環境を前提に設計されています。ユーザーは共有MCP ツールに瞬時にアクセスでます。Git からクローンする必要も、パッケージをインストールする必要もなく、API キーが漏洩する心配もありません。バージョン管理され、厳選されたセキュアなクラウドホスト型ツールが、認証された状態ですぐに使え、チームでのコラボレーションをすぐに始められます。
すべてのMCP Servers で共通のツールセット
Philip 氏は、ツール間の衝突や命名規則の不統一という重要な課題を指摘しています。CData では、これに対して独自のアプローチを採用しました。すべてのMCP Servers が、CData のドライバーやConnect AI と同じSQL ベースの抽象化レイヤーに基づいた、統一されたツールセットを提供しています。
このアプローチの利点は、多くのLLM がデータベース操作を前提に学習されているため、自然な形でデータにアクセスできることです。また、ローカル環境（stdio）でもリモート環境（HTTP）でも、同じツールが使えるため、環境の違いを意識する必要がありません：
queryData：接続先のデータソースにSQL クエリを実行して結果を取得。
execData：getProcedures で検出したストアドプロシージャを実行して、データソースに対してアクションを実行。
getCatalogs：CData Connect AI で利用可能な接続先のリストを取得。各接続が他のツールやクエリでカタログとして機能。
getSchemas：特定の接続先（カタログ）で利用可能なAPI やデータモデルのリストを取得。
getTables：特定のAPI やモデル内で利用可能なオブジェクト、エンティティ、またはコレクションのリストを取得。
getColumns：指定されたテーブル、オブジェクト、コレクションのフィールド、ディメンション、またはメジャーのリストを取得。
getProcedures：E メール送信、課題ステータス変更、ファイルダウンロードなど、特定のAPI やモデルで利用可能なアクション（ストアドプロシージャ）のリストを取得。
このツールの標準化により、動作の予測がしやすくなり、混乱も減り、モデルや環境をまたいでスケールできるワークフローを構築しやすくなります。
ツールフィルタリングでアクセスをスケールする
「ツールが多すぎる」「コンテキストが膨大すぎる」—Philip 氏が指摘するように、これは深刻なボトルネックです。
Connect AI では、エージェントごとにツールをフィルタリングする機能を提供しています。これにより、各LLM エージェントに公開するツールを選別でき、より多くのユーザーやエージェントにスケールしながらも、オーバーロードを防いでパフォーマンスを維持できます。さらに、検索ベースの手法やカスタムツールの開発も進めており、より使いやすいツール環境の実現を目指しています。
データ駆動型のスキーマ設計
CData MCP では、特定のLLM に合わせてスキーマをカスタマイズするのではなく、CData のドライバーやクラウドベースのアナリティクスコネクタで実績のあるスキーマ生成ロジックをそのまま活用しています。つまり、各ツールの構造は、モデルの都合ではなく、実際のデータソースの構造に基づいて決まります。
この方針により、ユーザーには明確で一貫性のある操作性を提供できます。ただし、開発者の皆様には、ChatGPT、Claude、オープンソースLLM など、複数のモデルでツールの動作を確認することをお勧めします。モデルによって互換性が異なる場合があるためです。
CData MCP Servers でスケーリングをはじめましょう
Philip 氏の投稿は、MCP エコシステムの現在地を確認するための素晴らしい指標となっています。そこから得られる教訓は明確です。stdio への過度な依存を避け、リモートファーストのアクセスに移行し、ツールセットを適切にキュレーションし、スキーマの複雑さがモデルの動作にどのような影響を与える可能性があるかを理解することです。
CData では、これらの課題を解決するために、オンプレミス向けのMCP Servers とConnect AI を設計しました。ローカル環境でツールを試したい場合も、チームをまたいでエージェントをオーケストレーションしたい場合も、CData のコネクティビティはお客様のニーズに合わせてスケールできます。
CData Connect AI でリモートMCP 機能をご体感いただくか、ローカルMCP Server をダウンロードしてぜひお試しください。MCP の可能性をCData とともに広げていきましょう！
※本記事はCData US ブログ From Local Experimentation to Team-Ready Deployments in the MCP Ecosystem の翻訳です。
