AS60077 が映す Cloud.ir の輪郭 IPv4 経路の先に残る設備経路の空白

Summary

RIPE RDAP と RIPEstat は、Asre Dadeha Asiatech に結び付く AS60077 が現在アナウンスされ、18本の IPv4 プレフィックスと広い RIS 観測範囲を持つことを示す。これは稼働中の経路面を裏付けるが、Cloud.ir の全製品がこの AS を通ることまでは証明しない。
公開観測で確認できた隣接 AS は AS43754 だけであり、その保有者も Asiatech Data Transmission company である。この関係を、組織的にも経路的にも独立した冗長性の証拠として扱うことはできない。
PeeringDB の AS60077 レコードには IX 接続も施設登録もなく、施設名、トラフィック規模、経路ポリシーも開示されていない。これは設備が存在しない証明ではないが、公開情報だけで設備経路や施設分散を立証できないことを意味する。
Cloud.ir の公式サイトはクラウドサーバー、VPS、クラウドデータセンターなどの現行サービス面を示す。しかし、設備・規格に関する自己説明と SLA の広い免責範囲を合わせて読むと、顧客が必要とする容量、独立経路、復旧境界にはなお確認すべき空白が残る。

まず見えるのは会社ではなく経路である

クラウド事業者を調べるとき、サービスページの品ぞろえは最も目に入りやすい。だが、そこで表示される製品名と、インターネット上で実際に観測できる制御面は同じものではない。Cloud.ir が何を販売しているかを読む作業と、どの自律システムがどのアドレスを世界へ広告しているかを確かめる作業は、いったん分ける必要がある。

AS60077 は、その分離を行うための明確な起点になる。RIPE RDAP では、この自律システムは有効な登録として扱われ、名称は AT-CLOUD、登録組織は ORG-ADA42-RIPE / Asre Dadeha Asiatech と記録されている。登録日は2022年6月27日、最終変更日は2026年1月23日である。少なくとも、古いブランド表記だけが検索結果に残っている状態ではない。

RIPEstat の AS 概要も、照会時点の AS60077 を「AT-CLOUD Asre Dadeha Asiatech」とし、2026年7月20日08:00:00のデータでアナウンス中と報告する。登録主体と観測された経路の間には、ここで一つの整合が生まれる。AS 番号、名称、組織、現行アナウンスを別々の公開データから結び付けられるためだ。

ただし、その整合が答えるのは「この AS が公開 BGP で活動しているか」という問いまでである。「Cloud.ir の仮想マシンがすべて AS60077 から配信されるか」「特定の顧客テナントがどの施設を通るか」「障害時にどの経路へ移るか」は別の問いであり、AS 概要の一行からは導けない。経路の存在は、製品ごとの配送経路図ではない。

この区別は形式的な注意ではない。クラウドの調達では、ブランド、契約主体、アドレス資源、物理設備、運用担当が一つの名称の下にまとめて語られやすい。公開資料が示す各層を混ぜると、確かな登録事実が、確認されていない設備能力の保証へとすり替わる。AS60077 は輪郭を与えるが、その輪郭の内側をすべて塗りつぶす証拠ではない。

18本の IPv4 プレフィックスが示す現在地

RIPEstat の routing-status は、AS60077 について18本の IPv4 プレフィックス、合計14,080個の IPv4 アドレスを報告している。RIS の IPv4 観測では325ピア中324ピアがこの AS を見ており、最後に確認されたプレフィックスとして193.151.156.0/24が2026年7月20日16:00:00の時点で示された。観測範囲という意味では、局所的な一地点だけに現れる経路ではない。

announced-prefixes の内訳を見ると、アドレス空間は一つの連続した塊だけではない。78.110.112.0/21に加え、85.198.8.0/22、85.198.12.0/22、85.198.16.0/23、85.198.19.0/24、85.198.20.0/23、85.198.22.0/23が並ぶ。さらに193.151.128.0/22から193.151.152.0/22までの複数ブロックと、193.151.156.0/24から193.151.159.0/24までの小さなブロックが観測される。

この構成は、AS60077 が単一の試験用プレフィックスだけを一時的に広告しているのではなく、複数の IPv4 範囲を現在の経路面に載せていることを示す。bgp.tools も、Asre Dadeha Asiatech の AS60077 を稼働中のネットワークとして要約し、18本の IPv4 起源プレフィックスと Server Hosting のタグを掲げている。別の公開ビューでも本数が一致する点は、現行性を判断する補助材料になる。

それでも、プレフィックス数をそのままサーバー台数、販売可能な仮想 CPU、ストレージ容量、利用企業数へ換算することはできない。IP アドレスは経路資源であって、計算資源や電力余力の単位ではない。14,080個という数字が具体的であるほど、別種の容量まで測ったように見えやすいが、実際に数えている対象は IPv4 アドレスである。

また、324の RIS ピアから見えることは、広い BGP 可視性を示す一方、個々の顧客通信が同じ品質で到達することを保証しない。経路選択は送信元、上流事業者、ポリシー、障害状態によって変わる。コレクターからの可視性は重要な運用信号だが、遅延、損失、輻輳、顧客別の経路、設備内のボトルネックを直接測定するものではない。

ここで確実に言えるのは、AS60077 に現在の IPv4 経路面があり、その面が多数の観測点から見えていることだ。言えないのは、その経路面の背後にどれだけの顧客向け余力があり、どの設備と回線が、どのサービス階層に割り当てられているかである。公開データの強さは、対象を限定して読むほど高くなる。

193.151.156.0/24からたどれる管理の連鎖

経路の存在だけでなく、アドレスの管理と起源承認を確かめるには、特定プレフィックスを深く見る方がよい。193.151.156.0/24について、RIPEstat の RPKI 検証は valid を返し、origin 60077を許可する ROA が検証に使われている。少なくともこのサンプルでは、観測された起源 AS と RPKI 上の承認が一致する。

RIPE RDAP で同じ193.151.156.0/24を照会すると、IR-AT-20210316 という有効な assigned PA 範囲に解決される。国コードは IR で、範囲は193.151.128.0から193.151.158.255までとされ、ASIATECH-MNT、Asiatech NOC の管理・技術連絡先が付いている。経路、RPKI、アドレス登録、運用連絡先を一つの例で連結できる点は有用である。

この連鎖が示すのは、193.151.156.0/24というアドレス範囲について、公開登録上の管理経路と BGP 起源の整合を確認できることだ。誤った起源 AS からの広告が検証上有効になる、という状態ではない。顧客や監視担当者がインターネット資源の来歴を調べる際には、ブランド説明よりも具体性の高い手掛かりになる。

しかし、RPKI の valid は可用性評価ではない。設備の電源が二重化されていること、回線が物理的に分離されていること、DDoS 時に十分な処理能力があること、障害後にデータが所定時間内に復旧することを保証しない。RPKI が答えるのは、主として「このプレフィックスをこの起源 AS が広告することは承認されているか」という問いである。

さらに、この検証結果は193.151.156.0/24という一つのサンプルに結び付いている。18本すべてのプレフィックスについて同じ状態だと一般化するには、各経路を個別に確認する必要がある。IR-AT-20210316 の範囲も、AS60077 が広告する全アドレス空間を一括して説明するものではない。部分的に強い証拠を、全体の保証へ拡張してはならない。

この点で AS60077 の公開情報は、入口としては良好である。登録主体、経路観測、RPKI の一例、連絡先が互いに大きく矛盾しない。ただし、ネットワーク資源の管理が確認できることと、顧客のワークロードを支える物理・論理基盤の全構成が開示されていることの間には、まだ大きな距離がある。

Whois の意図と BGP の観測は同じではない

RIPEstat の routing consistency は、AS60077 が BGP で広告している IPv4 プレフィックスが RIPE Whois にも存在することを示す。経路面に突然現れた未登録の範囲というより、登録情報と観測情報が対応している。一方で、Whois には記載されているが BGP では見えない、より広い範囲や構成要素となる範囲もある。

この差は異常を意味するとは限らない。登録データは、割り当て、経路ポリシー、将来または条件付きの関係を含み得るが、BGP 観測は特定時点に実際に見えたアナウンスを表す。大きな範囲を小さなプレフィックスに分けて広告する場合もあれば、登録済みの範囲を常時は広告しない場合もある。二つのデータセットは、同じ現実を異なる角度から切り取る。

隣接関係にも同じ注意が必要だ。AS43754 は、BGP と Whois の双方で import/export の相手として現れる。これに対し、AS212895 は Whois の import 情報にはあるが、今回の BGP 観測には現れない。設定や登録上の関係を、そのまま現行の転送経路と見なせないことが、この差から分かる。

AS212895 が観測されなかった理由は、この資料だけでは特定できない。現在使われていないのか、条件付きなのか、観測点から見えないのか、登録が現状を十分に反映していないのかは分からない。したがって「第二の上流が存在しない」と断定する材料にも、「冗長経路として利用できる」と肯定する材料にもならない。

公開ルーティング調査で重要なのは、登録された意図と観測された状態を区別することだ。前者だけなら紙上の関係を過大評価しやすく、後者だけなら私設接続や条件付き経路を見落としやすい。今回の安全な読み方は、AS43754 には両方の裏付けがあり、AS212895 には Whois 側の痕跡だけがある、という限定的なものになる。

IPv6 を「ない」と言い切れない理由

2026年7月20日の routing-status では、AS60077 が現在起源として見せている IPv6 プレフィックスはゼロである。RIS の IPv6 観測も321ピア中ゼロで、bgp.tools の要約も IPv6 起源プレフィックスをゼロとしている。照会時点の公開経路面は、明確に IPv4 中心だった。

ただし、announced-prefixes には2a05:1a30::/34が2026年7月13日の一つのタイムスタンプで現れている。継続的な現行広告として routing-status に残ってはいないが、過去の一瞬を含めれば、観測記録が完全に空というわけでもない。このため「AS60077 には IPv6 サービスが存在しない」と結論づけるのは強すぎる。

一つのタイムスタンプは、試験、短時間の広告、観測上の一過性、運用変更など複数の可能性を残す。どれであったかを示す追加資料はない。逆に、この一件を根拠に「IPv6 対応済み」と評価することもできない。顧客向けに継続提供され、サポートされ、SLA の対象になることは、経路が一度見えたこととは別の条件である。

調達側にとって必要なのは、二値のラベルよりも時点を伴う質問だ。現在、どの製品で IPv6 を提供しているのか。顧客へ割り当てられるのか。外部到達性、セキュリティ制御、監視、障害対応は IPv4 と同等なのか。公開経路データは、その質問を発生させる根拠にはなるが、回答そのものではない。

ここでも、欠けた観測を欠けた機能と同一視しない姿勢が必要になる。公開 BGP に現れない私設用途や将来計画はあり得る。しかし、公開されていない可能性を持ち出して現行能力を肯定することもできない。現時点で裏付けられる表現は、「現在見える起源経路は IPv4 であり、継続する IPv6 起源は確認できない」である。

唯一観測された AS43754 をどう読むか

RIPEstat の routing-status は、AS60077 について観測された隣接 AS を一つと報告する。asn-neighbours が返すその相手は AS43754 である。RIPEstat と RIPE RDAP では、AS43754 も有効な自律システムで、保有者は Asiatech Data Transmission company とされる。bgp.tools も AS43754 を AS60077 の上流として表示する。

この結果は、公開観測上の主要な外部到達経路を理解するうえで重要だ。AS60077 が完全に孤立しているわけではなく、AS43754 との関係を通じてより広いインターネットへ接続している様子が見える。同時に、その相手は名称上も Asiatech の組織圏と結び付いている。

したがって、AS43754 を「独立した第二事業者による冗長回線」と呼ぶことはできない。独立性には、別法人、別契約、別設備、別導管、別の障害領域といった複数の意味があるが、公開資料はそれらを立証していない。AS 番号が二つあるだけでは、共通原因障害からの分離は分からない。

一方、「観測隣接が一つだから物理回線も一本しかない」と断定するのも誤りである。同じ AS 間に複数の物理接続があり得るほか、私設接続、バックアップ経路、コレクターに見えにくいポリシーが存在する可能性もある。BGP 上の隣接 AS 数は、ケーブル本数や施設数を数える指標ではない。

ここから得られる結論は非対称である。公開記録は AS43754 への依存関係を積極的に示しているが、そこから独立した上流冗長性を確認することはできない。追加の上流や物理分離が実在する可能性は否定しないものの、顧客がそれを前提にリスク評価するには、別の証拠が要る。

クラウド事業では、同一企業群内のネットワーク統合が運用効率を高める場合がある。だが効率と障害領域の独立性は同義ではない。AS60077 と AS43754 の関係を評価する際は、「連携していること」と「相互に独立していること」を分け、後者については未確認とするのが妥当である。

PeeringDB の空欄は欠如の証明ではない

PeeringDB には ASN 60077の現行ネットワークレコードがあり、名称は Asre Dadeha Asiatech、status と rir_status はいずれも ok である。しかし、そのレコードは ix_count=0、fac_count=0で、ウェブサイト、looking glass、route server、経路ポリシーURL も掲載していない。トラフィック量や地理的スコープも開示されていない。

この情報を読む際、二つの誤りが起きやすい。一つは、施設登録がゼロだから物理施設を一切使っていないと推論することだ。PeeringDB への登録は事業者自身の開示や更新に依存し、すべての接続や拠点を網羅する台帳ではない。非公開接続や未登録施設の存在までは否定できない。

もう一つは、レコードの status が ok だから、施設分散やピアリング品質まで確認済みだと考えることだ。ok はレコードの状態を示すが、顧客トラフィック、設備所有、稼働率、契約上の可用性を監査した印ではない。rir_status が ok であることも、登録機関側の状態との整合を示すにとどまる。

それでも、空欄には調査上の意味がある。AS60077 を特定のインターネット交換点やデータセンターへ結び付ける公開自己申告が、PeeringDB からは得られないという意味だ。経路は広く見えるのに、その経路がどこで接続され、どの都市や施設に分散しているかを説明する公開面が薄い。

このため、PeeringDB は否定証拠ではなく、立証の不足を示す資料として使うべきである。「施設がない」ではなく「この公開レコードでは施設を確認できない」、「ピアリングしていない」ではなく「公開 IX 接続を確認できない」と表現すれば、データの限界を保ったまま判断材料にできる。

顧客が施設経路を重視するなら、別の形の証拠が必要になる。例えば、サービス別の提供拠点、外部キャリアとの接続点、障害領域の分け方、拠点間複製の条件を、契約資料や技術資料で確認することだ。公開レコードの空白を憶測で埋めるのではなく、確認項目へ変換する方が実務的である。

Cloud.ir の顧客向けサービス面は現在も見える

ネットワーク登録の調査だけでは、現在顧客に何が提示されているかは分からない。そこで Cloud.ir の公式面を見ると、cloud.ir は HTTPS で到達でき、ホームページとサービスサイトマップは、複数の現行サービスを案内している。経路データとは別に、顧客が接触できる商用サービス面が存在する。

案内されているのは、クラウドサーバー、VPS、クラウドデータセンターだけではない。クラウドスイッチ、クラウドドメイン管理、CDN、クラウドストレージに対応するページもあり、主要サービスページのサイトマップ上の最終更新日は2025年から2026年に分布する。少なくとも、長期間放置された単一製品ページだけではない。

公式の about ページとサービスページは、クラウドサービスの開始をイラン暦1399年とし、20を超えるクラウド製品を提供すると説明する。また、イラン国内の Asiatech データセンター上で運用すると述べている。これは事業者が自ら示すサービスの由来と運用上の位置付けである。

この自己説明は、ブランドと Asiatech の関係を理解するうえで価値がある。CLOUD Asre Dadeha Asiatech というディレクトリ上の主体、Asre Dadeha Asiatech という AS 登録、Cloud.ir という顧客向け名称が、無関係な三つの断片ではないことを示唆する。公開ページと登録データの間には、合理的なつながりがある。

ただし、そのつながりは、Cloud.ir の全サービス通信が必ず AS60077 を起源または通過点とすることの証明ではない。CDN、ストレージ、管理画面、名前解決、決済、サポートなどは、それぞれ異なる外部依存やネットワーク経路を持ち得る。製品一覧と AS 一覧を一対一で対応させる資料は、この公開情報にはない。

公式 contact ページが存在し、販売・支援への接点が示されることも、現行サービス面の一部である。しかし、連絡窓口の存在から顧客数、売上規模、応答時間、技術支援の品質を推定することはできない。現在アクセス可能な窓口と、実際の運用成果は分けて評価する必要がある。

ここまでの証拠を合わせると、Cloud.ir を単なる休眠ブランドと見る理由は乏しい。公開サイトは動き、サービスページは更新され、AS60077 は IPv4 経路を広告している。だが「事業が見える」という結論と、「事業の全配送経路と能力が立証された」という結論の間には、なお明確な境界がある。

データセンターに関する自己説明の位置付け

Cloud.ir は、Asiatech のデータセンターを利用することに加え、ISO27001、TIA-942、Tier 2/3に相当する説明を公式ページで掲げている。これらは、運用者がどのような品質や設計思想を顧客へ伝えようとしているかを知る資料になる。事業者の主張として無視すべき情報ではない。

一方、今回の公開資料には、独立機関が発行した証明書、対象施設の正確な一覧、認証の適用範囲、有効期間を突き合わせる証拠が含まれていない。TIA-942 や Tier 表現についても、どの建物のどの設備が、どの版または評価手続きに基づくのかまでは確認できない。したがって、独立検証済みの認証として扱うことはできない。

施設の位置や設計についても同様である。イラン国内の Asiatech データセンターで動くという公式説明はあるが、AS60077 の各プレフィックスがどの施設から広告されるのか、顧客サービスごとにどの設備へ収容されるのか、施設間でどのように切り替わるのかは公開資料から分からない。

電力、冷却、予備電源、保守体制、構内配線、外部回線の引き込み経路についても、検証可能な構成や実測値は示されていない。顧客が実際に利用できる計算・ストレージ容量と、障害時に残る予備余力も不明である。「データセンターを使う」という説明は、そこで提供できる量と復旧能力を自動的には表さない。

施設経路を立証するには、経路データとは異なる証拠が必要だ。AS 番号は論理的なルーティング主体を示すが、建物、電源系統、回線経路、運用チームの分離を表現する識別子ではない。同じ AS から複数施設が広告することも、一施設だけから広告することもあり得る。

したがって、公式ページの主張を退ける必要はないが、証拠の種類を明示すべきである。「Cloud.ir がそう説明している」と「第三者資料で施設と能力を確認できる」は別の文で書かれなければならない。この区別を保つことで、自己説明を有用な手掛かりとして使いながら、確認されていない強度を付け加えずに済む。

SLA は可用性より先に責任の境界を示す

Cloud.ir の SLA ページは、通常運用下のネットワークとクラウドサーバーの可用性を保証の中心に置いている。同時に、適用外となる条件を幅広く列挙している。サービスの強さを理解するには、可用性を掲げる文だけでなく、どの事象が計算や補償の対象から外れるかを読む必要がある。

除外対象には、顧客のソフトウェア、オペレーティングシステム、設定に起因する問題が含まれる。これは、仮想基盤が動いていても、顧客アプリケーションが利用不能なら必ずしも同じ障害として扱われないことを意味する。クラウド利用者にとっての「使えない」と、事業者が測る「基盤の停止」は一致しない場合がある。

DoS 攻撃、サービス停止措置、保守、重大なパッチ適用も除外に含まれる。これらは運用上起こり得る事象だが、SLA 上の扱いが通常障害と異なるなら、表面上の可用性率だけでは実際の利用不能時間を説明しきれない。計画停止と緊急対応をどのように通知し、どの単位で計測するかが重要になる。

不可抗力、顧客機器の故障、顧客が依頼した停止、未払いも対象外とされる。さらに、法的またはセキュリティ上の命令による停止も除外される。原因の所在、契約状態、規制対応によって、同じ利用不能でも責任の分類が変わる構造である。

ここで注意すべきなのは、免責があるから SLA に価値がないと結論づけることではない。除外条件は多くのサービス契約に必要であり、責任分界を明確にする役割がある。問題は、マーケティング上の高可用性という言葉を、除外後の保証範囲を確認せずに顧客体験全体へ拡張することだ。

Cloud.ir のサービスページが述べるデータ持続性、高可用性、途切れない接続に関する表現は、この SLA 境界と一緒に読む必要がある。通常運用のネットワークが利用可能であることと、攻撃、保守、重大パッチ、法的措置を含むあらゆる中断から顧客を保護することは同じではない。

また、公開された SLA からは、個別顧客の復旧順序、データ復元の手順、復旧時点、代替施設への切り替え動作までは分からない。停止時間の定義と、サービスを元の整合した状態へ戻す能力は別の評価軸である。可用性の契約は、復旧設計の完全な説明書ではない。

経路、設備、製品、契約を四層に分ける

AS60077 をめぐる公開情報は、四つの層に分けると読みやすい。第一は登録と経路の層である。ここでは RIPE RDAP、RIPEstat、RPKI、bgp.tools が、主体、IPv4 プレフィックス、観測可視性、起源承認の一例を比較的具体的に示している。

第二は相互接続と設備の層である。公開観測では AS43754 との関係が見えるが、独立した複数上流、IX 接続、施設登録、物理分離は確認できない。PeeringDB の空欄は可能性を否定しないものの、この層を肯定的に埋める証拠も提供しない。

第三は製品の層である。Cloud.ir の公式サイトから、クラウドサーバー、VPS、クラウドデータセンター、CDN、ストレージなどの顧客向け表面を確認できる。だが、各製品を AS60077 のプレフィックス、特定施設、特定上流へ対応付ける公開構成図はない。

第四は契約と回復の層である。SLA は通常運用下の可用性と多くの除外条件を示すが、障害領域ごとの復旧動作、顧客データの回復境界、独立施設への切り替えを立証しない。サービスが販売されていることと、最悪時の動作が開示されていることは別である。

この四層のうち、公開証拠が最も厚いのは第一層だ。第三層には公式な製品説明があり、第四層には少なくとも SLA 上の境界がある。最も薄いのは、論理経路を物理施設と独立した障害領域へ結び付ける第二層である。その薄さが、本稿の中心的な不確実性になる。

層を分ければ、ある事実の価値を過小評価せずに済む。18本の IPv4 経路や RPKI valid のサンプルは重要であり、無意味ではない。同時に、それを根拠に施設の耐障害性まで主張する必要もない。強い証拠を本来の範囲で使うことが、全体の分析を強くする。

顧客が使える容量は IP アドレスからは読めない

Cloud.ir が20を超える製品を案内していることと、それぞれに十分な提供余力があることは別問題である。製品の存在は選択肢を示すが、在庫、オーバーコミット、ストレージ性能、ネットワーク帯域、電力余力、障害時の予備資源までは示さない。

AS60077 の14,080個の IPv4 アドレスも、容量の代理指標にはなりにくい。一つのアドレスで多数のサービスを収容することも、顧客へ複数アドレスを割り当てることもできる。未使用、予約、内部用途の比率も分からない。アドレス数と収容可能なワークロード数の間に、公開された換算式はない。

顧客にとって重要なのは、平常時の総設備量より、必要な場所と時間に確保できる余力である。通常時に注文できても、大規模障害や需要急増時に代替資源が不足すれば、復旧の選択肢は狭くなる。今回の資料は、その予備余力や優先順位を数量で示していない。

ホスティング経済の観点では、設備を高い利用率で運用することは価格競争力につながり得る一方、余力をどれだけ持つかは回復能力とトレードオフになり得る。だが、Cloud.ir が実際にどの程度のオーバーコミットや予備容量を採用しているかは不明であり、一般論を同社の運用事実として当てはめることはできない。

したがって、公開情報から導けるのは「顧客向けの製品面と IPv4 資源面がある」というところまでだ。「顧客が必要な時に利用できる容量が十分である」という判断には、サービス別の上限、在庫、増設時間、障害時の予約方針など、別の情報が必要になる。

この不足は、Cloud.ir が容量を持たないことを意味しない。単に、現在の20件の公開情報では、顧客が使える容量を検証できる粒度に達していないということだ。不確実性は否定ではなく、判断に必要な証拠がどこにないかを示すラベルである。

復旧能力は平常時の到達性から推定できない

平常時に AS60077 が広く見えることは、障害前の状態を示す。復旧能力を評価するには、障害が発生した後に何が起きるかを知る必要がある。経路を別施設から再広告するのか、顧客データをどこから戻すのか、依存サービスをどの順で再開するのかは、通常時の BGP スナップショットには現れない。

唯一観測された隣接 AS が AS43754 であることも、障害時の挙動を決めるには情報が足りない。同じ AS 間に複数の物理経路があれば一部障害へ耐えられるかもしれないが、共通設備や共通運用に依存していれば同時に影響を受けるかもしれない。どちらの構成かは公開記録から判別できない。

Cloud.ir のクラウドデータセンター説明に冗長性や可用性の主張があっても、実際の切り替え条件、データ整合性、復旧優先度を独立資料で確認できなければ、回復の境界は残る。SLA の除外条件は、特に保守、重大パッチ、攻撃、不可抗力の場面で、通常時保証がそのまま適用されない可能性を示す。

復旧を評価する質問は、単なる「バックアップはあるか」では足りない。バックアップが同じ障害領域にないか、復元試験は行われているか、顧客が復元を開始できるか、サービス間の依存順序はどうか、ネットワークが戻る前後でデータ整合性をどう扱うか、といった運用の具体性が要る。

今回の資料は、これらの問いに否定的な回答を与えているのではない。回答を与えていない。ここを取り違えると、証拠不足を欠陥の断定に変えてしまう。逆に、公式の高可用性表現だけで回答済みと扱えば、未確認の復旧動作を保証として読み込むことになる。

安全な評価は、現在の IPv4 到達性を運用のプラス材料として認めつつ、障害時の施設切り替え、経路切り替え、容量再配分、データ復元については追加確認事項として残すことだ。平常時の可視性と異常時の回復は、連続していても同一の能力ではない。

公開証拠が支える評価と支えない評価

公開証拠が強く支える第一の評価は、AS60077 が登録上も観測上も現行の IPv4 ネットワークであることだ。AT-CLOUD という名称、ORG-ADA42-RIPE / Asre Dadeha Asiatech という主体、18本のプレフィックス、広い RIS 可視性が同じ方向を向いている。

第二に、193.151.156.0/24では、RIPE RDAP の管理範囲、ASIATECH-MNT と Asiatech NOC の連絡先、RPKI 上の origin 60077承認を結び付けられる。これは、少なくとも一つの現行経路について、資源管理と起源承認を追跡できることを示す。

第三に、Cloud.ir には現在アクセス可能な顧客向けサイトと複数のサービスページがある。クラウドサーバーや VPS だけでなく、CDN、ストレージなどを含む製品面を公式に確認できる。SLA ページも存在し、事業者が責任範囲を公表している。

反対に、公開証拠が支えないのは、AS60077 と全製品経路の一対一対応である。ある製品が別のネットワークや外部依存を使う可能性を排除できない。また、PeeringDB に施設情報がないため、プレフィックスを正確な提供施設へ割り当てることもできない。

独立した上流冗長性も確認できない。AS43754 は観測されるが、Asiatech Data Transmission company との関係を考えると、組織的に独立した代替経路の証拠にはならない。AS212895 は Whois の import 情報に現れるだけで、今回の BGP 観測から現行利用を裏付けられない。

顧客向け容量と復旧能力も、数値または手順としては確認できない。公式な設備説明や規格表現はあるものの、独立検証、対象範囲、施設経路、予備余力、回復動作の公開証拠が不足する。この評価は、能力がないという主張ではなく、公開情報から立証できる範囲の線引きである。

追加確認は四つの空白に集中できる

第一の空白は施設経路である。顧客のワークロードが置かれる施設、AS60077 の各プレフィックスが広告される場所、外部回線が接続する場所を対応付けられれば、論理経路と物理的な障害領域の関係が見える。現在の公開資料では、その対応表がない。

第二は独立した上流である。必要なのは AS 番号の数だけではなく、契約主体、物理経路、接続設備、障害時の選択方針がどこまで分離されているかだ。AS43754 以外の現行経路があるなら、その観測または技術説明が冗長性評価を前進させる。

第三は顧客が使える容量である。総設備の説明ではなく、製品別の提供余力、増設に要する時間、帯域制約、ストレージ性能、障害時に確保される予備資源が必要になる。IPv4 アドレス数や製品数では、この空白を埋められない。

第四は回復境界である。SLA が通常運用と除外条件を示している以上、保守、攻撃、重大パッチ、不可抗力などの場面で、通知、切り替え、復元、顧客支援がどう進むかを確認する必要がある。利用不能の計測と、サービスを正常状態へ戻す手順は分けて問うべきだ。

これらの情報が非公開の顧客資料や契約交渉で提供されている可能性はある。公開資料にないことは、事業者が内部に持っていないことを意味しない。だが、公開情報だけで比較や監視を行う読者にとっては、確認できない項目として残る。

追加確認の目的は、Cloud.ir を一律に高リスクまたは低リスクへ分類することではない。どの主張が公開証拠で支えられ、どの主張が事業者説明に依存し、どの判断が顧客自身の検証を必要とするかを分けることにある。その分解が、調達と継続監視の精度を上げる。

一日のスナップショットを監視基準へ変える

今回の経路データには、2026年7月20日という明確な観測時点がある。AS60077 がアナウンス中であること、18本の IPv4 プレフィックス、14,080個の IPv4 アドレス、325の RIS IPv4 ピアのうち324から見えることは、その時点の基準線として残せる。将来の観測をこの基準線と比較すれば、公開面に変化が起きたかを具体的に追跡できる。

基準線の価値は、現在の数字を恒久的な性質と見なすことではない。BGP 経路は運用変更、障害、集約方針、観測網の変化によって増減する。例えば、プレフィックス数が減っても、より大きな範囲への集約なら到達性が失われたとは限らない。逆に、本数が同じでも観測ピアが大きく減れば、別の問題を疑う必要がある。

隣接 AS の監視にも同じ原則が当てはまる。現在の公開観測では AS43754 だけだが、将来別の隣接 AS が現れれば、経路ポリシーが変化した可能性を示す。ただし、新しい AS 番号が見えただけで物理的に独立した冗長性が完成したとは言えない。継続性、方向、施設分離、実際のフェイルオーバーを別途確かめる必要がある。

IPv6 については、現在のゼロという状態と、2a05:1a30::/34が一度だけ見えた履歴の両方を基準にできる。今後、同じプレフィックスまたは別の IPv6 範囲が継続して複数観測点から見えるようになれば、現行起源の評価は変わる。それでも、顧客提供、サポート、SLA 対象まで確認するにはサービス側の証拠が要る。

RPKI も一回の valid 判定で監視を終える対象ではない。193.151.156.0/24の検証結果は強いサンプルだが、ROA や経路は変更され得る。18本の現行プレフィックスについて状態を定期的に比較すれば、登録された起源と観測起源のずれを早く見つけられる。ただし、その監視は設備障害や容量不足を検出する代替手段にはならない。

PeeringDB のレコードは、現在の空欄そのものを基準線として扱える。将来、施設、IX、looking glass、ポリシー、トラフィック範囲が追加されれば、公開透明性が高まったと評価できる。ただし、追加された自己申告を独立監査と同一視せず、施設や交換点側の資料、実際の経路観測と照合する必要がある。

Cloud.ir のサービスサイトマップも、商用面の変化を追うには有用である。新しい製品ページ、更新日の変化、既存ページの消失は、顧客向けポートフォリオの動きを示し得る。だが、ページ更新は設備増強の証明ではなく、更新がないこともサービス停止の証明ではない。商用面とネットワーク面は、並行して監視して初めて意味を持つ。

SLA の変更は、経路変更とは異なる種類の重要な信号になる。除外条件、対象サービス、停止の定義が変われば、同じ技術構成でも顧客が負うリスクの境界は変わる。可用性監視では、到達性の数字だけでなく、契約文面がどの時点でどの範囲を約束していたかを残す必要がある。

こうした継続監視では、一つの変化から原因を即断しないことが重要だ。RIS の観測減少は AS60077 側だけでなくコレクター側の事情でも起こり得る。ウェブページの一時的な不達も、製品基盤全体の停止とは限らない。複数の独立した信号が同じ方向へ動いたときに、初めて評価の強度が上がる。

現在の公開情報は、将来の比較に使えるだけの具体性を持つ。だからこそ、現状を最終判定として固定するのではなく、日時を伴う基準線として扱うべきである。AS60077 の可視性、AS43754 との関係、IPv6 の不在、PeeringDB の空欄、Cloud.ir の製品面、SLA の境界を別々に記録すれば、どの層が変わったかを見失わずに済む。

どの追加証拠なら結論が変わるのか

不確実性を列挙するだけでは、評価は前へ進まない。重要なのは、どの証拠が得られれば、どの結論を強められるかを明確にすることだ。AS60077 については、既に登録と IPv4 経路の基準があるため、次に必要なのは同じ事実の言い換えではなく、経路と設備、製品、回復を結ぶ資料である。

施設名と所在地だけでは十分ではない。各施設でどのプレフィックスを広告し、どのサービスを収容し、どの外部回線へ接続するかが対応付けば、設備経路の空白は小さくなる。さらに、電源や回線の障害領域が施設間でどう分離されているかを確認できれば、単なる複数拠点と実効的な分散を区別できる。

上流冗長性について結論を強めるには、AS43754 以外の経路があるという記述だけでなく、通常時と障害時の利用方法が必要になる。別の上流が継続して観測され、異なる接続設備や物理経路を使い、実際の切り替え試験が示されれば、独立性の評価は現在より強くなる。

容量については、製品数やアドレス数ではなく、顧客へ割り当て可能な資源と予備余力の指標が必要だ。サービス別の上限、増設時間、帯域の設計値と実績、障害時に確保される余力が示されれば、Cloud.ir の販売面と実行面をより直接に結び付けられる。

回復については、復元試験、切り替え試験、顧客通知、依存サービスの再開順序が証拠になる。SLA の可用性計算に加えて、どの障害で何をどこまで戻すのかが示されれば、免責範囲の確認だけでは届かなかった運用境界を評価できる。

反対に、現在と同じ種類のマーケティング文言が増えるだけでは、結論は大きく変わらない。高可用性、標準準拠、冗長設計という言葉は方向性を示すが、対象、時点、測定方法、責任主体が結び付かなければ検証可能性は増えない。必要なのは強い形容詞ではなく、層をまたぐ対応関係である。

この評価枠組みは、事業者に完全公開を求めるものではない。安全上または競争上、詳細を公開できない情報はあり得る。その場合でも、顧客向けの検証資料、契約上の表明、第三者監査など、公開ページとは別の方法で判断の強度を上げられる。公開情報だけを使う本稿では、その追加資料を確認できていないという位置にとどめる。

結論が変わり得る条件を示しておけば、現在の不確実性を固定的な評価にしなくて済む。設備経路、独立上流、利用可能容量、回復動作の証拠が加われば、AS60077 から見える輪郭はより立体的になる。逆に、経路可視性だけが増えても、物理・契約上の空白は自動的には埋まらない。

経路の透明性を設備の透明性と混同しない

AS60077 は、Cloud.ir を調べる際の有力な観測窓である。登録主体は明確で、IPv4 アナウンスは現行で、RIS からの可視性は広い。特定プレフィックスでは RPKI と RDAP の連鎖も追える。公開インターネット上の存在を評価する材料としては具体的だ。

その一方、同じ窓から施設の内部までは見えない。PeeringDB には施設・IX の開示がなく、観測隣接は AS43754 だけで、Cloud.ir のサービスページは各製品の配送経路を示さない。公式のデータセンター・規格説明も、今回の資料では独立検証されていない。

この非対称性こそが重要である。経路面が明確だからこそ、設備面も同じ程度に明確だと感じやすい。しかし、BGP は到達性を表し、施設証拠は障害領域を表し、SLA は契約上の責任を表す。それぞれが別の問いに答える。

Cloud.ir について安全に言えるのは、顧客向けサービス面と現在の IPv4 経路面がともに存在し、Asre Dadeha Asiatech との関係を公開資料から追えることだ。安全に言えないのは、正確な施設経路、独立した複数上流、顧客が利用できる容量、障害時の回復動作が公開証拠で完全に立証されたということだ。

したがって、AS60077 の価値は「すべてを証明する識別子」であることではない。何が観測でき、どこから先が未確認かを切り分ける基準点であることにある。公開経路の確かさを認めながら、設備・容量・回復については証拠を追加で求める。その読み方が、Cloud.ir の輪郭を最も正確に保つ。