AIものさし

AIでAPIモックの応答セットを作る方法｜正常・空・エラー・遅延を固定する

AIでAPIモック用の架空応答とシナリオ表を作り、status別のスキーマ、空一覧、エラー、遅延、画面での適用確認を分ける方法です。

AIものさし編集部

AIでAPIのモック応答を作るときは、見栄えのよい成功データを一つ出させるだけでなく、正常、空、エラー、待機中を再現するシナリオを分けます。API仕様に合う架空データと、画面で何を確認したいかを対応させると、同じ条件で修正前後を比べられます。

ここでは、プロジェクト一覧画面を確認するための応答セットを作ります。APIも画面も説明用の架空例です。実際のサーバー、モックツール、画面、認証、通信を動かした結果ではありません。実装済みAPIへ適用する場合は、そのAPIの仕様と確認済みの挙動を基準にしてください。

目次

モックの目的と、確かめられないことを分ける

今回の目的は、クライアントへ返す応答を固定し、画面の分岐を確認する材料を作ることです。データベースへテストデータを投入する作業や、API仕様そのものを新しく決める作業とは分けます。

表は横にスクロールできます

確認したいこと用意する材料モックだけでは分からないこと
一覧の表示既定の項目を持つ正常応答実データが同じ形で返るか
データがない状態空一覧の応答実環境で空になる条件
エラー表示定義済みエラーの応答サーバーが実際にそのエラーを返すか
応答を待つ表示遅延させるシナリオ実通信の速度、タイムアウトの再現性

Mock Service Workerは、ブラウザーやNode.jsでAPIの通信を扱うモックライブラリとして説明されています。こうしたツールは応答を差し替える手段ですが、使用しただけでAPI実装の正しさまで確認できるわけではありません。MSW公式：Introduction（新しいタブで開く）

採用するツール、版、実行環境、どこで通信を差し替えるかを決めます。未定義のリクエストがどう扱われるかも確認し、検証中の画面が意図せず実環境へ通信しない構成を、利用ツールと環境に合わせて用意します。ここでは個別ツールの設定や通信遮断を検証したとは扱いません。

応答の契約から、変更してよい値を決める

まずmethod、path、HTTP status、メディアタイプ、応答スキーマを揃えます。OpenAPIでは、operationの応答をstatusに対応付け、その内容をメディアタイプやスキーマで記述します。本文が同じJSONでも、成功の200とエラーの503を同じシナリオにはしません。OpenAPI 3.1.1：Responses（新しいタブで開く）

次は、架空のGET /projectsの200応答に使うスキーマ例です。OpenAPI文書全体ではなく、説明に必要なスキーマ部分だけを示します。OpenAPI 3.1.1を参照例にしており、すべての版や検証ツールへ無条件に移植するための例ではありません。

{
  "type": "object",
  "required": ["items"],
  "additionalProperties": false,
  "properties": {
    "items": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["project_id", "name", "status"],
        "additionalProperties": false,
        "properties": {
          "project_id": {"type": "string", "pattern": "^demo-[0-9]{3}$"},
          "name": {"type": "string", "minLength": 1},
          "status": {"type": "string", "enum": ["active", "archived"]}
        }
      }
    }
  }
}

この契約なら、AIがstatusへ「進行中」という日本語を入れたり、project_idを省いたりした値を、そのまま正常応答にしません。表示用の訳語と、APIの値を区別します。実在する利用者名や社内案件は不要なので、明らかに架空と分かる値を使います。

正常・空・エラー・遅延を固定のIDで管理する

次の四つを用意します。画面に期待する表示も架空の設計条件で、実際の製品では仕様に合わせて確定します。

表は横にスクロールできます

シナリオID応答条件確認したい表示
projects-one200、項目が1件名前と状態が対応して表示される
projects-empty200、itemsが空配列エラーではなく、データがない案内になる
projects-error503、別に定義したエラー本文エラー案内が出て、空一覧と混同しない
projects-delayedprojects-oneと同じ本文を3秒後に返す条件待機表示と完了後の切り替わりを確認する

projects-oneの本文例です。

{
  "items": [
    {"project_id": "demo-001", "name": "デモ企画", "status": "active"}
  ]
}

projects-emptyは次の形です。

{"items": []}

projects-errorの本文は、200応答のスキーマとは別の契約にします。以下も架空の例であり、実APIが503でこの値を返すという仕様説明ではありません。

{"code": "TEMPORARY_UNAVAILABLE", "message": "デモ用の一時エラー"}

3秒という遅延も、画面を観察するための任意の設定例です。実通信が常にその時間で返るという意味ではありません。HTTPのエラー応答、応答自体がない通信失敗、アプリ側の待ち時間超過は別の条件なので、必要な場合は別シナリオとして定義します。

AIには、本文とシナリオ表を一緒に作らせる

既存のAPI契約から、画面確認用の架空応答セットを作ってください。
入力：method/path/status/media type/schema/確認したい画面状態。
出力1：シナリオID｜適用条件｜status｜media type｜本文ファイル名｜遅延条件｜期待する表示。
出力2：各シナリオのJSON本文。
field名、型、required、enum、nullの扱いを勝手に変えないでください。
正常データ、空データ、エラー、遅延を区別してください。
エラー本文を成功スキーマに合わせて変形しないでください。
毎回ランダムな値を作らず、同じIDで再現できる架空値にしてください。
実際の個人情報、token、内部URLは入れないでください。
未定義のエラー条件や画面仕様は、創作せず確認事項にしてください。

AIの出力がJSONとして読めても、スキーマに合うとは限りません。逆に、スキーマが通るだけでは「名前と状態の対応が適切」「画面が正しく動く」とも判断できません。検査する層を分けます。

サンプルの掲載と、検証を同じ扱いにしない

JSON Schemaのexamplesは、説明用の例を置く注釈で、それ自体が検証を実行する仕組みではありません。例を記載した後、別に検証へ渡す必要があります。JSON Schema公式：Annotations（新しいタブで開く）

まず各本文をJSONとして解析します。次に、statusとメディアタイプに対応するスキーマで検証します。正常と空は200のスキーマ、エラーはエラー用のスキーマを使い、違反を検出したら該当する値と規則を確認します。

不正応答に画面が耐えられるかを調べたい場合は、「required欠落」「未知のenum」などを、正常例とは別の不正シナリオにします。不正な例を通すために本来のスキーマを緩めないでください。どの不正を扱うべきかは、実装側の仕様に合わせます。

画面へ組み込む前後で、失敗の場所を分ける

本文の検証が通ったら、選んだシナリオが実際に適用されたかを確認します。path、method、query、ベースURLなどがずれると、別の応答や実際の通信を見ている場合があります。モックの適用記録と画面を対応付け、成功データが見えたことだけで判断しません。

同じシナリオを切り替えても画面が変わらない場合は、再取得の条件、キャッシュ、前のデータの保持、モックの適用範囲を調べます。本文を作り直す前に、画面が何を受け取ったかを確認してください。

エラー後の再試行、待機中の操作、画面を移動した後の応答などは、JSONファイルだけでは検査できません。必要な操作と期待結果をシナリオ表へ加え、実際の画面で確認した範囲を残します。モックで成功したことを、実サーバーの認可、保存、課金、通知まで成功した証拠にはしません。

仕様が変わったら、応答セットも一緒に確認する

スキーマの版、対象operation、シナリオID、変更した値、本文検証と画面確認の結果を記録します。fieldの追加やenumの変更時は、影響する正常・空・エラーの例を確認し、古い本文を新しい仕様と混ぜないでください。

API仕様そのものを整理する場合は、AIでAPI仕様書のたたき台を作る方法が先です。画面で確認する正常系・異常系の選び方は、AIでテストケースを作る方法も参照できます。

参考資料

資料の確認日：2026年10月20日。応答とシナリオは架空例です。AIによる生成、モック適用、通信、待機時間、実画面や実APIの挙動は未実測です。

質問から自分に合うAIを探す