要約

  • 公式 API の議程項目9131は、表示用タイトルが LACNIC 46 Wrap-Up、正規分類が LACNIC46、開催日時が2026年10月22日である。一方、記録タイトル、slug、ACF の event 参照は LACNIC 45 を示す。
  • 現在の英語議程レスポンスは62件で、すべて正規の LACNIC46 分類を使う。重複して置かれた ACF のイベント参照では61件が LACNIC46、9131だけが LACNIC45 を指す。
  • ホームページ項目8993は、タイトル、slug、分類、Mendoza を記した本文が LACNIC 46 にそろっているのに、ACF event の文字列は LACNIC 39 である。確認できるのは機械フィールドの不整合であり、表示障害や参加者の損害ではない。

閉会枠だけが二つの版を持つ

異なる版番号は、最終日の最後の20分に現れる。議程項目9131の時刻は、2026年10月22日の17時40分から18時まで。スペイン語の表示名は Cierre LACNIC 46、英語は LACNIC 46 Wrap-Up、ブラジル・ポルトガル語は Encerramento LACNIC 46 だ。

同じ JSON の別のキーを読むと、版番号が変わる。

項目9131のフィールド 格納値 指し示す版
英語の表示用タイトル LACNIC 46 Wrap-Up LACNIC 46
正規の our_events 分類 ID 310、LACNIC46 LACNIC 46
上位の記録タイトル LACNIC 45 Cierre LACNIC 45
上位の slug lacnic-45-cierre-2 LACNIC 45
ACF event 参照 ID 250、LACNIC45 LACNIC 45

埋め込まれたタクソノミーでも、ID 310 の名称は LACNIC46 である。ID 250 の公式タームは LACNIC45 で、国欄には Ciudad de México, México が入る。つまり、正規分類と三言語の見出しは現行版、内部タイトルとアドレスと重複参照は前版という構造だ。

この観察から、閉会枠が実際には LACNIC 45 のものだとは言えない。日付、正規分類、表示名はいずれも LACNIC 46 を示す。確実に言えるのは、同じ公開オブジェクトでも、ソフトウェアが選ぶキーによって版の答えが変わるということだけである。

62件中の1件という境界

2026年9月5日に取得した英語版 LACNIC46 ターム経由の議程コレクションには62件が含まれていた。62件すべての上位 our_events は [310] だった。

ACF の event 配列では、61件が同じ [310] を使い、1件だけが [250] を使った。その1件が9131であり、このレスポンスには第三の値はなかった。

分母を明示すれば、例外をシステム全体の障害に膨らませずに済む。1件のずれは議程全体の破損を証明しない。残る61件についても、二つの参照が一致しただけで、全項目の正しさを保証するものではない。内部データベース、検索、エクスポート、キャッシュ、全言語経路までは調べていない。

9131の作成日時と更新日時は同一で、API のローカル時刻表記では2026年7月24日17時25分28秒である。9月初旬に更新された別の議程項目はあるが、その動きから9131の不整合が生じた時期を推定することはできない。

ホームページには LACNIC 39 が残る

ホームページ APIが返す項目8993は、上位タイトルと slug が LACNIC46、正規分類がID 310である。本文は LACNIC 46 / LACNOG 2026 を、アルゼンチンの Mendoza にある Hilton Mendoza で10月19日から22日まで開くと説明する。ところが ACF event の文字列は LACNIC 39 だ。

この一項目だけでページ全体を LACNIC 39 と呼ぶのは誤りである。観察できる主な内容と分類は現行版にそろっている。古いミラーが、更新済みオブジェクトの中に残り得ることを示している。

場所も一つの記録に収まっていない。正規ターム310の国欄は Buenos Aires, Argentina のままで、開始日と終了日は空欄だ。一方、ホームページ本文は Mendoza と10月の日付を示す。英語ターム312も LACNIC46 と名付けられているが、翻訳用の少数フィールドしか公開しない。現行属性は複数の場所に分かれている。

取得した公開 HTML は、LACNIC 46 というタイトルとクライアントアプリのルートだけを持ち、議程行をサーバー側では描画していなかった。ブラウザーも同名のタブまで到達したが、端末がロックされ、描画後の行を目視・読み取りできなかった。したがって、訪問者に LACNIC 45 が表示された、旧 slug が検索に載った、エクスポートが誤参照した、とは主張しない。

優先フィールドは利用側の選択になる

our_events で分類し、info_en.title などのローカライズ欄を表示するフロントエンドなら、結果は LACNIC 46 になる。acf.event で集約したり上位 slug から URL を組み立てたりする処理なら、旧版が残る。どちらも可能な読み方だが、実際の LACNIC サービスが後者で失敗した証拠はない。

見た目が正しいことと、ソースの同一性がそろっていることは別である。現在の画面は適切なキーを選べても、将来の移行、フィード、コード変更は別のキーを採るかもしれない。逆に、ソースに矛盾があるだけで下流障害が起きたと決めつけることもできない。

正規ID、言語別ラベル、廃止予定のミラー、履歴として残す別名を区別する必要がある。権威の順番を、各実装者の慣習に委ねてはならない。

消す前に版の対応表を作る

必要なのは大規模な管理制度ではない。各版について、シリーズ名と版番号、正規・翻訳タームID、コンテンツIDと種類、言語別タイトル、現行の日時と場所、公開 slug、旧別名を結ぶ一枚の正規表で足りる。

公開前の検証では、すべての有効な分類フィールドが同じ版に解決されるかを調べる。LACNIC 46 のオブジェクトが term 250 を指す、あるいは有効なイベント欄が LACNIC 39 のままなら警告する。lacnic-45-cierre-2 を既存リンクのために残すなら、競合する現在値ではなく、履歴別名かリダイレクトとして扱う。

古い文字列を無言で上書きすれば、見た目は整うがリンクや由来を失う恐れがある。訂正履歴には旧値、正規値、フィールドの役割、発効時刻、別名や転送の扱いを残すべきだ。

共通の規則は薄いままでよい。共有するのは一つの版の同一性、検証可能な関係、訂正の履歴である。各言語の自然なタイトルは各言語に残す。現在の整合性のために過去の入口を壊すことなく、将来の利用者はどのキーを信頼すべきか判断できる。

情報源