ProxymanでAPIを書き換えて、Androidアプリを実装する
はじめに
アプリ開発中に「このAPIレスポンス、サーバーを待たずにモックで差し替えられたら…」
「異常系の挙動を手元で再現できたら…」と思ったことはありませんでしょうか。
そんな悩みを解決してくれるのが、Proxyman というGUIベースの強力なプロキシツールです。
本記事では、私がAndroidアプリ開発でProxymanを活用した実例とともに、
Map Local、Breakpoint 機能について詳しく紹介いたします。
要約
- Map LocalでAPIレスポンスを自在に差し替える
- Breakpointでリアルタイムに通信を書き換える
- Androidエミュレータとワンクリックで連携
Proxymanとは
Proxyman は、macOS、Windows、iOS向けのGUIプロキシツールで、
iOSやAndroidなどのモバイルアプリ、Webアプリの開発時に役立つ機能が豊富に搭載されています。

- 通信のキャプチャと可視化
- HTTPS通信の中身を確認(SSLプロキシ)
- リクエスト/レスポンスの差し替えや編集
- スクリプトによる高度な操作
特にGUIが分かりやすく、初心者でも扱いやすいのが特長となっています。
主な機能紹介
Map Local:ローカルファイルでレスポンスを差し替え
任意のAPIレスポンスをローカルにあるJSONファイルなどで差し替える機能です。
対象となるURLに対して、そのレスポンスの代わりの内容を設定できます。
単純な機能ですが、アプリの開発において非常に便利で、この機能を利用してアプリを開発していくことが多かったです。
以下のような活用をしました。
- サーバー未実装のAPIを先行してアプリ側で実装・検証
- 一定の条件下で発生するレスポンス(例:エラーコード)の再現
Map Localでできることは以下です。
- 特定のURLのレスポンスを任意のJSONファイルに差し替え
- ステータスコードの変更(200 → 404エラーなど)
- レスポンスヘッダーの追加・変更
- 複数のAPIを同時に差し替え設定
- ワイルドカードを使った柔軟なURL指定
Map Localでできないことは以下です。
- リクエストの内容(ボディやヘッダー)の変更
- 動的な値の生成(現在時刻、ランダム値など)
- 条件分岐によるレスポンスの切り替え
- リクエストの順番や回数に応じた異なるレスポンス
これらの高度な操作が必要な場合は、Breakpoint機能やScripting機能を使用します。
手順は以下です。
- Proxymanで対象APIの通信をキャプチャ
- 右クリック →
Tools → Map Local - 差し替えたいJSONファイルを指定
- アプリを再実行 → レスポンスがローカルの内容に変化する

実際のプロジェクトでの活用例
私が携わったプロジェクトではサーバー側の開発よりも先行してアプリの開発を進める必要がありました。
通常ならモックサーバーを立てるかアプリ側でダミーデータを実装する必要がありますが、
Proxymanを使えば、アプリの実装を一切変更せずにAPIレスポンスを差し替えられることが大きなメリットでした。
具体的な作業フロー
-
APIが本来返すべきレスポンスと同じ形式のJSONファイルを作成
実際のAPIが返す予定のレスポンスのJSONをそのまま用意する{ "user_id": "12345", "name": "テストユーザー", "email": "test@example.com", "premium": true }このファイルを
user_profile.jsonとして保存する -
Proxymanで該当APIをキャプチャして、Map Localを設定
- URL:
https://api.example.com/v1/user/profile - ローカルファイル:
~/Desktop/mock_jsons/user_profile.json
- URL:
-
開発中の値の調整
- premiumフラグをfalseに変更して無料ユーザーの画面を確認
- nameを長い文字列に変更してUIの崩れをチェック
- 異常系のテストのため、エラーレスポンスのJSONに差し替え
このような開発スタイルにより、サーバーの実装を待たずに、様々なパターンのUIや挙動を効率的に実装・検証できました。
特に新規機能の実装では、APIも新規のものが多く、未実装のAPIの代わりにMap LocalでJSONを返すことで、
アプリの開発を止めることなく進めることができました。
Breakpoint:リクエストを一時停止して編集
Breakpoint機能は、HTTPリクエストやレスポンスを一時停止し、その内容をリアルタイムで編集してから通信を再開できる機能です。
Map Localのような事前準備が不要で、その場で思いついたテストケースをすぐに試せるのが最大の利点です。
主な活用シーン。
- エラーレスポンスの動作確認(特定のエラーコードを返して挙動を確認)
- リトライ処理のテスト(1回目は失敗、2回目は成功など)
- 特殊なパラメータでの動作検証(通常では発生しにくい値を設定)
Map Localとの使い分け。
- Breakpoint:その場で思いついたケースを素早くテスト、動的なシナリオ(1回目と2回目で異なる結果)
- Map Local:決まったパターンの繰り返しテスト、複雑なJSONレスポンスの差し替え
なお、Breakpointで通信を停止している間も時間は経過するため、アプリ側のタイムアウト設定には注意が必要です。
タイムアウトを避けるには、ステータスコードなど小さな変更に留めるか、
開発中はアプリの通信タイムアウト設定を長めに調整しておくことをお勧めします。
手順は以下です。
- Proxymanで対象APIの通信をキャプチャ
- 右クリック →
Tools → Breakpoint - リクエストやレスポンスが一時停止されたら、内容を自由に編集
- 編集完了後、「Execute」ボタンで通信を再開

実際に使用した例:ユーザー一覧APIの再読み込みエラーテスト
私の関わったプロジェクトでは、ユーザーの一覧APIのエラー処理テストでBreakpoint機能が特に役立ちました。
アプリの画面再読み込み時のエラーハンドリングが正しく実装されているかを確認する必要があり、
「初回は成功、再読み込み時はエラー」というシナリオをテストする必要がありました。
実際のサーバーでこのような状況を再現するのは難しいため、Breakpointを使って手軽にテストしました。
- 初回のユーザー一覧取得は正常に成功(200)
- ユーザーが画面を再読み込みした際にサーバーエラー(500など)を返す
- エラー時の表示が正しく表示されるか確認
手順は以下です。
- 対象のAPIのURLをBreakpointに設定
- 1回目のリクエストは正常に通す(ユーザー一覧が正しく表示される)
- 2回目のリクエスト(再読み込み時)をキャッチしたら、HTTPステータスコードのみを200から500に変更
- レスポンスボディはそのままで、ステータスコードだけが500になった状態でアプリに返す
- アプリ側でエラー表示が正しく動作するか確認
この方法により、実際のサーバーでエラーを再現することなく、アプリのエラーハンドリングをテストできました。
特に、ネットワークの不安定な状況や、サーバーの一時的な障害を想定したテストが簡単に行えるのが大きなメリットです。
その他の機能
Map LocalやBreakpointほど使う機会は少ないですが、
Proxymanには他にも便利な機能がいくつかあります。
Map Remote:リクエスト先のサーバーをリダイレクト
リクエストの接続先を任意の別サーバーに変更できる機能です。
サーバー側が先行で開発を進めている場合、この機能が特に威力を発揮します。
アプリ側のコードを一切変更することなく、新しいAPIエンドポイントの動作確認ができるため、
サーバー開発者との並行作業がスムーズに進められます。
以下のような場面で活用されます。
- 新規APIがまだ環境にデプロイされていないので、ローカルの開発サーバーに接続
- 特定のAPIだけ開発環境に向け、本番相当環境のアプリで新機能をテスト
- バックエンドの変更をアプリの接続先を変えて事前検証
設定方法もシンプルです。
- 対象の通信を右クリック →
Tools → Map Remote - 新しいリダイレクト先のホスト・ポートを設定
- アプリを操作 → 接続先が切り替わる
Scripting
ProxymanではJavaScriptベースのスクリプトで、
通信内容を条件付きで編集できます。
Map LocalやBreakpointでは対応しきれない、より複雑な要件がある場合に活用できます。
例えば、特定のパラメータが含まれている場合のみレスポンスを変更したり、
リクエストヘッダーを動的に生成したりといった処理が可能です。
ただし、実際の開発においては、Map LocalとBreakpointで大抵の作業は事足りるため、
このScripting機能を必要とする場面はあまりありませんでした。
Proxymanの使用方法
1. インストールと初期設定
Proxymanのインストール
- 公式サイトからダウンロード
- dmgファイルを開いてApplicationsフォルダにドラッグ&ドロップ
- 初回起動時にシステム設定の許可を求められるので許可
証明書のインストール
HTTPS通信を解析するために、Proxymanのルート証明書をインストールする必要があります。
- Proxyman起動後、メニューバーから
Certificate > Install Certificate on this Mac...を選択 - 証明書をインストール
2. Android端末の設定
エミュレータの場合
Proxymanの大きな利点の1つが、エミュレータの自動設定機能です。
- Android Studioでエミュレータを起動
- Proxymanのメニューから
Certificate > Install Certificate on Android > Emulators...を選択 - 「Override Emulator」ボタンをクリック
- 自動的にプロキシ設定と証明書のインストールが完了
自分で設定しようとするとかなり面倒なのですが、
この自動設定により、手動でのプロキシ設定やadbコマンドの実行が不要になります。

この自動設定機能により、私の実際の開発現場では以下のような効率化を実感しています。
CharlesというProxyアプリケーションでは、新しいエミュレータを立ち上げるたびに数分間の設定作業が必要でした。
設定画面を開いて、プロキシサーバーのIPアドレスとポートを入力し、
証明書をダウンロードしてインストールする、という一連の作業です。
Proxymanなら、この作業がワンクリックで完了します。
エミュレータ切り替えの頻度が高い状況では、1日に何度も行うことがあるため、
累積すると相当な時間短縮効果があります。
設定の解除
自動スクリプト使用後は「Revert All Changes」を実行します。
リバートしないとエミュレータがインターネットに接続できない問題が発生します。
Proxyman終了時の設定戻し手順。
- Proxymanのメニューから
Certificate > Install Certificate on Android > Emulator...を選択 - 「Revert All Changes」ボタンをクリック
- エミュレータのプロキシ設定と証明書が元に戻る
実機の場合
- AndroidデバイスとMacを同じネットワークに接続
- Androidの設定 > ネットワークとインターネット > Wi-Fi > 接続中のネットワークを長押し
- 「ネットワークを変更」を選択
- 詳細オプション > プロキシ > 手動 に設定
- プロキシホスト名:MacのIPアドレス、ポート:9090
- 保存して、ブラウザで http://proxy.man/ssl にアクセス
- 証明書をダウンロード
- 証明書のインストール(重要:CA証明書として設定)
- 設定 > セキュリティ > 暗号化と認証情報 > 証明書をインストール
- 「CA証明書」を選択
- ダウンロードした証明書ファイルを選択
- インストール完了後、設定 > セキュリティ > 信頼できる認証情報 > ユーザー タブで確認
3. macOSプロキシ設定の活用
開発中、Macのシステムプロキシを自動的に設定する「Override macOS Proxy」機能も便利です。
これを有効にすると、Mac上で動作するアプリケーションの通信も自動的にProxymanを経由します。
メニューバー > Proxyman > Preferences > General > Override macOS Proxy にチェック。
PCのブラウザで動作するWebアプリケーション開発でも、この機能は便利です。
ChromeやSafariでのAPI通信をProxymanでキャプチャして、Map LocalやBreakpoint機能を活用できます。
ただし、モバイルアプリ開発時はMacの通信ログが邪魔になるため、
この設定のチェックを外すことを推奨します。
まとめ
Proxymanはアプリ開発において、API通信のデバッグと検証を劇的に効率化してくれるツールです。
特に以下の点で優れています。
- Map Local機能による柔軟なレスポンス差し替え
- Breakpoint機能でのリアルタイムな通信編集
- エミュレータの自動設定による開発効率の向上
- 直感的なGUIで初心者でも扱いやすい
サーバー先行開発や、エラーハンドリングのテスト、UI実装の効率化など、
様々な場面で活用できるので、ぜひ試してみてください。
開発の生産性向上に大きく貢献してくれるはずです。
なお、本記事ではAndroidアプリ開発での活用例を中心に紹介しましたが、
ProxymanはWebフロントエンド開発やiOSアプリ開発でも同様に活用できます。
特にWebフロントエンドの場合は、証明書設定などがより簡単になるため、
導入のハードルはさらに低くなります。
Discussion