SaaS契約書のひな型設計
権利帰属・責任分界・損害賠償の交渉ポイント
SaaS契約は、運用の実務と法的リスクが一体で回る契約です。特に「誰が何をどこまで負担するか」を設計段階で明確にしておくと、障害対応、知的財産、データ取扱いの局面で交渉がぶれにくくなります。
設計の全体像
-
(1) 権利帰属利用者の入力・成果物・カスタマイズの帰属を分解して定義する。
-
(2) 責任分界SLA、障害、第三者クレーム、監査協力などの責任範囲を責任主体別に整理する。
-
(3) 損害賠償直接損害・間接損害、上限、特定損害の扱いを実務に即して調整する。
1. 権利帰属：ひな型で必ず分解する項目
権利帰属の交渉は、契約条項を「全部まとめて譲渡」型にしないことが第一です。入力データ、成果物、設定・ワークフロー、アドオン、カスタマイズ、そして派生物を、用途と主体に応じて切り分けます。
利用者の権利を維持したうえで、サービス提供・改善に必要な範囲でSaaS提供者が使用できる旨（目的限定）を記載します。目的の外に拡張される条項は、利用者側のデータガバナンスと衝突しやすいです。
出力の定義（誰の判断で成果物と呼ぶか）を明確化します。さらに、出力が第三者の権利に触れる場合の扱い、再利用可否、エクスポート手段（期限・形式）もセットで見ます。
ノーコードの設定やワークフローも、契約上は「カスタマイズ」に含めるかを確認します。含めるなら、ライセンス（利用許諾）範囲、移行時の引き継ぎ、解除後の取扱いまで設計します。
2. 責任分界：SLA・障害・第三者クレームの設計
責任分界は「起きた事象ごとに、責任主体を固定する」ことが狙いです。例外を拡大しすぎると、SLA違反が起きても回収不能になりがちです。
「稼働率の計算式」「計測タイミング」「メンテナンスの扱い」「通知要件」を明確にします。運用で検証できないSLAは、交渉上の武器になりにくいです。
影響範囲の評価、通知、再発防止、ログ提供（合理的範囲）の順番を決めます。通知期限は「いつまでに何を」まで具体化するのが交渉の中心です。
誰が防御し、どこまで負担し、和解条件にどんな制限を置くかを固定します。特に、利用者側のデータや指示に起因する場合の切り分けは、議論が長期化しやすいポイントです。
3. 損害賠償：上限・間接損害・特定損害の交渉
損害賠償は「理論」ではなく「想定シナリオで回るか」で設計します。たとえば障害時に発生しうる費用、データ復旧費、運用停止による損失を、契約上どのカテゴリに入るのか確認します。
年間利用料、直近6か月分、直近1か月分などの方式があります。高頻度障害やデータ喪失が起きた場合に、キャップが実損に対して小さすぎないかを検証します。
「逸失利益」「事業機会損失」だけでなく、合理的な範囲の復旧費が排除されないよう調整します。条文の文言が抽象的だと、賠償の成立が争点化します。
個人情報や第三者クレームに関する損害が「すべて除外」だと、利用者側のリスク吸収が過大になります。免責や例外の優先順位も含めて整合させます。
実務の進め方：交渉設計を条文に落とす
ひな型を作る段階で、まずは自社の想定運用を3パターンに絞ります。通常運用、重大障害、第三者クレームの三つです。次に、各パターンで「誰が」「何を」「いつまでに」対応するかを洗い出し、そのまま条文の見出しに反映させます。
「責任分界」と「損害賠償のカテゴリ分け」は、セットで整合させるのが最短ルートです。先にキャップだけ調整しても、実際の損害が別条項に吸い込まれてしまうことがあります。