Mockyとは？カスタムモックHTTPレスポンスに最適な代替サービス

サーバーを立ち上げずに、特定のJSONボディ、ステータスコード、ヘッダーを返すフェイクAPIエンドポイントが必要になることがあります。その場合、Mockyは最短で試せる選択肢です。この記事では、Mockyの使い方、実装時の向き不向き、そして複数エンドポイントや動的レスポンスが必要になったときの移行先を整理します。全体像を確認したい場合は、オンラインAPIモックツール比較とMockyのオープンソースリポジトリも参考になります。

今すぐApidogを試す

Mockyとは？

Mockyは、任意のHTTPレスポンスを返すURLを作成できる無料のオープンソースWebサービスです。ブラウザ上でレスポンス内容を定義すると、MockyがユニークなURLを発行します。そのURLにリクエストすると、設定したステータスコード、ヘッダー、ボディがそのまま返ります。

バックエンド実装やサーバー構築は不要です。ホスト版はmocky.ioで利用でき、コードも公開されているため、必要に応じてセルフホストもできます。

Mockyの基本モデルはシンプルです。

1つのURLに対して、1つの固定レスポンスを返す

この単純さが、Mockyの強みであり、同時に限界でもあります。

Mockyで設定できる内容

Mockyでは、クライアント開発やテストで必要になる基本的なHTTPレスポンスを設定できます。

• ステータスコード: 200、404、500などを指定
• レスポンスボディ: JSON、テキスト、HTMLなど任意の文字列
• HTTPヘッダー: Content-Typeやカスタムヘッダー
• レスポンス遅延: 遅いAPIやネットワーク遅延を再現

作成後は、Mockyが永続的なURLを発行します。そのURLをフロントエンド、E2Eテスト、HTTPクライアントなどに設定すれば、すぐにモックAPIとして使えます。

Mockyの基本的な使い方

たとえば、バックエンドが未実装の状態で、フロントエンドにユーザー情報を返したいとします。

Mockyで次のように設定します。

• Method: GET
• Status: 200
• Header: Content-Type: application/json
• Body:

{
  "id": 42,
  "name": "Ada Lovelace",
  "role": "admin"
}

保存すると、Mockyは次のようなURLを発行します。

https://run.mocky.io/v3/<some-id>

フロントエンドでは、そのURLをAPIエンドポイントとして指定します。

const res = await fetch("https://run.mocky.io/v3/<some-id>");
const user = await res.json();

console.log(user.name); // Ada Lovelace

これで、バックエンドなしで画面実装やテストを進められます。同じ考え方は、サーバーをセットアップせずにオンラインAPIをモックする方法でも解説されています。

Mockyが向いているケース

Mockyは、単発の静的レスポンスを素早く用意したい場合に便利です。

具体的には、次のような場面です。

• アカウントなしで、すぐに1つのモックURLを作りたい
• 固定JSONをチームメイトやサポートチケットで共有したい
• バグ再現用に500 Internal Server Errorレスポンスを返したい
• リクエスト内容によってレスポンスを変える必要がない
• 一時的なフロントエンド開発用のダミーAPIが欲しい

この範囲であれば、Mockyは非常に効率的です。ブラウザだけで作成でき、数分以内に利用可能なURLを取得できます。

Mockyの限界

Mockyは「1 URL = 1 固定レスポンス」という設計です。プロジェクトが大きくなると、このモデルでは足りなくなる場面が出てきます。

主な制限は次のとおりです。

• 動的データを返せない
  
  すべてのリクエストに同じボディを返します。/users/1と/users/2で異なるユーザーを返すような制御はできません。

• リクエストマッチングができない
  
  クエリパラメータ、パスパラメータ、リクエストボディの内容に応じて分岐できません。

• エンドポイント管理が煩雑になる
  
  実際のAPIには複数のエンドポイントがあります。Mocky URLが増えると、リンクの管理が難しくなります。

• チーム作業に向かない
  
  共有ワークスペース、権限管理、バージョン管理のような仕組みはありません。

• OpenAPIスキーマと連動しない
  
  API仕様とモックが別々に管理されるため、仕様とレスポンスがずれやすくなります。

たとえば、フロントエンドチームで次のようなモックが必要になったとします。

• GET /users/42
• GET /orders
• POST /auth/login
• GET /products?category=book

Mockyでは、それぞれが独立したURLになります。共通のベースURLもなく、環境ごとの差し替えも手作業になりがちです。

この段階では、単一レスポンスツールではなく、API全体を管理できるモックプラットフォームを検討するタイミングです。コスト面も含めて比較する場合は、無料および安価なAPIモックサーバーに関するガイドが参考になります。

Mockyの代替案としてのApidog

Apidogは、MockyのようにURLの背後にカスタムレスポンスを用意できる一方で、複数エンドポイント、スキーマ駆動のモック、動的データ、チームコラボレーションにも対応したAPI開発プラットフォームです。

Mockyが解決するのは、主に次の課題です。

1つの固定レスポンスをすぐに返したい

Apidogが解決するのは、より広い課題です。

API全体のモックを、仕様やチーム開発と一緒に管理したい

Apidogでは、エンドポイントを定義すると、ホスト型のモックURLを生成できます。ステータスコード、ヘッダー、JSONボディを設定できる点はMockyと同じですが、それらをAPI設計やOpenAPI仕様と紐づけて管理できます。

Apidogでできること

Mockyのユースケースに加えて、Apidogでは次のような実装ができます。

• スマートモックとAI生成データ
  
  フィールド名やスキーマから値を推測し、emailにはメールアドレス、createdAtには日付のような現実的な値を返せます。

• Faker.jsによる動的データ生成
  
  Faker.jsを組み込むことで、リクエストごとに異なるテストデータを生成できます。

• 条件付きレスポンス
  
  クエリパラメータやリクエスト内容に応じて異なるレスポンスを返せます。

• OpenAPIベースのモック
  
  API仕様からモックを生成できるため、仕様とモックのずれを減らせます。

• チームワークスペース
  
  モックURL、API仕様、テスト、ドキュメントを共有プロジェクト内で管理できます。

もちろん、単純に200と固定JSONを返すだけのエンドポイントも作成できます。小さく始めて、必要になったタイミングで動的データや条件分岐を追加できます。

MockyとApidogの比較

機能	Mocky	Apidog
URLの背後にあるカスタムステータス、ヘッダー、ボディ	はい	はい
無料で開始、セットアップ不要	はい	はい（無料プラン）
単一の静的レスポンス	はい	はい
動的データ（Faker.js、スマートモック）	いいえ	はい
リクエストマッチング/条件付きルール	いいえ	はい
1つのプロジェクトに多数のエンドポイント	いいえ	はい
スキーマ駆動（OpenAPI）モック	いいえ	はい
チームワークスペース + バージョン管理	いいえ	はい
セルフホストオプション	はい（オープンソース）	クラウド + セルフホストオプション

他の選択肢も比較したい場合は、最適なAPIモックツールとRESTエンドポイントモックのまとめも確認できます。

ApidogでMocky URLを置き換える手順

単一のMocky URLからApidogへ移行する場合は、次の流れで進めます。

1. Apidogをダウンロードしてプロジェクトを作成する
2. エンドポイントを追加する 例: GET /users/42
3. レスポンスを定義する
   • ステータスコード
   • ヘッダー
   • JSONボディ
4. モックを有効化する
5. 生成されたモックURLをフロントエンドやテストに設定する

例として、Mockyで使っていた次のレスポンスをApidogに移します。

{
  "id": 42,
  "name": "Ada Lovelace",
  "role": "admin"
}

フロントエンド側では、Mocky URLをApidogのモックURLに差し替えます。

const API_BASE_URL = "https://<apidog-mock-host>";

const res = await fetch(`${API_BASE_URL}/users/42`);
const user = await res.json();

最初は固定レスポンスで十分です。必要になったら、次のように拡張できます。

• GET /users/1とGET /users/2で異なるレスポンスを返す
• ?role=adminのようなクエリで条件分岐する
• Faker.jsで毎回異なるユーザー名やメールアドレスを返す
• OpenAPI仕様から複数エンドポイントをまとめて生成する

既存のMocky URLをすぐにすべて置き換える必要はありません。重要なエンドポイントからApidogに移し、プロジェクトが整理できた段階で古いURLを廃止する進め方が現実的です。

OpenAPIファイルがすでにある場合は、Apidogにインポートすることで、各レスポンスを手作業で作り直す手間を減らせます。

よくある質問

Mockyは無料ですか？

はい。MockyはApache 2.0ライセンスの無料オープンソースソフトウェアです。アカウントなしでモックレスポンスを作成できます。

ただし、Mockyは基本的に単一の固定レスポンスを返すためのツールです。動的データ、複数エンドポイント、チーム管理が必要な場合は、Apidogのようなプラットフォームを検討するとよいでしょう。

mocky.ioとモックサーバーの違いは何ですか？

MockyのURLは、1つの固定レスポンスを返します。

一方、モックサーバーはAPI全体をシミュレートします。複数エンドポイント、リクエストマッチング、動的データ、環境切り替えなどを扱えます。

モックAPIの基本から確認したい場合は、モックAPIとは何かを参照してください。

Mockyでカスタムステータスコードとヘッダーを返せますか？

はい。Mockyでは、ステータスコード、ヘッダー、ボディを自由に設定できます。

たとえば、次のようなエラー応答を作れます。

{
  "error": "Internal Server Error",
  "message": "Unexpected failure"
}

ステータスコードを500に設定すれば、フロントエンドでエラー状態のUIを検証できます。

ただし、リクエスト内容に応じてレスポンスを変えることはできません。常に同じレスポンスが返ります。

Mockyから本格的なモックプラットフォームに切り替えるべきタイミングは？

次のいずれかが必要になったら、切り替えを検討するタイミングです。

• 複数のAPIエンドポイントをまとめて管理したい
• リクエストパラメータによってレスポンスを変えたい
• 毎回異なるリアルなダミーデータを返したい
• OpenAPI仕様とモックを同期したい
• チームでモックAPIを共有したい
• ステージングや本番に近いデータパターンを再現したい

単発の固定レスポンスだけで十分なら、Mockyは引き続き有効です。

まとめ

Mockyは、1つのカスタムHTTPレスポンスをすぐにURL化したい場合に便利な無料ツールです。バックエンドなしでJSONレスポンス、ステータスコード、ヘッダーを返せるため、フロントエンド開発やバグ再現に向いています。

一方で、動的データ、条件付きレスポンス、複数エンドポイント、OpenAPI連携、チーム管理が必要になると、Mockyの単一レスポンスモデルでは足りなくなります。

その場合は、Apidogをダウンロードして、固定レスポンスから始め、必要に応じてスキーマ駆動のモックや動的データ生成に拡張していくのが実装しやすい進め方です。