「日本IP」の裏取り手順——契約前に決めるのは試用条件、WHOISとGeofeedの検証は試用開始後の5ステップ

販売ページの「日本IP対応」という表記は、そのアドレスがどのレジストリの管理下にあり、対象サイトのジオ判定でどう扱われるかまでは教えてくれません。ただし、WHOISやGeofeedによる裏取りは、払い出されたIPが手元にあって初めて実行できます。契約前に確認できるのは試用の可否・期間・返金条件までで、検証そのものは試用開始後（IP払い出し後）の作業だと切り分けてください。

前提：単一の情報源では保証できない

サービス提供者による地域別カスタマイズは接続元IPアドレスを使って行われることが多いものの、そのIPが利用者本人を指すとは限りません（[RFC 9632][rfc]）。RFC 9632のSecurity Considerationsも、Geofeedデータの利用者は他の情報源とクロスバリデーションするのが一般に賢明だとしています（[RFC 9632][rfc]）。単一の情報源だけで「必ず日本と判定される」と保証することはできません。目的は保証を得ることではなく、判断材料の質を上げることです。

ステップ1：WHOISで割り当てを引く（試用開始後）

JPNIC WHOISはIPv4・IPv6アドレスに加え、10.0.1.0/24 や 2001:db8::/32 のようなCIDR表記でネットワーク情報を検索できます（[JPNIC][jpnic]）。AS番号を検索タイプの指定なしで調べるときは「AS 2515」のようにASの後ろに半角スペースが必要で、番号のみでは検索できません（[JPNIC][jpnic]）。結果が表示されない場合、JPNICはAPNIC・AfriNIC・ARIN・RIPE NCC・LACNICの各WHOISで検索するよう案内しています（[JPNIC][jpnic]）。APNIC Whoisはアジア太平洋地域で配分された資源情報を誰でも検索できるデータベースで（[APNIC][apnic]）、Web版は入力した語がすべてのオブジェクト型とルックアップキーの対象になるため、絞り込みたいときはAdvanced searchのクエリオプションを使います（[APNIC][apnic]）。

ステップ2：Geofeedの所在をたどる

RFC 9632「Finding and Using Geofeed Data」は2024年8月公開のStandards Track文書で、RFC 9092を廃止しています（[RFC 9632][rfc]）。RIRのデータベースがgeofeed:属性を実装していない場合は、inetnum:のremarks:に大文字小文字を区別するトークン「Geofeed 」に続けてURLを1つだけ書く形式が定義されています（[RFC 9632][rfc]）。参照は、対象アドレス範囲を含む最も具体的なinetnum:のものを使わなければなりません（[RFC 9632][rfc]）。RFCは、192.0.2.0/29を探すアプリケーションは、より具体的な192.0.2.0/24が参照を持つため192.0.0.0/22側を無視しなければならない、という例を挙げています（[RFC 9632][rfc]）。取得はHTTPSで行う必要があります（[RFC 9632][rfc]）。

ステップ3：中身を正しく読む

GeofeedファイルはRFC 8805に基づくUTF-8テキストのCSV形式です（[RFC 9632][rfc]）。読むときの要点は次の3つです。

署名がない場合、参照元inetnum:のアドレス範囲外の行は無視する（[RFC 9632][rfc]）。
Geofeedは参照元inetnum:より細かい粒度を持ちうる（[RFC 9632][rfc]）。
Geofeedがある場合、country:やgeoloc:、DNSのgeoloc RRsetなど他の地理的ヒントは無視する。これらは管理上の情報で、実際の設置場所を示さないことがあるため（[RFC 9632][rfc]）。

RPKIによる署名は任意です（[RFC 9632][rfc]）。署名付きの場合、認証子はファイル末尾に「# RPKI Signature:」と「# End Signature:」で囲まれた「#」コメントの並びとして置かれ（[RFC 9632][rfc]）、検証には rpki-client を利用できます（[RFC 9632][rfc]）。同じ範囲をカバーするinetnum:が複数あるときは署名付きが優先され、いずれも署名なしまたは複数署名がある場合はlast-modified:が最新のものを優先します（[RFC 9632][rfc]）。

ステップ4：取得の作法を守る

Geofeedデータは変更頻度が非常に低いため、HTTP Expiresヘッダの指示がなければ週1回より高頻度で取得すべきではなく、UTC深夜0時や月初などの切りのよい時刻は避けるのが望ましいとされています（[RFC 9632][rfc]）。inetnum:の大規模収集はWHOISではなくRIRのFTPサービスを使うべきとされ（[RFC 9632][rfc]）、RPSLプロバイダは問い合わせが過剰な場合、通常は問い合わせ元IPやブロック単位でスロットリングします（[RFC 9632][rfc]）。横断的に集めるならオープンソース実装のgeofeed-finderが全RIRのRPSLから参照を収集し、統合済みの単一ファイルを出力します（[RFC 9632][rfc]）。調査対象サイトの規約とアクセス頻度への配慮も、同じ「負荷をかけない」設計として組み込んでください。

ステップ5：合否ラインは3軸に分けて先に置く

次の3つは別の評価軸です。混ぜると判断を誤ります。

契約表示との一致：WHOISで見えた割り当て組織・レジストリが、事業者の説明と食い違わないか。APNIC配下の管理であることや、登録組織が海外法人であること自体は、それだけでは不合格理由になりません。
Geofeed：最も具体的なinetnum:に参照があるか、該当行の国コードが参照元範囲と整合するか、署名の有無と優先順位を適用した結果はどうか。参照がないなら、何を根拠に「日本」と言えるのかを事業者に確認します。
対象サイトでの実挙動：実際に使うサイトで期待通りか。実装依存で結果が割れる前提で、複数サイトを見ます。

RFC 9632は、Geofeedの利用者は自分でデータを取得・処理すべきであり、第三者が生成・加工したデータセットを取り込むことはその第三者に大きな信頼を置くことになる、と述べています（[RFC 9632][rfc]）。事業者提供の判定スクリーンショットを唯一の根拠にしない、というのがその実務版です。

デメリットと、向いていないケース

手間が重い：IPプール全体には回せず、サンプル調査にならざるを得ません。
レジストリ情報は設置場所を保証しない：country:等は管理上の情報で、実際の設置場所を示さないことがあります（[RFC 9632][rfc]）。Geofeedも事業者側の申告データです。
サイト側の判定は実装依存：同じIPでも結果は割れます。
短期・小規模なら過剰：単発の表示確認が主目的なら、この検証コストは見合いません。料金体系（帯域課金の有無）やIPの検知されやすさは事業者と対象サイトで異なるため、見積り前提として個別に問い合わせてください。
都道府県レベルの粒度や同時接続数が要件なら、この手順では判断できません。別の評価軸が必要です。

まとめ

「日本IP対応」を検証可能な形に分解すると、①レジストリでの割り当て（[JPNIC][jpnic] / [APNIC][apnic]）、②最も具体的なinetnum:からたどるGeofeed（[RFC 9632][rfc]）、③対象サイトでの実挙動、の3層になります。契約前に決めるのは試用条件と合否ライン、実際に潰すのは試用期間中。断定できるのは①と②の状態までで、③は保証できない——この線引きを先に共有しておくと、継続か返金かの判断がぶれません。

[rfc]: https://www.rfc-editor.org/rfc/rfc9632.html [jpnic]: https://www.nic.ad.jp/ja/whois/ja-gateway.html [apnic]: https://www.apnic.net/manage-ip/using-whois/searching/