利用者アカウント・禁止事項・セキュリティの責任分担

契約の当事者は法人でも、実際に使うのは役員・従業員・派遣労働者・業務委託先の担当者です。提供者から見えない利用者の行為の責任を、契約で顧客に置きます。

トップページ › 利用者アカウント・禁止事項・セキュリティの責任分担
ユーザー数を無制限にしたまま利用者の行為の責任を書かずにいると、退職者のアクセスによる事故で、提供者が「顧客側の行為」を立証する立場に置かれます。

このページの要点

  • 利用者に派遣労働者や業務委託先の個人を含めるかを定義し、管理者の権限を決める。
  • 退職者のアカウントを削除・無効化する義務を顧客に置き、外部認証の障害の扱いを決める。
  • みなし条項は、提供者の責めによる認証情報の不正利用を除いて書く。
  • 競合調査・性能比較の公表・脆弱性探索を具体的に禁止し、顧客と提供者の管理の領域を表で分ける。

結論:ユーザー数を無制限にするほど、アカウントの管理と利用者の行為の責任を顧客に置く

法人向けのSaaSでは、契約の当事者は法人でも、実際に使うのはその役員・従業員・派遣労働者・業務委託先の担当者です。提供者からは誰が使っているのか見えにくく、退職した人のアカウントが残っていたり、1つのIDを何人もで使っていたりしても気づけません。アトラス行政書士法人がレビューした書類では、ユーザー数を無制限にしながら、アカウントの管理と利用者の行為の責任が書かれていない例がありました。この状態で事故が起きると、提供者が「それは顧客の側の行為だ」と立証する立場に置かれます。

このページでは、利用者の範囲と管理者、退職者のアカウント、共有の禁止と数え方、「アカウントの操作は利用者のもの」とみなす条項の限界、禁止事項(競合の調査・性能の比較の公表・脆弱性の探索など)、セキュリティの責任分担を扱います。料金と利用者の数の関係は料金設計のページをご覧ください。

利用者の範囲と、管理者を定義する

まず、顧客の側の誰がサービスを使えるのかを定義します。事務所の書類では、次のように書いています。

利用者と管理者の定義(事務所の書類から)

サービス利用者に含める者管理の仕組み
社内資料を読み込むAIサービスの試行版顧客の役員・従業員(派遣労働者と、顧客の業務に従事する業務委託先の個人を含む)利用者の行為は顧客の行為として顧客が責任を負う
事業者専用の管理クラウド契約者の役員・従業員・業務委託先企業アカウントと権限設定を管理する「管理者」を定義。1つの契約で複数の利用者を認める
広告の制作を管理するクラウド組織内の責任者(アカウント管理者)と、管理者が招待する従業員・委託先(メンバー)管理者とメンバーの二段構え
スクール向けの顧客管理クラウド(第2版)講師・スタッフ(ユーザー数は無制限)アカウントの管理、退職者のアカウントの削除・無効化、利用者の行為は顧客の行為

派遣労働者や業務委託先の個人を利用者に含めるかどうかは、実務ではよく問題になります。含めないと、顧客の業務を担う外部の人が使うことが契約違反になり、含めるなら、その人たちの行為も顧客の責任であることを書いておく必要があります。事業者向けの予約管理クラウドの規約では、招待されたメンバーが「利用者」に含まれる定義になっていたため、支払の義務、禁止事項、個人情報の委託元の主語にメンバーまで含まれるように読めてしまう、という問題も指摘しました。誰が契約の当事者で、誰が使うだけの人なのかを、定義の段階で分けておきます。

グループ会社での利用も、定義の段階で決めておく事項です。スカウト型の採用クラウドの企業向け規約では、本社・支社・子会社・関連会社・委託先などが実際に使う場合にも規約を準用する一方、当社の書面の承諾がなければ再許諾や転用はできないとし、個別契約書でもグループ会社・親会社・子会社への貸与と再許諾を禁止しました。料金を1社単位で決めているなら、グループの他社が同じアカウントで使うことをどう扱うかは、料金と利用の範囲の両方に関わります。取引先を招待して使わせる広告の制作を管理するクラウドでは、招待された制作会社の中のメンバーのアカウントの管理責任は制作会社にあり、そのアカウントを使った行為は制作会社自身の行為とみなす、と招待された側の規約に書いています。事業者専用の管理クラウドも、1つの契約で複数の利用者を認め、利用者の行為は契約者自身の行為と同視し、認証情報による操作は契約者又は正当な利用者の利用とみなす、としました。

退職者のアカウントは、誰が止めるか

スクール向けのクラウドのひな形について、確認の報告書では、ユーザー数が無制限で、提供者が把握も管理もできない多数の講師やスタッフが顧客の判断で生徒のデータにアクセスする構造だ、と指摘しました。禁止事項・アカウントの管理・利用者の行為の顧客の責任がないと、講師がデータを持ち出した、退職した講師がアクセスを続けていた、生徒に不適切な連絡をした、といった事故が起きたときに、提供者が「顧客の側の行為である」ことを立証しなければなりません。

事務所の改訂例:アカウントの管理

退職者・権限を失った利用者

改訂前定めなし。(依頼者のひな形)
改訂後依頼者の第2版で、顧客がアカウントを管理し、退職者のアカウントを削除又は無効化すること、利用者の行為は顧客の行為とみなすことを定めました。

理由退職者のアクセスの継続は、提供者には見えません。止める義務を顧客に置くことで、事故の責任の分かれ目がはっきりします。

  • 外部の認証を使う場合。採用支援のクラウドでは、大手のIT企業のアカウントによる外部の認証を使い、退職などで権限を失った利用ユーザーのアカウントは契約者が速やかに無効化する義務を負う、外部の認証サービスに起因する障害は当社の責任の外、と定めました。
  • 削除漏れの免責。事業者専用の管理クラウドでは、「退職者又は外部関係者のアカウントの削除漏れ」による損害は当社が責任を負わない、と明記しています。
  • 手続がない例。予約管理クラウドの規約では、退任・退職したメンバーの権限を解除する手続がなく、管理の責任もログインに使うメールアドレスに限られていて、パスワードなどの認証情報や不正なログインのときの分担が書かれていませんでした。

共有の禁止と、利用者の数え方

1つのアカウントを複数人で使うことを禁止するかどうかは、料金の設計と直結します。議事録のクラウドでは、利用者1人に発行したアカウントを「他者(同一法人内の者を含む)」と共有することを禁止しました。同じ会社の中でも共用を許さない、1人1アカウントの課金を前提にした規定です。確認したデータベースのクラウドの契約書でも、複数人が1つのIDを共同で保有することを禁止していました。

一方で、利用者の上限の数え方には注意が要ります。試行版の契約では、上限を「登録されている利用者の数」で数え、登録を削除すればその枠を他の人に割り当てられる、と書きました。「1つの登録を複数人で共用すること」の禁止と、「退職者を消して新しい人を登録すること」の自由を区別しておかないと、退職者を消しても枠が戻らない、という読み方の余地が生じるからです。

閲覧できる人を絞る書き方(事務所の書類から)

閲覧は認可した1名

タブレットで履歴書を入力・共有するシステム

  • 採用企業に複数のアカウントを発行しても、入力の時を除き、データの管理・検索・閲覧は提供者が認可した貸与者1名に限る
  • 貸与者以外との共有、認可のない者の閲覧を禁止

権限のある者だけ

スカウト型の採用クラウド

  • 学生の情報を社外で閲覧・複製・保存しない
  • 社内でも権限を与えた者に限る
  • 同じIDでの複数人のアクセス、グループ会社への貸与を禁止

「アカウントの操作は利用者のもの」とみなす条項の限界

多くのSaaSの規約には、「ID・パスワードを用いて行われた操作は、利用者自身が行ったものとみなす」という条項があります。予約管理クラウドの規約の確認では、この条項が当社のシステムに起因する不正な操作(当社の脆弱性を突かれた乗っ取りなど)にまで及ぶと読まれれば、不当な条項と評価されるおそれがある、と指摘しました。みなし条項は、顧客の管理の領域で起きたことについて顧客に責任を負わせるためのものなので、提供者の側に原因がある場合を除いておきます。

条文例アカウントの管理(事務所の書類を一般化)

  1. 契約者は、利用者の登録、権限の付与及び削除を自らの責任で管理し、退職その他の事由により権限を失った利用者のアカウントを速やかに削除又は無効化します。
  2. 契約者は、1つのアカウントを複数の者に共用させてはなりません。利用者の数は登録されているアカウントの数によって数え、契約者はアカウントの登録を削除したときは、その枠を他の利用者に割り当てることができます。
  3. 認証情報を用いて行われた本サービスの利用は、契約者又はその利用者による利用とみなします。ただし、当社の責めに帰すべき事由により認証情報が第三者に利用された場合は、この限りではありません。
  4. 当社は、不正な使用又はセキュリティ上の問題を検知したときは、速やかに契約者に通知し、アカウントの停止、認証情報の再発行その他必要な措置をとることができます。

最後の項は、法人向けの業務支援クラウドの約款で、レビューを受けて加えた当社側の義務です。みなし条項にも、当社に故意・重過失があれば別、という限定を置いています。

その約款のレビューでは、アカウントの管理が契約者の責任とだけ書かれ、提供者の側の対処の義務がない点を利用者の保護の観点から挙げ、合理的なセキュリティの対策を講じ、不正なアクセスが分かれば速やかに通知すること、二要素認証やアクセスのログの閲覧を用意することを提案しました。約款に取り込んだのは通知の義務です。送客の業務提携の契約では、提携先のAPIを使うためのアカウントについて、認証の方式をメールアドレス・パスワード・二段階認証とし、許可された担当者だけが使い、第三者に開示・貸与・共有しないこと、漏えいや不正な利用があれば速やかに通知して被害の拡大を防ぐことを定めています。人が画面から使うアカウントだけでなく、システムどうしをつなぐための認証情報も、管理の対象として書いておきます。

アカウントの停止の事由も、アカウントの条とつなげておきます。試行版の契約では、不正な利用の疑いがあるとき、セキュリティ上提供の継続が著しく困難なときは、事前の通知なく直ちに停止し、停止後速やかに通知し、事由が解消すれば速やかに再開する、としました(料金改定と支払のページで扱う未払いの停止と同じ条に置いています)。採用支援のクラウドでは、規約違反の防止や法令の遵守のためにも、事前の通知なくアカウントを制限できる、と目的を加えています。

禁止事項:競合の調査、性能の比較の公表、脆弱性の探索

法人向けのSaaSでは、一般的な禁止事項(法令違反、第三者の権利の侵害、過大な負荷)に加えて、競合他社による調査や模倣への備えが必要になります。試行版の契約の修正文案では、禁止事項を10号にまとめ、次の点を工夫しました。

  • リバースエンジニアリングの禁止に加えて、本サービスや生成物を競合のサービスやAIモデルの開発・学習に使うこと、性能の評価や比較の結果を無断で公表することを禁止した。
  • 「性能を評価すること」自体は禁止事項から外した。試行版では顧客が有用性や品質を確かめる協力をすることになっており、それが外形上は性能の評価に当たるため、公表の禁止に委ねた。
  • 「乙が不適切と判断する行為」という包括的な条項は置かなかった。顧客の法務がほぼ確実に削除を求めるからです。
  • 機械的な大量のアクセスは、システムの安定性の観点から別の条で制限し、禁止事項(目的の観点)とは区別した。

競合・模倣への備えの書き方(事務所の書類から)

サービス書き方
事業者専用の管理クラウド競合サービスの調査・分析・模倣・開発の目的のおそれを申込みの承諾拒否の事由に。競合目的の利用と、画面・スクリーンショット・動画・操作方法の無断公開を禁止。画面構成・機能仕様・データ構造・操作性・業務フローを使った同種サービスの開発(第三者にさせることを含む)を禁止。競合調査は即時の利用停止・解除の事由
投稿を生成するクラウド競合他社による利用と、調査目的の利用(データの収集・機能の分析・リバースエンジニアリング)を禁止し、利用停止の事由にも挙げる
スクール向けの顧客管理クラウド(第2版・修正加筆版)脆弱性の探索は事前の書面の承諾がある場合を除き禁止。同種サービスの提供の禁止は「本サービスを利用して」提供する行為に限定

予約管理クラウドの規約の確認では、要配慮個人情報の入力を「求める行為」だけを禁止していたため、自由記入欄にお客様が自ら書き込む場合は対象外になること、確認やリマインドのメールの送信の基盤に広告を混ぜる行為や予約者以外に送る行為の禁止がないこと(迷惑メールとして扱われれば、送信の基盤を共有する全利用者に影響する)も指摘しました。「当社が不適切と合理的に判断する行為」という号は、客観的な合理性を取り込んでいるので維持してよいと評価しています。包括条項は、「合理的に」の限定があるかどうかで評価が変わります。

料金や利用の上限を守らせるための禁止事項も置いておきます。スクール向けのクラウドの第2版では、再販・貸与と、AI機能の公正利用の上限を回避する行為を禁止しました。生成AIを統合した法人向けクラウドでは、サービスの全部又は一部の再販売・再配布・再許諾と、承諾のない営利行為を禁止しています。ソフトウェアの使用許諾では、権利の表示や保護の機能、ライセンスの管理を回避すること、許諾の範囲を超えたバックアップを禁止しました。予約管理クラウドの規約のように、ブランドや店舗の単位で1アカウントとし、有料の契約もブランドごととする数え方をとるなら、複数のブランドを1つのアカウントでまとめて使うことの扱いも、禁止事項か料金表のどちらかに書いておきます。

セキュリティの責任分担(共同責任モデル)を契約に書く

セキュリティの事故が起きたとき、顧客の管理の領域と提供者の管理の領域を契約で分けておくと、責任の分かれ目がはっきりし、損害の分担(過失相殺)にも影響します(責任制限のページ)。試行版の契約では、次の表を報告書に示しました。

共同責任モデル(社内資料を読み込むAIサービスの試行版)

顧客の管理提供者の管理
接続する資料の範囲とその権利解析用の複製・インデックスの保護と目的の限定
外部ストレージの側の権限の設定取得した権限情報に基づくアクセスの制御
利用者の登録と削除、アカウントの管理管理者に本文を見せない設計、終了後の削除
端末とネットワーク、利用者の教育基盤とAIのAPIの選定、脆弱性への対応、監視、インシデントへの対応
  • 手段の債務として書く。試行版の契約の原本は、試行版でも安全管理の義務を免れないこと、問題が一切生じないことは保証しないこと、合理的な措置を講じること、脆弱性があるだけでは責任を負わないこと、顧客の管理の事項は免責されることを定めており、方向は適切と評価しました。
  • ポリシーで分担を示す。広告の制作を管理するクラウドのプライバシーポリシーは、アプリケーション・アカウントの管理・アクセスの制御・操作のログは当社、基盤のインフラと物理的な設備はクラウドの事業者、と共有責任モデルを書いています。
  • 顧客にも義務を負わせる。音声応答のクラウドの規約の修正版では、セキュリティの確保の条を新設し、提供者の措置は「講じるよう努める」にとどめつつ、利用者にもサプライチェーンに起因するリスクの認識、アクセスの権限の管理、通信の暗号化などを義務付けました。提供者が合理的なインシデントへの対応をとった場合は、その措置によって利用者に生じた損害についても責任を負わない、という項も置いています。
  • 見られない設計を前提にする。個人向けの管理クラウドでは、運営者も復号できない暗号化(パスフレーズとリカバリーコードの両方を失えば誰も復元できない)を、責任の分かれ目と開示の請求への対応の前提として規約に書きました(データの返還・削除のページ)。

ヒヤリングの問いと理由アカウントとセキュリティの条を作る前に

  1. 利用者に派遣労働者や業務委託先の個人は入りますか。

    入るなら利用者の定義に含め、その行為も顧客の責任と書きます。

  2. 顧客の側に管理者を置きますか。

    置くなら、管理者の権限(登録・削除・権限の設定)と、メンバーとの関係を定義します。

  3. 退職者のアカウントを止める仕組みはありますか。外部の認証を使いますか。

    止める義務を顧客に置き、外部の認証の障害の扱いを決めます。

  4. 競合他社の申込みや、性能の比較の公表を制限したいですか。

    承諾拒否の事由、禁止事項、利用停止の事由のどこに置くかを決め、包括条項に頼らず具体的に書きます。

  5. 提供者と顧客の管理の領域は、どこで分かれますか。

    共同責任モデルの表にして、契約書か別紙に置きます。

起きがちなこと

アカウントとセキュリティで起きがちなこと

  • ユーザー数を無制限にしながら、アカウントの管理と利用者の行為の責任を顧客に置いていない。
  • 退職者のアカウントを誰が止めるのか決まっておらず、退職後のアクセスで事故が起きる。
  • 招待したメンバーまで「利用者」に含め、支払義務や禁止事項の主語が曖昧になる。
  • 「アカウントの操作は利用者のもの」とみなす条項が、提供者側の原因による乗っ取りにまで及ぶ。
  • 禁止事項に「当社が不適切と判断する行為」だけを置き、競合の調査や性能の比較の公表を具体的に書いていない。
  • セキュリティの措置を「完全に防止する」と読める書き方にし、顧客の管理の領域との分担を書いていない。

よくあるご質問

退職した社員のアカウントは、誰が止める義務を負いますか?

契約で決めておかないと曖昧になります。法人向けのSaaSでは、顧客がアカウントを管理し、退職などで権限を失った利用者のアカウントを速やかに削除又は無効化する義務を負うと定めるのが一般的です。削除漏れによる損害を提供者が負わないと明記する例もあります。

同じ会社の社員どうしで、1つのアカウントを共有することを禁止できますか?

契約で禁止できます。利用者1人ごとの課金なら、同一法人内の者を含めて共有を禁止すると書きます。あわせて、登録を削除すればその枠を他の人に割り当てられることを書き、共用の禁止と、退職者の入替えの自由を区別しておきます。

「IDとパスワードでの操作は利用者が行ったものとみなす」と書いてよいですか?

書いてよいですが、提供者の責めに帰すべき事由で認証情報が第三者に使われた場合は除いておくべきです。提供者のシステムの脆弱性による乗っ取りまで顧客の操作とみなす条項は、不当な条項と評価されるおそれがあります。

競合他社が調査目的で申し込んでくるのを、規約で防げますか?

完全には防げませんが、競合の調査・分析・模倣の目的のおそれを承諾拒否の事由にし、画面や操作方法の無断公開、画面構成や機能仕様を使った同種サービスの開発を禁止し、即時の利用停止・解除の事由にする、といった手当てができます。性能の比較の結果の無断公表の禁止も有効です。

セキュリティ事故の責任分担は、契約書にどう書けばよいですか?

顧客の管理の領域(接続する資料、外部の権限設定、利用者の登録と削除、端末とネットワーク)と、提供者の管理の領域(保存データの保護、アクセスの制御、脆弱性への対応、監視、事故への対応)を表にして示す方法があります。分担が明確だと、事故のときの責任の判断や損害の分担にも影響します。

あわせて読みたい、関連する別のガイド

あわせて読みたいページ

本ページは一般的な情報提供です。個別の取引への当てはめは、サービスの仕組みや契約の経緯によって異なることがあります。事務所の改訂例・ご相談の事例として紹介している内容は、アトラス行政書士法人が作成・レビューしてきた法人向けのSaaS・クラウドサービスの利用規約、サービス提供契約書、申込書、実証実験(PoC)の覚書、販売代理店契約書、レビュー報告書、ヒヤリングシートなどを、個別の事業者が特定できない形に整理したものです。条文は e-Gov法令検索(法令API)で確認しています(最終確認日:2026年10月16日)。参考: e-Gov法令検索 / 個人情報保護委員会 / 経済産業省 / 国税庁

SaaS・クラウドサービスの利用規約・契約書でお困りの方は、お気軽にご相談ください。

公式LINEで無料相談する
アトラス行政書士法人 公式LINEの友だち追加QRコード
  1. 公式LINEを友だち追加
  2. 「SaaS・クラウドサービスの契約書ガイドを見た」とメッセージを送信
  3. ご相談内容を確認し、LINEでご返信します(24時間・土日祝対応)

相談無料です。料金が発生するのは、お申込みいただいた書類の作成・点検だけです。

LINEで友だち追加して無料相談する

ご依頼・納品の流れを見る