要約

  • RIPEstatの2026年第3四半期計画は、利用価値の高いRouting Historyを次の刷新対象に挙げ、長期保守とContent Security Policy（CSP）対応を理由としている。
  • UIのデータ源は公開Data APIだけだが、行数のソフト上限、peer数のしきい値、first hop、可視性の正規化、時間範囲、欠測値の扱いによって、同じ応答から異なる結論が見える余地がある。
  • 固定応答と解決済みの既定値、新旧表示の意図的な差、境界事例、訂正履歴、旧表示の終了条件を結ぶ版管理されたパリティ記録が、最小の対策になる。

一本の線がいつ始まったか

あるプレフィックスが、最初の時間帯には九つのRISフルテーブルpeerから見え、次の時間帯には十一から見えたとする。Routing Historyの既定値である十を下限にすれば、線は後半から始まる。下限を下げれば、前半も履歴に入る。観測そのものに矛盾はなくても、二つの画面は「経路が現れた時刻」を違って見せる。

これは実在する表示不良を指摘する例ではない。RIPE NCCが次の移行で管理すべき判断の種類を示すものだ。2026年第3四半期のRIPEstat計画は、次に更新する可視化をRouting Historyとし、社内外の利用者にとって価値が高いと説明する。さらに、レガシーな可視化を新しい技術と外観で作り直す必要があり、その目的は長期的な保守とRIPEstatにおけるCSPの有効化だとしている。状況は「進行中」である。

この判断を支える事情は強い。古いフロントエンドは、データが正しくても負債になる。スクリプト、style、外部resourceの読み込み方に関する過去の前提が、厳格なブラウザpolicyを阻むことがある。W3CのCSP Level 3は、pageが取得・実行できるresourceなど、security上重要な動作を制御する仕組みを定義する。強制前に違反を観測するreport-onlyも用意されている。これを妨げる依存関係を取り除くのは、侵害の告白ではなく、通常の保守責任だ。

また、意味のパリティはpixelの複製ではない。色覚への配慮、keyboard操作、狭い画面での要約は、見た目を変える正当な理由になる。過去のRIPEstat計画には、旧UIと新UIの機能パリティを2022年に完了したこと、自動UI testを導入したこと、widgetの依存更新を慎重にproductionへ展開したこと、RISのdata processing移行の影響を監視したことが記録されている。公開資料だけから、内部testが存在しないとは言えない。

ただし、実行の安全性と意味の連続性は別の試験である。CSPの試験は、新しいcodeが厳しいbrowser policyの下で動くかを確かめる。意味の試験は、同じ観測を見た利用者が、開始時刻、origin、可視性について同じ重要事実を受け取るかを確かめる。CSP違反がゼロでも、後者が成立したことにはならない。

APIは比較の基準であって、完成した解釈ではない

RIPEstatの説明は役割を明確に分けている。Data APIの概要では、APIが公開data interfaceであり、widgetとUIの唯一のdata sourceだとされる。RIPEstatとは何かでは、APIがdataを供給してqueryに答え、UIがそのdataの可視化方法を示すと説明されている。

したがって、API応答は新旧比較の優れた基準になる。しかし、応答だけでgraphの読み方が決まるわけではない。現行2.3版のRouting History endpointは、RIS route collectorから得たannouncement期間をoriginとprefixごとにまとめる。表示結果を左右する複数のoptionがある。

max_rowsの既定値は3000で、しかもソフト上限だ。上限に達すると、すでに含まれたoriginの記録済みrouteはすべて返る一方、それ以降のoriginは返らない。安定した並べ方とtruncationの通知がなければ、「存在しない」と「表示対象から外れた」を区別できない。include_first_hopはoriginにfirst-hop ASNを組み合わせ、一本の系列を複数に分け得る。normalise_visibilityはそのrouteを見たRIS full-table peerの割合を加える。min_peersは既定値10で、低い可視性や局所的なannouncementを除外する。開始・終了時刻を指定しなければ、期間の意味も既定値に委ねられる。

とりわけ重要なのが、peer情報が欠けるか信頼できない場合に可視性が-1になり得る点だ。これはゼロではない。baselineに置けば「見えないことを測定した」と読める。無言で消せば連続していたように見える。前後を線で結べば、存在しない観測を作ってしまう。表現は一つでなくてよいが、「不明」と「ゼロ」の境界は守らなければならない。

観測範囲もgraphの一部である。Routing HistoryはRIS collector由来だ。Routing StatusもRISが「観測した」状態だと繰り返し、あるASにはRISから見えないneighborがあり得ると注意する。RIPEstatは定義された観測系からの強い公開証拠であって、Internet全体の完全な視界ではない。

さらに、live画面同士の比較には鮮度の罠がある。RIPEstatは、dataのtimelinessが収集頻度、store更新、processing delay、障害、cacheに左右されると説明している。異なる時刻に開いた旧画面と新画面の差は、front endではなくbackendの時間差かもしれない。意味の比較には、同一の取得済み応答、取得時刻、hash、query期間が要る。live testはservice healthに必要だが、別の問いに答える。

公開すべき最小記録

新たな審議組織も、二つのUIの永久併存も必要ない。代表的なfixtureごとに、一枚の版管理された記録をrolloutに添えればよい。

記録には、旧・新build、Routing History endpointとmethodologyのversion、resource、UTCの開始・終了、表示timezone、明示parameter、適用された全default、固定API応答の取得時刻とhashを書く。さらに、それぞれのviewが行うgrouping、sorting、truncation、missing valueの処理を示す。

fixtureは都合のよい一本線だけでは足りない。単一origin prefix、multi-origin、ソフト上限に届く応答、peer thresholdの上下、first hopを含むcase、peer情報が不確かな期間、終了していない最終interval、keyboard操作、狭い画面を含めるべきだ。見るべきなのはpixel一致ではない。重要な事実が消えたか、別groupへ移ったか、時間境界が動いたかである。

意図した差も記録する。accessibleな配色への変更は失敗ではない。legendの再配置が誤読を減らすなら改善だ。表示時刻をUTCへ統一することも、tooltipとexportが同じなら合理的である。理由を残せば、将来の担当者が古い制約を「整合性」と誤認して戻すことを防げる。

最後に、owner、未解決例外、review日、訂正・置換link、旧viewを止める判断基準が要る。装飾上の差がゼロになるまで古いcodeを残す必要はない。意思決定を変える差が解消または明示的に受容され、accessibility上の利用が通り、保存queryから新viewの読み方を再現できれば退場できる。

証拠が示していないこと

確認した資料は、現在のRouting Historyが誤っているとも、新版が公開済みまたは失敗したとも示さない。CSPがrouting dataを変える、悪用可能な脆弱性がある、RIPE NCCが観測を失った、内部testがない、という根拠もない。四半期計画は実装後報告ではなく、公開API文書は内部品質管理の全容ではない。

提案は予防的である。RISの観測、APIの公開契約、特定UI buildの表示判断を分けて残す。その線引きがあれば、安全性を急いで高めても、意味の継続を利用者の信頼だけに委ねずに済む。

情報源