Yandexへの攻撃から考える、データセンターの立地と分散

クラウドに預けたデータも、どこかの土地に置かれたサーバーに保存されている。そこには電力を供給する設備があり、通信回線が引き込まれ、日々の運用を担う人々がいる。ロシアのYandexが運営する複数のデータセンターへの攻撃は、こうした物理的な基盤への依存を改めて示した。

この出来事を受け、SNSではデータセンターの地下化や国外への分散を求める意見が出ている。立地を考え直す契機として重要な指摘である。検討の中心に置くべきなのは、複数の拠点が同じ原因で停止しないか、停止後も必要な業務を再開できるかという二つの問いである。

本稿では、Yandexの公式発表と障害履歴を確認した上で、データセンターの地下施設化、国内外への立地の分散、通信経路とクラウド事業者への依存を整理する。

2026年10月20日0時49分（日本時間）更新。クラウドの復旧案内、10月19日の利用者向けサービスの復旧報告、ボット通信に関する追加分析を反映した。表の発生日はロシア現地の日付、障害情報の更新時刻は日本時間で示す。以下では事件の経過と、立地・分散に関する一般的な設計上の考察を分けて扱う。

何が確認されているのか

Yandexは2026年10月9日の公式声明で、7日夜から8日にかけてサソヴォのデータセンターが無人機攻撃で大きく損傷し、稼働を全面的に停止したと発表した。9日朝にはカルーガのデータセンターも攻撃を受け、一部の設備が使用不能になったとしている。両拠点で従業員の負傷はなかったと説明している（参考資料1）。同社が自社のデータセンターと説明する拠点の被害であり、Yandex Cloudを利用する他社は、その施設の所有者・運営者とは区別する。

発生日	拠点	公式発表で確認できる内容
10月7日夜〜8日	サソヴォ（リャザン州）	無人機攻撃に伴う火災。施設の稼働を全面停止。Yandex Cloudのru-central1-bに障害。
10月9日	カルーガ	攻撃によって一部のインフラが使用不能。
10月11日	ウラジーミル	無人機攻撃による損傷。施設の稼働を全面停止。人的被害はないと発表。

ウラジーミルについては、11日12時08分の公式障害情報が停止を明記している。同社は残存する設備構成を不安定と評価し、緊急運用に移行したとして、利用者に代替の災害復旧計画を使うよう勧めた（参考資料2、3）。サソヴォの障害も、当初は電力障害として掲載され、その後、無人機攻撃による火災が原因と説明された。今回確認した発表は物理的な攻撃と、それに伴う電力・サービス障害についてのものであり、サイバー攻撃による侵入被害の発表ではない。ロイターの10月11日配信記事はウクライナによる攻撃と報じる一方、ウラジーミルの被害と停止についてはYandexの説明を伝えている（参考資料4）。

施設の全面停止という発表は、Yandexの全サービスが一律に停止したことを意味しない。10月11日17時14分の公式更新では、管理画面とAPIは利用可能、計算サービスは一部利用可能、S3互換ストレージは速度低下の可能性を伴いながら読み書き可能とされ、同日19時12分にも変更はないと説明された。これは11日時点の記録であり、20日現在の全サービスの状態を示すものではない。攻撃主体についても、事業者の被害報告や報道上の帰属と、実施部隊・作戦の独立した確認は区別する必要がある（参考資料3、4）。

その後、10月17日2時19分の公式更新でも、クラウド基盤は制限付きで稼働し、復旧作業を続けていると説明された。公式の復旧案内は16日17時50分（モスクワ時間、日本時間同日23時50分）更新と表示され、復旧期限は示せないとしている。一方、19日のRB.RU報道は、Yandexの広報説明として、配車、配送、カーシェアなどへのアクセスが復旧したと伝えた。利用者向けサービスの復旧と、損傷した施設やクラウド基盤全体の復旧は分けて見る必要がある。

また、設備の停止は、保存されていたデータの全消失を意味しない。衛星画像と現地映像を照合したVertical52の調査は、サソヴォの建物の屋根に焼損の跡を確認しているが、内部のスーパーコンピューターの状態は不明としている。11日撮影の衛星画像と、7日夜から8日にかけての攻撃の発生日も混同できない。機器ごとの損傷やデータの回収可能性は別に確認すべき事項であり、本稿では未公表の被害規模を推定しない。

なお、The Kyiv Independentの16日報道にはウラジーミルへの再攻撃の情報もあるが、同紙は監視チャンネルを情報源とし、攻撃対象と被害を独立に検証できていないと明記している。追加攻撃の被害は確定情報として表に加えていない。施設の全面復旧、保存データ全体の消失・無事のいずれも、今回確認した資料からは断定できない。

（余談）日本のSNS上のボットは減ったのか

日本語のSNSでは、今回の攻撃後にボットらしき投稿が減ったという見方もある。Cloudflareが10月14日に公表した分析では、Yandexの検索用ネットワークから減った通信の大部分は正規の検索クローラーだった。クラウド側では一部の悪意ある自動通信が別の事業者へ移り、同社が観測する特定SNSの投稿・返信・「いいね」の送信先でも、想定外の変化は確認できなかったとしている。これは同社の観測範囲の分析であり、日本語SNSの世論操作アカウント全体の増減を測った統計ではない。日本向けのボット活動の減少や、その運用基盤とYandexとの関係は、引き続き未確認である。

検証には、同じアカウント群の投稿数を攻撃前後で比較し、時差や曜日、話題の変化、SNS側の凍結・表示変更などを調整する必要がある。投稿数の減少を確認できた場合も、それだけで運営国や組織までは特定できない。一般利用者のタイムラインの変化は調査のきっかけにはなるが、原因を確定する証拠にはならない。

ベラルーシの配車サービスへの影響についても、SNS上の説明を裏付ける運営者の一次発表を今回の調査では確認できなかった。国境を越えて影響が波及する仕組み自体は理解できる。利用者がいる国と、その処理を実行するサーバーがある国は一致するとは限らないからである。

複数の拠点が共通の原因で止まる

冗長化の効果はどの範囲の障害を想定するかで変わってくる。同じ施設内でサーバーや電源を二重化しても、施設全体の火災や受電停止には備えられない。そのため、同一施設内の冗長化、別施設・別リージョンへの分散、別事業者の併用では、減らせる共通原因（同時に壊れる要因）がそれぞれ異なる。

ここで、クラウドの「ゾーン」と「リージョン」について確認しておく。Yandex Cloudの仕様では、ゾーンはデータセンター内のインフラの単位であり、他のゾーンの機器・ソフトウェア障害から分離されている。リージョンは、複数のゾーンをまとめる地理的な区分である。

同社の公式資料（参考資料5、6）によれば、ru-central1-a、b、d、eはロシア側のru-central1リージョンに属するゾーンであり、カザフスタンには別リージョン（kz1）のゾーンkz1-aがある。したがって、ロシア側で複数のゾーンを使っていても、それだけで複数国・複数リージョンに分散した構成にはならない。ただし、これらは配置の仕様であり、障害中に各ゾーンが利用できることを保証するものではない。また、今回の事例だけから「マルチリージョンは役に立たない」と結論することもできない。

分散の効果は、想定する障害によって決まる。一つの建物の火災に備えるなら別施設への分散が基本になるが、広域停電、通信網の途絶、戦争に備えるなら、より長い距離とより高い独立性が必要になる。さらに、同じ事業者の離れた拠点でも、認証や管理機能を共有していれば、そこが停止した際にまとめて影響を受けうる。設計にあたっては、まず想定する障害を決め、その障害に対して何を独立させておくべきかを確認する必要がある。

主に減らしたい共通のリスク	併せて確認すること
局所的な火災、設備故障	電源、通信、制御機能がどこまで独立しているか
広域災害、地域の電力・通信障害	離れた拠点に切り替えられるか、必要な容量があるか
一国規模の混乱、通信・制度上の制約	国内からの接続、データの取扱条件、運用体制
事業者全体の障害、共通基盤への依存	データ形式、機能差、認証・鍵の独立性
誤削除、破損、ランサムウェア	過去の正常な状態へ戻せるか

さらに重要なのは、退避先の容量である。Yandexは10月9日にSelectel、K2Cloud、VK Cloudへの移行支援を案内した。その後、計算資源などの割り当て上限を手動で管理する運用に移り、11日には追加資源の割り当て上限の引き上げを停止したと発表している（参考資料2、3）。

平時に空いているサーバーと、大勢の利用者が同時に避難する局面で確保できるサーバーは別である。予備拠点の存在に加え、予約容量、起動に必要な時間、負荷を絞って動かせる機能を確認しておく必要がある。

地下データセンターのメリット

国内では、三井不動産、熊谷組、ゲットワークスが10月6日、神戸の既存トンネルを活用する地中型データセンターの開発を発表した。2027年末のサービス開始を予定し、将来の最大受電容量は20MWを目指す。発表上の「日本初」は、既存トンネルを利用して外部顧客にサービスを提供する商用事業という条件付きである（参考資料7、8）。

事業者は、年間15〜20℃の冷涼性や物理的な保護を利点として挙げ、地下水を循環利用する水冷方式も導入するとしている。これは計画段階の説明であり、稼働後の省エネルギー性能や特定の攻撃に耐えられる能力が実測されたことを意味しない（参考資料7）。

地下化には、建物本体を外部環境から隔て、温度変動を抑えやすい利点がある。その効果を実際の可用性につなげるには、排水、換気、火災時の避難、搬入・保守、電源と通信の確保を一体で設計する必要がある。サーバーが無事でも、電力や冷却が失われれば稼働は続けられない。

冷たい空間にサーバーを置くだけで、大量の発熱を処理できるわけでもない。例えばIT機器が10MWを消費している場合、ほぼ同じ規模の熱が発生する。冷却系はその熱を継続的に外へ運び出さなければならない。冷涼な地下空間は冷却を助ける条件であり、排熱設備の代わりにはならない。

廃坑や旧トンネルも、地質、劣化状態、水の流入、避難経路、設備を更新できる空間を調べて初めて候補になる。日本に山が多いことは選択肢を増やす。個々の空間がデータセンターに適するかは、別の工学的な問題である。

立地の評価と場所を秘匿

北海道の石狩データセンターについて、さくらインターネットは冷涼な気候を利用した外気冷房や、地震・津波・液状化リスクを考慮した立地を説明している（参考資料9）。立地には、電力、用地、冷却、通信、保守人員、利用者との距離など、複数の条件が関わる。

周辺国への地理的な近さだけで、特定施設を「狙われやす過ぎる」と順位付けする根拠は不足している。軍事的脅威の評価には、攻撃能力、意図、防護、情勢を含む別の情報が必要になる。日本のデータセンター立地を考える際も、災害リスクを下げる地方分散の効果と、有事の共通リスクを並べて評価する方が建設的である。

施設の詳細な設備配置、警備情報、運用手順などは、公開範囲を絞る意味が大きい。所在地を一律に極秘化する制度については、顧客が保管場所を確認する必要、消防・防災、地域への説明との両立を考えなければならない。大きな建物や電力設備の存在を、長期間完全に隠し続けることも難しい。

英国NCSCの指針も、データの所在と適用される法制度、物理的な保護、運用に携わる人々を含めて評価する考え方を示している（参考資料10、11）。公開情報を減らす対策と、場所が知られていても被害を抑えられる対策を組み合わせる必要がある。

都市部の立地には、通信の接続性や保守のしやすさという利点がある。周辺住民には騒音や電力利用などへの関心がある。安全保障上の配慮を理由に、地域への説明を省略するのは適切ではない。従業員についても、設備保全と並んで、退避の判断、安否確認、遠隔運用への切り替えを事業継続計画に組み込むべきである。

外気冷房の観点では北海道の東側、釧路付近にデータセンターを構えても良さそうである。夏も冷涼な気候を生かせば、外気冷房を利用できる時間が長くなり、冷却用電力を抑えられるだろう。ただし、実際の立地選定では、電力供給や通信回線の確保、地震・津波などの災害リスクも併せて検討する必要がある。

海外に置くデータと、国内に残す機能

海外の別事業者にバックアップを保管すれば、国内の広域障害や一事業者への依存を減らすことができる。ここでは「データを残すこと」と「そのデータでサービスを再開すること」を分けて考えたい。バックアップが残っていても、接続できず、復号鍵を取り出せず、動かすサーバーがなければ復旧は進まない。

Yandexのカザフスタン側リージョンは、地理的な分散先の候補にはなる。公式資料ではリージョンごとに資源やデータが分離されており、ロシア側のデータが自動的にカザフスタンへ複製される仕様ではない。同じYandexを利用する以上、事業者の分散にもならない。使えるサービス、移行可能性、容量を確かめずに「そこへ逃げれば安全」とは言えない（参考資料6）。

日本から海外のデータへ接続する際には、国際通信も重要になる。ITUによれば、国際データ交換の99％超は海底ケーブルに支えられている（参考資料12）。国外への保存は一国集中のリスクを減らし、国内の複製は国際通信が途絶した場合の継続性を高める。両方を組み合わせる意義がある。

例えば重要な連絡先、業務手順、必要最小限の台帳を国内でも参照できるようにし、長期保存用の複製を国外の独立した環境にも保管する。どこに何を残すかは、機密性やデータの取扱条件、停止時に続けたい業務から決めることになる。分散先を増やせば設備・通信・運用の費用も増え、遠隔地への同期複製には書き込み待ち時間の増加が伴う。必要な復旧時間とデータの所在に関する条件を満たす範囲で、分散の距離や複製方法を選ぶ必要がある。

衛星通信と宇宙データセンターの役割

衛星通信は、地上回線が使えない場面の補助経路として価値がある。緊急連絡や復旧作業の指示など、少量でも優先度の高い通信を維持できれば、現場の対応力は大きく変わる。

海底ケーブルの通信量を一括して衛星へ移せるかどうかは、別途容量を検討すべき問題である。Starlink自身も、速度や連続した利用を保証せず、混雑、設置環境、天候、電源などの影響を示している（参考資料13）。大規模障害時には利用が集中するため、平時の速度だけを基準にした設計は避けたい。

将来の衛星網が大容量化すれば、バックアップ回線としての用途は広がると考えられる。実際の復旧計画には、現在契約できる容量、優先制御、必要な電源を用いるべきである。

宇宙へのデータセンター設置についても、打ち上げ、保守、通信、電力、排熱という独自の条件がある。宇宙空間へ熱を捨てる際には、地上の空気への放熱とは異なり、熱放射が重要になる（参考資料14）。地下と宇宙を同列の避難先と考えるより、それぞれの実証状況と運用費用を評価する段階にある。

マネージドサービスと、実際に戻せるバックアップ

クラウド事業者がデータベースの保守などを代行するマネージドサービスは、運用負担を軽くする。同時に、その事業者固有の機能を使うほど、移転先で同じ動作を再現する作業が増える。依存するのはデータ形式だけではなく、認証、権限、暗号鍵、監視、処理の順序などにも及ぶ。

対策としては、重要なデータを取り出せる形式で保存する、構成を文書やコードで再現できるようにする、移転先で必要な機能をあらかじめ決める、といった方法がある。AIエージェントによる構築支援は作業を速める可能性がある。障害時に確保できる設備や、サービス間の仕様差まで消えるわけではない。

複数事業者を常時使う構成では、権限や設定を管理する対象も増える。小規模な組織が最初に取り組むべきことは、全面的な二重運用よりも、主系から独立したバックアップと、そこからの復元確認である場合が多い。

CISAは重要データのオフライン・暗号化バックアップと、復旧時の利用可能性・完全性の定期的な確認を勧めている（参考資料15）。最新状態を常時複製する仕組みでは、誤削除や破損も複製され得る。過去の正常な状態を残すことや、本番環境の管理権限だけでは消せないようにすることにも意味がある。

復旧の目標は、許容できる停止時間であるRTOと、どの時点までのデータ損失を許容するかを表すRPOで整理できる。AWSも業務ごとにこれらを定め、復旧を試験することを勧めている（参考資料16、17）。例えば「4時間以内に再開し、失ってよい更新は直前1時間分まで」という目標なら、その条件を満たす構成と手順を実際に確認する。

安全な立地を復旧できる構成につなげる

地下化、分散、バックアップ、復旧訓練は、それぞれ守る対象が違う。地下化は設備を物理的に守る。地域・国・事業者の分散は、同じ原因で同時に止まる範囲を狭める。バックアップは過去の状態を残し、復旧訓練は、そのバックアップで実際に復旧できるかを確かめる。Yandexの事例はロシア特有のもので日本では関係ない、と一蹴してしまうのではなく、実際にデータセンターが機能不全になった際にどう対応するか、そうなる前にどのような準備をしておくべきかをシミュレートする良い機会にと見なすべきである。 

実務では次の4点を確認したい。

1. 1. 主系と予備系は、何を共有しているか（電源、管理機能、通信など）。
   2. 退避先には、必要な処理を引き受けるだけの容量があるか。
   3. 鍵や認証、通信が失われても、復旧できるか。
   4. 担当者が安全のために現場を離れた後も、最低限の業務を続けられるか。

データセンターの立地は、これらの確認と合わせて評価する。企業や自治体が調達で求めるべきなのは、拠点数だけではない。どのような障害を想定しているか、その障害からの復旧を実際に試した結果があるかまで確認する必要がある。設備の置き場所を決めるだけでなく、何を残し、どう再開するかまで計画してはじめて、長期的な耐障害性が高まる。

参考資料

2026年10月20日更新。1〜3は事業者による被害・障害報告、4は攻撃主体に関する補助的な報道、5以降は公式仕様・公的機関の指針・事業計画である。今回確認した復旧の続報、通信分析、映像・衛星画像の調査、分散設計の補足資料は、対応する本文中にもリンクを置いた。

1. 1. Yandex Cloud「Что происходит с дата-центрами Яндекса」（2026年10月9日）。
   2. Yandex Cloud公式障害履歴：インシデント2092。サソヴォの停止、他社移行案内、資源割り当ての制限。
   3. Yandex Cloud公式障害履歴：インシデント2136。ウラジーミルの停止、緊急運用、各サービスの状態。19時12分（日本時間）の更新まで確認。
   4. Reuters「Russia’s Yandex says data centre in Vladimir area shut down after drone attack」（2026年10月11日）。
   5. Yandex Cloud Documentation「Availability zones」。
   6. Yandex Cloud Documentation「Regions」。
   7. 三井不動産・熊谷組・ゲットワークス「日本初、既存トンネルを活用した地中型データセンターを開発」（2026年10月6日）。
   8. 神戸市「ベルトコンベア跡トンネル施設貸付の落札者決定」（2026年10月6日）。
   9. さくらインターネット「石狩データセンター」。
   10. 英国NCSC「Principle 2: Asset protection and resilience」。
   11. 英国NCSC「Joint security guidance offered to data centre operators and users」。
   12. ITU「Submarine Cable Resilience」。
   13. Starlink「Starlink Specifications」。
   14. NASA「7.0 Thermal Control」。
   15. CISAほか「#StopRansomware Guide」。
   16. AWS Well-Architected Framework「How do you plan for disaster recovery (DR)?」。
   17. AWS Prescriptive Guidance「Multi-Region fundamental 1: Understanding the requirements」。