EU SaaS向けサービス利用規約

このスキルの役割

製品フロー、商用モデル、規制上の制約を、ヨーロッパのSaaSに対する明確で実行可能な、買い手向けサービス利用規約に変換します。

このスキルは、利用規約をプライバシー通知およびDPAとは別の商用契約として扱い、1つの統制原則を適用します。それは、製品が実際に行うこと、実際に提供する対象者、およびEUの消費者法および契約法が実際に実行可能にするものに対してドラフトを作成するということです。米国スタイルの定型文言と一方的な裁量は、導入すべきものではなく削除すべき既定値です。

このスキルは以下の場合に使用してください。

• 新しいSaaS向けサブスクリプション利用規約またはマーケットプレイス利用規約をEU関連製品向けにドラフトする。
• 既存の利用規約を公平性、実行可能性、運用上の整合性についてレビューする。
• 変更条項、停止、終了、責任、請求、データ出口に関する条項を強化する。
• 必要に応じてDSA、DORA、AI Act、または業界固有のオーバーレイを適用する。
• 文書を折りたたまずに利用規約をプライバシーポリシーおよびDPAと整合させる。

このスキルはEU SaaS契約の起草用です。プライバシー通知のドラフト(プライバシーポリシースキルを使用)、Cookieバナーのメカニクス(Cookieポリシースキルを使用)、または最終的な法的助言には適していません。

使用のタイミング

• リクエストがSaaS利用規約、サブスクリプション利用規約、または利用可能性ポリシーのドラフト、レビュー、または更新に関する場合。
• 製品がEUユーザーまたはB2B顧客、あるいはその両方に提供される場合、およびサービス利用規約がEU消費者法および契約法の下で保持する必要がある場合。
• 既存の利用規約に米国スタイルの越権行為(広範な仲裁、一方的な変更、包括的な免責)が含まれており、EUへの適応性レビューが必要な場合。
• セクターオーバーレイ(DSA、DORA、AI Act、規制対象業界)を契約言語に反映する必要がある場合。
• 利用規約、プライバシーポリシー、DPAが文書全体で整合する必要がある場合。

このスキルを以下には使用しないでください。

• プライバシー通知または透明性開示 — プライバシーポリシースキルを使用してください。
• CookieバナーおよびePrivacyメカニクス — Cookieポリシースキルを使用してください。
• 最終的な法的助言または法律顧問としての活動。

収集する入力情報

ドラフト作成またはレビューの前に、欠けている情報について質問します。

• goal — draft、review、debug、またはupdate。
• commercial_model — B2B、B2C、両方、セルフサービス、エンタープライズのみ、マーケットプレイス形式、ユーザーコンテンツホスティング。
• product_behavior — 請求モデル、無料ティア、トライアル、更新メカニクス、停止トリガー、データエクスポートオプション。
• regulatory_overlays — DSA、DORA、AI Act、金融サービスルール、業界固有の追加要件。
• audience_and_jurisdiction — 主なEU市場、準拠法の選好、言語要件。
• documents_in_scope — 利用規約のみ、利用規約とAUP、利用規約とDPA参照、利用規約とSLA。
• existing_terms — レビューまたは更新時の現在のテキスト。

リクエストがレビューまたは更新の場合は、実際の現在の利用規約の提供を求めてください。新規で両方の対象者が存在する場合は、ドラフト作成前にB2BとB2Cの利用規約を分離すべきかどうかを尋ねてください。

交渉不可能な制約事項

ユーザーが明確に範囲を狭めない限り、これらを既定値として扱います。

1. 利用規約は商用契約です。プライバシー通知は透明性文書です。DPAはプロセッサ義務をカバーします。これらを混同しないでください。
2. 条項をドラフトする前に対象者を決定します。ヨーロッパにおける混合したB2B/B2C利用規約は、双方の実行可能性を弱めます。
3. 平易で具体的な言語が必要です。曖昧な定型文言、定義されていない除外条項、米国スタイルの越権行為は削除または起草者に対して解釈されます。
4. 一方的権限を制限します。変更、停止、価格変更、終了権には、実際のトリガー、通知、およびユーザー救済が必要です。
5. 責任と救済を実行可能にします。キャップ、除外、保証、補償は、特に重過失、故意の不正行為、および消費者保護に関して、EUの法律が実際に実行可能にするものと一致する必要があります。
6. 運用上の約束は監査可能である必要があります。ビジネスが条項を運用できない場合は、ドラフトしないでください。
7. セクターオーバーレイ(DSA、DORA、AI Act等)は、オプションの追加ではなく、関連する場合に必須入力です。
8. バージョニング、実質的変更の通知、解約メカニクス、文書全体の整合性は、時間をかけて保守可能である必要があります。

手順

ステップを順序どおりに従ってください。対象者分類ステップをスキップしないでください。

ステップ1 — ジョブと対象者を確立する

以下を判断してください。

• タスクがドラフト、レビュー、デバッグ、または更新であるかどうか。
• 製品がB2B、B2C、またはその両方に提供されるかどうか—および文書を分離すべきかどうか。
• 適用される規制上のオーバーレイ(ホスティング/仲介者向けDSA、金融サービス顧客向けDORA、AIシステムプロバイダー向けAI Act、セクター追加事項)。

両方の対象者が範囲内の場合、混合文書よりも、個別のB2BおよびB2Cトラック、または明確に分割されたセクションをデフォルトにします。

ステップ2 — 文書の境界をマップする

何がどこに属するかを決定します。

• 利用規約：商用関係、料金、期間、保証、責任、準拠法。
• プライバシー通知：GDPR下での透明性。
• DPA：第28条に基づくプロセッサ義務。
• 利用可能性ポリシー：行動ルールと実行。
• SLAまたは補則：稼働時間、サポート、および製品固有の約束。

相互参照を調整し、各文書が独自の役割を果たし、必要な場合に他を参照するようにします。

ステップ3 — 最もリスクが高い条項から外に向かってドラフトする

実行可能性またはバイヤーレビューで最も頻繁に失敗する条項から始めます。

• 変更条項。
• 請求、更新、および解約。
• 停止と終了。
• 責任キャップ、除外、および救済。
• データエクスポートと終了後のデータ処理。
• 準拠法と管轄。

これらが堅実になった後にのみ、リスクの低い言語を改善します。

ステップ4 — 一方的権限を強化する

各裁量権について、以下を指定します。

• トリガー(「いつでも」ではなく定義済み)。
• 合理的なリード時間を伴う通知要件。
• ユーザーの救済(キャンセル、払い戻し、移行ウィンドウ)。
• 行使についての紛争がどのように処理されるか。

「いつでも、当社の単独の裁量において」のデフォルトは、真に必要で明確に開示されている場合を除き、拒否します。

ステップ5 — 責任、保証、および救済を実行可能にする

EUの実行可能性制約を適用します。

• 責任を比例的に制限し、重過失、故意の不正行為、および法定保護の除外を行います。
• B2Cの包括的な「現状のまま」免責を避けてください。B2B免責を、関連司法管轄区の最高裁が実際に実行可能にするものと整合させます。
• 保証言語を製品の現実(稼働時間、サポート、セキュリティ約束)に合わせます。

ステップ6 — 請求、更新、および終了を運用化する

実際に実行できる条項を作成します。

• 請求頻度、督促、および払い戻し。
• 加盟国の消費者保護に整合した自動更新メカニクス。
• ユーザーが見つけて使用できるキャンセルパス。
• 終了トリガー、通知期間、および効果。
• データエクスポートウィンドウおよび終了後の保持。

事業が条項を実行できない場合は、事業または条項を変更してください。

ステップ7 — セクターおよび規制上のオーバーレイを適用する

製品が以下の場合。

• ホスティングまたは仲介サービス：DSA通知とアクション、透明性、および信頼できるフラッガー期待を適用します。
• 規制対象の金融顧客によって使用される：事件報告、終了、およびサブコントラクター管理に関するDORA契約期待を適用します。
• AIシステムまたはAIコンポーネントの提供：製品役割(プロバイダー、デプロイヤー、GPAI プロバイダー)に関連するAI Act義務を適用します。
• 業界固有(衛生、金融、公共セクター)：関連する国の固有要件を適用します。

これらを必須コンテンツとして、オプションではなく扱います。

ステップ8 — プライバシーポリシーとDPAに整合させる

以下を確認します。

• プライバシー開示はプライバシー通知に存在し、利用規約にはありません。
• プロセッサ義務はDPAに存在し、利用規約がそれを参照しています。
• サブプロセッサ処理、転送、およびセキュリティ対策は、文書全体で矛盾せずに複製されていません。

ステップ9 — 実行可能性にストレステストを実施する

各条項について、厳格な加盟国裁判所または消費者当局がそれを透明で比例的で、運用上サポートされていると見なすかどうかを尋ねます。答えが不明な場合は、条項を狭めるか、明確な除外を追加します。

ステップ10 — バージョニングと変更ガバナンスを接続する

以下を指定します。

• 効果発生日およびバージョンメタデータ。
• 実質的変更通知メカニクス。
• ユーザーが継続的な変更を受け入れる方法(継続的な使用、アプリ内確認等)適用法と互換性のある。
• 以前のバージョンにアクセスできる場所。

分岐ロジック

• B2C消費者SaaS。 消費者向けデフォルトをデフォルトにします。変更の短い通知、明確な解約、狭い免責、強力な払い戻し/撤回権、消費者保護を尊重する準拠法。
• B2Bエンタープライズ SaaS。 より強い制限と広い免責を許可しますが、重過失および故意の不正行為の除外を保持します。DPAおよびSLAと整合させます。
• B2BとB2C双方が範囲内。 文書を分離するか、明確に分割されたセクションを使用することをお勧めします。1つの混合された利用規約セットで両方の対象者を実行しないでください。
• ホスティングまたは仲介サービス。 DSA整合通知とアクション、違法コンテンツ処理、および透明性コンテンツを追加します。
• 金融サービス顧客。 DORA整合終了、サブコントラクター、および事件報告言語を追加します。顧客側の監査権を予想します。
• AI機能。 AI Act整合役割説明、意図的使用制限、および禁止使用への利用可能性制限を追加します。
• ユーザー生成コンテンツ。 実行メカニクス付きの利用可能性ポリシーを追加します。AUPトリガーでの停止/終了を整合させます。
• 最大主義の米国スタイル利用規約をレビュー。 EUで実行不可能である可能性が最も高い条項でリードし、狭まり、EU適応の置換を提供します。

出力フォーマット

配信可能物をタスクに合わせてください。

draftの場合:

1. 平易な見出しを持つ条項ごとの構造での利用規約。
2. 利用規約対プライバシー通知、DPA、AUP、またはSLAを示すトップの短い条項マップ。
3. バージョニングおよび変更ガバナンス言語。
4. ビジネス動作、請求、ベンダー、および運用実践のための「事実確認が必要」リスト。
5. 管轄権に関連する、またはセクターに関連する問題についての「法的レビューが必要」注記。

reviewまたはdebugの場合:

1. リスクおよび実行可能性の概要(重大度の順)。
2. 商用範囲、公平性/実行可能性、運用上の整合性、および規制上のオーバーレイでグループ化された調査結果。
3. リスクの高い言語への具体的な条項置換またはレッドライン。
4. 「事実確認が必要」および「法的レビューが必要」リスト。

updateの場合:

1. 変更された条項のレッドライン。
2. 新しいバージョンメタデータと短いユーザー向けの変更概要。
3. 変更が実質的である場合の通知メカニクスとユーザーオプション。

品質チェック

以下のすべてが真である場合、作業は準備が整っています。

1. 対象者は明確であり、B2BとB2Cはどちらかを弱める方法で混合されていません。
2. 利用規約、プライバシー通知、およびDPA境界はクリーンです。
3. 変更、停止、および終了権にはトリガー、通知、および救済があります。
4. 責任キャップと除外は比例的で、可能性の高いEUの実行可能性を生き残ります。
5. 請求、更新、解約、およびデータ出口条項は運用上の現実と一致しています。
6. セクターおよび規制上のオーバーレイ(DSA、DORA、AI Act等)は関連する場合に反映されます。
7. 文書全体の相互参照は一貫しています。
8. バージョニングおよび実質的変更通信は運用可能です。

回避するべき失敗モード

• EU利用規約への米国優先デフォルト(強制的仲裁、陪審団放棄、包括的免責、一方的管轄)のインポート。
• プライバシー開示またはプロセッサ義務を利用規約にマージ(明確に必要な調整言語がない限り)。
• トリガーまたは救済なしで一方的な変更、停止、または終了権をドラフト。
• サブプロセッサ、転送、移植性、払い戻し、またはエクスポート権を約束し、それらが運用上実装されていません。
• DSA、DORA、AI Act、またはセクターオーバーレイを無視(それらが適用される場合)。
• 最終的な法的助言の出力または法律顧問として行動することの主張。

デフォルトの姿勢

具体的で、公平で、運用上正直です。ビジネスが実行できる狭い条項は、規制当局が削除する最大主義の条項に勝ります。具体的な条項言語、レッドライン、および抽象的な法的解説に対する問題リストでリードしてください。加盟国法が分岐する場合、より厳密な現実的なEUバーをデフォルトにし、適格法的レビューのための残りをフラグします。