【ITニュース解説】7 API-Mocking Patterns Every 2025 Dev Pipeline Needs

現代のシステム開発では、アプリケーションが多くの異なるサービスと連携して動作する「マイクロサービス」という手法が主流になっている。これにより開発は柔軟になる一方で、テストの際に複雑な問題が起きがちだ。一つのテストを動かすために、平均して11もの外部サービスに接続する必要があり、これらはネットワークの不安定さ、テストの失敗（「不安定なCI」と呼ばれる）、そして週末のデプロイ作業を滞らせる原因となる。テスト環境では実際のデータが利用できなかったり、本番環境への負荷を考慮してテストが制限されたり、データが意図せず変更されてしまう可能性もある。

こうした課題を解決し、信頼性を保ちながら迅速な開発を進めるために不可欠なのが「モックAPI」の活用だ。モックAPIとは、実際のサービスが提供するAPIと同じように振る舞う偽物のAPIのことで、実際のサービスに接続することなく、テストや開発を進めることを可能にする。これにより、テストの実行時間を大幅に短縮し、外部サービスへの依存をなくして、より安定した開発プロセスを構築できる。

モックAPIには様々なパターンがあり、用途に応じて使い分けられている。ここでは、2025年の開発現場で特に重要となる7つのモックAPIパターンについて解説する。

一つ目のパターンは「パスベースのステータスシミュレーション」である。これは、テストでシステムが様々なHTTPステータスコード（通信が成功したことを示す200番台、エラーを示す400番台や500番台など）にどう対応するかを検証したい場合に有効だ。しかし、実際のテスト環境では常に正常な応答（200 OK）が返されてしまうことが多い。この問題を解決するために、リクエストするURLのパスに直接ステータスコードを含めることで、モックサーバーがそのパスに応じて特定のステータスコードを返すようにする。例えば、「https://fakeurl.dev/404」にアクセスすれば404エラーが返る、といった具合だ。これにより、特別な設定なしに多様なエラーケースをテストできる上、URL自体がテスト内容を明確にする。FakeURLやBeeceptorといったツールがこの機能を提供している。

二つ目のパターンは「記録と再生（レコード・リプレイ）によるモック」だ。実際のステージング環境には本番に近いデータがあるが、テストで頻繁にアクセスするとレート制限に引っかかったり、データが変更されてしまったりする問題がある。そこで、Keployのようなツールを使って、一度だけ本番環境やステージング環境との実際の通信内容（リクエストとレスポンス）を記録し、その記録した内容をオフラインでモックとして再生する。これにより、本番に近いデータでテストをしながら、外部環境への依存をなくし、テスト時間を大幅に短縮できる。

三つ目のパターンは「OpenAPIからのコントラクトファーストモック」である。フロントエンド（ユーザーインターフェース）とバックエンド（データ処理）の開発を並行して進める際、APIの仕様（コントラクト）が途中でずれてしまうことがある。このパターンでは、OpenAPI仕様というAPIの設計図（YAMLファイル）から直接モックAPIを自動生成する。WireMockなどのツールがこれに対応しており、仕様ファイルが更新されるとリアルタイムでモックも更新されるため、フロントエンドとバックエンドの開発者が常に最新のAPI仕様に基づいたモックを利用できる。これにより、仕様のずれを防ぎ、並行開発をスムーズに進められる。

四つ目のパターンは「ブラウザのみのMirageJS」だ。ReactやVue、Svelteといったモダンなフレームワークで開発されるシングルページアプリケーション（SPA）では、バックエンドがなくてもユーザーインターフェースのデモや開発を進めたい場面がある。MirageJSは、アプリケーションと同じブラウザ内で動作するモックAPIを作成できるJavaScriptライブラリだ。これにより、バックエンドのインフラを用意することなく、フロントエンドだけで機能確認やデモが可能となり、インフラコストもゼロに抑えられる。

五つ目のパターンは「Kubernetesサイドカーモック」だ。コンテナオーケストレーションシステムであるKubernetes環境で、テスト対象のアプリケーションが外部サービスと通信するような状況をシミュレーションしたい場合に利用する。このパターンでは、WireMockのようなモックサーバーを、テスト対象のアプリケーションコンテナと同じPod内に「サイドカー」として配置する。これにより、テスト対象のアプリケーションはあたかも実際の外部サービスと通信しているかのように振る舞い、アプリケーションのコードを変更することなく、Kubernetes環境での統合テストが可能になる。

六つ目のパターンは「カオスインジェクションモック」だ。これは、アプリケーションがネットワーク遅延やサービス停止、エラーといった障害発生時にどのように振る舞うかを検証するためのものだ。ToxiproxyやMockintoshといったツールを使い、意図的にモックAPIに遅延、ランダムなエラー応答、帯域制限などを注入する。これにより、アプリケーションの障害耐性や回復ロジック（リトライ処理など）が正しく機能するかを厳密にテストし、システム全体の堅牢性を高めることができる。

七つ目のパターンは「サーバーレスモック関数」である。AWS LambdaとAPI Gatewayのようなサーバーレスプラットフォームを活用してモックAPIを構築する。このモックは必要に応じて自動的にスケールし、使用されていない間はほとんどコストがかからないため、非常に効率的だ。例えば、APIリクエストのパスに応じて異なるステータスコードを返すLambda関数を作成し、API Gatewayを介して公開することで、オンデマンドで利用可能なモック環境を構築できる。

これらのモックAPIパターンを効果的に活用するためには、まず現在最も大きな外部依存を抱えている部分から手をつけることが重要だ。紹介されているサンプルコードを利用して、CI（継続的インテグレーション）パイプラインにモックを利用したテストジョブを追加し、モックを使ったテストが実際の通信よりも高速であることを確認するジョブを設ける。これにより、モックの性能劣化を防ぎながら、段階的に外部依存を解消し、開発の信頼性と速度を向上させることが可能になる。実際に、ある企業ではこのアプローチにより、不安定だった外部サービスへの依存を大幅に減らし、CIの信頼性が向上し、パイプラインの完了時間が短縮されたという成功事例もある。