Summary

  • ARIN には、Sovy Cloud Services に結び付く AS401110 が AS-SOVYCLOUD として active の状態で残る。これはネットワーク資源の登録上の同一性と過去の活動を支えるが、現在のクラウドサービス稼働をそれだけで証明するものではない。
  • 2026年7月20日、.cloud の RDAP は sovy.cloud を登録可能とし、システムリゾルバ、Cloudflare の1.1.1.1、Google の8.8.8.8はいずれも A レコード照会に NXDOMAIN を返した。ブランドの公開入口が確認できないという強い注意信号だが、会社の廃業や全サービスの停止までは意味しない。
  • PeeringDB にはグローバルな NSP、五つの施設との関連、IRR の AS-SOVYCLOUD という申告が残る一方、IPv4・IPv6 プレフィックス数と IX 数はゼロで、公開交換 LAN 行と公開 POC 行もなかった。施設行は調査の手掛かりであり、現在の設備、契約、顧客負荷を保証しない。
  • RIPEstat は2026年7月20日08:00 UTC 時点で AS401110 を未広報とし、現在のプレフィックス、RIS 可視性、隣接 AS もゼロと報告した。ただし、2024年から2025年にかけて複数の経路が観測されており、「実際には一度も運用されなかった」と読むのも誤りである。
  • 買い手が必要とするのは、古い登録を一括して信じることでも、現在の無音だけで事業の終わりを断定することでもない。証拠ごとに対象と観測時刻を分け、ドメイン、経路、連絡手段、施設申告について新しい裏づけを取り直すことである。

一つの事業者について、二つの異なる姿が残っている

Sovy Cloud Services を公開データだけで調べると、最初に現れるのは単純な「存在する」「存在しない」という答えではない。ARIN には active の AS 番号があり、PeeringDB には世界各地の施設と結び付いた NSP のプロフィールがある。その一方で、ブランド名と一致するドメインは名前解決できず、公開 BGP 観測では AS から出る経路も、その周囲の隣接関係も確認できない。記録の各層が、異なる時点と異なる種類の事実を語っている。

この食い違いは、公開情報の誤りを一つ見つければ解決するという問題ではない。ARIN の記録は番号資源の登録と連絡先を扱う。PeeringDB はネットワーク事業者が相互接続のために示すプロフィールである。RIPEstat は経路収集基盤から見える BGP の状態を集約する。ドメイン RDAP と DNS は、ブランドの公開入口が登録され、名前解決できるかを示す。それぞれは有用だが、どれも単独では会社の法的状態、顧客契約、施設内の機器、サポート体制、非公開ネットワークまで一望できない。

だから評価の出発点は、公開名簿に項目があるかどうかではなく、「その項目は何を証明でき、何を証明できないか」でなければならない。Sovy Cloud Services の場合、登録上の同一性と過去の経路運用には相応の裏づけがある。しかし、2026年7月20日に観測できる公開運用面は著しく薄い。この二つを同時に保持することが、過大評価にも早計な断定にも陥らないための基本になる。

ARIN の active は、現在のサービス稼働を表すラベルではない

ARIN の自律システム番号記録では、AS401110 は AS-SOVYCLOUD という名称で active とされている。登録日は2024年5月29日、最終変更日は翌30日である。関連する組織ハンドルは SCSL-51、名称は Sovy Cloud Services で、住所は25 First Ave. SW STE A, Watertown, SD 57201, United Statesと記録されている。少なくとも、番号と名称が無関係な第三者の推測で結び付けられたわけではなく、ARIN の公開登録の中に明確な対応関係がある。

ここで active という語を、クラウド環境が現在も顧客トラフィックを処理しているという意味に読み替えてはいけない。これは ARIN の資源記録上の状態である。ASN が登録に残っていることは、ウェブサイトが稼働していること、経路が広報されていること、契約相手が応答すること、あるいは PeeringDB に示された各施設でサービスが提供されていることを自動的には保証しない。登録の維持とサービスの稼働は、調査上別の命題である。

連絡先の記録にも時間差が表れている。ARIN に入れ子で登録された管理、技術、abuse の連絡先は sovy.cloud のメールアドレスを用いているが、2025年5月7日以降に応答がなく、POC が未検証であることを示す注記が付いている。これは公開連絡経路の信頼性を下げる材料になる。ただし、メールボックスが必ず停止している、担当者が存在しない、顧客サポートに別の経路がない、とまでは分からない。分かるのは、ARIN が期待する公開連絡先検証に応答がなく、その弱さが記録に残っているということだ。

買い手にとっての実務的な意味は明快である。ASN の active 表示をチェック欄の完了として扱わず、番号資源の同一性が確認できたという一段階の結果に限定するべきだ。その次には、いま使えるブランド入口、応答する連絡先、現在の経路、そしてサービス提供を裏づける相手方の資料が必要になる。

登録情報の更新日を、サービスの更新日と取り違えない

AS401110 の登録日が2024年5月29日で、最終変更日が翌30日であることは、調査の基準点を与える。ところが、この日付はクラウド基盤が最後に点検された日でも、顧客契約が更新された日でも、ネットワークの到達性が確認された日でもない。登録項目が最後に変更された時刻と、そこで名前を与えられた事業が最後に実働していた時刻は、別々に管理しなければならない。

番号資源の記録は、運用状況が変わるたびに自動更新される監視画面ではない。AS が経路を広報しなくなっても、ウェブサイトが消えても、施設との関係が変わっても、登録上の名称や状態が直ちに同じ速度で変化するとは限らない。したがって、古い日付があること自体を不正確さの証明にはできないが、現在形の営業説明を支えるには追加確認が必要だという鮮度の境界にはなる。

連絡先検証の注記は、この境界をさらに具体化する。ARIN の管理、技術、abuse の各連絡先は sovy.cloud を使い、2025年5月7日以降の無応答により未検証とされている。ここから言えるのは、公開登録を維持するための確認に応答が得られなかったことまでである。誰かが別経路で業務を続けている可能性は残るが、その可能性を登録上の active 表示から補うことはできない。

調達担当者が記録すべきなのは、単一の「有効」「無効」ではなく、項目ごとの最終確認日である。法人または組織の同一性、番号資源の登録、公開連絡先、ドメイン、経路、施設申告を別々の行にし、どの観測が誰によっていつ確認されたかを残す。そうすれば、AS401110 の登録は同一性の根拠として保持しながら、現在のサービス確認だけを未完了として扱える。

この区別は、登録記録を疑って捨てるためではない。記録が強い領域にだけ使うためである。ARIN の行は Sovy Cloud Services、SCSL-51、AS-SOVYCLOUD、AS401110 の対応関係を支える。一方で、現在の顧客向け運用を示すには、登録データとは別の更新頻度を持つ観測と相手方資料が必要になる。

sovy.cloud の不在は強い警告だが、結論そのものではない

2026年7月20日の.cloud レジストリ RDAP は、sovy.cloud を登録可能と報告した。同じ日に A レコードを調べると、ローカルのシステムリゾルバだけでなく、Cloudflare の1.1.1.1と Google の8.8.8.8も NXDOMAIN を返した。単一のキャッシュや一つの再帰リゾルバの一時的な挙動ではなく、三つの照会経路で、問い合わせたドメイン名そのものが DNS 上に存在しないという結果が一致したことになる。

これは Sovy Cloud Services を現在のクラウド事業者として評価するうえで重い。PeeringDB のウェブサイト欄は sovy.cloud を指し、ARIN の公開連絡先も同じドメインを使う。つまり、ドメインの不在は単に企業サイトが閲覧できないという一点にとどまらず、二つの主要な公開ディレクトリーに残る案内先と連絡先の鮮度にも疑問を投げ掛ける。新規顧客がブランドを確認し、サービス説明を読み、正式な連絡経路をたどるための一般公開面が、今回の観測からは成立していない。

それでも、NXDOMAIN から会社の廃業を直接導くことはできない。別の公開名、閉じた顧客ポータル、第三者ブランド経由の提供、非公開の管理面など、公開データだけでは検証できない可能性が残る。反対に、それらの可能性が理論上あるというだけで、現在運用の証拠として数えることもできない。調査者が置くべき結論は、「代替の運用経路がある」ではなく、「公開面からは代替経路を確認できない」である。

また、ドメインが登録可能であるという観測は時刻に強く依存する。再登録されれば状態は変わり得る。したがって、監査記録には照会日、利用したレジストリ、DNS の応答、問い合わせたレコード種別を残す必要がある。Sovy Cloud Services のケースで重要なのは、永続的なラベルを貼ることではなく、2026年7月20日の時点で、過去の登録記録が示すブランド入口が公開 DNS から消えていたという事実である。

ドメインは、ウェブ入口だけでなく公開同一性の接点でもある

sovy.cloud は、単に PeeringDB のウェブサイト欄に記された一つの URL ではない。ARIN の管理、技術、abuse 連絡先にも同じ文字列が使われている。このため、ドメインの状態は企業サイトの閲覧可否だけでなく、登録情報に残る組織名、ネットワーク資源、公開連絡経路を一つのブランドとして結び付ける接点の状態でもある。

2026年7月20日の観測では、レジストリ RDAP がこの名前を登録可能とし、三つの異なる再帰照会経路が A レコードに NXDOMAIN を返した。RDAP は登録状態を、DNS は名前空間での存在を調べるため、全く同じ検査ではない。それでも両者が同じ日に、過去の公開記録が指す名前を現在利用できる入口として確認できない方向で一致したことには意味がある。

ここから直ちに、ARIN に載る個々のメールボックスが停止したと断言することはできない。メール配送には A レコード以外の要素があり、非公開または別ブランドの連絡手段も理論上はあり得る。ただし、候補事業者の身元確認に古い sovy.cloud のメールアドレスだけを使うのは不十分である。調査日に公開名前空間で確認できなかったドメインを、現在も組織が支配しているという前提に置けないからだ。

新しい連絡先が提示された場合も、単に返信が来るかだけでなく、その連絡先が Sovy Cloud Services または Sovy Cloud Services LLC と AS401110 を現在どう結び付けるかを確認する必要がある。契約主体、請求主体、技術運用者、障害連絡先が異なるなら、その関係を説明する資料が要る。古い公開記録と新しい窓口の間に検証可能な連続性がなければ、応答の速さだけでは同一性を証明できない。

ドメインが後日再登録され、DNS が復旧したとしても、2026年7月20日の観測が消えるわけではない。むしろ、再登録日、登録主体の確認、DNS 復旧時刻、公開内容、連絡先の再検証を新しい証拠として積み上げるべきである。名前が再び応答することと、過去と同じ事業者が顧客向けクラウドを継続運用していることは、なお別の問いである。

PeeringDB の五つの施設行は、現在地ではなく検証先を示す

PeeringDB のネットワークプロフィールには、sovy.cloud、Sovy Cloud Services、組織名 Sovy Cloud Services LLC、タイプ NSP、スコープ Global、IRR として AS-SOVYCLOUD が記録されている。プロフィールは五つの施設との関連も示す。指定された表記のまま並べると、Equinix SG1 - Singapore、Equinix SG3 - Singapore、Equinix HK2 - Hong Kong、Linxdatacenter (Moscow)、NewTelco Kievである。

地理的にはシンガポール、香港、モスクワ、キーウにまたがり、一見すると広域な展開に見える。しかし、PeeringDB の施設関連行が直接示すのは、プロフィールにネットワークと施設の関連が登録されていることまでだ。各行が現在も有効である、対象サービスの提供地点として使われている、顧客ワークロードが置かれている、五地点が相互に冗長化されている、といった運用上の命題は別途確認しなければならない。施設事業者との現行契約やサービス品質を PeeringDB から読み取ることもできない。

同じプロフィールの数値は、その華やかな地理情報に慎重な注釈を加える。IPv4 プレフィックス数はゼロ、IPv6 プレフィックス数もゼロ、IX 数もゼロである。交換 LAN の公開行は返らず、一般公開された POC 行もなかった。五つの施設行があることと、公開相互接続面が見えることは一致していない。もっとも、交換 LAN 行がないからトランジット契約がないとは言えず、公開 POC 行がないから非公開の連絡先もないとは言えない。ここでも「公開欄の不在」を「現実世界の完全な不在」へ拡張してはならない。

PeeringDB を生かす正しい方法は、五施設を稼働証明として受け入れることではなく、確認先のリストに変えることだ。候補事業者には、どの施設関連が現在も有効なのか、どのサービスがどこから提供されるのか、誰がその主張を独立に確認できるのかを尋ねられる。回答が得られれば古いディレクトリー行を新しい証拠に更新できる。回答がなければ、施設一覧は履歴的な申告として重みを下げて扱うべきである。

五つの施設申告を、五つの検証課題に分解する

施設一覧を一つの「グローバル展開」という主張にまとめると、検証すべき違いが消えてしまう。Equinix SG1 - Singapore、Equinix SG3 - Singapore、Equinix HK2 - Hong Kong、Linxdatacenter (Moscow)、NewTelco Kievは、それぞれ別の施設行であり、同じ時期、同じ契約、同じ技術構成、同じサービス目的を持つとは限らない。調査では五行を五件の独立した申告として扱う方がよい。

各行について最初に問うべきなのは、対象サービスとの関係である。単にネットワーク名が施設ディレクトリーに結び付いているのか、現在も設備または回線があり、今回検討するクラウドサービスの提供に使われるのかでは、証拠の意味が違う。後者を主張するなら、対象施設、提供機能、運用主体、確認日がそろった説明を求める必要がある。

次に、外部から再確認できる要素と、相手方の説明に依存する要素を分ける。PeeringDB の netfac 行は公開情報として再取得できるが、ラック、電力、クロスコネクト、契約、顧客ワークロード、冗長構成までは示さない。今回の資料では netixlan に公開交換 LAN 行がなく、ネットワークプロフィールの IX 数もゼロであるため、施設名から公開ピアリング構成を補うこともできない。トランジットや私設接続の可能性は残るが、それは別の資料で示されるべきだ。

五施設のうち一つで現行関係が確認できても、残り四つまで自動的に確認済みにはならない。反対に、一つの行が古いと分かっても、全施設が非稼働だとは言えない。この粒度を保つことで、部分的な裏づけを全体へ拡張する誤りを避けられる。地域数の多さを評価する前に、各行を「確認済み」「相手方説明のみ」「公開申告のみ」「現在は確認不能」に分類するべきである。

Sovy Cloud Services の現行評価では、五つの施設名は具体的な質問を作る価値を持つが、回答そのものではない。どの施設が AS401110 の現在の経路に結び付くのか、経路が公開観測に出ないなら何が対象サービスの到達性を担うのか、障害時にどの窓口と運用主体が責任を持つのかを一件ずつ確かめる。施設行をこのような検証課題へ変換して初めて、古いプロフィールが現在の審査に役立つ。

BGP 履歴は、AS401110 が単なる空欄ではなかったことを示す

現在の無音だけを見ると、AS401110 は一度も使われなかった番号のように見えるかもしれない。RIPEstat の routing-history は、その読み方を退ける。2024年5月末から2025年2月までの観測範囲には、AS401110 を起点とする複数の経路が残っている。対象は166.88.177.0/24、2a12:8fc6:4011::/48、81.161.230.0/24、109.206.237.0/24、136.0.121.0/24、23.27.222.0/24である。

この履歴には二つの価値がある。第一に、ARIN と PeeringDB の記録が、経路収集系で観測された実際の広報履歴と接続する。AS 番号、IRR 名、事業者名だけがディレクトリーに置かれていたのではなく、少なくとも公開 BGP 上で AS401110 が起点として現れた期間があった。第二に、現在の状態を評価するための比較基準になる。以前は見えていたものが今は見えないからこそ、変化を具体的に示せる。

ただし、BGP 履歴もサービス内容の台帳ではない。あるプレフィックスを AS が広報したことは、その期間にどの製品が売られ、何社の顧客が利用し、どの施設に機器があり、どの SLA が適用されたかを教えない。経路が見えたことからクラウド商品の規模や品質を逆算することはできない。ここで証明できるのは、公開経路面で観測可能な活動があったという限定された事実である。

この限定は、履歴を軽視する理由ではない。むしろ、証拠の種類を正しく扱うための条件だ。会社の自己紹介だけでなく第三者の経路観測が過去の活動を支える一方、その観測が途切れた時期を現在の調査に結び付けられる。静的な登録情報だけでは得られない時間軸が、BGP 履歴にはある。

2026年7月20日の公開経路面は、複数の指標で静かだった

RIPEstat の AS overview は、2026年7月20日08:00 UTC の照会時点で AS401110 を not announced とした。announced-prefixes は直近二週間の窓に現在のプレフィックスを返さず、routing-status は現在広報中の IPv4 プレフィックスをゼロ、IPv6 の/48換算をゼロとした。IPv4 と IPv6 の RIS 可視性もゼロで、観測された隣接 AS もゼロだった。

ASN-neighbours の結果も同じ方向を指す。最新の利用可能な時点で、左側、右側、unique、uncertain の隣接数はいずれもゼロだった。したがって、RIPE RIS から見える公開 BGP 面には、現在のトランジットまたはピア関係を裏づける隣接情報がない。PeeringDB で IX 数と交換 LAN 行がゼロであること、DNS でブランド入口が見えないことと合わせると、一つだけでなく独立した複数の公開面が同時に薄くなっている。

一方、announced-prefixes には測定上の注意がある。RIS の full-feed ピアにおける可視性が非常に低い経路は、結果から除外され得る。インターネット全体のあらゆるルータを直接検査したわけではないため、「世界のどこにも経路がない」と言い換えるべきではない。RIS から見える現在の公開経路が確認できない、というのが適切な表現である。

同じ理由で、公開 BGP の無音は、私設接続、閉域サービス、内部ネットワーク、顧客ごとの非公開構成が存在しないことを証明しない。しかし、そのような非公開面があるなら、候補事業者側が新しい証拠を示す必要がある。観測できない可能性を、観測された稼働と同じ価値で扱うことはできないからだ。公開クラウドを名乗る相手の現況評価では、この証明責任の向きを曖昧にしてはいけない。

複数の公開面が同じ日に静かだったことをどう読むか

否定的な観測は、一件だけなら技術的な例外や測定範囲の違いを強く受ける。DNS の失敗だけなら、名前の変更や設定不備を考えられる。RIS で経路が見えないだけなら、低可視性や私設構成の可能性がある。PeeringDB に交換 LAN 行がないだけなら、トランジット中心の接続かもしれない。個別の空欄には、それぞれ異なる留保が必要である。

今回重いのは、異なる仕組みが2026年7月20日の現在運用を支える肯定的な手掛かりを同時に返していないことだ。.cloud の RDAP ではブランド名が登録可能、三系統の DNS 照会では NXDOMAIN、RIPEstat では AS401110 が未広報で現在プレフィックスと隣接 AS がゼロ、PeeringDB では IX 数、公開交換 LAN 行、公開 POC 行がゼロである。これらは同じ公開記録の重複項目ではない。

独立性があるからといって、ゼロを機械的に足し算して「廃業確率」を作ることはできない。各情報源が観測する対象は異なり、法的状態、顧客数、非公開サービスを直接測っていないからである。しかし、公開ブランド、公開経路、公開相互接続、公開連絡先のどれからも現在運用を補強できないなら、古い登録を現在形で受け入れるために必要な相手方証拠は増える。

このとき重要なのは、調査者が見つけられなかったという主観的な説明ではなく、再現可能な問いとして残すことだ。どの名前を、どのレコード種別で、どのリゾルバに照会したか。どの AS を、どの観測時刻で、どの経路指標にかけたか。どの PeeringDB ネットワーク ID に公開交換 LAN と POC を問い合わせたか。手順を固定すれば、後日状態が変わったときに同じ条件で差分を確認できる。

結論の強さも、観測対象に合わせる必要がある。「現在の公開運用面を確認できない」は、複数の結果から支持される。「事業者が存在しない」「顧客サービスが一切ない」は、同じ結果からは支持されない。この一段の差を守ることで、否定的なデータを軽視せず、同時にその射程を越えた断定も避けられる。

最初に見えた IPv6 と、最後に見えた IPv4 のその後

routing-status には、時間軸をつなぐ二つの目印がある。AS401110 について最初に観測されたものとして2a12:8fc6:4011::/48が2024年5月31日付で示され、最後に観測された IPv4 プレフィックスとして109.206.237.0/24が2025年2月14日付で示されている。現在の prefix-overview を重ねると、両者は別々の状態にある。

109.206.237.0/24は現在、AS401110 ではなく AS16045 BULINFO-HOSTING Spektar AD を起点として広報されている。これは起点 AS が変わったという公開 BGP 上の事実を示すが、その理由は示さない。アドレスの利用関係、再割り当て、運用主体、上流側の構成など、商業的・法的な経緯をこの観測だけで決めることはできない。少なくとも、Sovy Cloud Services の現在の到達性を裏づけるプレフィックスとして、古い履歴をそのまま数えることはできない。

一方、2a12:8fc6:4011::/48は現在広報されていない。これも IPv6 サービスが永久に終了したという意味ではないが、過去に見えた IPv6 経路を現在の運用証明として扱えないことは明らかである。履歴上の最初と最後の目印を現在の origin と広報状態まで追うことで、「プレフィックスの名前が資料に載っている」という確認から、「その経路はいま誰から見え、誰が起点なのか」という確認へ進める。

この追跡は、低可視性の事業者を評価する際に特に重要になる。ASN やプレフィックスは登録記録に長く残り、検索結果にも現れ続ける。ところが、経路の現在性は変わり得る。古い一覧を資産や接続性の現在値として読むのではなく、各プレフィックスの最新 origin、広報状態、観測時刻を別々に確認しなければならない。

点の一覧ではなく、変化の時間線として読む

Sovy Cloud Services の資料を日付順に並べると、静的な検索結果では見えにくい変化が表れる。2024年5月29日に AS401110 が登録され、翌30日に登録記録が変更され、5月31日には2a12:8fc6:4011::/48が最初の観測目印として現れる。その後、RIPEstat の履歴には六つの IPv4・IPv6 プレフィックスが AS401110 を起点として現れ、少なくとも公開経路上の活動期があったことが分かる。

次の目印は2025年2月14日で、routing-status は109.206.237.0/24を AS401110 について最後に観測された IPv4 プレフィックスとして示す。これはその日に会社やサービスが終了したという意味ではない。経路収集系で確認できる活動の終端を探すための観測点であり、契約、設備、顧客、組織の変化を説明する原因資料ではない。

さらに、ARIN の連絡先には2025年5月7日以降の無応答に基づく未検証注記が残る。経路の最終観測と連絡先検証の弱まりの時期が近いことは注意に値するが、一方が他方を引き起こしたと結論づける根拠はない。時間線の役割は因果を作ることではなく、どの時点から追加説明を求めるべきかを明確にすることである。

2026年7月20日には、sovy.cloud の登録可能状態と NXDOMAIN、AS401110 の未広報、現在プレフィックス、RIS 可視性、隣接 AS のゼロが同日に確認された。ここまで並べると、登録時の同一性、過去の公開活動、現在の公開無音という三段階が見える。古い登録と現在の観測を二者択一にせず、一つの変化過程として扱える。

この時間線を将来更新するときは、前の観測を消さずに新しい点を足すべきだ。AS401110 が再び広報される、別のプレフィックスが現れる、sovy.cloud が再登録される、公開 POC が追加されるといった変化があれば、その日付と内容を追加する。履歴を上書きしなければ、一時的な復旧、持続的な再開、別主体による変更を区別するための材料が残る。

証拠には「何の証拠か」と「いつの証拠か」の二軸がある

Sovy Cloud Services の公開記録を整理すると、証拠は三つの層に分かれる。第一は同一性である。ARIN の AS401110、AS-SOVYCLOUD、SCSL-51、名称、住所がこれに当たる。第二は過去の運用である。複数のプレフィックスが AS401110 を起点として観測された経路履歴がそれを支える。第三は現在の公開運用で、ドメインの登録・DNS 状態、現在の BGP 広報、隣接 AS、交換 LAN、応答可能な公開連絡先などから評価する。

第一と第二の層には肯定的な証拠がある。第三の層では、2026年7月20日の観測が否定的または空の結果を多く返した。ここで犯しやすい誤りは二つある。古い肯定的記録を使って現在の空白を埋めることと、現在の空白を使って過去の活動まで否定することだ。前者は事業者を過大評価し、後者は証拠を乱暴に捨てる。

時間軸を入れると、PeeringDB の施設行の扱いも変わる。五つの行は、少なくともプロフィール作成時にどの拠点との関連を主張していたかを示す。だが更新時刻や現在の裏づけを欠いたままでは、2026年の運用判断に使える強度は低い。ARIN の連絡先も同様で、登録されていることと、検証に応答していることは別である。静的な名簿を現在形で読むのではなく、各主張に有効期限を設ける必要がある。

この方法は、Sovy Cloud Services にだけ適用する特殊な基準ではない。小規模なクラウド、ホスティング、ネットワーク事業者では、法人・番号資源・ドメイン・相互接続プロフィール・経路が別々の速度で変化する。買い手は一つのロゴや一つの ASN 検索結果に依存せず、複数の面が同じ現在を指しているかを確かめなければならない。

「確認済み」「履歴あり」「未確認」を混ぜない

審査結果を一つの点数に畳むと、強い同一性証拠が弱い現在運用証拠を覆い隠しやすい。Sovy Cloud Services では、AS401110、AS-SOVYCLOUD、SCSL-51、組織名と住所の対応は ARIN で直接確認できる。ここは「確認済み」と置ける。一方、過去に六つの経路が AS401110 を起点として観測されたことは「履歴あり」であり、現在の到達性とは分離する必要がある。

現在のブランド入口は、2026年7月20日の RDAP と DNS から「未確認」よりさらに具体的に、公開名前空間では不在と記録できる。現在の公開 BGP 面も、RIPEstat の観測範囲で未広報、プレフィックス、可視性、隣接 AS がゼロである。施設については五行の公開申告が「履歴または申告として確認済み」だが、現在の設備・契約・対象サービス利用は「未確認」となる。

この分類では、空欄を推測で埋めない。たとえば非公開トランジットや顧客専用網があり得るとしても、証拠が提出されるまでは「確認済み」に上げない。同時に、未確認を「存在しない」とも書かない。分類名に証拠の状態を持たせれば、可能性の議論と観測された事実を同じ欄で混ぜずに済む。

連絡先にも同じ方法を使える。ARIN に sovy.cloud の管理、技術、abuse 連絡先が掲載されていることは確認済みである。検証要請への無応答注記も確認済みである。しかし、各メールボックスが現在配送不能であること、別の顧客窓口が存在しないことは確認されていない。何が肯定的事実で、何が否定的事実で、何がまだ調べられていないかを分けるべきだ。

最終判断では、分類ごとに用途を限定する。確認済みの登録同一性は、過去資料の名寄せや質問先の特定に使える。履歴ありの経路は、実際の公開活動期と変化点の把握に使える。未確認の現在運用は、調達承認を支える材料にはせず、追加証拠の要求事項に変える。こうすれば、古い情報を捨てずに、その重みだけを適切に下げられる。

買い手が求めるべきものは、説明ではなく更新可能な裏づけである

最初の確認対象は、契約相手とネットワーク資源の関係だ。ARIN の記録は Sovy Cloud Services と AS401110 の登録上のつながりを示すが、提案書を出す主体が現在その会社を代表し、その ASN やサービスを正当に運用していることまでは保証しない。候補事業者には、契約主体、現行の連絡先、サービス提供主体、障害時の責任窓口を一貫した形で示してもらう必要がある。

次は、観測時刻の付いたネットワーク証拠である。過去のスクリーンショットや古い PeeringDB プロフィールではなく、現在広報しているプレフィックス、origin AS、到達性、利用する公開接続面を特定し、買い手側でも独立に再確認できる形にする。非公開接続を理由に公開経路が見えないのであれば、その構成が対象サービスにどう結び付き、どの第三者または技術資料で確認できるかを相手に説明してもらう。秘密であることと、検証不能であることは同義ではない。

施設については、五つの名称をそのまま可用性の証明に使わない。どの施設が対象サービスに関係し、関係が現在も有効で、どの範囲を施設側または契約資料で確認できるのかを分けるべきだ。PeeringDB の行は質問を具体化するには有用だが、回答の代わりにはならない。地域名の多さより、対象ワークロードまで連続する証拠の方が重要である。

連絡経路も独立した検査対象になる。sovy.cloud を使う公開メールが ARIN に残る一方、そのドメインは調査日に NXDOMAIN で、POC 検証への未応答注記もある。買い手は営業担当一人との会話だけでなく、技術、セキュリティ、請求、契約、緊急時の各連絡経路が同じ組織へ確実につながるかを確認する必要がある。ここで必要なのはメールが必ず死んでいるという断定ではなく、公開記録からは到達可能性を信頼できないため再検証が要る、という判断だ。

最後に、これらの確認を一回限りの審査にしないことが重要になる。ドメイン、BGP、POC、施設申告はいずれも変化する。確認日と根拠を保存し、契約更新や重要な構成変更の前に取り直せるようにすれば、古い登録がいつまでも現在の証拠として残る問題を抑えられる。

継続確認を契約前の条件として設計する

現在の公開証拠が弱い事業者に対し、買い手ができる対応は、直ちに排除することと無条件に信頼することの二択ではない。足りない証拠を具体化し、提出、確認、再確認の条件を事前に定められる。Sovy Cloud Services の場合は、現在の運用主体、利用中のネットワーク資源、対象サービスの到達経路、連絡手段、施設との現行関係を別々の確認項目にする必要がある。

ネットワーク項目では、現在利用する origin AS とプレフィックスを相手方に特定してもらい、観測時刻をそろえて外部から確認する。AS401110 を使わない構成だという説明なら、どの資源と運用主体が代わりにサービスを担うのかを示してもらう。過去に AS401110 から見えた六つのプレフィックスを一覧として再提出するだけでは、2026年の到達性の証拠にはならない。

連絡項目では、営業担当者の応答だけを組織全体の継続性と見なさない。技術、abuse、障害、請求、契約上の通知について、役割ごとの到達可能な窓口と代替経路を確認する。sovy.cloud を使う古い公開連絡先と異なる連絡先が示される場合は、その変更を正当な組織が承認したことも確かめる。これにより、単発の会話と持続的な運用窓口を分けられる。

施設項目では、五つの PeeringDB 行をそのまま契約別紙へ写すのではなく、対象サービスに使う地点だけを特定する。各地点について、提供機能、運用責任、接続方法、確認日を残し、公開申告と相手方資料が一致するかを見る。公開交換 LAN 行がないことを理由に全接続を否定せず、代わりの接続形態が説明された場合は、その説明を独立に検証できる範囲まで具体化する。

再確認のきっかけも先に決められる。ドメイン、origin AS、プレフィックス、主要連絡先、対象施設の変更は、以前の確認を自動的に現在へ延長できない出来事である。変更通知を受けたとき、契約更新時、重要な障害後には、同じ項目を取り直す。証拠に日付と担当を付ければ、古いスクリーンショットやディレクトリー行だけが審査記録に残り続けることを防げる。

こうした条件は、公開面が薄いことへの罰ではない。買い手が依存するサービスと、相手方が実際に示せる運用面を一致させるための仕組みである。非公開構成には正当な理由があり得るが、非公開であることは説明責任を消さない。秘密情報そのものを公開せずとも、担当主体、確認日、対象範囲、第三者確認の有無を示す方法はある。

どの新しい証拠が評価を引き上げるのか

現時点の弱い評価は固定的な判決ではなく、追加証拠によって更新できる。最も直接的なのは、現在の Sovy ブランドと運用主体を結び付ける入口が確認され、そこから有効な技術・契約連絡先へ到達できることだ。ただし、sovy.cloud が再び名前解決するだけでは十分ではない。誰が登録し、どの組織を代表し、AS401110 または現在のサービス資源とどう結び付くかが必要になる。

ネットワーク面では、AS401110 から新しい経路が継続して観測される、現在のプレフィックスと origin が特定される、隣接関係または公開相互接続面が再び確認される、といった事実が評価を動かす。AS401110 以外の構成を使うなら、その構成が Sovy Cloud Services の対象サービスを担うことを示す連続した証拠が要る。単に過去の経路履歴を再掲しても、現在性は増えない。

施設面では、PeeringDB の五行が更新されること自体より、対象サービスと特定施設の現行関係が確認できることの方が強い。施設名、契約主体、提供機能、確認時点がそろい、可能な範囲で相手方以外の資料とも整合すれば、公開申告は現在の運用証拠へ近づく。プロフィールの文言だけが新しくなり、経路、連絡先、対象サービスとのつながりが示されなければ、評価を大きく上げる理由にはならない。

公開 POC が追加され、ARIN の連絡先検証が回復することも、ガバナンス面の改善材料になる。ただし、それだけでクラウドの可用性や顧客負荷を証明するわけではない。連絡可能性、ネットワーク到達性、施設関係、契約主体は別々に確認し、複数の面が同じ現在を指すかを見る必要がある。

反対に、どの証拠が不足したままかも記録するべきだ。現在のドメイン支配が不明、公開経路が見えない、施設関係が自己申告のまま、責任窓口の連続性が確認できないという状態が続くなら、登録上の active と過去の経路は現在運用の代替にはならない。評価を上げる条件を先に明示しておけば、事業者側にも何を示せばよいかが分かり、調査者側も印象で結論を揺らさずに済む。

判断を、新しい証拠で反証できる形にしておく

デューデリジェンスの結論は、対象へ永続的な評判を貼り付けるためのものではない。観測時点で利用できる証拠から、いま何を信頼できるかを示すためのものである。Sovy Cloud Services について「現在の公開運用証明は弱い」とする判断にも、対象日と根拠の範囲を付ける必要がある。そうすれば、後日の変化を例外扱いせず、通常の更新として受け入れられる。

反証条件は具体的でなければならない。たとえば、正当な組織によるドメイン支配が確認され、公開連絡先が再検証され、現在のサービス資源と AS401110 または別の運用主体との関係が示されれば、公開同一性の評価は変わる。新しい経路が継続して観測され、そのプレフィックスと対象サービスの関係が確かめられれば、現在のネットワーク運用に関する評価も引き上げられる。

逆に、見た目だけの更新では反証にならない。PeeringDB の説明文や施設数が書き換わるだけで、対象サービス、確認日、経路、連絡先とのつながりが示されなければ、現在運用の裏づけは増えていない。sovy.cloud に新しいページが現れても、登録主体と Sovy Cloud Services の連続性が確認できなければ、古いブランドがそのまま戻ったとは判断できない。

このため、調査記録には結果だけでなく、比較可能な最小情報を残す。RDAP と DNS の照会日、AS overview と routing-status の観測時刻、現在プレフィックスと隣接 AS の数、PeeringDB のネットワーク ID と各公開行の有無、ARIN の連絡先注記を同じ基準で保存する。次回は同じ項目を再取得し、増えたもの、消えたもの、主体が変わったものを区別する。

反証可能な判断は、事業者にとっても買い手にとっても公平である。公開面が回復すれば評価を更新でき、回復が説明だけにとどまれば慎重さを維持できる。現在の空白を過去の活動の否定に使わず、過去の活動を現在の保証にも使わないという原則を、将来の検証にもそのまま適用できる。

現時点の評価は「登録あり、履歴あり、現在の公開運用証明は弱い」

Sovy Cloud Services について、公開情報から会社が確実に閉鎖されたとは言えない。PeeringDB に列挙された施設がすべて非稼働だとも、顧客が一社もいないとも言えない。公開経路に見えない私設サービスや、別の連絡面が存在する可能性も排除できない。そのような断定を避けることは、評価を甘くすることではなく、証拠の射程を守ることである。

同時に、現在の運用を肯定する根拠も不足している。ブランドドメインは2026年7月20日に登録可能とされ、三つの DNS 照会経路で NXDOMAIN だった。RIPEstat では AS401110 が未広報で、現在のプレフィックス、RIS 可視性、隣接 AS が確認できない。PeeringDB には五つの施設行が残るが、プレフィックス数、IX 数、公開交換 LAN 行、公開 POC 行は現在の公開運用面を補強していない。

したがって、妥当な評価は「存在しない」でも「稼働中」でもない。登録上の同一性は強く、過去の公開経路活動にも直接の観測証拠がある一方、現在の Sovy ブランドによる顧客向けクラウド面を公開データから立証する力は弱い、というものだ。調達や依存継続の判断では、この弱さを相手方の新しい証拠で埋められるまで、古いディレクトリー情報を現在の運用保証として扱うべきではない。

この事例が教えるのは、登録記録を捨てることではなく、役割を狭く正確にすることだ。ARIN は誰とどの番号資源が結び付いていたかを示し、PeeringDB はどの相互接続・施設関係が申告されていたかを示し、RIPEstat と DNS は観測時点の公開面を照らす。四者が同じ方向を向かないとき、最も新しく、対象に直接近く、第三者が再現できる証拠から判断を組み立てる。それが、残存する登録と現在の運用を混同しないための実務的なデューデリジェンスである。

参照した公開情報