モックAPIとは?必要な理由から作り方、無料ツールの選び方まで

公開:

「バックエンドAPIがまだ完成していないから、フロントエンドの実装が進められない」——チーム開発をしていると、一度はこの壁にぶつかったことがあるのではないでしょうか。

この問題を解決してくれるのが「モックAPI(Mock API)」です。この記事では、モックAPIの基本的な考え方から、スタブとの違い、具体的な作り方、そして最近注目されている「ステートフルなモックAPI」の活用法まで、実務で使える形でまとめて解説します。

モックAPIとは

モックAPIとは、実際のバックエンドAPIの代わりに、あらかじめ決められたレスポンスを返す「疑似的なAPI」のことです。本物のサーバーやデータベースに接続しなくても、APIを呼び出しているかのように動作させられるため、開発初期段階やテスト工程で広く使われています。

たとえば、次のようなケースで威力を発揮します。

つまりモックAPIは、開発とテストを「本物のバックエンドの完成」から切り離し、並行して進められるようにするための仕組みです。

モックAPIが必要とされる4つの理由

1. フロントエンドとバックエンドの分業開発を可能にする

API仕様(エンドポイント、リクエスト、レスポンスの形)さえ決まっていれば、フロントエンドはバックエンドの実装完了を待たずに開発を始められます。モックAPIを共有すれば、チーム全体が同じ「仮の正解」を見ながら作業できるため、手戻りも減ります。

2. 外部依存を減らし、開発・テストを安定させる

決済、認証、外部の在庫管理システムなど、自分たちでコントロールできない外部APIに依存していると、その外部サービスの障害やレート制限がそのまま自分たちの開発の足かせになります。モックAPIに置き換えることで、外部要因に左右されない安定した開発環境を作れます。

3. 再現しにくいエラーやエッジケースを意図的に発生させられる

「認証トークンが切れたとき」「サーバーが429(レート制限超過)を返したとき」「同じリクエストを3回送ったら3回目だけ失敗するとき」——こうした状況は本番のAPIではなかなか意図的に再現できません。モックAPIであれば、条件やシーケンスを指定してこれらのケースを自在にテストできます。

4. コストとリスクを抑えられる

従量課金の外部APIを開発中に何度も叩くとコストがかさみますし、本番データベースに直接テストデータを書き込むのはリスクがあります。モックAPIを使えば、こうしたコストとリスクを開発初期から切り離せます。

モックAPIとスタブ・サービス仮想化の違い

似た言葉に「スタブ(Stub)」や「サービス仮想化(Service Virtualization)」があります。厳密な定義はツールや文脈によって幅がありますが、一般的には次のように整理されます。

個人開発や中小規模のチームであれば、まずは軽量に始められる「モックAPI」で十分なケースがほとんどです。

モックAPIの作り方: 主な3つのアプローチ

方法1: コードを書いて自作する

Node.jsのjson-serverやExpress、PythonのFlaskなどを使って、自分でモック用のサーバーを書く方法です。柔軟性は高い反面、レスポンスの出し分けやエラーパターンの実装、チームへの共有まで含めると、意外と手間がかかります。

方法2: OSSのモックサーバーツールを使う

MockoonやWireMockのように、ローカルにインストールして使うオープンソースのツールもあります。GUIでエンドポイントを設定できるものが多く、コードを書く方法よりは手軽ですが、チームで共有する場合は各自の環境構築や設定ファイルの同期が必要になることがあります。

方法3: クラウド型のノーコードモックAPIツールを使う

Beeceptorや ScenarioMock のように、ブラウザ上でエンドポイントを作成し、URLひとつで即座にチームに共有できるサービスです。環境構築が不要で、URLを送るだけで誰でもすぐに叩けるのが最大のメリットです。まず試してみたい、チームですぐ共有したいという場合に向いています。

一歩進んだモックAPI: 「ステートフル」という考え方

従来のモックAPIの多くは、同じリクエストには常に同じレスポンスを返す「ステートレス」なものでした。しかし実際のAPIは、たとえば次のように「状態」を持って動作します。

このように、リクエストの履歴や回数、条件によってレスポンスを変化させられるモックAPIを「ステートフルなモックAPI」と呼びます。CRUD操作を伴う本物のAPIに近い挙動をテストしたい場合や、エラーハンドリングのロジックを検証したい場合には、ステートレスなモックだけでは不十分で、ステートフルな仕組みが必要になります。

ScenarioMock は、この「ステートフルなモックAPI」をコードを書かずに構築できるツールです。主な特徴は次のとおりです。

開発チームより

APIを開発する際は、バックエンドとフロントエンドの間でインターフェースを効率よく決めることが重要です。とはいえ実際の開発では、最初に取り決めた仕様のまま進むことは少なく、フロントエンド側のUI/UX変更によってAPIのインターフェースまで変更が必要になる場面が何度もありました。理想を言えば、UIのモックアップと合わせてAPIの挙動まで確認できるのが望ましいのですが、現場ではどうしてもUI/UXの検討が優先され、API側の検証は後回しになりがちです。

私たち自身、POST /users でユーザーを作成したら、その後の GET /users/:id で同じユーザーが取得できる、3回目のリクエストでレート制限に達したら 429 エラーが返る——といった一連の挙動をモックで再現しようとするたびに、その都度サーバー側のコードを書き換える手間に悩まされてきました。ScenarioMockは、「APIのインターフェースを自由に変更しながら、フロントエンドのモックアップと合わせて挙動まで確認したい」というこの課題を解決するために作ったツールです。

ScenarioMockでモックAPIを作る流れ(3分でできる手順)

  1. ScenarioMock にアクセスし、プロジェクトを作成する
  2. 再現したいエンドポイント(例: /api/users)とHTTPメソッド(GET / POST / PUT / DELETEなど)を設定する
  3. 通常時のレスポンス、エラー時のレスポンス、シーケンスによる出し分けなど、必要なシナリオを設定する
  4. 発行されたURLをチームメンバーに共有し、フロントエンドやテストコードから叩いてもらう

コードを書く必要も、サーバーを自前で立てる必要もないため、「まずは触ってみたい」という段階から気軽に始められます。

モックAPI活用のベストプラクティス

よくある質問

Q. モックAPIとダミーデータの違いは何ですか?

A. ダミーデータは「データそのもの」を指す言葉で、モックAPIは「そのデータをHTTPレスポンスとして返す仕組み」を指します。モックAPIの中でダミーデータを使う、という関係になります。

Q. モックAPIは本番環境でも使えますか?

A. 基本的には開発・テスト用途を想定した仕組みです。本番環境で外部APIの代替として恒常的に使うことは想定されていません。

Q. 無料でモックAPIを試すことはできますか?

A. ScenarioMockをはじめ、多くのモックAPIツールには無料プランが用意されています。まずは無料枠で小さなエンドポイントを作り、使用感を確かめてみることをおすすめします。

まとめ

モックAPIは、バックエンドの完成を待たずに開発を進めたり、再現の難しいエラーケースをテストしたりするための強力な仕組みです。特に、リクエストの履歴や条件によってレスポンスが変化する「ステートフルなモックAPI」を使えば、本物のAPIに近い挙動をコードなしで再現できます。

「まずは触って試してみたい」という方は、無料のプロジェクトを作成してステートフルなモックAPIを数分で構築してみてください。

無料でモックAPIを作る