要約

  • APNICの公開NIR APIには POST /nir-delegations/asn があり、非同期タスクは SUCCESSFUL になり得る。ただし手順書はNIRのプール委任からの操作と説明し、ロードマップはMyAPNICとNIR APIによるNIRアカウント保有者への直接ASN委任を記す。版と日付がなければ両者を同一視できない。
  • 2024年9月のEC資料は中核レジストリとNIR APIの更新を進行中とし、12月資料は「NIR ASN direct assignments」を最終QAとした。現在の2025年ロードマップ項目は目的を残す一方、target と changelog が空である。これは失敗や未配備の証拠ではなく、公開された結合証跡がないという限定的な事実だ。
  • APNICは、ロードマップID、API・スキーマ版、本番切替、参加NIR、移行範囲、委任の意味、Whois/RDAPとの集計照合を結んだ、小さな署名付きまたはハッシュ参照可能なリリース・保証票を公開できる。

「プールから」と「直接」は、運用現場では一語の差で済まない。どの資源集合から番号が出たか、誰が適格性を判断したか、どのシステムが正本を書き換えたか、既存レコードが移行されたかという、異なる制御面を指し得るからだ。名称が短くなるほど、その境界はむしろ明記されなければならない。

APNICが公開している断片は、それぞれ単独では役に立つ。製品ロードマップは問題と予定する解決策を示す。Executive Councilの資料はプロジェクトの進行段階を残す。NIR APIの文書は呼出しの形、連絡先データ、非同期処理、再送制御を示す。しかし、三つを同じ本番変更として引用できる鍵がない。

時系列が近いことは、技術的同一性を保証しない。URLはバックエンドの意味が変わっても維持できる。最終QAは出荷直前の品質段階だが、出荷そのものではない。年次ロードマップに載ることは、全NIRが同じ日に新経路へ移ったという意味でもない。

これはAPNICが機能を配備しなかったという主張ではない。公開された資料だけでは、失敗、取消し、未配備のいずれも導けない。観察できる欠落はもっと狭い。計画、コード経路、本番切替、採用範囲、公開レジストリ上の結果を、一つの不変なリリース識別子で追えないのである。

最終QAの先で公開記録が途切れる

APNICの2019年のNIRデータ照合記事には、この問題を理解するための歴史的な手掛かりがある。記事はIPv4について、古い連合型の仕組みから、2004年以降は地域共通プールからの割当・割当てをAPNICレジストリへ直接反映する形へ移ったと説明する。それでも過去のブロックは残り、日付、保有者、欠落した移転の照合が後から必要だった。

このIPv4の経緯をASNの実装説明として流用してはならない。示しているのは、プールの出所、会員へのサービス責任、記録を書き込む場所、過去データの移行が別々に変化するという一般的な性質だ。「直接」という語だけでは、どの部分が直接になったか決まらない。

2024年9月のEC資料は、NIR向けASN直接割当てのための中核レジストリとNIR APIの更新が進行中だと記した。ウェブ上の説明文だけでなく、レジストリの実行面とAPIの双方にまたがる作業だったことを示す。ただし、本番日や対象NIRまでは示さない。

12月の資料では、目的がより明確になった。NIRアカウント保有者にASNを直接委任し、データの一貫性と妥当性を高めることが掲げられ、状態は最終QAテストとされた。構想から実装に進んだ強い兆候だが、最終QAはリリース証明ではない。切替の瞬間、版、対象、ロールバック状態は別途必要になる。

2025年2月のEC・年次報告資料でも、この項目は進行中のロードマップ作業として扱われた。現在公開されているロードマップJSONは項目を2025年に置き、Registryチーム、ARMS、MyAPNICを関連付ける。提案する解決策は、MyAPNICとNIR APIを介したNIRアカウント保有者への直接委任である。

ところが、同じレコードの target は空で、changelog も空だ。空欄は中止を意味しない。内部の展開記録が存在しないことも意味しない。公開面で言えるのは、予定日または実施日と、版・移行説明・検証結果へ進む変更履歴が、そのカードから取得できないということだけだ。

APNICの2025年年次報告は、四半期ごとの製品ロードマップ目標を達成したと述べる。具体例にはWhoisの認可更新、RPKI Signed Checklistオブジェクト、RDAP再設計の概念実証がある。取得した全文ではNIR ASN直接割当ての名称は見当たらない。

この沈黙も否定証拠ではない。年次報告は選択的な総括であり、全リリースの台帳ではないからだ。逆に言えば、総括の「達成」と特定機能の本番意味を結びつけるには、個別のリリース票が必要になる。

公開記録には、開始、最終QA、年次目標達成という三つの明るい点がある。欠けているのは、その間をつなぐ一本の線だ。説明を増やすより、各資料が共有できる不変IDを置く方が、監査上ははるかに強い。

APIは操作面を示すが、リリースの意味までは示さない

現在の公開NIR API文書は、NIRがサブアカウントの登録情報を管理する仕組みを説明する。ASNの手順では、WhoisとRDAPに使われる連絡先を伴って POST /nir-delegations/asn を送り、非同期タスクのURLを受け取る。共通の説明にはタスク状態の確認と Idempotency-Key の使用がある。

ここから確実に分かることは多い。ASNを扱う呼出し面が文書化されている。処理は即時完了とは限らない。クライアントはタスクを追跡できる。偶発的な重複送信に対する仕組みもある。登録に必要な連絡先がWhoisとRDAPへつながることも明記される。

しかし、手順の題材は「NIRのプール委任から」のASN委任である。ロードマップの文言は、NIRアカウント保有者への直接ASN委任だ。APIの経路名が同じでも、資源取得、アカウント結合、検証、記帳の内部手順が後から変わった可能性はある。公開資料はその可能性を肯定も否定もしない。

テストベッドのドメインにある文書も、本番操作の証拠として扱えない。テスト面で公開される仕様が本番と同じ版か、先行版か、互換版かは、版表示がなければ判断できない。文書が存在することは仕様形状の証拠であり、特定日の本番変更の証拠ではない。

Idempotency-Key にも厳密な役割がある。同じ意図を再送したとき、処理が二重化する危険を減らす。しかし、その意図が正しい政策版に沿うこと、正しいプールを選ぶこと、正しいNIRの移行段階を使うことまでは保証しない。古い意味の操作も一度だけ正確に実行できる。

非同期タスクの SUCCESSFUL はトランザクションの終端を表す。だが、何をもって成功とするかはタスク定義に依存する。中核レジストリの更新だけか、WhoisとRDAPへの投影までか、後続の照合までかを、状態語そのものからは読めない。

だからこそ、成功状態を弱める必要はない。機械には短い状態が適している。必要なのはその上位に、どの版の意味で何が完了したかを示すリリース来歴を置くことだ。トランザクションIDとリリースIDが関連付けば、短い状態を保ったまま監査可能性を得られる。

中核へ直接書くことと、NIRの判断を外すことは別だ

APNICのNIR運用方針は、NIRが地域の言語と制度環境に即したサービスを提供することを説明する。NIRは地域・世界の資源管理方針に従い、その範囲で地域要件を持ち得る。APNICには直接会員の選択肢を維持する役割もある。

一つの組織がNIRとAPNICの双方に所属する場合でも、同時点の資源サービスは一つの供給元から受ける。したがって、承認結果をAPNICの中核レジストリへ直接記録する設計は、NIRが申請者への窓口や適格性判断者でなくなることを必ずしも意味しない。

考えられる合理的な構造は、NIRが地域サービスと審査を担い、承認した結果が二重入力なしでAPNICの正本へ届くものだ。これなら連絡先、日付、アカウント所属、番号の転記差異を減らせる。ロードマップがデータの一貫性と妥当性を目的に置く理由も理解できる。

同時に、責任の出所が見えにくくなる可能性がある。公共のWhoisやRDAPを読む人は最終状態を見られても、NIRがいつ承認したか、どのAPI・スキーマ版が受理したか、どの移行群に属したか、例外処理を経たかまでは見えない。

APNICの現行資源方針によれば、申請者はAPNICまたは該当NIRにASNを申請でき、割り当てられたASNはAPNICまたはNIRのWhoisに公開登録されなければならない。これは制度上必要な最終状態を定めるが、その状態を作った実装の来歴までは定めない。

同じ公開レコードは複数の経路から生まれ得る。旧NIRプール、地域共通プール、新しいサブアカウント構造、段階移行中の互換経路である。結果が正しいことと、生成経路を説明できることは両立させるべきで、どちらかを選ぶ必要はない。

既存ASNの扱いは特に重要だ。新規だけが新モデルに入り、過去レコードは旧構造に残るのか。過去分を回収して移すなら、どの期間・NIR・例外が対象か。移行しないなら、二つの意味がどのように共存するか。これらは個人情報を出さずに版と集計で説明できる。

公開レビューは別の母集団を見ている

APNICには資源委任レビュー・プログラムがある。公開説明はデータ分析、方針遵守の標本確認、手続評価、アカウント記録の正確性、NIRへの支援、将来の協定見直しを含む。2026年第2四半期の更新ではJPNIC、TWNIC、KRNICでの作業完了と、他NIRの分析継続が報告された。

ただし、公開された主要対象は10年間のIPv4委任と移転である。この結果を、新しいASN経路を独立に測定したものとして扱うことはできない。直接ASN委任の件数、参加NIR、拒否率、公開投影との差異率は、このレビューの公表分母に含まれていない。

ここからAPNICにASN監査がないと結論するのも誤りだ。内部統制が存在するかどうかは、引用資料では判断できない。限定して言えるのは、公表されたレビュー範囲がIPv4であり、ASNプロジェクトの結果証明として代用できないという点である。

監査では分母が意味を決める。10年分のIPv4を調べる指標は歴史的な住所資源の品質を語る。APIタスク数は処理量を語る。ロードマップ状態は管理上の進捗を語る。それぞれが正確でも、別の問いへの答えである。

必要なのは三者を無理に一つの数字へ潰すことではない。リリース版と対象範囲を先に固定し、その版に属するトランザクションを集計し、最後にWhoisとRDAPの状態を照合する。この順序なら、別々の証拠が役割を保ったまま接続される。

最小限のリリース・保証票

公開に申請書、本人確認資料、内部審査メモ、NIRの商業条件は要らない。実装変更の境界を示す小さな文書で十分だ。署名するか、内容ハッシュで参照可能にすれば、後日の訂正も履歴を壊さず追加できる。

最初の欄には、ロードマップ項目ID、不変なリリースID、本番切替時刻、展開範囲、ロールバック状態、API版、スキーマ版を置く。旧・新の委任意味も明記し、NIRプールからか、APNIC管理の地域プールから直接かを曖昧にしない。

次に採用と移行を記す。どのNIRが参加し、同時か段階的か、旧経路が残るか、既存ASNのどの群を新しいサブアカウントへ移したか。名称を公表できない事情があれば、少なくとも採用段階と件数の分母を示せる。

結果欄には限定期間の試行、成功、拒否、取消し、訂正、照合の件数を置く。中核レジストリ、Whois、RDAPが一致した割合、幂等処理が吸収した重複、未解決例外も、定義と時間窓を付けて示す。

最後にロードマップ、変更履歴、該当版のAPI文書、後続の保証結果へのリンクを置く。これで計画の真実、リリースの真実、トランザクションの真実、現在状態の真実が、相互に代替されず結びつく。

この票はAPNICの運用自由度を狭めない。むしろ、段階展開、停止、ロールバック、修正版の投入を明確に記録できる。変更履歴が空のまま意味だけが動く場合より、障害と修正を説明しやすくなる。

NIRの技術者にとっては、サポート回答と実際の版を照合する基準になる。APNIC会員には責任の分担が見える。研究者には、テスト文書を本番証拠と誤認せずに済む境界ができる。将来のレビューは、どの母集団を調べるかを正確に選べる。

端点は確かに存在する。プロジェクトが最終QAまで進んだ記録もある。ロードマップには直接委任の目的が残る。問題は、三つの事実が一つのリリースであると証明されていないことだ。

APNICが追加すべきものは、大規模な透明性ポータルではない。実装が変わる瞬間に、識別子、意味、範囲、結果を一枚へ固定することだ。そうすれば「プールから」と「直接」の差は、推測ではなく参照できる運用史になる。

出典