広告代理店で退職者の権限を整理する｜アカウントの引き継ぎ手順

広告代理店で退職者の権限を棚卸しするときは、ユーザー一覧からの本人削除に加え、広告アカウントの所有・管理関係、外部サービスとの連携、個人やグループに与えたアクセスを分けて確認します。後任者が操作できることを確かめてから削除してください。

抜けを防ぐには、「所有者」「連携主体」「人の権限」という3つの観点を、広告・解析・資料のすべてに通します。媒体ごとの画面を順に見たあと、親アカウントからの継承や個別共有が残っていないかも確かめます。削除前後の状態を顧客側でも確認できる証跡までを、退職対応の範囲に含めてください。

退職者の権限を「アカウント一覧」だけで確認しない

広告運用では、ログインする人、管理主体となる組織、別サービスとの接続が異なる画面・単位で管理されることがあります。退職者のメールアドレスを検索して終えると、人に直接付与した権限以外を見落としやすくなります。

2026年9月21日時点のGoogle 広告アカウントのアクセス権の概要では、アカウントへのアクセス許可、権限変更、招待の取り消しに加え、サービス間リンクの追加・削除やMCCアカウントとのリンク解除が、管理者権限で行う操作として示されています。さらに、リンクされたMCCアカウントがオーナーに設定されている場合、そのMCCで管理者権限を持つユーザーは、クライアントアカウント内のユーザーアクセス、管理者、サービス間リンク設定も編集できます。

誰が管理できるかを確定するには、広告アカウントのユーザーに加え、MCCのオーナー設定とサービス間リンクを別項目として確認する必要があります。

Google Analyticsにも別の注意点があります。2026年9月21日時点のアクセス権とデータ制限の管理によると、有効な権限には対象リソースへ直接付与されたものに加え、組織、ユーザーグループ、親アカウントなどを経由する役割とデータ制限も含まれます。役割は親レベルから継承され、有効な役割には最も制限の少ないものが適用されます。対象プロパティの直接権限から退職者を外した後も、継承元まで確認してください。

所有者・連携主体・人の権限を分ける退職チェック表

次の表は、公式仕様を踏まえた運用上の提案です。製品上の項目名から一段抽象化し、退職後に「誰が保持するか」「何を経由して操作できるか」「誰が実行できるか」を分けます。

表の一行は、3つの欄が埋まり、後任者による操作確認と、顧客が変更後の状態を追える記録がそろった時点で「確認済み」にします。退職者名の削除だけを完了条件に含めると、経路単位の確認状況が残りません。

担当案件が複数ある場合も、退職者を起点に一括で済ませず、顧客と対象リソースの組み合わせごとに一行を作ります。同じ人が参加していても、MCCのオーナー設定、Analyticsの継承元、資料の所有主体は案件ごとに異なり得るからです。

削除より先に、後任管理者の継続性を確かめる

権限削除を最初に実行すると、確認や修正に必要な管理者まで失うおそれがあります。運用上の提案として、退職者以外の管理者が実際に管理画面へ入り、対象リソースを管理できることを確かめてから、退職者の権限を削除します。

この順序には公式情報上の根拠があります。2026年9月21日時点でGoogleは、Google 広告アカウントの管理者が1人だけで、そのユーザーが対応できなくなった場合、タグにアクセスできなくなる可能性を案内しています。継続的な管理のため、少なくとももう1人の管理者を追加するよう示しています。これは退職対応そのものの手順ではありませんが、単独管理者を残さないという判断を直接支える注意事項です。

実務では、次の順序を一つの作業単位にします。

1. 対象となる広告アカウント、解析リソース、資料を特定する
2. 退職者以外の管理者と、組織側に残る所有・管理主体を確認する
3. 後任管理者が自分の認証で入り、必要な管理箇所を開けるか確認する
4. 退職者の直接権限と、グループや親階層など別経路の権限を整理する
5. 変更後の状態を再確認し、顧客側確認証跡へ記録する

ここでの操作確認には、後任者自身のアクセスを使います。退職者のログイン状態や共有された認証情報は使いません。後任者の名前が一覧にある状態から一歩進め、実際の操作をもって管理継続を確認します。

Analyticsは直接権限と継承元を対で記録する

Analyticsの棚卸しでは、「プロパティのユーザー一覧に退職者がいない」という結果と、「退職者に有効な権限がない」という結果を分けます。前者は直接付与の確認、後者は組織、ユーザーグループ、親アカウントなどを経由した役割とデータ制限まで含む確認です。

運用上の提案として、台帳には「直接権限」「有効な権限」「継承元」の欄を並べます。たとえば、直接権限がなくてもユーザーグループを経由する場合は、グループ名と、そのグループに退職者が残っていないかの確認結果を記録します。親アカウントから継承する場合は、その親階層を確認対象として残します。

公式情報では、有効な役割に最も制限の少ないものが適用されます。複数経路があるときは、有効な権限と各経路の対応まで台帳に記録します。権限の強さだけを転記すると、ほかの経路を追えないためです。削除対象を決める際は、必要な組織・グループ設定まで誤って外さないよう、退職者本人の所属とリソース側の設定を切り分けます。

運用資料は保存場所より所有主体と共有経路を見る

レポート、入稿用素材、定例会資料、引き継ぎ文書は、表示の可否、所有者、共有経路を分けて調べます。このうち退職後の残存性を判断する項目は、誰が所有しているかです。

2026年9月21日時点の共有ドライブとはでは、共有ドライブ内のファイルはチームや組織の所有となり、メンバーが退職して管理者がそのアカウントを削除しても、その人が共有ドライブに追加または作成したファイルは残ると説明されています。したがって、継続利用する資料については、個人所有か、共有ドライブ上でチーム・組織が所有するものかを確認します。

同じ公式ページでは、共有ドライブ内のファイルやフォルダへのアクセス経路として、ユーザーまたはグループを共有ドライブのメンバーにする方法と、メンバーが非メンバーへ個別共有する方法が示されています。後者は外部共有が許可されている場合に利用できる経路です。これはアクセス経路の説明であり、すべての環境で外部共有が許可されるという意味ではありません。

そこで、運用上の提案として、資料の台帳には「共有ドライブのメンバー」と「ファイル・フォルダの個別共有先」を別欄で残します。退職者をメンバーから外した後に個別共有を確認し、個別ファイルを点検した後にグループ経由のメンバー資格を確認します。

資料の置き場や命名まで含めて退職時だけに整えると、判断が属人化します。平時の役割分担や更新手順は、広告運用を標準化するための整理方法と接続し、退職チェック表の所有者欄を日常の運用台帳にも使える形にしておくと、引き継ぎ時の確認対象を明確にできます。

顧客側確認証跡は変更後の状態を残す

「削除しました」という顧客への連絡には、確認した経路が残りません。運用上の提案として、顧客側確認証跡には、少なくとも次の項目を対象リソースごとに記録します。

• 対象サービスと、対象アカウント・プロパティ・共有ドライブ
• 所有者または組織側に残る管理主体
• Google 広告の変更後のユーザー、MCCオーナー、サービス間リンク
• Analyticsの直接権限、有効な権限、確認した継承元
• 資料の所有主体、共有ドライブのメンバー、個別共有先
• 後任管理者が自分のアクセスで確認した対象
• 変更した項目と、変更せず維持した項目
• 確認日と、代理店側・顧客側の確認担当

顧客側確認証跡には、変更後に誰と何が残ったかを示します。顧客側の担当者は、この記録を使って、意図した管理主体、連携、アクセス経路になっているかを確認できます。画面情報を扱う際は、権限一覧や顧客情報を必要以上に別の場所へ複製せず、保管先と閲覧者を決めます。生成AIへ扱わせる情報の境界は、生成AIへ機密データを入力するときの考え方もあわせて整理してください。

この証跡には、特定製品の画面キャプチャと、表の各欄に対応する文字情報を残します。後から画面構成が変わっても、「所有者」「連携主体」「人の権限」のどこを確認した記録かを追えるためです。

退職日までに完了と判断する条件

完了条件は、対象ごとに3つの観点を閉じた状態です。Google 広告はユーザー、MCCオーナー、サービス間リンク、Analyticsは直接権限と継承元、資料は所有主体と、メンバー経由・個別共有経由を確認します。そのうえで、後任管理者が継続して管理できることを自分のアクセスで確かめます。

最後に顧客側確認証跡を照合します。確認していない欄は推測で「該当なし」とせず、対象の有無を確定してください。退職者名の削除を確認したら、続けて別経路の有無も確定します。所有、連携、人という3つの欄が埋まり、後任の操作確認と顧客側の確認が結び付いた時点を、案件の権限棚卸しの完了とします。

関連ガイド：広告代理店のAI活用と業務改善