Gmail委任アクセスの設計と監査ポリシー

Google Workspace では、Gmail アカウントへのアクセスを別ユーザーに委ねる「Gmail 委任アクセス（Mail Delegation）」を利用できます。この記事では情シス担当者向けに、委任の仕組みとリスク、運用ポリシーの設計方針、現状の把握方法を整理します。

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

• Google Workspace を管理する情シス・コーポレートIT担当者
• 「役員のメールをアシスタントが確認・返信したい」という申請が来て、対応方針が決まっていない方
• Gmail 委任を有効にしているが、監査や管理の運用が整備されていない方
• 代理送信のセキュリティリスクを整理したい方

Gmail 委任アクセスとは何か

Gmail 委任アクセス（Mail Delegation）は、Gmail アカウントの所有者が同組織内の別ユーザーを「代理人（delegate）」として設定し、メールの読み取り・送信・削除を代わりに行えるようにする機能です。

委任を受けた代理人は、自分の Gmail アカウントから「別のアカウントに切り替える」操作で委任元のメールボックスにアクセスできます。代理人の画面では受信トレイが委任元のアカウント名で表示され、送信もそのアカウントとして行えます。秘書が役員の受信トレイを処理する、アシスタントが担当者の代わりにメールを返す、といったケースで使われます。

委任と混同されやすい機能に「別のアドレスから送信（Send mail as）」があります。こちらは別メールアドレスから送信できるだけで、メールボックスへの操作権限は付与されません。委任アクセスは「受信トレイへの操作権限ごと渡す」点で、より踏み込んだ権限です。

代理人が操作できる範囲は以下の通りです（公式ヘルプより）。

• メールの読み取り・送信・削除・アーカイブ
• フィルターやラベルの操作

一方で、代理人にできないことも明確です。

• チャット・Google Meet・Gemini 機能の利用
• アカウントのパスワードや設定の変更

委任先に設定できるのは同一の Google Workspace 組織内のアカウントのみで、外部ドメインへの委任は許可されていません。公式仕様では、1ユーザーに設定できる代理人の上限は25名です。実務上25名を超えるケースはほとんど発生しませんが、チームアカウント（info@〜 や sales@〜 など）への委任を多数設定している場合は上限に当たる可能性があります。

委任元のアカウントが停止・削除された場合、そのメールボックスへのアクセスができなくなります。ただし代理人側の設定からは即座には消えないケースがあるため、退職者アカウントの処理後に代理人のメール切り替え画面を確認する習慣を持つことを勧めます。

Gmail 委任と共有受信トレイの使い分け

委任アクセスと並んでよく検討されるのが、Google グループを使った共有受信トレイです。どちらを選ぶかは業務要件とセキュリティ要件の両方で決まります。

比較軸	Gmail 委任	Google グループ（共有受信トレイ）
アクセスの粒度	個人アカウント単位の1対1〜1対多	グループメンバー全員が等しくアクセス
設定の主体	アカウント所有者が自分で設定	管理者またはグループオーナーが管理
管理者の把握しやすさ	低い（通知なし）	高い（グループのメンバーリストで確認可）
送信時の表示	所有者名 or 所有者+代理人名	グループのメールアドレス名
向いているユース	役員秘書・一時的な代行	CS・サポート・問い合わせ対応チーム
退職者対応	手動での棚卸しが必要	グループからメンバー削除で即時対応

チームで共同対応する用途では、Google グループの共有受信トレイのほうが管理しやすい場面が多くあります。「メール対応が必要な人物が1名に特定されている」「委任元アカウントに秘匿性がある」ケースに限って、委任アクセスを選ぶ判断が妥当です。

情シスとしては、「委任してほしい」という申請が来たとき、まず共有受信トレイで代替できないか確認するという一次チェックを申請フロー内に組み込むことで、委任の乱立を抑制できます。

管理者が制御できる範囲とできない範囲

情シス担当者が最初に理解しておきたいのは「管理者の権限がどこまで及ぶか」です。

管理者が制御できること（Gmail の管理設定から）

• 委任機能そのものの有効/無効（OU 単位で切り替え可能）
• Google グループを代理人として設定できる機能の有効/無効（グループのメンバー全員が委任元のメールボックスにアクセスできるようにする機能で、チーム単位での委任付与に使う）
• 代理人がメール送信したときの送信者表示形式（所有者のみ / 所有者と代理人の両方）
• ユーザーが送信者表示をカスタマイズできるかどうか

委任機能の有効/無効は OU 単位で切り替えられるため、経営層の OU のみ委任を禁止し、一般社員 OU では許可するという粒度の制御が可能です。ただし重要な注意点があります。管理コンソールで OU の委任機能を「無効」に切り替えても、その時点で既に設定済みの委任関係は自動解除されません。無効化と同時に棚卸しを行い、既存の委任を手動で解除する作業がセットで必要です。

管理者が直接制御できないこと

• 誰が誰に委任を付与しているかのリアルタイム把握（委任が設定されても管理者への通知は来ない）
• 委任設定の一括強制付与（ユーザーが個別に設定するしかない）
• 代理人がいつどのメールを操作したかの自動アラート

「委任機能をオンにした状態」は、管理者が把握しない委任関係が自然発生しうる状態でもあります。後述する定期棚卸しとポリシー整備がセットで必要です。

Gmail 代理送信が生む3つのリスク

リスク1: 操作ログの帰属が曖昧になる

代理人が委任元アカウントとしてメールを送信した場合、受信者にはアカウント所有者から送信されたように見えます。管理者が監査ログを確認する際、「誰が実際に操作したか」を特定するには、ログの検索に追加の工夫が必要です。

ログの詳細度は契約プランによって異なります。Google Workspace の公式情報（2022年3月 Workspace Updates）によると、Enterprise Standard / Enterprise Plus / Education Standard / Education Plus 以上のプランでは、セキュリティ調査ツールで代理人による操作を所有者の操作と区別した形でログを参照できます。それ以外のプランでは、誰の操作かを詳細に区別するには手順が複雑になります。インシデント発生後に行為者を追跡しようとしたとき、契約プランによっては想定外の工数がかかる状況が起きえます。

委任を申請許可制で運用するなら、承認の際に現行プランでどこまでログを追跡できるかを組織として確認し、追跡性の限界をポリシー文書に明記しておくことを勧めます。

リスク2: なりすましリスクと意図しない情報開示

管理コンソールでは送信時の表示形式を「所有者のみ表示」と「所有者と代理人の両方を表示」から選べます。「所有者のみ表示」を選んだ場合、外部取引先には「役員から来たメール」として届きますが、実際にはアシスタントが送ったという状況が生まれます。

たとえば、価格交渉のメールを役員委任を受けたアシスタントが送り、役員が関知しない条件で「役員からの返信」として届いてしまうケースがありえます。業務委任の範囲が曖昧なまま委任だけ付与すると、意図しない情報漏洩や契約誤認のリスクが生まれます。

内部統制を重視するなら、「両方表示」を組織のデフォルト設定にした上で、例外的に「所有者のみ」を使うケースを申請制で管理する方針が現実的です。

リスク3: 委任関係の「放置」

委任の付与はユーザー任意ですが、解除も同様にユーザー任意です。退職者や異動者のアカウントへの委任設定が残り続けるケースが発生しやすく、定期的な棚卸しなしでは「誰が誰のメールを読める状態か」を組織が把握できなくなります。

具体的なリスク期間のイメージとして、3月末に異動した社員が役員秘書の委任を持っていた場合、9月の棚卸し実施まで6ヶ月間、その委任が残り続ける状況がありえます。人事異動と棚卸しのサイクルがずれているほど、この「放置ウィンドウ」は広がります。

対策として、人事異動・退職が発生したタイミングを委任棚卸しのトリガーに組み込む仕組みを、人事フロー（退職手続きチェックリストや異動通知フロー）と連携させておくことで後手の対応を防げます。

全社禁止・申請許可・自由化の3択判断フロー

組織のリスク許容度と業務フローに応じて、以下の3択から方針を選びます。

全社禁止

金融・医療・法律など機密性が高い業態や、情シスのリソースが限られていて例外管理が困難な組織に向いています。委任設定の管理負荷をゼロにできますが、秘書・アシスタントが必要とする業務フローを別手段で補う必要があります。代替手段としては Google グループを使った共有受信トレイがよく採用されます。

「全社禁止」を採用しながらも例外申請を認める場合は、申請件数が増えた時点で「申請許可」に体系を切り替えるタイミングを事前に決めておくことを勧めます。例外が5件を超えたら体系見直しを検討する、という目安を持つだけで運用が楽になります。

申請許可（要承認）

役員秘書や営業アシスタントが存在し、委任が業務上不可欠だが内部統制も維持したい組織に向いています。申請フォームと承認フローを整備し、定期的な棚卸しをセットにすることが前提です。

申請の有効期間は最大6ヶ月とし、期限到来時に棚卸しと更新判断を行う設計にすると、放置リスクを構造的に抑えられます。承認者は委任元の直属上長（または同等の権限を持つ管理職）に限定することで、「とりあえず申請だけ出す」ケースを減らせます。

自由化（全員利用可）

スタートアップなど少人数でフラットな組織向けです。委任関係が増殖・放置されやすいため、最低でも半年に1回の棚卸しを必ず実施する体制が必要です。人員が増えてきた段階で「申請許可」への移行を検討する目安は、組織規模が50名を超えたタイミングです。

判断の目安

方針	向いている状況	最低限必要な整備
全社禁止	高機密業態・管理リソース不足	代替手段（共有受信トレイ等）の整備
申請許可	秘書・アシスタントが存在・内部統制重視	申請フォーム・承認フロー・定期棚卸し
自由化	少人数・フラット組織	定期棚卸し（最低限）

Gmail delegation 監査の実務と現状把握の方法

現在の組織内でどのような委任関係が存在するかを把握するには、Gmail API の delegates リソースを使います。各ユーザーに設定された委任一覧を取得できるリソースで、組織全体のユーザーを対象に実行することで委任状況を一覧化できます。組織全体を対象にするには、管理者がサービスアカウントに適切なアクセス権を付与する設定が必要です。

棚卸しの工数は対象者数次第です。目安として、50名以下の組織ではスプレッドシートへの手動エクスポートで管理できる量ですが、100名を超えると API を活用した自動化を検討する価値が出てきます。委任申請の頻度や管理方針によっても変わるため、まずは手動で一度全件確認してから自動化の要否を判断する進め方が現実的です。

委任操作の活動履歴については、管理コンソールのレポート機能（レポート > 監査と調査 > Gmail ログイベント）で確認できます。Enterprise Standard / Enterprise Plus 以上のプランではセキュリティ調査ツールで代理人による操作を所有者の操作と区別した形でログを参照できます（2022年3月 Workspace Updates より）。これ以外のプランでは詳細な区別が難しいため、利用プランとポリシーのセットで設計する必要があります。

棚卸しの年間サイクル（申請許可制の場合）

タイミング	実施内容
1月・7月（半年ごと）	全組織の委任状況を一覧化し、承認記録との突き合わせ
人事異動・退職発生時（随時）	関係するアカウントの委任設定を即時確認・解除
新入社員受け入れ時	先任者が持っていた委任設定の引き継ぎ可否を確認
プラン変更時	ログの詳細度が変わる場合は運用手順を見直す

棚卸しで確認したい3点は以下です。

• 代理人として登録されているアカウントが現在も有効かどうか（退職者・休職者チェック）
• 承認記録のない委任関係（「野良委任」）が存在しないか
• 役員・管理職など機密情報を扱うアカウントへの委任が意図せず広がっていないか

「野良委任」が見つかった場合の対応フローも事前に決めておきます。委任元・代理人双方への事実確認 → 業務必要性の確認 → 必要なら正規申請へ移行、不要なら即時解除という流れが現実的です。対応記録は証跡として申請管理台帳に追記します。

情シスが整備すべき運用ポリシーのひな型

申請許可方式を選んだ場合、最低限以下の項目をポリシーとして定義しておきます。

申請段階で確認すること

申請フォームには次の項目を含めておくと、後からの追跡が容易になります。

• 委任元のメールアドレスと代理人のメールアドレス
• 委任元の直属の上長による承認日時と承認者名
• 業務上の委任理由（「便利だから」は原則不可。具体的な業務タスク名で記載）
• 委任の有効期間（開始日・終了日、または「次回定期棚卸しで再評価」の明記）
• 利用する送信者表示設定（「所有者のみ」or「両方表示」）

ポリシー文書に含めておきたい基本原則の例

実際のポリシー文書に書く表現として、以下のような粒度の記載が参考になります。

• 「Gmail 委任アクセスは、委任元の上長承認を必須条件とし、情報システム部による台帳登録をもって有効とする」
• 「委任の有効期間は最長6ヶ月とする。延長が必要な場合は期限前に再申請を行う」
• 「送信者表示は原則として所有者・代理人の両方を表示する設定とする。例外申請は情報システム部が個別に承認する」
• 「代理人が退職・部署異動した場合は、人事手続き完了後5営業日以内に委任を解除する」

運用中に定期実施すること

• 半年に1回の委任状況棚卸し（Gmail API を活用して全組織の委任関係を抽出・確認）
• 退職者・異動発生時のトリガー確認（人事フローへの組み込みが理想）
• 棚卸し結果と申請台帳の突き合わせ（承認記録のない委任が存在しないか確認）

解除基準を明確にすること

• 代理人が退職・異動した場合は即時解除（5営業日以内）
• 有効期間が満了し更新申請がない場合は、情シスが手動削除
• 委任の業務上の理由がなくなった場合（担当変更・プロジェクト終了など）

この3点をあらかじめ決めておくことで、「申請が来てから考える」という後手の対応を避けられます。

まとめと次のアクション

Gmail 委任アクセスは、管理者が「使えるかどうか」を設定できても「誰が誰に付与しているか」を自動で把握する仕組みを持っていません。ユーザーが自由に操作できる領域があるため、ポリシーなしで運用すると委任関係が自然増殖します。

情シスとして取れる打ち手は「全社禁止/申請許可/自由化」の3択です。どれを選ぶにせよ、委任の現状を定期的に棚卸しする仕組みをセットで作ることが最低条件です。申請が来てから方針を決めようとしている組織では、その時点で野良委任が広がっている可能性があります。

組織規模が小さいうちに「申請フォーム → 承認 → 期限付き委任 → 定期棚卸し」のサイクルを整備しておけば、100名を超えた段階でも追跡可能な状態を維持できます。共有受信トレイ（Google グループ）で代替できるケースは委任ではなくグループで対応し、委任が本当に必要なケースに絞って申請制で管理する、というシンプルな原則から始めてみてください。

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

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