要約

  • AFRINIC Statusの概要APIは全体をoperationalとし、「All systems are go!」と表示している。
  • 2026年7月3日に始まった通知502905はpresentかつrecoveringで、ended_atはnullのままである。
  • 通知に結び付く「AFRINIC Web Sites」とwww.afrinic.netは正常だが、公開更新は最初の調査報告一件しかない。
  • 現在も停止中だとは証明できない。証明できるのは、全体、部品、通知、履歴が同じ出来事を一緒に閉じていないことだ。必要なのは復旧観測と終了判断を結ぶ機械可読な受領記録である。

7月3日から時計が止まっている。ウェブサイトではなく、インシデントの時計である。

AFRINICのステータス概要は、現在のページ状態をoperationalと返す。人向けの文言は「All systems are go!」だ。部品一覧でも、ウェブサイト群と主サイトはいずれも正常とされている。ところが通知502905を開くと、出来事はまだ現在に属し、復旧中で、終了時刻がない。

最初の更新でAFRINICは、技術的な問題のためウェブサイトを予防的に停止し、調査と通常運用への復帰を進めていると説明した。今後も更新すると記したが、固定した公開応答にはその一件しかない。復旧観測も解決通知も追加されていない。

ここから現在の停止を推論してはならない。部品の正常表示は正しいかもしれず、サイトは長く問題なく応答している可能性が高い。狭く確実な問題は、同じ公式システムが「現在使えるか」と「出来事が終わったか」を別々に答え、その関係を示していないことだ。

色ではなく遷移を管理する

ステータスページは色付き掲示板に見えるが、実際には状態遷移を管理する台帳である。インシデントにはID、開始、影響範囲、観測、段階、終了がある。その台帳から全体表示、部品状態、通知ページ、購読者向け更新、履歴が作られる。

各表示が短時間ずれること自体は異常ではない。部品が応答し始めても、運用チームが安定を確認する間は復旧中にできる。利用者には先に再試行を勧め、最終報告は後で出してもよい。問題は、ずれに期限と説明がなく、最終的に同じ状態へ収束しないことである。

7月の記録は四方向に分かれている。全体は正常、関連する二部品も正常、通知は復旧中、履歴は6月20日のAIS 2026ウェブサイト問題を直近のインシデントとして示す。6月の記録には調査開始だけでなく、解決したとの更新と終了時刻がある。

6月と7月の原因や影響を同一視する根拠はない。比較できるのは記録構造だけだ。6月の例は、使用中のプラットフォームが明示的な解決状態を表現できることを示す。7月の通知に終端がないのは、公開媒体に終端能力がないからではない。

観測と判断は別の証拠である

あるURLが一度成功したという観測は、到達可能性の証拠になる。代表的な確認を一定時間続ければ、サービス復旧の判断材料になる。しかしインシデントを閉じるには、観測を受け入れ、残存条件を記し、監視段階を終える決定が要る。

この二つを一つにすると、早すぎる終了か、終わらない復旧になる。前者では一回の成功が不安定な状態を隠す。後者ではサービスが健全でも、通知だけが永遠に現役として残る。記録は「実際に復旧を観測した時刻」と「終了を決定した時刻」の両方を持つべきだ。

通知502905では、その二つを公開情報から復元できない。上位の状態は調査から復旧中へ移ったように見えるが、更新欄に遷移理由がない。部品は正常へ戻っているが、その根拠となった確認が関連付けられていない。ended_atが空なので、公開データだけでは期間を計算できない。

詳細なログや構成、委託先、セキュリティ情報の公開は不要だ。サービス区分、確認時刻、合格条件、終了を承認した職務、残存リスクの有無があれば、外部は判断の輪郭を検証できる。生の証拠は保護された内部参照に置ける。

簡単なAPIほど計算規則が要る

AFRINICのAPI説明は、概要を部品や通知の複雑さを扱わずに全体状態を得る方法として紹介する。自動処理には有用だ。ただし、簡略化は根拠の省略ではない。何を圧縮したかが分からなければ、緑色は再現できない結論になる。

一つの設計では、全体状態を現在の部品観測だけから計算できる。その場合は、未終了通知の件数と段階を別軸で返すべきだ。「部品は正常、一件は復旧観察中」と表現できる。別の設計では、presentの非計画通知が一件でもあれば完全なall-clearを禁止できる。どちらも明示されれば合理的である。

現状では利用者が優先順位を決めるしかない。概要を読む監視は解除へ進み、通知一覧を追う運用は7月からずっとインシデントを保持する。両者とも公式APIを正しく使っている。矛盾は利用者側ではなく、公開契約の継ぎ目にある。

概要を複雑な画面に変える必要はない。open_incident_count、最も重い未終了段階、page_state_ruleのような数項目で十分だ。人向けにも「現在のサービスは正常、インシデントは観察または管理上の終了待ち」と書ける。単純さを保ちながら、異なる時間軸を隠さずに済む。

終了受領記録の設計

小さな終了受領記録は、既存の通知IDから始まる。開始時刻、影響部品、最後に確認した影響を保持する。次に復旧観測を追加する。何を、いつ、どの基準で確認し、監視を継続したかを記す。最後に終了判断、実際の終了時刻、責任を負う職務、残る条件、最終公開文を追加する。

記録は単調に増える必要がある。正常へ戻した際に調査履歴を上書きしない。再開した場合は新しい遷移と理由を足す。もし今日になって7月の出来事を補正するなら、証拠が示す復旧時刻と、管理上の終了を入力した今日の日付を分ければよい。遅い訂正を長期障害にも即時記録にも見せない。

いくつかの検証規則で抜けを防げる。終端状態には必ず終了時刻を要求する。非計画通知がpresentのまま全体を緑にする場合は、例外または計算規則を返す。インシデント中に部品が正常へ移るなら、復旧観測を関連付ける。閉じたイベントは同じIDで履歴に現れるようにする。

これは現場を罰する仕組みではない。圧力下の更新では操作漏れが起きる。訂正履歴を認めれば、古い日付へ黙って書き換える誘惑を減らせる。公開記録は完璧な即時性より、遅れを含めて検証できる方が信頼される。

開いたままのコスト

最初のコストは指標だ。終了時刻がなければ、回復時間を正しく求められない。7月から継続する巨大な値として扱うか、統計から除外するしかなくなる。影響終了、観察終了、公開閉鎖を分ければ、三つの遅延を比較できる。

次は自動化である。緑だけを見る仕組みは停止し、現行通知を見る仕組みは動き続ける。やがて運用者はノイズを止めるため片方を無視する規則を足す。その例外が将来の重要な通知にも適用されると、保護は静かに失われる。

第三は説明責任だ。正常という現在値だけでは、誰がどの観測を採用し、なぜ監視を終了したかが残らない。ログが循環し担当者が変われば、後から緑色を見ても判断は再構成できない。

第四は信頼の学習である。一件の不整合で信頼が消えるわけではない。しかし、利用者は「通知欄は閉じなくてもよい」または「全体色は決定的でない」と覚える。次の出来事で、その習慣が重要な信号を弱める。

AFRINICの機関サイトはWHOIS、RPKI、会員ポータルと同じものではない。本稿は7月の問題を他サービスへ拡張しない。むしろ影響が違う部品を一つの状態ページで扱うからこそ、範囲と段階を正確に保つ必要がある。

確実に言える範囲

2026年9月11日に固定した公式応答から、全体が正常であること、通知502905が現在・復旧中であること、終了時刻が空であること、更新が調査一件だけであること、二つの関連部品が正常であること、6月の別件が直近の完了履歴として見えることを確認できる。

現在の停止、性能低下、サービス水準違反、会員被害、意図的な隠蔽は確認できない。全体状態の計算実装、監視間隔、内部記録、公開ページ外の購読者通知も分からない。部品のupdated_atをプローブ時刻として扱う根拠もない。

結論は限定的でよい。公開記録に、四つの表示を同時に閉じる共通取引がない。サービスが7月に戻ったのなら、その証拠を境界付きで記録し、終了を追加すれば現実と表示が一致する。

緑色を変える必要はないかもしれない。変えるべきなのは、緑色へ至った経路を空欄のままにする習慣である。

情報源