要約

  • AFRINICの公式AfPIF 2026ページは、MyAFRINIC v2を会員向けセルフサービスポータルの全面的な再構築と説明している。
  • 同ページは、ユーザー受入テストとベータプログラムへの参加者に加え、会員の業務フローや改善要望を聞く短時間のインタビュー協力者を募っている。
  • ページには8月19日のプレゼンテーション予定もあるが、発表、聞き取り、テスト、ベータが実際に行われたことまでは立証していない。
  • 参加人数、テスト範囲、受入基準、不具合、移行結果、本番公開日は、現在の情報源には示されていない。

1. 確認できるのは参加募集であり、製品の状態ではない

会員を公開前のテストに招くことは、妥当な出発点になり得る。レジストリのポータルは、見た目が整った画面を提示すれば検証できるものではない。資源申請、権限を伴う連絡先変更、請求の確認、日々の照会は、認証、データ検証、内部判断、複数システムの連携にまたがる。こうした作業を担う利用者は、準備されたデモでは見えない前提のずれを見つけられる。

公式ページが裏付けるのは、その参加募集の存在である。AFRINICはMyAFRINIC v2を会員向けセルフサービスポータルの全面的な再構築と位置付け、ユーザー受入テストと「live beta」に先立ってコミュニティの意見を集めていると記した。テストとベータへの参加を希望する会員の連絡先、さらに日常業務と改善要望を話す短時間のインタビュー協力者を求めている。

日程について確認できる事実は、さらに限られる。ページはAfPIFを2026年8月17日から20日までキガリで開催する予定とし、21日に会員会合を置いている。19日11時には、AFRINICのサービス、MyAFRINIC v2、ポリシーパイプラインを扱うAFRINICの発表が予定されていた。発表時刻のタイムゾーンと、ページの初回公開日時は記載されていない。

証拠の締切日である8月28日時点では、予定日は既に過ぎていた。しかし、予定日が過ぎたことは実施記録の代わりにはならない。現在の情報源からは、発表が行われたか、何人が応募したか、聞き取りが実施されたか、テスト環境が開いたかを判断できない。参加者がどのビルドを見たのか、どの業務フローが使えたのか、何を合格としたのかも不明である。

したがって、明確な境界が必要だ。参加募集は、公開前に意見を得ようとする組織的な意図を示す。MyAFRINIC v2が完全、安全、アクセシブル、受入れ済み、本番運用可能であることは示さない。会員の本人性、資源申請の完了、請求残高の正しさ、組織データの移行結果についても証明しない。

2. テストの単位は画面ではなく業務上の結果である

単独の不具合一覧だけでは、会員ポータルの公開判断を支えられない。「連絡先更新に失敗した」という記録があっても、誰がどの権限で変更し、どの検証が必要で、最終状態がどこに記録され、会員がどの通知を受け取るべきだったのかが分からなければ、制度上の仕事が完了したか判断できない。

各テストには、業務フローの識別子と期待される成果を結び付けるべきだ。連絡先変更なら、許可された役割、変更の種類、必要な承認、レジストリ側の期待状態、通知と監査記録を区別する。資源申請なら、自動処理、必要資料、人の判断が入る箇所、会員に見える状態遷移を記録する。目的はクリックをすべて記録することではなく、行為、権限、結果の関係を残すことにある。

参加者のカバレッジも、個人名を出さずに記録できる。プライバシーに配慮した概要で、規模や種類の異なる会員、複数の運用上の役割、関連するアクセシビリティ上のニーズが含まれたかを示せる。参加者を完全な統計標本と見せる必要はない。どの仕事が代表され、どれが未検証かを明らかにする方が重要だ。

実行結果には、ビルド、環境、時刻、データ境界を付けなければならない。同じ画面上の症状でも、アプリケーションコード、権限、参照データ、外部連携、移行規則のいずれかが原因になり得る。接続先が実サービスか模擬系か、データが合成、匿名化、あるいは管理された実データかも区別する必要がある。

これは、本人確認、請求、資源情報に触れるフローで特に重要だ。画面が「成功」を示しても、背後の制度的な状態が一貫して更新されたとは限らない。反対に、単純に見える失敗が、複数システムをまたぐ権限や同期の問題を示すこともある。業務結果と技術証拠を同じ鎖に置くことで、受入判断を画面表示だけに依存させずに済む。

3. 台帳は不具合からベータ判断までを追う

必要なのはチケット保管庫ではなく、会員の実行から機関の判断までをたどれる台帳である。最小構成は次のように整理できる。

判断段階 管理対象の証拠 安全に公開できる記録
参加受付 資格、同意、役割 参加者群のカバレッジと募集状況
業務フロー 前提、手順、データ境界、期待結果 フロー識別子とカバレッジ状態
実行 ビルド、環境、時刻 バージョンとテスト期間
指摘 再現資料と影響を受けた記録 不具合ID、分類、重大度、関連フロー
処置 責任者、理由、例外を認める権限 修正、延期、却下、既知の制限として受容
再テスト 修正版、結果、回帰範囲 検証状態と確認済みバージョン
ベータ判断 承認、制限、ロールバック経路 採用または除外と機関としての理由

処置の段階で、技術的な指摘は統治された判断に変わる。不具合は、修正、延期、再現不能、対象外、既知の制限としての一時受容などに分類される。どの結論にも責任者と理由が必要だ。制限を残したままベータに進む場合は、誰がリスク受容の権限を持ち、誰に影響し、どの補完策があり、何をもって例外を解消するかを記録すべきである。

修正だけで証拠の鎖を閉じるべきでもない。再テストは、元の不具合と修正を含むビルドの双方を参照し、回帰テストの範囲を示す必要がある。認証の変更は連絡先の権限に影響し、移行規則の修正は隣接データを変え、請求処理の修正は外部連携に作用するかもしれない。一つのケースが通っても、関連フロー全体が健全とは限らない。

ベータを開く判断も、後から再構成できる状態にすべきだ。どのフローを含め、どの制限を残し、誰が残存リスクを受け入れ、障害時にどの支援・退避経路を使うのか。台帳はAFRINICの裁量を奪わない。判断時に利用した事実と理由が、会議の終了とともに消えることを防ぐ。