オンライン秘書にアカウントを預けるとき：共有IDを避ける権限の設計

結論：ID とパスワードを渡す前に、「誰が、どの権限で、いつまで」を設計する

オンライン秘書や事務代行では、会計のクラウド、メール、カレンダー、チャット、顧客管理の画面、クラウドストレージ、ネットバンキングなど、任せる側が日々使っている道具に、受ける側が入って作業する場面が多くあります。このとき、いちばん手っ取り早いのは、ID とパスワードを教えて、同じアカウントで作業してもらう方法です。しかし、この方法は、手っ取り早い分だけ、あとで困る点が多い方法でもあります。

共有の ID とパスワードで作業すると、画面の履歴には「任せる側本人が操作した」としか残りません。誰が何をしたのかが後から分からず、ミスや不正があっても原因をたどれません。受ける側がパスワードを控えて持ち続ければ、契約が終わったあとも入れる状態が残ります。パスワードの変更を忘れれば、その後の操作は、誰のものか判断しにくくなります。こうした問題は、契約書に「アカウント情報を厳重に管理する」と書くだけでは解決しません。

• 最初に考えるのは、パスワードを渡さずに済む方法。多くのサービスには、別の人を招待して個別の ID と権限を与える仕組みがある。
• 権限は必要最小限にする。閲覧だけでよい作業に、編集や削除の権限を与えない。管理者の権限は任せる側に残す。
• 二要素認証や端末の条件は、契約書に書いておく。認証の第二の要素（確認コードを受け取る端末など）を誰が持つのかを決める。
• 操作の記録が残る設計にする。誰が・いつ・何をしたかが後から確認できれば、ミスにも不正にも対処できる。
• 生成AIや外部のサービスに、預かった情報を入力してよいかどうかを書く。書かないと、受ける側は便利さを理由に使ってしまう。
• 終了時は、権限の取消し、パスワードの変更、連携サービスの切断までを手順にして、完了を確認する。

このページは、会計・メール・カレンダー・チャット・顧客管理のツールなど、事務で預けるアカウントの権限設計に絞って説明します。紙や原本、データファイルの預かりは資料の預かりのページで、個人データを含む情報の監督は個人データを預けるときの監督のページで扱います。

預けるアカウントの種類と、渡し方の選択肢

アカウントといっても、預ける対象の性質で、気をつけるべき点が大きく変わります。メールは、他のサービスのパスワード再設定の連絡も届くため、入れる人は、実質的にその人の他のアカウントにも影響を及ぼせます。ネットバンキングやクラウド会計は、お金の動きに関わります。顧客管理のツールには、個人データが大量に入っています。種類ごとに、渡し方を考えます。

表のとおり、多くのサービスには「ユーザーを招待する」「権限を役割で分ける」「閲覧だけの権限を与える」といった機能があります。この機能を使えば、パスワードを教えずに、必要な作業をしてもらえます。サービスによっては、無料の枠では追加のユーザーを作れず、有料の契約が必要なことがあります。そのような費用は、誰が負担するのかも、報酬や費用の条項と合わせて決めておきます。費用の分担の考え方は報酬の決め方のページで説明します。

共有の ID を使わざるを得ない場面もあります。たとえば、サービスの仕組み上、ユーザーを追加できない場合や、一つの ID でしか使えないシステムを使っている場合です。この場合は、共有の ID で作業する理由、共有する範囲、パスワードの受渡しの方法、変更の時期を、書面に残します。そして、サービスの利用規約で ID の共有や貸与が禁じられていないかを、任せる側が確かめます。禁じられているのに共有して作業させると、規約違反を理由にアカウントを停止される危険があります。

共有 ID を避ける設計：個別 ID・最小権限・管理者権限の留保

権限の設計で、基本になる考え方は三つあります。

個別 ID の利点は、操作の記録に、誰が操作したかが残ることです。担当者が複数いても、それぞれの操作が区別され、ミスの原因をたどれます。担当者が交代したときも、前の担当者の ID を停止するだけで済み、パスワードの変更や連絡の手間がかかりません。

最小権限の考え方は、業務の範囲を決める作業と、つながっています。どこまでが業務の範囲かを決めていれば、必要な権限も自然に決まります。たとえば、請求書の作成と送付が業務であれば、作成の権限と送付の権限が必要です。入金の確認だけが業務であれば、入金の閲覧の権限で足ります。業務の範囲の決め方は業務範囲の線引きのページで説明しています。

管理者権限の留保は、特に重要です。管理者の権限があれば、受ける側は、自分で他の人を追加し、権限を広げ、設定を変えられます。受ける側を信頼していても、管理者の権限を渡すと、事故があったとき、受ける側の操作と任せる側の操作を区別できず、責任の判断が難しくなります。任せる側が管理者の権限を持ち続けることで、契約の終了時にも、権限の取消しを自分の手で行いやすくなります。

認証・端末・ネットワークの条件：二要素認証と作業環境

権限の設計に加えて、受ける側が、どの環境から、どの方法で入るのかも、条件として決めておきます。

二要素認証は、パスワードに加えて、確認コードや認証アプリ、物理的なキーなど、もう一つの要素で本人を確かめる仕組みです。個別のユーザーを付与する場合は、受ける側が自分の端末で第二の要素を持つため、受ける側が二要素認証を設定する、という約束で足ります。共有の ID を使う場合は、第二の要素の確認コードが、任せる側の携帯電話などに届くことがあり、その場合は、受ける側が入るたびに任せる側に連絡が必要になります。この手間を避けるために、二要素認証を外してしまうと、安全性が大きく下がります。共有を避ける理由の一つが、ここにあります。

端末の条件も決めます。受ける側が自分の端末で作業する場合、その端末に、画面のロック、最新の更新、ウイルス対策などの基本的な対策を求めます。複数の人が使う共用の端末や、公共の無料無線 LAN からの接続は、避けるか、条件を付けます。端末の紛失や盗難があったときの連絡も、事故対応の条項と合わせて決めます。

画面共有やリモート操作を使って作業する場合は、画面に映った情報が録画や記録で残る可能性、画面の共有中に別の情報が見えてしまう可能性にも注意が必要です。作業の終了後に、共有やリモート接続を切る手順も書いておきます。

操作の記録と、不正アクセス禁止法の考え方

誰が、いつ、何をしたかが分かる記録があれば、ミスの原因の特定も、不正の疑いへの対応もできます。記録の残し方は、アカウントの設計と一体です。個別のユーザーを付与すれば、多くのサービスが、変更履歴、閲覧履歴、ログイン履歴を、ユーザーごとに残してくれます。履歴の保存期間や、確認できる範囲は、サービスの契約の種類で変わるため、導入の時点で確かめておきます。

記録を確認する権限と手順も決めます。任せる側が、受ける側の操作の履歴を、いつでも確認できるのか、定期的に確認するのか、問題があったときに限るのか。受ける側にとっても、自分の操作の記録が残ることは、疑いをかけられたときの身の潔白の証明になります。

ここで、アカウントに入る行為と法令の関係を、整理しておきます。不正アクセス行為の禁止等に関する法律3条は、何人も不正アクセス行為をしてはならない、と定めています。同法2条4項1号は、不正アクセス行為の一つとして、他人の識別符号（ID やパスワードなど）を入力して、アクセス制御機能により制限されている利用ができる状態にさせる行為を挙げ、その括弧書きで、アクセス管理者または当該識別符号に係る利用権者の承諾を得てするものは除かれる、と定めています（条文の趣旨）。

つまり、任せる側が、自分の ID とパスワードで受ける側にアクセスさせることを承諾している場合は、この条文の構造上は、不正アクセス行為の除外の対象になる、と整理されます。しかし、これは、承諾が及ぶ範囲の話です。承諾した範囲を超えて、別のサービスや、承諾していない情報に入る行為は、承諾を得ていないものとして扱われ得ます。契約書に、入ってよいアカウントと、してよい操作の範囲を書いておくのは、この意味でも重要です。範囲が書かれていないと、受ける側が「ここまでは承諾の範囲だと思った」と考えて操作したときに、意見が食い違う余地が生まれます。

また、サービスの利用規約が、ID の共有や貸与、他人による利用を禁じている場合は、法令上の問題とは別に、規約違反の問題が生じます。アカウントを預ける前に、利用するサービスの規約を確かめるのは、任せる側の責任として整理しておくのが現実的です。

生成 AI・外部サービスへの入力：便利さと、預かった情報の外への流れ

事務の現場では、文章の下書き、議事録の要約、翻訳、表の整形などに、生成 AI や外部のオンラインサービスを使う場面が増えています。受ける側が自分の判断でこうしたサービスを使うと、預かった情報が、契約当事者の知らないところで、外部の事業者に渡ることになります。

この点について、契約書に何も書かれていなければ、使ってよいのか、いけないのかが分かりません。任せる側が知らないうちに、顧客の氏名や取引の内容が外部のサービスに入力されていた、という事態が、あとから発覚する可能性があります。そのため、契約書または運用ルールに、次の点を決めておきます。

• 外部のサービス（生成 AI、翻訳、文字起こし、クラウドの変換ツールなど）に、預かった情報を入力してよいか。入力してよいなら、どのサービスで、どの種類の情報までか。
• 入力した情報が、サービスの提供側で学習や改善に使われない設定になっているか。設定の確認は誰が行うか。
• 個人データを含む情報を入力する場合は、そのサービスの提供側への提供や委託に当たるかどうかを、個人情報保護法27条5項1号（委託に伴う提供）なども踏まえて整理する。判断が難しい場合は、入力しない運用にする。
• 入力した内容と、得られた出力の取扱い。出力を成果物として使う場合の、権利や正確性の確認。
• 許可なく使った場合の扱い（報告、削除の依頼、再発防止）。

最も簡単な運用は、「任せる側が事前に承諾したサービスに限り使う。個人データや秘密にしている情報は入力しない」と書くことです。業務の効率を落とさずに使いたい場合は、使ってよいサービスの一覧を別紙に置き、定期的に見直します。外部のサービスを使う場合の個人データの扱いの整理は、個人データを預けるときの監督のページで扱っています。

終了時の権限の失効：パスワード変更と連携の切断までを手順にする

アカウントの預かりで、終わり方の設計は、始め方と同じくらい重要です。契約が終わったのに、受ける側がまだ入れる状態が残っていれば、情報の流出や、意図しない操作の危険が続きます。

この手順で、最も見落とされやすいのは「連携」です。たとえば、メールの自動転送の設定や、カレンダーの共有、外部アプリへのアクセスの許可は、ユーザーを削除しても、設定の側が残る場合があります。受ける側の端末にログイン状態が残っていることもあります。終了時の一覧の突合は、ユーザーだけでなく、連携や共有の設定も対象にして行います。

契約書には、終了時に任せる側が行うこと（権限の取消し）と、受ける側が行うこと（認証情報の破棄、保存した情報の削除、完了の報告）を、それぞれ書きます。取消しの期限も書きます。契約終了の直前や直後の、何も決まっていない期間に、受ける側が入れる状態が続くと、トラブルのもとになるからです。終了時の全体の処理は契約の終わり方と引継ぎのページにまとめています。

アカウント預かりの確認表

よくあるご質問

あわせて読みたいページ

本ページは一般的な情報提供です。個別の取引への当てはめは、業務の内容や預けるものの種類、当事者の事業の形によって異なることがあります。書き方の例として紹介している内容は、一般に見られる書き方を整理した例で、特定の事業者や案件を示すものではありません。条文は e-Gov法令検索で確認しています。参考: e-Gov法令検索 / 個人情報保護委員会 / 公正取引委員会 / 厚生労働省