Number Resource Society

IP アドレスの RDAP レコードを読み解く

登録範囲、組織、連絡先、状態を確認し、BGP、RPKI、社内台帳と照合するための実務ガイド。登録情報だけで判断できることと、別途確認すべきことを整理します。

Ann Yong初回公開 2026年8月26日更新 2026年8月26日

このページの内容

レコードが見つかったところから、確認が始まる

RDAP で分かるのは、レジストリに何が登録されているかです。事業を支えるネットワークでは、誰が経路を広告し、どの認可があり、誰がアカウントを管理できるかも確認する必要があります。本稿では検索、各フィールドの読み方、照合、監査の順に説明します。

コード内のアドレス、組織名、日付は説明用です。現在のネットワークを測定した結果ではありません。原文の JSON 例はそのまま残しています。

RDAP レコードから何が分かるのか

RDAP は Registration Data Access Protocol の略です。IPv4 のアドレス範囲、IPv6 プレフィックス、AS 番号（ASN）などの登録データを、標準化された Web クエリで取得し、JSON として返します。運用で重要なのは略称よりも、結果を正しく読み、その限界を理解することです。

応答には登録範囲、情報を提供するレジストリ、識別子、ネットワーク名、分類、状態、関連組織と連絡先、イベント、上位リソース、注記などが含まれます。リソース監査、障害調査、IPv4 移転の事前調査、企業買収、セキュリティ調査、台帳管理に利用できます。

組織に心当たりがあるか。管理、技術、不正利用の窓口は今も有効か。社内台帳と外部の登録は一致しているか。RDAP はこれらを確かめる手掛かりですが、プレフィックスの状態をすべて説明するデータベースではありません。

WHOIS との違いを、使い方から考える

WHOIS も RDAP も登録情報へのアクセス手段です。WHOIS は主にテキストを返し、形式がレジストリごとに異なります。RDAP は JSON、標準クエリ、HTTP/HTTPS、サービス間のリダイレクト、国際化への対応により、機械処理しやすくなっています。RIPE NCC や APNIC もサービスを提供しています。

API 連携や一括照合には便利ですが、共通の形式だからといって各 RIR の分類やポリシーまで同じとは限りません。受け取った値を保存し、意味は提供元の定義に照らして確認します。

RDAP と WHOIS の比較
項目	RDAP	WHOIS
応答形式	構造化 JSON	主にテキスト
通信	HTTP/HTTPS	従来は TCP 43 番ポート
標準フィールド	あり	レジストリごとの差が大きい
自動解析	処理しやすい	複雑になりやすい
リダイレクト	対応	限定的
国際化	対応が充実	従来は限定的
Web／API 連携	適している	構造が一定しない

対象を管理する RDAP サービスへ問い合わせる

IP のクエリは通常 /ip/{IP-address} または /ip/{CIDR-prefix} という形です。/ip/192.0.2.1 は単一アドレス、/ip/192.0.2.0/24 はプレフィックスの例です。単一アドレスを指定しても、それを含む広い範囲のレコードが返ることがあります。

IANA の RDAP ブートストラップ情報は、アドレス範囲と対応するサービスを結び付けます。クライアントはこれを使って権威ある情報源を探せます。RIR の検索画面を使う方法もあります。RIPE NCC の例は https://rdap.db.ripe.net/ip/{address} です。問い合わせ先と取得時刻も記録しておきます。

簡略化した応答を見てみる

次の JSON は、範囲、名前、状態、エンティティ、イベントをまとめた説明用の例です。192.0.2.0/24 や EXAMPLE という名前は実際の調査対象ではありません。実際の応答は、サービスの方針やアクセス権に応じて任意フィールドが省略されたり、別の情報が加わったりします。

{
  "objectClassName": "ip network",
  "handle": "NET-192-0-2-0-1",
  "startAddress": "192.0.2.0",
  "endAddress": "192.0.2.255",
  "ipVersion": "v4",
  "name": "EXAMPLE-NET",
  "type": "DIRECT ALLOCATION",
  "country": "ZZ",
  "status": [
    "active"
  ],
  "entities": [
    {
      "handle": "EXAMPLE-ORG",
      "roles": [
        "registrant"
      ]
    },
    {
      "handle": "EXAMPLE-ABUSE",
      "roles": [
        "abuse"
      ]
    }
  ],
  "events": [
    {
      "eventAction": "registration",
      "eventDate": "2020-01-01T00:00:00Z"
    },
    {
      "eventAction": "last changed",
      "eventDate": "2026-01-15T00:00:00Z"
    }
  ]
}

1. objectClassName：まず対象の種類を確認する

IP ネットワークのオブジェクトクラスは ip network です。autnum は ASN、entity は組織や連絡先、domain はドメイン、nameserver はネームサーバーを表します。プレフィックスを調べる際には、関連する連絡先ではなくネットワーク本体を見ているか、最初に確かめます。

"objectClassName": "ip network"

2. startAddress と endAddress：範囲全体を記録する

この二つは登録範囲の開始・終了アドレスです。192.0.2.45 を調べた結果が 192.0.2.0 から 192.0.2.255 なら、情報はそのネットワークブロックに適用されます。各ホストに独立した登録があるという意味ではありません。

監査では検索のきっかけになったアドレスだけでなく、両端を保存します。社内のプレフィックス、下位への割り当て、実際の広告とは範囲が異なる可能性があるためです。

"startAddress": "192.0.2.0",
"endAddress": "192.0.2.255"

3. ipVersion：IPv4 と IPv6 を区別する

v4 は IPv4、v6 は IPv6 を表します。単純な項目ですが、多数のレコードを処理する場合にアドレス形式やプレフィックスの扱いを混同しないための基本になります。

"ipVersion": "v4"

4. handle：レコードを識別するための番号

handle は、そのレジストリ内でオブジェクトを一意に識別する値です。IP アドレスそのものではなく、関連情報の参照、レコードの追跡、監査記録、リンクの確認、過去データとの比較に使います。

識別子があることと法的な所有権が証明されることは別です。handle を権利証書のように扱わないでください。

"handle": "NET-192-0-2-0-1"

5. name：ネットワーク名と現在の法人名は別のこともある

name はネットワークを人が識別しやすくする名前です。社名変更や買収後も、技術システムには以前のラベルが残ることがあります。

詳しい調査では、エンティティ、組織情報、会社の資料、他の登録情報と照合します。名前が違うという理由だけで即座に異常と判断せず、関係を確認します。

"name": "EXAMPLE-NET"

6. type：提供元の RIR の定義で読む

type は、その RIR の登録モデルに基づくネットワーク分類です。DIRECT ALLOCATION は一例であり、どの RIR でも同じ値や意味になるとは限りません。

まず値を記録し、用語とポリシー上の意味を別途確認します。分類のラベルだけで権利に関する結論を出すことはできません。

"type": "DIRECT ALLOCATION"

7. country：登録国を稼働場所と取り違えない

登録上の国コードは、すべてのサーバーや利用者の所在地を証明するものではありません。ある国の組織に関係する範囲が、別の国でルーティングされ、複数拠点やクラウドで使われ、国外の顧客に提供されることもあります。商用 GeoIP の判定が異なる場合もあります。

場所を調べるなら別の証拠が必要です。例の ZZ は説明用の値であり、実在の国やリアルタイムの位置情報を示していません。

"country": "ZZ"

8. status：active は疎通確認の結果ではない

status は登録オブジェクトの状態を示します。IANA の定義では、ネットワークや ASN の active は運用ネットワークで使うために割り振り・割り当てされている状態です。実際の到達性を測定した結果とは異なります。

現在の BGP 広告、到達性、特定 ASN の認可、有効な ROA、逆引き DNS、本番トラフィックの存在までは証明しません。登録、経路、RPKI、IRR、DNS を別々に確認します。

"status": [
  "active"
]

9. parentHandle：上位の登録をたどる

parentHandle は親ネットワークの登録を識別します。リソースは階層を持ち、小さな範囲が大きな割り振りの中に含まれることがあります。

親を確認すると、下位への割り当て、顧客ネットワーク、リソースの履歴、組織間の関係を理解する助けになります。最初の応答だけでは見えなかった背景も調べられます。

"parentHandle": "PARENT-NET"

10. entities：名前だけで責任を決めない

エンティティは組織、個人、役割や連絡先を表します。独自の handle、連絡情報、roles、関連エンティティ、イベント、注記、リンクを持つことがあります。

組織名を見つけても、それだけで全責任を負う主体とは判断できません。リソースとの関係を示す roles を続けて確認します。

"entities": [
  {
    "handle": "EXAMPLE-ORG",
    "roles": [
      "registrant"
    ]
  }
]

11. roles：必要な窓口につながるかを確かめる

主な役割には registrant、administrative、technical、abuse、noc、billing があります。abuse は不正利用の連絡先、technical は技術連絡先です。一つのエンティティが複数の役割を担う場合もあります。

組織を確認できるか、管理連絡先の権限は今も有効か、技術担当は現職か、不正利用の通報経路が機能するかを確認します。古い連絡先は、障害、移転、セキュリティ事故、アカウント復旧で実害につながります。

"roles": [
  "abuse"
]

"roles": [
  "technical"
]

12. vcardArray：連絡先がすべて公開されるとは限らない

vcardArray は組織名、個人名や役割名、住所、メール、電話などを構造化して表します。毎回すべての項目が返されるわけではありません。

実装、プライバシー方針、アクセス権、情報のマスキング、リソース種別、適用規則によって公開範囲は変わります。重要な項目が見当たらない場合は remarks と notices を読み、情報自体が存在しないと即断しないようにします。

13. events：日時には理由を添えて読む

eventAction は出来事の種類、eventDate は日時です。registration、last changed、expiration、deletion などがあり、監査では登録日と最終変更日が手掛かりになります。

最近の変更は連絡先の更新、組織変更、保守、移転、訂正かもしれません。新しい日時だけで不審とはいえず、古い日時だけで放棄ともいえません。履歴や業務の変化と合わせて理由を確認します。

"events": [
  {
    "eventAction": "registration",
    "eventDate": "2020-01-01T00:00:00Z"
  },
  {
    "eventAction": "last changed",
    "eventDate": "2026-01-15T00:00:00Z"
  }
]

14. remarks：オブジェクト固有の補足を読む

remarks には、特別な事情、制限、情報を隠している理由、過去の経緯、レジストリ固有の説明などが入ります。

JSON の末尾にあるからといって読み飛ばさないでください。他のフィールドをどう解釈するかに関わることがあり、事前調査でも重要です。

"remarks": [
  {
    "description": [
      "Additional registration information."
    ]
  }
]

15. notices：応答全体に関わる条件を確認する

notices は通常、応答の最上位に置かれ、利用条件、プライバシー、著作権、データの非表示、クエリ制限などを伝えます。個別オブジェクトに付く remarks とは対象が異なります。

自動処理でも無視すべきではありません。データがない理由や、返された情報の扱い方が記されている場合があります。

16. links：関連する登録情報へ進む

リンクは現在のオブジェクト、親、関連エンティティ、別表現、その他の登録情報を指します。rel の self や up などが関係を示し、href が宛先を示します。

次の原文例は省略された断片です。RFC 9083 に適合するリンクオブジェクトには value も必要です。関係を理解する例として読み、完全な実装用テンプレートとしてそのまま使わないでください。

"links": [
  {
    "rel": "self",
    "href": "https://example.net/rdap/ip/192.0.2.0/24"
  }
]

最初の確認は、この順で進める

範囲と IP バージョンを確認し、handle、名称、分類、状態を読みます。続いてエンティティ、役割、イベントを調べ、注記、通知、親や関連オブジェクトへのリンクを確認します。表はその際の手引きです。

ここまでで終わりではありません。経路、認可、評判、業務依存も別途調べる必要があります。

RDAP を確認する順序
手順	フィールド	確認すること
1	startAddress / endAddress	登録範囲を確かめる
2	ipVersion	IPv4 と IPv6 を区別する
3	handle	登録オブジェクトを識別する
4	name	ネットワーク名を確認する
5	type	提供元の分類を読む
6	status	登録状態を理解する
7	entities	組織や連絡先を確認する
8	roles	各主体とリソースの関係を読む
9	events	登録・変更日時を確認する
10	remarks / notices	解釈に必要な補足を読む
11	parentHandle / links	親や関連レコードを追跡する

RDAP だけでは判断できない六つのこと

現在のルーティング：登録があっても BGP に見えない範囲はあります。広告の有無、Origin ASN、安定性、プレフィックス長を経路データで確認します。

広告の認可：登録組織名から、どの ASN が広告してよいかは決まりません。ROA と RPKI 検証、IRR、適用される LOA、実際の BGP を、それぞれの証拠能力の違いを踏まえて照合します。

法的・契約上の権利：登録は証拠の一つです。契約、移転書類、会社記録、ポリシー、履歴、適用法、関連する判断なども関わります。

物理的な場所：country は GeoIP やネットワーク調査の代わりになりません。アドレスの評判：スパム、ブロックリスト、マルウェア、過去の不正利用、商業上の評判は専用の情報源で調べます。

逆引き DNS：正しく設定されているかは独立して確認します。メール、ホスティング、企業サービス、セキュリティ運用では特に重要です。

一つのデータベースではなく、複数の層をつなぐ

登録の層では記録の正確性、経路の層では期待どおりの広告、認可の層では起源と許可の関係、DNS の層では名前と逆引き委派を確認します。

さらに RPKI オブジェクトとアカウントの安全性、アドレスの評判、取得・管理を説明する書類、担当者や事業者、設備、組織が変わっても管理を続けられるかを見ます。

社内の基準台帳は、これらの事実、情報源、差異を結び付けるためにあります。単一フィールドに全運用状態を代表させないことが大切です。

七つの手順で、繰り返せる監査にする

1. 台帳を作る。重要な IPv4、IPv6 プレフィックスと ASN を列挙し、予約、未使用、委派済み、旧設備用、継続運用用のリソースも含めます。稼働中の設定だけでは不十分です。

2. RDAP を取得する。範囲、レジストリ、handle、名称、分類、状態、組織、管理・技術・不正利用の連絡先、登録日と更新日を、取得元と時刻とともに保存します。

3. 社内記録と照合する。組織の関係、担当者の在籍と権限、範囲、履歴、レジストリアカウントへのアクセスを確認します。差異は片方を正解と決め付けずに説明します。

4. BGP を独立して確認する。Origin ASN、広告範囲、可視性、想定上流、予期しない広告を調べます。RDAP の取得成功は運用健全性の証明ではありません。

5. 認可を確認する。ROA、ASN、プレフィックス、最大長、RPKI 検証状態、IRR を照合します。経路移行や ASN 変更の後には再確認します。

6. 依存を洗い出す。逆引き DNS、API、顧客の許可リスト、VPN、ファイアウォール、SaaS、決済、メール、コンプライアンス書類を確認します。

7. 例外を記録する。差異、理由、責任者、修正の必要性、継続運用上のリスクを残し、別の担当者が引き継げるようにします。

IPv4 移転の調査では、登録の外側も見る

取引前には管理 RIR、実際の登録範囲、エンティティ、親との関係、変更日時、注記・通知を確認し、取引書類と照合します。

適用される手続き、移転・会社書類、BGP 履歴、RPKI、IRR、逆引き DNS、評判、導入計画も調査範囲です。古い WHOIS/RDAP 情報の影響について原文が挙げた参考記事は、関連資料として残しています。

登録の不備が事業継続に影響する場面

技術担当は三年前に退職し、社名も変わり、アカウント管理者が分からない。そのブロックは何百もの顧客の許可リストに入り、大規模移行が迫っている。この状況では登録の正確性は単なる書類整理ではありません。

重要なリソースには最新の登録、管理されたアクセス、明確な社内責任、履歴、BGP・RPKI の可視性、復旧手順が必要です。登録の層を、運用全体を支える信頼できる一部にします。

登録情報と実際のネットワークを結び付ける

RDAP は登録内容、BGP は観測した経路、RPKI は公開された認可と起源の整合性、DNS は名前と逆引き委派を示します。会社・取引書類はリソースの経緯を補います。合わせて読むことで判断の根拠が増えます。

登録と経路、国コードと所在地、エンティティと法的権利、active と実利用を混同しないこと。IPv4、IPv6、ASN に依存する組織は、記録全体が正確で、説明でき、現在の事業と一致しているかを定期的に点検する必要があります。

よくある六つの質問

RDAP レコードとは何ですか？

リソースについて RDAP で返される構造化された登録情報です。IP ネットワークでは範囲、識別子、状態、エンティティ、連絡先、イベントなどを含みます。

RDAP は何の略ですか？

Registration Data Access Protocol です。登録データにアクセスするためのプロトコルを指します。

IPv4 アドレスも検索できますか？

はい。IPv6、CIDR 範囲にも対応し、ASN 用のクエリもあります。単一アドレスより広い範囲の登録が返る場合があります。

WHOIS より何が便利ですか？

標準クエリ、JSON、HTTPS、権威あるサービスへのリダイレクトが自動処理や連携に向いています。WHOIS も広く使われていますが、いずれも文脈に沿った解釈が必要です。

handle は何を表しますか？

レジストリ内のオブジェクト識別子で、関連情報の参照に使います。所有権を証明するものではありません。

active なら通信できるという意味ですか？

いいえ。登録上の状態であり、現在の経路、到達性、RPKI 起源検証の成功をそれだけで示すものではありません。

原文と今回の編注

Ann Yong が 2026 年 8 月 26 日に公開し、同日に更新した記事に基づきます。全論点、16 の JSON 例、二つの表、六つの FAQ を保持し、旧アコーディオンに重複していた五問は対応する回答にまとめました。active の定義と links 例の value 省略については今回の編注です。原文の公開日は維持しています。

標準と関連資料

確認した事実から、次の行動を選ぶ

調査でリスクが見つかった場合、NRS Shield の会員支援につなげられます。POA は別途行う明示的な代理権の付与です。範囲、期間、判断権限、撤回方法を理解して決めてください。記事を読んだり相談したりするだけで、委任が成立することはありません。

NRS Shield を知る · POA と代理権を理解する · 現在の取り組みを見る