【ITニュース解説】How to soak-test your MCP server before AI agents do it for you

AIエージェントが活躍する現代において、システムが長時間にわたり安定して動作することは非常に重要だ。従来のサーバーテストでは、一つのクライアントから手動でいくつかの機能を試す程度の簡単な確認で「OK」とされてきた。しかし、実際のAIエージェントは同時に多数のセッションを立ち上げ、並行して複数の機能を呼び出し、時にはセッションを適切に閉じないといった、人間には想像しにくい複雑な挙動を示す。このような状況下では、従来のテストでは見つからなかった隠れた問題が露呈する。例えば、数時間にわたってメモリ使用量が少しずつ増え続けたり、レスポンスタイムの95パーセンタイル値（p95）がゆっくりと倍になったり、ロードバランサーの背後で複数のサーバーが動いている場合にのみ「セッションが見つからない」といったエラーが発生したりする。これらはシステムが完全にクラッシュするわけではないため、発見が非常に難しい。

このような潜在的な問題を早期に発見するために、「ソークテスト」という方法が注目されている。ロードテストが「システムはどれくらいの量の負荷に耐えられるか」を測るのに対し、ソークテストは「システムが長時間にわたって健全な状態を維持できるか」を問いかける。この記事で紹介する「mcpload」は、このようなソークテストを実行するためのオープンソースツールであり、k6という別の負荷テストツールをベースに開発されている。mcploadを使えば、AIエージェントが利用するMCP（Model Context Protocol）サーバーの長時間稼働における問題点を、自身の開発環境で簡単に、しかも短時間で特定できるのだ。

mcploadによるソークテストは、以下の3つのフェーズで構成される。まず「ウォームアップ」フェーズでは、システムへの負荷が徐々に増加し、キャッシュの構築やコネクションプールの初期化といった起動時の処理が完了するのを待つ。次に「定常負荷」フェーズでは、30分間にわたって一定数のAIエージェントセッションが継続的にサーバーへアクセスし続ける。最後に「クールダウン」フェーズでは、負荷を完全に停止し、サーバーのメモリ使用量などがベースライン近くまで戻るかどうかを確認する。メモリリーク、つまりサーバーが不要になったメモリを適切に解放せず、時間とともにメモリ使用量が増加し続ける問題は、この定常負荷フェーズでメモリが着実に増加するか、クールダウン後もメモリがベースラインに戻らない場合にのみ「問題あり」と判断される。単に起動時に一時的にメモリが増加するだけでは誤報となり、真のリークとはみなされない。シミュレートされるAIエージェントは、実際の挙動を模倣し、初期化、ツール一覧の取得、思考時間を挟みながら1～5ラウンドの並列ツール呼び出し、そしてセッション終了という一連のプロセスを実行する。

mcploadの導入は非常に簡単だ。GitHubのリリースから、自分のPCのOSに合ったファイルをダウンロードし、展開するだけでよい。例えばLinux環境であれば、コマンド一つでダウンロードから解凍まで完了する。展開されたフォルダには、コマンドラインツールのmcpload、MCPをサポートするk6バイナリ、そしてテストシナリオが含まれている。

次に、テスト対象のサーバーをDockerコンテナで起動する。Dockerを使う理由は、サーバーに固定されたCPUやメモリといったリソースを割り当て、他のプロセスから隔離された状態で実行できるためだ。これにより、mcploadはDockerからサーバーのメモリ使用量を正確に読み取ることが可能になる。例として、Node.jsで書かれた公式のMCPリファレンスサーバー「server-everything」をDockerコマンドで起動する。サーバーがポート5101でリッスン状態になったことをログで確認すれば準備完了だ。

サーバーの起動後、まずは1分間の「スモークテスト」を実行して、サーバーが正しく動作するかを軽く確認する。mcploadのrunコマンドにURLや実行時間を指定し、TOOL_MIXやTOOL_ARGSといった環境変数を設定して、どのツールをどのくらいの頻度で呼び出すか、またその際の引数を指定する。TOOL_MIXで指定するツールは、メール送信やデータベースへの書き込み、有料API呼び出しなど、テスト中に何千回も呼び出されても問題ない「安全な」ツールに限定することが重要だ。このスモークテストで「PASS」と表示されれば、基本的な動作は問題ない。

いよいよメインとなる38分間のソークテストを実行する。先ほどのrunコマンドに--scenario soakと--soak-min 30、--warmup-min 3、--cooldown-min 5といったパラメータを追加し、ソークテストの各フェーズの時間を指定する。RATE=2という設定は、毎秒2つの新しいAIエージェントセッションが開始されることを意味し、30分間で約3,600セッションが生成される計算だ。さらに--sampler dockerと--container mcp-under-testを指定することで、mcploadはDockerコンテナのメモリ使用量を10秒ごとに記録し、--out soak.json --html soak.htmlで結果をJSONファイルとHTMLレポートとして出力する。

この記事の著者が自身のラップトップでserver-everythingをテストした結果は非常に良好だった。コンテナのCPUを2コア、メモリを1GiBに制限した環境で、3,780セッション、49,227リクエストが実行され、エラーは0件だった。メモリ使用量は約136MiBでほぼ横ばいを維持し、1分あたり0.12MiBというわずかな増加に留まり、クールダウン後にはベースライン近くまで戻った。p95レイテンシも30分間を通して約21msと安定していた。また、同時接続エージェント数を5から80まで段階的に増やして計測したところ、40エージェントまではスループットが線形に増加したが、80エージェントではレイテンシが急激に上昇したものの、エラーは発生しなかった。これは、この特定のワークロードとリソース設定において、サーバーの性能限界が40から80同時接続エージェントの間にあることを示している。このように、システムの限界をユーザーが発見する前に、開発者自身が把握できることがこのテストの大きなメリットだ。

mcploadは基本的なソークテストだけでなく、さらに特定のシナリオでの問題を発見する能力も持っている。例えば、ロードバランサーの背後でステートフルなセッション（Mcp-Session-Idなど）を使用するサーバーの場合、--scenario lb-checkを使うことで、スティッキーセッションが設定されていない環境で発生しうる「セッションが見つからない」エラーを検出できる。また、AIエージェントがクラッシュするなどしてセッションが適切に閉じられなかった場合に、サーバーがそのセッションに関連する状態をいつまでも解放しないメモリリークがないかどうかも、クールダウンフェーズで確認できる。さらに、--scenario burstを使うと、initialize処理に一度に大量の負荷をかけ、その後200エージェントまで急激に負荷を上げていくような、突発的な高負荷状況での挙動もテストできる。

このようなソークテストは、開発プロセスに組み込むことでさらに効果を発揮する。GitHub ActionsのようなCI/CD（継続的インテグレーション/継続的デリバリー）ツールを利用すれば、新しいコードがプルリクエストとして提出されるたびに自動的にソークテストを実行し、その結果をプルリクエストのコメントとして表示させることができる。これにより、新しいコードがサーバーの性能や安定性に悪影響を与えていないかを常に監視し、問題があればすぐに検知できるため、高品質なシステム開発に貢献する。

mcploadは、異なるプログラミング言語で実装された公式のMCP SDK（Python, Go, Rust, C#など）に対しても同様のテストを実行し、その結果は各開発者と共有される予定だ。もし自身のサーバーでmcploadを試してみて、何か新しい発見があったり、あるいは現状のmcploadにはないけれど将来的にチェックすべきだと思う点があれば、GitHubリポジトリを通じてフィードバックを送ることも可能だ。システムエンジニアを目指す上で、このようなテストの概念やツールを理解し活用する能力は、将来のキャリアにおいて大きな強みとなるだろう。