導入：Interceptorで足りる？それともProxyMan？
Androidで通信デバッグをしていると、
必ず一度はこう悩みます。
「OkHttp Interceptorで十分じゃない？」
「ProxyMan Scriptを使うのは大げさ？」
結論から言うと、
この2つは競合しません。役割が違います。
この記事では、
OkHttp Interceptor と ProxyMan Script の正しい使い分けを、
実務で判断できるレベルまで整理します。
先に結論です。
- Interceptorは「アプリ内部の制御」
- ProxyMan Scriptは「外部から壊す」
- 検証フェーズで使い分ける
まず結論を図にすると
- 通常開発・軽い検証 → OkHttp Interceptor
- 異常系・WebView含む検証 → ProxyMan Script
この前提を持って読み進めると、
迷わなくなります。
OkHttp Interceptorとは
OkHttp Interceptorは、
アプリ内部で通信をフックできる仕組みです。
class LoggingInterceptor : Interceptor {
override fun intercept(chain: Interceptor.Chain): Response {
val request = chain.request()
return chain.proceed(request)
}
}
特徴は以下のとおりです。
- アプリコードとして管理できる
- 条件分岐が書きやすい
- CI・テストとも相性が良い
Interceptorが得意なこと
① 共通ヘッダの付与
認証トークンやUser-Agentの付与は、
Interceptorの王道ユースケースです。
② 通信ログの出力
debugビルド限定でのログ出力も、
Interceptorが最適です。
③ 軽いリクエスト改変
「この条件のときだけヘッダを変える」
といった用途には向いています。
Interceptorの限界
便利なInterceptorですが、
できないことも多いです。
- WebView通信は見えない
- サーバー異常の再現が難しい
- timeoutを自然に起こせない
ここで登場するのが、
ProxyMan Scriptです。
ProxyMan Scriptとは
ProxyMan Scriptは、
アプリの外側から通信を操作する仕組みです。
- 通信を止める
- レスポンスを改変する
- エラーを注入する
アプリ実装に手を入れず、
通信そのものを壊せるのが最大の特徴です。
Scriptの具体的な活用例については、
以下の記事で詳しくまとめています。
ProxyMan Scriptが得意なこと
① timeout・無応答の再現
実機で自然に起きにくい状況を、
確実に再現できます。
② レスポンス破壊
フィールド欠損・型不正など、
サーバーを壊さずに再現可能です。
③ WebView通信の検証
Interceptorでは不可能な領域です。
使い分けを間違えると起きる問題
Interceptorで無理に再現しようとする
コードが検証用ロジックだらけになります。
ProxyManに頼りすぎる
通常開発のデバッグ効率が下がります。
どちらも万能ではありません。
実務でのおすすめ運用
- 通常開発：Interceptor
- 異常系検証：ProxyMan Script
- WebView含む検証：ProxyMan Script
これをチームで共有すると、
デバッグ方針がブレなくなります。
セキュリティ・運用上の注意
- Interceptorのログは本番で出さない
- ProxyMan Scriptはdebug限定
- 検証後は必ず無効化
よくある質問
Q. テストコードではどちら？
自動テストではInterceptor、
手動検証ではProxyManが向いています。
Q. Charlesと比べると？
Script前提ならProxyManの方が柔軟です。
まとめ
- Interceptorは内部制御
- ProxyMan Scriptは外部破壊
- 役割を分けるのが正解
迷ったら：Interceptorで無理をしない。
それが健全な設計です。
コメント