【Mock活用術】EchoAPIで効率的に進めるAPI開発

Last updated at 2025-09-25Posted at 2025-09-19

こんにちは！API開発って、楽しいですよね。でも、その一方で「あー、またAPIができてないのか…」なんて足踏みしちゃう瞬間、ありませんか？今日は、そんなモヤモヤをスッキリ解決してくれる、開発者の強い味方「モック」について、私なりの経験も交えながらお話ししたいと思います。

プロジェクトの初期って、特にスピードが命。でも、バックエンドのAPIがまだできていなかったり、外部との連携がまだだったりして、フロントエンド側でやることがなくなっちゃう…なんて状況、よくある話ですよね。そんな時、実際のデータがなくても開発を止めずに進める**ためのスーパーツールが、このモックなんです。

現場で直面する「モックが必要な3つの瞬間」

想像してみてください。あなたは今、Eコマースサイトのフロントエンドを開発しています。ユーザーが**「即時決済」**ボタンをクリックしたら、フロントエンドはバックエンドの決済API /pay を呼び出す必要があります。成功したら、こんなレスポンスが返ってくる予定です。

{
    "data": {
        "code": 0,
        "message": "success",
        "pay_dtime":"2025-08-10 10:00:00",
        "order_id":"sn12345678"
    }
}

でも、ここで開発は一時停止…。なぜなら、こんな「困った！」が起きてるから。

バックエンドAPIがまだ開発途中：決済成功後の画面遷移やロジックを試したいのに、APIがまだ存在しない。
外部サービスへの依存：決済APIが外部のゲートウェイに依存していて、テスト環境がまだ整っていないため、APIがまともに動かない。
複雑な認証・データ準備が必要：一部のAPIは、呼び出すまでに複雑な認証フローや事前のデータ準備が求められ、開発初期ではそもそも試すことすら難しい。

もし、フロントエンドがバックエンドの完成をただじっと待っているだけだったら、プロジェクト全体の進行が滞ってしまいます。まさに、こんなピンチを救ってくれるのが、モックなんですよね。

昔ながらのモック手法と、その限界

モックにはいくつかの定番手法がありますが、それぞれに「うーん、もう少しどうにかならないかな」という課題が隠れています。

1. ローカルJSONファイルを使う

最もシンプルで手っ取り早いのが、mock/data.json のようなファイルをローカルに用意して、APIリクエスト時にそのファイルを読み込む方法です。

fetch('/mock/pay.json')

でも、これだと…

データが固定されがち：成功・失敗、ユーザーA・ユーザーBなど、多様なシナリオを再現しようとすると、ファイルがどんどん増えて管理が大変になります。
複雑なロジックに対応できない：ページネーションや、リクエスト内容に応じた動的なレスポンスなど、少し凝った処理はモックできません。

2. フロントエンドでリクエストをインターセプトする (`axios-mock-adapter`, `Mock.js` など)

リクエストを途中で横取りし、ブラウザ上でモックデータを返す方法です。JavaScriptで書けるので、ある程度の柔軟性があります。

モック.onPost('/api/pay/confirm').reply(200, {
    "data": {
        "code": 0,
        "message": "success",
        "pay_dtime":"2025-08-10 10:00:00",
        "order_id":"sn12345678"
    }
});

ただ、これも…

プロジェクト固有の仕組みになってしまう：他のプロジェクトや、別の開発者とモックを共有するのが難しい。
モックコードの管理が大変：アプリケーションのコードとモックのコードが混在してしまうため、データ修正や、最終的にモックを削除する作業に手間がかかります。

3. 独自のモックサーバーを立てる (`json-server`, `Easy Mock` など)

独立したモックサーバーを立てて、フロントエンドからのリクエストに応答させる方法です。

でも、これもまた…

構築・維持コストが高い：サーバーのセットアップや管理に手間がかかります。チームで使うならなおさらです。
柔軟性に欠ける：複雑なロジックを再現するには、別途スクリプトを書く必要があり、自由度が限られます。

これらの手法は、確かに特定の問題を解決してくれますが、プロジェクトがスケールしたり、より複雑な要件が出てきたりすると、「柔軟性の低さ」や「動的なデータ生成が難しい」というデメリットが浮き彫りになってくるんですよね。

EchoAPIが提供する、一歩進んだモックの世界

そこで私が「これは使える！」と感じたのが、EchoAPIです。EchoAPIは、モックに関して、より柔軟でパワフルなソリューションを提供してくれます。開発初期のプロトタイピングから、複雑なシナリオのシミュレーションまで、これ一つでかなり幅広く対応できます。

ここでは、さっきの決済API /pay を例に、EchoAPIでどのように多様なモックシナリオを実現できるか、具体的に見ていきましょう。

1. まずは基本！固定レスポンスを返す

一番シンプルな「固定値」のレスポンスを返す方法から。

こんなレスポンスをモックしたいとします。

{
    "data": {
        "code": 0,
        "message": "success"
    }
}

EchoAPIでは、まず新しいAPIを作成します。リクエストメソッドは POST、URLは /pay と設定。次に、「設計 (Design)」タブの「定義済みレスポンス期待値 (Predefined Response Expectations)」**で、下のように設定するだけです。

設定が終わったら、「Mock」タブに切り替えると、自動的に「Mock URL」が生成されています。これがいわば、あなた専用のモックサーバーへの入り口です。

このモックURLを、実際のAPIエンドポイントとして使えば、設定した通りのレスポンスが返ってきます。

これで、バックエンドがなくても、APIからの返り値を自由にシミュレーションできるようになりました！

2. 一歩応用！組み込み変数で動的な値を生成する

次に、レスポンスに動的な要素を加えてみましょう。例えば、決済日時 pay_dtime のように、毎回異なるリアルタイムの値を返したい場合です。

{
    "data": {
        "code": 0,
        "message": "success",
        "pay_dtime":"2025-08-10 10:00:00" // このフィールドは毎回変動させたい
    }
}

EchoAPIには、様々な種類のデータを簡単に生成できる「組み込み変数 (Built-in Variables)」が豊富に用意されています。pay_dtime フィールドの値として、「モックデータ (Mock Data)」を選択し、組み込みの日付・時刻変数**を挿入するだけでOKです。

このように設定すると、リクエストごとに異なる日時が返ってくるようになります。

これで、ローカルJSONの限界を超え、よりリアルなデータフローをシミュレーションできるようになりますね！

3. さらなる進化！カスタム関数で複雑なロジックを実装する

組み込み変数だけでは表現しきれない、もっと複雑なデータ生成が必要な場合もあります。例えば、order_id のように、「sn というプレフィックスに続いて8桁の数字」という特定のフォーマットを持つ値を生成したい、といったケースです。

{
    "data": {
        "code": 0,
        "message": "success",
        "pay_dtime":"2025-08-10 10:00:00", // このフィールドは毎回変動させたい
        "order_id":"sn12345678" // このフィールドは高度にカスタマイズしたい
    }
}

そんな時は、「カスタム関数 (Custom Functions)」の出番です！EchoAPIでは、カスタム関数を使って、より高度なデータ生成ロジックを実装できます。

ここで、fn_orderno という名前で新しい関数を作成し、EchoAPIのAI機能を活用したり、手動でコードを記述したりして、注文番号を生成する関数を定義します。