要約

  • AS209045にはRIPEの登録資源、経路オブジェクト、RPKIの認可情報、PeeringDB上の10G接続が残る一方、RIPE RISの2026年7月20日時点の観測ではIPv4、IPv6とも可視性がゼロで、現在の広報経路も確認されなかった。これは重要な経路上の警告だが、Genesis Cloud全体の停止を示すものではない。
  • PeeringDBの「Operational」は運用者が記載する設定情報であり、DE-CIXのルートサーバー側で確認されたダウンまたはパッシブのセッション、経路数ゼロという時点観測と両立する。施設名、ポート容量、方針記録から設備所有、実トラフィック、代替GPU在庫まで推定してはならない。
  • 購入判断で必要なのは、公開記録の見栄えではなく、アカウントごとの割当量、同型インスタンスの再確保、スナップショット複製、ボリューム復元、通信規則の再現、オブジェクト保存先の名前解決、API経路、外部経路、交換点セッションを日付付きで実証することである。

「矛盾」ではなく証拠の層を読む

Genesis Cloudをめぐる公開情報には、第一印象では食い違って見える組み合わせがある。PeeringDBにはDE-CIX FrankfurtとDE-CIX Kristiansandの10G接続が運用中として記録されている。それに対し、RIPE RISの収集結果ではAS209045から見えるIPv4とIPv6の広報経路がなく、DE-CIXのルートサーバー観測でも対象セッションはダウンまたはパッシブだった。この差だけを見て、どちらかが誤っていると決めるのは早い。

各記録が答えている問いが違うからだ。番号資源の登録は、誰にどの資源が関連付けられているかを示す。IRRの経路オブジェクトやaut-numの記述は、経路を広報する権限や受け入れ方針を表す。RPKIのVRPは、特定の起点ASによる経路広報を検証するための認可文脈を与える。PeeringDBは運用者が交換点接続や施設を記載する場所であり、交換点のルートサーバーは特定時点のBGPセッションを観測する。RISは複数の収集点から見えた世界規模の経路可視性を集約する。

さらに、DNSの応答は名前がどこへ解決されたかを示すが、そこで動くサービスの全構成や正常性までは示さない。開発者向け文書は、利用可能な操作や引数を説明するが、特定顧客の復旧が完了した事実にはならない。したがって、登録、認可、設定、観測、名前解決、サービス操作を一列に並べて「稼働している」か「停止している」かの二択に圧縮すると、証拠が持つ本来の範囲を失う。

購入者に必要なのは、記録同士を平均して安心度を作ることではない。どの記録がどの問いに答え、何を答えられないのかを明示し、不足する部分を自社の試験で埋めることである。本稿で最も重く見るのは、時刻が明示された経路観測とDNS応答である。ただし、その重みはAS209045と確認対象ホストについてのものであり、Genesis Cloudの全サービス、全契約、全顧客環境へ自動的に広げられるものではない。

同じ名称の下に異なる主体を重ねない

Overviewに記したGenesis Cloud Routing, Peering and DNSは、独立した会社名ではない。RIPEデータベースのGCRP3-RIPEという技術連絡用のroleであり、2019年4月29日に作成され、2024年7月25日に更新され、ミュンヘンの住所が記録されている。このroleは連絡先をまとめるための識別子として読むべきであり、ホステッド容量を販売する主体、施設を所有する主体、顧客契約を締結する主体として扱うことはできない。

AS209045は別の単位である。RIPEではGENESIS-CLOUD-ASとして登録され、RDAPとRIPEの記録はORG-GCL19-RIPEに関連付けている。ORG-GCL19-RIPEはGenesis Cloud Limitedで、国はマルタ、登録番号はC 88032、組織種別はLIRとされる。RIPEのマルタ会員一覧にもGenesis Cloud Limitedが載っている。しかし、LIRであることは番号資源の管理上の関係を示すにとどまり、サーバーの所有、データセンターの統制、現在のトラフィック、顧客との契約名義を証明しない。

Genesis Cloud GmbHも区別が必要だ。GLEIFのLEI記録にはドイツの法人名があり、登録状態はLAPSED、最終更新は2026年6月26日、2025年9月2日を記録日とする清算進行中の事象が示されている。これは当該ドイツ法人について無視できない法的手掛かりである一方、Genesis Cloud Limited、Genesis Cloud Norway AS、AS209045、あるいはすべての顧客サービスが清算中だと証明する記録ではない。

Bulk Infrastructureは施設と接続性を説明する別会社であり、DE-CIXは相互接続の場とルートサーバー観測を提供する別組織である。Google Cloudは確認されたAPI用IPアドレスのASに関係し、Cloudflareはgenesiscloud.comのネームサーバーとドメイン登録情報に現れる。これらの名称をすべて「Genesis Cloudの内部」とひとまとめにすれば、契約上の責任、設備の支配、技術上の依存関係を取り違える。評価の第一歩は、名前が似ているかではなく、各記録が指す法的・技術的単位を固定することだ。

この区別は言葉遣いの問題に見えて、実務上は大きい。障害時に誰が説明責任を負うのか、誰が経路を変更できるのか、誰が交換点ポートを契約しているのか、誰が施設内の電力や光回線を管理するのかは、それぞれ異なり得る。公開記録だけでその責任分担を完成させることはできないため、購入者は契約書、サポート窓口、技術担当、施設運営者の関係を自分の契約単位で確認しなければならない。

登録資源は稼働中の経路ではない

RIPEの逆引き資源検索では、ORG-GCL19-RIPEに147.189.192.0から147.189.207.255、194.61.20.0から194.61.23.255、IPv6の2a09:7000::/29、そしてAS209045が関連付けられている。これは番号資源の登録関係として具体的であり、Genesis Cloud LimitedとAS209045を評価する基礎資料になる。しかし、アドレス範囲が登録されていることと、その範囲が現在インターネットへ広報され、顧客のパケットを運んでいることは別である。

AS209045を起点とするRIPEのrouteまたはroute6オブジェクトは六つ確認されている。対象には147.189.200.0/22、147.189.207.0/24、2a09:7000::/29、2a09:7000::/31、2a09:7007::/36、2a09:7000:1000:200::/56が含まれる。最後の/56には「Test for traffic redirection」という備考がある。これらは経路方針や広報権限を記述する記録であって、その経路が現在BGPで見えること、短い経路で安定して届くこと、実際のサービス通信を運ぶことの証明ではない。

aut-numの記録には、AS13237、AS50304、AS60259、AS44735、AS200781、AS212175からANYを受け入れるという宣言があり、多数のルートサーバーまたはピアとの受入・送出方針も書かれている。ここから読み取れるのは、登録された方針上の関係である。現在もそれらのASと商用トランジット契約が有効である、全セッションが確立している、実トラフィックがその経路を通っている、といった観測事実へ格上げしてはならない。

RPKIについては、2026年7月18日に得られた最新行で、AS209045にIPv4のVRPが二つ、IPv6のVRPが三つある。これは起点認可を検証する材料が存在することを示す。だがVRPがあっても、対応するプレフィックスが広報されていなければ、到達可能な経路は生まれない。RPKIは不正な起点を見分けるための重要な仕組みだが、可用性監視でも、経路広報の開始指示でもない。

したがって、登録資源、routeオブジェクト、aut-num方針、VRPを合計して「ネットワークが動いている」と評価するのは誤りである。一方、現在の可視性がゼロだからといって、それらの登録が無意味になったわけでもない。登録と認可は、再広報や構成変更の際に必要となる土台であり得る。購入者が知りたいのは、その土台の上で実際に何が、いつ、どの観測点から見えたかである。

RIPE RISが示す現在地と過去の変化

最も明確な現在値は、RIPEstatのrouting-statusがquery_time 2026-07-20T00:00:00に返した観測である。AS209045のIPv4可視性はRISピア323のうちゼロ、IPv6可視性は318のうちゼロだった。広報空間として数えられたIPv4プレフィックスもIPv6プレフィックスもゼロで、観測された近隣ASもゼロである。2026年7月6日から7月20日までを対象にした現在のannounced-prefixesも空だった。

これは弱い手掛かりではない。多数のRIS収集ピアからAS209045起点の経路が見えなかったという、時刻付きの数値観測である。少なくとも、登録済みプレフィックスがAS209045から世界規模に通常広報されていると想定して、調達判断を進めることはできない。経路の存在を前提にするなら、別の観測点や顧客側の実測で現在値を取り直す必要がある。

ただし、RISが観測するのはBGPの可視性である。ウェブサイトが開くか、APIへ接続できるか、アカウント画面が動くか、既存の顧客仮想マシンが別のASや私設経路を通じて稼働しているかを直接測ってはいない。ゼロという数字を「Genesis Cloudが全面停止している」に置き換えれば、証拠の射程を越える。ここで言えるのは、AS209045の公開経路について、指定時刻のRIS観測に可視性がなかったことまでだ。

過去を見ると、観測像が変化したことも分かる。2025年11月1日から12月3日の履歴では、2a09:7000::/31が11月3日16時から12月2日0時まで、147.189.200.0/22が11月3日16時から12月2日8時まで可視だった。2025年12月1日のASN-neighboursには左側の近隣としてAS50304が一つ記録されている。これに対し、2026年7月20日のobserved_neighboursはゼロである。

この時系列は、以前見えていた経路と近隣が、現在の観測では見えなくなったという変化を支える。しかし、なぜ広報が止まったのかは示さない。計画的な移行、契約変更、構成変更、休止、障害など原因の候補を公的観測だけで選ぶことはできない。過去の可視性を現在へ延長することも、現在の不在を原因説明へ変換することも避けるべきだ。

BGP.toolsはAS209045を見るための補助的な入口にはなるが、本稿の主要な数値は時刻と母数が明確なRIPEstatに基づく。異なる収集網、異なる更新時刻、異なる集計方法の画面を混ぜて、永続的な経路在庫のように扱うべきではない。購入者が再確認する際も、観測時刻、収集点、アドレスファミリー、対象プレフィックスを一組として保存する必要がある。

10Gの「運用中」と停止したセッションは両立する

PeeringDBはAS209045のGenesis Cloudについて、種別をEnterprise、範囲をEuropeとして記録している。交換点LANの項目には、DE-CIX FrankfurtとDE-CIX Kristiansandにそれぞれ10Gの接続があり、route serverとBFDが有効で、状態がOperationalとされている。この情報は、どの交換点でどの容量の接続を構成する意図が記載されているかを知るうえで有用だ。

しかしPeeringDBは、基本的に運用者が自ら接続情報を保守する台帳である。Operationalという表示は、独立したパケット測定、広報プレフィックス数、GPUサービスの稼働率、顧客からの到達性を意味しない。物理ポートが存在してもBGPセッションが停止していることはあり、BGPセッションが立っていても受信経路がゼロであることはある。10Gという容量は上限側の接続仕様であって、実際に10Gbpsの通信が流れているという利用量の測定でもない。

DE-CIXのlooking glassで2026年7月20日に確認された対象エントリーは、別の層を映す。FrankfurtのIPv4とIPv6は、2025年10月22日にhold timerの満了後にダウンした状態を示していた。KristiansandのIPv4とIPv6はダウンまたはパッシブで、状態変化日は2026年6月24日、確認された経路数はゼロだった。これは交換点のルートサーバーから見た、特定セッションの時点観測である。

両者を並べると、PeeringDBの登録を削除すべきだとも、looking glassがGenesis Cloudのあらゆる接続を網羅するとも言えない。記載上は運用中の10G接続がありながら、確認対象のルートサーバーセッションは経路を交換していない、という二つの事実が同時に成立する。二者間の直接ピアリング、別のトランジット、顧客専用接続、私設ネットワークの状態は、この観測だけでは分からない。

購入者が確認すべきなのは「10Gポートはありますか」という一問では足りない。どの施設のどのポートか、物理リンクは上がっているか、IPv4とIPv6のBGP状態はどうか、受信・送信プレフィックスはいくつか、最後に状態が変わった時刻はいつか、経路を失ったときの代替は何かを分けて尋ねる必要がある。交換点名と容量値は質問の出発点であり、到達性の結論ではない。

施設名から設備所有を推定しない

PeeringDBには、ミュンヘンのEMC Home of Data MUC I/II - MuCon-Xと、ノルウェーのØvrebøにあるBulk Norway Data Center Campus - N01も施設として記録されている。Bulk Infrastructureの公開資料はN01キャンパスとデータセンター接続性を説明し、DE-CIXはKristiansandの交換面を案内している。これらを組み合わせると、Genesis Cloudが欧州内の施設と相互接続を利用する構成を検討する材料にはなる。

それでも、施設に存在するという記録と施設を所有することは同じではない。確認資料のどれも、Genesis Cloudがキャンパス、受電設備、発電機、冷却設備、長距離光ファイバー、構内接続室、交換点そのものを所有しているとは証明していない。コロケーション利用者、接続利用者、設備所有者、交換点運営者は、それぞれ別の役割を持ち得る。

この境界は、障害領域を考えるときに重要になる。電力障害への備えを尋ねる相手、光回線の多重化を証明する相手、ラック内機器を交換する相手、交換点セッションを操作する相手が同じとは限らない。施設名が有名であることや、サイトが再生可能エネルギー、接続性、拡張性を説明していることを、個別のGenesis Cloud構成が同じ性質を備える証拠として使うことはできない。

購入者は、リージョン名やキャンパス名だけではなく、責任境界を図にして確認すべきだ。ラックと機器の所有者、電源系統の分離、上流回線の事業者、構内経路の物理分離、交換点までの接続、遠隔操作と現地保守の担当を区別する。そのうえで、単一の施設事象が計算資源、保存データ、管理API、DNS、対外経路へ同時に及ぼす影響を問う必要がある。

公的資料から得られる施設情報の証拠強度は中程度だが、購入者固有の物理構成については弱い。施設が実在し、接続サービスが説明されていることと、自社が割り当てられるラック、電力、ファイバー、予備機器の配置は別問題である。契約対象の構成表、施設証明、試験記録がなければ、立地名から耐障害性を補完してはならない。

相互接続の狙いと実測結果の距離

DE-CIXとGenesis Cloudの公開資料は、10GのGlobePEER Remote、BulkのKristiansandを経由する橋渡し、AIやHPCの通信をトランジット中心からピアリングへ移す狙いを説明している。遠隔の交換点へ接続し、多数のネットワークとの経路を短くするという設計思想は理解しやすい。大量の学習データや分散処理の通信では、遅延、経路長、転送費用、混雑の回避が経済性に影響するためだ。

ただし、これはDE-CIXまたは関係者による事例紹介として読む必要がある。性能向上、負荷軽減、費用効果に関する説明は、購入者が独立して測定した結果ではない。いつ、どのトラフィックで、どの比較対象に対して、どれだけ改善したのかという測定条件がなければ、一般的な利点を現在のAS209045の実績へ変換できない。

また、相互接続の設計が存在したことは、現在の経路広報を保証しない。過去に構成されたポート、遠隔接続、ルートサーバー参加が、その後も同じ契約、同じ容量、同じ経路方針で使われ続けるとは限らない。RISの現在値とDE-CIXのセッション観測を踏まえれば、購入者は事例紹介の設計図を現状説明として受け取らず、最新のBGP状態とトラフィック測定を求めるべきである。

逆に、現在確認できたルートサーバーの停止だけで、ピアリング戦略そのものが無価値だったとも言えない。過去の履歴にはAS209045のプレフィックス可視性があり、2025年12月1日にはAS50304が近隣として観測されている。設計の狙い、過去の観測、現在の観測を時系列で分ければ、必要なのは断定ではなく更新された運用説明だと分かる。

調達上の問いは、宣伝文句の真偽を争うことではない。現在使える交換点とポート、ルートサーバーと直接ピアの内訳、トランジットの代替、地域間の経路、障害時の切替条件、直近の遅延・損失・経路数を確認することだ。AIやHPCという用途名は、通信依存性を強める理由にはなるが、ネットワークの実効性能を証明する測定値ではない。

リージョンは操作範囲であって独立性の証明ではない

Genesis Cloudの開発者向け文書は、Compute APIと平均毎秒10リクエストの制限を説明している。regionsの文書にはNorway-KRS1、識別子NORD-NO-KRS-1があり、プライベートネットワーク、ボリューム、セキュリティグループをリージョン単位の資源として扱っている。利用者はこの単位を使って計算、保存、通信規則を操作できる。

ここで「リージョン」という言葉を、完全に独立した災害領域と同義にしてはいけない。文書上の地域境界からは、実際の複製先、建屋間の距離、電力系統の共通部分、長距離回線の共有、管理機能の共通依存、予備容量の配置は分からない。NORD-NO-KRS-1という識別子は操作対象を選ぶために重要だが、別の地域へ自動的に切り替わることを保証しない。

毎秒10リクエストという平均制限も、平常時の自動化設計には使えるが、事故時の成功率を示さない。多数の仮想マシン、ボリューム、通信規則を一斉に再作成する場合、呼び出し制限、同時処理、再試行、依存順序が復旧時間に影響する。APIが文書化されていることと、逼迫時にも必要な操作が同じ速度で完了することは別だ。

購入者は、リージョンを選べるかだけでなく、各資源がどの地域に固定され、どの操作が地域をまたげるのかを一覧化すべきである。インスタンス、起動ディスク、追加ボリューム、スナップショット、イメージ、セキュリティグループ、プライベートネットワーク、オブジェクト保存先、APIの名前解決を同じ表で追うと、計算だけを再作成してもサービス全体は戻らない可能性が見える。

公開文書から判断できるのは、利用者に一定の地域別操作面が用意されていることまでだ。物理的な複製、地域間の独立性、代替在庫、復旧の完了時間については、購入者固有の実証が必要である。文書の機能一覧は試験項目を作る材料であり、試験結果の代用品ではない。

在庫の真偽値と代替能力は違う

availabilityの機能は、リージョンとインスタンスタイプに応じた利用可能性を真偽値で返す。instance-typesの文書はNorway-KRS1で選べるCPUとGPUの形状を示す。購入者が自動化の前段で「今、要求できそうか」を問い合わせるには便利な仕組みである。

しかし、真であることは予約ではない。照会後に別の利用者が容量を確保するかもしれず、要求する台数すべてが同時に用意できるかも分からない。特定GPUの型、メモリー量、接続方式、ローカル保存領域、ネットワーク性能が元の環境と同等であることも、単一の真偽値では表せない。製品一覧に形状が載っていることも、事故時の代替在庫を確約しない。

反対に、ある時点で偽が返ることも、永続的な供給停止を意味しない。容量は時間とともに変わり得るため、観測時刻、リージョン、インスタンスタイプ、要求台数を一緒に記録しなければ、調達判断に使える履歴にならない。平常時に一台だけ起動できた結果を、大規模復旧時に必要な数十台、数百台へ外挿することもできない。

GPU計算では、代替能力の確認が特に重要だ。ハードウェアの型が変われば、ドライバー、ライブラリー、学習の再現性、分散処理の構成、性能単価が変わる。空きがあるという回答だけでなく、許容できる代替形状、最低台数、確保までの時間、地域変更時のデータ移送時間を事前に定義しておく必要がある。

購入者が求めるべき証拠は、製品一覧の画面ではなく、自社アカウントでの割当量、実際の起動要求、失敗時の理由、必要台数を確保できる時間である。予約や優先割当の契約があるなら、その対象地域と形状、除外条件を確認する。公開資料だけでは、代替GPU容量、在庫の優先順位、逼迫時の供給義務を確定できない。

インスタンス操作は復旧保証ではない

instancesの文書は、作成、起動、停止、再起動、終了などのライフサイクル操作を示し、起動時のスクリプトや接続ボリュームの扱いも説明する。利用者が構成をコード化し、同じ手順を繰り返すための基礎になる。終了時に起動ディスクがどう扱われるかという注意も、破壊的な操作を避けるうえで重要だ。

それでも、操作項目が存在するだけでは復旧しない。元のインスタンスを終了できることは、同等のGPUを別の場所で確保できることを意味しない。起動時のスクリプトが保存されていても、依存するパッケージ配布先、秘密情報、ライセンスサーバー、名前解決、外部データが利用できなければ構成は完了しない。自動化の成功は、計算資源以外の依存関係にも左右される。

起動ディスクを伴う終了操作は、復旧試験の手順設計にも影響する。本番機を壊さずに複製できるか、試験用のスナップショットから隔離環境を作れるか、終了と削除の権限を分けられるかを確認しなければならない。操作権限が広すぎれば人為的な損失の危険が増え、狭すぎれば事故時に必要な作業が遅れる。

復旧時間を測る際は、API呼び出しが受理された時刻だけでなく、インスタンスが起動し、ボリュームが接続され、通信規則が適用され、アプリケーションが応答し、データ整合性を確認できた時刻まで追うべきだ。文書が示す状態遷移と、利用者が必要とするサービス回復の完了条件は一致しない。

したがって、インスタンス操作面の評価は「機能があるか」から「自社の構成を再現できるか」へ進める必要がある。構成ファイル、イメージ、起動処理、秘密情報、監視、DNS変更を含む通し試験を日付付きで行い、元の地域が使えないという前提でも完了するかを見る。公開文書から、実行済みの復旧や特定顧客の回復時間を読み取ることはできない。

ボリューム、イメージ、スナップショットを分けて試す

volumes、images、snapshotsの文書には、リージョン、接続先、保存領域、イメージ種別、互換性、複製、スナップショットに関する引数が示されている。現在のinstancesとsnapshotsの文書には、replicated_regionまたは別リージョンへのcloneに関する指定もある。これは、利用者が状態を別の場所へ持ち出す操作を設計するための重要な手掛かりだ。

ただし、引数があることを普遍的な地域間複製保証と書き換えてはならない。どの資源種別、どのイメージ、どの大きさ、どの暗号化条件で利用できるのか、完了まで何時間かかるのか、複製時点のデータが完全かは、実際に試さなければ分からない。文書だけでは、すべてのスナップショットが任意の地域へ移せるとも、事故時に同じ速度で処理されるとも言えない。

ボリュームとスナップショットも同一ではない。実行中の書き込みがある状態で取得したスナップショットが、アプリケーション整合性を満たすとは限らない。データベースの静止化、ログの確定、分散ノード間の順序を考えずに複製すれば、ファイルが存在してもサービスとして復元できないことがある。復旧時点は、保存機能の存在ではなく、復元後の検証で決まる。

イメージの互換性も実機で確認する必要がある。別のGPU形状や仮想化環境で起動するか、必要なドライバーが合うか、ネットワークインターフェース名やディスク配置が変わらないか、ライセンス条件に抵触しないかを試す。cloneの要求が成功しても、その先でアプリケーションが動かなければ代替環境にはならない。

購入者は、少なくとも小規模な復元を定期的に実行し、要求開始、複製完了、ボリューム接続、起動、整合性確認までの時間を保存すべきだ。さらに、元の地域へ接続できない状況を模した試験を行い、管理API、保存先、認証、名前解決の共通依存が残っていないかを見る。文書上の可搬性は有望な操作面だが、日付付きの実行結果がなければ復旧力の証拠にはならない。

通信規則の再現と経路の冗長性は別問題

security-groupsの文書は、リージョン単位でファイアウォール規則と通信制御を設定する仕組みを示す。接続元、宛先、プロトコル、ポートを定義できれば、再作成した環境に最低限の通信境界を戻すことができる。構成を自動的に再現するうえで欠かせない要素である。

しかし、セキュリティグループは経路そのものを作らない。規則が正しくても、外部経路が広報されていない、上流接続がない、DNSが古い宛先を指す、プライベートネットワークが再現されていない場合、通信は成立しない。逆に、経路が存在しても規則の移行に失敗すれば、必要な通信が遮断されたり、意図しない範囲へ開放されたりする。

また、リージョン単位の規則が、地域間のネットワーク分離や東西通信の隔離を証明するわけではない。管理面、監視、認証、ログ保存が同じ障害領域にある可能性も残る。文書から設定項目は分かっても、物理経路の多重化、セグメント間の独立性、事故時の切替は分からない。

復旧試験では、規則を再作成できたかだけでなく、期待した通信だけが通るかを両方向から測るべきだ。公開サービスへの入口、管理用接続、ノード間通信、保存先、監視先を分け、許可すべき通信と拒否すべき通信を検証する。設定のエクスポートがあっても、地域固有の識別子や参照先が残っていれば、そのままでは別地域で適用できないことがある。

AS209045の現在のRIS可視性とDE-CIXセッション状態を考えると、クラウド内の通信規則と対外経路を同じ試験表に載せる意味は大きい。アプリケーション側の復元が完了しても、利用者から到達できなければ事業上の回復にはならない。通信制御は必要条件だが、経路可用性の十分条件ではない。

DNSが示す外部の制御依存

genesiscloud.comのCloudflare RDAP記録には、ara.ns.cloudflare.comとzeus.ns.cloudflare.comがネームサーバーとして載る。ドメイン登録日は2008年8月5日、最終変更は2026年7月11日、有効期限は2027年8月5日である。これはドメイン登録と権威DNSの委任先についての手掛かりであり、Genesis Cloudの本番DNS全体やクラウド内ワークロードの到達性を開示するものではない。

api.genesiscloud.comについては、Google Public DNSの確認でgws-loadbalancer-prd.genesiscloud.comへのCNAMEを経て34.76.254.30へ解決された。RIPEstatのnetwork-infoはこのアドレスをAS396982へ対応させ、ARINはAS396982をGOOGLE-CLOUD-PLATFORMとしている。確認時点の公開API入口がGoogle Cloudの番号資源上のアドレスへ解決されたという、具体的な外部依存の証拠である。

この事実から、Genesis Cloudの全管理機能がGoogle Cloudへ外部委託されている、データ面も同じ場所にある、冗長化がない、と結論することはできない。DNSが返す一つの公開入口から分かるのは、名前解決経路と最終Aレコードの所属ASまでである。負荷分散の背後にある構成、別の入口、認証、データベース、地域間切替は公開DNS応答だけでは見えない。

同様に、Cloudflareのネームサーバー利用から、Genesis Cloudのあらゆるサービス通信がCloudflareを通るとは言えない。権威DNSの運用と、APIの宛先、計算ワークロードのデータ通信、AS209045のBGP広報は別の層である。ただし、ドメイン委任、公開リゾルバー、API入口の外部ASという連鎖がある以上、購入者は自社の復旧設計に外部依存を明示すべきだ。

実務では、API名のCNAMEとAレコード、応答時間、TTL、複数地域からの到達性、TLS接続、認証後の最小操作を定期的に測る。AS209045の経路が見えない時でもAPIが使えるのか、逆にAPI入口が使えない時に既存ワークロードへどの操作が残るのかを分けて試す。APIのDNS経路が外部ASにあることは、回復力を高める場合も共通依存を増やす場合もあり、構成と試験なしに方向を決められない。

解決しなかった保存先をどう扱うか

regionsの文書は、オブジェクト保存先としてs3.nord-no-krs-1.genesiscloudusercontent.comを記載している。ところが確認時点のGoogle Public DNSでは、このホストのAレコード照会とgenesiscloudusercontent.comのNS照会が、いずれもDNS Status 3のNXDOMAIN型応答を返した。文書に載る利用先が公開DNSで解決しなかったことは、購入者が見過ごせない強い試験信号である。

それでも、NXDOMAINを保存データ消失の証明にしてはならない。対象名が変更された、公開向けではなくなった、文書更新が追い付いていない、別の名前や私設DNSを使うなど、公開資料だけでは選べない可能性がある。また、一つの文書化された入口が解決しないことから、すべてのオブジェクト保存機能、すべての地域、既存の保存データ、Genesis Cloud全体が停止したとは言えない。

重要なのは、購入者にとって名前解決が復旧手順の入り口になることだ。保存データが物理的に残っていても、利用者が正しいエンドポイントを発見できず、認証できず、一覧や取得を実行できなければ、復旧に使えない。逆に、名前が解決しても、必要なオブジェクトが完全で、期限内に読み出せる保証にはならない。

確認すべき項目は、現在有効な正式エンドポイント、名前解決の範囲、証明書、認証方式、バケット一覧、少量と大容量の読み書き、複数場所からの到達性、データのハッシュ、復元速度である。既存の保存先が使えない場合に、別の地域または顧客管理の保存先へ複製できるかも試す必要がある。問い合わせへの回答だけでなく、実際の読み出し結果を保存するべきだ。

このDNS観測は、AS209045のRIS不在とは別の証拠層にある。対象ホストの名前解決失敗と、ASNの経路不在が同時に見えても、共通原因だとは断定できない。関連を調べるには、正しい現行ホスト名、宛先アドレス、所属AS、経路、サービス応答を同じ時刻帯で確認する必要がある。

公開APIと顧客環境の間にある空白

Compute APIの存在は、利用者がインスタンス、ボリューム、イメージ、スナップショット、セキュリティグループなどを操作できる設計を示す。公開APIのDNSがGoogle CloudのASへ解決される一方、AS209045のRIS可視性がゼロであることから、管理用入口とAS209045の公開経路は少なくとも同一の観測結果にはなっていない。この分離は、制御機能の到達性を考えるうえで重要だ。

ただし、入口が別のASにあることだけで、管理機能がデータ面から完全に独立しているとは言えない。APIが受け付けた要求を実行する先、認証情報、状態データ、メッセージ配送、地域内の管理ネットワークがどこにあり、どの障害を共有するかは不明である。外からAPIが応答しても、対象地域で新しい資源を確保できない可能性はある。

反対に、AS209045がRISに見えなくても、顧客環境が別の経路、別の起点AS、私設接続を使っている可能性は排除できない。公開資料は完全なデータ面のアドレス設計を示していないため、ASNの観測を全ワークロードへ拡張できない。顧客は自分の仮想マシンに割り当てられたアドレスと起点ASを測り、外部からの経路と実通信を確かめる必要がある。

この空白を埋める最小試験は、APIで小さなインスタンスを要求し、状態が完了になるまで追い、割り当てアドレスの起点ASと到達性を複数地点から測り、終了まで実行することだ。そこへボリューム復元、通信規則、DNS更新を加えれば、文書上の機能が一つの復旧手順としてつながるかが分かる。

事故時には、平常時に成功した個別操作が同じ順序、同じ速度で成功するとは限らない。容量不足、呼び出し制限、認証、地域依存、名前解決のどこで止まるかを記録し、代替手順を用意する必要がある。公開APIは検証可能性を高める道具だが、検証そのものを省略する理由にはならない。

購入者が日付付きで実証すべきこと

第一の試験は、アカウント固有の割当量と交換可能な計算資源である。利用予定の各インスタンスタイプについて、平常時の空き表示だけでなく、必要台数の起動要求を行う。元のGPU形状が得られない場合に許容する代替、性能差、ソフトウェア互換性、確保までの時間を測る。公開製品一覧や真偽値を、予約や供給義務として扱わない。

第二の試験は状態の回復である。稼働中のデータを整合した形でスナップショットにし、別の対象地域へ複製し、ボリュームとして接続し、イメージから計算資源を起動する。要求開始からアプリケーション検証までの時間を取り、復旧時点と復旧時間を区別する。小さな試験だけでなく、実際のデータ量に近い読み出しと復元を行う。

第三の試験は通信設定である。セキュリティグループとプライベートネットワークを空の環境へ再作成し、許可通信と拒否通信を確認する。地域固有の参照、固定アドレス、証明書、秘密情報、監視先が自動化を止めないかを見る。計算資源が起動したという状態ではなく、利用者が必要なサービスへ到達できることを完了条件にする。

第四の試験は名前解決とAPI入口である。api.genesiscloud.comのCNAME、Aレコード、宛先AS、接続結果を時刻付きで記録し、文書化されたオブジェクト保存先についてもAとNS、認証後の読み書きを確認する。NXDOMAINが返る場合は、現行の正式名と移行手順を確認し、データがあるという説明だけで完了にしない。

第五の試験は公開経路と相互接続である。AS209045のIPv4、IPv6の広報プレフィックス、RIS可視性、観測近隣、RPKI状態を同時に保存する。DE-CIX FrankfurtとKristiansandについて、ルートサーバーセッション、受信・送信経路数、最終状態変化、直接ピアやトランジットの代替を確認する。PeeringDBの設定値と観測値を別欄に置く。

第六の確認は契約上の救済と責任分担である。今回確認できた資料だけでは、現在の価格、サービス水準に伴うクレジット、サポート応答、プライバシー上の管理主体を確定できない。古い説明を現在の条件として引用せず、契約相手から有効な条項を直接入手し、対象法人、対象サービス、除外条件、申請期限を確認する必要がある。

これらの試験は、一度成功すれば終わりではない。経路、DNS、在庫、文書、法人状態は変わるため、日付、アカウント、地域、資源種別、要求量、結果、所要時間を残して定期的に繰り返す。公開記録の更新日と自社試験日を並べれば、どの結論が現在も有効かを判断しやすくなる。

証拠の強さを購入条件へ変える

公的な登録情報、API文書、DNS応答、RIPE RISの経路可視性については、対象と時刻を限定すれば証拠強度は中程度と評価できる。Genesis Cloud Limitedと番号資源の関連、AS209045の方針記録、2026年7月20日のRISゼロ可視性、API名の解決先、文書化された保存先のNXDOMAIN型応答は、再確認可能な具体的事実である。

一方、購入者固有の物理容量、保存データの複製配置、代替GPU在庫、経路と管理機能の完全な冗長構成、実行済みの復旧については証拠が弱い。施設ページや製品文書は設計可能性を示すが、個別契約に割り当てられた資源や試験結果を示さない。ここを「一般にはそうだろう」という推測で埋めると、最も費用の大きい障害時に前提が崩れる。

中程度の証拠は、無条件の採用や即時の排除を命じるものではない。むしろ、どの購入条件を検証可能な形にするかを決める。例えば、必要GPU台数の試験、地域間複製の最大時間、保存先の外部コピー、経路観測の通知、連絡窓口、契約上の対象法人を、受入条件として明文化できる。

AS209045のゼロ可視性は、ネットワーク資源の公開経路を重視する購入者にとって重大な確認事項である。しかし、対象ワークロードがAS209045を使っていないなら、その直接的な影響は異なる。だからこそ、自社に割り当てられるアドレス、起点AS、入口、保存先を契約前の試験で特定しなければならない。企業名だけを見てネットワーク構成を推定することはできない。

同じく、Genesis Cloud GmbHのLEI記録は法務確認を促すが、別法人や全サービスの状態を決めない。購入者は請求書、契約書、データ処理条件、サポート連絡先に記載される法人名を照合し、Genesis Cloud Limitedやその他の主体との関係を確認する必要がある。技術記録と法的記録を接続するのは、推測ではなく契約文書である。

調達判断は「あるか」から「戻せるか」へ

Genesis Cloudについて公開記録から見えるのは、何もない空白ではない。登録番号資源、六つの経路オブジェクト、RPKIのVRP、複数の経路方針、PeeringDBに記載された二つの10G交換点接続、施設情報、Compute API、地域別資源、状態を扱う機能、外部DNS依存がある。これらは調査と試験の入口として価値がある。

同時に、現在の観測には看過できない空白がある。2026年7月20日0時のRIPE RISではAS209045のIPv4とIPv6可視性、広報プレフィックス、観測近隣がすべてゼロだった。DE-CIXで確認したルートサーバーの対象セッションはダウンまたはパッシブで、経路数もゼロだった。文書化されたオブジェクト保存先は公開DNSで解決しなかった。

これらを全面障害という一語にまとめるのは不正確である。API入口は別のASへ解決され、顧客のワークロードがどの経路を使うかは公開資料だけでは分からない。二者間接続、私設経路、別の起点AS、既存資源の状態も観測範囲外に残る。証拠が示すのは、公開経路と一部の接続、名前解決について、購入者が現在値を再検証すべき理由である。

調達判断の中心は、登録や機能が「ある」ことから、必要な条件でサービスを「戻せる」ことへ移るべきだ。元の地域が使えず、同型GPUが不足し、AS209045の経路が見えず、保存先の名前が解決しないという条件を置いて、それでもデータを取り出し、別の計算資源を確保し、通信規則を再現し、利用者へ到達させられるかを試す。

その試験が成功すれば、公開記録だけでは得られなかった購入者固有の強い証拠になる。失敗すれば、必要なのは曖昧な安心材料ではなく、外部保存、予備容量、別経路、別地域、別事業者といった具体的な緩和策である。Genesis Cloudを採用するかどうかは一律の結論ではなく、検証結果と許容損失、復旧目標、代替費用の組み合わせで決めるべきだ。

結論　記録を足すのではなく境界を確かめる

AS209045を読むときの核心は、PeeringDBの10G表示とRISのゼロ可視性のどちらを信じるかではない。前者は運用者が記載した接続構成、後者は多数の収集点から得た特定時刻の経路観測であり、DE-CIXのlooking glassはさらに特定ルートサーバーのセッション状態を示す。それぞれの答えを、本来の問いにだけ使う必要がある。

Genesis Cloud Routing, Peering and DNSというRIPE role、Genesis Cloud Limited、Genesis Cloud GmbH、AS209045も同じではない。Bulk Infrastructureは施設運営の文脈、DE-CIXは交換点、Google CloudはAPI用アドレスの所属AS、Cloudflareはドメイン委任の文脈に現れる。主体を混同しなければ、誰に何を確認すべきかが明確になる。

公開情報からは、現在の価格やサービス水準の救済、物理的な複製、代替GPU容量、完全な経路冗長性、実行済みの復旧を確定できない。そこで推測を重ねるより、APIと公開観測を使って小さくても実際の復旧を行い、契約上の回答と合わせて証拠を作るほうがよい。とりわけ、保存データの顧客管理コピーと、別の場所で再構成できる手順は、特定の施設やASNへの依存を減らす。

2026年7月20日時点で最も堅いネットワーク上の結論は限定的だ。AS209045はRIPE RISでIPv4、IPv6とも見えず、現在の広報プレフィックスも観測近隣もゼロだった。この事実は全サービス停止を証明しないが、過去の登録や接続事例だけで現在の到達性を仮定してはならないことを示す。

購入者にとっての結論も限定的かつ実務的である。登録資源、操作機能、施設名、ポート容量を安心材料として数えるのではなく、自社のアカウント、データ量、必要台数、地域、経路で復旧試験を完了させる。その結果がない限り、公開資料から言えるのは「操作できる可能性が文書化されている」ことであって、「必要なときに回復できる」ことではない。

Sources

  1. RIPE REST — role GCRP3-RIPE - https://rest.db.ripe.net/ripe/role/GCRP3-RIPE.json
  2. RIPE RDAP — AS209045 - https://rdap.db.ripe.net/autnum/209045
  3. RIPE REST — organisation ORG-GCL19-RIPE - https://rest.db.ripe.net/ripe/organisation/ORG-GCL19-RIPE.json
  4. RIPE NCC — Local Internet Registries in Malta - https://www.ripe.net/membership/member-support/list-of-members/mt/
  5. GLEIF — LEI 894500D5RP23ET9F9O40 - https://api.gleif.org/api/v1/lei-records/894500D5RP23ET9F9O40
  6. RIPE REST — resources linked to ORG-GCL19-RIPE - https://rest.db.ripe.net/search.json?query-string=ORG-GCL19-RIPE&type-filter=inetnum&type-filter=inet6num&type-filter=aut-num&inverse-attribute=org&flags=no-referenced&flags=no-filtering
  7. RIPE REST — route and route6 objects for AS209045 - https://rest.db.ripe.net/search.json?query-string=AS209045&type-filter=route&type-filter=route6&inverse-attribute=origin&flags=no-referenced&flags=no-filtering
  8. RIPE REST — aut-num AS209045 policy - https://rest.db.ripe.net/ripe/aut-num/AS209045.json
  9. PeeringDB — AS209045 public page - https://www.peeringdb.com/asn/209045
  10. PeeringDB API — AS209045 depth 2 - https://www.peeringdb.com/api/net?asn=209045&depth=2
  11. RIPEstat routing status — AS209045 - https://stat.ripe.net/data/routing-status/data.json?resource=AS209045
  12. RIPEstat announced prefixes — current AS209045 - https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS209045
  13. RIPEstat announced prefixes — AS209045 2025-11 to 2025-12 - https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS209045&starttime=2025-11-01T00:00:00&endtime=2025-12-03T00:00:00
  14. RIPEstat ASN neighbours — AS209045 at 2025-12-01 - https://stat.ripe.net/data/asn-neighbours/data.json?resource=AS209045&query_time=2025-12-01T00:00:00&lod=1
  15. RIPEstat RPKI history — AS209045 IPv4 - https://stat.ripe.net/data/rpki-history/data.json?resource=AS209045&family=4&resolution=d
  16. RIPEstat RPKI history — AS209045 IPv6 - https://stat.ripe.net/data/rpki-history/data.json?resource=AS209045&family=6&resolution=d
  17. BGP.tools — AS209045 - https://bgp.tools/as/209045
  18. DE-CIX looking glass API — Frankfurt IPv4 neighbours - https://lg.de-cix.net/api/v1/routeservers/rs1_fra_ipv4/neighbors
  19. DE-CIX looking glass API — Frankfurt IPv6 neighbours - https://lg.de-cix.net/api/v1/routeservers/rs1_fra_ipv6/neighbors
  20. DE-CIX looking glass API — Kristiansand IPv4 neighbours - https://lg.de-cix.net/api/v1/routeservers/rs1_krs_ipv4/neighbors
  21. DE-CIX looking glass API — Kristiansand IPv6 neighbours - https://lg.de-cix.net/api/v1/routeservers/rs1_krs_ipv6/neighbors
  22. DE-CIX — Genesis Cloud peering news - https://www.de-cix.net/en/about-de-cix/news/genesis-cloud-enhances-ai-and-hpc-capabilities-with-de-cix-peering
  23. DE-CIX — Genesis Cloud peering PDF case study - https://www.de-cix.net/_Resources/Persistent/7/0/6/4/70646d11ea3d9beea4d676de422368b2bf1ab4e9/AI%20and%20HPC%20in%20the%20Nordics_Genesis%20Cloud%20benefits%20from%20peering%20in%20Frankfurt.pdf
  24. DE-CIX — Kristiansand location - https://www.de-cix.net/en/locations/kristiansand
  25. Bulk Infrastructure — N01 data centre campus - https://bulkinfrastructure.com/data-centers/locations/n01/p3
  26. Bulk Infrastructure — data-centre connectivity - https://bulkinfrastructure.com/data-centers/connectivity
  27. Genesis Cloud Developers — Compute API - https://developers.genesiscloud.com/compute-api/
  28. Genesis Cloud Developers — Regions - https://developers.genesiscloud.com/compute-api/regions/
  29. Genesis Cloud Developers — Availability - https://developers.genesiscloud.com/compute-api/availability/
  30. Genesis Cloud Developers — Instance types - https://developers.genesiscloud.com/compute-api/instance-types/
  31. Genesis Cloud Developers — Instances - https://developers.genesiscloud.com/compute-api/instances/
  32. Genesis Cloud Developers — Volumes - https://developers.genesiscloud.com/compute-api/volumes/
  33. Genesis Cloud Developers — Images - https://developers.genesiscloud.com/compute-api/images/
  34. Genesis Cloud Developers — Snapshots - https://developers.genesiscloud.com/compute-api/snapshots/
  35. Genesis Cloud Developers — Security groups - https://developers.genesiscloud.com/compute-api/security-groups/
  36. Cloudflare RDAP — genesiscloud.com - https://rdap.cloudflare.com/rdap/v1/domain/genesiscloud.com
  37. Google Public DNS — api.genesiscloud.com CNAME - https://dns.google/resolve?name=api.genesiscloud.com&type=CNAME
  38. Google Public DNS — api.genesiscloud.com A - https://dns.google/resolve?name=api.genesiscloud.com&type=A
  39. RIPEstat network-info — 34.76.254.30 - https://stat.ripe.net/data/network-info/data.json?resource=34.76.254.30
  40. ARIN RDAP — AS396982 - https://rdap.arin.net/registry/autnum/396982
  41. Google Public DNS — s3.nord-no-krs-1.genesiscloudusercontent.com A - https://dns.google/resolve?name=s3.nord-no-krs-1.genesiscloudusercontent.com&type=A
  42. Google Public DNS — genesiscloudusercontent.com NS - https://dns.google/resolve?name=genesiscloudusercontent.com&type=NS