本記事はこちらのブログを参考にしています。
翻訳にはアリババクラウドのModelStudio(Qwen)を使用しております。
MCPの技術的原則から始まる、複雑さを軽減しサーバー運用の安定性を向上させるための洞察
著者: Ji Yuan
編集者ノート: アプリケーションがよりインテリジェントになるほど、その背後にある設計はより複雑になります。ソフトウェアの本質は複雑さの問題を解決することにあります。MCPがインテリジェンスの創造的な限界を開拓する一方で、バックエンド設計にも無限の複雑さをもたらします。この記事では、MCPの技術的原則から始まり、MCPサーバー構築における複雑さを軽減し、サーバー運用の安定性を向上させるための実践的な洞察を共有します。内容は長文ですが、以下に概要を示します。
- MCPの概念とその動作メカニズムを紹介。
- MCPとFunction Callingの違いを説明。
- MCPの本質と課題について議論（MCP情報に関するシステムプロンプトの課題、MCPクライアントとMCPサーバーの協力関係、MCPサーバーの迅速な構築、Dify構築の痛みのポイントなど）。
- MCPのさまざまな課題を解決する方法を分析（MCPレジスター、MCPサーバー、プロンプトの一元管理、MCP効果検証システムと安全性の保証、MCPゲートウェイ、MCPサーバーの動的サービスディスカバリ、ストリーム可能なHTTP、弾力的効率、観測可能性など）。
- 最後に、MCPがAIアプリケーションアーキテクチャの新しいパラダイムに与える影響を議論し、「MCPサーバーファースト」の概念を紹介。
現状とAIエージェントのアーキテクチャ
人工知能（AI）は、ビジネスにおける革新と効率の推進力としてますます中核的な存在となっています。その核心は、複数のAIエージェントの協力にあり、それらが分業と協力を通じてAIアプリケーションによってサポートされるビジネスニーズを満たしています。この協力モデルは企業運営を最適化し、高影響度の課題を解決するAIの可能性を示しています。
現在のAIエージェントは、LLM（大規模言語モデル）以外ではOpenAIパラダイムに従うことが一般的であるものの、HTTPプロトコルを通じて相互作用しています。これには、さまざまなツール（各種ビジネスサービスインターフェース）、さまざまなメモリ（各種ストレージサービスインターフェース）、およびさまざまなLLMとのインタラクションが含まれます。また、他のツールやメモリと対話する際には、その戻り形式を一つ一つ理解して解析・適応する必要があります。AIアプリケーションが複数のAIエージェントを含む場合や、複数のビジネスサービスインターフェースやストレージサービスインターフェースと対話する必要がある場合、全体的な開発作業量は非常に大きくなります。主に次の3つの側面に反映されます。
適切なビジネスインターフェースやストレージサービスインターフェースを見つける
- 第三者サービスインターフェースを探す。
- 社内に適した内部サービスインターフェースを探す。
- 見つからない場合は自社でインターフェースを開発する。
インターフェースの戻り形式を解析する
第三者サービスインターフェースや社内のサービスインターフェースでも、戻り形式は大きく異なるため、それぞれを理解して解析する必要があります。
複数のAIエージェントをオーケストレーションする
Difyのようなツールを使用することで、プロセスの可視化を支援し、多くのオーケストレーションタスクを軽減できますが、複雑さは依然として高く、運用効率やパフォーマンスにボトルネックがあります。コーディングアプローチ（例：Spring AI AlibabaやLangChainを使用）によるオーケストレーションはパフォーマンスが高いものの、さらに複雑になり、オーケストレーションの効率と柔軟性が制限されます。そのため、現在のAIアプリケーションでは少数のAIエージェントしか使用されておらず、多くの場合、単一目的のエージェント（Siloed, Single-Purpose Agents）に留まっています。AIエージェントを第二段階（プラットフォームレベルのエージェント）に進化させるために、クラウドネイティブAPIゲートウェイを統一アクセス層として使用します。ゲートウェイを3つの異なる役割で活用することで、一部の複雑さを解決します。
- 南北トラフィックゲートウェイとして、AIエージェントへの着信トラフィックを管理し、主に転送、負荷分散、認証、承認、安全性制御を実行。
- AIゲートウェイとして、さまざまなLLMをプロキシし、AIエージェントが複雑なアクセス要件から解放され、多モデル切り替え、モデルフォールバック、マルチAPIキー管理、安全性、オンライン検索などの生産グレードの問題を解決。
- 東西ゲートウェイとして、AIエージェントが利用できるさまざまなソース（ACK、ECS、Function Compute FC、SAE、第三者サービス）からのサービスを管理。
ただし、上記は一部の複雑さしか解決しておらず、インターフェースの探索や解析という根本的な問題は未解決のままです。MCP（Model Context Protocol）の登場により、ようやく第二段階（プラットフォームレベルのエージェント）に到達する道筋が見えてきました。そして、第三段階（ユニバーサルエージェント、マルチエージェント）に接近する可能性もあります。
MCPとは何か？
MCPはModel Context Protocolの略で、Anthropic（Claude開発会社）によって開発されたオープンソースプロトコルです。これは、大規模言語モデル（LLM）が標準化された方法で外部データソースやツールに接続できるように設計されています。MCPはAIアプリケーションのための普遍的なインターフェースとして機能し、各AIモデルや外部システムごとにカスタム統合を行うことなく、より柔軟でコンテキスト認識型のAIアプリケーションを構築する手助けをします。MCPはUSB-Cポートに似た普遍的なインターフェースとして設計されており、ファイル、データベース、APIなどのさまざまなデータソースやツールに一貫して接続できるようになります。
MCPには現在3つの主要な概念があります。
-
MCPサーバー:
各種言語のMCP SDKに基づいて開発されたプログラムまたはサービス。既存のプログラムやサービスが特定の仕組みを通じてMCPサーバーへと変換されます。 -
MCPツール:
MCPツールはMCPサーバーに属しており、1つのMCPサーバーには複数のMCPツールを持つことができます。クラスに複数のメソッドがある、あるいは複数のインターフェースを持つサービスと同様です。 -
MCPクライアント:
MCP仕様に基づき、コード、エージェント、またはクライアントがMCPサーバー内のMCPツールを使用および呼び出す際に、MCPクライアントとして機能します。
MCPの動作原理
MCPが何であるかを真に理解するためには、その動作メカニズムを把握する必要があります。これにより、MCP呼び出しが従来のHTTP呼び出しとどのように異なるのかを理解でき、私がなぜMCPがAIエージェントを第二段階に進化させることができると言ったのかについて漠然とした感覚を得られるかもしれません。
上の画像は、LLMがユーザーのクエリを解決するために明確なMCPサーバーおよびツール情報を返す第二ステップを示しています。MCPと関数呼び出しの違いについて説明します。
この段階に到達したことで、あなたはMCPとは何かについてある程度の理解を得られたと思います。では、MCPはインターフェースを見つけることや解析することに関する問題を解決したのでしょうか？なぜなら、これらのタスクはすべてLLMに委ねられるからです。
- LLMはAIエージェントが最も適切なインターフェースを見つけるのを助けます。
- AIエージェントはインターフェースを直接呼び出し、戻り結果を解析する必要はありません。変更せずにそのままLLMに戻します。
- LLMはユーザーの質問とインターフェースからの戻り結果を組み合わせて処理し、コンテンツを整理します。
ここで、一部の人々が尋ねるかもしれません。「MCPとLLMにおける関数呼び出し(Function Calling)の違いは何ですか？」その核心的な違いは、モデルまたはベンダーにバインドされるかどうかにあります。
- MCP は一般的なプロトコル層の標準であり、AIのUSB-Cインターフェースのようなもので、LLMと外部ツール/データソース間の通信フォーマットを定義しますが、特定のモデルやベンダーには依存しません。複雑な関数呼び出しをクライアント・サーバーアーキテクチャに抽象化します。
- 関数呼び出し (Function Calling) は大規模モデルベンダーが提供する独自の機能であり、各ベンダーによって定義され、異なる形式を持ちます。これにより、モデルは直接関数呼び出しを生成し、外部APIをトリガーすることが可能になります。これはモデル固有のコンテキスト理解と構造化された出力能力に依存しています。LLM関数呼び出しでは、LLMが外部関数ごとにJSON Schema形式の関数記述を作成し、慎重に設計されたプロンプトテンプレートを作成して関数呼び出し応答の精度を向上させる必要があります。数十の外部システムが必要な場合、設計コストは非常に高くなり、製品化コストも大幅に増加します。
しかし、MCPはクライアントとサーバーの両方の操作仕様を標準化し、MCPクライアントとサーバー間の通信が事前に決められたプロンプトテンプレートに従うことを義務付けています。これにより、グローバルな開発者間の協力を強化し、世界中の開発成果を再利用できるようになります。
MCPの本質と課題
これまでの一連の説明に基づいて、MCPの本質を以下のようにまとめることができます。
Model Context Protocol (MCP) は確定的なデータ形式や構造ではありません。それはMCPサーバー/MCPツール情報のためのシステムプロンプトと、MCPサーバーとLLM間の相乗効果を表します。また、インターフェースを見つけることや解析することに関する根本的な問題を解決します。
MCPの本質が明らかになると、それを企業向けの生産アプリケーションに導入することで、これらの2つの主要領域における多くの課題や不足が浮き彫りになります。
MCPシステムプロンプト情報の記述における課題
-
システムプロンプトの安全性をどう確保するか？
もしコアとなるシステムプロンプトが破損した場合、LLMはどのMCPサーバーやツールが存在するのか正確に把握できなくなり、無効または安全でないMCPサーバーやツール通知が行われる可能性があります。これにより、AIアプリケーションに重大なリスクが生じ、MCPワークフロー全体が崩壊する可能性があります。 -
システムプロンプトをどう管理するか？
新しいバージョンのMCPサーバーやツールが登場した場合、システムプロンプトには対応するバージョン管理戦略が必要です。もしシステムプロンプトが不適切に書かれていた場合、それを簡単に迅速にデバッグできますか？リアルタイムで効果を発揮させることは可能でしょうか？ -
システムプロンプトの長さとトークン消費
システムプロンプトに標準的な定義がないため、理論的には各企業が独自のシステムプロンプトテンプレートを定義できます。例えば、PEプロジェクトと同様です。プロンプトを完璧に書くことは一回で達成できません。繰り返し調整を行い、リアルタイムで変更が効く仕組みが必要です。多数のMCPサーバーがある場合、システムプロンプトが過剰に長くなり、多くのトークンを消費する恐れがあります。どのようにしてMCPサーバーとツールの範囲を絞り込むか、または指定するかが重要です。数十以上のMCPサーバーがあれば、数百以上のMCPツールを持つことも考えられます。システムプロンプト内にすべての情報を文書化すると、プロンプトテンプレートが非常に大きくなり、大量のトークンを消費し、コストがかかります。オンライン検索での意図認識と同様に、ユーザクエリに基づいてMCPサーバーとツールを事前に選択し、トークン使用量を減らし効率を上げる仕組みが必要です。
MCPクライアントとMCPサーバー間の連携に関する課題
-
既存のMCPクライアントの不足
現在、Cline、Claude、CursorなどのC/Sツール（SSEプロトコルをサポート）しかありません。これらは企業レベルのAIアプリケーションに統合できるのでしょうか？基本的に、市場にある既存のMCPクライアントは企業レベルのAIアプリケーションに統合することはできません。ステートフルプロトコルであるSSEには多くの欠点があり、回復性の欠如、サーバーが長期接続を維持する必要があること、サーバー→クライアントへのメッセージしか許可されないこと、双方向通信の柔軟性の欠如などです。 -
既存の伝統的なビジネスをMCPサーバーに迅速に変換できるか？ゼロコード変更で実現可能か？
MCPサーバーの構築はMCP SDKに大きく依存しており、現在はPython、Java、TS、Kotlin、C#のみに対応しています。GoやPHPを使用している企業はどうすればよいでしょうか？さらに、既存のすべてのビジネスをMCP SDKでリファクタリングするのは莫大な作業量となり、実際的ではありません。 -
多数のMCPサーバーをどう統一的に管理するか？
自社開発のMCPサーバー、サードパーティのMCPサーバー、および伝統的なビジネスから何らかのメカニズムで変換された多数のMCPサーバーがあります。MCP HubやMCPマーケットプレイスのような統一管理システムを作成して、クライアントによるMCPの使用を容易にする必要があります。 -
企業レベルのAIアプリケーションにおける認証、データ権限、およびセキュリティ対策の実装方法
企業レベルのアプリケーションでは、プロトコル、アーキテクチャ、ビジネスタイプに関係なく、認証、データ権限、セキュリティの問題が常に最重要です。これらをMCP特有の協調方式でどのように達成するかが課題です。
AIアプリケーションアーキテクチャにおける新しいパラダイム
これらの課題に対処するためにMCPパラダイムを統合し、AIエージェントのアーキテクチャを再構築しました。クラウドネイティブAPIゲートウェイやNacosなどのマイクロサービスエンジンにMCP強化機能を実装し、前述の多くの課題を解決しました。Function Compute FCとServerless Application Engine SAEにもMCP強化機能を追加しました。前者はMCPサーバ
MCP登録 (MCPサーバー登録/設定センター)
MCPサーバーの統一管理
MCPサーバーは、次の2つの方法でMSE Nacosに登録できます：
- 手動でMSE Nacosコンソールに作成する：これには、MSE Nacos内でMCPサーバーエンドポイントを設定することが含まれます。
- Nacos SDKを使用してMCPサーバーを自動的にNacosに登録する：これは現在のJava SpringCloudおよびJava Dubboサービスのロジックと類似しています。
MSE NacosでのMCPサーバーの統一管理により、ヘルスチェック、ロードバランシング、JSONからXMLへの記述情報の変換、およびMCPサーバーのオンラインとオフライン状態の制御が可能になります。
MCPプロンプトの統一管理
MSE Nacosでは、MSPサーバープロンプトを維持するための2つの方法があります：
-
手動でMCPサーバーの設定情報を作成する
設定ファイル内のData IDの命名形式は、[MCPサーバー名]-mcp-tools.jsonです。設定ファイル内でMCPツールのプロンプトを管理します（例：全体的な説明やパラメーターなど）。 -
MSEガバナンス機能の利用
JavaまたはGoを使用している場合、サービススキーマを自動的に検知し、MCPサーバーおよびツールのプロンプト情報を自動生成できます。
MSE NacosにおけるMCPサーバープロンプトの統一管理では、プロンプトのバージョン管理（ロールバック）、グレープロセスの管理、プロンプトのセキュリティ管理、およびリアルタイムで効果を発揮するプロンプトの動的調整が可能です。
MCP効果検証システム（進行中）
前述のように、多数のMCPサーバーがある場合、その広範な記述情報によって長いプロンプトが生成され、トークン消費量が増加します。したがって、ユーザー入力に基づいてMCPサーバーの範囲を狭め、トークン消費を削減し、LLM推論効率を向上させる仕組みが必要です。
さらに、LLMとのインタラクションにおいてプロンプトの品質が非常に重要であることは明らかです。MCPプロセス全体がプロンプトエンジニアリングに大きく依存しているため、プロンプトが適切に調整されていない場合、LLMは正確なMCPサーバーやツールの解決策を返さず、プロセス全体が使用不能になる可能性があります。
このため、私たちはNacos内にMCP効果検証システムを開発しています。そのコアとなる原則は、Spring AI Alibabaに基づいて開発されたAIエージェントを提供することです。ユーザー設定のビジネス入力、LLM、そして絞り込まれたMCPサーバーとツールのコレクションを利用して、継続的な検証を行い、その結果を視覚的に（例えば成功率など）表示します。ユーザーはNacos内で成功率の低いMCPサーバーに対応するプロンプトを動的に調整し、効果を改善できます。
MCPのセキュリティ保証（継続的な改善）
アーキテクチャやモードに関係なく、企業での運用においてセキュリティは最優先事項であり、特にMCPでは考慮すべき点が多岐にわたります。
-
MCPサーバーの機密情報の管理
MSE Nacosに登録されたさまざまなMCPサーバーには、APIキー、AK/SK、シークレット、ログインパスワードなどの機密データが含まれる可能性があります。MSE NacosはAlibaba Cloud KMSと深く統合され、これらの機密データを暗号化します。 -
MCPプロンプトのセキュリティ管理
再び、MSE NacosとKMSの統合を利用することで、MCPサーバーおよびツールの完全なプロンプト（記述情報）を暗号化し、プロンプト汚染を防ぎます。 -
MCPプロンプトのセキュリティ検証
上記の検証システムおよびコンテンツセーフティとの統合により、MSE NacosはMCPプロンプトの合法性チェックを行うことができます。
MCPクライアントとMCPサーバー間の連携における課題への対応
MCPパラダイム内では、3つの役割が協力します：
- MCPクライアント → LLM
- MCPクライアント → MCPサーバー
これらの2種類の連携関係は、本質的にはサービスプロバイダーと消費者の相互作用を反映しており、プロキシ協力やトラフィック制御が含まれます。従来の開発パラダイムでは、これらは通常ゲートウェイによって管理されます。そのため、クラウドネイティブAPIゲートウェイを強化し、LLMプロキシおよびMCPサーバープロキシ機能を追加しました。これにより、トラフィックゲートウェイとしてだけでなく、AIゲートウェイ（LLMプロキシ）およびMCPゲートウェイとしても機能します。これが新しいAIアプリケーション開発パラダイムの中核的な要素となります。
したがって、企業全体のシステムアーキテクチャにおいて、単一のクラウドネイティブAPIゲートウェイのみが必要です。それはトラフィックゲートウェイ、APIゲートウェイ、マイクロサービスゲートウェイ、AIゲートウェイ、およびMCPゲートウェイとして機能し、従来の業務とAI業務を統合的に制御し、シームレスに融合させます。
クラウドネイティブAPIゲートウェイ ドッグフーディング
「自社製品を自ら使用する」という原則に従い、クラウドネイティブAPIゲートウェイはすでにアリババグループ内で幅広く使用されており、企業レベルの製品、安定性、およびパフォーマンスに関して高い評価を得ています。
AIゲートウェイ
MCPクライアントとLLM間の相互作用は、従来のサービスとLLM間の相互作用と似ています。アプリケーションが本番環境に移行すると、次のような問題が生じ、解決する必要があります：
-
コストバランス
例えば、DeepSeek R1 671Bモデルをデプロイするには少なくとも2台の8カードH20マシンが必要で、年間のリスト価格は100万を超えますが、TPSが限られており、複数のユーザーからの同時リクエストに対応できません。新しくリリースされたLlama4でも、少なくとも1台のH100が必要です。そのため、TPSとコストのバランスを取るソリューションが必要です。 -
モデルの幻覚現象
完全なDeepSeek R1 671Bモデルでも、オンライン検索がない場合、大きな幻覚現象が発生します。 -
マルチモデル切り替え
単一モデルのサービスには安定性リスクや、ビジネス（消費者）ニーズに基づいた最適なモデル選択ができないといった大きなリスクと制限があります。現在、このような課題に対処するオープンソースコンポーネントやフレームワークはありません。 -
安全性とコンプライアンス
企業クライアントはQ&Aプロセスの監査を必要としており、コンプライアンスを確保し、使用リスクを軽減する必要があります。 -
モデルサービスの高可用性
自前で構築されたプラットフォームが性能の上限に達した場合、大規模モデルを活用した基盤ソリューションで顧客体験を向上させる必要があります。 -
クローズドソースモデルのQPS/トークン制限
商用の大規模モデルは一般的にAPIキーごとにQPS/トークン制限を設けており、迅速にクォータを増やすための効果的な方法が必要です。
これらの各問題は、クライアントが実際に使用中に直面する課題であり、一部はモデル固有のものであり、他はアーキテクチャ展開に起因するものです。お客様にこれらを個別に解決させることは、複雑さと時間コストが非常に高くなります。
MCPに関する詳細情報
新しい設定ファイルの追加とMCP仕様について
MSE Nacosに、[サーバー名]-mcp-tools.jsonという命名形式に従った新しい設定ファイルが追加されます。このMCP仕様は、既存のビジネスサービスのインターフェースを記述します。
クラウドネイティブAPIゲートウェイ（MCPゲートウェイ）経由でのMCPサーバーの自動発見
クラウドネイティブAPIゲートウェイ（MCPゲートウェイ）を通じて、MCPクライアントは従来のサービスから変換されたMCPサーバーを自動的に発見できます。
SSEからStreamable HTTPへの変換
MCPのデフォルト伝送プロトコルはSSE（Server Sent Event）で、これは基本的にステートフルな長時間接続プロトコルです。この種のプロトコルには企業アプリケーションにおいて多くの欠点があります：
- 再開のサポートなし：切断後、クライアントはセッション全体を再起動する必要があります。
- サーバーは長期接続を維持する必要がある：永続的なSSE接続をサポートするために高可用性を維持する必要があります。
- SSEはサーバー → クライアントメッセージのみをサポート：双方向通信の柔軟性が不足しています。
- 現在、少数のクライアント/サーバーアーキテクチャクライアントとMCP提供のWebクライアントだけがMCPパラダイムおよびSSEプロトコルをサポートしているため、エンタープライズ生産製品には適していません。
幸いにも、MCP戦略チームはこれらの問題を認識し、3月下旬に新しいStreamable HTTPプロトコルをリリースしました。Streamable HTTPはMCPのデータ伝送方法を修正し、プロトコルをより柔軟で使いやすく、互換性のあるものにします：
- より柔軟：ストリーミング伝送をサポートしますが、必須ではありません。
- より使いやすい：ステートレスサーバーに対応します。
- より互換性がある：標準的なHTTPインフラストラクチャにも適用可能です。
要するに、以前のMCP伝送方法ではお客様とのやり取り中にオンライン状態を維持する必要がありましたが（SSEでは長時間接続が必要）、新しい方法ではいつでもメッセージを送信し、応答を待つことができます（通常のHTTPリクエストにもストリーミングが含まれます）。以下を考慮してください：
- Streamable HTTPは現在の複数のC-end MCPクライアントに存在する障壁を排除します。つまり、どんなリクエスタ（単純なHTTPリクエストコードさえも）でも標準的なHTTP APIをリクエストするのと同じようにMCPサーバーと対話できるということです。
- つまり、標準的なHTTP API形式を通じた対話が可能になった場合、MCPクライアントという概念は依然として有効でしょうか？
Streamable HTTPはまだ草案段階ですが、クラウドネイティブAPIゲートウェイはSSE伝送プロトコルを自動的にStreamable HTTPプロトコルに変換する機能を実装しています。言い換えれば、クラウドネイティブAPIゲートウェイ（MCPゲートウェイ）を通じてアクセスされるMCPサーバーは、クライアント向けの伝送プロトコルとしてSSEとStreamable HTTPの両方をサポートできます。
MCPパラダイムにおけるアイデンティティ認証と権限管理
アイデンティティ認証と権限制御は、どのアーキテクチャやビジネスコンテキストにおいても不可欠であり、MCPパラダイムも例外ではありません。ここでは2つのレベルの権限管理が存在します：
- クライアントは特定のMCPサーバーとその中のどのMCPツールを使用する権利を持つか。
- クライアントはMCPツールを通じて特定のデータにアクセスする権利を持つか。
MCPサーバーとMCPツールの使用権限
ゼロコーディング変更で既存のビジネスがMCPサーバーに変換できると想像してください。Nacos内に登録されている多数のMCPサーバーとツールは複数のドメインにまたがり、金融関連のMCPサーバーや販売関連のMCPサーバー、アフターサービスのMCPサーバーなどが含まれる可能性があります。これらはすべてのMCPサーバーとツール情報を返すことはできず、クライアントにアクセス権限があるものだけを返す必要があります。
クラウドネイティブAPIゲートウェイ（MCPゲートウェイとして）は、HTTP Basic Auth、OAuth2.0、JWT、API Key、外部認証、および成熟したプラグインメカニズムを通じて複数の認証オプションを提供し、ユーザーがクライアントのアイデンティティ認証とMCPサーバー/MCPツールの使用権限を柔軟に管理・制御できるようにします。
MCPサーバーとMCPツールのデータ権限
MCPサーバーがMySQL MCPサーバーやRedis MCPサーバーなどのデータ型サービスである場合、権限はデータベースやテーブルレベルまで拡張できます。このようなシナリオでは、クラウドネイティブAPIゲートウェイ（MCPゲートウェイとして）はプラグインメカニズムを利用してリクエストヘッダーに値を書き換えたり追加したりでき、MSEガバナンスと連携してそれらのヘッダーバリューを渡し、サービス内でさらにデータ権限制御を実行できます。
例えば、データベースの読み書き分離にこのアプローチを採用する方法を示します。
MCPサーバーを迅速に構築する方法
LLM推論を伴うAIアプリケーションは、比較的疎な呼び出しシナリオで動作することがよく知られています。MCPパラダイムはLLM推論に大きく依存しています。そのため、AIアプリケーションの開発アーキテクチャがHTTP APIまたはMPCパラダイムを採用しても、主に疎な呼び出しコンテキストで機能します。これにより、以下の2つの緊急の問題が浮き彫りになります：
- 疎な呼び出しシナリオにおいて、MCPサーバーを実行するための計算リソースをどのように最適化し、コスト効率を達成するか。
- 新しいビジネスでMCPサーバーを迅速に構築するにはどうすればよいか。
すべてのコンピューティング製品の中で、Function Compute (FC) というServerless FaaSコンピューティング製品は、リソース粒度、弾力性戦略、および疎な呼び出しコンテキストでの効率に関して理想的に機能します。Function Compute (FC) は現在、PythonとNodeJSのMCP実行環境をサポートしており（他のプログラミング言語の実行環境も間もなく提供予定）、MCP実行環境を選択して関数を作成すると、ユーザーはMCPツールのビジネスロジックを構築するだけで、MCP SDKの使用を心配する必要はありません。
さらに、クラウドネイティブAPIゲートウェイとFunction Compute (FC) の深い統合により、AIアプリケーション開発の新しいパラダイムに自然に対応できます。
MCPサーバーの弾力性効率
Function Compute (FC) 上に構築されたMCPサーバーは、弾力性効率の観点から以下の2つの次元で評価できます：
- リソース仕様の細かい制御。
- ユーザー要求に基づく完全な弾力性。
Function Compute (FC) のインスタンスは、0.05C 128MBから16C 32GBまでの範囲で、数十種類の組み合わせ仕様が利用可能で、各MCPサーバーが担うビジネスに応じて柔軟に選択できます。特にAIアプリケーションでは、ほとんどのAIエージェントの責任は単一で計算が
例えば、時間間隔やタスクのステータスによるクエリは、オープンソース版のDifyでは対応していない一般的な要件です。監視やアラート機能もありません。タスクスケジューリングシステムでは、ワークフローの実行を監視し、ワークフローが失敗した場合に各担当者にアラートを送信する必要があります。しかし、オープンソース版ではそのようなアラート機能は一切ありません。私たちの解決策は、これらの問題に対処するためにMSEタスクスケジューリング（SchedulerX）を利用する方法です。
- ユーザーはMSEタスクスケジューリングでDifyのエンドポイントを設定し、Dify APIを通じてワークフローアプリケーションを取得します。
- ユーザーはMSEタスクスケジューリングで定期的な実行とアラート監視を設定します。
- Difyワークフローをスケジューリングする際、MSEタスクスケジューリングはDifyが提供するAPIを使用してユーザーのDifyアプリケーションをスケジュールし、実行結果や詳細をリアルタイムで取得し、それらをMSEのAIタスクスケジューラに保存します。
- AIタスクスケジューリングを活用することで、アラート監視と高度な観測性が可能になります。
MSEタスクスケジューリング統合Difyソリューションは、オープンソースソリューションと比較して以下の7つの利点があります：
| 機能 | MSEタスクスケジューリング + Dify | オープンソースDify |
|---|---|---|
| 定期実行 | あり | なし |
| 監視 & アラート | あり | なし |
| 実行記録の保持期間 | 過去2ヶ月分保持 | 無制限だが、過剰なデータはパフォーマンスに深刻な影響を与える可能性がある |
| 実行記録のクエリ | 時間間隔、ステータス、様々な条件でのクエリをサポート | 制限されたフィルタリング条件 |
| 権限管理 | 細かい操作レベルの権限管理 | ユーザーレベルの権限 |
| トラフィック制限 | アプリケーションレベルの制限、トークン制限 | なし |
| 失敗時の自動再試行 | あり | なし |
AIアプリケーションの観測可能システム
Ali Cloudの観測可能製品ARMSとトレース追跡OpenTelemetryを統合することで、AIアプリケーション向けの包括的な観測可能システムを構築します。全体的なAIアプリケーション観測可能システムの構築は、次の2つのコアコンポーネントを中心に展開します：
- データ収集
- データリンクと分析
観測データ収集
データ収集の鍵は広範囲なカバレッジであり、これには2つの側面があります：
- 多様なプログラミング言語および開発フレームワークのサポート
- 新しいAIアプリケーションアーキテクチャに関与するクラウド製品は、同じ基準に基づいてデータを報告すべきです
これらの側面により、Alibaba Cloudのアプリケーション監視製品ARMSとトレース追跡OpenTelemetryを組み合わせることで、包括的なカバレッジを達成します：
- 最新のOpenTelemetryコミュニティGenAIセマンティック規約に準拠
- Spring AI Alibaba / LLamaIndex / Langchain / Tongyi Qianwen 2 / OpenAI / PromptFlowなど、人気のあるAIフレームワークやモデルをサポート
- Python、Java、GoなどのAIアプリケーション開発における主流のプログラミング言語をサポートし、コミュニティ標準よりも細かく調整されたトラッキングと属性を提供
- セッション情報を異なる呼び出しチェーン間で伝搬させる
- クラウドネイティブAPIゲートウェイはOpenTelemetryプロトコルをサポートしており、ゲートウェイ自体とそのプラグインはOpenTelemetryに基づいて観測データを報告
- Function Compute (FC) およびServerless Application Engine (SAE) は、アプリケーション監視ARMSとOpenTelemetryトレース追跡製品と深く統合されています
データリンクと分析
アプリケーション監視ARMS内には、LLMアプリケーション専用の監視モジュールが開発されており、AIシナリオ向けに完全な観測可能システムを提供しています。垂直メトリクスには以下が含まれます：
- オンラインAIアプリケーションの数
- トレースの数
- スパンの数
- 大規模モデルの数
- トークン使用統計
- セッション数
- ユーザー数
- モデル呼び出し数
- トークン消費メトリクス
- モデル呼び出し時間
- トークン消費ランキング
- その他…
水平リンクに関しては、専門的な呼び出しチェーン分析機能が提供されます：
- スパンリスト
- トレースリスト
- 散布図
- 全体的なリンク集約
- 全体的な呼び出しチェーントポロジー
- エラー/遅いトレース分析
- 呼び出しチェーンの各リンクには、入力、出力、トークン消費の分析が表示されます
今後の追加予定機能
Dify DSLをSpring AI Alibabaコードに変換
DifyはAIエージェントの開発において大きな利便性を提供しますが、プログラミング言語（Python）やワークフローエンジンの実装ロジックに関する制限により、複雑なAIアプリケーションでのパフォーマンスに悪影響を与える可能性があります。そのため、DifyワークフローDSLをSpring AI Alibaba開発フレームワークに基づいて自動的にコードに変換することを検討しています。これにより、Difyの低コードビジュアル構造でユーザーを引きつけつつ、基盤部分はSpring AI Alibaba開発フレームワークのコードに依存し、AIエージェントの便利なオーケストレーションと向上したランタイムパフォーマンスを両立させることができます。
LLM駆動型のMCPサーバーオーケストレーション
現在のMCPパラダイムでは、LLMはユーザーのプロンプトに対応して明確なMCPサーバーとツールを返します。これは主にシステムプロンプトによって制御されています。理論的には、LLMはユーザーのクエリに対して複数のMCPサーバーとツールを返し、それらの呼び出し順序をMCPサーバーとツールの説明に基づいて示すことができます。これにより、LLMにMCPサーバーのオーケストレーション責任が本質的に割り当てられます。このアプローチはまだ研究段階であり、現在のマルチエージェントモデルに非常に似ています。
MCPモードでのパフォーマンス強化
MCPモードは頻繁にLLMとやり取りを行うため、従来のAPI呼び出しに比べてパフォーマンスが劣ります。現在、レイテンシに敏感なシナリオでは、MCPモードが適さない場合があります。私たちは、MCPモデルに固有のリクエストパフォーマンス問題の改善についても調査しています。例えば：
- MCPサーバー/MCPツールの組み合わせを固定してLLMとのやり取りを減らす。LLMによるMCPサーバーのオーケストレーションが実現されれば、LLMとのやり取りは開発またはデバッグ段階に限定され、クラウドフォーメーションは確立されたMCPサーバーとツールの呼び出し関係に依存する。
- 関数計算は、エッジケースを探索するためにMCPサーバーをユーザーに近い場所で実行する。
新しいAIアプリケーションアーキテクチャパラダイムが企業に与える影響
これで、エンタープライズ級のAIアプリケーションアーキテクチャパラダイムの紹介は終了です。全体構造には多くの要素があり、この記事ではすべてを網羅することはできません。興味がある方は