Google Workspace 障害 時に情シスが最初にやること：初動対応フロー設計

Google Workspace では2026年にも複数のサービス障害が報告されており、Gemini を含む主要サービスで断続的な影響が確認されています。この記事では、GWS が落ちたときに情シス担当者が最初に何をすべきか、初動対応フローと事前準備の設計を整理します。

この記事を読んだほうが良い人

• Google Workspace を1〜2名体制で管理している情シス担当者
• GWS障害時の対応フローを文書化していない方
• ユーザーへの通知方法や代替連絡手段を事前に決めていない方
• これまで障害のたびに場当たりで対応しており、仕組みを整えたい方
• 障害発生から復旧まで、自分がどのくらいの時間軸で動くべきか整理できていない方

Google Workspace 障害 対応の基本フロー（情シス向け）

障害発生時の初動は「確認→判断→通知→継続対応→記録」の5ステップで整理できます。それぞれのステップで「何分以内に何をするか」を事前に決めておくことが、場当たり対応を防ぐ第一歩です。

ステップ1：状況確認（障害発生から5分以内）

ユーザーから「メールが使えない」「Drive に繋がらない」という報告が入ったとき、最初に確認するのは次の2点です。

• Google Workspace ステータスダッシュボードでサービス別の稼働状況を確認する
• 複数の端末・ネットワーク環境で再現するかを確認する（社内LAN / モバイル回線など）

2点目の確認には、具体的な方法があります。手元のスマートフォンをキャリア回線のテザリングに切り替え、そのネットワーク経由で Gmail や Drive にアクセスします。テザリングでは問題なくアクセスできる場合は、社内ネットワーク（VPN・Proxy・ファイアウォール）側の問題です。テザリングでも繋がらない場合は、Google サービス自体の障害と判断できます。この「社内ネットワーク vs GWS本体」の切り分けを5分でできるかどうかが、対応の速度を大きく左右します。

Google のステータスダッシュボードは、障害発生から情報掲載まで一定のタイムラグがある場合があります（公式ヘルプより）。ダッシュボードがまだ「正常」を示していても、複数ユーザーから報告が来ている場合は、15分後に再確認することを基本ルールにします。

ステップ2：判断（5〜15分）

ステータスダッシュボードで障害が確認できたら、影響サービスと影響範囲を把握し、次のアクションを決めます。判断の軸は「復旧見込み時間」と「業務への影響度」の2つです。

代表的なシナリオごとの対応方針は以下の通りです。

シナリオ	判断	対応方針
復旧見込み30分以内	軽微	様子見。代替手段への切り替えは不要。Slackなど主要連絡手段で1報のみ
復旧見込み1時間超 or 不明	要対応	代替連絡手段の案内を開始。重要な外部対応・締め切りタスクの方針を決める
Gmail障害	通信系影響大	SlackまたはSMSへ誘導。外部への送受信は復旧後に再送依頼を周知
Google Meet障害	会議系影響大	外部との会議は電話または Teams（ゲスト招待）を代替手段として案内
Google Drive障害	ファイルアクセス停止	ローカル作業に切り替えを依頼。共有が必要な場合は添付メール送信で暫定対応

ダッシュボードには「一部ユーザーへの影響（Service Disruption）」と「全体停止（Service Outage）」の区別が表示されます。Service Disruption は機能の一部または特定地域への影響であることが多く、Service Outage は全ユーザー規模での停止です。この区別が「自社に影響があるかどうか」の最初の判断材料になります。

ステップ3：ユーザーへの通知（15分以内）

一つの原則を最初に押さえておきます。「GWSが落ちているのにGWSで通知しようとしない」です。Gmail が使えない状態で Gmail を送っても届きません。GWS とは別の連絡手段が必要になります（代替手段の詳細は後述します）。

通知の送信者は個人名ではなく「情報システム部」などのチーム名義にします。障害対応中は担当者が変わる場合があるため、個人名で通知すると引き継ぎ後に連絡先として機能しなくなります。

第一報は完璧な情報が揃ってから出す必要はありません。「現在障害が発生しており、調査中です。詳細は分かり次第連絡します」という一報を15分以内に出すことで、ユーザーからの問い合わせ量を大幅に減らせます。情報が不足していても、「状況を把握している情シスがいる」と伝えることが優先です。

ステップ4：継続対応（復旧まで）

ステータスダッシュボードを15〜30分おきに確認し、状況変化をユーザーに都度共有します。「復旧見込みが変わった」「影響範囲が拡大した」「別サービスにも波及した」などが通知対象です。ユーザーを不安にさせないためにも、「現在も対応中です」という定期更新に意味があります。

継続対応中は、タイムスタンプ付きのログを残しながら動きます。例として以下のような記録を残します。

09:10 Slack で「Gmailが使えない」という報告を受信
09:15 ダッシュボードで Gmail が Service Disruption 表示を確認
09:20 全社向けに第一報を Slack #general で送信
09:25 テザリングで Gmail 接続 → 問題なし（社内NW起因の可能性排除）
09:40 続報を Slack で送信（復旧見込み10:30頃）
10:35 ダッシュボードが正常表示に戻る
10:40 情シス側で Gmail 送受信・Drive アクセスを確認 → 問題なし
10:42 復旧通知を全社向けに送信

この記録が、後述のSLA申請や事後レビューの一次資料になります。

ステップ5：復旧後の確認と記録

ダッシュボードが正常に戻ったら、まず情シス側で主要サービスが実際に使えることを確認してから「復旧しました」通知を出します。ダッシュボードが正常になってもDNSキャッシュやアプリキャッシュの影響で、一部ユーザーが引き続き繋がらないケースがあります。特にモバイルアプリ経由のアクセスは、キャッシュのクリアや再起動が必要になる場合があるため、「問題が続く場合はアプリを再起動してください」と復旧通知に一言添えると問い合わせが減ります。

Google Workspace ステータスダッシュボードで最初に確認すること

Google が公式に提供するステータスダッシュボードでは、サービス別の稼働状況をリアルタイムで確認できます。追加の認証なしにどこからでもアクセスでき、GWS自体が使えない状況でも参照できます（Google Workspace 管理者ヘルプでは「Google Workspace ステータスダッシュボード」という名称で案内されています）。

ダッシュボードには4種類の状態表示があります。

• Available（正常）: サービスは通常通り稼働中
• Service information（お知らせ）: 障害ではなく Google からの情報提供がある状態。機能への影響はないが確認を推奨
• Service Disruption（一部影響）: 一部のユーザーや地域で問題が発生している状態。自社への影響有無は確認が必要
• Service Outage（全体停止）: 機能全体が利用できない状態

「Service Disruption」は機能の部分的な問題であるため、自社ユーザーには影響が出ていない場合もあります。報告内容と照合して、実際に影響が出ているかどうかを確認してから対応方針を決めます。

確認できる主なサービスには、Gmail / Google Drive / Google Meet / Google Calendar / Google Chat / Google Docs / Google Sheets / Google Slides / Google Vault などコアサービスが一覧で表示されます。インジケータをクリックすると、障害の発生時刻・影響範囲・Google の対応状況・復旧見込みが確認できます。

障害の自動検知を仕組みとして整備したい場合は、ステータスダッシュボードが提供するRSSフィードとJSONフィードが活用できます。また、管理コンソールのアラート機能から、サービス障害に関する通知メールを情シス宛に受け取る設定も可能です（詳細は Google Workspace 管理者ヘルプを参照）。人手による定期確認に頼らない体制を作るなら、まずこの自動通知の設定から始めることを推奨します。

ステータスダッシュボードの情報が出る前に報告が来た場合

ユーザーから「使えない」という報告が入っているのに、ダッシュボードがまだ「正常」を示している場合があります。このケースは2つの可能性があります。一つはGoogleの情報掲載が遅れているケース、もう一つは自社インフラ側の問題のケースです。ダッシュボードを15分おきに確認しながら、並行して自社側の切り分け（VPN / DNS / ファイアウォールのログ確認）も進めます。

GWSダウン時の代替連絡手段を確保する

GWSが落ちた状態でも社内連絡が機能するよう、代替手段を事前に確保して全社員に周知しておく必要があります。代表的な選択肢を以下に整理します。

手段	特徴	注意点
Slack	チャンネル単位で通知可能。既存ユーザーには即届く	GWSと独立したインフラで運用している場合が多い
携帯電話（通話 / SMS）	アプリ不要で確実に届く	全員の番号を事前に収集しておく必要がある
Microsoft Teams	通話・チャット・ビデオ会議の代替になる	Microsoft 365 ライセンスが別途必要
社内放送・物理掲示板	オフィス常駐者への物理的な通知手段	リモートワーカーには届かない

Slack を導入していない場合、最低限の備えは「各部門リーダーの携帯番号リスト」と「リーダーから各メンバーへ伝達する連絡ツリー」の整備です。

「代替手段を決めて終わり」にしないことも重要です。年に一度でもよいので、実際にその手段で連絡が届くかを確認する機会を作ります。Slackのアカウントが非アクティブになっていたり、携帯番号が変わっていたりするケースは実際にあります。

代替手段を全社に周知する進め方

代替連絡手段は「決めた」だけでは機能しません。以下のタイミングで繰り返し周知することが現実的に有効です。

• 新入社員オンボーディング時: IT環境案内の中に「GWS障害時の連絡先と手段」を1スライド追加する
• IT通知メールの定期発信時: 季節のセキュリティ情報などと合わせて年1回リマインドする
• オフィスの見える場所への掲示: 簡易版の連絡先表（Slackのチャンネル名・情シス直通番号）をA4で印刷してラミネートし、休憩スペースや会議室に貼っておく

特にリモートワーク主体の組織では、「印刷物を見せる」手段が使えないため、Slack または社用スマートフォンのメモアプリへの事前配布が現実的です。

ユーザー通知テンプレート例

障害時の通知は「何が使えないか」「いつ復旧見込みか」「代替手段は何か」の3点に絞ります。承認待ちや長文作成に時間を取られないよう、事前にテンプレートを用意し、空欄だけ埋める形にします。

Slack のピン留めや、GWSを使わずにアクセスできるドキュメントにテンプレートを保管しておくことを推奨します。GWS が落ちているときに Google ドキュメントを開こうとしても開けない、というケースを避けるためです。

第一報（障害発生時）

【GWS障害のお知らせ】
現在、〇〇サービスに障害が発生しています（〇時〇分〜）。
復旧見込み：〇〇（調査中の場合は「分かり次第お知らせします」）
緊急連絡：Slack またはXX-XXXX（情シス直通番号）にてお願いします。
— 情報システム部

続報（状況変化・定期更新）

【GWS障害 続報】
引き続き〇〇サービスの障害が継続しています（〇時〇分時点）。
Googleの復旧見込みは〇〇時頃です。追加情報は随時お知らせします。
— 情報システム部

原因調査中・復旧見込み不明の場合

【GWS障害 状況報告】
〇〇サービスの障害について、Googleが引き続き調査中です（〇時〇分時点）。
復旧見込みはまだ発表されていません。次回の状況報告は〇〇時頃を予定しています。
緊急対応が必要な場合は、情シスまで直接ご連絡ください。
— 情報システム部

復旧通知

【GWS復旧のお知らせ】
〇時〇分頃、〇〇サービスが復旧しました。
ご不便をおかけしました。引き続き問題がある場合はアプリを再起動してからお試しください。
それでも繋がらない場合は情シスまでご連絡ください。
— 情報システム部

「〇〇」の部分だけ埋めれば使えるよう、全文をあらかじめ用意します。完璧な文章よりも、15分以内に出せる簡潔な内容のほうがユーザーへの安心感につながります。

障害発生時のインシデント記録の残し方

障害対応中の記録は、後から「どういう対応をしたか」を説明するための唯一の根拠になります。振り返りとSLA申請の両方で使えるように、以下のフォーマットで残すことを推奨します。

【GWSインシデント記録】
発生日時：YYYY-MM-DD HH:MM
検知方法：ユーザー報告 / 自動アラート / 情シス自身の確認
影響サービス：Gmail / Drive / Meet / Chat / その他（具体的に）
影響範囲：全社 / 一部部署 / 特定機能のみ / 一部地域

タイムライン：
  HH:MM — 検知/確認/通知/対応内容を記載
  HH:MM — （続く）

第一報送信日時：HH:MM
代替手段案内日時：HH:MM（案内した手段の名称）
復旧確認日時：HH:MM（情シス側での動作確認完了時刻）
復旧通知送信日時：HH:MM

対応者：氏名 または 役割
次回の改善点：
  - （例）管理コンソールのアラート通知をまだ設定していない → 今週中に設定する
  - （例）通知テンプレートの保管場所を Slack のピン留めに追加する

このフォーマットをスプレッドシートの1シートとして用意し、障害発生のたびに1行追加する運用にすると、年間の障害傾向（発生頻度・影響サービスの偏り・平均復旧時間）を後から分析できます。「Gmail が年に何回落ちているか」「平均で何分で第一報を出せているか」という数字が見えるようになると、次のBCP設計の材料になります。

SLAとサービスクレジット申請の仕組み

Google Workspace の SLA（Service Level Agreement）は、月次稼働率を99.9%以上と保証しています。この水準を下回った場合、サービスクレジットを申請できます。

クレジット額の基準は以下の通りです（Google Workspace 公式SLAより）。

月次稼働率	クレジット
99.0% 以上 99.9% 未満	3日分
95.0% 以上 99.0% 未満	7日分
95.0% 未満	15日分

申請には Google のサポートケースを、障害終了から 30日以内 に作成する必要があります。この期限を過ぎると申請権利を失います。前述のインシデント記録フォーマットでタイムスタンプ付きの記録が残っていれば、申請時の情報整理が格段に楽になります。

ただし実際のところ、GWSが月次SLAを下回るほどの大規模障害は年間を通じて頻繁には起きません。クレジット申請の優先度よりも、初動対応とユーザー影響の最小化が情シスの本来のミッションです。「障害記録を残す理由の一つ」としてSLA申請の仕組みを把握しておく、という位置付けが現実的です。

Workspace 障害 BCP のための事前準備チェックリスト

対応フローを決めても、事前の準備が整っていなければ本番で機能しません。以下の項目を確認しておきます。

代替連絡手段の整備

• GWS以外の代替連絡手段（Slack / SMS / 電話など）が確定しており、全社員に周知されている
• 各部門リーダーの携帯番号を情シスが把握している
• 連絡ツリー（部門リーダー → 各メンバー）の構成が文書化されている

ステータス確認の仕組み

• Google が提供するステータスダッシュボードの URL が、情シスチームでブックマークまたはドキュメント化されている
• 管理コンソールのアラート機能から、障害発生時に自動で通知を受け取る設定が済んでいる

通知と記録の準備

• ユーザー通知テンプレート（第一報・続報・復旧通知）が、GWSが使えない環境からでもアクセスできる場所に保管されている
• 障害記録フォーマット（発生時刻・影響範囲・対応内容・復旧時刻）が用意されている
• インシデント記録の保管先（スプレッドシートまたはGWS外のドキュメント）が決まっている

定期確認の仕組み

• SLAクレジット申請の窓口（Google サポートポータル）を把握している
• 代替連絡手段が実際に機能するかを年に一度確認するスケジュールが決まっている
• 新入社員のオンボーディング資料に障害時の連絡先・代替手段が記載されている

全項目が整っていれば、障害発生時に「何から手をつければいいか」で迷う時間がなくなります。未整備の項目があれば、次の定例MTGのアジェンダに入れることが最初のアクションです。

まとめ

GWSの障害対応で押さえるべき核心は「GWSが使えない時の手順と連絡手段を、GWSが使える平常時に決めておく」という点です。

初動の5ステップ（確認→判断→通知→継続対応→記録）は、テンプレートとして文書化しておけば1〜2名体制でも十分に対応できます。「ステータスダッシュボードを先に見る」「テザリングで切り分ける」というルールが定着するだけでも、自社インフラ問題との判別に使う時間が大幅に短縮されます。

障害対応の品質は、平常時の準備量に比例します。通知テンプレートの置き場所を決める、部門リーダーの携帯番号リストを作る、管理コンソールのアラート通知を設定する——これらは1時間以内に着手できる準備です。次に障害が起きたときに「仕組みがあってよかった」と思えるかどうかは、今日の取り組み次第です。GWSの運用体制の見直しや、BCP設計全般のご相談は以下からどうぞ。

コーポレートITのご相談はお気軽に

この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。