サマリー

  • Ubiquitous Corp. データセンター Network. の公開レジストリ証拠は AS23929 に解決され、その名は Ubiquitous-AS で、APNIC 登録者は Foresightwave INC.、住所は滋賀県大津市である。これは古いネットワークアイデンティティを確立するものであり、稼働中のデータセンター施設を証明するものではない。
  • 2026 年 7 月 12 日時点の RIPE NCC の経路ビューでは、AS23929 についてアナウンスプレフィックス、IPv6、観測された近隣、現在のグローバル可視性は確認されなかった。過去の経路証拠は 203.191.136.0/21 とそれに関連するより具体的な経路に遡り、AS23929 の最終的なオリジン証拠は 2019 年に終了している。
  • Foresightwave 自身のサービスページでは、大阪のデータセンターからトランジットを提供し、APNIC メンバーとしてグローバルアドレスを供給できると述べている。しかし、施設名、ラック数や電源容量、ファイバー引き込み口、UPS や発電機の稼働時間、顧客のフェールオーバー証拠は公開されていない。
  • 現時点での証拠グレードは、Ubiquitous-AS のデータセンターネットワーク主張に対して「ネガティブ」である。より広範な Foresightwave のトランジットサービスは存在する可能性があるが、公開証拠はそのサービスを検証済みで耐障害性のあるデータセンター能力に変換するものではない。

レジストリ名は生き残るが、経路ネットワークは生き残らない

Ubiquitous Corp. データセンター Network. に関する最も具体的な公開証拠は、データセンターパンフレットではなく、自律システムの登録情報である。AS23929 の APNIC RDAP レコードでは、AS 名が Ubiquitous-AS とされ、国は日本、レコードはアクティブ、2008 年 9 月に登録、説明には「Ubiquitous Corp. データセンター Network.」と記載されている。同じレコードには登録者として Foresightwave INC. が挙げられ、住所は滋賀県大津市尾賀谷 1-13-4 深田ビル 2F、連絡先も記載されている。これは実在するレジストリの記録である。

しかし、それだけの記録である。自律システムレコードは、地域インターネットレジストリにおいて番号と管理上のアイデンティティが存在することを示すに過ぎない。建物が存在するか、ラックが設置されているか、顧客がいるか、電力負荷が保護されているか、あるいは現在トラフィックが流れているかは示さない。今回のケースでは、その違いが決定的である。なぜなら、経路層が沈黙しているからだ。RIPE NCC のAS23929 に対するアナウンスプレフィックスビューは、2026 年 7 月 12 日の観測ウィンドウにおいて空のプレフィックスリストを返した。経路状況ビューでも、IPv4、IPv6 ともにアナウンスプレフィックスはゼロ、観測された近隣なし、クエリ時点で AS を確認している RIS ピアもなしと報告されている。

これらの経路情報の事実は、Foresightwave が事業を継続していないことを意味するものではない。特定の Ubiquitous-AS ネットワークが、ここで検討する公開証拠において現在のグローバル経路オリジンとして可視化されていないことを意味する。この区別は重要である。なぜなら、ディレクトリ上のエンティティがデータセンターネットワークとして位置づけられているからだ。データセンターやトランジットサービスを購入する顧客は、契約から物理的な能力へ至る経路――施設、電力、冷却、ファイバー、経路、監視、復旧――を必要とする。AS23929 は単独ではその経路を提供していない。

歴史的な経路証拠が、なぜこの名前が基盤レコードに現れるのかを説明している。RIPE NCC の経路履歴エンドポイントは、AS23929 が 2005 年 10 月から 203.191.136.0/21 をオリジンし、後にそれに関連するより具体的な経路を確認していたことを示している。経路状況ビューでは、最初に観測されたオリジンプレフィックスは 203.191.136.0/21、最後に観測されたプレフィックスは 203.191.136.0/24 であり、最後の可視性は 2019 年とされている。したがって、公開証拠はかつて経路が存在したネットワークを支持するものであり、現在も経路が存在するネットワークを支持するものではない。

アドレスの証拠も移り変わっている。203.191.136.0/21 の JPNIC ミラー RDAP レコードでは、そのブロックが Netforest, Inc. 向けの NETFOREST-CIDR-BLK-JP と記述されている。現在の203.191.136.0/21 の RIPE NCC プレフィックス概要では、このブロックが AS23929 ではなく Netforest の AS17931 によってアナウンスされていることが示されている。これが直ちに企業売却、リース、あるいはサービス失敗を証明するわけではない。しかし、歴史的な Ubiquitous-AS 経路を現在の Ubiquitous-AS の顧客容量として扱えないことは証明している。

これが、本稿が容量の推定ではなく、格下げから始める理由である。古い AS レコードをキロワット、ラック数、ケージ数、あるいは顧客余力に変換する方法は、正当化できない。歴史的な 2,048 アドレスブロックを現在のサービス規模に変換する方法すら、正当化できない。なぜなら、そのブロックは現在、別の場所で観測されているからだ。もし Ubiquitous Corp. データセンター Network. がいまだに有効なサービスラベルであるならば、そのラベルが現在何をカバーしているか、事業者が明らかにする必要がある。

Foresightwave が手がかりを提供するが、施設境界は不明

最も有力な手がかりは Foresightwave 自身から得られる。Foresightwave のホームページでは、同社が日本全国の地域ビジネスをネットワークからシステム開発まで支援すると述べている。サービスページでは、接続ポイントとして大阪市内のデータセンターを利用し、主要キャリアのトランジットを大量購入して地域事業者向けに分割し、APNIC メンバーであるためにグローバルアドレスを準備できると説明している。これは、サービスを物理的な相互接続の文脈に置く貴重な証拠である。大阪のデータセンター接続ポイント、地域事業者、トランジット、アドレス供給という文脈だ。

しかし、同じページはデータセンターの中心的な疑問に答えを残している。大阪の施設名は挙げられていない。Foresightwave がスペースを所有しているのか、ケージを借りているのか、ラックを賃借しているのか、キャリアポートを転売しているのか、他社のルーム内でルータを管理しているのかについても触れられていない。ランドロード、施設運営者、電力供給の取り決め、冷却設備、防火・防水対策、建物内への引き込み経路、クロスコネクト数、キャリア受け渡し地点、Foresightwave と基盤施設間の保守義務についても特定されていない。この文言は、大阪の接続ポイントを備えたトランジットサービスを支持するが、所有または独立運営のデータセンター資産を支持するものではない。

Foresightwave の会社概要ページは、より広範なネットワーク事業であることを確認している。商号は Foresightwave、代表取締役は辻井 路子(Michiko Tsujii)氏、本社は大津市、2003 年 11 月設立、届出番号 E17-2598 の電気通信事業、IT ネットワーク企画・コンサルティング、ネットワーク構築・システム開発、APNIC および一般社団法人日本インターネットプロバイダー協会への参加が示されている。沿革には、初期の地域相互接続プロジェクト、2010 年の滋賀向け固定 IP インターネットアクセスサービス、2014 年の大津への移転、Juniper リセラー登録、SmartOptics との関係が含まれている。これらは関連する事業者のシグナルである。

しかし、それは施設の証明ではない。ネットワークインテグレータやトランジットリセラーは、自社でデータセンター設備を一切保有していなくとも技術的に有能であり得る。企業は APNIC メンバーでありながら、サードパーティ施設を通じてサービスを提供できる。企業は大阪のデータセンターにルータを設置していながら、電力フィード、発電機、冷却、防火システム、入退室管理、キャリアライザーを完全に他社に依存している可能性もある。したがって、購入者が問うべきは、Foresightwave が存在するかどうかではない。サービスチェーンのどの部分を Foresightwave が管理し、どの部分が外部委託され、どの部分が障害時にテスト済みか、である。

同社のトピックスページは、これが大規模な公共インフラ事業者ではなく、小規模で可視性のあるビジネスであることを補強する。2026 年 6 月の電話線工事通知、季節休業のお知らせ、2024 年の新規コワーキングスペース契約受付終了の案内、過去の電話回線障害のお知らせなど、定型的な通知が含まれている。これらのいずれも、トランジット業務の弱点を証明するものではない。しかし、公開されている企業の表面は、サイトのスペックシート、電力表、ネットワークマップ、稼働履歴を備えた透明なコロケーションプラットフォームではなく、オフィス的でサービス会社的であることを示している。

また、ウェブプレゼンスは AS23929 の外部に位置している。RIPE NCC のwww.foresightwave.net の DNS チェインビューは、そのホストを 159.28.124.124 にマッピングし、foresightwave.net の DNS チェインビューは、apex を 159.28.124.125 にマッピングした。159.28.124.112/28 の JPNIC ミラー RDAP レコードは、この小さなブロックが Foresight Wave INC. 向けの FSW-NET であることを示している。RIPE NCC のそのアドレス範囲のプレフィックス概要は、それをより大きな So-net のアナウンスプレフィックスに紐付けている。これは、Foresightwave のライブなウェブエンドポイントを示すが、ライブな Ubiquitous-AS オリジンは示さない。

この分離は有用なデューデリジェンスシグナルである。企業は、古い AS が休眠状態である間にウェブサイトをホストし、事業を運営できる。ディレクトリエンティティは、これら二つの事実が同一であるかのように評価されるべきではない。もしサービスが現在、別のネットワーク、キャリア管理のポート、または異なる AS を通じて実行されているならば、顧客は現在のネットワーク識別子、サービス境界、施設スケジュールを必要とする。

古いインポートレコードは現在のキャリア多様性ではない

AS23929 の古いレジストリポリシーには、二つのキャリアの手がかりが含まれている。RIPE NCC のAS23929 の WHOIS ビューには、AS17685 と AS9607 のインポートおよびエクスポート行が含まれている。現在の APNIC および JPNIC のレコードでは、AS17685は Square Enix 向けの PLAYONLINE、AS9607は BroadBand Tower 向けの BBTower と特定されている。いずれも自らの権利でアクティブな日本のネットワークである。RIPE NCC のAS17685 と AS9607 の経路状況比較では、AS9607 は IPv4 と IPv6 スペースの両方で可視化されており、AS17685 は IPv4 スペースで可視化されている。これらのネットワーク自体が問題なのではない。

問題は、AS23929 がそれらを現在使用しているかどうかである。2026 年 7 月 12 日時点で、RIPE NCC のAS23929 の ASN 近隣ビューでは、近隣はゼロだった。ASN 23929 の PeeringDB クエリは、公開ネットワークレコードを返さなかった。AS23929 の CAIDA AS Rankは、AS が観測されておらず、プロバイダー、ピア、顧客、プレフィックスもゼロとマークした。IP2Location の AS23929 ページは、依然としてその名前を foresightwave.net に関連付け、アップストリームやダウンストリームは報告せず、現在のグローバルアナウンスメントではなく過去のまたは商業的なマッピングを反映したと思われるアドレス総数を示している。信頼できる現在の結論は、ここで検討した公開経路コレクタのいずれも、AS23929 がアクティブであるとは見ていないということである。

キャリアの多様性は古いインポート行から推測できない。それらは過去の計画、過去の運用状態、古くなった経路ポリシー、あるいは未使用のオブジェクトを示している可能性がある。たとえかつてライブ接続を反映していたとしても、二つのアップストリーム名が耐障害性のあるファイバーを証明するわけではない。二つの BGP セッションはクロスコネクトパネル、光筐体、建物入口、ダクト、メトロプロバイダー、または電力の依存関係を共有することができる。障害時に重要な多様性は物理的かつ運用的なものである。つまり、分離された入口、分離された meet-me ルームまたは保護された経路、分離されたアクティブデバイス、独立した電源、文書化されたエスカレーション、テストされたフェールオーバーである。

Foresightwave の現在のトランジットサービスにとって有用な証拠は、AS23929 の歴史の教訓ではなく、現在のキャリアスケジュールであろう。それは、大阪の施設、キャリアポート、受け渡しタイプ、コミットされた帯域、バースト余力、経路分離、メンテナンスウィンドウ、エスカレーション連絡先、そして片方の経路を喪失した後の経路収束結果を特定すべきである。もし現在のサービスが AS23929 なしで販売されているならば、事業者はどの AS が顧客経路をオリジンするか、またはどのアップストリームが割り当てアドレススペースをアナウンスするかを明示すべきである。もし AS23929 が意図的に休眠中であるならば、顧客が沈黙する AS を原因不明の脆弱性と扱わないよう説明されるべきである。

公開 IPv6 証拠の欠如もまた実際的な制約である。RIPE NCC の経路状況では AS23929 の IPv6 アナウンスはゼロであり、現在の公開ウェブエンドポイントは IPv4 経由で観測された。これは、Foresightwave が別の構成で IPv6 をサポートできないことを意味するものではない。Ubiquitous-AS レコードがデュアルスタックトランジットを公に実証していないことを意味する。公共サービス、近代的なアクセスネットワーク、または将来のポータビリティのために IPv6 を必要とする顧客は、実際のサービス境界での現在の証明を必要とする。

キャリアからの教訓は単純である。論理的なレジストリ履歴は可用性の約束ではない。ライブなトランジットサービスは別の AS の背後に、または別のプロバイダーを通じて存在し得るが、証拠はそのライブな経路を名指ししなければならない。それがなされるまでは、顧客は Ubiquitous-AS ラベルをアクティブな経路冗長性としてではなく、歴史的識別子として評価すべきである。

電力こそが欠落している容量の数字である

本稿の課題は、謳われているデータセンター容量が電源と回線の制約を克服できるか否かである。Ubiquitous Corp. データセンター Network. については、いかなる公開容量数値も検証できない。Foresightwave のサービスページは大阪にデータセンター接続ポイントがあると述べているが、そこにどれだけのラック、ポート、ルータ、または顧客が存在するかは述べていない。契約電力、保護 IT 負荷、UPS トポロジー、発電機定格、燃料稼働時間、配電経路、または一つのコンポーネントが利用不能になった場合の残容量についても明示していない。

この欠落は、10 年前以上に 2026 年においてより重要である。日本のエネルギー白書 2025 概要は、新たなデータセンターと半導体工場により電力需要が増加すると予想しており、将来のデータセンター立地を電力と通信の「ワットビット連携」を通じて枠組み付けている。また、大規模データセンター需要の不均一な分布と、データセンター建設リードタイムとクリーン電源リードタイムの差にも焦点を当てている。言い換えれば、電力可用性はもはや背景的なユーティリティの前提ではなく、製品の一部なのである。

小規模または地域トランジット事業者にとって、関連する数字はハイパースケールのメガワットではない。ルータ、光機器、管理システム、ホストされている場合は顧客機器、そしてサービスをサポートするあらゆるサーバや制御プラットフォームといった、実際の区切り点での保護負荷である。ルータ、光筐体、トップオブラックスイッチ、認証ホスト、または DNS サービスが電力を喪失した場合、建物が稼働し続けていてもサービスは停止し得る。データセンター接続ポイントに関するセールスステートメントは、Foresightwave の機器が A 給電と B 給電を備えているか、両方の給電が UPS と発電機によってバックアップされているか、あるいは単一の分電盤がサービスを切断し得るか、という問いに答えない。

日本の日本データセンター協会(JDCC)のファシリティスタンダード概要はここで有益である。なぜなら、「データセンター」を一般的なラベルとして扱うのではなく、信頼性とセキュリティ要件をファシリティカテゴリに分けているからだ。JDCC データセンターファシリティスタンダードの英文概要は、建築、電気設備、空調設備、通信設備、ファシリティ運用、セキュリティ、サーバルーム、エネルギー管理といったカテゴリを説明している。そのサンプル基準には、より高いレベルに対する電力線冗長性、電源経路冗長性、燃料または水の貯蔵が含まれる。検討した公開情報源のいずれも、Ubiquitous-AS または Foresightwave が JDCC ティアを主張していることを示していないが、このフレームワークは日本の施設購入者が期待すべき証拠が何かを示している。

グローバルベンチマークも同じ点に到達する。Uptime Institute のティア認証概要は、設計、建設施設、運用持続可能性の成果を区別しており、ティアの説明は冗長性、並行保守性、耐障害性に焦点を当てている。ラベル、接続ポイント、または一対のルータは、これらの成果のいずれも証明しない。顧客には、図面、定格、測定負荷、試験記録が必要である。

発電機の証拠は特に重要である。なぜなら、ユーティリティの中断は、効率的なホストからアイランド化された発電所へとデータセンターの役割を変えるからだ。Uptime Institute の燃料システム信頼性に関する議論は、燃料供給、ポンプ、制御装置、デイタンク、バルクタンク、再充填手配を一つの故障チェーンの一部として扱っている。Foresightwave は大阪の接続ポイントについて、稼働時間の数字を一切公開していない。また、自社の機器が施設運営者の発電機契約によってカバーされているか、ユーティリティから発電機への切り替え中にネットワークルームが通電状態を保つか、キャリア meet-me ルームが同じバックアップ経路を共有するかについても公開していない。

これは、Foresightwave に対して機密性の高い図面を公に開示するよう求めているのではない。信用できる顧客向けパッケージは、契約の下で共有され得る。それには施設名、利用可能な負荷と保護負荷、シングルコード接続のデバイスはどれか、保守中に何が起こるかを示すべきである。Uptime のデュアルコード電源に関するノートは、施設の冗長性がデバイス層で破綻し得ることを念押ししている。もしルータ、ファイアウォール、ストレージ機器、または管理サーバが一つの電源経路しか持たなければ、顧客向けサービスは高度に耐障害性のある建物の内部でさえ、その単一障害点を継承する。

したがって、設置容量、販売可能容量、耐障害容量は異なる数字である。設置容量は通常の状況下でサイトがサポートできるもの。販売可能容量はコミットメントと予備を差し引いたもの。耐障害容量は、定義された障害またはメンテナンス状態の後に残るものである。Ubiquitous Corp. データセンター Network. については、これらの数字のいずれも公開されていない。そのため、いかなる容量の主張も、運用証拠ではなくリスクの価格未決定と見なされる。

冷却と大阪のハザードは実際の部屋に結び付けられなければならない

冷却は電力問題のもう一方の側面である。サーバとルータは電気を熱に変換し、データセンターサービスは通常負荷、保守、障害中にその熱を除去する能力と同等の安定性しか持たない。Foresightwave のサービスページは大阪のデータセンター接続ポイントを挙げるが、施設、冷却設計、環境エンベロープ、センサー配置、水依存性、あるいは冷却コンポーネント喪失後の熱的結果を開示していない。

大阪は特異な気候ではないが、基盤にとって過酷な夏の環境である。気象庁の平年値表は、大阪の 1991-2020 年月平均気温が 8 月に 29.0℃ でピークに達することを示し、大阪の月別気候統計ページは、月別の日最高気温平均を追跡している。これらの公開気候記録は、Foresightwave のケージ内の室温を確定するものではない。しかし、大阪におけるデータセンターの主張が、一般的な声明ではなく、サイト固有の熱排出証拠を必要とする理由を示している。

鍵となるテストは、冷却が存在するかどうかではない。電源状態が変化した後に冷却が適切であり続けるかどうかである。ユーティリティ喪失は、冷却を発電機バックアップ電源に依存させる可能性がある。UPS の切り替えは、一部の熱排出機器が発電機の安定化を待つ間、IT 負荷を存続させ得る。暑い日はマージンを減少させる。もし事業者のサービスがネットワークデバイスのみに依存するならば、熱負荷は控えめかもしれないが、部屋、meet-me エリア、またはアクセス機器が過熱すれば、サービスは依然として停止し得る。もし顧客サーバや共有プラットフォームがホストされているならば、必要とされる証拠は増大する。

ASHRAE のデータセンター向け環境ガイダンスも、温度だけが環境変数ではない理由を示している。粒子状汚染、ガス状汚染、湿度、腐食は機器の信頼性に影響を与え得る。Foresightwave の公開資料は、フィルタ、監視、腐食制御、漏洩検知、大阪の部屋の保守について何も述べていない。これは小規模な公開ウェブサイトとしては通常のことだが、顧客のデューデリジェンス負担を未解決のままにする。

立地ハザードも同様にサイト固有である。大阪市の浸水ハザードマップ資料は、河川洪水、内水氾濫、高潮、津波を市に関連する災害種別として説明している。この文書は区ごとであり、名前のないデータセンターサイトが曝露しているか安全であるかをラベル付けするために使用すべきではない。その価値は、それが次の質問リストを設定する点にある。すなわち、床面高さ、浸水深さ、排水、入口封鎖、燃料と配電盤の配置、キャリアダクトルート、緊急アクセス、そして輸送途絶後の復旧である。

大津の本社は別の連続性に関する疑問を生じさせる。APNIC レコードと Foresightwave 会社概要ページは大津を指し示しているが、サービスページは大阪のデータセンター接続ポイントを指し示している。それは合理的な分離かもしれない。すなわち、滋賀に事務所、エンジニアリング、管理機能を置き、大阪に相互接続を置くという分離だ。しかし、それは購入者が二つの連続性の全体像を必要とすることをも意味する。大阪サイトはトラフィックを動かし続けなければならない。大津またはリモートのサポート機能は、監視、顧客コミュニケーション、復旧権限を機能させ続けなければならない。機器が故障したから、誰も施設にアクセスできないから、あるいは認証情報とベンダー連絡先を持つ人々が連絡不能だから、サービスは停止し得る。

火災と消火の証拠も同じパッケージに属する。別のデータセンター内にあるルータケージは、ランドロードの探知、区画化、ガス式または水式消火、警報ルーティング、緊急アクセスに依存するかもしれない。Foresightwave は、どの文書が施設運営者に属し、どの文書が Foresightwave 自身の機器慣行に属するかを顧客に伝えるべきである。証拠には、最近の点検状況、保守ウィンドウ、アクセスルール、煙、漏水、バッテリー事故、または偶発的な電源遮断への対応計画が含まれるべきである。

施設名なしでは、本稿は実際の洪水、火災、地震、または熱曝露を評価することができない。それがポイントである。現在の公開記録は、容量が利用可能かどうかを決定する物理層の手前で止まっている。

AS が沈黙していても顧客への影響は集中している

非アクティブな AS であっても、他の基盤を通じてトランジット、アドレス管理、ネットワーク機器、システム開発、またはホスティング機能を販売している場合、顧客に影響を及ぼし得る。Foresightwave の一次ソースのページは、地域事業者サポート、システム開発、ネットワーク機器調達・構築、固定 IP および相互接続作業の履歴を説明している。したがって、顧客影響の対象領域は AS23929 の現在の経路表に限定されない。

第一の影響クラスは、Foresightwave を通じて共有トランジットを購入している、または検討している地域 ISP である。もし大阪の接続ポイントが故障すれば、これらの事業者はアップストリーム容量、アドレス到達性、エンジニアリングサポート、あるいは自前の都市 meet ポイントを構築する代わりに選択した経済的な経路を喪失するかもしれない。それらの事業者が地域の企業、学校、自治体、小規模アクセスネットワークにサービスを提供している場合、停止は再販サービスを通じて外側へ波及し得る。公開証拠は現在の下流ネットワークを特定していないため、これは実名の顧客に関する主張ではなく、依存性のモデルである。

第二の影響クラスは、Foresightwave のネットワーク設計または機器の役割に依存する顧客である。スイッチ、光モジュール、あるいはルータの設計決定は、データセンターの建物が健全であっても停止の一部となり得る。Foresightwave のサービスページは、Cisco、Ruckus、Juniper、および光製品の作業を宣伝している。これにより、文書化、スペアパーツ、ベンダーエスカレーション、設定バックアップが重要になる。もし顧客ネットワークを設計したのと同じ小規模チームがその復旧に必要とされるならば、スタッフの層の厚さも耐障害性の一部である。

第三の影響クラスは、同社またはそのパートナーによって開発またはホストされたシステムを利用する顧客である。会社概要ページとサービスページは、PHP ベースのシステム開発と通信関連のサービス管理システムを説明している。公開情報源はそれらのシステムがどこで稼働しているかを示していない。もし何らかの運用ツールがトランジット機器と同じ大阪の部屋でホストされている場合、施設の停止によって顧客サービスとそれを管理するためのツールの両方が失われる可能性がある。もしそれらが別の場所で稼働しているならば、その分離が文書化されるべきである。

したがって、復旧の証拠はサービス固有であるべきである。NIST のコンティンジェンシー計画ガイドは米国連邦情報システム向けに書かれているが、その中核的なカテゴリは広く有用である。計画:システム、電気通信、人員、テスト、保守、復旧優先順位。Foresightwave にとって有用な顧客向け計画は、誰がインシデントを宣言するか、誰が経路を変更できるか、誰がクロスコネクトサポートを依頼できるか、設定バックアップがどこに保管されているか、オフィス電話が不通の場合に顧客にどう連絡するか、大阪施設にアクセス不能な場合にサービスをどう復旧するかを定義するであろう。

公開ステータスの証拠が助けになる。データセンターやトランジットプロバイダーは、信頼性を得るために完璧な履歴を必要としない。日付入りのメンテナンス通知、インシデントサマリー、是正措置、テスト結果が必要である。Foresightwave のトピックスページは通常のオフィス案内と一部の電話サービス中断を示しているが、ネットワークステータスのアーカイブやデータセンターメンテナンスログは示していない。その欠如は、隠れた停止記録として扱われるべきではない。ビジネスがそのサービスに依存している顧客にとっての情報開示ギャップとして扱われるべきである。

契約上の救済策は実際のアーキテクチャと一致すべきである。ネットワーク可用性パーセンテージだけでは不十分であり、もしそれが Foresightwave のポートのみを測定し、アップストリームキャリア、施設、顧客ルータ、DNS、アドレス認証、計画保守を除外しているならば。顧客は、サービスレベルが経路到達性、パケット損失、機器への電力、クロスコネクト修復、リモートハンズ、顧客機器、サポート応答、あるいはトランジット製品のみをカバーしているのかを知るべきである。また、クレジットが唯一の救済策であるかどうかも知るべきである。なぜなら、クレジットは長期間の停止中に失われたデータを復元したり、地域の事業運営を維持したりしないからである。

エグジット計画は、公開 AS が休眠中である場合に一層重要になる。もし顧客がアドレスを受領するならば、それらがポータブルか、Foresightwave から割り当てられたか、キャリアから割り当てられたか、別の AS によって経路されるかを知る必要がある。認可状、ルートオブジェクトの責任、DNS 制御、逆引き DNS の責任、移行パスが必要である。不明確なアドレス慣行を持つ休眠 AS は、顧客が依存を減らそうとしているまさにその時に移行を遅くする可能性がある。

証拠グレードを変えるものは何か

Ubiquitous Corp. データセンター Network. は、少数の日付入りの具体的な開示によって「ネガティブ」な証拠グレードから脱することができる。第一はアイデンティティである。現在のサービスが Ubiquitous-AS か、Foresightwave トランジットか、レガシーラベルか、サードパーティ施設アレンジメントか、事業者は明示すべきである。契約主体、顧客向けサービス名、現在の AS または経路プロバイダー、顧客が利用可能なアドレスリソースを名指しすべきである。

第二は施設境界である。開示は機密の詳細を公開ページに載せる必要はないが、顧客は都市、施設運営者、建物の役割、Foresightwave のフットプリント(ラック、ケージ、キャリアキャビネット、ルータシェルフ、またはリモート管理ポート)を受け取るべきである。所有機器、賃借スペース、転売トランジット、キャリア提供サービス、ランドロード管理設備を区別すべきである。古い AS23929 の説明は、現在のサービスと整合させるべきである。

第三は電力と冷却の証拠である。有用なパッケージは、契約電力、現在のピーク負荷、一つの電源コンポーネント除去後の保護負荷、UPS サポート、発電機カバレッジ、燃料稼働時間、メンテナンス状態、ラック給電構成、すべての重要機器がデュアル給電かどうかを示すだろう。冷却の証拠は、環境目標、測定された吸気温度、アラート閾値、真夏の余力、ユーティリティ喪失と一つの冷却コンポーネント停止時に何がサポートされたままかを特定すべきである。

第四はキャリア証拠である。事業者は現在のアップストリーム、交換所またはプライベート相互接続場所、物理的な受け渡しポイント、コミットされた帯域、ルートオブジェクト責任、IPv6 利用可能性、障害テスト結果をリストすべきである。もし AS23929 が使用されていないならば、顧客は現在の AS と、なぜ Ubiquitous-AS レコードがいまだに存在するのかを知るべきである。もし二つのキャリアが提供されているならば、事業者はダクト、入口、光機器、電源が真に分離されているかを明示すべきである。

第五は復旧証明である。顧客は、最新のユーティリティ切り替えテスト、発電機負荷テスト、キャリアフェールオーバーテスト、設定復元テスト、顧客影響演習の結果を見るべきである。その記録には、継続時間、負荷、例外、是正措置を含めるべきである。失敗したテストと修正を開示する方が、完璧だが未テストの主張を提供するよりも良い。

第六は独立または施設所有者の文書である。名前の挙がった大阪のデータセンターは、JDCC、ISO、SOC、防火安全性、電気点検などの証拠を保有するかもしれない。文書の種類は範囲ほど重要ではない。もし認証がランドロードの建物をカバーしているが Foresightwave のルータ設定をカバーしていないならば、そう述べるべきである。もし点検が物理的設備をカバーしているが顧客のフェールオーバーをカバーしていないならば、そう述べるべきである。範囲の正直さは、バッジよりも有用である。

第七は公開経路ハイジーンである。もし AS23929 が意図的に引退しているならば、公開記録はそれを明白にすべきである。もし復帰が意図されているならば、経路がライブな時に現在の経路計画と ROA ステータスを公開すべきである。もしそれが単に歴史的なアーティファクトに過ぎないならば、顧客にそれを運用能力の証明として扱うよう求めるべきではない。現在の経路可視性はサービスの全体ではないが、データセンターネットワークとラベル付けされたネットワークにとって、それは基本的な証拠層である。

購入者が依存する前にサービスをどうテストすべきか

このエンティティに対する実際的なデューデリジェンスパスは、名前を資産として受け入れることを拒否することから始めるべきである。「Ubiquitous Corp. データセンター Network.」はレジストリの説明である。購入者が実際に依存するであろうサービスは、現在の契約、ポート、アドレス、デバイス、部屋、人々の集合である。購入者は、Foresightwave またはいかなるリセラーに対しても、これらのピースを文書でマッピングするよう要求すべきである。そのマッピングは、現在のサービスラベル、法的契約主体、施設運営者、大阪の住所または匿名化された施設識別子、そして顧客経路をアナウンスする現在の AS またはアップストリーム AS から始めるべきである。もし AS23929 がサービスから欠落しているならば、それは脚注として残されるのではなく、明示的であるべきである。

第二のステップは、アドレス権限をテストすることである。もしサービスがパブリック IPv4 スペースを含むならば、顧客はアドレスが Foresightwave 自身の割り当て、キャリアプール、施設パートナー、顧客所有の割り当て、または一時的な割り当てのどこから来るのかを知るべきである。誰がルートオブジェクトを作成するか、RPKI が使用される場合に誰が ROA に署名またはリクエストするか、誰が逆引き DNS を管理するか、そしてサービスを移行するためにどの書類が必要かを知るべきである。古い 203.191.136.0/21 の歴史は、これがなぜ重要かを示している。アドレススペースは移動、再割り当て、別の AS による経路、またはアップストリーム契約に束縛される可能性がある。停止中にこれを学ぶ顧客は、既に交渉力を失っている。

第三のステップは、大阪の接続ポイントをフロアレベルの責任モデルに変換することである。購入者は、どのキャビネットに Foresightwave の機器が含まれているか、そのキャビネットが施錠されているか、誰がアクセスできるか、誰がリモートハンズを供給するか、どの電源フィードがそのキャビネットに供給しているか、どのクロスコネクトパネルが使用されているか、そしてどのシステムが Foresightwave の制御外にあるかを尋ねるべきである。もし Foresightwave がルータのみを管理しているならば、施設運営者の電力と冷却の証拠は、顧客がそれに依存するため、やはり検討されなければならない。もし Foresightwave がサーバや制御システムもホストしているならば、そのレビューにはそれらのデバイス、ストレージ、バックアップ、管理アクセスが含まれるべきである。

第四のステップは、ライブ経路テストを要求することである。サービスは契約内に存在しながら、グローバルテーブルから不在であり得る。それに依存する前に、顧客は経路広告を観測し、複数の独立したルッキンググラスまたはテレメトリポイントから可視性を確認し、期待されるオリジン AS を検証し、制御された変更後の収束を測定し、一つのアップストリームまたはクロスコネクトが除去されたときに経路が約束どおりに変化するかを確認すべきである。もしサービスが顧客経路広告なしに提供されているならば、同等のテストは、通常および障害条件下での顧客サービスエンドポイントへのトラフィックおよび到達可能性の演習である。

第五のステップは、実際の負荷における電力および熱マージンを測定することである。購入者は、関連機器が大きな建物内の小さなルータフットプリントであるかもしれない場合に、一般的なデータセンター声明を受け入れるべきではない。現在のキャビネット消費、許容最大消費、A 給電と B 給電の負荷バランス、ブレーカー定格、測定された吸気温度、アラート閾値、夏季の最近の最高動作温度を尋ねるべきである。もし機器がシングルコード接続ならば、顧客は補償する制御を知るべきである。もしキャビネットが電源サイクル復旧のためにランドロードのリモートハンズに依存しているならば、応答目標が契約内にあるべきである。

第六のステップは、サポート通信をテストすることである。Foresightwave の公開通知には通常の電話線工事と過去の電話障害が含まれているが、それはネットワーク障害の証拠ではない。それらは、顧客接点が一本のオフィス回線に依存すべきでないことを想起させる。耐障害性のあるサービスは、緊急時のメール、電話、チケット、エスカレーションルートを定義すべきであり、営業時間外に何が起こるか、通常のオフィス通信が利用不能な時に何が起こるかを含む。顧客は、経路変更、クロスコネクト作業、リモートハンズ、機器交換、顧客通知を承認する権限を誰が持つかを知るべきである。

第七のステップは、メンテナンスと緊急事態を区別することである。計画されたメンテナンスは、影響を受けるポート、キャリア、デバイス、顧客サービスを特定し、ロールバック計画と、約束された保護容量を保持するメンテナンス状態を伴うべきである。緊急作業は、誰が機器に触れることができ、変更をどう記録し、顧客がポストインシデント説明をどう受け取るかを定義すべきである。沈黙する AS は、ライブ監視にギャップを隠蔽し得る。小規模な事業者は、規律ある変更記録と独立した経路チェックによってそのリスクを回避できる。

第八のステップは、未解決のままのものを価格に織り込むことである。もし事業者が施設名を明かさず、現在のアップストリームを開示せず、電源フィード分離を証明せず、フェールオーバーを実演せず、アドレスポータビリティを提供できないならば、顧客は依然としてそのサービスを購入できるが、ベストエフォートまたはセカンダリパスとして購入すべきである。重要なサービスは、独立したトランジット、独立した DNS、独立したバックアップ、そしてテスト済みのエグジットパスを維持すべきである。それは Foresightwave の能力の否定ではない。サービス名が暗示するよりも少ないことを証明する公開記録への正しい応答である。

現在の評決:生きた会社、非アクティブな AS、未証明のデータセンター主張

公開記録は三つの別個の結論を支持する。第一に、Ubiquitous Corp. データセンター Network. は AS23929、Ubiquitous-AS のレジストリ上の名前として存在する。第二に、Foresightwave は日本のネットワーキングおよびシステム企業として存在し、大津の本社、APNIC メンバーシップ、電気通信事業の開示、大阪のデータセンターを参照する一次ソースのトランジットサービスを有する。第三に、AS23929 はここで検討したグローバル経路証拠において現在可視化されていない。

これらの事実は交換可能ではない。ライブな企業ウェブサイトは、休眠中の AS をアクティブにしない。歴史的な AS レコードは施設の容量を証明しない。大阪のデータセンター接続ポイントを参照するサービスページは、所有ラック、保護負荷、二重ユーティリティフィード、発電機稼働時間、冷却冗長性、分離されたキャリア入口、テスト済みの顧客復旧を証明しない。公開証拠は物語を施設のドアの前まで運び、そこで止まる。

顧客にとって、最も安全な仮定は、事業者が別段の証明をしない限り、Ubiquitous-AS ラベルには現在の耐障害性の価値がないということである。Foresightwave のトランジットサービスは、特に自前のキャリアアレンジメントを構築せずに大阪の meet ポイントを欲する地域事業者にとって、商業的に有用であり続けるかもしれない。しかし、それは名前付き施設、現在のアップストリーム、電力/冷却の範囲、アドレス権利、復旧テストを備えた特定のサービスとして購入されるべきであり、推論されたデータセンターネットワークとして購入されるべきではない。

投資家やディレクトリ読者にとっても、同じ規律が当てはまる。機会は、数えられるのを待っている可視的なデータセンター資産ではない。それは古いネットワークアイデンティティに付随する、薄いが実在する事業者シグナルである。重要な運用表面は小さく、物理的である。すなわち、ルータ、ポート、電源フィード、冷却依存性、建物アクセス、キャリア受け渡し、大阪サービスを存続させる人々である。これらはいずれも、AS23929 の現在の公開経路表から読み取ることはできない。なぜなら、その表は空だからである。

したがって、現在の Ubiquitous Corp. データセンター Network. の経路およびデータセンター容量の主張に対する証拠グレードは「ネガティブ」である。Foresightwave が現在のサービス境界と施設の証明を公開すれば、グレードは迅速に改善し得る。それまでは、謳われている容量は未検証として扱われるべきであり、そのサービスを利用する顧客は独立したトランジット、独立した DNS、テスト済みの移行パスを維持すべきである。