Gmail自動転送の無効化と棚卸し手順：退職者対応の情シス実務

Google Workspace では、ユーザー自身が Gmail の設定から任意のアドレスへの自動転送ルールを作成できます。管理者が明示的に制限しない限り、この機能はデフォルトで全ユーザーに対して有効のままです。

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

• 100名前後の規模で Google Workspace を管理している情シス担当者
• 退職者・異動者のアカウント処理（オフボーディング）を担当している方
• Gmail のセキュリティ設定は一通り実施したが、自動転送ルールの管理が曖昧になっている方
• 「誰が、どこへメールを転送しているか」を組織として把握できていないと感じている方

退職者のメール転送が情報漏洩につながる理由

Gmail の自動転送ルールは、ユーザーが自分のアカウントから任意のメールアドレスへの転送を設定する機能です。業務上の利便性のために使われることもありますが、情シス観点では次の二つのリスクがあります。

個人アドレスへの転送によるデータ持ち出し

在職中に個人メール（外部のフリーメール等）への転送ルールを設定し、業務メールを個人デバイスで受け取り続けるケースがあります。転職・退職を控えた時期に顧客情報や提案書が含まれるメールをまるごと個人アドレスへ転送されると、後からアカウントを停止しても転送先にはすでにデータが届いています。

このリスクがやっかいなのは「見えにくさ」にあります。管理コンソールのトップ画面や標準的なセキュリティダッシュボードには、各ユーザーの転送設定が一覧表示されません。情シスが個別に確認しにいかない限り、退職者が転送を設定していたことに数週間後に気づく、という事態になりやすいです。退職日にアカウントを停止しても、それより前から転送されていたメールは取り戻せません。

アカウント侵害時の盗聴手段として使われるリスク

フィッシングやパスワード漏洩でアカウントを乗っ取った攻撃者が、発覚を遅らせながら外部アドレスへの転送ルールを設定してメールを継続的に収集するという手口は、実際のインシデントで繰り返し見られるパターンです。Google Workspace のアラートセンターにも不審な転送ルールの追加を検知するアラート種別が用意されており、それだけリスクとして認識されている機能です。

厄介な点は、パスワードリセットや MFA の再設定を完了した後も、転送ルールを削除していなければ侵害が継続するところです。セキュリティ対応が「完了した」つもりでも、転送だけが残り続けてしばらく気づかないまま情報が流れ続けます。

二つのリスクに共通するのは、転送ルールが「設定した本人がいなくなっても、ルールだけが残り続ける」という点です。情シスが能動的に管理していなければ、誰が何を転送しているかを把握できないまま運用が続きます。

Google Workspace メール転送ポリシーの設定方針

管理コンソールの Gmail 設定には、ユーザーによる自動転送ルールの作成を組織単位（OU: Organizational Unit）ごとに制御できるオプションがあります。この設定を無効化すると次のように変わります。

• ユーザーは Gmail の設定画面から新しい転送先を追加できなくなる
• ただし、無効化する前にすでに作成されていた転送ルールは残ったままになる

2点目が重要です。「ポリシーをオフにすれば安全」ではなく、「ポリシーをオフにして新規ルールの追加を防ぎつつ、既存ルールを別途棚卸しして削除する」という二段構えが必要です。

全社一律禁止 vs OU 別制御の選び方

全ユーザーに一律で転送を禁止するか、特定の OU だけ先に禁止するかは業務要件によって異なります。

適用範囲	向いているケース
全社一律禁止	業務で外部転送が不要、または代替手段（共有メールボックスなど）を用意できる
特定 OU に限定禁止	財務・法務・経営層など機密度の高い部門から先に適用したい
段階的適用	棚卸し結果を確認してから全社展開する

なお、グループ（Google グループ）単位でのポリシー適用については、公式ヘルプで最新の仕様を確認してください。OU 単位での制御が基本となります。

ポリシー変更の推奨手順

ポリシー変更を急ぎすぎると「外部転送ができなくなった」という問い合わせが集中します。次の順序で進めると現場の混乱を抑えやすいです。

1. 現状把握（後述の棚卸し手順を先に実施） ── 組織全体の転送状況を洗い出す
2. 業務上必要な転送の確認 ── 転送を使っているユーザーに業務上の必要性を確認する
3. 代替手段の整備 ── 必要に応じて共有メールボックスやラベル整理で代替する
4. テスト OU での先行適用 ── 影響の少ない OU から 1〜2 週間様子を見る
5. 全社展開 ── 問題がなければ残りの OU に適用する

このステップを踏まずに全社一斉適用すると、業務上の転送（自分の作業メールを別アカウントで処理していた、など）が突然停止して混乱が生じます。特に、ステップ 1 の棚卸しを先に実施することは譲れません。ポリシーを先に変えても、残っている既存ルールのリスクは消えないからです。

Gmail 自動転送ルールの監査方法

ポリシーを変更する前に、現時点で組織内にどれだけの転送ルールが存在するかを把握しておく必要があります。アプローチは二つあります。

管理コンソールの「監査と調査」で履歴を確認する

管理コンソールの「監査と調査」から、過去のユーザーアクティビティを確認できます。外部ドメインへのメール転送が有効化された際のイベントを検索・抽出でき、転送を設定したユーザーと転送先アドレスが記録として残ります。

この方法でわかること：

• 誰がいつ外部への転送を有効化したか
• 転送先のメールアドレス

限界もあります。ログの保持期間（Reports API のログ保持期間は 6 ヶ月・プラン共通）の上限があるため、それ以前に設定された転送ルールは履歴が残っていない場合があります。また、「いつ転送が有効化されたか」の記録であり、「現時点でも転送が動作しているか」は別途確認が必要です。

GAS スクリプトで転送有効化イベントを一括取得する

Admin SDK Reports API を使うと、過去のイベントをプログラムで取得してスプレッドシートに出力できます。管理者権限で動作するため、Domain-Wide Delegation のような追加設定は不要です。

以下は処理の流れを示すサンプルです。GAS の高度なサービスで「Admin SDK（Reports）」を有効化してから実行してください。イベント名 email_forwarding_out_of_domain は Reports API（user_accounts アクティビティ）の公式イベント名です。

// Gmail 転送有効化イベント 棚卸しスクリプト（Google Apps Script）
// 高度なサービスで「Admin SDK（Reports）」を有効化してから実行
// 実行には Google Workspace の管理者権限が必要です

function listForwardingEvents() {
  const sheet = SpreadsheetApp.getActiveSpreadsheet().getActiveSheet();
  sheet.clearContents();
  sheet.appendRow(['ユーザー', 'イベント名', '発生日時']);

  // 過去 6 ヶ月のユーザーアカウントアクティビティを取得
  const startTime = new Date();
  startTime.setMonth(startTime.getMonth() - 6);

  const result = AdminReports.Activities.list('all', 'user_accounts', {
    eventName: 'email_forwarding_out_of_domain', // 転送先が外部ドメインの場合の正式イベント名（Reports API: user_accounts）
    startTime: startTime.toISOString(),
    maxResults: 1000
  });

  for (const item of (result.items || [])) {
    const actor = item.actor?.email ?? '';
    const time  = item.id?.time   ?? '';
    // パラメータ（転送先など）は item.events[].parameters で取得できる
    // フィールド名は公式 Reports API ドキュメントを参照
    sheet.appendRow([actor, 'email_forwarding_out_of_domain', time]);
  }
}

このスクリプトは、過去 6 ヶ月間に転送ルールを設定したユーザーと設定日時をスプレッドシートに書き出します。取得できるのはあくまで「履歴」であり、現在も転送が動作しているかどうかは含まれません。

現在の転送設定を全ユーザー分で確認するには、Gmail API を組み合わせてユーザーごとの現在の設定を取得するアプローチが別途必要です。ただしこの方法は、サービスアカウントへの Domain-Wide Delegation 設定が前提となるため、追加の技術的設定が必要になります。最初の棚卸しとして「過去 6 ヶ月で誰が転送を設定したか」を把握するには、上記の Reports API アプローチが手軽です。

退職者オフボーディングチェックリストへの組み込み方

自動転送ルールの確認は、既存のオフボーディングフローに追加する形で対応できます。以下を参考に、実務に合わせて調整してください。

退職通知を受けたタイミング（アカウント停止前）

• [ ] 対象アカウントの外部転送設定を確認し、転送先が存在する場合は削除する
• [ ] 削除した転送先アドレスと実施日時をオフボーディング記録に残す
• [ ] 監査ログで直近 30 日間に転送が有効化されたイベントがないかを確認する

アカウント停止・削除の直前

• [ ] 転送設定の削除が完了していることを再確認する
• [ ] 完了をオフボーディング記録に記載し、担当者間で引き継ぐ

定期棚卸し（四半期に一度を推奨）

• [ ] 全ユーザーの転送設定をスキャンし、外部アドレスへの転送が有効なアカウントを一覧化する
• [ ] 業務上の必要性が確認できない転送先は、該当ユーザーに確認の上で削除を検討する
• [ ] 棚卸し結果をセキュリティ担当者・上長へ共有する

退職だけでなく、部署をまたぐ異動時にも同様の確認を検討してください。旧部門宛てのメールが新部門の担当者に転送されている状態が生じると、情報アクセス権の設計が崩れます。オフボーディングの対象を「退職」と「異動」の両方として定義するかどうかは、組織の規模と機密情報の取り扱い方針に合わせて判断してください。

このチェックリストは「退職者が転送を設定した」というケースだけでなく、「アカウントが侵害されて転送が設定された」ケースの早期発見にも機能します。定期的な棚卸しが、侵害の早期発見にもつながる側面があります。

自動転送リスクを継続管理するための運用設計

単発の棚卸しだけでは、その後に設定されたルールは把握できません。継続的な管理のために、次の三点をセットで組み込んでください。

ポリシーで新規ルール作成を禁止する

管理コンソールの Gmail 設定からユーザーによる転送ルール作成を無効化すると、問題が積み上がるリスクを抑えられます。ただし既存ルールは残るため、先に棚卸しを完了させてからポリシー適用に移ることを推奨します。影響範囲の大きい変更なので、テスト OU で先行確認することも重要です。

アラートセンターで転送有効化を検知する

管理コンソールのアラートセンターには、不審な転送ルールの追加を通知するアラート種別が含まれます。このアラートのデフォルト有効状態と通知先アドレスが正しく設定されているかを一度確認しておくことを勧めます。

アラートが届いた際の対応フローを先に決めておくと、実際に通知が来たときに判断が速くなります。最低限、次の流れを定義しておくのが現実的です。

• アラート受信 → 当該ユーザーの転送設定を即時確認
• 不審な転送先と判断した場合 → アカウントの強制ログアウト・パスワードリセット・MFA 再確認
• 転送ルールの削除 → セキュリティログの保全と上長への報告

オフボーディングフローに転送確認を組み込む

人事システムや Slack などからの退職通知をトリガーに、情シスのオフボーディングチェックリストへ転送確認を必須項目として加えます。一度手順を定めれば、担当者が変わっても抜け漏れを防ぎやすくなります。Google Workspace と人事システムが連携している場合は、退職処理のワークフローに組み込むとさらに確実です。

自動転送ルールは管理コンソールのトップ画面からは見えにくく、放置されやすいリスクの一つです。「ポリシーで新規作成を防ぐ」「既存ルールを棚卸しする」「退職者・異動者対応に組み込む」の三点を実務フローとして定着させることが、Gmail 経由の情報漏洩リスクを実質的に下げる手段になります。

GWS のセキュリティ運用設計やオフボーディング設計の見直しについては、DRASENAS の関連記事（drasenas.com）もあわせてご覧ください。

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

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