チームはアプリを1スプリント全体でテストし、ビルドをリリースしますが、1週間後にはサポートに「私の街では価格が異なる」「プッシュ通知が来なかった」「カードで支払えない」といった苦情が殺到します。原因はほとんどいつも同じです：すべてのテストが1つの企業IPから行われており、実際のユーザーは他の地域、ネットワーク、キャリアからアクセスしています。この記事では、IPアドレスを変更せずには物理的に確認できない7つの具体的なQAシナリオを解説し、プロキシを使ったテストインフラの設定方法を示します。
なぜオフィスIPはQAの盲点なのか
今日のほとんどのモバイルアプリは、IPアドレスに基づいて決定を行います：ユーザーの国、インターフェースの言語、通貨、利用可能な支払い方法、機能のセット、さらにはサブスクリプションの価格を特定します。QA部門全体が1つのオフィスから、1つの静的なデータセンターまたは企業ネットワークのIPでテストを行うと、アプリは常にバックエンドから同じ応答を受け取ります。まるですべてのテスターが世界の同じ地点にいるかのようです。
その結果、ジオロケーション、タイムゾーン、通信キャリア、接続タイプに依存するバグは、テスト環境では再現されません。これらは本番環境でのみ発生します。カザフスタンのユーザーがルーブルで価格を見たり、ドイツのユーザーが彼のネットワークでGCMがブロックされているためにプッシュ通知を受け取れなかったり、インドネシアの顧客が彼の地域の支払いプロバイダーが接続されていないためにカードで支払えなかったりします。このようなバグをリリース後に修正するのは、QA段階で捕まえるよりもはるかに高くつきます。
解決策は、リリース前に実際の地理的およびネットワークの多様性をエミュレートすることです。これを実現するために、QAエンジニアはますますプロキシサーバーを使用しています。これにより、テストデバイスやエミュレーターを物理的にそこに行くことなく、任意の国、都市、またはキャリアに「移動」させることができます。
シナリオ1：ジオコンテンツと地域価格
サブスクリプションを持つほとんどのアプリ（ストリーミング、フィットネス、教育）は、異なる国で異なる価格を表示します。これをジオプライシングと呼びます。QAがローカルIPからのみサブスクリプションの申し込みを確認する場合、トルコ、ブラジル、インドのユーザーに対して価格が正しく表示されているか、正しい通貨で、正しい端数処理で表示されているかを確認することはできません。
コンテンツカタログにも同じ問題があります：映画、商品、またはプロモーションのライブラリはしばしば地域的です。実際のユーザーが見るのと同じ画面を見るためには、必要な国に物理的に「現れる」必要があります。このような確認には、レジデンシャルプロキシを使用するのが便利です。これにより、特定の国の実際の家庭ユーザーのIPが提供され、アプリのバックエンドはリクエストを通常のオーガニックトラフィックとして認識します。データセンターからのリクエストとしてではありません。
実践的なチェック：アメリカ、ドイツ、ブラジル、インド、トルコ、日本、ナイジェリア、UAEの8〜10の主要市場でサブスクリプション申し込みシナリオを実行し、価格と通貨のスクリーンショットを記録し、製品の価格表と照合します。これにより、「なぜ私には異なる価格があるのか」という苦情の大部分を解消します。
シナリオ2：ジオブロックとアクセス制限
フィンテックアプリ、ストリーミングサービス、一部のゲームは、法的またはライセンス上の理由から特定の国からのアクセスをブロックします。QAは、アプリが正しく機能する場所だけでなく、アクセスを拒否すべき場所で正しく（クラッシュせずに）拒否することを確認する必要があります。
典型的なバグ：ユーザーは「このサービスはあなたの地域では利用できません」というきれいな画面の代わりに、白い画面または無限のローダーを見ます。これは、開発者が許可された国からのハッピーパスのみをテストしたためです。ジオブロックの確認には、いくつかの禁止された法域からの順次接続が必要であり、実際のSIMカードや出張では現実的ではありませんが、プロキシを使用すれば国ごとに10〜15分かかります。
このシナリオには、国だけでなく都市レベルでの正確なジオロケーションを持つプロキシが適しています。ライセンスが国内の地域に制限されている場合、単に「ドイツ全体」ではなく、特定の州を確認することが重要です。
シナリオ3：A/Bテストと国別の段階的ロールアウト
フィーチャーフラグと段階的ロールアウトはほぼ常にジオロケーションに基づいて設定されています。新しい機能は最初にカナダで有効になり、1週間後にオーストラリアで、その後はすべての地域で有効になります。QAチームが物理的に1つの国にいる場合、フラグが彼らに届くまで、新しいバージョンを他の地域よりも早く見ることはできません。
グローバルリリース前に機能をテストするには、ロールアウトの第一波の国にジオロケーションを変更する必要があります。これは、プロキシとアンチデテクトブラウザやデバイスエミュレーターの組み合わせで解決される最も一般的なタスクの1つです。必要な国にIPを変更し、アプリのセッションを再起動し、他のユーザーよりも早く機能を見て、フラグが100％のオーディエンスに届く前にバグを見つけることができます。
重要な点：A/Bテストには、テストサイクル全体にわたってIPの安定した「登録」が必要です。セッションはリクエスト間で国を飛び回ってはいけません。そうでないと、バックエンドは実験条件を混同し、コントロールグループとテストグループの両方を表示します。
シナリオ4：ローカリゼーションとプッシュ通知
プッシュ通知のテキスト、送信時間、さらには配信自体の事実は、デバイスのジオロケーションに依存することがよくあります。いくつかの国では、プッシュプロバイダー（Firebase、APNs、ローカルSMSゲート）が遅延や代替ルートを介して動作します。モスクワのオフィスからのテスト環境でうまく配信されるものが、インドネシアのユーザーには特定のプッシュサーバーがローカルプロバイダーによってブロックされているために届かないことがあります。
また、インターフェースのローカリゼーションは、システムの言語だけでなく、IPによってトリガーされることがよくあります。英語の電話を持つユーザーがフランスのIPを持っている場合、フランス語の見出しと英語のボタンが混在したインターフェースを見ることがあります。このようなバグは、すべてのQAが1つのジオゾーンからテストしている場合、100％見えません。
推奨プロセス：製品の優先市場から5〜7のロケールを選び、プロキシを介して対応するIPに接続し、デバイス/エミュレーターのシステム言語を変更し、アプリがどのテキストと日付/数値の形式を表示するかを記録します。IP国とシステム言語の不一致は、別の必須ケースであり、しばしば見落とされます。
シナリオ5：支払い方法と不正防止システム
モバイルアプリで利用可能な支払い方法のセットは、ほぼ常に国に依存します。ある地域ではカードとApple Payでの支払いが可能で、別の地域ではローカルウォレット（Mercado Pago、Boleto、UPI、QIWI）のみ、さらに別の地域では通信キャリアを通じた支払いのみが可能です。QAが必要な国から接続できない場合、支払いシナリオの半分は本番環境まで未確認のままとなり、エラーの代償は失われた収益とサポートへの苦情です。
別の問題は、支払いプロバイダーの不正防止システムです。これらは、IPによってトランザクションのリスクを評価します。データセンターのIPからのリクエストは、ほぼ確実に拒否されるか、追加の3D-Secureチェックを受けます。たとえカードが完全に有効であってもです。これにより、テスト結果が歪められます。QAは支払いの拒否を見て、開発者にバグを報告しますが、問題はコードではなく、テストIPが不正防止スコアリングにとって疑わしいように見えることです。
支払いシナリオには、レジデンシャルプロキシまたはモバイルプロキシを使用するのが最適です。これにより、通常のユーザーのトラフィックのように見え、不正防止システムの余分なトリガーを引き起こさず、支払いフローの動作をより正確に把握できます。
シナリオ6：キャリアのモバイルネットワークでの動作
オフィスのWi-Fiで200Mbpsで正常に動作するアプリが、3G/4Gの不安定な接続、キャリアのNATプロキシ、高い遅延のモバイルネットワークではまったく異なる動作をする可能性があります。リクエストのタイムアウト、再試行、ビデオ/オーディオ品質の劣化、オフラインモードの動作などは、安定したオフィスネットワークではなく、モバイルインターネットに近い条件で正確にテストする必要があります。
追加の複雑さ：一部の通信キャリアは独自のプロキシとCGNATを適用しており、サーバーはユーザーの実際のIPではなく、同時に数千の加入者を通過するキャリアの共有IPを認識します。これにより、レート制限やIPによるジオロケーションに影響を与え、アプリはユーザーが物理的にいる場所とは異なる都市にいると「考える」ことがあります。
このような動作を再現するには、必要な国の実際のSIMカードを介してインターネットに接続するモバイルプロキシが必要です。これにより、通常のデータセンターのIPでは得られないNAT、遅延、速度の正確な状況が得られます。
シナリオ7：レート制限とボット対策
多くのモバイルアプリのバックエンドAPIは、1つのIPからのリクエスト数を制限（レート制限）し、キャプチャや行動分析に似たボット対策を使用します。QAチームが1つの企業IPから自動テストを実行していると、しばらくするとサーバーはエラー429で応答し始めたり、リクエストを完全にブロックしたりします。テストがアプリのバグではなく、バックエンドがテストトラフィックを攻撃と見なしたために失敗します。
これは、短時間で数百の同様のリクエスト（登録、ログイン、カートへの追加）を実行する必要がある負荷テストや回帰テストに特に重要です。プロキシプールを介して異なるIP間でリクエストを分散させることで、APIを公正に負荷テストし、不正防止対策による結果の歪みを避けることができます。
このような大量の自動テストには、データセンターのプロキシを使用する方が経済的です。これにより、大量のリクエストに対してより高速で安価に処理でき、このシナリオではジオロケーションよりも速度と接続の安定性が重要です。
QAのためのツールとプロキシ設定
エミュレーター（Android Studio Emulator、Xcode Simulator）での手動QAでは、プロキシはエミュレーターのネットワーク設定を介して設定されます。プロキシサーバーのIPとポート、認証が必要な場合はログインとパスワードを指定します。実際のデバイスでは、Wi-Fi接続の「詳細設定→プロキシ→手動」で同様の設定が利用可能です。
アプリとバックエンド間のトラフィックをキャプチャして分析するために、QAエンジニアはCharles ProxyやProxymanを使用します。これらのツールは、アプリのトラフィックを外部プロキシを介して通過させ、すべてのHTTP/HTTPSリクエスト、ジオロケーションのヘッダー、サーバーの応答を同時に表示します。これは診断に便利です。リクエストの瞬間にバックエンドが「見る」IPと国がすぐにわかります。
AppiumやEspressoを介した自動テストでは、プロキシはセッションのdesired capabilitiesに指定されるか、テストセットを実行する前にデバイスのシステム設定を介して指定されます。モバイルアプリのテスト用のクラウドプラットフォーム（BrowserStack、Sauce Labs）もカスタムプロキシの接続をサポートしており、物理デバイスなしで世界中の異なる国から同じ自動テストシナリオを実行できます。
チームにアプリのウェブバージョンがある場合や、異なるジオロケーションの複数のアカウントを同時にテストする必要がある場合、アンチデテクトブラウザ（Dolphin Anty、AdsPower、Multilogin）を使用するのが便利です。各プロファイルは個別のプロキシにリンクされ、QAエンジニアは異なる国から5〜10のセッションを同時に開いたまま、クッキーやキャッシュの混乱を避けることができます。
各シナリオに適したプロキシの種類
| QAシナリオ | 推奨されるプロキシの種類 | 理由 |
|---|---|---|
| ジオ価格とコンテンツ | レジデンシャル | 通常のユーザーのトラフィックのように見え、不正防止対策をトリガーしない |
| ジオブロック | レジデンシャル | 都市/地域までの正確なジオロケーション |
| A/Bテストとロールアウト | レジデンシャル / データセンター | テスト全体にわたる安定したセッション |
| プッシュ通知とローカリゼーション | モバイル | キャリアを通じた配信の実際の条件を再現 |
| 支払いと不正防止 | レジデンシャル / モバイル | 不正防止システムの誤作動のリスクが低い |
| モバイルキャリアのネットワーク | モバイル | キャリアの実際のSIMカード、NATと遅延の正確なエミュレーション |
| レート制限 / 負荷テスト | データセンター | 大量のリクエストに対する高速度と低コスト |
リリース前のチェックリスト
ビルドを本番環境にリリースする前に、ジオロケーションとネットワークに関連する短いチェックリストを確認してください。これにより、上記のほとんどのバグを解消できます：
- 5つの主要市場でのサブスクリプションの価格と通貨が確認されている
- 禁止された国でのジオブロック画面の正しい表示が確認されている
- グローバルリリース前にロールアウトの第一波の国でフィーチャーフラグがテストされている
- 異なる国の組み合わせからのIPとシステム言語でプッシュ通知が確認されている
- 各主要地域の利用可能な支払い方法が個別に確認されている
- 不正防止システムによる誤作動なしに支払いフローがテストされている
- アプリがWi-Fiだけでなくモバイルネットワーク（3G/4G）でテストされている
- 自動テストが1つのIPからの並列実行時にレート制限で失敗しない
結論
モバイルアプリは、同時に何十もの国、ネットワーク、支払いエコシステムで動作しますが、QAチームは物理的に1つのオフィスに1つのIPで座っています。このようなテスト条件と実際のオーディエンスの間のギャップが、リリースに至る「説明のつかない」バグの大部分を生み出します。上記の7つのシナリオ—ジオ価格、ジオブロック、A/Bロールアウト、プッシュ通知とローカリゼーション、支払い、キャリアのモバイルネットワーク、レート制限—は、これらのリスクの大部分をカバーします。
地域のコンテンツ、価格、または支払いを扱うアプリをテストするチームの場合、実際のユーザーを模倣するためにテストスタックにレジデンシャルプロキシを接続するのが賢明です。また、モバイル通信とプッシュ通知のシナリオには、特定のキャリアに関連付けられたモバイルプロキシを使用することをお勧めします。これにより、ユーザーからの苦情がストアに届く前に、QA段階で重大なバグを見つけることができます。