フロントエンドで <code>GET /users</code> や <code>GET /orders</code> のUIを実装したいのに、バックエンドAPIがまだ使えない――この状況では、リスト、ページネーション、空状態を確認するための現実的なデータが必要です。手作業でJSONを用意する方法は、API仕様の変更に追従しにくく、すぐに実装とのズレが発生します。
API仕様がすでにあるなら、Apidog の Smart Mock を使うことで、設定やコードを書かずにレスポンススキーマからモックデータを生成できます。たとえば name は名前らしい値、email はメールアドレス形式の値として生成されます。
この記事では、EコマースAPIの GET /users と GET /orders を例に、Smart Mockの作成、モックURLの確認、レスポンスの優先順位、想定どおりの値が出ない場合の調整方法を解説します。APIモックの基礎は APIモックとは何か、どのように機能するか、スキーマ制約の詳細は JSON Schema を参照してください。
Smart Mockでできること
Apidogのモック機能では、主に次のレスポンス生成方法を利用できます。
- Smart Mock: API仕様・レスポンススキーマからデータを自動生成
- Response Example: 定義済みのレスポンス例を返す
- Custom Mock: 任意のカスタムレスポンスを返す
- Conditional Mock: リクエストパラメータに応じてレスポンスを切り替える
- Mock Script: リクエストに関連した値を返すスクリプトベースのモック
Smart Mockは、レスポンススキーマさえあれば動作する自動フォールバックです。レスポンス例や個別ルールをあらかじめ作成しなくても、フィールド名・型・JSON Schema制約を基に妥当な値を返します。
つまり、APIを設計またはインポートした時点で、フロントエンドから利用できるモックAPIを用意できます。スキーマを更新すればモックも同じ定義に追従するため、手作業でモックJSONを保守する必要がありません。
開始前の要件
Smart Mockに必要なのは、エンドポイントのレスポンススキーマです。
ApidogでAPIを設計している場合は、各エンドポイントのレスポンス定義にスキーマを追加してください。OpenAPI ファイルをインポートする場合、通常はレスポンススキーマも同時に取り込まれます。
レスポンス定義がない場合、Smart Mockには生成の基準がないため、有用なモックデータを返せません。
Local Mockを使う場合はApidogデスクトップクライアントが必要です。Local Mockはローカルマシン上で実行され、Apidog Webでは利用できません。Apidogをダウンロードして準備してください。
GET /users と GET /orders をモックする
ここでは、小さなストアAPIを例に2つのエンドポイントを作成します。
1. レスポンススキーマを定義する
まず、GET /users を作成し、レスポンスを次の形で定義します。
{
"id": 1024,
"name": "Amara Osei",
"email": "amara.osei@example.com",
"phone": "+1-415-555-0148",
"createdAt": "2026-03-11T09:24:00Z",
"isActive": true
}
次に、注文一覧を返す GET /orders を定義します。
[
{
"orderId": "ORD-58210",
"userId": 1024,
"total": 84.5,
"currency": "USD",
"status": "shipped",
"createdAt": "2026-05-02T14:03:00Z"
}
]
各プロパティには適切な型を設定してください。Smart Mockは型だけでなく、name、email、createdAt のようなプロパティ名も利用して生成値を推測します。
2. モックURLをコピーする
各エンドポイントにはモックURLが自動で割り当てられます。
- DESIGNモード: エンドポイント下部の API タブ
- DEBUGモード: Mock タブ
「クリックしてコピー」でURLを取得できます。ただし、コピーされるのはURLのみです。GET 以外のHTTPメソッドやリクエストボディが必要なAPIでは、呼び出し側でメソッドとボディを指定してください。
Local MockのパスモードURLは次の形式です。
http://127.0.0.1:4523/m1/{projectID}-{versionNo}-{serverNo}/users
IDモードでは、エンドポイントIDを直接指定します。
http://127.0.0.1:4523/m2/{projectID}-{versionNo}-{serverNo}/{endpointId}
Local Mockは、Apidogクライアントが開いている間に自動で起動します。
3. curlでモックを呼び出す
GET /users を呼び出します。
curl http://127.0.0.1:4523/m1/1234567-0-0/users
以下のように、スキーマから生成されたレスポンスが返ります。
{
"id": 3187,
"name": "Diego Marchetti",
"email": "diego.marchetti@example.net",
"phone": "+1-628-555-0113",
"createdAt": "2026-01-27T18:41:22Z",
"isActive": true
}
name が名前形式、email がメールアドレス形式になっている点に注目してください。これは Property Name Matching による生成です。
続いて、注文一覧も呼び出せます。
curl http://127.0.0.1:4523/m1/1234567-0-0/orders
注文オブジェクトの配列が返るため、一覧UI、価格表示、ステータスバッジ、日時フォーマットなどをすぐに実装・検証できます。
Smart Mockのデータ生成優先順位
Smart Mockは、プロパティごとに次の順序で生成方法を決定します。
- モックフィールド(Mock Field)
- プロパティ名マッチング(Property Name Matching)
- JSON Schema
1. モックフィールド
プロパティにモックフィールドを設定した場合、それが最優先です。
- Fixed value: 常に同じ値を返す
- Fakerステートメント: 条件に沿った動的な値を返す
たとえば currency を常に USD にしたい場合は固定値を指定します。status を pending、shipped、delivered の候補から生成したい場合は、Fakerステートメントを設定します。
2. プロパティ名マッチング
モックフィールドが未設定の場合、Smart Mockはフィールド名を組み込みルールと照合します。
たとえば以下のような名前は、意味に合う値として生成されます。
| プロパティ名 | 生成される値の例 |
|---|---|
email |
メールアドレス |
name |
人名 |
phone |
電話番号 |
createdAt |
日時 |
address |
住所 |
独自の命名規則がある場合は、Mock Settingsでルールを追加できます。
3. JSON Schema
名前がルールに一致しない場合、Smart MockはJSON Schemaの型や制約に基づくデフォルト値へフォールバックします。
次のようなJSON Schema制約も反映されます。
enum-
minimum/maximum - 文字列長
pattern-
minItems/maxItems
たとえば、status に列挙値を設定すれば、その候補以外は返されません。
{
"type": "string",
"enum": ["pending", "shipped", "delivered"]
}
配列の最低件数も指定できます。
{
"type": "array",
"minItems": 3
}
また、モックロケールを変更すれば、対象地域に合わせた名前や住所の形式でテストデータを生成できます。
Smart Mockの推測を修正する方法
Smart Mockの生成結果が期待どおりでない場合は、次の順番で調整します。
1. スキーマの制約を強化する
まずはJSON Schemaで表現できる制約を追加します。
{
"sku": {
"type": "string",
"pattern": "^SKU-[0-9]{6}$"
},
"total": {
"type": "number",
"minimum": 0,
"maximum": 100000
},
"status": {
"type": "string",
"enum": ["pending", "shipped", "delivered"]
}
}
この方法は、API仕様そのものを明確にしながらモック出力も改善できるため、最初に検討すべきです。
2. モックフィールドを設定する
スキーマだけで表現しにくい場合は、対象プロパティにモックフィールドを設定します。
-
currencyを必ずUSDにする → Fixed value -
skuを特定パターンで生成する → Fakerステートメント -
statusを決められた候補から生成する → Fakerステートメント
ApidogのFaker機能は Mock.js と同じ考え方に基づいています。式の書き方は ApidogでFakerを使用する方法 を参照してください。
3. プロパティ名マッチングルールを追加する
同じフィールド名が複数のエンドポイントに存在する場合は、ルールをプロジェクト全体に追加します。
- Settings
- General Settings
- Feature Settings
- Mock Settings
の順に開きます。
「New」を選択し、対象フィールド名に一致する条件とモック式を設定してください。たとえば sku のルールを一度定義すれば、プロジェクト内のすべての sku に同じ生成ルールを適用できます。
複数のモック候補がある場合の優先順位
1つのエンドポイントに複数のレスポンス候補がある場合は、Mock Settingsの Default mock method で優先順位を決めます。
Smart Mock First(デフォルト)
Mock Expectation→Smart MockResponse example first
Mock Expectation→Response Example→Smart Mock
重要なのは、Mock Expectationが一致した場合は常に最優先という点です。
たとえば userId=9999 のときだけ404を返す条件付きモックを設定した場合、Default mock methodの設定にかかわらず、その条件付きレスポンスが返されます。
条件付きレスポンスの設定方法は、Apidogでの条件付きAPIレスポンスのモック を参照してください。
実務では、次のように整理するとわかりやすくなります。
- 特定条件のテストが必要 → Mock Expectation
- 常に固定サンプルを返したい → Response Example
- スキーマ準拠の動的データがほしい → Smart Mock
Local Mock、Cloud Mock、Runner Mockの使い分け
モックの生成方法とは別に、モックをどこで実行するかも選択できます。
Local Mock
Apidogデスクトップクライアントを通じてローカルマシンで実行されます。
- URL:
127.0.0.1:4523 - Apidogクライアントを開いている間のみ利用可能
- 個人のフロントエンド開発に向く
- Apidog Webでは利用不可
Cloud Mock
Apidogのサーバー上でホストされるモックです。
- URL:
https://mock.apidog.com - 24時間アクセス可能
- チームメンバーやプレビューデプロイから利用しやすい
- デフォルトではオフのため、環境管理で有効化が必要
- テスト用途向けであり、本番トラフィック向けではない
Runner Mock
チームのインフラストラクチャ上で自己ホストする方式です。
- 社内ネットワーク内でモックを運用したい場合に向く
- チーム共通のモック環境として利用できる
個人開発ではLocal Mock、チームやプレビュー環境ではCloud Mock、ネットワーク内で運用する場合はRunner Mockを選択してください。
比較の詳細は、オンラインAPIモックツール比較 と Apidog Cloud Mockガイド を参照してください。
ルーティング時の注意点
モックURLを利用する際は、次の点を確認してください。
パスは / で始める
モック環境で正しくルーティングするには、エンドポイントパスを /orders のように / で始めます。
先頭に / がないパスや完全URLは、モック環境を期待どおりに経由しない場合があります。
同じメソッド・パスのAPIがある場合
複数のAPIが同じHTTPメソッドとパスを共有している場合、パスモードだけでは区別できません。
対象エンドポイントを明示するには、クエリパラメータを付与します。
?apidogApiId={endpointId}
リフレッシュでデータは再生成される
Smart Mockは動的な値を生成するため、リクエストを更新すると値も変化します。
同じレスポンスが続けて表示される場合は、新しいリクエストではなくキャッシュされた表示を見ている可能性があります。
Apidog CLIで仕様とモックを同期する
Smart Mock自体はGUIおよびクラウド機能であり、Apidog CLI がモックサーバーを起動するわけではありません。
ただし、CLIを使うと、モックの生成元であるAPI仕様を継続的に更新・検証できます。
Smart Mockの品質はレスポンススキーマの品質に依存します。API契約を更新すれば、モック出力も同じ仕様に合わせて変化します。さらに、テストシナリオをCIで実行することで、実際のバックエンドがモックと同じ契約を満たしているか確認できます。
apidog run -t <scenario_id> -e <env_id> -r html,cli
CLIのインストールと認証は次のとおりです。
npm install -g apidog-cli
apidog login --with-token <your-token>
Node.js v16以降が必要です。CI/CDへの組み込み方法は、CI/CDパイプラインでApidogを実行する方法 を参照してください。
よくある質問
Smart Mockを使うためにコードは必要ですか?
不要です。レスポンススキーマが定義されていれば、Smart Mockが自動でデータを生成します。
特定値への固定や複雑な生成ルールが必要な場合のみ、Mock Field、Fakerステートメント、モックスクリプトを使用します。基礎は モックAPIの概要 を参照してください。
モックURLがレスポンスを返さない原因は何ですか?
まず、エンドポイントにレスポンススキーマが定義されているか確認してください。
あわせて次も確認します。
- パスが
/で始まっているか - Local Mockの場合、Apidogクライアントが起動しているか
- 呼び出し先URL、HTTPメソッド、リクエストボディが正しいか
特定の値を常に返すにはどうすればよいですか?
プロパティに Mock Field を設定してください。
- 常に同じ値を返す → Fixed value
- 動的だが制御された値を返す → Fakerステートメント
Mock Fieldは、プロパティ名マッチングやJSON Schemaのデフォルトより優先されます。
チームメンバーはLocal Mockへアクセスできますか?
Local Mockは 127.0.0.1:4523 で動作し、Apidogクライアントが開いている間に利用できます。
常時アクセス可能な共有モックが必要なら、Cloud Mockを有効化してください。Cloud Mockは https://mock.apidog.com でホストされます。
Response ExampleとSmart Mockのどちらが優先されますか?
Default mock methodの設定によります。
- Smart Mock First: Smart Mockを優先
- Response example first: Response Exampleを優先
ただし、一致するMock Expectationがある場合は、常にMock Expectationが最優先です。
まとめ
Smart Mockを使えば、APIレスポンススキーマをそのまま実用的なモックAPIに変換できます。
実装手順はシンプルです。
- エンドポイントのレスポンススキーマを定義する
- APIタブまたはMockタブからモックURLをコピーする
- フロントエンドやcurlから呼び出す
- 出力を調整したい場合は、スキーマ制約・Mock Field・名前マッチングルールを使う
バックエンドの完成を待たずにフロントエンド開発を進めたい場合は、Apidogをダウンロードして、最初のエンドポイントをモックしてみてください。


Top comments (0)