サービス仮想化とは?おすすめツールをご紹介

サービス仮想化は、制御できない依存関係をシミュレートします。モックとの違い、チームがこれを利用する理由、そして主なツール(WireMock, Hoverfly, Mountebank, Apidog)について学びましょう。

INEZA Felin-Michel

INEZA Felin-Michel

6 7月 2026

サービス仮想化とは?おすすめツールをご紹介

Apidog エンタープライズ

オンプレミスデプロイ

SSO & RBAC

SOC 2 準拠

Apidog Enterpriseを見る

あなたのコードは、自分で制御できないサービスに依存しています。決済ゲートウェイ、パートナーAPI、レガシーメインフレーム、あるいは別のチームのマイクロサービスなどです。これらの依存サービスは、メンテナンスで停止したり、テスト実行をレート制限したり、呼び出しごとに課金されたり、不安定なデータを返したりすることがあります。その結果、開発が滞り、CIパイプラインがあなたのコードとは無関係な理由で赤信号になることがあります。

サービス仮想化はこれを解決します。実際の依存サービスを、そのように動作する代替サービスに置き換えることで、完全に制御できるものに対して開発とテストを行うことができます。このガイドでは、サービス仮想化とは何か、モックとスタブとの違い、チームがサービス仮想化を必要とする理由、そしてWireMock、Hoverfly、Mountebank、エンタープライズ向けオプション、およびAPI契約仮想化のためのApidogのモックサーバーの実際のコマンドとともに、その役割を果たすツールについて説明します。

ボタン

サービス仮想化とは

サービス仮想化は、あなたが制御できない依存サービスの振る舞いをシミュレートすることで、アプリケーションが実際のサービスではなく、そのシミュレーションと通信できるようにします。

ここでの「振る舞い」という言葉は重要です。優れた仮想サービスは、単に固定のペイロードを返すだけではありません。リクエストの詳細に一致させたり、異なる入力に対して異なるレスポンスを返したり、呼び出し間で状態を保持したり、遅延や障害を注入したり、実際のシステムと同じプロトコルで通信したりします。目標は、開発やテスト中にあなたのコードが違いを認識できないほど現実的な代替サービスを提供することです。

依存サービスがHTTP APIである場合、「API仮想化」という用語は同じ意味を持ち、「APIシミュレーター」は仮想エンドポイントを生成するツールを指します。どちらも、サービス仮想化のAPIに焦点を当てた部分の同義語として扱ってください。

サービス仮想化 vs モック vs スタブ

これら3つの用語は重複しており、人々は漠然と使いがちです。これらを区別する実用的な方法を以下に示します。

スタブはハードコードされたレスポンスを返します。リクエストを無視し、常に同じ方法で応答します。もしテストがGET /user/42を呼び出し、スタブが固定のユーザーオブジェクトを返すように設定されている場合、送信するIDに関係なく、その同じオブジェクトを返します。スタブは最も単純な形式であり、テストコード内に存在します。

モックは、相互作用も検証するスタブです。それがどのように呼び出されたか(どのメソッドが、どの引数で、何回)を記録するため、テストでコードが依存サービスを正しく使用したことをアサートできます。モックは単体テストツールです。通常、コードと同じ言語で、プロセス内で実行されます。弊社のAPIスタブ vs APIモックの解説では、この区別についてさらに深く掘り下げています。

サービス仮想化は、コード内ではなく、ネットワーク上で動作します。実際のネットワークポート上で、実際のプロトコルを話す実行中のサービスを立ち上げます。アプリケーションは、ベースURLやプロキシ設定を変更することで、本番環境に接続するのと同じ方法でそれに接続します。仮想サービスはステートフルであり、複雑なリクエスト条件に一致させることができ、HTTPステータスコード、ヘッダー、ストリーミング、接続障害などのプロトコルレベルの動作をシミュレートできます。

日常会話では、「モック」と「サービス仮想化」の境界線は曖昧です。多くのチームは、完全に仮想化を行っている場合でも、実行中のHTTPモックサーバーを「モック」と呼びます。それは問題ありません。重要な区別は、プロセス内のオブジェクトを置き換えているのか(モック/スタブ)、それともアプリが接続するネットワークサービスを立ち上げているのか(仮想化)という点です。モック側については、APIモック:知っておくべきことすべてを参照してください。

チームがサービス仮想化を使用する理由

主に3つの問題が導入を促しています。

依存サービスがまだ準備できていない。フロントエンドとバックエンドのチームは並行して作業を進めますが、フロントエンドはバックエンドがAPIをリリースする前に動作するAPIを必要とします。API契約から構築された仮想サービスにより、フロントエンドは今日から現実的なレスポンスに対して開発を進めることができます。誰も待つ必要がありません。

依存サービスが高価であるか、レート制限されている。サードパーティのAPIは、呼び出しごとに課金されたり、厳しくレート制限されたりすることが多いため、ライブサンドボックスに対して完全なテストスイートを実行すると、割り当てと費用を消費します。仮想サービスは無料で利用できるため、CIは1日に数千のシナリオを実行できます。

依存サービスが不安定であるか、制御が難しい。実際の決済プロバイダーに特定のエラーを返させたり、タイムアウトさせたり、不正なレスポンスを送信させたりすることは容易ではありません。仮想サービスは、これらすべてをオンデマンドで生成できるため、本番環境で発生する障害パスをテストすることができます。

また、制御上の利点もあります。実際の依存サービスは、あなたに気づかれずにデータが変化することがあります。仮想サービスは固定された既知の状態を提供するため、テストは決定論的になります。ビルドが成功したということは、あなたのコードが動作しているということであり、リモートシステムがたまたま今日うまく動作したということではありません。

サービス仮想化の仕組み

ほとんどのツールは、2つのパターンのいずれかに従います。

記録と再生。ツールを実際のサービスにプロキシとして向け、一度実際のトラフィックを通過させると、リクエスト/レスポンスのペアがキャプチャされます。後で、実際のサービスを呼び出す代わりに、これらの記録を再生します。レスポンスを手書きする必要がないため、これは高速です。HoverflyのキャプチャモードとWireMockの記録モードはどちらもこの方法で動作します。

仕様駆動型。API契約から、または手動で仮想サービスを定義します。どのリクエストがどのレスポンスに一致するかを宣言し、動的な値を追加し、ステートフルな動作を設定します。これは初期の作業は増えますが、完全な制御を可能にし、実際のサービスがまだ存在しない場合でも機能します。

いずれの方法でも、コアとなる仕組みはリクエストマッチングです。リクエストが到着すると、ツールは一連のルール(パス、メソッド、クエリパラメータ、ヘッダー、ボディ)に対してそれをチェックし、最初の一致に関連付けられたレスポンスを返します。より優れたツールはテンプレート機能を追加するため、レスポンスはリクエストの一部をエコーバックしたり、呼び出しごとに新しい値を生成したりできます。これにより、仮想サービスは静的ではなく、生きているように感じられます。

ツール

ここでは、オープンソースのHTTP中心ツールから大規模なエンタープライズスイートまで、主要なオプションを紹介します。これらは急速に変化するため、コミットする前に各プロジェクトの公式ドキュメントで現在のバージョンと機能を確認してください。

WireMock

WireMockは、HTTP用のオープンソースのAPIモックおよびサービス仮想化ツールです。スタンドアロンプロセスとして、JVMテストに組み込まれて、またはコンテナ内で実行できます。スタブマッピングをJSONとして定義し、WireMockは受信リクエストをそれらと照合します。実際のサービスに対する記録と再生、レスポンステンプレート、ステートフルなシナリオ、障害注入、シミュレートされた遅延をサポートしています。

スタンドアロンJARを実行します。

java -jar wiremock-standalone-3.13.2.jar --port 8080

次に、その管理API経由でスタブを登録します。

curl -X POST http://localhost:8080/__admin/mappings \
  -H "Content-Type: application/json" \
  -d '{
    "request": {
      "method": "GET",
      "url": "/user/42"
    },
    "response": {
      "status": 200,
      "headers": { "Content-Type": "application/json" },
      "jsonBody": { "id": 42, "name": "Ada Lovelace" }
    }
  }'

WireMockは、依存サービスがHTTPであり、JVMまたはコンテナ環境で詳細な制御をしたい場合に最も強力です。マネージドオプションが必要な場合は、商用ホスト型バージョン(WireMock Cloud)もあります。

Hoverfly

Hoverflyは、Goで書かれた軽量なオープンソースのサービス仮想化ツールです。プロキシとして機能し、アプリケーションの外部トラフィックをHoverfly経由でルーティングすることで、実際のレスポンスを記録するか、シミュレートされたレスポンスを再生します。キャプチャ、シミュレート、スパイ、変更、合成、差分など、いくつかのモードで実行されます。

hoverctlコマンドを使用した基本的なキャプチャと再生のフロー:

hoverctl start
hoverctl mode capture
curl --proxy http://localhost:8500 https://api.example.com/user/42
hoverctl export simulation.json
hoverctl mode simulate

Hoverflyの管理APIはデフォルトでポート8888で、プロキシは8500で実行されます。記録と再生のプロキシモデルは、すべてのレスポンスを手書きするのではなく、既存のトラフィックを迅速に仮想化したい場合に最適です。ホスト型Hoverfly Cloudもあります。

Mountebank

Mountebankは、「インポスター(imposter)」を中心に構築されたオープンソースツールです。インポスターは、1つのポートでリッスンし、1つのプロトコルを話す単一の仮想サービスです。HTTPとHTTPSに加えて、MountebankはTCPとSMTPも処理するため、依存サービスが単なるREST APIではない場合に役立ちます。ポート2525上のRESTコントロールプレーンを介して完全に制御します。

インストールして起動します。

npm install -g mountebank
mb

次に、JSONをコントロールポートにPOSTしてインポスターを作成します。

curl -X POST http://localhost:2525/imposters \
  -H "Content-Type: application/json" \
  -d '{
    "port": 4545,
    "protocol": "http",
    "stubs": [{
      "predicates": [{ "equals": { "method": "GET", "path": "/user/42" } }],
      "responses": [{ "is": { "statusCode": 200, "body": "{\"id\":42,\"name\":\"Ada Lovelace\"}" } }]
    }]
  }'

述語(predicates)はどのリクエストが一致するかを決定し、レスポンスは何を返すかを定義します。Mountebankのマルチプロトコル対応は、オープンソースの選択肢の中での差別化要因です。

Parasoft VirtualizeおよびBroadcom Service Virtualization

大規模エンタープライズ向けには、Parasoft VirtualizeとBroadcom Service Virtualization(DevTestスイートの一部)が有力な選択肢です。これらは、HTTP以外の多くのプロトコルやメッセージ形式をシミュレートし、仮想サービスを実際のデータソースに接続し、多数の環境にわたる仮想化を一元的に管理する必要があるチーム向けに構築された商用プラットフォームです。

Parasoft Virtualizeは、幅広い業界標準プロトコルとメッセージ形式、さらに外部データソースから供給されるデータ駆動型仮想サービスのサポートを謳っています。Broadcomの製品も、並行開発とテストのための仮想化環境を提供し、同様のエンタープライズシナリオを対象としています。どちらもエンタープライズライセンスとセットアップのオーバーヘッドがあるため、少数のRESTエンドポイントではなく、レガシープロトコル(メインフレーム、MQ、固定長メッセージ)を大規模に仮想化する場合に適しています。依存サービスが通常のHTTP APIである場合、上記のオープンソースツールまたはAPIプラットフォームがはるかに低いコストで対応できます。現在のプロトコルリストと価格については、各ベンダーに確認してください。

Apidog: API契約のための軽量なサービス仮想化

仮想化する必要がある依存サービスが契約で定義されたHTTP APIである場合、Apidogは別途ツールなしでその部分をカバーします。APIを設計またはインポートすると、Apidogは自動的にそのモックサーバーを立ち上げます。バックエンドコードが存在する前でも、フロントエンドやテストスイートはスキーマだけで機能するエンドポイントを入手できます。

これが単純なスタブよりも仮想化に近いのは、Apidogのモックがスキーマを認識し、動的であるためです。そのスマートモックはJSONスキーマを読み取り、すべての制約(型、フォーマット、列挙型、必須フィールド)を尊重したレスポンスを生成します。また、フィールド名を組み込みルールと照合するため、emailという名前のフィールドは有効なメールアドレスを返し、cityという名前のフィールドはプレースホルダーのジャンクではなく都市名を返します。より細かい制御のために、Faker.jsに基づいた動的な値は呼び出しごとにリアルなデータを生成し、決定論性が必要な場所では固定値を指定できます。

また、リクエストパラメータに基づいて異なるレスポンスを返すカスタムモックルールを作成することもできます。これは、仮想化を固定スタブと区別するリクエストマッチングの振る舞いです。モックサーバーはGUIまたはヘッドレスで実行されるため、ローカル開発とCIの両方に適しています。1分でAPIをモックする方法で詳細な手順を確認してください。

Apidogが適しているのは:HTTP/RESTなどのAPI契約サービス仮想化です。適さないのは:任意のレガシープロトコル用のプロキシベースの記録・再生ツールではなく、ロードジェネレーターでもありません。それらの目的には、上記のツールが適切な選択肢です。より広範なツールごとの比較については、オンラインAPIモックツールの比較APIモックツールベスト10を参照してください。

始め方

ツールを依存サービスに合わせて選び、逆にしてはいけません。

  1. プロトコルを特定する。プレーンなHTTP/RESTですか?ここにあるほとんどのものが機能し、APIプラットフォームが最も摩擦が少ないです。TCPまたはSMTPが必要ですか?Mountebankです。大規模なレガシーエンタープライズプロトコルですか?ParasoftまたはBroadcomです。
  2. 記録か指定か決定する。実際のサービスが存在し、トラフィックをルーティングできる場合は、記録と再生(Hoverfly、WireMockの記録モード)が最速です。まだ存在しない場合は、API契約から仮想サービスを駆動します(Apidog、WireMockスタブ、Mountebankインポスター)。
  3. アプリをそれに接続する。テスト環境または開発環境でベースURLまたはプロキシ設定を変更し、仮想と実際の切り替えが単一の変数で行えるように設定で管理します。
  4. 障害ケースを追加する。エラーパスをテストすることが目的であるため、4xxおよび5xx、タイムアウト、不正な形式のボディに対するレスポンスを追加します。これは、実際の依存サービスではリハーサルできない部分です。
  5. CIで実行する。ラップトップだけで実行される仮想サービスはあなたを助けますが、ビルドを助けるわけではありません。パイプラインに組み込んで、緑色が成功を意味するようにします。GUIなしでCIでヘッドレス実行されるモックが必要な場合は、ヘッドレスAPIモックツールを参照してください。

一般的に仮想依存サービスとライブ依存サービスのトレードオフについては、モックサーバー vs リアルサーバーでそれぞれの使用時期が説明されています。

よくある質問

サービス仮想化はモックと同じですか?厳密には違います。モックは通常、単体テストのためにプロセス内のオブジェクトを置き換え、それがどのように呼び出されたかを検証します。サービス仮想化は、アプリケーションが実際のプロトコルを介して接続するネットワークポート上で実行中のサービスを立ち上げます。人々はHTTP仮想サービスを「モック」とカジュアルに呼びますが、それは問題ありません。しかし、技術的な区別は、プロセス内のオブジェクトかネットワークサービスかという点です。

実際のテスト環境の代わりに仮想サービスを使用すべきなのはいつですか?実際の依存サービスが利用できない、レート制限されている、高価である、または制御が難しい場合に仮想化を使用します。これにより、決定論的で、無料で、常に利用可能なレスポンスが得られ、実際のシステムではトリガーできないエラーをシミュレートできます。最終的な統合の信頼性のために、実際のサービスに対してより小規模なテストセットを維持してください。

仮想サービスはステートフルにできますか?はい。WireMockやMountebankのようなツールは、以前のリクエストに基づいてレスポンスが変化するステートフルなシナリオをサポートしています。例えば、空のカートを返し、その後のPOSTで商品が入ったカートを返すといった具合です。これは、単一の呼び出しではなくワークフローをシミュレートする際に重要です。

有料のエンタープライズツールは必要ですか?多くの非HTTPプロトコルを仮想化している場合や、大規模な組織全体で仮想化を管理している場合にのみ必要です。通常のHTTP APIの場合、オープンソースツール(WireMock、Hoverfly、Mountebank)またはAPIプラットフォームのモックサーバーが、エンタープライズライセンスなしでその役割を果たします。

HTTP APIを仕様から仮想化する最速の方法は何ですか?API定義を、スキーマからモックを生成するツールにインポートします。Apidogはこれを自動的に行います。OpenAPI仕様をインポートするだけで、リアルな動的データを備えたスキーマ認識型モックサーバーが手に入り、レスポンスを手書きする必要はありません。そこから、テストに必要な特定のリクエスト/レスポンス条件のカスタムルールを追加します。

ApidogでAPIデザイン中心のアプローチを取る

APIの開発と利用をよりシンプルなことにする方法を発見できる