要約

  • 9月8日14:00〜15:00 UTCの保存済みスナップショットでは、WHOISのtotal_queriesは3,192,583だが、表示された七種別の合計は3,183,463で、差は9,120だった。同じファイルのRDAPは正確に一致する。
  • 6月30日から証拠基準時までの1,691ファイルを全件検査すると、WHOIS通信のある1,690時間はすべて不一致だった。総数が大きい時間は1,011、種別合計が大きい時間は679あり、単一の「その他」区分では両方向を説明できない。
  • APNIC 62向けに公開された実施状況資料は、prop-167を「実施中」とし、データ精度の問題を解決中だと記す。ただし、この算術差を指すとは書いていない。必要なのは、生の照会を公開せずに計数段階、除外、検証、訂正履歴を示す照合票である。

統計の透明性は、数字を見せることだけでは完成しない。読み手がその数字を組み立て直せることまで含む。APNICがprop-167を受けて公開した時間別ファイルは、WHOISとRDAPの利用量を、サービス、照会種別、送信元ASN、異なる送信元IP数という集計値で示す。個別のIPアドレスや照会対象を明かさず、利用の輪郭を保存する仕組みだ。

その仕組みを最新の保存資料で試す。2026年9月8日14:00から15:00 UTCまでのWHOIS欄では、total_queriesが3,192,583とされる。種別は、inetnumが1,670,618、routeが1,284,709、aut-numが93,537、domainが88,530、organisationが31,500、as-setが13,888、inet6numが721である。合計は3,183,463になる。

差は9,120、表示総数の0.2857%だ。併記されたMD5は取得したJSONと一致するため、転送中の破損ではない。同じ文書のRDAP欄では五種別の合計が588,346となり、総数と完全に一致する。ファイル形式そのものが照合不能なのではない。

一時間だけなら、小さな締め時間のずれとも読める。アーカイブ全体では、その読み方では足りない。

ゼロでないWHOIS時間は一つも一致しない

月別ディレクトリにある最初のファイルは6月30日03:00 UTC、今回の最後は9月8日13:00 UTC開始である。間には1,691時間があり、ファイルも1,691個あった。時刻名に欠落はない。すべてのgzipを展開でき、JSONとして解析でき、内部の半開区間はファイル名と一致した。展開後の内容が同一のファイルもなかった。

検査式は単純である。各サービスについてquery_type_distributionの値をすべて足し、その値をtotal_queriesと比較する。表示された各ASN行についても、query_count_by_typeの合計とquery_countを比較する。

RDAPは1,691時間すべてで一致した。サービス全体の差は常にゼロで、表示されたASN行にも不一致はない。同じ公開処理の中に、明確な対照が存在する。

WHOISが一致したのは1ファイルだけだった。8月27日09:00〜10:00 UTCで、総照会数がゼロ、ASN数もゼロ、種別は空、行もゼロである。つまり、WHOIS通信を記録した1,690ファイルはすべて、サービス総数と種別合計が異なる。同じ1,690時間のすべてに行レベルの差もあり、期間全体では347,490行に及んだ。

公開初時間から差はある。6月30日03:00〜04:00 UTCでは総数4,774,145に対し、種別合計は4,801,599で、種別側が27,454多い。最後の保存時間では総数2,989,539、種別合計2,987,334となり、今度は総数側が2,205多い。

向きが変わる点が重要だ。1,011ファイルでは総数が種別合計を上回る。入口で受け付けたものの、公開された型に分類できなかった照会があるなら、「不明」区分を足すことで閉じられるかもしれない。

残る679ファイルでは種別合計が総数を上回る。7月14日05:00〜06:00 UTCには、総数3,288,941に対して種別合計3,652,538となり、363,597、率にして11.0551%多い。非負の残余区分では引き算できない。反対方向で最大の差は8月20日03:00〜04:00 UTCの80,961、2.3823%だった。

正負を通算し「誤った照会数」と呼ぶのも正しくない。相殺された値には定義された単位がない。証明できるのは、二つの欄を結ぶ公表済みの恒等式がないことだけである。

二つの計数段階がそれぞれ正しい可能性

最も強い反論は、WHOISの運用構造を考えれば二つの数が違って当然かもしれない、というものだ。外縁の計数器は受信したコマンドを数え、後段の解析器は認識したオブジェクト種別を数えることがある。一つのコマンドが複数種別を増やす設計もあり得る。構文不正、内部再試行、遅着イベント、異なる締め時刻、送信元ASN付与の失敗も母集団を分けうる。

それ自体は欠陥とは限らない。公開上の問題は、その橋渡しがREADMEにないことだ。READMEは各サービスに時間範囲、総照会数、ASN総数、種別分布、ASN別統計があると説明する。ところが、どの地点で数えるか、複数分類を許すか、何を除外するか、再試行や遅着をどう扱うかを定義しない。不明区分、検証状態、訂正先への参照もない。

したがって、3,192,583と3,183,463のどちらが正しいかは判定できない。二つとも別々の質問には正しいかもしれない。前者が「外縁で受け付けたコマンド」、後者が「分類器が出した型の増分」なら、名称を分けるべきだ。片方を総数、片方をその内訳に見せたまま段階を隠すと、読み手は約束されていない足し算をする。

チェックサムも別の責任を果たすだけだ。APNICが出したバイト列と読者が得たバイト列が同じだと証明するが、フィールド同士の単位や母集団は証明しない。ファイル完全性と指標整合性は同じ品質管理ではない。

ASN配列にも説明のない上限が見える。多くの時間でtotal_asnsは数千なのに、asns配列は最大1,000行である。上位リストとしては合理的だが、READMEにはランキングとも選択基準とも書かれていない。行内を照合できても、表示行の合計をサービス全体とみなすことはできない。

完了した公開と、終わっていない保証

prop-167の公式ページは現在もImplementedと表示し、2026年6月30日の履歴に「Implementation Complete」と記す。一方、APNICは9月10日に予定されたAPNIC 62 Policy SIGセッション用の資料を公開している。prop-167のスライドは「Status: In Implementation」とし、6月30日に初回公開した後、データ精度の問題を現在解決中で、第三四半期末までの完了を見込むと述べる。

時間の扱いには注意が要る。資料は予定セッション前に取得したため、「会議で発言した」とは書けない。公開済みの準備資料である。また「精度の問題」が本稿の算術差を意味するとも書かれていない。APNIC自身が原因を特定したかのように結び付けてはならない。

それでも、資料は二つの完了層を示す。6月の状態は公開サービスの存在を、9月の状態は品質保証が継続中であることを表せる。利用可能性、範囲、整合性、訂正能力は別々の節目である。一語の状態に押し込むより、層ごとに記録する方が正確だ。

分母の選択は分析結果の選択になる

この公開データには明確な公益がある。利用規模、型の構成、ASN集中度、送信元の多様性を、個別IPや照会対象なしで観察できる。時間別保存により追試も可能だ。本稿が存在できるのも、APNICが検査可能な形で開いたからである。

ただし再利用者は必ず分母を選ぶ。ASN行をtotal_queriesで割る集中率と、種別合計で割る集中率は異なる。総数から作る時系列と種別から再構成する時系列も異なる。分類器の版が変わっただけで、利用者行動が変わったように見える危険がある。

ここから、照会の紛失、重複、不正利用、誤答、個人情報漏えい、ネットワーク障害は証明できない。不一致行がASNの責任を意味することもない。ゼロ時間も独立した障害告知なしには停止と呼べない。対象はサービス全体ではなく、公開証拠の自己説明力である。

個別照会を出さずに照合する

各時間に小さな照合票を付ければよい。外部境界で受け付けた数、正常に解析した数、種別に割り当てた増分を並べ、構文不正、未対応、時間切れなどの除外を大分類で示す。一照会が複数型を増やすなら規則を書く。段階ごとに締め時刻が違うなら両方を示す。

次に変換の身元を残す。収集器と分類器の版、実行識別子、完了時刻、全等式を再計算した検証結果である。ASN付与失敗は集計数で十分で、IPを出す必要はない。1,000行はランキングと明記し、抽出規則を示す。

最後に訂正を出来事として保存する。各ファイルを暫定、検証済み、訂正済み、撤回のいずれかにし、指紋を持たせる。代替版は旧指紋、訂正時刻、理由区分、影響フィールドを参照し、旧版も発見可能にする。

これは誰が何を照会したかを求める仕組みではない。同じ時間に二つの総数を出すなら、その間の変換を説明してほしいという要求だ。定期公開、開放、保存、チェックサムという難しい部分はすでにある。照合票が、その出力を長期に再利用できる証拠へ変える。

情報源