データサイロからツールの相互運用性へ：MCPの位置づけ
孤立したシステムに閉じ込められたデータは、人類が知識を保存し共有しようとした歴史の中で常に人々を悩ませてきました。ソフトウェアが登場するずっと前でも、知識は特定の都市、図書館、機関、政治制度の中に閉じ込められることが多かったのです。
今日でもこの問題は残っています。貴重な情報は存在しますが、異なるシステム間でアクセス、接続、利用することが困難です。その結果、以下のような課題が生じます：
- 効率の低下：人々は情報を単に取得する代わりに、会議で情報を探したり尋ねたりするのに時間を浪費してしまいます。
- 意思決定の障害：意思決定がサイロ化されたデータに基づいて行われます。
- 自動化の複雑化：ワークフローが脆弱な統合、手作業の回避策、または不完全なデータに依存している場合。
データサイロとは？
IBMによると、データサイロは「異なる部門、システム、事業部間でのデータ共有を妨げる孤立したデータの集合体」です。
組織内では、部門ごとに独自のツールを使用することが多く、時間がかかるかエラーが発生しやすい回避策なしに他のチームとデータを直接共有することは困難です。
ここに現実世界の例があります。
データサイロの例：マーケティング、営業、カスタマーサポート
企業は、マーケティングキャンペーンにHubSpotを使用し、営業パイプラインにSalesforceを使用し、カスタマーサポートにZendeskを使用することがあります。
それぞれのシステムには貴重な顧客情報が含まれていますが、その情報は分断されたままです。
マーケティングはキャンペーンのエンゲージメントを確認し、営業チームは取引状況と収益を確認し、サポートは苦情やチケットを確認しますが、誰も全体像を把握していません。
これは実際の問題を引き起こす可能性があります。営業は、顧客が最近いくつかのサポートチケットを開いていたことを知らずに連絡してしまうかもしれません。マーケティングは、すでに不満を持っているユーザーにプロモーションメールを送るかもしれません。サポートは、顧客のアカウント価値や最近の営業の会話に関する重要な情報を見落とすかもしれません。
なぜAIが問題をより可視化しているのでしょうか
データサイロは新しいものではありません。では、なぜ今それがこれほど注目されているのでしょうか？一つの理由はAIです。
生成AIが日常業務の一部になる前、チームはデータサイロに対処するために手作業による回避策を使うことが多かったです。部門は別々のプラットフォームで作業し、必要に応じて情報を手動でシステム間でコピーしていました。
もちろん統合もありました。しかし、多くの場合、統合は特定の目的のために構築され、継続的なメンテナンスが必要でした。もちろん、この設定は非効率でしたが、チームはそれを回避して作業する方法を学びました。
現代のAIツールは、ますます多くの異なるシステムでの作業が期待されています。単一のエージェントが必要とすることは次の通りかもしれません：
- CRMから顧客情報を取得する
- サポートチケットを確認する
- アナリティクスをチェックする
- プロジェクト管理ツールでタスクを更新する
- 全く異なるプラットフォームでアクションをトリガーする
これをうまく行うためには、システム同士が情報をスムーズに共有する必要があります。しかし、ほとんどのツールは、このようにシームレスに連携するように作られていません。異なるデータ構造を使用し、APIの動作が異なり、多くの統合は特定の用途向けにカスタムで作られています。
その結果、よくある問題がより目立つようになります。情報が分散し、システム間の通信がうまく行かず、場合によっては統合が壊れてしまうこともあります。その結果、ツール間で重要な文脈が失われてしまいます。
企業が通常データサイロにどのように対処するのでしょうか
前述の回避策に加えて、組織はデータサイロに対処するためにさまざまな方法を継続的に試みています。ある組織はデータをウェアハウスやデータレイクに集中管理します。別の組織はAPI統合を構築したり、自動化プラットフォームを使用したり、ビジネスインテリジェンスツールに依存して情報をまとめます。これらデータサイロへの従来のアプローチは、組織が異なるソースからデータを収集、構造化、解析するのに役立ちます。主な目的は情報をまとめることです。
これは多くのレポート作成や解析のユースケースではうまく機能しますが、システムが動的に相互作用する必要がある場合には柔軟性が低くなります。これは特にAI搭載ツールに当てはまります。AIアシスタントは単にデータを一箇所から読むだけでは済まない場合があります。利用可能なツールを理解し、適切なコンテキストにアクセスし、異なるシステム間で適切なアクションをトリガーする必要があるかもしれません。
ここで会話は単に「データサイロを破壊する」から「相互運用性を改善する」へとシフトします。
データの中央集約からツールの相互運用性へ
これらの従来のアプローチは依然として重要です。特にレポート作成、解析、そして信頼できるビジネスデータのビューを作成するためには必要です。しかし、ますます多くの場合、システムは単にデータをある場所から別の場所に送信するだけでは不十分です。システムは、自身が何を行えるのか、どの情報を保持しているのか、他のツールがどのように相互作用できるのかも公開する必要があります。ここでMCPが関係してきます。
MCPとは？
MCPは「Model Context Protocol」の略で、2024年にAnthropicによって導入されたオープン標準です。この標準は、すべての接続をゼロから構築することなく、AIツールが既存のビジネスシステムで動作できるようにします。
あらゆるワークフローのためにカスタム統合を構築する代わりに、MCPはAIが外部ツールやデータソース、ワークフローにアクセスするための一貫した方法を提供します。簡単に言えば、AIシステムとそれがやり取りするツールの間の共通言語のように機能します。
組織にすべてのデータを一つのシステムに集中させることを強いる代わりに、MCPはAIアプリケーションがすでに存在する場所でデータやツールにアクセスできるようにします。
会社がAIアシスタントをウェブ解析プラットフォーム、CRM、ヘルプデスク、またはドキュメントシステムで利用したい場合、そのシステム用のMCPサーバーを誰かが提供するか構築する必要があります。
つまり、MCPはまだすべてのソフトウェアで普遍的に利用できるわけではありません。多くのアプリケーションに実装可能ですが、MCPサポート付きのシステムまたはMCPサーバーを持つシステムだけが参加できます。
MCPのサポートを提供するのは誰か、またはMCPサーバーを運営しているのは誰か？
MCPを利用可能にする一般的な方法は三つあります：
- CRM、解析プラットフォーム、ヘルプデスク、プロジェクト管理ツールなどのソフトウェア会社が、自社製品向けの公式MCPサーバーを構築し提供することができます。
- 企業が内部システム用に独自のMCPサーバーを構築することができます。
- ベンダー、代理店、コンサルタント、またはオープンソースのメンテナーが、人気のあるツール向けにMCPサーバーを構築することができます。
シンプルなMCPの例
マーケティングチームが、先週有料キャンペーンからのコンバージョンが急激に減少したことに気付いたとします。調査を行うためには、この問題がキャンペーンのパフォーマンス、ウェブサイトの動作、トラッキングの変更、またはその他の要因によるものかを理解する必要があります。AIアシスタントはその調査を助けることができますが、異なるシステム間で正しいコンテキストにアクセスできる場合に限られます:
- トラフィック、コンバージョン率、参照元、キャンペーンのパフォーマンスを示すウェブ解析データ
- 広告費用、クリック数、キャンペーンの変更を示す広告データ
- リードの質や販売結果を示すCRMデータ
- チェックアウトの問題やフォームの不具合に言及したサポートチケット
- 最近のウェブサイトやトラッキングの変更を示す社内リリースノート
そのコンテキストにアクセスする共通の方法がなければ、チームは手動チェックやエクスポート、ダッシュボード、あるいは一度きりの統合に頼ることが多くなります。
MCPをサポートするツールやデータソースでは、このプロトコルによって関連するコンテキストやアクションをAIアプリケーションに公開するためのより一貫した方法が提供されます。公式MCPドキュメントによれば、これは「データソース、ツール、ワークフローなどの外部システムにAIアプリケーションを接続するためのオープンソース標準」とされています。
このようにして、すべてのシステムを個別の統合プロジェクトとして扱うのではなく、AIアプリケーションは共通のプロトコルを使用して利用可能な情報を発見し、適切なコンテキストを取得し、チームの調査を支援することができるようになります。システム自体は別々に存在しますが、AIアプリケーションがそれらのシステム全体で動作する方法はより一貫したものになります。
これはスケーリング時に特に重要です。カスタム統合はすべてメンテナンスの負担を増やし、使用するシステムの数が増え、相互運用性の必要性が高まるにつれて維持がより困難になります。
MCPではないもの
CPはAPI、データベース、またはデータウェアハウスの代替ではありません。また、データサイロを魔法のように消すものでもありません。基盤となるシステムは依然として個別に存在しており、組織は依然としてガバナンス、権限、および信頼性のあるインフラを必要とします。
MCPが行うのは、分離されたシステムによって引き起こされる摩擦の一部を軽減することです。APIを置き換えるわけではありません。多くの場合、MCPは裏側でそれらを使用します。APIは個々のシステムがデータや操作を公開する方法のままです。MCPは、AIアプリケーションが異なるツール間でそれらの機能をより一貫して発見・利用できる共通レイヤーを提供します。実際には、MCPは、既存のツールをAI対応のワークフロー向けにより使いやすくするのに役立ちながら、データを既存のシステムに残したままにすることができます。
アクセスは依然として管理する必要があります
ツールを接続しやすくすることは、すべてを誰でもアクセスできるようにすべきだという意味ではありません。
もしAIアプリケーションがCRMデータ、サポートチケット、解析、内部文書全体で操作できる場合、アクセス制御はさらに重要になります。組織は、権限、データガバナンス、認証、監査可能性に関して明確なルールを持つ必要があります。
MCPはツールやコンテキストの公開方法を標準化するのに役立ちますが、責任ある実装の必要性をなくすわけではありません。
なぜ今、相互運用性が重要なのでしょうか
ほとんどの企業は、一緒にうまく機能するように作られていない数十ものツールに依存しています。自動化やAI駆動のワークフローが一般的になるにつれて、そのギャップは無視できなくなります。だからこそ、相互運用性は今非常に重要なトピックとなっているのです。MCPのようなプロトコルは、無限のカスタム統合に頼らず、情報、コンテキスト、アクションをより一貫して公開する方法として役立ちます。
方向性は明確です：ツール同士が簡単にコミュニケーションできればできるほど、それらはより有用になります。
データ所有権を手放さずにスタックに組み込める解析を求めていますか？21日間の無料トライアルを始めましょう。