運用代行会社がクライアントとの契約に入れておくアカウントの条項
入れておきたいのは、アカウントの渡し方、使う担当者の範囲、記録と報告、事故のときの通知、終了と交代の手続きの 5 つです。自社だけで守れる約束と、クライアントに動いてもらう約束を分けて書きます。
5 つの条項はどれも、運用代行会社が自社だけで守れる約束と、クライアントに動いてもらう約束を分けて書くためのものです。クライアント(任せる側)が入れる条項は委託契約に入れるアカウント条項の要点にまとめています。
任される側が自分の案を持っておく理由
個人データの取扱いを任せるとき、クライアントは個人情報保護法 25 条で委託先を監督する立場になります。任される側については、IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版に原則があります。原則 2 は「受託している場合には、委託元の要求に応じる必要があります」としています。
それでも運用代行会社が自分の案を持っておくのは、自社だけでは守れない約束を、相手の案のまま引き受けないためです。権限付与は持ち主が招待する仕組みです。媒体(広告や SNS などのサービス)によっては、代理店側の管理アカウントで担当者を付け外しできます。Google 広告の MCC がその例です。そうした形がない媒体では、担当者を加える操作も外す操作もクライアント側で行います。「交代の当日に入れなくする」と約束しても、クライアントの操作が遅れれば守れません。
契約に書かなくても負う義務もあります。投稿や入稿のように、成果物の完成ではなく作業そのものを任せる形なら、民法 656 条の準委任に当たると読めます。準委任は、契約を結ぶといった法律行為ではない作業を任せる契約で、委任の規定が当てはめられます。そのため 645 条により、任された側はクライアントの請求があればいつでも作業の状況を報告します。終わったあとは、遅れずに経過と結果を報告します。請求は「いつでも」来るので、何を記録するかを決めておかないと、担当者ごとの作業をあとから集め直すことになります。
一方で、引き受ける対策の水準には法律上の目安があります。個人情報保護委員会のガイドライン(通則編)は 3-4-4 の注(※2)で、法律上は「委託先は、法第 23 条が求める水準の安全管理措置を講じれば足りると解される」としています。クライアントの社内規程と同じ対策を求められても、それは法律の求めではなく合意で決まる話です。実施できるかを確かめてから同意します。
5 つの条項と文例
文例の「委託者」はクライアント、「受託者」は運用代行会社です。
アカウントの渡し方とクライアント側の協力
委託者は、各媒体の権限付与の機能で、受託者の管理アカウントまたは受託者が届け出た担当者に、業務に必要な権限を付与する。権限付与の機能がない媒体に限り、委託者は ID とパスワードを、委託者が定める方法で受託者に通知する。受託者の管理アカウントで行えない担当者の追加または削除は、受託者の依頼を受けて、委託者が◯営業日以内に行う。
前半は、渡し方を先に決めておくための文です。権限付与ができる媒体では、担当者は自分のユーザーで入り、誰が操作したかが人ごとに残ります(媒体が履歴を残す範囲で)。媒体によっては、ヘルプでログイン情報を人に教えないよう求めています。YouTube ヘルプは「パスワードやログイン情報を誰とも共有しないでください」と書き、チャンネルの権限で承認したアカウントから入るよう求めています。こうした媒体で ID とパスワードを受け取る約束は避けたいところです。後半の期限は、運用代行会社の側で付け外しできない媒体のためのものです。クライアントの操作待ちで追加や削除が止まっても、その遅れが運用代行会社の落ち度にならないようにします。
使う担当者の範囲と再委託
受託者は、委託者のアカウントを使う担当者の名簿を委託者に届け出て、変更があれば◯日以内に更新する。受託者の従業員でない者(業務委託の個人を含む)に使わせるときは、事前に委託者の書面による承諾を得る。
名簿は、クライアントにとっては取扱状況をつかむ材料になり、運用代行会社にとっては誰に使わせてよいかの合意になります。社外のフリーランスに作業を任せるのは、クライアントから見ると再委託(任された仕事をさらに別の人に任せること)です。ガイドライン 3-4-4(3) は、再委託について、委託元が事前に報告を受けるか承認することを望ましいとしています。業務の一部をそのまま任せるなら、民法 644 条の 2 の制限にも当たると読めます。この条は、任された側が別の人に任せられるのを、許しを得たときか、やむを得ない事情があるときに限っています。承諾の手続きを書いておけば、忙しい時期に外部の人を入れる前に何をすればよいかがはっきりします。
記録と報告の範囲
受託者は、担当者ごとのアカウントの使用日時と作業内容を記録し、契約終了後◯年間保存する。委託者の求めがあるときは、受託者が保有する記録の範囲で、◯営業日以内に提出する。
「受託者が保有する記録の範囲で」と書くのは、出せる記録が渡し方で変わるからです。権限付与なら、媒体の履歴に担当者ごとの操作が残ります(媒体が履歴を残す範囲で)。共有 ID では媒体の記録は ID 単位なので、誰が操作したかは、運用代行会社が別に付けた作業記録に頼ることになります。クライアントの社員も同じ ID で入っていると、その操作と運用代行会社の操作を記録から分けられません。そうした ID があるなら、クライアント側でも使うかどうかと、使うときは前もって知らせることを、この条項に書き足します。
事故のときの通知と協力
受託者は、アカウントの不正な使用、ID・パスワードの流出またはそのおそれを知ったときは、知った時から◯時間以内に委託者に通知し、調査に協力する。委託者は、自ら行ったパスワード、二段階認証、権限の変更を、受託者に速やかに知らせる。
個人データの漏えいなどで、個人情報保護委員会への報告が必要な事態があります。ガイドラインでは、その場合は原則として委託元と委託先の両方が報告の義務を負います。ただし委託先は、委託元に通知すれば報告の義務を免れます(個人情報保護法 26 条 1 項ただし書)。ガイドライン 3-5-3-5 は、この通知の「速やか」の目安を、委託先が知った時から「概ね 3~5 日以内」としています。契約の◯は、夜間や休日に誰が気づき、誰が連絡するかを決めてから、守れる数字を入れます。IPA のガイドラインも「取引先 / 外部情報サービスの管理」の項で、事故のときの通知の義務と連絡先を文書にするよう勧めています。役割と連絡の体制は、相手と合意しておくものとしています。
後半の文は、クライアントがパスワードを変えた結果、担当者が入れなくなったときに、それを乗っ取りと取り違えないためのものです。
終了と担当交代のときの手続き
契約が終了したとき、または担当者が交代したときは、受託者は対象の担当者の使用を止め(受託者の管理アカウントで行える権限の削除を含む)、保存していた ID・パスワードを消去し、消去した日を委託者に書面で報告する。委託者は、受託者の依頼を受けて、受託者の管理アカウントで行えない権限の削除と、受託者に知らせていたパスワードの変更を◯営業日以内に行う。
この条項では、運用代行会社の作業とクライアントの作業を分けて書きます。代理店側の管理アカウントで付け外しできる媒体なら、権限の削除は運用代行会社が当日に自分で行えます。そうでない媒体の権限の削除と、知らせてもらっていたパスワードの変更は、クライアントの操作です。依頼と期限を書いておかないと、辞めた担当者が入れる状態が残っても、運用代行会社からは止められません。IPA のガイドラインも「取引先 / 外部情報サービスの管理」の項で、アクセス権を回収する側に勧めています。契約終了時の回収は、責任者と期限を決めて行い、記録を残します。
契約の文言は、任せる業務と媒体に合わせて書き直したうえで、弁護士の確認を受けてください。この記事は法的助言ではありません。
よくある質問
クライアントの求める対策が法律より厳しいときは
ガイドラインは、法律上は委託先の対策は個人情報保護法 23 条が求める水準で足りるとしています。それを超える対策は合意で決まるので、実施できるかを確かめてから同意します。
個人データを扱わない運用でも条項は要りますか
25 条の監督が及ばない業務でも、作業そのものを任せる契約なら民法の準委任と読め、求めがあれば作業の状況を報告する義務(645 条)があります。何を記録するかを決めておきます。
フリーランスに作業させるときは何を書きますか
クライアントから見ると再委託に当たり、ガイドラインは事前の報告か承認を望ましいとしています。仕事の一部をそのまま任せるなら民法の制限にも当たると読めます。事前に書面で承諾を得る手続きを書きます。
個人データの流出に気づいたら、いつまでに知らせますか
委員会への報告が必要な事態なら、ガイドラインは委託元への通知の目安を知った時から概ね 3〜5 日以内とし、通知すれば委託先の報告は免除されます。それ以外は、契約で守れる期限を決めます。
契約のひな形に ID とパスワードの通知があったら
権限付与ができる媒体では、担当者ごとの招待に替えてもらうよう相談します。YouTube のように、ヘルプでログイン情報を誰とも共有しないよう求めている媒体もあります。
Junify の場合
- 人手で続けると
- クライアントごとに渡し方を決め、担当替えのたびに権限を付け外しし、どの担当者がどのクライアントのアカウントを使ったかを媒体ごとに追い続けることになります。
- Junify なら
- 共有 ID のままだと、交代のたびにクライアントへパスワードの変更を頼む作業と、作業記録を求められるたびに、その日誰が入ったかを勤務表と突き合わせる作業が人の手で続きます。導入時にクライアントと相談してパスワードを変え、Junify だけが持つ形にすれば、担当者は知らないまま入れ、誰がいつ使ったかは担当者ごとに残ります。交代の日は割り当て(使ってよい人の指定)を外すだけです。
参考資料
- 民法(e-Gov 法令検索)
- 個人情報の保護に関する法律(e-Gov 法令検索)
- 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)
- IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版
- Google 広告ヘルプ「MCC アカウントのユーザーとアクセス権を管理する」
- YouTube ヘルプ「ハッキングされた YouTube チャンネルを復元する」
同じテーマの記事
-
クライアントのアカウントの扱いを、運用代行会社のセキュリティの文書にどう書くか
誰でも読める基本方針、社内の規程、クライアントごとに渡す説明書の 3 つに分けて書きます。IPA の規程のサンプルは自社で ID を出して消せる前提なので、預かったアカウント向けに書き換え、説明書にはその結果を書きます。
-
Qoo10・au PAY マーケットの店舗管理を代行するときの担当者のアカウント
Qoo10 は QSM のサブ ID で担当者の画面を分けられますが、店舗の ID を共有する仕組みです。au PAY マーケットは分け方が公開されていません。両モールの規約が ID の共有を禁じているので、使う前にモールに確かめます。
-
SNS の予約投稿ツールにクライアントのアカウントをつなぐ権限と、担当が外れたときに外すもの
連携は、つないだ人の媒体上の権限か、媒体が発行する連携用の文字列で成り立ちます。つなぐ操作はクライアント側の権限者に頼み、担当が外れたら、ツールのメンバー・媒体の権限・連携そのものの 3 か所を確かめます。