スマホ(Android)からモックAPIを叩いて動作確認する方法
公開:
この記事の英語版: English
打合せで「このAPIを呼ぶと、こういうデータが返ってきます」と見せたい。外出先で、アプリが受け取るレスポンスの形を確かめたい。バックエンドはまだできていないが、エラーのときに画面がどうなるかは先に決めておきたい——そんなとき、手元にPCがないと何もできない、ということはありません。
この記事では、ScenarioMockでモックAPIを用意し、Androidスマホのアプリ「Mobile API Tester」から叩いて動作を確かめる手順を紹介します。題材は架空のサポートチケット(問合せ)のAPIです。チケットを作って一覧で確かめ、状態を更新し、最後に401と500のエラーを再現します。
ScenarioMockが公開しているデモのモックを使うので、アカウント登録なしで、この記事の手順をそのまま試せます。
準備するもの
- Android端末と Mobile API Tester: Google Play から無料でインストールできます(画面下部にバナー広告が出ます。アプリ内課金はありません)。提供元のToolboxMAppは、ScenarioMockと同じ運営者です
- モックAPIのURL: この記事では、ScenarioMockの公開デモを使います。自分専用のモックを作る場合は、ScenarioMockのアカウント(無料プランで作れます)
Mobile API Tester は、GET・POST・PUT・PATCH・DELETE・HEAD・OPTIONS を送れるRESTクライアントです。ヘッダー、クエリパラメータ、認証(Basic / Bearer)、JSONのリクエストボディを設定でき、レスポンスのステータス・所要時間・サイズ・本文・ヘッダーを確認できます。
モックAPIを用意する
公開デモを使う
この記事では、次のデモを使います。ScenarioMockの共有ギャラリーに掲載しているもので、誰でも叩けます。
| 項目 | 値 |
|---|---|
| URL | https://demo-mock--support-tickets.scenariomock.com |
| 共有ページ | Support Ticket API |
エンドポイントは4つです。
| メソッドとパス | 動き |
|---|---|
POST /tickets |
チケットを作る。送ったJSONに連番の id を付けて保存し、201で返す |
GET /tickets |
チケットの一覧を返す。60秒以内の3回目だけ500を返す |
GET /tickets/:id |
チケットを1件返す。なければ404 |
PATCH /tickets/:id |
送った項目でチケットを更新する。なければ404 |
どのエンドポイントも、Authorization: Bearer <任意の値> を付けないと401を返します。トークンの値は確かめていないので、demo-token など何でもかまいません。
デモのデータは訪問者全員で共有され、6時間ごとに空に戻ります。個人情報や本物のトークンは送らないでください。送ったリクエストは、共有ページのリクエストログで誰でも見られます(Authorization の値は伏せて記録されます)。
自分のモックを作る場合
同じ構成のモックは、ScenarioMockの管理画面から作れます。
- ダッシュボードの「新規プロジェクト」でプロジェクトを作る。プロジェクト画面に表示される Mock URL を控える(
https://<ドメイン>--<プロジェクトのslug>.scenariomock.comの形) - 「エンドポイントを追加」で
GET /ticketsを作る - エンドポイントの画面で「シナリオを追加」から Stateful Collection を選ぶ。State Key を
tickets、ID生成戦略を「連番」にし、各操作のパスを/ticketsと/tickets/:idに書き換える - 認証のチェックを付けるなら、エンドポイントに Conditional のシナリオを足し、「
Authorizationヘッダーがなければ401」のルールを作る。Conditionalは足したエンドポイントにだけ効くので、POST /ticketsなども確かめたい場合は、そのエンドポイントも追加して同じシナリオを足す
Stateful Collectionを使うと、POSTで作ったデータがGETで返ってくるモックになります。作り方の詳細は、管理画面の使い方のページ(/docs)を見てください。
Mobile API Tester から GET を送る
まずはチケットの一覧を取得します。
- メソッドを GET にし、URLに
https://demo-mock--support-tickets.scenariomock.com/ticketsを入力する - 認証で Bearer を選び、トークンに
demo-tokenを入力する - 送信する

ステータスは色とアイコンで表示され、200 なら ✓ が付きます。所要時間とサイズもあわせて表示されるので、レスポンスが重すぎないかの目安にもなります。本文のJSONは整形して表示され、Raw表示に切り替えることもできます。
デモのデータは6時間ごとに空になるので、[](空の配列)が返ってくることがあります。ほかの訪問者が作ったチケットが見えることもあります。
POST で作って GET で取れることを確かめる
次に、チケットを作ります。
- メソッドを POST にし、URLを
.../ticketsにする(認証の Bearer はそのまま) - リクエストボディをJSONにして、次の内容を入力する
{
"subject": "Cannot log in to the app",
"priority": "high",
"status": "open",
"customerEmail": "[email protected]"
}
JSONの整形ボタンで見やすく整えられ、構文のチェックもできます。Content-Type: application/json はボディに合わせて自動で付くので、ヘッダーを手で足す必要はありません。
- 送信すると、201 と、
idが付いたチケットが返ってくる

続けて、もう一度 GET /tickets を送ってください。いま作ったチケットが一覧に含まれているはずです。返ってきた id を使って GET /tickets/<id> を送れば、そのチケットだけを取得できます。
状態の更新も試せます。メソッドを PATCH にし、URLを .../tickets/<id>、ボディを {"status": "resolved"} にして送ると、status だけが変わったチケットが返ります。もう一度 GET すれば、一覧の status も変わっています。
固定のレスポンスを返すだけのモックでは、POSTしても一覧は変わりません。作る→一覧に出る→更新が反映されるという流れを確かめられるのが、データを保存する(ステートフルな)モックの利点です。アプリの「登録したら一覧に戻って表示する」画面を、バックエンドなしで確かめられます。
エラーを再現する
正常系だけでなく、エラーのときにアプリがどう振る舞うかもスマホから確かめられます。
401: トークンを外す
認証を「なし」に切り替えて、GET /tickets を送ります。

ステータスは 401 になり、⚠ のアイコンで表示されます。Mobile API Tester は4xxや5xxのときも本文とヘッダーを表示するので、モックが返したエラーの中身をそのまま読めます。
{
"type": "https://api.example.com/problems/unauthorized",
"title": "Authentication required",
"status": 401,
"detail": "Send an Authorization header with a Bearer token. Any token value is accepted in this demo."
}
レスポンスヘッダーには WWW-Authenticate: Bearer realm="support-tickets" が付いています。本文は RFC 9457 の Problem Details という形式です。エラーレスポンスの形をそろえたい場合は RFC 9457対応のAPIエラーレスポンス設計 で解説しています。
500: 3回目だけ失敗させる
認証を Bearer に戻し、GET /tickets を続けて3回送ります。3回目だけ 500 が返り、✕ のアイコンで表示されます。

これは ScenarioMock の Sequence シナリオで、「60秒以内の3回目だけ500を返す」と設定しているためです。回数は利用者のIPアドレスごとに数え、最初のリクエストから60秒たつと数え直します。4回目は再び 200 が返るので、「失敗したら再送する」処理の確認にも使えます。
いくつか注意があります。
- 前の手順から60秒以内に続けて GET した場合は、3回目より早く500が返ることがあります。60秒待ってから試し直してください
- Wi-Fiとモバイル通信を切り替えるとIPアドレスが変わるので、回数は別に数えられます
- 自分のモックでは、Sequenceで「1回目だけ503」「3回目以降は200」など、回数ごとのレスポンスを自由に決められます。回数はシナリオの画面から0に戻せます
どのエラーをどう確かめるかの観点は、APIエラーレスポンスのテスト設計|観点と再現方法 にまとめています。
スマホでの確認を楽にする使い方
- 履歴から再送する: 送ったリクエストは履歴に自動で保存され(最大100件。4xx・5xxのものも残ります)、タップすれば同じリクエストを呼び出せます。不要なものはスワイプで削除できます。Basic認証の情報とBearerトークンは履歴に保存されません
- cURLでチームに渡す: リクエストを cURL コマンドとして表示・コピーできます。チャットに貼れば、PCの担当者が同じリクエストをそのまま再実行できます。レスポンスやエラーの内容もコピー・共有できます
- 打合せでデモする: ScenarioMockの共有ページのURLを相手に送り、自分はスマホから叩いて見せると、相手は共有ページのリクエストログでリクエストが届く様子を見られます
- 手元の開発サーバーにもつなぐ:
http://のURLにも接続できるので、同じネットワークにある開発中のサーバーを叩くこともできます
スマホのアプリから叩いて動いても、ブラウザで動くWebアプリから呼んだときに同じように動くとは限りません。ブラウザには、ほかのドメインへのリクエストを制限するCORSという仕組みがあり、ネイティブアプリやcURLにはこの制限がないためです(下の「開発チームより」)。ScenarioMockのモックはどのOriginからのリクエストも許可しているので、ブラウザのフロントエンドから直接呼べます。
開発チームより
「curlで叩いて動いたから大丈夫」は、ブラウザから呼ぶAPIには当てはまらない——これは私たち自身がScenarioMockで経験したことです。
2026年9月、ScenarioMockの使い方を説明する文書を書くために、機能の動きを一つずつ確かめていたときのことです。モックはcurlで叩けば問題なく応答していました。ところが、ブラウザで動くフロントエンドから、JSONのボディやAuthorizationヘッダーを付けて呼ぶと、ブラウザが本番のリクエストの前に送る確認(CORSのプリフライト)の段階で止まってしまう設定になっていました。管理画面のAPI向けの「許可するOriginの一覧」が、モックにも当てはまっていたのが原因です。
curlやスマホのネイティブアプリは、CORSの制限を受けません。そのため、こうした道具で確かめている限り、この問題は見えません。いまはモックのホストだけ設定を分けて、どのOriginからでも呼べるように直しています。
スマホからの確認は手軽で、打合せや外出先では特に便利です。ただ、実際にAPIを呼ぶのがブラウザのWebアプリなら、最後はブラウザからも一度呼んで確かめることをおすすめします。
まとめ
- ScenarioMockでモックAPIを用意すれば、PCがなくてもスマホの Mobile API Tester から動作を確かめられる
- ステートフルなモックなら、POSTで作ったデータがGETで返り、PATCHの更新も反映される。登録から一覧表示までの流れを、バックエンドなしで確かめられる
- 認証を外して401、Sequenceで3回目だけ500のように、エラーもスマホから再現できる。4xx・5xxでも本文とヘッダーを読める
- 履歴からの再送とcURLのコピーで、確認したリクエストをそのままチームに渡せる
- 実際のクライアントがブラウザなら、最後にブラウザからも確かめる(CORS)
Mobile API Tester の機能や画面は Mobile API Tester(Androidアプリ)の紹介ページ で紹介しています。モックAPIの考え方や使いどころは モックAPIとは?必要な理由から作り方、無料ツールの選び方まで を見てください。
打合せや外出先でも、スマホからそのまま叩けるモックAPIを作ってみませんか。ScenarioMockなら、POSTしたデータが返るモックやエラーを返すモックを無料で作り、URL1つで共有できます。
スマホから叩けるモックを無料で作る