# 運用代行のクライアントアカウント管理

預かり方は権限付与・ID とパスワードの共有・アクセス管理ツールの 3 つ。違いは「誰が使ったかが残るか」と「担当交代時に何をするか」に出ます。

更新日: 2026-09-17

クライアントから SNS 公式・広告・EC モールのアカウントを預かって運用する会社では、預かり方によって 2 つのことが変わります。事故のあとに説明できることと、担当交代時の作業です。媒体(Google 広告や LINE などのサービス)ごとの権限の付け方は媒体別の記事で扱います。

## クライアントのアカウントを預かるとはどういうことか

アカウントを預かるとは、クライアントが所有するアカウントを、運用代行会社の担当者が業務のために操作できる状態にすることです。所有者はクライアントのままで、運用代行会社は任された範囲で操作します。この「委任の範囲」(何をしてよいか)と「アカウントの扱い」(どうやって入るか、誰が ID とパスワードを持つか)は別の問題です。契約で委任の範囲を決めても、アカウントの扱いは決まりません。詳しくは[運用代行におけるアカウントの預かりとは](/guides/agency-accounts/what-is-delegated-account-access)にまとめています。

アカウントの扱いが問題になる理由は、クライアントと運用代行会社の両方にあります。クライアントから見ると、自社の名前で投稿・出稿・受注が起きるアカウントを社外の人に操作させています。運用代行会社から見ると、預かるアカウントの数はクライアント数と媒体数の掛け算になります。一人の担当者が、複数のクライアントの同じ管理画面を扱うことになります。アカウントの取り違えや、担当交代時の回収漏れは、この数と重なりから起きます。

## 預かり方の 3 つの型

預かり方は、誰が ID とパスワードを持ち、媒体にどのような形で入るかで 3 つに分かれます。

1. 権限付与: クライアントの管理下にアカウントを置いたまま、媒体の仕組みで運用代行会社の担当者を招待する。担当者は自分のユーザーとして入り、クライアントのパスワードは知らない。
2. ID とパスワードの共有: クライアントの ID とパスワードをそのまま受け取り、担当チームで共有して使う。
3. アクセス管理ツール: 運用代行会社が ID とパスワードをツールに登録し、担当者はツールを通してログインする。担当者はパスワードを見ず、ツールが担当者ごとの利用を記録する。パスワード自体を担当者に配る道具(パスワードを保管して配れるアプリなど)は 2 の共有に含める。

| | 権限付与 | ID とパスワードの共有 | アクセス管理ツール |
| --- | --- | --- | --- |
| できること | 担当者ごとに権限の種類を分ける | 媒体の仕組みに関係なく、どのアカウントでも使える | 権限付与のない媒体でも、担当者にパスワードを見せずに使わせる |
| できないこと | 媒体に仕組みがなければ使えない | 誰が操作したかを担当者まで絞れない | 媒体から見た権限は共有 ID のまま |
| 記録の単位 | 招待された担当者(媒体が履歴を残す範囲で) | 共有した ID 1 つ | ツールにログインした担当者 |
| 担当交代時に起きること | クライアント側か代理店側の管理アカウント(Google 広告の MCC など)で、その人の招待を媒体ごとに取り消す | クライアントにパスワード変更を頼み、共有している全員に配り直す | ツール上でその担当者の利用を止める |

表に入りきらない点を型ごとに 1 つずつ添えます。権限付与は、始めるのにクライアント側の設定を変えてもらう必要があります。共有では、担当者ごとにできる操作を分けることもできません。アクセス管理ツールは、導入と登録の手間がかかる代わりに、担当交代のときにパスワードを変えずに済みます。

3 つはどれか一つを選ぶものではなく、組み合わせられます。権限付与ができる媒体はそれを使い、できない媒体を共有 ID かアクセス管理ツールで扱う形が現実的です。権限付与の仕組みについては[権限付与(アカウントを共有しないアクセス)とは](/guides/agency-accounts/what-is-delegated-permission)で説明しています。

## なぜ ID とパスワードの共有が残るのか

権限付与があれば共有は要らないはずですが、実際には共有 ID が残ります。理由は 3 つに分けられ、どれも運用代行会社の側だけではなくせません。

第一に、媒体が権限付与の仕組みを提供していない場合です。ログインの手段が 1 組の ID とパスワードしかない管理画面では、預かり方は共有かアクセス管理ツールに限られます。

第二に、権限付与はあるが、招待されたユーザーにはできない操作がある場合です。所有者のユーザーでしか変えられない設定や、招待された権限では開けない画面があります。その操作のために、所有者の ID を共有する運用が残ります。

第三に、クライアント側の設定を変えられない事情です。権限付与は所有者が招待する仕組みなので、クライアントの担当者に設定の操作を頼まなければ始まりません。クライアントに媒体の管理画面に詳しい人がいない、対応が後回しになる、契約の途中で頼みにくい、といった理由があります。その結果、受け取った ID とパスワードをそのまま使い続けることになります。この運用は珍しくないでしょう。

どの媒体がどの理由に当たるかは変わるので、媒体別の記事で扱います。残った共有 ID について「誰が知っていて、誰がいつ使い、担当交代時にどうするか」が決まっているかが問題です。

## クライアントに説明を求められる場面

預かり方の違いは、クライアントに説明を求められたときに表に出ます。場面は 3 つあります。

セキュリティチェックシート(委託先の安全対策を確かめる質問票)は、個人情報保護法をもとに求められることがあります。同法 25 条は、個人データの取扱いを委託する事業者に、委託先への「必要かつ適切な監督」(委託先がきちんと扱っているか確かめること)を求めています。個人情報保護委員会のガイドライン(通則編)は、その監督の内容として 3 点を挙げています(3-4-4)。適切な委託先の選定、委託契約の締結、委託先における個人データ取扱状況の把握(委託先がどう扱っているかを知ること)です。チェックシートは、預かる業務に個人データの取扱いが含まれる場合、この把握の一手段として求められると読めます。EC モールの受注情報や広告の顧客リストを扱う委託では、運用代行会社はこの監督の対象になると読めます。そのため、アカウントを誰がどう使っているかの説明を求められます。個人データを扱えば、運用代行会社自身も 23 条の安全管理措置(個人データを守るための対策)を負います。それに加えて、委託元の監督(25 条)に応える立場になります。

25 条が及ぶかどうかは、預かる業務に個人データの取扱いが含まれるかで決まります。投稿の作成と配信だけなら含まれないこともあります。DM への対応、キャンペーンの応募者情報、広告の顧客リストを扱えば含まれます。含まれない業務では、説明を求める根拠は契約と取引の慣習になります。

事故時の報告では、誤投稿や誤設定が起きたときに、誰がいつ操作したかを答えられるかが問われます。共有 ID では媒体の記録が ID 単位です。媒体の記録だけでは担当者まで絞れず、勤務時間や作業の分担と突き合わせることになります。権限付与かアクセス管理ツールなら、記録が担当者単位で残ります。

担当交代では、辞めた人や外れた人がクライアントのアカウントに入れない状態を示す必要があります。作業は上の表のとおりです。共有 ID ではクライアントにパスワード変更を頼むことになり、その依頼自体が「共有していた」ことの説明になります。

## 何から始めるか

最初の作業は、預かっているアカウントの一覧を作ることです。1 行に 1 アカウントずつ、次の項目を書きます。クライアント名、媒体、アカウント、預かり方(権限付与・共有・ツール)、使っている担当者、二段階認証のコード(ログイン時に届く使い捨てのコード)を誰が受け取っているか、です。この一覧がないと、担当交代時に何を外せばよいかが分かりません。

次に、一覧の中で権限付与に移せるものを選びます。媒体に仕組みがあり、クライアントに招待の操作を頼める関係にあるアカウントから、担当者ごとの招待に切り替えます。切り替えの際に、それまで共有していたパスワードをクライアントに変更してもらうと、共有の状態を終えられます。

最後に、残る共有 ID の扱いを決めます。アカウントごとに 3 つを書き添えます。パスワードを知っている人の範囲、担当交代時の変更手順、誰がいつ使ったかを残す方法(アクセス管理ツールを挟むか、作業記録を手で残すか)です。ここまでできると、クライアントから説明を求められたときに、一覧を見せて答えられる状態になります。


## このテーマの記事

- [クライアントのセキュリティチェックシートへの、運用代行会社の答え方](/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 問に答えます。根拠は預かっているアカウントの一覧に置きます。
- [Google 広告の MCC(クライアント センター)で代理店アクセスを整理する](/guides/agency-accounts/google-ads-mcc-agency-access): クライアントのアカウントを MCC にリンクし、担当者は MCC のユーザーとして招待します。担当交代は MCC 側でその人のアクセス権を削除すれば済み、クライアントのパスワードは受け取りません。
- [運用担当者の交代・退職時のアカウント引き継ぎチェックリスト](/guides/agency-accounts/handover-checklist): 交代前に担当アカウントの一覧・二段階認証のコードの受け取り先・共有 ID を確かめます。当日は招待の取り消し・パスワード変更の依頼・ツール上での利用停止とクライアントへの連絡を行い、後日に反映を確かめて一覧を更新します。
- [LINE 公式アカウントを複数人・外部と運用するときの権限](/guides/agency-accounts/line-official-account-permissions): 管理者が発行する認証用 URL で担当者ごとにメンバーを追加し、管理者か運用担当者の権限を持たせます。外部の運用代行会社も同じ形で追加でき、外すときはメンバーのリストから削除します。
- [Meta(Facebook・Instagram)のビジネスポートフォリオで代理店に権限を付与する仕組みと、できないこと](/guides/agency-accounts/meta-business-portfolio-agency-access): クライアントのポートフォリオに担当者を「人」として招くか、代理店のポートフォリオを「パートナー」としてつなぎます。ページ・広告アカウント・Instagram ごとに、許す操作(タスク)を付けます。取り消しは所有者側の操作です。
- [Shopify・BASE などカート側のスタッフ権限と、運用代行会社への渡し方](/guides/agency-accounts/shopify-base-staff-permissions): Shopify はスタッフの招待か、パートナー向けのコラボレーターアカウントで渡します。BASE は「スタッフ権限管理 App」でスタッフごとにメニュー単位の権限を付けられます。どちらもオーナーの ID は渡しません。
- [誤投稿・誤設定のあとに原因を追える運用と追えない運用](/guides/agency-accounts/tracing-misposts): 報告に要るのは「誰が・いつ・何を」の 3 つです。共有 ID では媒体の記録が ID 単位で担当者まで絞れず、権限付与かアクセス管理ツールなら人単位で残ります。記録がなければ作業記録から推定するほかありません。
- [運用代行におけるアカウントの預かりとは](/guides/agency-accounts/what-is-delegated-account-access): クライアントが所有する SNS・広告・EC のアカウントを、運用代行会社の担当者が業務のために操作できる状態にすること。委任の範囲とアカウントの扱いは別の問題です。
- [権限付与(アカウントを共有しないアクセス)とは](/guides/agency-accounts/what-is-delegated-permission): アカウントの所有者が、パスワードを渡さずに他の人に操作を許可する仕組み。権限の種類・招待・取り消しの 3 つで成り立ち、誰が操作したかが人ごとに残ります(媒体が履歴を残す範囲で)。
- [X・TikTok の企業アカウントを運用代行するときの権限と共有 ID](/guides/agency-accounts/x-tiktok-business-account-access): X は広告アカウントの権限(ロール)と、投稿や DM を任せる委任機能(X アカウント権限の付与)を別々に付けます。TikTok はビジネスセンターにメンバーかパートナーとして招きます。どちらもパスワードは渡しません。

## よくある質問

**クライアントのパスワードを担当者に教えずに運用できますか**

媒体に権限付与の仕組みがあれば、担当者を招待する形で教えずに済みます。仕組みがない媒体や、クライアント側の設定を変えられない場合は、共有 ID か、パスワードを担当者に見せないアクセス管理ツールが選択肢になります。

**共有 ID で運用すると何が困りますか**

媒体の記録が ID 単位になり、誰が操作したかを担当者まで絞れません。担当交代のたびにクライアントにパスワード変更を頼み、共有している全員に配り直す作業も残ります。

**担当者が辞めたとき、まず何をしますか**

その人が使っていたアカウントを一覧で確認し、権限付与なら招待を取り消し、共有 ID ならクライアントに変更を頼み、アクセス管理ツールならその担当者の利用を止めます。一覧がないと漏れが分かりません。

**運用代行会社にも個人情報保護法の義務がありますか**

個人データを扱えば、運用代行会社自身が 23 条の安全管理措置(個人データを守る対策)を負い、加えて委託元の監督(25 条)に応える立場になります。

## 参考資料

- [個人情報の保護に関する法律(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 は、権限付与ができない媒体や、所有者の ID でしかできない操作で使います。運用代行会社の管理者が預かった ID とパスワードを登録し、担当者はパスワードを見ずにログインします。利用は担当者ごとに記録され、担当交代時は割り当てを外すだけで入れなくなります。

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

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