MockServer 7.6.0レビュー: 1ポートでHTTP/2・gRPC・WebSocketを捌くモック兼プロキシの実力と境界
MockServer is an HTTP(S) mock server and proxy for testing that lets you mock APIs, inspect and modify live traffic, and inject failures. It supports HTTP/1.1, HTTP/2, gRPC, WebSockets, TCP and more on a single port, with additional support for HTTP/3, message brokers, and AI/LLM APIs.
ひと目でわかる
- これは何？
- MockServerはHTTP(S)のモックとプロキシを単一ポートで提供し、gRPCやWebSocket、TCPまでプロトコルを自動判別するJava製ツールである。REST制御プレーンとダッシュボードで期待値(expectation)を登録する設計を、実際のコマンドと制約から読み解く。
- 誰に向いている？
- 既存の依存先APIが未完成、あるいは再現困難で、HTTP以外にgRPCやWebSocket、生TCPも同じテスト基盤で扱いたいチームに向く。逆に、単一プロトコルの単純なスタブで足りる場合や、テスト実行ごとにプロセスを起動したくない組み込み志向のケースでは、MockServerの制御プレーンをHTTP経由で叩く設計が過剰になる。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に Java です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
MockServerが埋めるのは「相手がまだ無い」と「相手が言うことを聞かない」の2つの穴
テストを書くときに詰まる場面は大きく2つある。依存先のAPIがまだ存在しない、あるいは手元で再現できないケースと、依存先が本来と違う振る舞いをしたときに自分のアプリがどう壊れるかを確かめたいケースである。READMEは前者を mock、後者を chaos engineering として並べ、その間に proxy を置いている。プロキシは実トラフィックを記録・検査・改変する用途で、proxy breakpoints で各交換を一時停止し、デバッガのようにステップ実行、編集、中断できると説明されている。
対象読者は、マイクロサービスの結合テストを書いているエンジニア、フロントエンドとバックエンドの並行開発で契約を固定したいチーム、そして障害注入をテストスイートに組み込みたいSRE寄りの担当者である。Java製だが、クライアントはJava、JavaScript/Node、Python、Rubyが用意され、JUnitとSpringのサポートもある。テストコードから制御プレーンを叩く前提の道具立てだと読める。
単一ポートでプロトコルを自動判別するという設計判断
READMEで最も特徴的なのは、HTTP/1.1とHTTPS、HTTP/2、gRPCとgRPC-Web、WebSocket、生TCPを接続の先頭バイトから自動判別し、1つのMockServerポートで処理するという記述である。プロトコルごとの設定を要求しない点が売りになっている。HTTP/3はQUIC上でexperimental扱い、かつ専用のUDPポートを使うと明記されており、ここは自動判別の対象から外れる。
この設計はテスト側の構成を単純にする一方で、ポート番号がテストスイート全体の共有資源になることを意味する。並列実行するテストワーカーごとに別ポートを割り当てるか、後述するクラスタ化された状態管理を使うかの判断が要る。制御プレーン自体も同じポート上のHTTP RESTで提供されるため、モック対象のパスと /mockserver/ 配下の管理パスが同一空間に同居する。パス設計の衝突は自分で避ける必要がある。
expectationの登録とマッチングの粒度
READMEの60秒手順は、モックの実体が expectation というJSON文書であることを示している。httpRequest に method と path を書き、httpResponse に statusCode と body を書いて、PUT /mockserver/expectation に投げる。curl http://localhost:1080/hello が Hello World を返す、という流れである。
マッチングはメソッド、パス、クエリ、ヘッダ、Cookie、ボディに対して行い、ボディはJSON、XML、JSONPath、XPath、正規表現、OpenAPIで照合できるとREADMEは説明する。OpenAPI/Swagger仕様から期待値を直接生成する機能もある。応答側は静的な値に限らず、Velocity、Mustache、JavaScriptによるテンプレート、クラスやクロージャのコールバック、Webhookで動的に組み立てられる。
検証機能も見逃せない。どのリクエストを、どの順序で、何回受け取ったかをアサートできる。つまりモックサーバでありながら、呼び出しの記録と検証までを1つのプロセスで担う。テストダブルとスパイの役割を同じ制御プレーンに寄せた構成だと理解できる。
起動方法はDocker、Homebrew、JAR、Helm、Testcontainersに分かれる
READMEが示す最短経路はDockerである。docker run -d --rm -p 1080:1080 mockserver/mockserver で起動し、同じ1080番にREST制御プレーンが乗る。macOSかLinuxなら brew install mockserver の後、mockserver run --port 1080 で直接起動できる。ポートは --port で指定する。
より実践的な入口として examples/docker-compose 配下にワンコマンドのレシピが用意されている。OpenAPI仕様からのモック生成、record/replayプロキシ、契約検証プロキシ、カオスプロキシの4種で、それぞれ cd examples/docker-compose/mock-from-openapi && docker compose up のように起動し、curl http://localhost:1080/pets で確認する流れがREADMEに書かれている。
実行形態はDocker、docker-compose、mockserver CLI、JVM不要のバイナリバンドル、Helm/Kubernetes、JAR、WAR、Testcontainersと多岐にわたる。マルチインスタンス配備向けに任意のクラスタ化状態も用意されている。APIクライアントから制御プレーンを試したい場合は、examples/postman と examples/bruno が同梱されており、BrunoはOpen Collectionとして開く手順が案内されている。
LLMモックとMCPサーバを同じプロセスに載せた意味
7系ではAI関連の記述が増えている。OpenAI、Anthropic、Gemini、Bedrock、Azure OpenAI、Ollamaのチャット補完APIをモックでき、ストリーミングにも対応するとREADMEは述べる。さらに /mockserver/mcp にMCPサーバを内蔵し、AIコーディングアシスタントから操作できるとしている。JSON-RPCはMCPとA2Aのモック用途として挙げられている。
これはテスト対象がLLM呼び出しを含むアプリケーションに広がったことへの対応である。ただし注意点がある。LLMモックはあくまでHTTP応答の差し替えであり、モデルの出力品質を再現するものではない。ストリーミング形式やツール呼び出しのペイロード形状を固定して、アプリ側のパースとエラーハンドリングを検証する用途だと読むのが妥当である。MCPサーバをテスト用プロセスに同居させる構成は便利だが、テスト実行環境からMCPエンドポイントに到達できることが前提になる。
experimental表記とJava前提という2つの制約
README自身がHTTP/3をexperimentalと明記している。QUICは専用UDPポートを使うため、単一ポートで全部を捌くという売り文句の例外になる。KafkaやMQTTといったメッセージブローカー連携は、AsyncAPI駆動で外部ブローカーに対して行うと説明されており、外部依存が残る。ここも成熟度を過大に評価すべきではない。
もう1つの制約は言語である。実装はJavaで、JVM不要のバイナリバンドルが用意されているとはいえ、テストスイートに組み込む際の第一級クライアントはJava、JavaScript/Node、Python、Rubyに限られる。他の言語からはREST制御プレーンを直接叩くことになり、型付きのクライアントが得られない。
失敗モードとして想像しやすいのは、パス空間の衝突と、期待値のマッチング順序の誤解である。制御プレーンがモック対象と同じポートに同居する以上、/mockserver/ で始まるパスをアプリのAPIとして使う設計は避けるべきだ。また、複数の期待値が同じリクエストにマッチしうる場合の優先順位は、期待値を登録する側の責任で管理することになる。
WireMockやTestcontainersのMockServerモジュールとの違い
同じ領域の代表としてWireMockが挙げられる。両者ともHTTPモックとリクエスト検証を提供するが、MockServerはプロキシ、プロキシブレークポイント、カオス注入、そしてHTTP/2・gRPC・WebSocket・生TCPの自動判別を同じプロセスに同居させている点が異なる。WireMockでgRPCやWebSocketを扱う場合は別の拡張や別プロセスを組み合わせる発想になりやすい。
もう1つの比較軸はTestcontainersである。MockServer自身がTestcontainers経由の起動をサポートしており、JUnitやSpringとの統合も用意されている。つまりTestcontainersは競合ではなく、MockServerをテストライフサイクルに埋め込むための経路の1つとして位置づけられている。コンテナ起動のオーバーヘッドを許容できるなら、この経路が最も素直だろう。逆に、テストごとにプロセスを立てたくない組み込み志向なら、MockServerのHTTP制御プレーン依存は重く感じられるはずだ。
ライセンスとメンテナンスの見え方
ライセンスはApache-2.0である。商用利用や改変、再配布を含む広い利用が想定されるが、実際の適用条件は同梱のLICENSE.mdを確認する必要がある。ここで法的な助言はできない。
メンテナンスの活発さについては、リポジトリがarchivedではなく、7.6.0が2026年8月17日、7.5.0が7月29日、7.4.0が7月4日と、およそ1か月弱の間隔でリリースが続いている事実が確認できる。ただし、これはリリース頻度の話であって品質や安定性の証明ではない。アップグレードコストを見積もる際は、changelog.md を版ごとに追い、experimental扱いの機能に依存していないかを確認するのが現実的である。プロトコル自動判別やMCPサーバのような新しい層は、メジャー番号が上がる過程で挙動が変わりやすい箇所だと考えるべきだ。
編集部の結論
既存の依存先APIが未完成、あるいは再現困難で、HTTP以外にgRPCやWebSocket、生TCPも同じテスト基盤で扱いたいチームに向く。逆に、単一プロトコルの単純なスタブで足りる場合や、テスト実行ごとにプロセスを起動したくない組み込み志向のケースでは、MockServerの制御プレーンをHTTP経由で叩く設計が過剰になる。採用前に確認すべきは、対象プロトコルが自動判別の対象に入っているか、そしてHTTP/3やKafka・MQTT連携がexperimental扱いである点を前提に運用設計できるかである。判断の出発点としては、docker run -d --rm -p 1080:1080 mockserver/mockserver で起動し、/mockserver/expectation にPUTした期待値が /mockserver/dashboard でどう見えるかを自分の目で確かめるのが最短である。
コミュニティノート