Google Workspace 管理者引き継ぎ完全チェックリスト

Google Workspace では、管理者アカウント・課金担当者・外部連携アプリ・Vault 保持ポリシーなど、引き継ぎ対象の設定情報が複数のカテゴリに分散しています。この記事では、担当者交代時に確認すべき項目をフェーズ別チェックリストとして整理します。

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

• 人事異動や退職によって GWS（Google Workspace）の管理担当者が変わる予定がある組織の前任者・後任者
• 情シスが1〜2名体制で、管理者ロールが特定の個人に集中している会社
• 業務委託先が GWS を管理しており、契約終了に伴う引き継ぎを控えている
• 「とりあえずスーパー管理者を追加した」以外の引き継ぎ手順がない状態の情シス担当者

引き継ぎを始める前に整理しておくこと

引き継ぎはスーパー管理者のパスワードを一つ渡せば終わりではありません。GWS の管理範囲には「誰が何の権限を持っているか」だけでなく、課金情報・外部連携・ログ設定など、担当者の頭の中にしか存在しない設定が積み重なっています。

作業を始める前に、次の3点を確認します。

• スーパー管理者は2名以上いるか: Google は複数のスーパー管理者を維持することを推奨しています。1名しかいない状態でその担当者が急に離脱すると、アカウントロック時の回復手段がなくなります
• 引き継ぎドキュメントは存在するか: 設定変更の経緯・カスタム設定の意図・例外ルールが文書化されていないと、後任者は現状把握から始めることになります
• 引き継ぎ期間はどれくらい確保できるか: 最低1ヶ月の重なり期間を設けるのが現実的です。即日交代は極力避けてください

引き継ぎドキュメントには最低限以下の内容を記載しておくことを推奨します。

• 組織単位（OU）の構造と、その設計意図（例: 「正社員・業務委託・テスト用を OU で分けた理由」）
• カスタム管理者ロールの一覧と、各ロールを誰に付与しているか・付与した理由
• 接続している OAuth アプリの用途（「このアプリを許可している背景」）
• Vault の保持ポリシーを設定した背景（法務要件なのか IT 部門の独自判断なのか）
• 過去に発生したインシデントとその対処の記録

こうした「判断の経緯」がドキュメントに残っていないと、後任者は設定の正否を判断できないまま運用を続けることになります。「設定は引き継いだが意味は分からない」という状態が、次の問題の温床になります。

引き継ぎ1ヶ月前から始めるチェックリスト

以下のカテゴリ別に、前任者が担当して整理しておくべき項目を示します。

スーパー管理者権限の棚卸し

現時点でスーパー管理者ロールを持っているアカウントを洗い出すところから始めます。管理コンソールのユーザー管理画面でロールによるフィルタリングが可能です。

• [ ] スーパー管理者ロールを保持しているアカウントを一覧化する
• [ ] 後任者のアカウントにスーパー管理者ロールを付与する
• [ ] 前任者以外に別のスーパー管理者がいる場合、後任者との連絡経路を確保する
• [ ] 個人の gmail.com アカウントでスーパー管理者操作をしていないかを確認する（GWS ドメインのアカウントで管理すること）
• [ ] スーパー管理者が1名しかいない場合、Google サポートへの緊急連絡手順を文書化する

スーパー管理者はすべての設定にアクセスできる最上位の権限です。退職者アカウントにこのロールが残ったままアカウントが停止されると、そのアカウントを経由した認証操作ができなくなります。また、一時停止後もサードパーティアプリの OAuth 許可は自動では取り消されません。不要なアプリのアクセス権は、停止処置の前に明示的に取り消しておく必要があります。

課金担当者・連絡先情報の確認

課金通知メール（請求書・更新通知など）はデフォルトでスーパー管理者のメールアドレスに届く設定になっています。担当者交代のタイミングで、受信先をグループアドレス（例: it-admin@company.com）に変更しておくことを推奨します。退職者が担当者のまま離脱すると、更新通知・請求書の宛先が元担当者のメールアドレスに届き続けます。最悪のケースでは、支払い期限の通知が誰にも届かずサービスが停止するリスクがあります。

• [ ] 管理コンソールの課金設定画面で、請求書・通知メールの受信先アドレスを確認する
• [ ] 課金担当者・連絡先メールアドレスを会社のグループアドレス（例: it-admin@company.com）に変更する
• [ ] 緊急連絡先電話番号が最新のものになっているか確認する
• [ ] Google からの通知メール（セキュリティ警告・利用状況レポートなど）の配信先を確認・更新する

通知メールの宛先を個人アカウントではなくグループアドレスにしておくと、担当者が変わったときも通知が途切れません。引き継ぎのタイミングにかかわらず、普段から設定しておくべき事項です。課金関連通知は見逃すと直接的な業務影響に直結するため、このカテゴリを最優先で確認します。

外部連携アプリ（OAuth）の棚卸し

管理コンソールのセキュリティ設定（API の制御セクション）から、組織に接続しているサードパーティアプリを確認します。

• [ ] 現在接続されている OAuth アプリの一覧を取得する
• [ ] 使用者が不明または不要になったアプリをリスト化し、アクセスを取り消すかどうか判断する
• [ ] Marketplace アプリの許可ポリシー（全許可・許可リスト制・全拒否）が意図した設定になっているか確認する
• [ ] ドメイン全体の委任（Domain-wide delegation）が付与されているアプリ・サービスアカウントを一覧化し、用途を確認する

ドメイン全体の委任は、GWS 全ユーザーのデータへのアクセスを一括許可する非常に強い権限です。用途が不明なものは後任者と協議して整理してください。

用途が説明できないアプリには、一度アクセスを取り消してから改めて必要性を確認し、必要なら再許可する対応が安全です。ただし、取り消すと連携が停止するため、ユーザー部門への影響確認を先に行います。特に自動化スクリプト（GAS 含む）でドメイン全体の委任を使っている場合、そのスクリプトの内容を後任者が理解できているかを確認します。理解されないまま引き継ぐと、誤って委任を削除してしまい業務が止まる事故につながります。

サービスアカウントの棚卸し

GAS（Google Apps Script）や社内システムから GWS API を呼び出すためにサービスアカウントを使っている場合、そのアカウントが前任者個人の Google Cloud プロジェクトに紐付いていないかを確認します。

• [ ] GWS API と連携しているサービスアカウントの所有プロジェクトを特定する
• [ ] プロジェクトの所有者が前任者の個人アカウントになっていないかを確認する
• [ ] 必要であれば、会社ドメインのアカウントが管理する共有プロジェクトへの移管を検討する
• [ ] サービスアカウントの鍵ファイル（JSON キー）がチーム共有のパスワードマネージャー等、安全な場所に保管されているかを確認する
• [ ] スクリプト・連携アプリが使うサービスアカウントの一覧と各アカウントの用途を文書化する

特に注意が必要なのは、前任者の個人 Google Cloud プロジェクトにサービスアカウントが作成されているケースです。前任者のアカウントが停止・削除されると、プロジェクトへのアクセス権が失われ、GAS マクロや API 連携が突然動作しなくなります。「退職後しばらくして突然スプレッドシートのマクロが動かなくなった」という報告の原因として、このパターンはよく発生します。退職前に必ず確認します。

Vault 保持ポリシーと法的保留の確認

Google Vault（eDiscovery・電子証拠保全ツール）が有効な場合、既存の保持ポリシーと保留（Hold）を確認しておく必要があります。vault.google.com から直接アクセスできます。

• [ ] 現在有効な保持ルール（Retention rule）を一覧化する
• [ ] 法的保留（Legal hold）が掛かっているユーザー・データがないかを確認する
• [ ] Vault の管理者権限を後任者に付与する
• [ ] vault.google.com へのアクセスを後任者と一緒に実機で確認する

法的保留が掛かっているユーザーのアカウントを削除すると、対象データが失われるリスクがあります。退職者アカウントを削除する前に、必ず法務部門と連携して確認してください。

Vault の保持ポリシーは管理コンソール側の設定（例: ドライブの共有設定やゴミ箱のデータ保持）とは独立して動作します。「管理コンソールで特に設定していないから問題ない」とはならないため、Vault を契約しているなら vault.google.com の設定を直接確認してください。なお、Vault のメイン操作はこの専用 URL 上で行い、管理コンソール側はおもに権限付与とサービスの有効化のみを担当します。

2段階認証（2SV）の回復手段の整備

• [ ] スーパー管理者アカウントに2段階認証が設定されているか確認する
• [ ] 後任者のアカウントで回復用電話番号・メールアドレスが登録されているか確認する
• [ ] 認証器（ハードウェアキーや認証アプリ）の引き渡しまたは後任者による再セットアップを実施する
• [ ] 2段階認証の回復コードをパスワードマネージャーなど安全な場所に保管する
• [ ] 組織全体の 2SV 強制ポリシーが意図した設定になっているかを確認する

スーパー管理者アカウントに対しては、FIDO2 対応のハードウェアセキュリティキーの使用が推奨されます。認証アプリ（TOTP）よりフィッシング耐性が高く、管理者アカウントの保護に適しています。

組織全体で 2SV 強制ポリシーを設定している場合、後任者が 2SV のセットアップを完了する前にポリシー確認を行うと、意図せずロックアウトが発生するケースがあります。2SV のセットアップを先に完了させてから、ポリシー設定の確認に進む順番を守ってください。

委任管理者とカスタムロールの確認

スーパー管理者以外に「委任管理者（Delegated admin）」ロールを持つユーザーが存在する場合があります。ユーザー管理のみを担当する管理者・ヘルプデスクロール・レポート閲覧専用ロールなど、組織の運用に応じてカスタムロールが設定されているケースは少なくありません。

• [ ] 委任管理者ロールを持つユーザーの一覧を取得する
• [ ] カスタムロールが作成されている場合、各ロールに付与されている権限と付与理由を確認する
• [ ] 後任者がカスタムロールを自分で確認・編集できることを実機テストする
• [ ] 退職する前任者が委任管理者として登録されている場合、ロールを削除する

委任管理者は部門システム担当者やヘルプデスク担当者に付与されることが多く、スーパー管理者よりも見落とされやすい存在です。「誰がどの権限で何をできるか」の全体像を後任者に伝えることが、引き継ぎの本質です。「スーパー管理者は引き継いだが、ヘルプデスクロールを持っていた前任者が誰かに付与したままになっている」という状況が後になって発覚するケースがあります。

引き継ぎ当日のチェックリスト

1ヶ月前からの準備が整った上で、当日は以下を確認します。

後任者アカウントの最終確認

• [ ] 後任者がスーパー管理者権限で管理コンソールにログインできることを実機確認する
• [ ] 課金管理画面にアクセスできることを確認する
• [ ] Vault（vault.google.com）にアクセスできることを確認する
• [ ] 引き継ぎドキュメントの共有ドライブ上の場所を後任者と口頭で確認する
• [ ] 後任者が実際に設定を変更し、元に戻せることを確認する（「見えるだけで操作できない」状態を防ぐ）

最後の項目は見落とされやすいポイントです。権限が付与されていても、特定の OU やグループへの操作が制限されていると、後任者が実際には変更できないケースがあります。試験的な設定変更で動作確認しておくと安心です。変更する項目は影響範囲が小さいものを選び、確認後は元の値に戻してください。

前任者アカウントの処置

前任者アカウントをその日のうちに削除してはいけません。退職後一定期間は「一時停止」状態にしておき、データ移行・メール転送の設定が完了してから削除を判断します。

• [ ] 前任者アカウントを削除せず「一時停止」に設定する
• [ ] メールの自動転送または代理受信の設定を確認する
• [ ] 一時停止後にスーパー管理者ロールを前任者から削除する
• [ ] 前任者が所有するドキュメント・カレンダー・共有ドライブのオーナー移管スケジュールを確認する

一時停止状態でも、データ（Google ドライブのファイル・Gmail のメールなど）はアカウントが削除されるまで保持されます。Vault の保持ポリシーが設定されている場合は、ポリシーの保持期間も考慮してアカウント削除のタイミングを決めてください。「退職したからすぐ削除」という運用ルールがある場合は、必ず法務・コンプライアンス担当と擦り合わせた上で決定してください。

後任者が着任後1週間でやること

次の項目は引き継ぎ当日に完了しなくても構いませんが、1週間以内に着手してください。

• [ ] Google からの通知メールが自分のアドレスに届くことをテストする
• [ ] 管理コンソールのセキュリティダッシュボードとアラート設定を確認する
• [ ] 監査と調査（Audit and investigation）から直近のログに異常がないかを確認する
• [ ] 前任者との引き継ぎMTGで未解決だった事項を文書化し、期日を設けて対処する
• [ ] 週次・月次の自動レポートの送信先が自分のアドレスに更新されているかを確認する
• [ ] 引き継ぎドキュメントを読み、意図が不明な設定を前任者に確認する（連絡が取れる最後の機会になる場合が多い）

「自動レポートの送信先」は引き継ぎで特に見落とされやすい項目です。前任者のアドレスに毎週レポートが届き続けていることに誰も気づかないまま数ヶ月が経過するケースは実際に起きています。着任直後に一度、全ての自動通知の宛先を確認しておくことを推奨します。

前任者への問い合わせ窓口は時間とともに閉じていきます。「あとで聞けばいい」と後回しにした事項が残ったまま前任者と連絡が取れなくなると、独力で現状把握をするしかなくなります。1週間のうちに「不明点リスト」を前任者に送り、回答をもらっておくことが効果的です。

見落としやすい3つの落とし穴

チェックリストを進める中で、実際によく見かける失敗事例を整理します。

退職当日にアカウントを削除してしまう

なぜ起きるか: 「退職者のアカウントを素早く削除してセキュリティを守る」という意識自体は正しいのですが、削除のタイミングを誤ると大きな問題が発生します。退職後の不正アクセスリスクと、削除によるデータ消失リスクを同時に考える視点が必要です。

退職者アカウントを即日削除した結果、Vault に保全されていたデータが消失したり、Google からの通知が届かなくなったり、サービスアカウントの OAuth 連携が壊れたりする事故が起きます。アカウント削除のタイミングは Vault の保持ポリシーに合わせて決定するのが原則です。Vault の保持ルールに設定されている保持期間が終わるまでは削除しないことが基本で、具体的な日数は組織の Vault ポリシーに合わせて決定してください。

どう防ぐか: 退職者アカウントの処置フローを事前に文書化し、「一時停止 → データ移行 → 保持期間確認 → 削除」の順番を組織のルールとして決めておきます。個人の判断で削除しないルールを設けるだけで、このリスクは大幅に下がります。

スーパー管理者ロールだけを移管して終わりにする

なぜ起きるか: 「管理者権限を渡した＝引き継ぎ完了」と認識していることが多いです。権限があれば後任者が自分で調べられると思いがちですが、GWS は設定の全体量が多く、何をどこで設定しているかを把握するだけでも相当な時間がかかります。

権限移管後に、後任者が課金メールを受け取れない・Vault にアクセスできない・一部の API 連携が壊れていると気づく事例は少なくありません。ロール移管と設定引き継ぎは別の作業として、カテゴリ別に確認する必要があります。

どう防ぐか: この記事のチェックリストのように、「前任者が整理する事項」と「後任者が動作確認する事項」をカテゴリ別に分けて管理します。権限移管はゴールではなく、引き継ぎの前提条件です。

引き継ぎドキュメントが存在しない

なぜ起きるか: 管理業務が1人に集中していると、設定内容が担当者の記憶に依存しやすくなります。「自分がやってきたことは分かっているから、口頭で説明すれば済む」という認識が、ドキュメント不在につながります。口頭での引き継ぎは、後任者が実際に困ったときに情報を参照できません。

設定の「意図」が引き継がれないと、後任者はすべての設定を一から調査することになります。カスタム OU の構造・特定グループへの例外設定・承認済み OAuth アプリのリストなど、管理コンソールを見ても経緯がわからない設定は、前任者が在籍中に必ず文書化してください。

どう防ぐか: 引き継ぎ時点から文書化を始めるのでは間に合わない場合があります。普段から設定変更のたびに変更ログ（何を変えた・なぜ変えた）を残す習慣を持つことが、最終的に最もコストの低い対策です。変更ログを Google スプレッドシートや共有ドキュメントに蓄積しておくだけで、引き継ぎの品質が大きく変わります。

まとめ

GWS の担当者引き継ぎは、権限のパスを一つ渡せば終わりではありません。課金担当者・OAuth 連携・Vault・サービスアカウント・委任管理者ロールはそれぞれ独立して管理されており、1つでも見落とすと後任者が問題に気づいたときには対処が難しくなっています。

この記事のチェックリストを「1ヶ月前・当日・1週間後」の3フェーズで使い、カテゴリごとに担当者を決めて進めることで、引き継ぎの漏れを大幅に減らせます。

引き継ぎが終わった後も、定期的な棚卸しを推奨します。OAuth アプリのリスト・委任管理者の一覧・Vault のポリシー設計は、半年に一度見直す習慣を持つことで、次の引き継ぎ時の作業コストが下がります。「引き継ぎが発生してから整理する」ではなく、「常に引き継げる状態を維持する」が情シス運用の基本姿勢です。

自社の設定が複雑で引き継ぎ可能な状態かどうか判断しにくい場合は、GWS 管理の専門家に棚卸しのサポートを依頼するのも現実的な選択肢です。

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

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