基本サービス契約(MSA)とは?

マスターサービス契約(MSA)とは、通常はベンダーと顧客という二者間の継続的な取引関係に適用される基本条件を定める法的契約です。支払条件、責任、守秘義務、データの取り扱い、解約権などを定めるため、将来の業務は、毎回契約全体を交渉し直すのではなく、作業指示書(SOW)のような簡易な文書で追加できます。SaaSの購入者にとってMSAは、個別の注文書や更新よりも上位に位置する契約であり、ベンダーとの関係が続く間、価格改定、紛争、データの取り扱いがどう処理されるかを左右します。

マスターサービス契約には通常何が含まれますか?

MSAは、案件ごとに交渉し直すことになりがちな事項、つまり誰が何を所有するのか、誰が何に責任を負うのか、関係が悪い形で終わった場合にどうなるのかに答えるために作られています。業界を問わず、ほとんどのMSAは共通する一連の条項を含んでいます。

• サービスの範囲:ベンダーが提供する内容の概要。プロジェクト固有の詳細は、別のSOWを参照する形が一般的です
• 支払条件:請求頻度、請求書発行の手順、支払遅延のペナルティ、価格改定の仕組み
• 守秘義務:取引期間中に共有された情報を、各当事者がどのように保護するか
• 知的財産:成果物、既存の知的財産、取引の過程で生成されたデータの帰属先
• 保証と責任制限:各当事者が約束する性能基準と、問題発生時の金銭的負担の上限
• 補償条項:データ、知的財産、コンプライアンス違反を理由に第三者から訴えられた場合に、どちらの当事者が損失を負担するか
• データセキュリティ:保管方法、情報漏えい時の通知要件、SOC 2やGDPRなどのコンプライアンス上の義務
• 解約:契約を終了できる理由、必要な通知期間、終了後のデータとサービスの扱い

よく練られたMSAは、締結後に頻繁な変更を必要としません。更新は修正契約や追補で対応し、中核となる条件は関係が続く間、固定されます。

MSAと作業指示書(SOW)はどう違いますか?

MSAは取引のルールを定めます。SOWはそのルールを特定のプロジェクト、成果物、またはサブスクリプション期間に適用し、その業務の価格、範囲、スケジュールを定めます。

1つのMSAで、ベンダーとの関係が続く間に数十件のSOWを支えることができます。これこそがこの構造の狙いです。法務、セキュリティ、調達の各部門が重要な条件を一度だけ交渉し、その後の購入や更新では、その上に重ねる軽く迅速な文書だけで済みます。両者に矛盾がある場合、多くのMSAでは、その特定の取引についてはSOWが優先し、それ以外はマスター契約に従うと定められています。

SaaSの購入者にとって、この違いは更新時に重要になります。ベンダーは毎年新しい注文書を発行することが多いものの、当初のMSAにある責任上限、データ条件、解約権は、誰かが積極的に再交渉しない限り、通常はそのまま関係を規律し続けます。

企業が実際にMSAを必要とするのはどのような場合ですか?

すべての購入にMSAが必要なわけではありません。クリックスルー形式の規約による低価格のソフトウェアサブスクリプション1件に、正式なMSAを整える法務上の手間をかける意味は、ほとんどありません。MSAが価値を発揮するのは、継続的な取引、相応の支出、または機密データの共有が伴う関係です。

MSAを検討するきっかけとして、よくあるものは次のとおりです。

1. 複数年または複数プロジェクトにわたるベンダーとの関係:毎年更新される見込みのエンタープライズ向けSaaSプラットフォームなど
2. カスタム導入やプロフェッショナルサービス:プロジェクトごとに範囲や成果物が変わる場合
3. データの取り扱いに配慮が必要な取引:ベンダーが顧客、従業員、財務に関するデータを処理する場合
4. 契約金額が大きい場合:責任リスクが大きく、詳細な法的保護が妥当な場合

MSAがいったん整えば、新しいSOWの交渉のたびに白紙から始めるのではなく、調達部門と法務部門が更新の協議の前に必ず参照する基準点になります。

SaaSの購入者にとって、MSAはなぜ重要ですか?

SaaSツールのポートフォリオを管理する財務、調達、IT部門にとって、本当の財務上および運用上のリスクがあるのは請求書ではなくMSAです。MSAに埋もれた自動更新条項、解約通知期限、責任上限によって、優先事項が変わったときやベンダーの成果が不十分なときに、企業が実際にどれだけ柔軟に動けるかが決まります。

現実的な課題は、ほとんどの企業が追跡すべきMSAを1つではなく何十も抱えていることです。ベンダーごとに通知期間、更新条件、データに関する義務が異なります。こうした条件の把握が不十分になると、望まない更新に縛られたり、誰も合意した覚えのない責任リスクを抱えたりすることになります。

ここでSeedlingの出番です。Seedlingを使ってSaaSスタックを管理しているチームは、MSAに埋もれた解約期限、更新日、主要条件を含むベンダー契約を一元的に確認できます。そのため調達部門と財務部門は、通知期限が過ぎてから気づくのではなく、期限前に対応できます。

MSAの交渉で最も多い論点は何ですか?

MSAの中には、他の条項よりもはるかに頻繁に交渉される条項があります。どこに注力すべきかを知っておけば、双方の時間の節約になります。

解約と通知期間が筆頭です。ベンダーは顧客が契約を終了するまでの通知期間を長くしたがり、購入者は短くしたがります。適切なバランスは、他の部分での価格面の譲歩と引き換えに、購入者がどれだけの運用リスクを受け入れるかによって決まります。

自動更新条項も、よく争点になります。気づかれないまま自動更新されると、不要になったツールの契約に縛られかねないため、多くの購入者はこの条項を完全に削除するか、明示的な更新手続きを必要とする形に置き換えようとします。

責任上限と補償は、機密データが関わる取引では厳しく精査されます。購入者は、上限を過去12か月に支払った料金のような意味のある基準に連動させたいと考え、重大な過失やデータ侵害については例外を設けたいと考えます。重大な障害が起きた後に、ベンダーが低い責任上限を盾にできないようにするためです。

データに関する権利は、年々重要性を増しています。特に、ベンダーが顧客データを基にAI機能を構築するケースが増えているためです。購入者は、広範で曖昧な文言を受け入れるのではなく、ベンダーによるデータの利用、共有、モデルの学習への使用について、明確な制限を交渉するケースが増えています。

これらの条項は、定型文としてそのまま受け入れる必要はありません。ほとんどのベンダーはある程度の修正を想定しており、譲れない条件の明確なリストを持って交渉に臨む企業は、署名後も長く自社を守る契約を得られる傾向があります。

MSAを一度きりの法務上の手続きと見なすのはよくある間違いです。署名時に交渉した条件は、その後のあらゆる更新、あらゆるSOW、あらゆる紛争を規律し続けます。MSAは企業のベンダースタックの中でも特に影響の大きい文書の1つであり、各更新期限のかなり前に見直す価値があります。