👀

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

に公開
API
エンジニア
mock
tech

こんにちは！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)」**で、下のように設定するだけです。

EchoAPIのMock機能とその実践的な使い方

設定が終わったら、**「Mock」タブに切り替えると、自動的に「Mock URL」**が生成されています。これがいわば、あなた専用のモックサーバーへの入り口です。
EchoAPIのMock機能とその実践的な使い方
このモックURLを、実際のAPIエンドポイントとして使えば、設定した通りのレスポンスが返ってきます。
EchoAPIのMock機能とその実践的な使い方
これで、バックエンドがなくても、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です。
EchoAPIのMock機能とその実践的な使い方
このように設定すると、リクエストごとに異なる日時が返ってくるようになります。
EchoAPIのモック機能とその実践的な使い方
これで、ローカル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では、カスタム関数を使って、より高度なデータ生成ロジックを実装できます。
EchoAPIのモック機能とその実践的な使い方
ここで、fn_orderno という名前で新しい関数を作成し、EchoAPIのAI機能を活用したり、手動でコードを記述したりして、注文番号を生成する関数を定義します。
EchoAPIのモック機能とその実践的な使い方

EchoAPIのモック機能とその実践的な使い方
このように設定すると、リクエストごとにユニークな注文番号が生成されます。
EchoAPIのモック機能とその実践的な使い方
カスタム関数を使えば、APIのレスポンスで起こりうるあらゆるシナリオを、かなり忠実にシミュレーションできるようになります。これは熱いですね！

4. モックの究極！リクエストパラメータに応じてレスポンスを切り替える

決済機能では、「成功」だけでなく、「残高不足」や「アカウントロック」など、様々なエラーパターンを考慮する必要があります。EchoAPIなら、リクエストパラメータに基づいて、返すレスポンスを切り替えることも可能です。

例えば、「残高不足」のシナリオを考えてみましょう。新しい**「期待値 (Expectation)」**を作成し、条件として特定のパラメータ（例: payment_method: "credit_card", amount: 50000）を指定し、それに応じたレスポンスを設定します。
EchoAPIのモック機能とその実践的な使い方

EchoAPIのモック機能とその実践的な使い方
レスポンスは以下のとおりです：

EchoAPIのモック機能とその実践的な使い方

EchoAPIのモック機能とその実践的な使い方

静的なJSONファイルよりも、実際のビジネスロジックに近い形でテストできるため、フロントエンド開発者が様々なロジック分岐を網羅的にテストするのに役立ちます。

結論：モックは「開発の魔法の杖」だった！

ここまで見てきたように、API開発においてモックは単なる「あれば便利」なツールではありません。むしろ、「開発のスピードと質を劇的に高めるための必須スキル」と言っても過言ではないと私は思っています。

モックを効果的に活用すれば、

  • フロントエンド開発者は、バックエンドの完成を待つ必要がなくなり、独立して開発を進められます。
  • テスト担当者も、モックURLさえ共有してもらえれば、APIが未完成な段階から早期に連携テストを開始できます。

そして、EchoAPIのモック機能は、そうしたモックの価値を最大限に引き出してくれる、まさに現代的なツールです。

  • 組み込み変数: 多様なデータを素早く生成。
  • カスタム関数: 複雑なビジネスロジックにも対応。さらに、AIがカスタム関数作成をサポートしてくれるという、まさに至れり尽くせり！

「迅速なイテレーション」「独立した開発」「複雑なシナリオのシミュレーション」が求められる現代の開発現場では、EchoAPIのモック機能は非常に効率的でプロフェッショナルな選択肢となるはずです。

私も最初は「モックって面倒だな…」と思っていましたが、一度使いこなすとその便利さに手放せなくなりました。皆さんもぜひ、EchoAPIのモック機能を試して、API開発をもっとスムーズに、もっと楽しく進めてみてください！もし何か聞きたいことがあれば、いつでも気軽にコメントくださいね！

Discussion