アオウル博士: ITとセキュリティの専門家。ミマワリの頼れる相談相手。
ミマワリ: アオウルのキャラクター。PCやスマホは毎日使うけど、たまにツールがうまく使えず困ってしまう。
昨日(10/27)、Microsoft 365で障害が発生。もしGoogle Workspaceが止まったら？「クラウドは止まらない」という誤解と、Googleが持つインフラの「秘密」を専門家が比較解説。障害時のデータ移行の落とし穴や、私たちが本当に備えるべきことを会話形式で学びます。
博士、昨日のニュース見ましたか？ 2025年10月27日の午前中、Microsoft 365（Officeのクラウド版）で障害があって、ポータルにアクセスできないトラブルがあったみたいです（※検索結果2.1参照）。
僕の会社はGoogle Workspaceを使ってるから直接の影響はなかったですけど、取引先がいくつかMicrosoft 365を使ってるみたいで、午前中はメールの返信が来なくて少し焦りました。
もしこれが、うちが使ってるGmailやGoogle Driveで起こっていたら…と考えると、業務が完全にストップしちゃうわけで…。本当にゾッとします…
うむ。ミマワリ君の言う通り、昨日の障害をきっかけに、改めて「クラウドサービスの安定性」や、万が一の際の「障害時のデータ移行」といったキーワードの検索が急増しておる。
【警告】じゃが、ここで一つ、絶対に持ってはならない「危険な誤解」がある。それは、「クラウドサービスは絶対に止まらない」という思い込みじゃ。
「Googleだから大丈夫」「Microsoftだから安心」という考えは、非常に危険なんじゃよ。
えぇっ！？そうなんですか？
昔、会社の中にサーバー（オンプレミス）を置いていた頃は、停電したり、機械が壊れたりして、しょっちゅう止まってましたけど…。クラウドなら、そういう心配が一切ないものだと思ってました。だって、管理してるのがあのGoogleやMicrosoftなんですよ？
第1章：なぜ？「止まらない」はずのクラウドで障害が起きる理由
ミマワリ君の言う通り、オンプレミスより「はるかに安全で、比較にならないほど止まりにくい」のは紛れもない事実じゃ。SLA（サービス品質保証協定）でも99.9%以上の稼働率を保証しておる。
しかし、逆に言えば「0.1%」は止まる可能性があるということ。そして、100%止まらないサービスは、残念ながらこの世に存在しない。なぜなら、クラウドといえど「人間が運用する物理的な機械」であることには変わりないからじゃ。
クラウドサービスが停止する主な原因は、だいたい以下のパターンに分類されるんじゃ。
原因①：設定・更新ミス（ヒューマンエラー）
これが実は最も多い原因の一つじゃ。GoogleもMicrosoftも、サービスを改善するために毎日、毎週のようにソフトウェアのアップデートを行っておる。その際、新しいプログラムのバグや、ネットワークの設定変更（ルーティング設定など）を、運用しているエンジニアが誤ってしまい、それがシステム全体に波及するケースじゃ。
今回のMicrosoftの障害も、こうした内部のオペレーションが関係している可能性が報じられておるな。どんなに優秀なエンジニアでも、ミスを100%防ぐことはできんのじゃ。
原因②：ハードウェアの物理的故障
クラウドの実態は「データセンター」という巨大な倉庫のような建物に、何万台、何十万台というサーバー（コンピュータ）が詰め込まれておる。当然、それらのサーバーも機械じゃから、電源ユニットが壊れたり、データを保存するストレージ（HDDやSSD）が寿命を迎えたり、データを繋ぐネットワークスイッチが故障したりすることは日常茶飯事じゃ。
もちろん、1台壊れてもサービスが止まらないよう「冗長化」されておるが、その冗長化システム自体がうまく作動しないという不運が重なると、障害として表面化するんじゃ。
原因③：トラフィックの異常集中
特定のサービスに、想定をはるかに超えるアクセスが殺到し、システムが処理しきれなくなるケースじゃ。例えば、世界的な大事件やイベントが発生し、全員が一斉にGmailやGoogle検索、あるいはTeamsで会議を始めようとすると、サーバーがパンク状態になることがある。
原因④：外部からの攻撃や自然災害
DDoS攻撃（大量のデータを送りつけてサーバーを麻痺させるサイバー攻撃）でサーバーがダウンしたり、地震や火災、テロ、大規模停電などでデータセンターそのものが物理的に機能しなくなったりするケースじゃな。
これらのリスクは、GoogleだろうとMicrosoftだろうとゼロにはできんのじゃよ。
第2章：【比較】Google Workspaceが「特に安定している」と言われるインフラの秘密
うーん、理屈はわかります。どんな大企業でもリスクはゼロじゃないんですね…。
でも博士、ここだけの話、正直なところ、Microsoft 365（旧Office 365）って、Google Workspace（旧G Suite）より障害が多いイメージがありませんか？
僕の周りでも、「Teamsが繋がらない」とか「Outlookが固まった」って話は、年に数回は聞く気がします。それに比べて、Googleが止まったって話はあまり聞かないような…。これは単なる僕の気のせいでしょうか？
良いところに気が付いたな、ミマワリ君。それは「体感」だけでなく、実際にインフラの設計思想に大きな【秘密】があるからなんじゃ。
断っておくが、MicrosoftのAzureが劣っているわけではない。あれも世界最大級の素晴らしいクラウドインフラじゃ。しかし、Googleのインフラには、根本的に異なる「出自」と「哲学」があるんじゃ。
秘密①：「地球規模」が前提の超分散設計（アクティブ・アクティブ）
そもそもGoogleは、Google Workspace（ビジネス用）を作るずっと前から、「Google検索」と「YouTube」という、全人類が日常的に使う超巨大サービスを運用していた。Gmailも、元は個人向けの無料サービスとして爆発的に普及した。
つまり、Googleのインフラは最初から「特定の国や地域のデータセンターが一つ停止しても、地球の裏側のデータセンターが瞬時に引き継いで、サービスを絶対に止めない」という思想（＝地理的分散アーキテクチャ）で設計されておる。
ミマワリ君のデータ（例えばメール）が、東京のデータセンターだけに保存されているのではない。そのデータは暗号化され、断片化され、大阪、台湾、シンガポール、アメリカ…と、世界中の複数のデータセンターにリアルタイムで複製・分散されておるんじゃ（これをアクティブ・アクティブ構成と呼ぶ）。
だから、仮に東京のデータセンターが丸ごと停電したとしても、ミマワリ君のPCは自動的かつ瞬時に、次に最も近い大阪や台湾のデータセンターに接続しにいく。ミマワリ君はおそらく、その切り替わりに気づくことさえないんじゃ。
秘密②：独自の「海底ケーブル網」という専用道路
通常、データセンター間（例えば東京と大阪）は、他の通信会社が敷設したインターネット回線（海底ケーブルなど）を「借りて」通信するのが一般的じゃ。しかし、この「公道」は、他の車（他の会社の通信）で混雑することがある。
しかしGoogleは、自社専用の海底ケーブルを太平洋や大西洋に何本も敷設しておる。これは、一般道の混雑（インターネットの混雑）を避け、自社データセンター間を**「自社専用の高速道路」で結ぶようなもの。これにより、超高速なデータ複製と、外部の影響を受けない圧倒的な安定性を両立させておるんじゃ。
秘密③：「SRE」という最強の運用哲学
Googleには「SRE（Site Reliability Engineering）」という、障害対応専門の最強エンジニアチームがおる。彼らの仕事は「障害を起こさない」ことではない。「障害は必ず起きる」という前提のもと、「障害を『予兆』の段階で検知し、人間が気づく前にソフトウェアで自動復旧させる」ことじゃ。
例えば、あるサーバーの動作が少し遅くなった（故障の予兆）とAIが検知したら、SREが作った自動化プログラムが、人間が介入する前にそのサーバーをサービスから切り離し、トラフィックを正常なサーバーに振り分ける。
Microsoftの障害は「発生してから復旧まで数時間」かかることがあるが、Googleの場合、こうした小さな障害はSREによって日々「自動的」に処理されており、我々ユーザーが気づくレベルの大規模障害に至るケースが極めて少ないんじゃ。
この「インフラの強靭さ」こそが、Google Workspaceが相対的に安定していると言われる最大の理由じゃな。
第3章：【ビフォーアフター】もし障害が起きても「データは消えない」という絶対的安心感
なるほどー！Googleのインフラって、元々が世界中の検索や動画を支えるために作られてるから、桁違いに頑丈なんですね！「自動で復旧してる」から僕らが気づかないだけ、というのは目からウロコです。
でも、博士。いくら頑丈でも、もし（SREでも対応できないような）大規模な障害が起きたら、その間の業務はストップしちゃいますよね？
昔、会社で使ってたファイルサーバーが壊れた時は、復旧するまで丸一日何もできなくて、しかも「昨日のデータが消えたかもしれない」って大騒ぎになって…本当に地獄でした…。クラウドでも、結局同じことになりませんか？
そこが、オンプレミス（自社サーバー）とGoogleのようなクラウドの決定的な【ギャップ】じゃ。ミマワリ君が体験した「地獄」を【ビフォーアフター】で詳細に比較してみよう。
【ビフォー】（オンプレミスのファイルサーバー）
- 障害発生時：サーバー室のファイルサーバーが「ガリガリ」と異音を立てて停止。赤いランプが点滅。
- データ：「昨日の夜中にバックアップは取ったはず…」とIT担当者が青ざめる。最悪、故障したHDD（ハードディスク）がバックアップ用HDDも道連れにしていた場合、データは完全に消失する。運良くバックアップが残っていても、昨日の夜中から障害発生までの「数時間分の作業データ」は全員分、消し飛ぶ。
- 復旧作業：社内のIT担当者（あるいは外部の業者）が駆けつける。故障部品を特定し、秋葉原に代替品を買いに走る。新しい機器を設置し、OSを再インストールし、バックアップからデータを数時間かけて戻す。
- 業務：復旧まで数時間～数日間、全部署の業務が完全にストップする。「データは戻るのか？」「いつ直るんだ！」という問い合わせがIT担当者に殺到する。
【アフター】（Google Workspace / クラウド）
- 障害発生時：（例えば）Googleの東京データセンターが大規模停電で停止。
- データ：データは世界中にリアルタイム複製（アクティブ・アクティブ）されているため、データ消失の可能性は天文学的にゼロに近い。（Googleは「99.999999999%（イレブンナイン）」の耐久性をうたっておる）
- 復旧作業：GoogleのSREチームが即座に対応。自動で別のデータセンター（大阪や台湾）に切り替わるか、数十分～数時間以内に問題を修正する。ユーザー（我々）がやることは「待つ」こと以外、何もない。PCを再起動したり、ケーブルを抜き差ししたりする必要も、業者に電話する必要もない。
- 業務：「あれ、Gmail重いな？」と感じるかもしれない。一時的にアクセスしにくくなるが、「データが消えたかも」という恐怖は一切ない。復旧を「待つ」だけ。
「アクセスできない時間」が発生するリスクは同じでも、「データが消し飛ぶリスク」と「自分たちで復旧作業をするコストと手間」がゼロになる。この精神的な安心感の【ギャップ】こそが、クラウド最大のメリットなんじゃ。
第4章：【警告】障害が怖いからと「データ移行」する際の落とし穴
なるほど！「止まってもデータは絶対に安全」って思えるだけで、心の持ちようが全然違いますね！オンプレ時代のあの悪夢とは比べ物にならないや…。
昨日の障害で、Microsoft 365を使ってる会社さんの中には、本気で「Google Workspaceに移行したい」って考え始めたところ、多いんじゃないですかね？「障害時のデータ移行」って、検索もされてるみたいですし。
ふむ。確かに、競合の障害は「乗り換え（リプレイス）」を検討する大きなきっかけになる。しかし、ここで大きな【警告】がある。「隣の芝は青い」と安易に「データ移行」に飛びつくと、想像以上の困難とコストに直面し、大やけどをしかねんのじゃ。
落とし穴①：メール・カレンダー移行の地獄
Microsoft Exchange（Outlookのサーバー）からGmailへ、全社員の数年分、数十テラバイトに及ぶ過去のメールデータをすべて移行するのは、想像を絶する作業じゃ。専門の移行ツールと高度なノウハウが必要で、時間もコストも非常にかかる。
移行中に「Aさんのデータだけ抜けた」「Bさんのカレンダーの予定が重複した」「移行作業中、数時間のメール不達期間が発生した」など、必ずトラブルは起きる。これを障害のドタバタの中でやろうとするのは無謀じゃ。
落とし穴②：「Excelマクロ」と「SharePoint文化」という巨大な壁
これが日本企業における最大の障壁じゃ。多くの企業では、Excelの「マクロ（VBA）」で組まれた複雑な業務システム（請求書発行、勤怠管理など）が、今も現役で動いておる。これらは、Googleスプレッドシート（GAS）では100%そのまま動かない。**
また、SharePoint（Microsoft版ファイルサーバー）で構築した複雑なファイル権限設定やワークフロー文化も、Google Driveのシンプルな思想とは相容れない部分がある。
「安定性のためにGoogleへ！」と移行したはいいが、肝心の業務システム（Excelマクロ）が動かず、結局Excelを使い続ける…という本末転倒なことになりかねん。
落とし穴③：Googleも「ゼロ」ではないという事実
先ほども言った通り、Google Workspaceも（稀ではあるが）障害は起こる。2020年12月には、世界的な認証システム（ログイン機能）の障害で、GmailやYouTubeなど広範囲なサービスが数十分間停止したこともある。
「障害が嫌だからMicrosoftをやめる」という動機だけでは、移行先のGoogleで障害が起きた時に「こんなはずじゃなかった」と、同じ不満を持つことになるじゃろう。
第5章：結論：私たちが「障害」に備えて本当にやるべきこと
うーん、難しいですね…。移行も簡単じゃないし、Googleだって100%じゃないとなると…。
結局、僕たちユーザーは、障害が起きないことを「祈る」しかないんでしょうか？
いや、我々にも「祈る」以外の「備え」はできる。クラウド時代に必要なのは「100%の安定を盲信する」ことではなく、「障害は起こりうるもの」として賢く「備える」ことじゃ。
対策①：「オフライン機能」を有効にしておく
Google Workspaceの非常に優れた機能の一つじゃ。Gmail、Googleドキュメント、スプレッドシート、スライドなどは、インターネットが繋がっていなくても（あるいはGoogle側が障害で止まっていても）、PC（Chromeブラウザ）上で作業を続けられる「オフライン機能」がある。
これを全社員が有効にしておけば、一時的なネットワーク障害や、数十分レベルのGoogle側の障害なら、それに気づかずに作業を続行できるんじゃ。ネット接続が回復した時点で、作業内容は自動的にクラウドと同期される。
対策②：「障害情報ダッシュボード」をブックマークしておく
「あれ、Gmailが開かない？」と思ったら、まずは「Google Workspace ステータス ダッシュボード」という公式ページを確認する癖をつけるんじゃ。ここに、今どのサービスで障害が起きているか（緑＝正常、黄・赤＝問題あり）がリアルタイムで表示される。
ここが赤くなっていたら「ああ、Google側の問題だな」と分かり、慌てて自分のPCを再起動したり、社内のIT担当者に電話したりする必要がなくなるぞ。
対策③：緊急連絡手段（BCP）を決めておく
これが組織としては最も重要じゃ。会社全体でGoogle Workspaceに依存している場合、もしチャット（Google Chat）やメール（Gmail）が同時に止まったら、業務連絡が一切できなくなる。
「もしGoogleが半日以上停止したら、緊急連絡は〇〇（別のサードパーティ製チャットツールや、個人の携帯電話を使った緊急連絡網など）で行う」というルール（BCP：事業継続計画）を、あらかじめ決めておくだけで、障害時のパニックは防げる。
障害はゼロにはできん。しかし、Googleの圧倒的なインフラの安定性を信頼しつつ、我々も「オフライン機能」や「緊急連絡網」といった賢い備えを持つこと。これがクラウドサービスと付き合う最適解じゃよ。
なるほど！ただ移行を考えるんじゃなくて、今使ってるGoogle Workspaceの「オフライン機能」を見直したり、障害時のルールを決めたりする方が、よっぽど現実的で重要なんですね！
早速、自分のオフライン設定が有効になってるか、確認してみます！ありがとうございました！
