Azure Load TestingとLocustでhosted MCP serverを負荷試験する実践記事が公開

Microsoft Foundry Blog は 2026年5月29日、hosted MCP server を Locust と Azure Load Testing で負荷試験する方法を紹介しました。MCP server は エージェント が外部ツールや業務システムにアクセスする入口になるため、通常の API と同じように性能、安定性、認証、失敗時の挙動を検証する必要があります。

要点

• Hosted MCP server は、エージェント からの tool call を受ける本番コンポーネントとして負荷試験が必要になる
• Locust を使うことで、複数ユーザーや複数 エージェント からの呼び出しをシミュレーションできる
• Azure Load Testing と組み合わせると、負荷試験をクラウド上で再現しやすくなる
• 遅延、error rate、スループット、認証、外部依存先のボトルネックを事前に見るべき

今回のブログ記事で語られていること

この記事は、MCP server を「動いた」で終わらせず、本番利用に耐えるかを検証するための内容です。MCP は エージェント がツールを発見し、呼び出すための標準的な接続面として広がっています。しかし、エージェント が増えたり、同じ tool を複数 ワークフロー が同時に呼び出したりすると、MCP server 側の 遅延 や error rate がユーザー体験に直結します。

Locust は、ユーザー行動をコードで定義し、負荷を段階的にかけられるツールです。MCP server の場合、単純な HTTP エンドポイント の応答時間だけでなく、tool list、tool call、認証、外部 API 呼び出し、payload サイズ、セッション の扱いを含めてテストする必要があります。エージェント が本番でどのような頻度で tool を呼ぶかを想定しないと、過小評価になります。

Azure Load Testing と組み合わせる意味は、負荷試験を個人PCではなく、再現可能なクラウド環境で実行できることです。CI/CD やリリース前検証に組み込めば、MCP server の変更が 遅延 や error rate を悪化させていないかを継続的に見られます。

特に注意したいのは、MCP server 自体よりも外部依存先が詰まるケースです。Tool がデータベース、検索 API、CRM、チケットシステム、内部 REST API を呼ぶ場合、負荷試験ではその downstream の レート制限、timeout、再実行、circuit breaker も見る必要があります。エージェント は失敗時に再試行や別 tool 呼び出しを行うことがあり、想定以上に負荷を増幅する可能性があります。

実務で確認したいポイント

まず、MCP server の代表 tool call を洗い出し、読み取り系、書き込み系、重い検索系、外部 API 依存系に分けて負荷シナリオを作ってください。全 tool を同じ負荷で叩くより、実際の エージェント ワークフロー に近い比率で試す方が意味があります。

次に、SLO を定義します。たとえば p95 遅延、error rate、timeout rate、downstream API の レート制限 到達率、認証失敗率、同時 セッション 数を確認します。

結局、このブログ記事をどう読むべきか

Hosted MCP server は エージェント 時代の backend API です。エージェント 連携を本番に出す前に、Locust や Azure Load Testing で性能と失敗時の挙動を検証することが、安定した エージェント 運用の前提になります。