# 「御社にアカウントを預けて大丈夫か」に商談で答えるための説明の型

預かり方(権限付与・共有・アクセス管理ツール)ごとに、担当者はパスワードを知るか、誰が使ったかは残るか、担当交代で何が起きるか、の 3 問に答えます。根拠は預かっているアカウントの一覧に置きます。

更新日: 2026-09-17

新規のクライアントとの商談で「御社にアカウントを預けて大丈夫か」と聞かれたときの答えは、自社の運用の説明です。説明は、預かり方ごとに 3 つの問いへ答える形に整えられます。預かり方の定義は[運用代行におけるアカウントの預かりとは](/guides/agency-accounts/what-is-delegated-account-access)にまとめています。

## この質問の裏にある 3 つの問い

クライアントがこの質問をするのは、自社の名前で投稿・出稿・受注が起きるアカウントを、社外の人に操作させることになるからです。漠然とした「大丈夫か」を分けると、聞きたいことは 3 つに分かれます。

1. 担当者はパスワードを知るか。知っていれば、退職後も本人の記憶に残り、回収できないためです。
2. 誰が使ったかは残るか。誤投稿や誤設定が起きたときに、原因を人まで追えるかが決まるためです。
3. 担当交代で何が起きるか。辞めた人が入れる状態が残るかどうかと、クライアント側に何を頼まれるかが決まるためです。

預かる業務に個人データの取扱いが含まれる場合、クライアントは委託先の監督を負います(個人情報保護法 25 条。[運用代行におけるアカウントの預かりとは](/guides/agency-accounts/what-is-delegated-account-access))。個人情報保護委員会のガイドライン(通則編)3-4-4 は、委託前に委託先の安全管理措置(個人データを守るための対策)を確かめることを求めています。確かめる方法としては、個人データを取り扱う場所に赴くこと、またはこれに代わる合理的な方法(口頭による確認を含む)が挙げられています(3-4-4 の※3)。そのため、商談での説明も選定時の確認の一部として扱われうると考えて話すことになります。

## 預かり方ごとの答えの型

3 つの問いへの答えは、預かり方で決まります。自社の運用がどの型に当たるかをアカウントごとに把握していれば、答えは表から読めます。

| 問い | 権限付与 | ID とパスワードの共有 | アクセス管理ツール |
| --- | --- | --- | --- |
| 担当者はパスワードを知るか | 知らない。担当者は自分のユーザーで入る | 知っている。共有している全員が知る | 知らない。管理者がツールに登録し、担当者はツール経由で入る |
| 誰が使ったかは残るか | 媒体に担当者単位で残る(媒体が履歴を残す範囲で) | 媒体には ID 単位でしか残らない。人は作業記録から推定する | ツールに担当者単位で残る。媒体側は ID 単位のまま |
| 担当交代で何が起きるか | クライアント側(または代理店側の管理アカウント)で招待を取り消す。パスワードは変えない | クライアントにパスワード変更を依頼し、残る全員に配り直す | ツール上でその担当者の利用を止める。クライアント側の操作は要らない |

権限付与では「知らない・残る・招待の取り消しを頼む(パスワード変更は不要)」です。アクセス管理ツールでは「知らない・残る・クライアントの操作は要らない」です。共有 ID では「知る・残らない・パスワード変更を頼む」になります。共有 ID が残る理由は媒体側の制約にあります。それでも、運用代行会社が決められる範囲(知っている人の範囲、変更の手順、記録の方法)は決めていることを、この表に添えて話します。

## 答えの根拠を一覧に置く

商談での答えに根拠を持たせるのは、[運用代行のクライアントアカウント管理](/guides/agency-accounts)で述べた、預かっているアカウントの一覧です。この一覧があれば、アカウントごとに預かり方を決め、担当者と記録の残り方を把握していることを、文書で示せます。

一覧を根拠にするのは、説明が後のチェックシートや監査で突き合わせられるためです([クライアントのセキュリティチェックシートへの、運用代行会社の答え方](/guides/agency-accounts/answering-security-questionnaires))。商談で話した内容、チェックシートに書いた内容、監査で見せる内容が同じ一覧から出ていれば、食い違いは起きません。

見せるのは一覧の項目の構成だけで、ほかのクライアントの行は見せません。他社のアカウントの扱いを見せることは、その他社との秘密保持に反しうるためです。

## 避けたい答え方

説明の組み立てを保つために、避けたい答え方が 3 つあります。

### 共有 ID が残っているのに「共有はしていません」と言う

後のチェックシートや監査で共有の事実が出れば、商談での説明と食い違います。代わりに話すのは、共有が残る媒体側の理由と、知っている人の範囲・変更の手順・記録の方法です。

### 「この媒体は担当者ごとに権限を出せます」と媒体の仕組みを言い切る

説明は公式ヘルプに基づくもので、媒体の仕組みは後から変わります。「公式ヘルプでは」と根拠を添えて話し、媒体側の仕組みと、クライアント側の設定(招待の操作は所有者が行うこと)を分けます。

### 「事故は起きません」と言う

預かり方が決めるのは、誰が操作したかを追えるかと、辞めた人が入れる状態を残さないかです。誤投稿を防ぐ仕組みは別にあります。代わりに話すのは、起きたときに何を報告でき、交代時に何をするかです。


## よくある質問

**商談でどこまで自社の運用を話しますか**

預かり方ごとの 3 問(パスワードを知るか・誰が使ったかが残るか・交代時に何が起きるか)への答えまでです。ほかのクライアントの名前や個別のアカウントは出しません。

**共有 ID で運用していることは商談で話しますか**

媒体側の制約で共有が残る場合、その事実と管理方法(知っている人の範囲・変更手順・記録)を話します。後のチェックシートや監査で共有の事実が出れば、説明と食い違います。

**口頭の説明は法令上の確認に当たりますか**

個人データを扱う委託では、ガイドラインは委託先の確認方法に口頭による確認を含めています(3-4-4 の※3)。商談での説明も選定時の確認の一部として扱われうると考えて話します。

**一覧はクライアントに見せるものですか**

見せるのは項目の構成です。ほかのクライアントの行は見せません。アカウントごとに預かり方・担当者・記録の残り方を把握していることを、文書で示せます。

## 参考資料

- [個人情報の保護に関する法律(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 を使っているアカウントについては、3 問に「担当者はパスワードを知りません。誰がいつ使ったかは担当者ごとに残ります。交代時は割り当てを外します」と答えられます。権限付与ができない媒体でも、この答えを変えずに済みます。

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 を持つ仕組みです。
- [Google 広告の MCC(クライアント センター)で代理店アクセスを整理する](/guides/agency-accounts/google-ads-mcc-agency-access): クライアントのアカウントを MCC にリンクし、担当者は MCC のユーザーとして招待します。担当交代は MCC 側でその人のアクセス権を削除すれば済み、クライアントのパスワードは受け取りません。