フロントエンドを作りたいのにAPIがまだできていない、という状況はよくあります。かといって待っていては進まないので、仮のデータで組み立てることになりますが、その場しのぎで書いたダミーデータは、本物のAPIに差し替えた瞬間に壊れがちです。件数が少なすぎてレイアウトが崩れる、長い名前で表示がはみ出す、エラー時の表示を作り忘れていた——こうした手戻りは、モックの作り方を工夫すれば減らせます。この記事では、APIができる前に開発を進める手順を、レスポンス設計からモックの用意、テストデータ生成、スキーマ検証まで順番に紹介します。
1. 返ってくるレスポンスの形を決める
最初にやるべきは、コードを書くことではなく「どんなJSONが返ってくるか」を関係者と合意することです。ここが曖昧なままだと、後から項目名の違いや階層の違いで作り直しになります。決めるべきなのは、項目名と型、必須かどうか、配列の場合の入れ物の形（データを直接配列で返すのか、dataやitemsといったキーで包むのか）、そしてページングの方式です。特に、日時の形式（ISO 8601かUnixタイムスタンプか）、IDの型（数値か文字列か）、金額の単位は、後から変わると影響範囲が広いので早めに固めます。数値のIDは桁が大きいとJavaScriptで精度が落ちることがあるため、文字列で扱う判断も検討に値します。まずは実際に返ってきそうなJSONを1件書き出して、それをチーム共通の出発点にします。
2. ステータスコードとエラー時の形も決めておく
見落とされやすいのが、成功時以外の設計です。実装が終わってから「エラー時の表示がない」と気づくのは、よくある手戻りです。HTTPステータスリファレンスで、200と201の違い、204（本文なし）、400（リクエストが不正）と401（未認証）・403（権限なし）・404（存在しない）・409（競合）・422（内容が処理できない）の使い分けを確認し、どの状況でどれを返すかを決めます。あわせて、エラー時に返すJSONの形も統一しておきます。エラーコードとメッセージ、項目ごとのバリデーションエラーをどう表現するか、といった部分です。ここが決まっていれば、フロント側は「読み込み中」「成功」「入力エラー」「権限なし」「サーバーエラー」の各状態を最初から作り込めます。後から足すより、最初から状態を並べて作る方が結果的に速く終わります。
この手順で使うツール
HTTP Status Reference
HTTPステータスコードを番号/キーワードで検索 — 説明・用途・ヘッダー例を表示
3. モックのレスポンスを用意する
形が決まったら、実際に返すモックを用意します。HTTP Response Mock Builder では、ステータスコード・レスポンスヘッダー・JSONボディを組み立てて、実際に返ってくる形を確認できます。ここで意識したいのが、成功パターンだけでなく異常系も作っておくことです。空の配列（データが0件のとき表示が崩れないか）、極端に長い文字列（省略表示が効くか）、nullが入る項目（表示側で落ちないか）、そしてエラーレスポンス——これらを用意して切り替えられるようにしておくと、実装しながら各状態を確認できます。実際の開発では、モックサーバーを立てる、開発時だけ差し込むスタブを書く、といった方法を取りますが、いずれの場合も「返す中身の設計」がここで固まっていれば作業は単純です。
この手順で使うツール
HTTP Response Mock Builder
レスポンスを組み立てて curl / fetch / 生HTTP形式で出力
4. 現実的なテストデータを大量に用意する
モックの中身に「テスト1、テスト2、テスト3」のようなデータを入れると、見た目の検証になりません。実際には、名前の長さはバラバラで、住所には改行が入ることもあり、日付は幅広い範囲に散らばります。Fake Data Generator では、名前・メールアドレス・住所・電話番号・日付・数値などを、それらしい形で必要な件数だけ生成できます。件数を変えて生成し、1件のとき、20件のとき、100件のときで表示がどうなるかを確認すると、ページングや無限スクロールの実装漏れに気づけます。ここでのコツは、あえて極端なデータも混ぜることです。極端に長い名前、記号を含む文字列、絵文字、空文字——これらを1件ずつ入れておくと、リリース後に発覚しがちな表示崩れを事前に潰せます。生成したデータはJSONとしてそのままモックに貼り付けられます。
この手順で使うツール
Fake Data Generator
テスト用ダミーデータを一括生成 — JSON / CSV / TSV で出力
5. 本物のAPIと形が一致しているか検証する
最後に、モックと本物のAPIがずれていないかを確認します。ここを飛ばすと、差し替えた瞬間に動かないという事態になります。有効なのが、レスポンスの形をJSON Schemaとして定義しておき、モックと本物の両方を同じスキーマで検証する方法です。JSON Schema Validator にスキーマとデータを入れると、必須項目の欠落、型の違い、想定外の値をその場で検出できます。バックエンドが完成したら、実際のレスポンスを同じスキーマにかけて、合意した形と一致しているかを確認します。ずれていれば、その時点で修正を依頼できるため、フロントに場当たり的な変換処理が増えるのを防げます。スキーマを一度書いておくと、仕様書としても機能し、後から参加した人が形を把握するのにも役立ちます。
この手順で使うツール
JSON Schema Validator
JSON と JSON Schema を並べてリアルタイムバリデーション
まとめ
APIができる前に開発を進めるには「レスポンスの形を合意する → エラー時の設計も決める → モックを用意する → 現実的なテストデータで確認する → スキーマで一致を検証する」という流れが有効です。特に「異常系のモックも作る」「極端なデータを混ぜる」「スキーマで本物と突き合わせる」の3点は、差し替え時の手戻りを大きく減らします。待ち時間を無駄にせず、しかも後で壊れない進め方として押さえておく価値があります。