要約

  • InterLAN IX の Lighthouse は、会員からの変更依頼を複数の装置へ届ける前に、装置ごとの設定案、ロールバック用タイマー、個別確認を置く。安全な復旧を証明できなければ人が引き継ぐ。
  • データベースが「あるべき状態」を握り、AI は読み取りと報告書作成にとどまる。セルフサービスの画面に、ネットワーク全体の決定権まで渡していない。

クリック一回、ルーターは三台

「会員が自分で変更できる」は耳触りがいい。空港の自動チェックインのように、列は短くなり、窓口の人員も別の仕事に回せる。だが交換所の装置は、一人分の搭乗券を印刷する機械ではない。会員の一件が複数のルーターに及べば、一台だけ変更された途中の状態も共有設備の現実になる。

RIPE 93 の発表概要で、InterLAN IX の Andrei Dinu が示す Lighthouse は、この途中を隠さない設計だ。Nokia SR OS と Arista EOS が混在するネットワークで、一つの依頼について装置ごとの設定案を先に示す。それぞれに復旧タイマーを設け、確認も一台ずつ進める。安全な復旧を示せない場面では、人間の担当者が引き取る。会議ページには現時点で議事録、スライド、録画がなく、実際の処理件数や復旧成績も載っていない。公表されているのは運用の設計である。

この設計が重要になる理由は、InterLAN 自身が説明するサービスにある。公共ピアリング、二つのルートサーバー、プライベート VLAN、予備ポート。どれも複数のネットワークが使う交換基盤の一部だ。ある会員向けの設定を急ぐほど、別の会員が使う経路との境界を正確に守る必要がある。Lighthouse が扱う具体的な変更メニューは公開されていないから、ここで特定の VLAN 変更が既に実施されたと装う必要はない。問題は複数装置にまたがる変更権限の構造そのものだ。

「ロールバック可能」と書くのは簡単だ。実際には最初の装置が変更を受け取り、次の装置が拒むことがある。戻す指示を送れたとしても、戻るまでの数分間は消えない。Lighthouse の発表概要は、魔法の一括取り消しをうたっていない。装置ごとのタイマーと確認、そして安全性が立証できない時の人への引き継ぎを挙げる。責任の所在を曖昧な「システム」に預けない点に、むしろ信頼がある。

正本を決める静かな権力

Lighthouse で最も政治的なのは、派手な AI 画面ではなくデータベースだ。発表概要では、データベースが意図した状態の正本を持つ。装置へ直接打ち込まれた手作業の変更は差分として現れ、黙って正本に取り込まれない。深夜の応急処置が翌朝には恒久方針になっていた、という事故を防ぐための線引きである。誰が依頼し、誰が承認し、何が実機に残ったかを分けて読める。

盧恒の Note 73 が問う「参加者がいつ決定権者に化けるのか」という問題は、会議室だけの話ではない。会員は依頼できる。運用者は共同設備の意図を承認する。技術者は緊急対応できる。どの行為が恒久的なネットワーク方針になるかを記録しなければ、セルフサービスは権限の抜け道になる。データベースの正本性は退屈な仕様書の一行に見えて、組織の統治そのものを動かす。

本番環境のスナップショットから作ったデジタルツインで変更を予行演習するという記述もある。必要なのは、そのスナップショットの時刻、実機との差、演習結果と承認のつながりだ。これらの実例は公表されていない。取材で最初に求めたいのは宣伝用の画面ではなく、一件の依頼から装置ごとの確認、復旧結果まで続く記録だろう。

AI には報告書と移行計画を書かせる。設定を変更する道具は渡さない、と発表概要は明記する。自信満々の文章を作る能力と、共有ネットワークのスイッチを動かす資格は別物だ。InterLAN の FAQでは、ルートサーバーとの BGP セッションは任意で、参加者は自らのピアリング方針を選べる。交換所の共同設備の管理権と、参加ネットワークの経路選択権も別の箱に入っている。RIPE NCC の RIS 資料が InterLAN-IX の RRC22 を挙げるのは、外から経路を観測できるという別の証拠面だ。観測値から内部の承認者の名前は読めない。