標準化できるリスクを利用規約に集約し、顧客固有・案件固有・規制固有のリスクを個別契約や別紙に切り出すための企業法務実務ガイドです。
標準化できるリスクを 利用規約に集約し、顧客固有・案件固有・規制固有のリスクを個別契約や別紙に切り出すための企業法務実務ガイドです。
この章では、制度や実務上の論点を整理し、契約判断で確認すべき観点を示します。
次の一覧は、BtoB SaaS契約を安定させる四層構造を整理したものです。利用規約と個別契約を対立させず、標準化と例外統制を両立させるために重要であり、各層がどの条件を受け持つかを読み取ってください。
全顧客に適用される基本条項を置く層です。
DPA、SLA、セキュリティ別紙などリスク領域ごとに分ける層です。
料金、契約期間、利用数量、適用文書、顧客固有条件を記録する層です。
大口顧客、規制業種、カスタム開発、特別な責任制限などを調整する層です。
BtoB SaaSの契約実務では、利用規約だけで全顧客を処理すべきか、顧客ごとに個別契約を締結すべきかという問いが繰り返し生じる。しかし、実務上の本質は「利用規約か、個別契約か」という二者択一ではない。重要なのは、標準化できるリスクを利用規約に集約し、顧客固有・案件固有・規制固有のリスクを個別契約または別紙に切り出し、契約文書間の優先順位、変更手続、証跡管理、運用責任を明確にすることである。
この記事は、弁護士、企業内弁護士、外部弁護士、契約法務担当、個人情報保護担当、情報セキュリティ担当、知財法務担当、内部統制担当、内部監査担当、リーガルオペレーション担当、会計・税務・監査に関わる専門職の視点を統合した実務解説として構成する。もっとも、この記事は一般的な情報提供であり、特定の事案についての法律意見ではない。実際の契約設計では、事業内容、顧客属性、取り扱うデータ、業法、海外展開、既存契約、販売チャネル、社内権限規程を踏まえ、個別に検討する必要がある。
結論を先に述べると、BtoB SaaSの契約設計は、次の四層構造で考えるのが実務上もっとも安定する。
この四層のうち、利用規約は「スケールする標準契約」であり、個別契約は「例外を統制するための契約」である。両者を対立概念として扱うのではなく、標準化と例外管理を両立させるための契約アーキテクチャとして設計することが、この記事の中心命題である。
---
この章では、制度や実務上の論点を整理し、契約判断で確認すべき観点を示します。
次の一覧は、BtoB SaaS契約に内在する緊張関係を整理したものです。事業者、顧客、営業、法務、セキュリティ、経営の要請が同時に働くため重要であり、どの部門の事情が契約条件に影響するかを読み取ってください。
多数の顧客に同一サービスを提供するため、契約条件を標準化したい要請があります。
セキュリティ基準、個人情報保護、内部統制、業法、監査対応に合わせたい要請があります。
契約締結を速く進め、商談遅延を避けたい要請があります。
責任制限、DPA、SLA、知財、秘密保持、解除、紛争解決を正確に管理したい要請があります。
BtoB SaaSは、ソフトウェアをインターネット経由で提供する継続的サービスである。従来型の受託開発やオンプレミス型ソフトウェア販売では、契約交渉、仕様確定、納品、検収、保守という流れが比較的明確であった。これに対し、SaaSでは、サービス仕様が継続的に変化し、顧客はWeb上で利用を開始し、データはクラウド環境で処理され、サポート・セキュリティ・可用性・外部サービス連携・再委託が契約関係に組み込まれる。
この構造のため、BtoB SaaSの契約には、少なくとも次の矛盾が内在する。
利用規約だけに依存すると、大口顧客や規制業種の要求を吸収できず、商談が進まない。反対に、すべての顧客と個別契約を交渉すると、契約管理コストが増大し、営業サイクルが長期化し、条項のばらつきが内部統制上のリスクになる。
したがって、BtoB SaaSにおける契約設計の目的は、単に「規約を作ること」でも「契約書を厚くすること」でもない。目的は、標準化できるリスクと個別調整すべきリスクを分離し、サービス運用・営業プロセス・法務審査・監査対応が同じ設計図に基づいて動ける状態を作ることである。
---
この章では、制度や実務上の論点を整理し、契約判断で確認すべき観点を示します。
この記事でいうBtoB SaaSとは、企業、団体、官公庁、専門職事務所その他の事業者向けに、インターネット経由でソフトウェア機能を継続的に提供するサービスをいう。典型例は、CRM、会計、人事労務、契約管理、電子署名、BI、プロジェクト管理、チャット、マーケティングオートメーション、セキュリティ監視、業務特化型クラウドなどである。
BtoB SaaSでは、顧客がサービスを「購入する」というより、一定期間サービスを「利用する」。この点が、所有権移転型の売買契約や、成果物納品型の請負契約とは異なる。
利用規約とは、サービス提供者が、多数の利用者に共通して適用するためにあらかじめ準備する契約条件である。SaaSでは、Webサイト上に掲載され、申込画面、注文書、管理画面、電子契約、見積書、または申込書によって契約に組み込まれることが多い。
利用規約は、単なる「注意書き」ではない。適切に契約へ組み込まれれば、料金、サービス利用条件、禁止事項、知的財産、データの取扱い、秘密保持、責任制限、契約終了時の処理などを定める契約条項となる。
個別契約とは、特定の顧客または特定案件に合わせて締結される契約文書をいう。名称は、基本契約、個別利用契約、サービス利用契約、クラウドサービス契約、マスターサービス契約、注文書、申込書、SOW、覚書、特約、補足契約など様々である。
重要なのは名称ではなく、機能である。個別契約の機能は、利用規約では標準化しきれない条件を、顧客または案件単位で調整することにある。
注文書または申込書は、契約の商業条件を確定する文書である。一般に、契約当事者、サービス名、プラン、数量、契約期間、料金、支払条件、更新条件、適用される利用規約のバージョン、適用別紙、特記事項を記載する。
注文書は一見すると営業文書に見えるが、契約上は非常に重要である。なぜなら、利用規約を契約に組み込む入口であり、個別特約を記録する場所でもあるからである。
SLAとは、Service Level Agreementの略で、サービスの稼働率、応答時間、サポート時間、障害通知、復旧目標、サービスクレジットなどを定める文書である。BtoB SaaSでは、SLAは顧客の業務継続性と密接に関わる。
ただし、SLAに書かれている数値がすべて法的義務になるとは限らない。文書の表現が「努力目標」なのか「契約上の保証」なのか、未達時の救済がサービスクレジットに限定されるのか、損害賠償請求も可能なのかを明確にする必要がある。
DPAとは、Data Processing AgreementまたはData Protection Addendumの略で、個人データその他のデータ処理に関する契約または別紙である。日本法上は、個人情報保護法上の委託先監督、外国にある第三者への提供、再委託、漏えい対応、安全管理措置などと関係する。
BtoB SaaSでは、顧客が個人データをSaaS上に保存し、SaaS事業者がそのデータを保守・運用・サポートのために取り扱うことが多い。そのため、DPAを利用規約に含めるか、別紙として分離するか、顧客ごとに交渉するかが重要な設計課題となる。
SOWとは、Statement of Workの略で、個別の作業範囲、成果物、スケジュール、検収、費用、責任分担を定める文書である。SaaS本体の利用とは別に、初期設定、データ移行、システム連携、カスタム開発、教育、コンサルティングを提供する場合に用いられる。
SaaSの利用規約でカスタム開発や個別導入支援まで処理しようとすると、請負・準委任・著作権帰属・検収・瑕疵対応・変更管理が曖昧になる。SOWは、SaaS本体とプロフェッショナルサービスを切り分けるための実務的な道具である。
定型約款とは、日本の民法において、一定の要件を満たす定型的な契約条項をいう。Webサイトの利用規約が定型約款に該当するか、またどのように契約に組み込まれるかは、BtoB SaaSの利用規約設計において重要である。民法は、定型約款の合意、内容の表示、変更について規定している。電子商取引に関する公的ガイドラインでも、Webサイトの利用規約と定型約款の関係が検討対象とされている。
定型約款に該当する可能性がある場合、事業者は「規約を掲載しておけば足りる」と考えるべきではない。契約締結時の表示、同意取得、変更通知、不合理条項の排除、個別合意との優先関係を意識する必要がある。
---
この章では、制度や実務上の論点を整理し、契約判断で確認すべき観点を示します。
BtoB SaaSの利用規約が契約として機能するためには、顧客との間で契約内容として組み込まれている必要がある。実務上は、申込画面でのチェックボックス、注文書への参照、電子契約上の添付、見積書・申込書での明示、管理画面上の同意、更新時の通知などが用いられる。
ここで避けるべきなのは、「Webサイトのどこかに掲載されている規約だから当然に適用される」という設計である。特にBtoB取引では、購買部門、事業部門、システム部門、法務部門、利用部門が分かれていることが多く、誰がどの時点で何に同意したかが後から問題になる。
したがって、利用規約を契約に組み込むには、少なくとも次の点を設計すべきである。
BtoB SaaSの利用規約は、一定の場合、民法上の定型約款に該当し得る。定型約款に該当する場合、民法上の組入れ、表示、変更のルールを意識する必要がある。経済産業省の「電子商取引及び情報財取引等に関する準則」でも、Webサイトの利用規約の定型約款該当性、契約への組入れ、契約締結後の規約変更が論点として整理されている。
ここで重要なのは、BtoB取引であっても、著しく不合理な条項を標準規約に入れれば常に安全というわけではない点である。例えば、事業者側の重過失まで広く免責する条項、顧客の重要な権利を一方的に奪う条項、サービス内容を無制限に変更できる条項、顧客データを広範に利用できる条項などは、契約解釈、信義則、定型約款の不当条項規制、説明義務、業法、個人情報保護法、取引上の公正さの観点から問題になり得る。
一方で、個別契約を締結すればすべて解決するわけでもない。個別契約が増えすぎると、次の問題が生じる。
そのため、個別契約は「顧客の要望を何でも受ける文書」ではなく、「例外を正式に承認し、記録し、運用可能にする文書」でなければならない。
---
この章では、制度や実務上の論点を整理し、契約判断で確認すべき観点を示します。
BtoB SaaSの利用規約と個別契約を使い分ける設計では、次の原則が有効である。
多数の顧客に共通し、プロダクト仕様・標準運用・一般的なリスク配分に関わる事項は、利用規約に置くのが適切である。具体的には、アカウント管理、禁止行為、料金支払の基本、知的財産権、顧客データの基本取扱い、秘密保持、標準責任制限、契約期間、解約、サービス変更、通知、準拠法・管轄などである。
利用規約に置くべき条項は、サービス運用の標準仕様と一致していなければならない。実際には実施できないセキュリティ義務、サポート体制、データ削除期限、監査対応を利用規約に書くと、契約違反リスクだけでなく、不当表示、顧客対応、内部統制上の問題にもなる。
顧客の規模、業種、データの重要度、利用部門、海外展開、内部統制、監査要件により変わる事項は、個別契約または別紙に置くべきである。具体的には、特別なSLA、特別な責任制限、監査権、サブプロセッサ承認、データ所在地、業法対応、公共調達条項、親会社・子会社利用、特別な解約権、カスタム開発、専用環境、移行支援、特別なサポート時間などである。
すべてを一つの利用規約に詰め込むと、規約が長大化し、改定のたびに影響範囲が広がる。そこで、BtoB SaaSでは、次のようにリスク領域ごとに文書を分けることが望ましい。
次の比較表は、4. 基本思想 ― 契約を「標準化」と「例外統制」に分けるで扱う項目を列ごとに整理したものです。実務上の判断を誤らないために重要であり、左の項目と右側の説明を対応させて、どの条件やリスクを確認すべきかを読み取ってください。
| 文書 | 主な役割 | 典型的な管理主体 |
|---|---|---|
| 利用規約 | 全体の基本契約条件 | 法務・事業責任者 |
| 注文書・申込書 | 商業条件と適用文書の特定 | 営業・法務・経理 |
| DPA | 個人データ・委託・再委託・漏えい対応 | プライバシー・法務・セキュリティ |
| SLA | 稼働率、サポート、サービスクレジット | SRE・CS・法務 |
| セキュリティ別紙 | 技術的・組織的安全管理措置 | 情シス・セキュリティ・法務 |
| AUP | 禁止行為、不正利用、利用停止 | プロダクト・セキュリティ・法務 |
| SOW | 導入支援、移行、開発、検収 | PM・開発・法務 |
| 特約・覚書 | 顧客固有の例外 | 法務・営業責任者 |
この分離により、標準規約を頻繁に変更せずに、SLAやセキュリティ情報だけを更新できる。また、DPAやSOWなど専門性の高い領域を、担当部門が責任を持って維持できる。
契約条項は、事業者が実際に提供・運用・検証できる内容でなければならない。例えば、次のような約束は、法務だけで判断してはならない。
これらは、プロダクト、SRE、セキュリティ、CS、経理、営業、プライバシー、知財の実務体制に直結する。契約設計は、法務文書の作成ではなく、組織として履行可能な約束の棚卸しである。
---
この章では、制度や実務上の論点を整理し、契約判断で確認すべき観点を示します。
利用規約には、サービスの概要、利用資格、アカウント発行、管理者権限、ユーザー追加、認証情報管理、API利用、外部連携、利用環境、ベータ機能、仕様変更を定める。
特にBtoB SaaSでは、顧客企業の従業員、役員、業務委託先、子会社、関連会社が利用することがある。誰が「ユーザー」に含まれるか、顧客がどの利用者の行為について責任を負うかを明確にする必要がある。
利用規約には、料金支払、請求、遅延損害金、税金、返金不可、契約期間、自動更新、解約期限、利用数量超過、プラン変更の基本ルールを置く。
ただし、具体的な料金、割引、支払サイト、請求先、PO番号、複数年度契約、最低利用料などは、注文書で定めるのが通常である。利用規約には基本ルールを、注文書には個別条件を置くという分担が望ましい。
SaaS事業者は、サービスの安定運用、セキュリティ、他顧客保護のため、禁止行為を定める必要がある。典型例は、不正アクセス、リバースエンジニアリング、過度な負荷、スパム、違法コンテンツ、第三者権利侵害、認証情報の共有、脆弱性探索の無断実施、制裁対象者による利用などである。
利用停止条項では、停止事由、通知の要否、緊急停止、停止中の料金、データ保全、解除との関係を定める。特に、セキュリティインシデントが疑われる場合には、事前通知なしに一時停止できる条項が必要になることがある。ただし、顧客の業務停止リスクにも配慮し、停止権限は合理的に限定すべきである。
利用規約には、SaaS本体、ソフトウェア、画面、ドキュメント、商標、API、テンプレート、ノウハウに関する知的財産権が事業者またはライセンサーに帰属すること、顧客には契約期間中の利用権のみが付与されることを定める。
顧客がサービス上に入力するデータやコンテンツについては、顧客に権利が残ることを明確にしつつ、事業者がサービス提供、保守、セキュリティ、サポート、改善、統計分析のために必要な範囲で利用できる旨を定める。ただし、個人データ、秘密情報、営業秘密、医療情報、金融情報を含む場合には、DPAや個別契約で詳細化する必要がある。
BtoB SaaSの利用規約には、相互の秘密保持義務を定めることが多い。秘密情報の定義、除外情報、利用目的、開示先、保護措置、法令・裁判所・当局命令による開示、存続期間を定める。
ただし、顧客が自社NDAの締結を求める場合や、商談段階で機密情報を交換する場合は、利用規約とは別にNDAを締結することがある。NDA、利用規約、DPAの秘密保持条項が重複する場合は、優先順位と適用範囲を明確にする。
利用規約には、事業者の損害賠償責任の範囲と上限を定めることが多い。BtoB SaaSでは、典型的に「直近一定期間の利用料金」または「当該注文書に基づき支払済みの金額」を上限とする。
ただし、責任制限は、顧客データ漏えい、秘密保持違反、知財侵害、故意・重過失、支払義務、補償義務、法令違反などについて、例外を設けるかが交渉ポイントになる。利用規約では標準上限を定め、個別契約では例外と上限額を調整するのが実務的である。
利用規約には、契約終了後のアカウント停止、データエクスポート期間、データ削除、バックアップ、未払金、存続条項を定める。
顧客にとって、終了時のデータ取得は非常に重要である。特に、基幹業務、契約管理、労務、会計、医療、金融、自治体、教育などのSaaSでは、契約終了時のデータ移行が事業継続に直結する。標準的なエクスポート方法、期間、追加費用、削除証明の可否を明確にすることが望ましい。
---
この章では、制度や実務上の論点を整理し、契約判断で確認すべき観点を示します。
契約金額が大きい場合、利用規約だけでは責任制限、SLA、監査権、サポート、更新、解約、セキュリティ、データ処理の調整が不足することが多い。大口顧客は、調達規程、情報セキュリティ基準、個人情報保護規程、内部監査、会計監査、取締役会承認などの制約を受けるためである。
この場合、個別契約では次の事項を定める。
金融、医療、製薬、通信、電力、教育、自治体、官公庁、重要インフラ、上場企業グループなどでは、法令・監督指針・業界ガイドライン・内部規程により、SaaS利用時の契約条件が厳格化されることがある。
この場合、利用規約の標準条項だけでは、顧客の監査証跡、再委託管理、インシデント通知、データ所在地、業務継続、可用性、復旧目標、権限管理、ログ保存、削除証明、委託先監督に対応できないことがある。個別契約またはセキュリティ別紙で、顧客の規制要件と事業者の実運用をすり合わせる必要がある。
個人データを取り扱う場合、顧客は委託先を監督する立場になり得る。個人情報保護法上、個人データの取扱いを委託する場合には、委託先に対する必要かつ適切な監督が求められる。実務上は、契約に安全管理措置、再委託、監査、報告、漏えい対応、削除・返却、外国での取扱いなどを定める必要がある。
特に、人事労務、医療、金融、教育、本人確認、採用、マーケティング、カスタマーサポート、行動ログ分析などのSaaSでは、DPAを利用規約の一部として標準化しつつ、大口顧客や規制業種では個別DPAを締結する設計が有効である。
SaaS本体とは別に、初期導入、設定代行、データ移行、API連携、帳票カスタマイズ、専用機能開発を行う場合、個別契約またはSOWが必要になる。
ここでは、作業範囲、前提条件、顧客の協力義務、成果物、検収、変更管理、遅延、追加費用、知財帰属、再利用権、保守範囲、瑕疵対応を定める。SaaS利用規約だけで処理すると、「サービス利用料」と「開発委託料」、「利用権」と「成果物権利」、「標準サポート」と「個別保守」が混同される。
大企業や公共部門は、自社の標準契約書、購買条件、反社条項、輸出管理条項、贈収賄防止条項、人権・サステナビリティ条項、監査条項、情報セキュリティ条項、請求書要件、電子帳簿保存対応、下請・取引適正化対応を求めることがある。
事業者は、すべてを受け入れるのではなく、自社の標準ポジション、受入可能なフォールバック、経営承認が必要な条項を定めるべきである。特に、無制限責任、広範な補償義務、片務的な解除権、無償の長期サポート、過大な監査権、最恵待遇、競業避止、広範な知財譲渡は慎重に扱う必要がある。
---
この章では、制度や実務上の論点を整理し、契約判断で確認すべき観点を示します。
次の判断の流れは、案件を標準処理にするか個別契約へ送るかを確認する順番です。金額だけで判断しないために重要であり、データ、規制、運用、例外の有無を上から下へ確認してください。
標準機能、標準料金、標準DPA・SLAで足りるかを確認します。
個人データ、秘密情報、営業秘密、規制データの有無を確認します。
高可用性、監査、サポート、データ移行、インシデント通知を確認します。
責任上限、無制限責任、国内保存、AI学習不使用、専用環境などを確認します。
標準なら利用規約と注文書、例外があれば個別契約や別紙で統制します。
利用規約と個別契約の使い分けは、契約金額だけで判断してはならない。小規模契約でも、機微な個人データや規制対象データを扱う場合は個別検討が必要である。逆に、大口契約でも、標準仕様の範囲で利用し、標準DPA・SLAで足りる場合は、注文書と利用規約で処理できることがある。
判断軸は、次の六つで整理できる。
次の比較表は、7. 判断基準 ― どの案件を利用規約で処理し、どの案件を個別契約に送るかで扱う項目を列ごとに整理したものです。実務上の判断を誤らないために重要であり、左の項目と右側の説明を対応させて、どの条件やリスクを確認すべきかを読み取ってください。
| 案件類型 | 推奨契約構成 | 理由 |
|---|---|---|
| 小規模・標準利用・低リスクデータ | 利用規約 + 注文書 | 交渉コストを抑え、標準条件で処理できる |
| 個人データを扱う標準案件 | 利用規約 + 注文書 + 標準DPA | 委託先監督・安全管理措置を明確化する |
| 高可用性が必要な業務利用 | 利用規約 + 注文書 + SLA | 稼働率、障害時対応、救済を明確化する |
| 規制業種・公共部門 | 個別契約 + DPA + SLA + セキュリティ別紙 | 監査・再委託・業法・内部統制への対応が必要 |
| カスタム開発・導入支援あり | 利用規約 + SOW + 必要に応じ個別契約 | SaaS利用と作業委託を分離する |
| 海外顧客・海外データ処理 | 個別契約 + DPA + 越境移転条項 | 準拠法、管轄、データ移転、制裁対応が必要 |
| 代理店・リセラー経由販売 | 販売店契約 + エンドユーザー規約 + 注文条件 | 誰が顧客に責任を負うかを明確化する |
| 大口・戦略顧客 | MSA + 注文書 + DPA + SLA + セキュリティ別紙 | 長期運用と例外管理が必要 |
SaaS事業者は、営業担当が判断しやすいように、法務レビューに回す基準を定めるべきである。例えば、次のいずれかに該当する場合は、法務レビュー必須とする。
---
この章では、制度や実務上の論点を整理し、契約判断で確認すべき観点を示します。
BtoB SaaSでは、利用規約、注文書、DPA、SLA、セキュリティ別紙、サポートポリシー、AUP、SOW、顧客ひな形、覚書、メール合意など、複数文書が関係する。これらの優先順位を定めなければ、紛争時にどの条項が適用されるか不明になる。
優先順位条項は、単に「個別契約が利用規約に優先する」と書けば十分ではない。なぜなら、DPAは個人データの領域だけで優先すべきであり、SLAはサービスレベルの領域だけで優先すべきであり、注文書は料金・数量・期間の領域で優先すべきだからである。
実務上は、次のような優先順位モデルが有効である。
このように、単純な縦並びではなく、領域別優先を設計することが重要である。
この例では、文書ごとの優先範囲を限定している。これにより、例えばSLAが料金条項を上書きしたり、セキュリティ別紙が責任制限全体を意図せず変更したりすることを防げる。
SaaS事業者は、利用規約を改定するたびに全顧客へ適用したいと考えがちである。しかし、個別契約で特定条件を合意している場合、後からWeb規約を更新するだけで個別合意を当然に上書きできるとは限らない。
特に、責任制限、データ利用、SLA、解約権、料金、監査権、セキュリティ義務などの重要条項を一方的に変更する場合、顧客の予測可能性や個別合意との関係が問題になる。
そのため、標準利用規約の変更条項では、次のように整理するのが望ましい。
---
この章では、制度や実務上の論点を整理し、契約判断で確認すべき観点を示します。
BtoB SaaSでは、顧客が個人データをサービスに入力し、SaaS事業者が当該データを保守、サポート、障害対応、セキュリティ監視、バックアップのために取り扱うことが多い。この場合、顧客は委託元、SaaS事業者は委託先に近い立場になることがある。
個人情報保護法の実務では、委託先の監督として、契約で安全管理措置、取扱状況の把握、再委託、監査・モニタリングなどを定めることが重要とされる。したがって、個人データを扱うSaaSでは、DPAを利用規約の一部または別紙として整備すべきである。
DPAを別紙化する利点は、次のとおりである。
DPAには、少なくとも次の項目を置くことが望ましい。
次の比較表は、9. DPA・個人情報保護・データ処理の設計で扱う項目を列ごとに整理したものです。実務上の判断を誤らないために重要であり、左の項目と右側の説明を対応させて、どの条件やリスクを確認すべきかを読み取ってください。
| 項目 | 内容 |
|---|---|
| 処理目的 | SaaS提供、保守、サポート、セキュリティ、障害対応など |
| データ種類 | 顧客データ、個人データ、ログ、メタデータ、添付ファイルなど |
| 処理期間 | 契約期間中および終了後の削除・返却期間 |
| 安全管理措置 | アクセス制御、暗号化、ログ管理、脆弱性管理、教育、委託先管理 |
| 再委託 | 再委託先の範囲、通知、変更、異議申立て、監督 |
| 越境移転 | データ処理国、外国制度の把握、顧客への情報提供 |
| 漏えい対応 | 通知期限、協力義務、原因調査、再発防止 |
| 監査・報告 | SOC報告書、ISMS認証、質問票、合理的監査 |
| 削除・返却 | 終了時のデータエクスポート、削除、バックアップ処理 |
| データ主体対応 | 本人請求、苦情、当局対応への協力 |
| 顧客指示 | 顧客の合理的指示に従う範囲と限界 |
SaaS事業者が「当社は個人情報を取得しない」と規約に書いていても、実際には顧客がサービス上に従業員、顧客、取引先、求職者、患者、会員、問い合わせ者の情報を入力することがある。ログ、メールアドレス、IPアドレス、アカウント情報、操作履歴も個人に関する情報になり得る。
契約設計では、事業者が直接取得する情報、顧客が入力する情報、サービスが自動生成するログ、サポート時に閲覧する情報、分析に利用する情報を分けて整理する必要がある。
SaaS事業者は、顧客データをどの範囲で利用するかを明確にしなければならない。典型的には、次のように分類できる。
顧客データをAI学習に用いる場合、利用規約に広く書いておけば足りると考えるのは危険である。顧客の秘密情報、個人データ、営業秘密、知財、規制データが含まれる可能性があるため、オプトイン、オプトアウト、匿名化、分離学習、保持期間、再利用範囲、出力結果の扱いを慎重に設計する必要がある。
日本法上、データそれ自体は有体物ではないため、物権的な所有権の対象として単純に扱うことはできない。実務では、「データの所有権」という表現を安易に使うより、誰がどのデータを、どの目的で、どの期間、どの範囲で利用・開示・複製・削除できるかを契約で定めることが重要である。経済産業省のAI・データ契約ガイドラインも、データ契約を、利用権限や取引コスト低減の観点から整理している。
BtoB SaaSでは、少なくとも次の分類が有効である。
次の比較表は、9. DPA・個人情報保護・データ処理の設計で扱う項目を列ごとに整理したものです。実務上の判断を誤らないために重要であり、左の項目と右側の説明を対応させて、どの条件やリスクを確認すべきかを読み取ってください。
| データ区分 | 契約上の設計ポイント |
|---|---|
| 顧客入力データ | 顧客に権利・管理権を残し、事業者の利用目的を限定する |
| アカウント情報 | 契約管理、認証、請求、サポートのために利用する |
| 操作ログ | セキュリティ、監査、改善、障害解析のための利用を定める |
| 集計・統計データ | 個人・顧客を識別しない範囲での利用可否を定める |
| 派生データ | 分析結果、スコア、レポート、予測値の権利関係を定める |
| AI学習データ | 学習利用の可否、除外、保持、再利用、説明責任を定める |
---
この章では、制度や実務上の論点を整理し、契約判断で確認すべき観点を示します。
SLAは、顧客に安心感を与えるための営業資料ではない。SLAは、サービスレベルを満たせなかった場合に、誰が、何を、どの範囲で負担するかを定める契約上のリスク配分である。経済産業省のSaaS向けSLAガイドラインも、SaaSにおいてサービス内容・範囲・品質に関する共通認識を持つことの重要性を示している。
SLAでは、次の点を明確にする。
特に、「99.9%稼働率」と書く場合、月間か年間か、計測対象はAPIか管理画面か、計測方法は事業者の監視システムか第三者測定か、予定メンテナンスは除外されるかを明確にする必要がある。
セキュリティ別紙は、利用規約より技術的・運用的な安全管理措置を説明する文書である。顧客のセキュリティ審査では、暗号化、アクセス制御、ログ、権限管理、脆弱性診断、ペネトレーションテスト、バックアップ、BCP、インシデント対応、従業員教育、委託先管理、認証取得状況が確認される。
これらをすべて利用規約に入れると改定が困難になるため、セキュリティ別紙、セキュリティホワイトペーパー、トラストセンター、FAQ、監査報告書提供手続として管理するのが実務的である。
ただし、注意すべき点がある。セキュリティ資料に書かれた内容が契約上の義務なのか、参考情報なのか、現時点の運用説明なのかを明確にする必要がある。クラウドサービス契約では、サービス内容が契約として法的拘束力を持つか、努力目標にとどまるかが実務上重要になる。
SaaSでは、事業者だけがすべてのセキュリティ責任を負うわけではない。顧客側にも、ID管理、権限設定、パスワード管理、多要素認証、利用者教育、端末管理、ネットワーク管理、設定ミス防止、データ入力管理の責任がある。クラウド利用に関する公的ガイダンスでも、利用者の選定、利用、設計、運用、インシデント時の関係者連携が重視されている。
利用規約やセキュリティ別紙では、事業者の責任範囲と顧客の責任範囲を明確にする必要がある。例えば、顧客管理者が過大な権限を付与したことによる情報漏えい、顧客端末のマルウェア感染、顧客がAPIキーを公開したことによる不正利用まで、事業者が全面的に責任を負う設計は通常適切ではない。
BtoB SaaSでは、セキュリティインシデント発生時の通知条項が重要である。通知条項では、次の事項を定める。
過度に短い通知期限を約束すると、初動対応が混乱することがある。他方、通知期限が曖昧すぎると、顧客の法令上・社内規程上の報告義務に支障が出る。標準DPAでは合理的な通知基準を置き、大口顧客や規制業種では個別調整するのが望ましい。
---
この章では、制度や実務上の論点を整理し、契約判断で確認すべき観点を示します。
SaaSは、多数の顧客に標準サービスを継続提供するモデルである。低額または中額の月額利用料で、顧客の間接損害、逸失利益、事業停止損害、第三者請求、データ損失について無制限責任を負うことは、事業継続上困難である。
そのため、責任制限条項はSaaS利用規約の中核である。責任上限を設定し、間接損害・特別損害・逸失利益を除外し、SLA未達時の救済をサービスクレジットに限定する設計は一般的である。
しかし、責任制限を広くしすぎると、顧客にとって受け入れられず、また条項の合理性が問題になることがある。重要なのは、価格、保険、サービス特性、データリスク、顧客の依存度に応じて、標準上限と例外を設計することである。
個別契約で交渉になりやすい例外は、次のとおりである。
SaaS事業者は、各例外を無制限責任にするのか、別枠上限を設けるのか、通常上限内に含めるのかを決めるべきである。例えば、標準責任上限を「直近12か月分の利用料」とし、個人データ漏えいについては「直近24か月分または一定金額のいずれか高い額」、知財補償は「一定金額上限」、故意・重過失は「法令上制限できない範囲を除き上限適用」など、段階的に設計することがある。
補償条項は、第三者からの請求に対して、一方当事者が他方当事者を防御し、損害を補填する条項である。BtoB SaaSでは、典型的に、事業者がSaaS本体の知財侵害について補償し、顧客が顧客データ、顧客の利用方法、顧客による法令違反について補償する構造が用いられる。
知財補償では、次の点を定める。
SaaS利用規約では、サービスが「現状有姿」で提供されること、特定目的適合性、完全性、無停止性、エラー不存在を保証しないことを定めることが多い。ただし、BtoB SaaSで「一切保証しない」とだけ書くと、顧客から受け入れられないことがある。
実務的には、標準保証として「当社は、契約期間中、サービスを実質的にドキュメントに従って提供するよう商業的に合理的な努力を行う」とし、SLAで稼働率とサービスクレジットを定める方法が考えられる。
---
この章では、制度や実務上の論点を整理し、契約判断で確認すべき観点を示します。
SaaSは、継続的に機能改善、UI変更、API変更、セキュリティ更新、外部連携追加、料金プラン変更を行う。そのため、利用規約にはサービス変更条項と規約変更条項が必要である。
ただし、サービス変更条項が広すぎると、顧客にとって契約内容が不安定になる。特に、顧客の業務フローに深く組み込まれた機能の廃止、API仕様の大幅変更、データ保存仕様の変更、SLA低下、サポート終了は、顧客への影響が大きい。
規約変更とサービス変更は、次のように分類して手続を分けるのが望ましい。
次の比較表は、12. 規約変更・サービス変更・バージョン管理で扱う項目を列ごとに整理したものです。実務上の判断を誤らないために重要であり、左の項目と右側の説明を対応させて、どの条件やリスクを確認すべきかを読み取ってください。
| 変更類型 | 例 | 推奨手続 |
|---|---|---|
| 軽微な変更 | 誤記修正、表現整理 | 掲載更新 |
| 顧客に有利な変更 | 機能追加、セキュリティ強化 | 通知または掲載 |
| 法令対応 | 法改正、当局指針対応 | 事前通知または速やかな通知 |
| セキュリティ上必要な変更 | 脆弱性対応、危険機能停止 | 緊急変更後通知も可 |
| 顧客に重大な不利益がある変更 | 主要機能廃止、料金体系変更 | 事前通知、猶予期間、解約権 |
| 個別契約に影響する変更 | 特約済みSLA低下等 | 個別変更合意 |
利用規約は、改定日、バージョン番号、変更履歴を管理すべきである。顧客との注文書には、適用される規約のURLとバージョン、または「申込時点で有効な規約」と「その後有効に変更された規約」の関係を明記する。
契約管理システムには、顧客ごとの適用規約バージョン、個別特約、DPAの種類、SLAの種類、責任上限、サポートレベルを登録する。これがないと、規約改定時、更新時、インシデント時、M&A時、監査時に、どの顧客にどの条件が適用されるか把握できない。
---
この章では、制度や実務上の論点を整理し、契約判断で確認すべき観点を示します。
BtoB SaaS契約は、多くの場合、SaaS事業者が顧客に標準サービスを提供する利用契約である。しかし、案件によっては、顧客からSaaS事業者へ特定作業を委託する構造、またはSaaS事業者から外部ベンダーへ開発・運用・サポート・データ処理を委託する構造が含まれる。
この場合、単なる利用規約の問題ではなく、委託取引の公正性、支払条件、仕様変更、成果物、検収、やり直し、買いたたき、支払遅延、発注者・受注者間の力関係が問題になることがある。日本では、従来の下請法が、2026年1月から中小受託取引適正化法、いわゆる取適法へ移行している。SaaSそのものの利用契約に直ちに適用されるとは限らないが、カスタム開発、運用委託、保守委託、コンテンツ制作、データ処理、外部業務委託を含む場合には、取引類型と当事者規模を確認すべきである。
SaaS事業者が顧客から受託作業を受ける場合も、SaaS事業者が外部委託先を使う場合も、利用規約とは別に、発注書、SOW、業務委託契約、検収条件、支払条件、再委託条項を整備する必要がある。
---
この章では、制度や実務上の論点を整理し、契約判断で確認すべき観点を示します。
生成AI、機械学習、予測分析、推薦、要約、分類、チャットボット、文書レビュー、需要予測などのAI機能を含むSaaSでは、利用規約と個別契約の境界がさらに重要になる。経済産業省は、AI事業者向けのガイドラインを公表・更新しており、AI機能を組み込むSaaSでは、契約条項だけでなく、AIガバナンス、説明、リスク管理、利用者への情報提供も実務上の論点になる。
AI機能では、少なくとも次の論点を検討する。
標準利用規約にはAI機能の基本条件を置き、顧客データの学習利用、規制業種での利用、重要判断への利用、第三者AI基盤への送信については、DPAまたは個別契約で詳細化するのが望ましい。
---
この章では、制度や実務上の論点を整理し、契約判断で確認すべき観点を示します。
BtoB SaaSでは、直販だけでなく、代理店、販売店、SIer、クラウドマーケットプレイス、OEM、ホワイトラベル、紹介パートナーを通じて販売されることがある。この場合、利用規約と個別契約の使い分けはさらに複雑になる。
リセラー販売では、顧客との契約当事者がSaaS事業者なのか、リセラーなのかを明確にする必要がある。料金請求、サポート、返金、契約解除、DPA、インシデント通知、責任制限、準拠法・管轄について、誰が責任を負うかが問題になる。
リセラーが顧客と契約する場合でも、SaaS事業者のエンドユーザー規約を顧客に適用する必要があることが多い。注文書、販売店契約、申込手順で、顧客がエンドユーザー規約に同意する仕組みを作る必要がある。
代理店やSIerが、SaaS事業者の標準仕様を超えるSLA、セキュリティ、機能、カスタマイズ、返金保証を顧客に約束すると、後に紛争になる。販売店契約では、パートナーがSaaS事業者を代理して契約変更できないこと、標準資料以外の表明保証をしないこと、顧客への説明責任、秘密保持、個人情報、反社、贈収賄防止、輸出管理を定めるべきである。
---
この章では、制度や実務上の論点を整理し、契約判断で確認すべき観点を示します。
次の時系列は、契約運用を標準化、承認、記録、更新、監査の順で整理したものです。個別契約を締結した後に現場が義務を知らない状態を防ぐために重要であり、契約締結前後で何を整えるかを読み取ってください。
利用規約、注文書、DPA、SLA、SOW、セキュリティ資料をセットで管理します。
責任上限、特別SLA、オンサイト監査、国内保存、AI学習不使用などの承認者を決めます。
標準条項、受入可能な修正、原則不可の修正、交渉時説明文を整理します。
顧客ごとの規約バージョン、DPA、SLA、責任上限、通知期限、監査権を登録します。
古い特約、個別SLA、質問票回答、データ処理条件を抽出できる状態にします。
BtoB SaaSの契約設計は、利用規約や個別契約を作成して終わるものではない。むしろ重要なのは、営業、CS、プロダクト、セキュリティ、経理、法務が同じ基準で契約を運用できる状態を作ることである。
必要な運用要素は次のとおりである。
例外条項を誰が承認するかを事前に定める。例えば、次のようなマトリクスが考えられる。
次の比較表は、16. 契約運用 ― リーガルオペレーションとして設計するで扱う項目を列ごとに整理したものです。実務上の判断を誤らないために重要であり、左の項目と右側の説明を対応させて、どの条件やリスクを確認すべきかを読み取ってください。
| 例外内容 | 承認者 |
|---|---|
| 標準責任上限の2倍まで | 法務責任者 |
| 標準責任上限を大幅超過 | 法務責任者 + 事業責任者 + CFO |
| 無制限責任 | 原則不可。例外は経営会議承認 |
| 個人データ漏えいの別枠上限 | 法務 + セキュリティ + プライバシー責任者 |
| 特別SLA | SRE責任者 + CS責任者 + 法務 |
| オンサイト監査 | セキュリティ責任者 + 法務 |
| データ国内保存 | インフラ責任者 + 法務 |
| AI学習不使用特約 | プロダクト責任者 + 法務 + プライバシー |
| カスタム開発 | 開発責任者 + PM + 法務 + 経理 |
契約プレイブックには、条項ごとに次の情報を整理する。
プレイブックがないと、同じ条項について担当者ごとに回答が異なり、顧客間の不公平、内部統制不備、交渉長期化が起きる。
個別契約を締結した場合、その内容を契約書フォルダに保存するだけでは不十分である。特約台帳に、少なくとも次の項目を登録する。
特約台帳は、CS、セキュリティ、SRE、経理、営業、法務が必要に応じて参照できる形で管理する。ただし、秘密情報や個人情報へのアクセス権限には注意する。
---
この章では、制度や実務上の論点を整理し、契約判断で確認すべき観点を示します。
BtoB SaaSを導入する顧客側は、すべてのSaaS契約を同じ深さでレビューする必要はない。リスクに応じてレビュー範囲を変えるべきである。
導入前に、次の質問に答える。
顧客側は、次の条項を重点的に確認する。
小規模SaaSでは、すべてを交渉するより、DPA、SLA、データ削除、責任上限、セキュリティ資料の確認に集中する方が実務的な場合が多い。
顧客側が自社の汎用業務委託契約書をそのままSaaS事業者に提示すると、交渉が長期化することがある。汎用業務委託契約は、成果物納品、検収、再委託禁止、所有権移転、瑕疵担保、詳細な作業指揮命令を前提にしていることがあり、標準SaaSには適合しない場合がある。
顧客側は、SaaSの標準性を理解したうえで、自社にとって本当に重要なリスクに絞って交渉する方が、結果的に安全で速い契約締結につながる。
---
この章では、制度や実務上の論点を整理し、契約判断で確認すべき観点を示します。
中小企業向けのタスク管理SaaSで、月額数千円から数万円、標準機能のみ、顧客データは一般的な業務情報、個人データはアカウント情報程度という場合、利用規約、プライバシーポリシー、注文画面、標準DPAで十分なことが多い。
この場合の重点は、規約の分かりやすさ、同意取得、料金・更新・解約、禁止行為、データ削除、標準責任制限である。個別契約を広く認めると、法務コストがサービス価格に見合わなくなる。
大企業が全社の契約書、取締役会資料、M&A資料、秘密保持契約、個人データを管理するSaaSを導入する場合、標準利用規約だけでは足りない。DPA、SLA、セキュリティ別紙、監査資料、責任制限の特約、データエクスポート、サポート、グループ会社利用を個別契約で調整する必要がある。
この場合、利用規約はサービスの基本条件として残しつつ、MSAまたは個別利用契約で、顧客固有の条件を定めるのが望ましい。
会計SaaSの導入時に、既存システムからのデータ移行、勘定科目設定、承認フロー設定、外部システム連携を行う場合、SaaS利用契約とは別にSOWを作成する。
SOWでは、顧客が提供すべきデータ、作業範囲、前提条件、検収、遅延時の扱い、追加費用、成果物権利、再利用可能なテンプレートを定める。SaaS利用規約には、SaaS本体の利用条件を置く。
営業メールを自動生成するAI SaaSでは、顧客が入力した顧客情報、商談情報、メール履歴、営業秘密がAI処理に使われる可能性がある。この場合、利用規約にはAI機能の一般的制限、出力結果の確認義務、禁止用途を定める。DPAには個人データ処理と第三者AI基盤への送信を定める。個別契約では、学習利用の可否、データ分離、保持期間、監査資料、責任制限を調整する。
SaaS事業者がSIerを通じて販売する場合、SIerが顧客に独自の導入支援を提供し、SaaS事業者は標準サービスを提供するという分担がある。この場合、販売店契約、エンドユーザー規約、SOW、サポート分担表が必要である。顧客が誰に問い合わせるか、誰が一次サポートをするか、誰がデータ処理者になるかを明確にする。
---
この章では、制度や実務上の論点を整理し、契約判断で確認すべき観点を示します。
小規模から中規模の標準案件では、次の構成が考えられる。
大口または規制業種では、次の構成が考えられる。
---
この章では、制度や実務上の論点を整理し、契約判断で確認すべき観点を示します。
次の一覧は、BtoB SaaS契約で起きやすい失敗を整理したものです。契約締結時だけでなく、更新、監査、インシデント、M&A時にも条件を説明できる状態にするために重要であり、各項目から事前に整備すべき管理手続を読み取ってください。
DPA、SLA、セキュリティ詳細、SOW、代理店条項を詰め込むと読みにくく改定しにくくなります。
責任制限やSLAを大幅変更したのに現場へ共有しないと、履行できない義務を負います。
利用規約、注文書、DPA、SLA、顧客ひな形が矛盾すると、紛争時の解釈が不安定になります。
個別回答が契約上の表明保証として扱われることがあります。
成果物、検収、知財、納期、変更管理が曖昧になります。
利用規約にDPA、SLA、セキュリティ詳細、SOW、カスタム開発、代理店条項、海外条項をすべて入れると、読みにくく、改定しにくく、顧客にとっても審査しにくい。重要領域は別紙化すべきである。
大口顧客との交渉で、責任制限、SLA、監査、データ利用、解除、サポートを大幅に変更したにもかかわらず、社内に共有されないことがある。結果として、現場が履行できない義務を負う。個別契約は、契約管理と運用引継ぎを前提に締結すべきである。
利用規約、注文書、DPA、SLA、顧客ひな形が矛盾しているのに、優先順位がないと、紛争時に解釈が不安定になる。優先順位条項は、契約構成の中核である。
営業担当やCS担当が、顧客のセキュリティ質問票に個別回答し、その回答が契約上の表明保証として扱われることがある。質問票回答は、標準回答データベース、承認フロー、更新管理が必要である。
個別契約で合意した条件を、Web規約の改定で一方的に変更しようとすると、顧客との紛争になる。個別特約は、原則として個別の変更手続に従う。
「当社は顧客データを自由に利用できる」といった条項は、顧客の秘密情報、個人データ、営業秘密、知財の観点から受け入れられにくい。利用目的は、サービス提供に必要な範囲、改善、統計、AI学習などに分けて明確化すべきである。
SaaS利用契約の中にカスタム開発を含めると、成果物、検収、知財、納期、変更管理が曖昧になる。SOWで分離すべきである。
---
この章では、制度や実務上の論点を整理し、契約判断で確認すべき観点を示します。
---
この章では、制度や実務上の論点を整理し、契約判断で確認すべき観点を示します。
次の重要ポイントは、このページの結論を整理したものです。利用規約の整備だけでは大口顧客の信頼を得られず、個別契約の乱発だけではSaaSとしての拡張性を失うため重要であり、標準化と例外統制の両立を読み取ってください。
利用規約は標準的なリスク配分を実装する道具であり、個別契約は標準規約では吸収できない顧客固有のリスクを正式に承認し、記録し、運用可能にする道具です。
BtoB SaaSの利用規約と個別契約を使い分ける設計において、もっとも重要なのは、契約文書を事業運営の一部として捉えることである。利用規約は、SaaS事業の標準的なリスク配分を実装する道具である。個別契約は、標準規約では吸収できない顧客固有のリスクを正式に承認し、記録し、運用可能にする道具である。
よい契約設計は、法務部門だけで完結しない。プロダクト、セキュリティ、SRE、CS、営業、経理、内部監査、プライバシー、知財、経営が、同じ契約アーキテクチャを理解している必要がある。
利用規約を整備するだけでは、エンタープライズ顧客の信頼は得られない。個別契約を乱発するだけでは、SaaSとしてのスケーラビリティは失われる。両者を統合する設計こそが、BtoB SaaSの契約実務の核心である。
最終的に目指すべき状態は、次の三つである。
BtoB SaaSの契約は、単なる法的防御ではない。顧客にサービスを安心して使ってもらうための信頼設計であり、プロダクト、セキュリティ、データガバナンス、営業効率、企業価値を支える基盤である。
---
一般的な制度説明と実務上の注意点として整理します。
一般的には、小規模で標準的な利用であれば、利用規約、注文書、標準DPA、標準SLAで処理できる場合があります。ただし、顧客属性、データの種類、規制業種、監査要件、責任制限、カスタム開発の有無によって結論は変わります。具体的な契約構成は、資料を整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、個別契約が多いほど安全になるとは限らないとされています。顧客ごとの特約が増えすぎると、現場が履行できない義務を負ったり、更新時や監査時に条件を把握できなくなったりする可能性があります。具体的には、承認マトリクスと特約台帳を整備したうえで専門部署や弁護士等に相談する必要があります。
一般的には、SLAの数値がすべて同じ法的効果を持つとは限らないとされています。努力目標なのか契約上の保証なのか、未達時の救済がサービスクレジットに限定されるのか、解除権や損害賠償との関係があるのかで意味が変わります。具体的な条項設計は、サービス運用実態を確認したうえで弁護士等の専門家へ相談する必要があります。
本文の前提として参照した公的資料・国際的枠組み・実務資料の名称です。