見えている経路と契約責任の間：Datacenta Hosting Ltd を四つの身元から検証する

Summary

RIPE の登録と RIPEstat の観測は、AS196745 が DATACENTA-AS としてアドレス空間を広告し、外部ネットワークから広く見えていることを裏付ける。しかし、設備所有、回線の物理的多様性、顧客契約、請求、SLA 責任までは証明しない。
Companies House には SC208801、15255267、03290605 という別々の法人記録があり、Datacenta Hosting の名称をめぐる変更時期も近接している。公開提出書類だけで、顧客、資産、IP 資源、契約または債務の移転を推定することはできない。
X-Net の公開条項は、マネージドサービスの提供者を X-Net (Services) Ltd trading as Datacenta Hosting と示し、帯域、バックアップ、保守、物理アクセス、サービス水準、終了時の義務を顧客固有の Service Specification に委ねている。
買い手に必要なのはブランドの説明ではなく、署名主体、ASN 登録者、設備と回線の権利、復旧設計、監視、クレジット、データ移行と機器撤去を一つずつ照合できる証拠束である。

一つに見える名称を、最初から一つと扱わない

ホスティング事業者のデューデリジェンスでは、ウェブサイトのロゴ、BGP 上の名称、請求書の社名が似ていれば、同じ事業体の異なる表記だと受け止めやすい。日常の購買ではそれで支障がないこともある。しかし、可用性、データ保全、規制対応、事業継続を契約に乗せる場面では、似ていることと法的に同一であることは別問題になる。Datacenta Hosting を調べると、その違いが例外的な細部ではなく、調査の中心に現れる。

ここで区別すべき身元は少なくとも四つある。第一は、RIPE に記録された AS196745 と DATACENTA-AS というネットワーク上の身元である。第二は、Companies House が会社番号ごとに管理する法人上の身元である。第三は、顧客がウェブサイトやサポート窓口で接する Datacenta Hosting という取引上のブランドである。第四は、利用規約、注文書、Service Specification、請求書に記載され、サービス義務を負う契約上の身元である。この四層は関連していても、同じ証拠で同時に確定するわけではない。

したがって調査の目的は、「Datacenta とは結局どの会社か」という一問に急いで答えることではない。どの記録が、どの時点の、どの役割を指しているのかを明示し、その役割間の接続を別の資料で確かめることにある。ネットワーク資源の登録者が契約者と異なること自体は、直ちに異常を意味しない。グループ運営、ブランド利用、業務委託、資産保有会社との分業など、正当な説明はいくつもあり得る。問題は、その説明と責任分担が顧客に検証可能な形で提示されるかである。

この視点に立つと、公開資料の食い違いは断罪の材料ではなく、追加確認を設計するための手掛かりになる。会社番号は法人を固定し、ASN は経路起点を固定し、契約書は義務を固定する。それぞれの固定点を無理に重ねず、間を結ぶ文書を要求することが、名称変更の多いサービス事業を評価する最も実務的な方法である。

RIPE が固定するのはネットワーク登録の範囲である

RIPE RDAP は AS196745 を active の自律システムとして示し、名称を DATACENTA-AS、登録時期を 2009 年 12 月、登録組織を ORG-DHL11-RIPE としている。[5] RIPE の組織オブジェクトでは、ORG-DHL11-RIPE の名称は Datacenta Hosting Ltd、登録番号は SC208801、国は GB、所在地は Q.20 Dorset Innovation Park とされ、最終更新日は 2026 年 5 月 13 日である。[7] これは曖昧な広告文ではない。少なくとも、当該 ASN と登録組織ラベルが RIPE の公開データ上で結び付いていることを確かめる一次的な手掛かりである。

ただし、登録オブジェクトが答える質問は限定されている。そこから分かるのは、インターネット番号資源の管理文脈で誰がどの連絡先・組織情報に結び付けられているかであり、個々の顧客サービスを誰が販売したかではない。データセンター建物の登記上の所有者、ラックやサーバーの所有者、運用要員の雇用主、電力契約の当事者、保険の被保険者、証明書の保有者、障害時の損害賠償主体も、このオブジェクトからは決まらない。

登録情報の更新日が新しいことも、内容の全項目が別資料によって検証済みだという意味ではない。レジストリ情報は重要な出発点だが、顧客のための企業監査や設備監査を代行するものではないからだ。買い手は ORG-DHL11-RIPE と SC208801 の関係を確認した後、契約書側に現れる会社番号と比較し、不一致があれば関係図、ブランド使用権、資源利用権、責任分担を示す資料を求める必要がある。

ここでの証拠の読み方は、「RIPE に載っているから会社全体が証明された」でも、「名称が違うから登録が無意味」でもない。正しい結論はその中間にある。AS196745 の登録上の連結は具体的である一方、その連結がカバーする法的・運用的な範囲は狭い。狭い証拠を狭いまま使うことが、後続の確認を正確にする。

Companies House の三つの番号は、三つの確認単位である

法人記録では、名称より会社番号の方が長期的な識別子として役に立つ。Companies House の記録によると、SC208801 は現在 active で、2000 年 7 月に設立され、SIC 63110 のデータ処理・ホスティング関連事業に分類されている。[4] 現在の表示名は Datacenta Hosting (Scotland) Ltd である。同じ記録は、2003 年 9 月から 2024 年 9 月 17 日まで DATACENTA HOSTING LIMITED という名称を使用していた履歴を示す。

これとは別に、会社番号 15255267 は 2023 年 11 月に PBL 200 LTD として設立され、2024 年 9 月 23 日に DATACENTA HOSTING LTD へ名称を変更した。[2][3] 公開された filing history には、2024 年 11 月までの期間について dormant company accounts が提出されたことも記録されている。休眠会計の提出は、その対象期間についての法定提出情報として読むべきであり、別会社が担っていた運用、ブランド、契約または資産の所在を自動的に説明するものではない。

SC208801 の旧名称が終わった 2024 年 9 月 17 日と、15255267 が Datacenta 名を採用した 9 月 23 日の間は六日である。この近さは、名称変更が相互に無関係ではない可能性を調べる理由にはなる。だが、日付の連続だけで事業譲渡を認定することはできない。公開提出書類の範囲では、顧客契約、設備、ソフトウェア、ドメイン、商標、IP アドレス、ASN の利用、従業員、認証、保険、売掛金、返金義務、将来の SLA 債務がどの法人からどの法人へ移ったかは閉じていない。

第三の番号が 03290605 である。Companies House はこの会社を active とし、2024 年 4 月まで KIMCELL LIMITED という名称であった履歴を示す。[1] X-Net の連絡先ページは、X-Net が Kimcell の新しい名称であり、Kimcell が Datacenta Hosting としても取引していたと説明し、Dorset の拠点に Datacenta のサポート連絡先を掲げている。[15] さらにマネージドサービス条項は、提供者を X-Net (Services) Ltd trading as Datacenta Hosting と表現する。[16]

この三番号を一枚の表に置くと、調達上の問いが具体化する。SC208801 は RIPE の組織オブジェクトに結び付く。15255267 は現在 Datacenta の法人名を持つ。03290605 に対応する X-Net (Services) Ltd は公開条項でサービス提供者として現れる。これらを同一視するのではなく、契約書の署名欄、請求先、入金口座、データ処理契約、保険証券、証明書、サポートのエスカレーション先がどの番号を使っているかを照合する必要がある。

名称変更は、サービス品質の低下や責任回避をそれだけで示すものではない。逆に、ブランドが連続していることも、過去の義務が当然に新名称の会社へ承継された証拠にはならない。買い手が求めるべきなのは推測ではなく、法人関係図、必要なら譲渡・更改・代理・ライセンスの根拠、そして自社契約に対する明示的な確認である。

AS196745 の可視性は強い信号だが、回線設計図ではない

ネットワーク面では、公開観測は実体のある信号を返している。2026 年 7 月 20 日 16:00 UTC の RIPEstat のスナップショットでは、AS196745 は六つの IPv4 プレフィックス、合計 1,536 アドレスと、十個の IPv6 /48 を起点としていた。[9] RIPE RIS はその時点で、IPv4 経路を 325 ピア中 323、IPv6 経路を 320 ピアすべてから観測していた。少数の観測点だけに現れる局所的な告知ではなく、広い観測面に届く経路起点であったことは、この数値から合理的に言える。

RIPE の aut-num ポリシーオブジェクトは AS5511、AS60670、AS206347 からの import を列挙し、RIPEstat の observed-neighbour データも同じ三 ASN を観測隣接として返している。[6][8] 宣言されたポリシーと観測データが同じ外部 ASN を示すことは、複数の外部隣接が記録されているという点で有用である。ネットワーク調査の初期段階では、単一の名称やマーケティング文言よりも具体的な検証材料になる。

それでも、この一致を物理的な二重化の証明に変えてはならない。BGP の隣接が三つ見えることと、三本の回線が異なる導管、引込口、電源、装置、都市、事業者障害領域を通ることは同じではない。複数の論理セッションが同じ建物入口や同じ卸回線に依存することも理論上あり得る。公開データには、回線契約、コミット帯域、バースト条件、混雑率、DDoS 防御余力、障害時の優先順位、顧客ごとの経路制御は示されていない。

また、経路が多数の RIS ピアで見えることは、顧客アプリケーションの応答時間やパケット損失を測った結果ではない。起点の可視性は到達可能性を評価する重要な部品だが、施設内のスイッチ、ファイアウォール、仮想化基盤、ストレージ、DNS、顧客 VLAN、ラストメートルの障害を含むサービス全体の可用性とは異なる。スナップショットは 2026 年 7 月 20 日の観測であり、過去の SLA 達成率や将来の性能保証でもない。

したがって、AS196745 に関する公開情報から確定できるのは、「その時点でアドレス空間を起点とし、広く観測され、三つの外部 ASN がポリシーと観測の双方に現れた」というところまでである。物理経路の分離、契約済み容量、フェイルオーバー時間、顧客トラフィックの優先制御を評価するには、回線図、キャリア注文書、ポート情報、試験記録、障害訓練の結果を別途確認しなければならない。

PeeringDB の空欄は「存在しない」ではなく「ここでは閉じない」を意味する

PeeringDB の AS196745 ページは、ネットワーク名を Datacenta Hosting、方針を open と示す一方、トラフィック量と地理的範囲を undisclosed とし、IPv4 と IPv6 のプレフィックス数をともにゼロとしている。[14] 公開 IX や施設の掲載もなく、最終更新は 2022 年 7 月である。現在の RIPEstat が実際のプレフィックス起点を観測しているため、少なくともプレフィックス数の欄は現況を表す資料として使えない。

この不一致から二つの誤った結論が生まれ得る。一つは、PeeringDB がゼロとするため AS196745 は経路を出していない、という結論である。これは RIPEstat の観測と合わない。もう一つは、IX や施設一覧が空なので、プライベート相互接続も物理拠点もない、という結論である。自己管理型プロフィールの空欄は、非公開接続や未掲載施設の不存在を立証しない。

有効な読み方はより限定的である。PeeringDB のページだけでは、2026 年時点のポート、施設、ピアリング、容量を再構成できない。この情報不足は、ネットワークの不存在ではなく、公開ディスクロージャーの鮮度と完全性に関するリスクである。調達側は、更新された接続マトリクス、各接続の役割、物理的な分離、障害領域、通常時と切替時の利用率を事業者に確認すべきである。

情報源の衝突を見つけた時、どちらか一方を機械的に採用する必要はない。RIPEstat は観測時点の経路を扱い、PeeringDB はネットワーク運営者が入力するプロフィールを扱う。目的も更新方式も異なる。衝突そのものが、「現在の運用像を得るには追加資料が必要だ」という監査上の結論を支える。

サービスページは提供可能性を語るが、購入済み義務を定義しない

Datacenta の公開ページは、Dorset を基盤とするコロケーション、マネージドホスティング、マネージドアプリケーション、環境制御、UPS、監視、24 時間 365 日のサポート能力を掲げている。[13] ネットワークページは、ブロードバンド、ポイント・ツー・ポイント接続、選択されたピアリング、AS196745 を用いる IP トランジットを提供すると説明する。[11] これらはサービスの候補範囲を知る手掛かりになるが、特定顧客の注文内容や現在の空き容量を示すものではない。

バックアップのページは、各データセンター内でのローカルなバックアップとセンター間のリモートバックアップに触れ、暗号化したデータを英国で保管し、二次サイトを提供できると説明する。[10] セキュリティページは、運営者がホスティング施設を所有し、他のホスティング事業者へフロアやラック空間を再販せず、多様な経路の回線を使うと述べる。[12] 重要なのは、これらを Datacenta 側の説明として帰属させることである。本調査の公開資料だけでは、所有権登記、回線契約、現在の構成、二次サイトの割当、証明書の対象範囲、復元成功率まで独立に確認できていない。

「提供できる」と「この顧客に提供する」は区別しなければならない。二次サイトという選択肢が存在しても、契約に含まれ、必要容量が予約され、データが期待どおり複製され、復元試験が通っているとは限らない。24 時間の能力が表示されていても、特定プランの一次応答、技術者の現地対応、エスカレーション、クレジット条件は別の問題である。多様な回線という説明も、顧客が利用する経路について共通障害点がないことを個別に証明しない。

マーケティングページを無視する必要はない。むしろ、そこで示された各能力を質問票の項目に変換すればよい。施設所有を掲げるなら、契約主体との関係と利用権を確認する。二次サイトを掲げるなら、所在地、障害領域、容量予約、複製方法、復旧手順を確認する。多様な回線を掲げるなら、キャリア、経路、引込、終端装置、切替試験を確認する。公開説明は証拠の終点ではなく、顧客固有の証拠を要求する起点になる。

Service Specification が実際の制御面になる

X-Net の公開マネージドサービス条項を読むと、サービスの重要部分が一律のウェブ説明ではなく、顧客固有の Service Specification に置かれていることが分かる。[16] 最大サーバー空間、インターネットのサービス水準、包括されるトラフィック、ファイアウォール規則、その他の性能条件は、個別仕様で定める構造になっている。つまり、同じブランドの顧客であっても、購入した保護や保証が同じとは限らない。

条項は、予定保守と緊急保守の余地を設ける。バックアップは、バックアップオプションが要求され合意されていない限り、顧客側の責任とされる。保証帯域を選択しなければ最低転送速度は設けられない。物理アクセスには事前通知が必要で、サポート時間の制約を受ける。契約終了時には、顧客が自己負担で七日以内にサーバーを撤去する義務があり、回収されない機器には保管とその後の処分に関する規定がある。[16]

これらは細則ではない。バックアップの責任主体、帯域の保証、保守による停止、機器へのアクセス、退出費用は、障害時の事業継続性と総コストを左右する。サービスページに「バックアップ」「24/7」「多様な回線」と書かれていても、自社の Service Specification にその選択肢、数値、責任、救済が入っていなければ、契約上の保護としては閉じない。

調達時には、提案書、注文書、Service Specification、一般条項、データ処理条件、SLA の優先順位も確認すべきである。文書間で用語や会社名が異なる場合、どの文書が優先するのか、誰が変更を承認できるのか、ブランド変更や再編時に契約をどう引き継ぐのかを明確にする。口頭説明や営業メールに重要な約束が残るなら、署名前に仕様へ取り込む必要がある。

Datacenta のケースで契約が制御面になる理由は、公開情報が弱いからだけではない。公開経路はインターネット上の現象を、法人登記は法的な識別を、サービスページは提供メニューを、それぞれ異なる粒度で示す。顧客が実際に受け取るサービスを一つの義務として束ねられる場所が、署名された個別仕様だからである。

公開信号と必要証拠を対応させる

調査を効率化するには、見つかった情報を単純な「確認済み」「未確認」に分けるより、各信号が答えられる問いと答えられない問いを並べる方がよい。次の表は、今回の証拠から導ける確認設計である。

検証領域	公開資料が示す信号	公開資料だけでは閉じない点	顧客側が求める証拠
法人とブランド	三つの会社番号、名称履歴、X-Net のブランド説明	資産・顧客・債務・契約の移転、請求主体	署名法人、会社番号、関係図、更改・譲渡・ブランド使用の根拠
ネットワーク資源	AS196745、DATACENTA-AS、ORG-DHL11-RIPE の登録上の関連	顧客サービスへの利用権、設備所有、SLA 責任	ASN・アドレス利用権、契約主体との関係、責任分担
経路と外部接続	広い経路観測、三つの記録・観測隣接	物理多様性、容量、混雑、DDoS 余力、切替性能	論理・物理構成図、回線注文、利用率、フェイルオーバー試験
施設	Dorset に関する所在地・サービス説明	正確な本番・予備サイト、所有権、共通障害点、空き容量	サイト一覧、利用権、電源・冷却構成、容量予約、試験記録
バックアップ	ローカル・遠隔・英国保管・二次サイトという提供者説明	自社が購入した構成、世代、改ざん耐性、復元成功	コピー構成、保持、暗号化、immutability、復元試験、RPO・RTO
サービス運用	監視、サポート、保守に関する公開説明と一般条項	自社プランの応答、対応範囲、除外、救済	当番体制、エスカレーション、保守通知、測定方法、SLA クレジット
退出	七日以内の機器撤去と未回収時の扱い	データ・VM・DNS・IP 依存の移行時間と費用	退出計画、エクスポート形式、支援料金、消去証明、機器回収手順

この対応表の利点は、公開資料に過大な役割を負わせないことにある。例えば、RIPEstat の可視性はネットワークの存在を確認する強い信号だが、バックアップの復元試験には何も答えない。Companies House の会社番号は署名者を識別する助けになるが、回線の多様性を示さない。証拠を用途ごとに分ければ、「公式情報だから全部を証明する」という誤りを避けられる。

同時に、未確認という言葉を漠然と使わずに済む。物理回線が未確認なら、必要なのは一般的な安心説明ではなく、ルート、引込、キャリア、装置、試験日の資料である。バックアップが未確認なら、必要なのは「バックアップ可能」というページの再提示ではなく、顧客名またはサービス識別子に結び付いたコピー構成と復元結果である。問いを証拠の形式まで具体化するほど、営業説明と契約義務のずれを早く見つけられる。

契約前にたどる七段階の検証チェーン

第一段階は、法人と署名の固定である。提案書、Service Specification、一般条項、データ処理契約、請求書見本、入金先の会社名と番号を並べる。X-Net (Services) Ltd、Datacenta Hosting Ltd、Datacenta Hosting (Scotland) Ltd、DATACENTA HOSTING LTD を表記の揺れとして消してはいけない。各名称がブランド、登録組織、資産保有、契約、請求のどの役割を担うのかを書面で確認する。

第二段階は、権利の連鎖である。契約主体が自ら所有しない設備、施設、ネットワーク資源、ソフトウェアまたは証明書をサービスに用いるなら、それを利用し顧客へ提供する権利がどの契約で確保されているかを確かめる。ここで必要なのは企業グループの一般的な説明だけではない。契約期間中に権利が失われた場合の代替、通知、責任も含む、サービス固有の連結である。

第三段階は、ネットワーク設計の確認である。AS196745 が起点となるプレフィックス、顧客に提供されるアドレス、上流との接続、経路制御、DDoS 対応、DNS 依存を構成図に落とす。AS5511、AS60670、AS206347 が公開データに現れることは質問の出発点になるが、契約関係や物理経路を決め付けない。通常運転時と一経路喪失時の双方について、期待経路、収束、容量余裕、監視方法を確認する。

第四段階は、施設と容量の確認である。本番とバックアップがどのサイト、室、電力系統、冷却系統、ネットワーク引込に依存するかを特定する。予約されたラック、電力、計算、メモリー、ストレージ、ポート容量があるのか、共有リソースなら競合時にどう配分されるのかを問う。施設や回線の説明は、最新の試験日、試験範囲、例外、是正状況と組み合わせて評価する。

第五段階は、データ保護の確認である。バックアップが契約オプションなら、選択済みであることを Service Specification 上で確認する。何個のコピーが、どの障害領域に、どの頻度で、どの期間保存されるかを図示し、暗号鍵の管理、削除・改ざんへの耐性、監視失敗時の通知を確かめる。RPO と RTO は宣伝上の目標ではなく、対象システム、測定起点、除外条件、復元試験の結果に結び付ける。

第六段階は、運用と救済の確認である。監視範囲、一次応答、技術者のエスカレーション、現地作業、顧客への通知、予定・緊急保守、サービス水準の測定方法を確認する。保証帯域を購入しない場合に最低転送速度がないという一般条項の構造は、価格比較にも影響する。帯域値だけでなく、コミット、バースト、超過料金、混雑時の扱い、測定点、違反時のクレジットを同じ表で比べるべきである。

第七段階は、退出を稼働前に設計することである。サーバー撤去の七日という条件を、社内承認、運送、データ消去、停止可能時間と照合する。仮想マシン、データベース、オブジェクト、設定、ログ、暗号鍵、DNS、ドメイン、IP 許可リスト、監視履歴をどの形式で取り出せるかを決める。物理機器の梱包・搬出、未回収時の保管費と処分、移行支援の単価、契約終了後のアクセス期間も事前に合意しておく。

この七段階は、一度だけのチェックリストではない。会社名、請求主体、回線、施設、バックアップ構成、下請先、証明書が変われば、証拠連鎖の一部が切れる可能性がある。年次レビューに加え、法人変更、重大障害、サービス変更、更新交渉を再検証のトリガーとして契約に組み込む方がよい。

五つの仮想シナリオで、説明と義務の隙間を試す

第一のシナリオは、AS196745 の経路が外部から見えているのに、顧客サービスは利用できない場合である。施設内ネットワーク、ファイアウォール、ストレージ、仮想化基盤、認証、DNS のどこかに障害があれば、BGP 起点が維持されてもアプリケーションは停止し得る。これは Datacenta で実際に障害が起きたという主張ではない。経路可視性をサービス可用性の代替指標にしないためのテストである。

第二は、法人名が変わっても古い名称の契約が残る場合である。顧客は、名称変更だけなのか、契約当事者の更改が必要なのか、請求先やデータ処理者が変わったのかを判断しなければならない。六日間に近接した名称変更は質問を生むが、答えではない。会社番号、通知文、署名、譲渡・更改文書によって個別に閉じる必要がある。

第三は、ウェブサイトにバックアップが掲載されているが、自社の Service Specification ではオプションが選択されていない場合である。一般条項上、合意されたバックアップがなければ責任が顧客側に残り得る。調達担当者は、製品カタログの機能を契約済み機能と誤認せず、ジョブの対象、保存先、保持期間、失敗通知、復元試験まで確認する必要がある。

第四は、複数の外部 ASN が見えているが、同じ物理障害で同時に影響を受ける場合である。公開データだけでは、そのような共通障害点があるともないとも言えない。だからこそ、事業者名の数ではなく、管路、引込、終端、電源、装置、経路試験の分離を確認する。論理的な多様性と物理的な多様性を別々の受入条件にする。

第五は、終了通知後にデータ移行は終わったが、物理サーバーの回収が七日以内にできない場合である。保管費や処分の可能性があるなら、退出作業は契約終了後に考える事務処理ではない。代替環境の準備、データ同期、DNS 切替、機器の停止・梱包・運送を逆算し、必要なら個別仕様で期間や支援を調整するべきである。

これらのシナリオは、公開資料にない事故や顧客結果を推測するためではない。契約がどの条件で機能し、どこに未定義の責任が残るかを署名前に可視化するためである。良いデューデリジェンスは、事業者に「安全ですか」と尋ねるのではなく、失敗状態を一つずつ提示し、検知、対応、復旧、費用、責任、証拠を答えられる形にする。

ホスティングの価格は、保証されない部分まで含めて比較する

ホスティングの経済性は、月額料金や公称帯域だけでは読めない。保証帯域を選ばない場合に最低転送速度がないなら、安価なプランと保証付きプランは同じ商品ではない。バックアップが別途の合意を要するなら、ストレージ料金だけでなく、コピー、保持、復元試験、運用要員、目標未達時の救済を含めて比較する必要がある。物理アクセスの通知条件やサポート時間も、緊急作業の社内コストに影響する。

退出条件も総保有コストの一部である。七日以内の撤去、未回収機器の保管と処分、データや仮想マシンのエクスポート支援、IP 依存の変更には、時間と費用がかかる可能性がある。契約時に単価と手順が定まっていなければ、切替の最も時間制約が厳しい局面で交渉することになる。安い通常運転と高い退出費用を別々に評価すると、比較を誤る。

同じことはレジリエンスにも当てはまる。二次サイト、複数回線、24 時間サポートという語は、すべて同じ水準の商品を意味しない。専用か共有か、容量は予約済みか、どの障害を想定するか、誰が切替を開始するか、何分で復旧するか、失敗時にどの救済があるかによって経済価値は変わる。Service Specification は技術仕様であると同時に、価格とリスクの配分表である。

買い手は、基本料金、オプション、超過、作業、保守、復旧、退出を一つのコストモデルに置き、未保証の項目には自社側の代替費用を加えるべきである。例えば、事業者バックアップを購入しないなら、自社のバックアップ基盤、監視、試験、人員が必要になる。保証帯域を購入しないなら、性能変動を吸収する設計や別回線の費用を考える。契約で移転しなかったリスクは消えず、顧客の費用として残る。

証拠には鮮度、所有者、用途を記録する

今回の資料は、同じ表に並べても性質が異なる。Companies House は会社番号と提出履歴を示す公的レジストリである。RIPE のデータベースは番号資源に関する登録とポリシーを示す。RIPEstat は特定時点の観測を返す。PeeringDB はネットワーク運営者が維持する自己申告プロフィールである。Datacenta と X-Net のページは提供者自身のサービス説明と契約条項である。どれか一種類だけを「公式」と呼んで、他の問いまで代用させることはできない。

監査台帳には、各証拠の URL だけでなく、取得日、対象時点、情報の所有者、確認した主張、確認できない主張を残すとよい。RIPEstat の数値には観測時刻を付ける。PeeringDB の記載には最終更新時期を付ける。法人名には会社番号と名称履歴を付ける。サービス説明には提供者による主張であることを付け、契約条件には適用対象と文書の優先順位を付ける。

更新頻度も一律にはできない。経路と隣接は変動し得るため、契約前、稼働前、重大変更後に再確認する価値がある。法人名、登記状態、契約主体は更新・更改時に照合する。証明書、保険、試験記録には有効期限を持たせる。バックアップとフェイルオーバーは文書の存在ではなく、定期的な試験結果で追跡する。証拠が古くなった時に自動的に再要求される仕組みが、調査を一度きりの資料収集から運用管理へ変える。

矛盾を解消した記録も重要である。例えば、PeeringDB のゼロプレフィックスと RIPEstat の観測が異なる場合、「どちらが正しいか」だけで終えず、PeeringDB は現行容量表として採用しない、経路は観測データで確認する、施設と接続は事業者資料で別途閉じる、と判断根拠を残す。後任者が同じ衝突を再発見しても、推論の範囲を再現できる。

証拠資料室はブランド名ではなく、責任の種類で組み立てる

実査の資料室を Datacenta Hosting という一つのフォルダーだけで組むと、異なる法人や役割の資料が混ざりやすい。より安全なのは、法人・契約、ネットワーク資源、施設・設備、運用、データ保護、セキュリティ、財務・保険、退出という責任単位で棚を分け、すべての文書に対象会社番号、対象サービス、対象サイト、対象期間を付ける方法である。同じロゴが付いていても、対象法人が記載されていなければ未分類のまま扱う。

法人・契約の棚には、最新の登記情報だけでなく、提案から請求までの連鎖を置く。提案者、署名者、請求者、入金口座名義、データ処理者、保険の被保険者、苦情・訴訟時の通知先を一行ずつ並べ、会社番号で照合する。名称が Datacenta Hosting Ltd で一致しているように見えても、SC208801、15255267、03290605 のどれを指すかがなければ、重要な義務の帰属は確定しない。略称や取引名を許容する場合も、正式法人への対応表を契約付属書に残すべきである。

ネットワーク資源の棚では、AS196745、プレフィックス、登録組織、連絡窓口を、顧客が実際に使うサービス識別子と結び付ける。公開登録の写しだけでなく、誰が経路変更を承認し、誰が障害連絡を受け、契約終了時に顧客の許可リストや DNS 依存をどう変更するかを記録する。資源の登録者と契約主体が異なるなら、その差を説明する権限・責任文書を置き、変更通知の期限も決める。

施設・設備の棚では、営業資料、構成図、資産一覧、利用権、保守契約、試験記録を分ける。提供者が施設所有を説明していても、それだけで自社サービスに使う部屋、電源、冷却、回線、ラックの権利と責任は確定しない。どの資料が所有を、どの資料が利用可能性を、どの資料が顧客への割当を示すのかを明記する。機密上、原本を開示できない場合は、独立保証、抜粋、閲覧記録など、主張を検証できる代替証拠の範囲を合意する。

運用とデータ保護の棚には、方針書だけでなく実績資料を置く。監視項目、アラート、当番表、演習計画、復元結果、是正措置、未解決例外を、契約上の目標と対応させる。証拠には所有者と有効期限を設定し、期限が来たら新しい文書を要求する。資料が存在することを完了条件にせず、対象、日付、承認者、結果が今回のサービスと一致することを受入条件にする。

資料室の索引には、各主張を「確認済み」「条件付き」「未解決」に分ける。確認済みは、対象と時点が一致する証拠がある状態である。条件付きは、契約への追記、稼働前試験、第三者確認などの完了を前提とする状態である。未解決は、説明がなく矛盾が残るか、証拠が対象外・期限切れである状態を指す。この区分によって、営業上の回答が出たことと、監査上の問いが閉じたことを混同しにくくなる。

技術的な受入試験を、契約語と同じ粒度で設計する

ネットワークの受入試験では、単に外部から疎通できることを確認するだけでは足りない。平常時の経路、遅延、損失、利用率を基準値として残し、契約で想定する障害条件ごとに経路がどう変わるかを確認する。どの監視点から、どのプレフィックスとサービスを、どの時間幅で測るかを先に定義することで、AS196745 の広い可視性と、自社ワークロードの性能を別々に評価できる。

フェイルオーバー試験では、論理的な隣接の切替だけでなく、物理回線、終端装置、電源、ルーター、ファイアウォールの障害をどこまで対象にするかを決める。実環境で遮断できない箇所は、過去の試験結果、構成レビュー、机上演習などで補うことになる。その場合も、実試験と代替保証を同じ強さで扱わず、未試験の障害領域を残余リスクとして記録する。

性能条件は、帯域の数字を一つ書くだけでは不十分である。保証値か最大値か、上りと下り、測定点、集計間隔、バースト、パケット損失、遅延、混雑時の優先、保守時の扱いを Service Specification と試験手順で揃える。最低転送速度を必要とするなら、保証帯域を選択し、その値をどの監視データで判定するかまで合意する。判定不能な SLA は、数字が厳しくても救済に結び付かない。

施設の受入では、公開ページに並ぶ環境制御や UPS という機能名を、試験対象へ変換する。電源系統の切替、冷却喪失、温度・湿度アラート、設備故障時の連絡、現地作業の権限を、顧客サービスに影響する経路に沿って確認する。ここで本調査は Datacenta の設備性能を断定しない。必要なのは、現在の構成と試験記録を提供者から取得し、自社の許容停止時間と照合することである。

監視の受入では、事業者が見る状態と顧客が見る状態の差を確認する。ネットワーク装置が正常でもアプリケーションが応答しない場合を誰が検知するのか、バックアップジョブが成功しても復元不能な場合をどう見つけるのか、営業時間外に誰が判断を下すのかを決める。アラートの重大度、一次応答、更新頻度、解決宣言、事後報告の期限を、エスカレーション表に結び付ける。

受入試験の結果は、合格・不合格だけでなく、前提、除外、観測値、逸脱、是正期限を残す。条件付き合格なら、未完了項目が本番開始前に必要か、開始後の期限付き改善でよいかをリスク所有者が承認する。試験で見つかった弱点を営業上の説明で上書きせず、Service Specification、運用手順、価格または代替策のいずれかへ反映することが重要である。

バックアップと退出は、一つの可搬性試験として扱う

バックアップについて最も起こりやすい誤認は、コピーが作成されたことを復旧可能性と同じだと考えることである。必要なのは、対象データが選ばれ、ジョブが完了し、コピーが元障害から分離され、必要な認証情報と鍵が利用でき、整合性を保った状態で復元できるという連鎖である。各段階に責任者、監視、失敗通知、再実行手順がなければ、コピー数だけを増やしても復旧の確実性は上がらない。

ローカルとリモートのコピーを使う場合は、地理的な呼称より障害領域を見る。二つのコピーが同じ管理資格情報、同じ削除権限、同じネットワーク、同じ運用チームに依存するなら、場所が違っても共通の失敗が残る。逆に、距離だけで良否は決まらない。業務が必要とする RPO、RTO、法的な保管条件、転送時間を満たすように、コピーの位置、隔離、暗号化、immutability、保持を組み合わせる。

復元試験では、少量のファイルだけでなく、業務が再開する単位を選ぶ。仮想マシン、データベース、設定、依存サービス、DNS、秘密情報を含め、どこまでを事業者が、どこからを顧客が担当するかを明示する。開始時刻と完了時刻、復元時点、欠損、手作業、エラー、再試行を記録し、RPO と RTO の判定根拠を残す。成功した一回の試験も永続的な保証ではないため、構成変更後と定期周期で再実施する。

この復元手順を別環境への移行まで延ばすと、退出可能性を同時に試せる。標準形式でデータを取得できるか、仮想マシンや設定を別基盤へ持ち出せるか、固定 IP や許可リストを変更できるか、DNS の権限を顧客が保持しているかを確認する。移行に事業者作業が必要なら、申請期限、作業時間、料金、優先度を事前に定める。退出試験は契約関係への不信ではなく、障害復旧と事業継続の実装確認である。

物理サーバーについては、データ移行と機器撤去を別工程にする。停止承認、最終同期、データ消去、梱包、搬出許可、運送、受領確認を七日という一般条項の期間に収められるかを計画する。期間が現実的でなければ、署名前に個別条件を交渉する。未回収時の保管や処分に進む条件、通知方法、費用、所有権の扱いも曖昧に残さない。

バックアップと退出を同じ可搬性の問題として扱えば、平常時には見えにくいロックインを把握できる。データは存在していても、独自形式、帯域制約、権限不足、作業待ち、短い撤去期限によって移動できないことがあり得る。今回の公開資料は実際の顧客がその状態にあるとは示していない。だからこそ、顧客固有の試験結果と契約条件によって、可能性を事実へ変える必要がある。

意思決定では、重要な未解決点を平均点に埋めない

最終評価を一つの点数にまとめる場合でも、法人主体、データ復旧、物理的な単一障害点、退出権のような重要項目を平均点で相殺してはならない。公開経路が強く観測され、サービス説明が充実していても、署名主体が不明なままなら契約執行の問題は残る。逆に、法人関係が明確でも、復元試験がなければデータ保全の問題は残る。異なる種類の証拠は、互いの代替にならない。

実務上は、必須条件、稼働前条件、期限付き改善、受容する残余リスクの四つに分けると判断しやすい。必須条件は満たされるまで署名しない。稼働前条件は契約できても本番データを置く前に閉じる。期限付き改善には所有者、期日、未達時の措置を付ける。残余リスクは、技術担当だけでなく、その影響を負う事業責任者が明示的に受容する。

Datacenta を評価する際の必須条件は、特定の法人を疑うことではなく、役割を文書で確定できることである。契約・請求・SLA の主体、AS196745 の登録者との関係、設備とサービスを提供する権利、選択したバックアップと帯域、保守・アクセス・退出の条件を一つの契約束で追跡できなければならない。説明が合理的でも、証拠が別の会社、別の期間、別のサービスを対象にしていれば条件は未完了である。

また、未解決点には情報不足と許容不能を区別する。PeeringDB の古い空欄は追加情報を必要とするが、それだけでネットワーク不在を意味しない。近接した名称変更は法人関係の説明を必要とするが、それだけで不正や責任回避を意味しない。証拠がそろった後に設計や条件が自社要件を満たさないなら、それが否定的判断の根拠になる。先に結論を置かず、問い、証拠、基準、判断の順序を守ることが重要である。

良い回答は、各名称を消すのではなく責任線を引く

Datacenta Hosting Ltd に関する公開情報は、何も分からない状態ではない。AS196745 は DATACENTA-AS として登録され、2026 年 7 月の観測では IPv4 と IPv6 の経路を広く到達させていた。ORG-DHL11-RIPE は Datacenta Hosting Ltd と SC208801 に結び付く。Companies House は SC208801、15255267、03290605 の名称と履歴を分けて示す。X-Net のページと条項は、Datacenta Hosting という取引名と X-Net (Services) Ltd の契約上の位置を説明する。

同時に、公開証拠には明確な限界がある。登録ラベルは施設所有や請求主体を決めず、BGP の可視性は回線の物理多様性や SLA 達成を決めず、PeeringDB の空欄は施設や私設接続の不存在を決めない。提供者ページの能力説明は、顧客に割り当てられた容量、復旧成功、証明範囲を独立に証明しない。近接した法人名変更も、資産・契約・債務の移転を単独では証明しない。

このため、調達の最終成果物は単一の会社紹介ではなく、責任線を引いた証拠地図であるべきだ。左側にネットワーク資源、法人、ブランド、施設、運用、データを置き、右側に登録者、所有者、利用権者、契約者、請求者、サポート担当、SLA 責任者を置く。その間を会社番号、契約条項、Service Specification、権利文書、構成図、試験結果で結ぶ。接続できない線は、署名前の条件または残余リスクとして明示する。

見えている経路は、調査を始めるには十分に具体的である。しかし、購入するサービスを定義するには十分ではない。Datacenta の事例が示すのは、インターネット上の可視性と契約上の確実性の間に、法人、権利、設備、運用、退出という複数の検証段階があることだ。その段階を飛ばさず、顧客固有の Service Specification に証拠と責任を固定できた時に初めて、ブランド名の連続性は実行可能なサービス義務へ変わる。