レンタルしたMacはホスティング施設にはない。テストではそれが強みになる

申し込みを検討していた方から、もっともな質問を2つ受けました。マシンはどこにあるのか。送信元IPの位置情報はそこを指しているのか。正直に答えると、マシンはホスティング施設ではなく、ニュージャージー州にある自社の専用施設にあり、ビジネス向け光回線につながっています。数週間前までは、これは申し訳なさそうに説明すべきことのように感じていました。そうではありません。

データベースの判定

推測ではなく、マシン自身から確認しました。送信元アドレスは、ビジネス向け光回線の事業者のものと判定されます。逆引きDNSは、その事業者の顧客向けアドレス群を指しています。独立した2つの位置情報サービスが、同じ分類をしています。

isp:      Verizon Business
as:       AS701
hosting:  false
proxy:    false
mobile:   false

大事なのは最後のブロックです。通信元で通信を評価するあらゆるシステムにとって、このMacはオフィスに見えます。実際にそうだからです。

テストでそれが重要な理由

ボット対策や不正対策のシステムは、ホスティング事業者のアドレス範囲を疑ってかかります。それは正しい判断です。そのため、新規登録フロー、決済のサンドボックス、広告の検証、アンケートパネル、地域に応じたサービスは、どれもクラウドのIPから来たリクエストには違う動きをします。開発者のノートPCでは通るのにCIでは失敗するテストは、原因がこれだけということがよくあります。

この点について最初に質問してきたお客様は、iOSのQAをしています。そのテストは、クラウドからの通信には違う動きをする本番サービスとやり取りします。その作業では、普通のビジネス回線につながったMacは妥協ではありません。必須の条件です。

ご自身の送信元を確認する

どのマシンの分類も、そのマシン自身から1分で確認できます。当社が実際に実行したコマンドは次のとおりです。

# what address does the world see?
curl -s https://api.ipify.org

# how is it classified?
curl -s "http://ip-api.com/json/<that-address>?fields=isp,as,hosting,proxy,mobile"

# what does reverse DNS say about it?
dig +short -x <that-address>

同じ3つのコマンドをクラウドのCI runnerから実行して比べてください。CIでだけ失敗するテストは、たいていhostingフラグと逆引きDNSのパターンで説明がつきます。

正直に言うと、制約もあります

• 固定または専用のパブリックIPv4はありません。アドレスはビジネス向け光回線で割り当てられたもので、変わることがあります。許可リストに固定アドレスを登録する必要があるなら、この製品は合いません。
• 受信用のポートはありません。MacへはプライベートなTailscaleネットワーク経由か、ブラウザのデスクトップからアクセスします。インターネットには何も公開していません。
• 拠点は1か所です。都市や国は選べません。
• 開発者向けサービスのみです。利用規定の対象は、ご自身のソフトウェアに対するCI、ビルド、テスト、そしてコーディングエージェントを含む開発者ツールです。大規模なスクレイピングや、ほかのサービスの規約の回避は対象外です。本物のネットワークアドレスがあるからといって、試してよいわけではありません。

向いている用途

• クラウドからの通信を別扱いする実サービスに対するQA。
• CI中に本番APIとやり取りするシミュレータやテスト端末。
• 自社のバックエンドがクラウドのアドレス範囲をブロックしているアプリのビルドパイプライン。
• ドキュメントを閲覧し、ボット対策の壁に引っかからずに開発者ツールへサインインするコーディングエージェント。

以前は、設置場所を言葉を選んで説明していました。今は正確に説明しています。このサービスが合うお客様にとっては、正確さこそが売りだからです。