# 運用担当者の交代・退職時のアカウント引き継ぎチェックリスト

交代前に担当アカウントの一覧・二段階認証のコードの受け取り先・共有 ID を確かめます。当日は招待の取り消し・パスワード変更の依頼・ツール上での利用停止とクライアントへの連絡を行い、後日に反映を確かめて一覧を更新します。

更新日: 2026-09-17

担当者の交代や退職は、クライアントから預かったアカウントに入れる人が変わる出来事です。何をすればよいかは、預かり方で違います。預かり方は、権限付与・ID とパスワードの共有・アクセス管理ツール(担当者にパスワードを見せずにログインさせる道具)の 3 つです。このうち共有 ID は、クライアントに変更を頼まなければ止められません。預かり方の全体像は[運用代行のクライアントアカウント管理](/guides/agency-accounts)にまとめています。

## 交代前に確かめること

交代前の作業は、退職日や異動日が決まった時点で始めます。本人がいるうちにしかできない確認を先に済ませます。退職後に「どのアカウントを使っていたか」を聞くことはできません。クライアント側の操作を待つ工程は、この段階で依頼を出します。

1. 本人が使っているアカウントを、預かっているアカウントの一覧から抜き出します(自社の操作)。一覧がなければ本人と一緒に作ります。一覧に載っていないアカウントは当日の作業から漏れ、退職後も入れる状態が残ります。
2. アカウントごとの預かり方を確かめます(自社の操作)。当日の作業が型ごとに違うためです。権限付与は招待の取り消し、共有 ID はパスワード変更の依頼、アクセス管理ツールはツール上での利用停止です。
3. 権限付与の招待先が会社のメールアドレスか私用のアドレスかを確かめます(自社の操作)。私用のアドレスで招待されたユーザーは、会社のメールを止めても媒体に入れる状態が残ります。
4. 二段階認証のコードの受け取り先を確かめます(自社の操作。変更の依頼先はクライアント)。コードが本人のスマホや電話番号に届く設定のままだと、本人がいなくなった日に誰も入れなくなります。受け取り先の変更はクライアント側の操作です。
5. 共有 ID のうち本人がパスワードを知っているものを書き出します(自社の操作)。パスワードは記憶から回収できないので、変更を依頼するクライアントと依頼の時期を決めておきます。
6. 後任を決め、権限付与なら後任の招待を、アクセス管理ツールなら後任がツール上で使える設定を先に済ませます(招待はクライアント、ツールは自社の操作)。取り消しと同時に後任が入れないと、投稿や入稿が止まります。
7. クライアントへの連絡の文面と時期を決めます(自社の操作)。招待の取り消しとパスワードの変更はクライアント側の操作で、交代の連絡は挨拶であると同時に依頼でもあるためです。

急な退職で本人に確認できない場合は、一覧が唯一の手がかりになります。一覧もなければ、クライアントごとに媒体のユーザー一覧と共有している ID を洗い直します。確かめた順に、クライアントへ依頼を出します。

## 交代当日に行うこと

当日の作業は、預かり方ごとに「入れなくする操作」が違います。権限付与と共有 ID ではクライアント側の操作を待ち、アクセス管理ツールでは自社の操作で完結します。

1. 権限付与のアカウントは、本人の招待の取り消しを依頼し、後任の招待が有効なことを確かめます(クライアント、または代理店側の管理アカウントの操作)。招待は本人のユーザーに結びついていて、取り消すまで同じ権限で入れます。
2. 共有 ID は、パスワードの変更を依頼し、新しいパスワードを共有する範囲を決めて配ります(変更はクライアント、配布は自社)。本人が知っているパスワードそのものは、変える以外に無効にできません。
3. アクセス管理ツールでは、ツール上で本人の利用を止めます(自社の操作)。担当者はパスワードを知らないので、ツール上で止めればツール経由では入れません。
4. 二段階認証のコードの受け取り先を、本人のスマホや電話番号から会社の管理する先へ変えます(クライアントの操作)。そのままだと、後任のログインに要るコードが社外の端末にしか届きません。媒体によっては、その番号でパスワードの再設定もできます。
5. 本人が使っていた端末を回収します。または、私物端末のブラウザーに保存されたパスワードとログインしたままの状態を、本人と一緒に消します(自社の操作)。ブラウザーに保存されたパスワードは、変更前のものがそのまま端末に残ります。
6. 媒体にログイン中の端末を切る操作があれば行います(媒体によってクライアントか自社の操作。手順は媒体別の記事で扱います)。回収できなかった端末に残るログイン状態を切るためです。
7. クライアントに交代を伝え、依頼した取り消しと変更の完了を確認します(自社の操作)。クライアント側で後回しになれば、入れる状態が続きます。

## 交代後に確かめること

交代後の作業は 2 つです。当日の操作が反映されたかの確認と、次の交代に備える一覧の更新です。依頼したことと実施されたことは別なので、依頼の返事だけでは反映を確かめたことになりません。

1. 権限付与のアカウントは、媒体のユーザー一覧に本人の名前がないことを確かめます(自社の操作)。招待の取り消しが実施されたかは、媒体の一覧で分かります。
2. 共有 ID は、クライアントから変更完了の連絡を受け、新しいパスワードでの初回ログインが成功したことを確かめます(完了の連絡はクライアント、ログインは自社)。旧パスワードで入れないことは補助の確認です。記録が ID 単位なので、本人名義の記録の有無では確かめられません。
3. アクセス管理ツールは、利用者一覧に本人がないことを確かめます(自社の操作)。自社の操作なので、操作の記録と一覧の両方で確かめられます。
4. 権限付与とアクセス管理ツールのアカウントについて、交代後しばらく本人名義の記録がないことを見ます(自社の操作)。人単位の記録が残る預かり方に限ってできる確認で、取り消し漏れがあれば本人名義の記録として現れます。
5. 預かっているアカウントの一覧を更新します(自社の操作)。担当者名、パスワードを知っている人、二段階認証の受け取り先、招待先のアドレスを書き換えます。次の交代はこの一覧から始まります。
6. 秘密保持の義務を本人に確認します(自社の操作)。個人情報保護委員会のガイドライン(通則編)10-4 の例示によるもので、秘密保持に関する事項を就業規則等に盛り込むことが、人的安全管理措置(従業員に対する対策)の例として挙げられています。

## 個人データを扱う委託で交代の手順が持つ意味

預かる業務に個人データの取扱いが含まれる場合、運用代行会社は従業者に対する必要かつ適切な監督(個人情報保護法 24 条)を負います。従業員が個人データをきちんと扱っているか、確かめる義務です。個人情報保護委員会のガイドライン(通則編)は、組織的安全管理措置(体制やルールの面での対策)として、個人データを取り扱う従業者とその役割、取り扱う個人データの範囲を明確にすること(10-3)を例示しています。技術的安全管理措置(システム上の対策)としては、ユーザー ID に付与するアクセス権により従業者を限定すること(10-6)を例示しています。ID ごとに入れる範囲を決めて、扱う人を絞ることです。交代のたびに一覧と権限を更新する手順は、これらの対策を行っていることを示す材料になります。クライアントから取扱状況の確認を求められたときに、示せる根拠になります。

個人データを扱わない投稿代行にこの条文が当てはまるかは、[運用代行におけるアカウントの預かりとは](/guides/agency-accounts/what-is-delegated-account-access)で扱っています。退職者がクライアントのアカウントに入れる状態を残さないという点で、手順は同じです。


## よくある質問

**退職する担当者がパスワードを知っている共有 ID はどうしますか**

本人の記憶からは回収できないので、クライアントにパスワードの変更を依頼し、新しいパスワードを配る範囲を決めます。反映は、クライアントの完了連絡と新しいパスワードでの初回ログインで確かめます。

**交代の準備はいつから始めますか**

退職日や異動日が決まった時点です。二段階認証のコードの受け取り先や招待の取り消しはクライアント側の操作を待つので、本人がいるうちに一覧を確かめ、依頼を先に出します。

**急な退職で本人に確認できないときは**

預かっているアカウントの一覧が頼りになります。一覧がなければ、クライアントごとに媒体のユーザー一覧と共有している ID を洗い直し、順にクライアントへ依頼します。

**交代の手順は個人情報保護法と関係がありますか**

預かる業務に個人データの取扱いが含まれる場合、運用代行会社は従業者の監督(法 24 条)を負います。ガイドラインは、ID ごとに入れる範囲を決めて扱う人を絞る手法を例示しています。

## 参考資料

- [個人情報の保護に関する法律(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/415AC0000000057)
- [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf)

## Junify の場合

**人手で続けると** クライアントごとに渡し方を決め、担当替えのたびに権限を付け外しし、どの担当者がどのクライアントのアカウントを使ったかを媒体ごとに追い続けることになります。

**Junify なら** Junify では担当者にパスワードを渡していないので、交代の日は管理者がその人の割り当てを外すだけです。導入時にパスワードを変えて Junify だけが持つ運用なら、以後はクライアントのアカウントに入れず、パスワード変更を頼む工程もなくなります。誰がいつ使ったかの記録は担当者ごとに残ります。

Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。

- [登録不要の体験デモを見る](https://www.junify.jp/bpo/try)
- [30 分デモを予約する](https://www.junify.jp/bpo/demo)

## 同じテーマの記事

- [クライアントのセキュリティチェックシートへの、運用代行会社の答え方](/guides/agency-accounts/answering-security-questionnaires): 設問は個人情報保護委員会ガイドライン(通則編)別添の安全管理措置の項目に対応しています。現状をそのまま書き、共有 ID は管理方法まで書き、対応予定には期限と担当を添えます。
- [楽天 RMS・Yahoo! ショッピングの店舗管理を代行するときのアカウント](/guides/agency-accounts/ec-mall-store-admin-access): 楽天は担当者ごとの楽天 ID を店舗の管理者が承認し、Yahoo! はビジネスマネージャーでツール管理者が従業員のビジネス ID を登録します。どちらも担当者ごとに ID を持つ仕組みです。
- [「御社にアカウントを預けて大丈夫か」に商談で答えるための説明の型](/guides/agency-accounts/explaining-account-handling-in-sales): 預かり方(権限付与・共有・アクセス管理ツール)ごとに、担当者はパスワードを知るか、誰が使ったかは残るか、担当交代で何が起きるか、の 3 問に答えます。根拠は預かっているアカウントの一覧に置きます。