翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
MCP とは
LLMs、トレーニングデータに基づいてプロンプトへの回答を予測することによって機能します。つまり、LLM は、すでに表示したデータとイベントに関する回答のみを提供できます。取得拡張生成 (RAG) やナレッジベースなどの方法を使用すると、コンテキストデータを含めることができます。ただし、明日の天気予報がどのようなものになるか、データベースに何人の顧客がいるかを LLM に尋ねると、これらは LLM の事前トレーニング済みの知識の範囲外であるため、ハルシネーションになるか、回答を提供できない可能性があります。これらの種類の質問に回答できるようにするには、エージェントは LLM のネイティブコンテキスト外の外部機能、データ、APIs にアクセスする必要があります。
ツールについて
ツールを使用して、LLM に追加のシステムやコンテキストへのアクセスを許可できます。 ツールは、明確な目標を達成するために LLM に提供される関数です。ツールは、API の呼び出し、データベースのクエリ、計算ツールオペレーションの実行、コードサンドボックスの操作、ウェブ検索の実行、さらには別の AI システムやagent-as-a-tool呼び出すこともできます。各ツールには、ツールの動作、使用タイミング、受け入れるパラメータを LLM に伝える説明を含める必要があります。これにより、LLM はユーザーの入力に基づいて呼び出すツールまたはツールの組み合わせについて微妙な決定を行うことができます。LLM は、エージェントが使用できるツールについて説明され、ツールを呼び出すようにエージェントに指示するレスポンスを生成できます。たとえば、データベース内の顧客数を LLM に尋ねると、LLM はエージェントにレスポンスを送り返し、特定の入力パラメータを使用してquery_databaseツールを実行するようにリクエストします。LLM は、呼び出すツールとツール呼び出しの入力を決定します。エージェントはツールを実行し、自然言語入力を構文的に正しい関数呼び出しに変換してクエリを実行します。エージェントは LLM からの命令に基づいてツールを呼び出し、その結果は LLM に返されます。これにより、LLM はテキストベースの入力を推論し、ジョブに適したツールを選択できます。
次の図は、各エージェントが各ターゲットに対して独自のツールセットを管理する方法を示しています。
スケーリングツールへのアクセスは、エージェント AI ソリューションにとって課題となる可能性があります。
-
すべての開発者が同じ外部機能用に独自のツールを作成している場合、これらの外部機能を操作するための重複した労力と標準化されていない方法が多数あります。これにより、エージェント間で実装に一貫性がなくなります。ライブラリで標準ツールを開発して配布することで、この問題を解決できますが、一元化されたガバナンスはありません。これにより、セキュリティポリシーの適用、ツールの使用状況の追跡、チーム間のバージョニングの管理、組織の標準への準拠の確保が困難になります。さらに、ツールをエージェントに直接埋め込む場合は、新しいツールが作成されるか、既存のツールが更新されるたびにエージェントを再デプロイする必要があります。
-
LLM にツールを提供すると、そのコンテキストウィンドウが消費されます。コンテキストウィンドウは、モデルが一度に考慮できるトークンの数 (LLMs が処理するテキストの単位。通常は単語、単語の一部、または句読点を表します) です。LLMsにはコンテキストウィンドウの制限があります。ツールとそのドキュメントは、システムプロンプトとユーザープロンプトとともに、その有限コンテキストウィンドウを使用します。コンテキストウィンドウがいっぱいになると、LLMs、関連情報の識別が困難になり、処理の複雑さが増し、推論の容量が減るため、パフォーマンスが低下する可能性があります。ツール定義、システムプロンプト、会話履歴が各 LLM 呼び出しで提供されるため、制限されたコンテキストウィンドウスペースで競合すると、チャレンジが複雑になります。
したがって、ツールの数と文書化方法は、応答時間や精度など、LLM のパフォーマンスに直接影響します。
MCP は、エージェントを外部機能に接続するためのユニバーサルスタンダードを確立します。一般的に「AI アプリケーション用 USB-C」と呼ばれます。MCP サーバーは、ツールをエージェントに直接登録する代わりに、JSON-RPC 2.0 で検出および呼び出されるホスティングツールの仲介として機能します
次の図は、MCP を使用して外部リソースにアクセスするエージェントを示しています。
ただし、MCP 標準では、スケーリングとガバナンスに関するすべての課題が解決されるわけではありません。MCP サーバーの実装は、効果的なツール設計、ホスティング、エンタープライズガバナンス戦略と組み合わせる必要があります。このガイドでは、エージェント AI ソリューションの一部として MCP を構築して使用するのに役立つ各戦略のベストプラクティスを提供します。
MCP を使用するタイミング
MCP は、エージェント AI イニシアチブをスケーリングするための戦略的インフラストラクチャを提供します。ツールの管理とガバナンスを一元化することで、MCP サーバーは複数のエージェント間でカスタム統合を構築および維持するための累積コストを削減します。これにより、エージェントのエコシステムが拡大するにつれてリターンが増加します。
MCP は、次の場合に戦略の一部になる可能性があります。
-
データベース、APIs、内部ツール、サードパーティー統合などのエンタープライズシステムやサービスにエージェントがアクセスする方法を一元管理する必要があります。
-
開発者は、実装間で一貫性のないカスタム統合の作成にあまりにも多くの時間を費やしています。
-
一般的な機能を提供できるツールが重複している。
-
標準化され管理された MCP インターフェイスを通じて、独自のツールやデータを外部のコンシューマーやサードパーティーのエージェントシステムに提供し、セキュリティと制御を維持しながら新しい収益ストリームを解放したいと考えています。
MCP サーバーが戦略の一部になると判断したら、既存のオープンソース MCP サーバーの実装がニーズを満たしているかどうか、拡張が必要かどうか、カスタムサーバーを構築する必要があるかどうかを評価します。構築済みの MCP サーバーの実装の多くはパブリックリポジトリで利用でき、ファイルシステムアクセス、ウェブブラウジング、コードサンドボックス、データベースアクセス、API 統合などの一般的な機能を対象としています。
多くの場合、既存の MCP サーバーで十分です。たとえば、 はAWS MCP Server、AI アシスタントとエージェントに自然言語インタラクション AWS のサービス を通じて への安全で認証されたアクセスを提供するマネージドリモート MCP サーバーである AWS を提供します。を使用して、 AWS ドキュメントへのリアルタイムアクセス、構文的に正しい API コール、ベストプラクティスに従う AWS エージェント SOPs と呼ばれる構築済みのワークフローを組み合わせることで、複雑な複数ステップの AWS タスク AWS MCP Server を実行できます。 AWS は を継続的にテスト AWS MCP Server して、カスタマーエージェントがそれらを正常に使用できることを確認します。
これらの既存の MCP サーバーをエージェントでテストして、ユースケースを満たしているかどうかを判断する必要があります。エージェントがワークフローを完了できなかったり、正しくないレスポンスや最適でないレスポンスを生成したり、複雑なマルチステッププロセスをナビゲートできなかったり、重要なドメイン固有のベストプラクティスやセキュリティ上の考慮事項を見逃したりした場合は、いくつかの側面で強化を検討する必要があります。
既存の MCP サーバーがニーズを完全に満たしておらず、既存のツールを正しく使用したり、正確なレスポンスを生成したりするのに苦労する場合は、カスタムサーバーを構築する前に、次の拡張アプローチを検討してください。
-
エージェントコンテキストの強化 – エージェントが既存の MCP サーバーでツールを適切または効率的に使用できない場合は、これらのツール定義に追加のドキュメントや例を追加することを検討してください。これにより、LLM に追加のコンテキストが提供されます。
-
補完ツールの追加 – エージェントがワークフローを正常に完了するために必要な追加の組織データまたはコンテキストにアクセスするツールを使用して、既存の MCP サーバーを拡張します。
-
基盤となる APIs – パラメータの複雑さを軽減し、より明確なエラーメッセージを提供し、エージェントが使用できる適切なデフォルトを提供することで、サービス APIs を簡素化して LLM フレンドリにします。
既存の MCP サーバーの実装を使用すると、一般的な機能の開発が加速されますが、ユースケースで特殊な機能が必要な場合は、カスタム MCP サーバーを構築することが不可欠です。カスタム MCP サーバーは、ドメインの専門知識をカプセル化し、組織標準を適用し、複雑なワークフローのエージェントの信頼性を向上させ、セキュリティ要件への準拠をサポートします。次の状況では、カスタム MCP サーバーの構築を検討してください。
-
ドメイン固有のワークフロー – 必要な知識が API ドキュメントに記録されていない場合は、ドメインの専門知識を必要とするマルチステップワークフローをカスタム MCP ツールにカプセル化する必要があります。 例えば、医療保険の相互運用性と説明責任に関する法律 (HIPAA) のコンプライアンスを検証し、PII を匿名化し、HL7 FHIR
形式に変換する必要がある複雑な医療データパイプラインをエージェントにオーケストレーションさせる代わりに、ドメインの専門知識を直接埋め込む process_patient_dataツールを提供します。これにより、ワークフローステップを正しく調整して実行するための LLM への依存関係が削除され、一貫性とコンプライアンスが向上します。 -
ゴールデンパス抽象化 – エージェントは、組織のコンテキストが不足し、組織のベストプラクティスではなく基本的なパターンがデフォルトであるため、最適なアプローチの実装に苦労する可能性があります。これらのシナリオでは、これらのゴールデンパスをカスタム MCP ツールにカプセル化することで、コスト、パフォーマンス、またはセキュリティに関する規範的な標準を適用できます。たとえば、エージェントが安全でない、または非効率なデフォルト設定でインフラストラクチャをデプロイするのではなく、組織の標準を直接埋め込むツールを提供します
deploy_secure_infrastructure。 -
複雑なマルチサービスオーケストレーション – 各ステップで使用する正しいシーケンスとサービスのセットを推測することで、エージェントに複雑なワークフローをオーケストレーションさせる代わりに、MCP ツール内でそのロジックを決定的に構築できます。また、エージェントが認識していない最適なサービス統合パターンに関する専門知識を提供することもできます。 これにより、エージェントの精度と効率を向上させることもできます。
-
サービス固有のベストプラクティス – これは、エージェントがエージェントツールを介してアクセスされるサービスに固有の暗号化ポリシー、アクセスコントロール、コンプライアンスパターンを実装するのに役立つセキュリティに焦点を当てたツールに共通です。さらに、サービス固有の運用上のベストプラクティスが明確でない場合、MCP サーバーを使用すると、それらが実装され、理由がエージェントに委ねられないようにすることができます。
