Google Workspace のスーパー管理者（Super Admin）アカウントがロックアウトされた場合、または担当者が突然退職した場合に復旧できる設計が整っていないと、組織全体の管理機能が停止します。この記事では、情シス担当者がスーパー管理者アカウントを保護し、緊急時に復旧できる設計の判断軸を整理します。
この記事を読んだほうが良い人
- GWS（Google Workspace）のスーパー管理者が社内に1名しかいない環境を担当している方
- スーパー管理者のロックアウトや担当者離脱に備えた設計がまだできていない方
- CAA・MDM・DLP など GWS セキュリティを整えているが、管理者アカウント自体の BCP が手つかずの方
- 担当者交代時の引き継ぎ手順を文書化していない方
なぜ管理者アカウントの BCP が抜けやすいのか
GWS のセキュリティ設計では、CAA（Context-Aware Access：端末条件でアクセスを制御する仕組み）、MDM（Mobile Device Management：端末管理）、DLP（Data Loss Prevention：データ流出防止）といった施策が積み上がっていきます。ところが、それらを管理するスーパー管理者アカウント自体が失われた場合、すべての設定変更も緊急対応も止まります。
100名規模の企業では情シス担当者が1〜2名であることが多く、スーパー管理者を実質1名で運用しているケースは珍しくありません。その担当者が次のいずれかの状況に置かれると、組織は即座に詰みます。
- 2SV（2段階認証：ログイン時に2つの認証要素を求める仕組み）の強制適用後、設定を完了していなくてロックアウトされた
- MFA（多要素認証）デバイスを紛失した、または機種変更で認証アプリが引き継がれなかった
- 担当者が退職し、スーパー管理者権限を持つアカウントが誰にも使えない状態になった
こうした事態は周辺のセキュリティ強化が進むほど起きやすくなります。2SV 強制適用が「スーパー管理者アカウント自体のロックアウト」に直結するためです。
特に問題になりやすいのが「展開タイミングのミス」です。組織全体への 2SV 強制を先に有効化し、スーパー管理者自身の 2SV 設定がまだ完了していない状態が生まれます。担当者がその状態でログインしようとすると、段階的にアクセスが制限され、最終的には Web アプリへのアクセスも遮断されます。セキュリティ強化の手順を一つ間違えるだけで、強化策が自分たちのアクセスを断ち切る逆効果になります。
「CAA や MDM を整えているのにスーパー管理者アカウントが詰んだ」という状況は、周辺を固めれば固めるほど管理者アカウントへの依存度が上がる構造から来ています。管理コンソールへのアクセスを失うと、CAA のポリシー変更も、MDM の端末登録解除も、ユーザーアカウントのパスワードリセットも、すべて止まります。
適正なスーパー管理者数の設計基準
スーパー管理者は少なくとも2名以上設置することがベストプラクティスとして広く推奨されています。1名だけでは単一障害点になるためです。
実務での設計基準として、次の3役割を意識すると判断しやすくなります。
| 役割 | 人数 | 方針 |
|---|---|---|
| プライマリ管理者 | 1名 | 日常的な管理操作を担う主担当者 |
| バックアップ管理者 | 1名 | プライマリが不在・ロックアウト時に対応 |
| 緊急アクセス用アカウント | 1つ | 特定の個人に紐付けず、認証情報を安全な場所に保管 |
最小構成は「プライマリ + バックアップ」の2名ですが、両者が同時に離脱するリスク（退職・長期休暇・組織変更の重なり）を考えると、緊急アクセス用のアカウントを1つ用意しておくと安全マージンが確保できます。
緊急アクセス用アカウントの命名と運用
緊急アクセス用アカウントは、特定の担当者名に紐付けないことが重要です。tanaka@company.com のように個人名が入ったアカウントは、その人の退職時に権限整理の対象になり、誤って削除や停止されるリスクがあります。it-admin-emergency@company.com のような役割ベースの名前を使うことで、「このアカウントは緊急用」という認識が組織内で維持されます。
認証情報の保管は2系統が基本です。一つは組織共有のパスワードマネージャー（LastPass Teams・1Password Business など）、もう一つは封印した物理的な紙を施錠可能な場所に保管するアナログ保管です。クラウドストレージへの保管だけでは、GWS 自体にアクセスできない状況でその情報も取り出せなくなります。
また、緊急アクセス用アカウントが実際に機能するかを定期的に確認することも必要です。四半期に一度程度、ログインと基本操作ができることをテストして記録に残しておくと、いざというときに「認証情報が失効していた」という事態を防げます。
ただし、スーパー管理者の数を増やすほど攻撃面も広がります。日常業務の大半は権限を絞った委任管理者ロールに割り当て、スーパー管理者権限は本当に必要な操作だけに絞る設計が原則です。
Google Workspace 管理者アカウント 復旧オプションの優先順位
スーパー管理者がアクセスできなくなった場合、回復の手段は複数あります。Google の公式ヘルプに基づいて、優先度の高い順に整理します。
優先度1: 別のスーパー管理者による操作
別のスーパー管理者アカウントが存在すれば、管理コンソールのユーザー設定からロックされたアカウントのパスワードリセットや 2SV 解除が可能です。最速で最も確実な手段であり、事前準備なしに即日対応できるのもこの方法だけです。複数の管理者を設置しておく最大の理由がここにあります。
優先度2: スーパー管理者の自己回復（回復情報登録済みの場合）
管理コンソールのセキュリティ設定でスーパー管理者の自己回復が有効になっており、かつ回復用メールアドレスまたは電話番号が登録されている場合、サインイン画面から自己回復が使えます。
ただし、Google は新規の GWS・Cloud Identity 顧客に対してスーパー管理者の自己回復をデフォルトで無効にしています。セキュリティリスクを防ぐためです。複数の管理者を確保できている組織では無効のままにしておくのが望ましく、1名しかいない組織では有効にして回復情報を事前登録しておく判断になります。この設定は事前に行っておかないと、ロックアウトが発生した後から変更することはできません。
優先度3: ドメイン所有権の確認による回復
別のスーパー管理者がおらず自己回復も使えない場合、ドメインの DNS に CNAME または TXT レコードを追加してドメイン所有権を証明する方法があります。これはドメインレジストラへのアクセスが必要で、DNS レコードの反映を含めて処理完了まで最大72時間かかることがあります。
ドメインレジストラのログイン情報が失われていると、このルートも使えなくなります。ドメインレジストラの認証情報を組織として管理し、担当者個人のアカウントだけに依存しない体制が必要です。
優先度4: Google サポートへの連絡（サポート支援回復）
上記の手段が取れない場合は、Google Workspace サポートに連絡してサポート支援による回復を依頼します。本人確認・ドメイン所有確認が必要で、対応完了まで数日単位の時間がかかります。このルートは「最後の手段」であり、計画的に使うものではありません。
設計判断のポイント
優先度2〜4はいずれも事前準備がなければ使えない、または時間がかかります。即日復旧が必要な状況では、優先度1（別のスーパー管理者）以外の選択肢は実質的に機能しません。4つの回復ルートのうち、事前準備なしに使えるのは「既に別のスーパー管理者がいる」場合だけという構造を理解した上で設計してください。
GWS 緊急アクセス 設計：2SV 適用前に確認すること
組織全体に 2SV を強制適用する前に、スーパー管理者自身の設定が完了していない状態で適用を始めると、管理者アカウントがロックアウトされます。Google の公式ヘルプによると、2SV 強制適用後に登録を完了していない管理者は段階的にアクセスが制限され、最終的には Web アプリへのアクセスも遮断されます。
2SV の展開順序
2SV を組織に展開するときは、次の順序を守ることで管理者ロックアウトを防げます。
- スーパー管理者全員の 2SV 設定を完了させる（バックアップコード取得を含む）
- 2SV 強制をスーパー管理者に対して有効にし、動作確認を行う
- 問題がないことを確認してから、一般ユーザーへの強制適用を段階的に展開する
一般ユーザーへの強制適用を先に走らせると、スーパー管理者自身が強制の対象に含まれる場合があり、管理者ロックアウトに直結します。管理者自身の設定完了と動作確認を先に済ませることが最初の確認事項です。
認証方法と保管の選択
認証方法は複数の選択肢がありますが、ハードウェアセキュリティキー（Google Titan Security Key など）が最も耐障害性の高い選択肢です。ただし、紛失した場合に備えてバックアップコードとの併用が必要で、バックアップコードはオフラインで保管します。
SMS 認証だけに依存するのは SIM スワップ攻撃のリスクがあるため、スーパー管理者アカウントでの利用は推奨されません。Google Authenticator などのアプリ認証と組み合わせることで、端末紛失・機種変更の際にバックアップコードで回復できる構成が現実的です。
バックアップコードのオフライン保管は特に重要です。GWS 自体にアクセスできない状況でクラウドストレージに保存したバックアップコードも取り出せなくなるためです。印刷して施錠可能な場所に保管するか、緊急アクセス用アカウントと同様に2系統で管理することを推奨します。
2SV を組織に展開する前に、スーパー管理者アカウントについて以下を確認してください。
- 全スーパー管理者アカウントで 2SV が有効になっているか
- バックアップコード・代替電話番号など、複数の確認方法が設定済みか
- バックアップコードを印刷またはオフラインで保管しているか
- SMS のみの認証になっていないか（SIM スワップリスクの確認）
Google Workspace 管理者 引き継ぎ：担当者交代時の設計
スーパー管理者が退職・部署異動する際、アカウントの引き継ぎと削除を正しい順序で行わないと、新担当者が着任した時点で管理者アカウントがゼロになるリスクがあります。退職プロセスにスーパー管理者の引き継ぎを組み込んでください。
計画的な交代の場合：退職の2週間前までに着手する
退職日の直前では時間が足りません。後任者の管理コンソール操作の習熟時間や、問題が発生した場合の修正時間を確保するため、遅くとも退職日の2週間前から以下の作業を始めます。
退職・交代の前に完了させること:
- 後任者のアカウントをスーパー管理者に昇格させる（先に昇格、後で剥奪の順が絶対原則）
- 後任者が管理コンソールの基本操作を実際に行えるかをテストして確認する
- 緊急アクセス用アカウントの認証情報を後任者に引き継ぐ
- ドメインレジストラのログイン情報が後任者に共有されているか確認する
退職後に実施すること:
- 退職者のスーパー管理者権限を剥奪してから、アカウントを停止または削除する（順番を逆にするとロックアウトの原因になる）
- 退職者が個人の電話番号・個人メールアドレスを 2SV 連絡先や回復情報として登録していた場合は、必ず変更または削除する
突発的な離脱（急な退職・連絡不能）の場合
計画的な引き継ぎができなかった場合、まず管理コンソールにアクセスできる別のスーパー管理者がいるかを確認します。いれば、そのアカウントから退職者の 2SV 設定と回復情報をリセットし、アカウントの権限剥奪・停止を進めます。
別のスーパー管理者がいない状態であれば、前述の優先度3（ドメイン所有権確認）または優先度4（Google サポート）のルートになります。この段階まで来ると即日解決はほぼ不可能です。突発的な離脱への最低限の備えとして、ドメインレジストラのログイン情報だけでも組織管理しておくことが重要です。
オフボーディングで見落とされやすいのが「退職者の個人連絡先の削除」です。退職者の個人電話番号が 2SV 連絡先として残ったままだと、そのアカウントの回復フローが元担当者の端末に届く状態が続きます。オフボーディングのチェックリストに「2SV 連絡先・回復情報のリセット」を明示的に含めてください。
まとめ：今日から設計を始める
スーパー管理者アカウントの BCP は、CAA や MDM を整える前に固めておくべき基盤です。周辺を整えても、管理者アカウントへのアクセスが失われると設定変更も緊急対応も止まります。
まず現状を把握するために、次の4点を確認することから始めてください。
- 組織内のスーパー管理者が2名以上いるか
- 全スーパー管理者アカウントで 2SV とバックアップコードのオフライン保管が完了しているか
- ドメインレジストラのログイン情報が組織として管理されているか
- 担当者交代の手順がオフボーディングフローに含まれているか
これらが揃っていない状態で GWS のセキュリティ強化を進めると、強化施策そのものがロックアウトの引き金になることがあります。ゼロトラスト設計の「ゼロ番目」として、管理者アカウントの設計から手をつけることが重要です。
4点すべてに自信を持って「YES」と答えられれば、ひとまず最低限の BCP は整っています。1つでも「NO」があった場合は、次の更新作業・人事異動の前に対処する優先度を上げてください。スーパー管理者のロックアウトは、備えていれば「想定内のトラブル」で済みますが、備えなければ「組織の管理機能が止まる危機」になります。
コーポレートITのご相談はお気軽に
この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。
御社の IT 部門、ここにあります。
「ITのことはあまりわからない」── そのような状態からで、まったく問題ございません。まずはお気軽にご相談ください。