Summary

  • AFLY CLOUD LLC の現行公式サイトは、米国西部、ドイツ、フィンランドを選択肢に含む VPS、クラウドサーバー、専用サーバーの販売面を示すが、設備の所有、実際の収容先、規模、運用品質を独立に証明するものではない。
  • 公開ネットワーク面では、AS63101 と IPv6 プレフィックス2602:f824::/48、2602:f824:1::/48を複数の第三者ページで確認できる。ただし、経路の可視性は利用量、顧客、容量、物理所在地、私的な接続関係を示さない。
  • 購入者が確かめるべきなのは地域名の数ではなく、契約するサービスがどのアドレス資源と経路を使い、データ、バックアップ、管理アクセス、障害対応、退出時の移送がどの法域と事業者に依存するかである。

AFLY CLOUD LLC のディレクトリ項目

販売画面が示すのは、サービスの約束である

AFLY CLOUD LLC の公式サイトは、同社を高性能 VPS と専用サーバーのグローバルな提供者として位置づけている。画面には Cloud Servers、VPS、Dedicated Servers、Colocation といった製品名が並び、ロケーションの選択肢として US West、Germany、Finland が表示される。短時間での VPS 展開、root 権限、複数地域、管理画面、技術支援なども訴求されており、購入希望者が最初に接するサービスの入口は明瞭だ。

しかし、ここで読めるのは、あくまで事業者が現在どのような商品を売り、どのような価値を約束しているかである。低遅延、高可用、堅牢なセキュリティ、企業向けハードウェアといった表現は、比較項目を見つける手掛かりにはなるが、測定結果や監査記録ではない。ページに地域名があることも、その地域で利用できる商品が掲示されていることを示す一方、サーバーを収容する建物の運営者、機器の所有者、回線の調達形態までは説明しない。

今回参照できる AFLY 自身の現行資料は、この公式サイト一つだけである。残る七つは、公開されている ASN、IP アドレス、プレフィックスの可視性を整理する第三者ページだ。この構成は、企業の販売面を理解するには十分な出発点になるが、運用の深さを評価するには薄い。顧客、所有関係、従業員、正確なデータセンター運営者、物理設備、私的なピアリング、収容能力、稼働実績、認証、サービス品質について、本稿の資料は検証可能な根拠を与えていない。分からない項目を肯定にも否定にも読み替えないことが重要である。

クラウドの購入では、説明の魅力と証拠の強さを同じ尺度で扱いがちだ。価格、地域名、導入の速さは画面上で比較しやすい。それに対し、障害時の責任、データの複製先、上流への依存、解約時の搬出方法は、短い商品説明には収まりにくい。AFLY を読む作業は、この見えやすさの差を埋めることから始まる。

AS63101 は会社の存在をネットワーク面へ結び付ける

IPinfo の AS63101 ページは、AS63101 の名称を AFLY CLOUD LLC、国を米国、種別を Hosting、関連ウェブサイトを aflycloud.com として表示する。レジストリは ARIN とされ、割り当てと更新の日付はいずれも2024年8月30日と記載されている。これは、公式サイトのブランド名とは別に、公開ネットワーク情報の中で同じ社名とドメインが AS63101 へ結び付けられていることを示す。

ASN は、共通の経路制御方針の下でプレフィックスを外部へ知らせる際の識別子である。したがって AS63101 が見えることには、単なる会社名検索とは異なる意味がある。少なくとも、AFLY CLOUD LLC という名称に関連するネットワーク上の識別点を、第三者の観測画面から追跡できるからだ。購入者は、提示された接続先 IP がこの AS へ結び付くか、経路がどのように見えるかを調べる入口を得る。

ただし、ASN は会社全体の能力を数値化する格付けではない。AS 番号が存在しても、どの製品がその AS を使うのか、全通信がそこを通るのか、上流障害への備えがどうなっているのかは分からない。IPinfo の画面も第三者の検索結果であり、取得された表示では WHOIS の詳細が伏せられている。公式レジストリそのものの代わりとして法的主体や資源保有を最終確認する用途には向かない。

ここで得られる最も堅実な結論は狭い。AFLY CLOUD LLC は、公開検索上、米国に関連付けられたホスティング種別の AS63101 と結び付いている。それ以上の規模、収益、利用企業、技術力を ASN から推定することはできない。ネットワークの識別点が見えることと、サービスの実力が分かることの間には、なお大きな距離がある。

二つの IPv6 プレフィックスが作る、観測可能な輪郭

Hurricane Electric の AS63101 ページは、AFLY CLOUD LLC、Country of Origin を米国とする表示、会社サイトへの参照に加え、観測されたプレフィックスを示している。2026年7月20日付の画面では、起点として観測されたプレフィックスも、広告されたプレフィックスも合計二つで、いずれも IPv6 だった。同じ画面で IPv4 はゼロ、RPKI 上で起点が Valid と判定されたものは IPv6 の二件と表示されている。

その二件は、2602:f824::/48のプレフィックスページ2602:f824:1::/48のプレフィックスページで個別に追える。両ページは、起点を AS63101、名称を AFLY CLOUD LLC として表示し、より大きな2602:f824::/36について、ARIN、allocated、US という一致する委任文脈を示す。route6 の表示には、前者について2024年9月3日、後者について2025年2月7日の作成・最終変更時刻も記載されている。

この二つのページが有用なのは、公式サイトの「グローバル」という広い言葉を、そのまま信頼性の証明にせず、外から観測できる具体的な番号資源へ議論を戻せる点にある。プレフィックスと起点 AS が分かれば、購入候補の接続先について、DNS の応答、実際に割り当てられた IP、経路観測を照合するための基準ができる。宣伝文句を否定するのではなく、検証できる単位へ分解できる。

一方、二つの/48が見えることは、それらがどの程度使われているかを示さない。アドレス空間の大きさを、稼働中のサーバー台数や処理能力へ換算することもできない。BGP 画面に経路や隣接先が現れても、それだけで商業契約の種類、物理経路の独立性、私的な接続関係は確定しない。RPKI の妥当表示も、経路起点の認可を考える材料であって、アプリケーションの安全性や可用性を保証する印ではない。

さらに、BGP の可視性は時点と観測点に依存する。経路は追加、撤回、変更され得るため、2026年7月20日の表示を恒久的な構成図として保存するのは不適切だ。調達時には候補サービスの IP を確認し、その時点の複数の観測結果と事業者の説明を照らし合わせる必要がある。

IPv4 をめぐる表示差は、データの種類を問う

IP2Location の AS63101 ページは、Afly Cloud LLC、aflycloud.com、データセンター/Web Hosting/Transit という分類とともに、23.188.40.0/24、142.249.228.0/22という IPv4 範囲、2602:f824::/48、2602:f824:1::/48という IPv6 範囲を掲載している。これは、同時期の Hurricane Electric 画面が「起点・広告として観測した IPv4 プレフィックスはゼロ」と示すことと、一見すると食い違って見える。

だが、ここで直ちにどちらかを誤りと決めるべきではない。IP 範囲のデータベースは、登録、過去の関連付け、地理情報、商用データの整理結果を含み得る。一方、BGP の画面は、特定の観測時点に経路として見えたものを数える。ある範囲が事業者名に関連付けられていることと、その事業者の AS がその瞬間に当該範囲の起点として観測されることは、同じ問いへの答えではない。

この表示差は、AFLY だけに特有の問題ではない。小規模クラウドを調べる際、会社名、ASN、登録上の範囲、現在の経路、実際に商品へ割り当てられる IP を一つの一覧に混ぜると、実像より大きくも小さくも見せてしまう。調達側は、情報ごとに「何を、いつ、どの方法で観測したか」を残し、同じ基準の数字だけを比較する必要がある。

たとえば、IPv4 対応が要件なら、第三者ページに範囲が載っているだけで判断せず、購入予定の商品で IPv4 が提供されるか、専用か共有か、どの AS から経路が出るかを確認する。IPv6 が要件なら、二つの/48が見えるだけで満足せず、顧客への割り当て単位、逆引き、フィルタリング、障害時の経路変更を尋ねる。公開データは質問を精密にする道具であり、契約仕様の代用品ではない。

「Sheridan」という地名を物理設備へ変換しない

TheIpAPI の AS63101 ページは、AFLYCLOUD-NETWORK、AFLY CLOUD LLC、米国、ARIN という文脈に加え、Wyoming 州 Sheridan の住所表示と二つの IPv6 プレフィックスを掲載している。この地理表示は、公開データベース上で AS 情報を探す際の補助材料にはなる。しかし、これだけで法人の現在の登記状態、実際の執務場所、サーバーの収容場所を確定することはできない。

同様に、142.249.229.182の IP2Location ページは、この一つのサンプル IP を米国、Wyoming 州 Sheridan、Afly Cloud LLC、aflycloud.com、AS63101、データセンター/Web Hosting/Transit という項目へ結び付ける。ページ上では AS CIDR として142.249.228.0/22も示される。だが、IP 位置情報はデータベースによる推定・分類であり、緯度経度の表示がそのまま機器の設置地点を指すとは限らない。

一つの IP からネットワーク全体の地理を推定するのも危険である。サービスが米国西部、ドイツ、フィンランドを選択肢として掲げるなら、商品ごとにアドレス、収容先、上流、バックアップの扱いが異なる可能性を考える必要がある。本稿の資料は、その対応関係を示していない。Sheridan というラベルを、ドイツやフィンランドを含む全サービスの所在地へ広げる根拠はない。

地理情報には少なくとも四つの層がある。契約主体に結び付く住所、番号資源の登録国、経路から推定されるネットワーク上の位置、データと機器が実際に置かれる場所である。これらが一致する場合もあれば、異なる場合もある。データローカリティを必要とする購入者は、第三者の地図表示ではなく、サービス仕様、データ処理条件、構成資料、契約上の約束で最後の層を確認しなければならない。

データローカリティは、サーバーの国名だけでは完結しない

クラウドサービスの地域選択は重要だ。規制上の要件、顧客との約束、遅延、事業継続の方針によって、米国、ドイツ、フィンランドのどこを選ぶかが実務上の差になることはある。ただし、注文画面で国や地域を選べることと、すべてのデータ処理がその境界に閉じることは同義ではない。

確認対象は、仮想サーバーの主ディスクだけではない。スナップショット、バックアップ、監視ログ、サポートへ送る添付、課金情報、管理画面の認証記録、障害解析用の複製がどこに置かれるかを見る必要がある。管理者がどの国からアクセスできるか、削除要求がどの複製へ及ぶか、障害時に別地域へ移すことがあるかも、データ主権の実効性を左右する。

AFLY の公開販売面は地域選択の存在を示すが、本稿の資料だけでは、各データ分類の保存国、管理経路、委託関係、災害時の複製先を確認できない。この空白は、問題があるという証拠ではない。同時に、安全な地域運用が確認済みだという証拠でもない。購入者は、必要な境界を自ら定義し、回答を契約文書へ落とす必要がある。

データローカリティとネットワーク経路も分けて考えるべきだ。データが特定国のサーバーに保存されていても、利用者からそこまでの通信が同じ国だけを通るとは限らない。反対に、AS63101 の登録文脈が米国であっても、公式サイトに表示された全商品が米国内に収容されるとは限らない。保存場所、処理場所、管理アクセス、通信経路は、別々に検証する項目である。

この区別は、地域名を無意味にするものではない。むしろ、地域選択を実務的な統制へ変える。主データはどこにあるか、複製はどこへ行くか、誰が操作できるか、契約終了時にどこを経由して返されるかを明示できれば、「ドイツ」や「フィンランド」という表示は、初めて監査可能な条件になる。

小規模事業者への依存は、見える制御面で測る

AFLY のように公開資料が限られる事業者を、大手クラウドと同じ情報量だけで比較するのは難しい。だからといって、知名度の大小だけで採否を決めるのも合理的ではない。見るべきなのは、顧客が自ら確認し、保持し、移せる制御面である。

最初の制御面はアカウントと管理権限だ。多要素認証、権限の分離、操作記録、鍵の交換、退職者の停止をどこまで顧客が管理できるかを確認する。root 権限が提供されるとしても、仮想化基盤、ネットワーク、課金、復旧の権限は事業者側に残る。顧客が自由に操作できる層と、事業者へ依存する層を一枚の責任表にする必要がある。

次の制御面は観測可能性だ。稼働状態、通信量、経路、ディスク、バックアップ、管理操作について、どのログと指標を顧客側へ保存できるか。障害時に事業者の説明だけを待つ構造なのか、自社の記録から影響開始時刻と範囲を確認できるのか。この差は、平常時の価格表には現れにくいが、復旧判断と顧客説明の速さを大きく左右する。

第三の制御面は変更と退出である。仮想ディスク、設定、DNS、ファイアウォール規則、ログ、バックアップをどの形式で取得できるか。データ量に応じて搬出にどれほど時間がかかるか。契約終了後の削除をどう確認するか。別事業者へ移す手順を導入前に試せるなら、依存は把握可能な選択になる。出口が不明なまま複数のサービスをまとめると、便利さと同時に交渉上の固定も強まる。

小規模であること自体は、品質の低さも高さも意味しない。公開情報が少ない場合に必要なのは、想像による評価ではなく、検証条件を細かくすることだ。短い試用、実際の利用地域からの測定、バックアップ復元、権限停止、サポート連絡、データ搬出を試せば、一般的な宣伝文句より自社に近い証拠を得られる。

公開経路は、サービスの一部分だけを照らす

AS63101 と二つの IPv6 プレフィックスは、AFLY CLOUD LLC について外部から追える数少ない具体的な手掛かりである。公式サイトだけを見れば「グローバルなクラウド基盤」という広い像が先に立つが、経路ページを重ねると、少なくとも一つの AS と二つの IPv6 経路という観測単位へ焦点を合わせられる。この焦点は、販売上の物語を技術的な質問へ変えるうえで価値がある。

同時に、公開経路が照らす範囲は狭い。経路は、アプリケーションが正常に動くかを示さない。プレフィックスは、保存データの法域を示さない。IP 位置情報は、建物や設備の所在を確定しない。ASN の名称は、契約主体、支援体制、資産所有、顧客関係を説明しない。それぞれの資料を、本来答えられる問いにだけ使う必要がある。

今回の八つの資料から組み立てられる AFLY 像は、米国に結び付くクラウド、VPS、専用サーバーの販売面を持ち、AS63101 と IPv6 プレフィックスが公開ネットワーク上で観測される事業者、というところまでである。IPv4 範囲を掲載する第三者資料もあるが、同時期の BGP 表示とは観測対象が異なる。地域ラベルも複数見えるが、商品と物理・論理基盤の対応は公開資料だけでは決まらない。

この限定は、調査の失敗ではない。証拠が届く境界を明示することで、購入者が次に求めるべきものが分かる。対象商品の IP と起点 AS、データとバックアップの所在地、上流障害時の扱い、責任分界、ログの提供、復旧手順、契約終了時の搬出条件を、提案書と契約で確認する。必要なら、その回答を小規模な技術試験で確かめる。

判断軸は「地域の多さ」ではなく「説明できる依存」である

AFLY CLOUD LLC の公開像には二つの面がある。一つは、US West、Germany、Finland を掲げ、VPS や専用サーバーを手軽に選べる販売面。もう一つは、AS63101、2602:f824::/48、2602:f824:1::/48を中心に外部から観測できるネットワーク面である。両者は矛盾するものではないが、自動的につながるものでもない。

調達判断で必要なのは、その間を具体的なサービス情報で埋めることだ。注文する商品にはどの IP が割り当てられ、どの AS から経路が出るのか。主データと複製はどこに置かれ、誰が管理するのか。障害が起きたとき、どの情報を受け取れ、どこまで自社で切り分けられるのか。退出時にデータと設定をどの形式で回収できるのか。これらへの回答が、価格や地域名を継続可能な運用へ変える。

公開資料の薄さを、根拠のない疑念で埋めるべきではない。同様に、洗練された販売画面を、確認済みの運用能力であるかのように扱うべきでもない。AFLY を評価する適切な姿勢は、見えるものを正確に認め、見えないものを質問と試験へ変えることにある。

AS63101 は、AFLY のサービス全体を保証する印ではない。それでも、会社名、番号資源、経路という三点を結び付け、購入者が検証を始めるための有用な足場になる。クラウド依存を管理するとは、依存先をなくすことではない。どの層を誰に預け、どの証拠を自分で持ち、必要なときにどう移るかを説明できる状態にすることである。