店舗向け予約・会員管理SaaSの利用規約：三つの規約と二層の決済

結論：規約は三つに分け、決済は二層で考え、プライバシーポリシーの名義は店舗にする

店舗が自分のお客様（会員）の予約や会費を管理するために使うSaaSは、契約の当事者が三組できます。提供者と店舗の利用契約、店舗と会員の会員契約、そして店舗を介さずにアプリを使う個人（単独利用者）と提供者の利用契約です。法人向けのSaaSの規約を一本作って終わり、という整理がきかない理由は、会員という個人の消費者が加わることにあります。

最初に決めておくことは三つあります。どの規約を誰の名義で出すか。お金が誰から誰へ流れ、決済が止まったり取り消されたりしたときの損失を誰が負うか。会員の個人情報について、個人情報取扱事業者としての義務を誰が負うか。この三つが決まっていないと、規約の条文を整えても、店舗・会員・提供者の三者が互いに責任を押し付け合う構造が残ります。

• 店舗用・会員用・単独利用者用の三つの規約に分ける。会員用は店舗の名義で、提供者はひな形と表示の仕組みを提供する側に回る。
• 提供者が受け取るのは店舗からの利用料と手数料に絞り、会員が店舗に支払う会費や予約代金を提供者がいったん預かる設計は、資金決済法の確認が済むまで避ける。
• 決済事業者の審査・停止・チャージバック（カード利用者が支払に異議を述べ、売上が取り消されること）による損失は、店舗への求償と決済機能の停止の権限を規約に書いて割り振る。
• プライバシーポリシーは、会員の情報を取得する店舗の名義で公開させる。提供者はひな形を出し、採用の確認と更新の通知までを仕組みにする。
• 会員の持病や服薬などは要配慮個人情報にあたり得る。「入力したら同意したとみなす」では足りないので、明示の同意の画面か、入力させない設計を選ぶ。

このページは、店舗が契約者になり、その会員が個人であるSaaSに絞って説明します。法人向けのSaaSに個人事業主が混じる場合の整理は契約の組み立て、提供者が会員の情報を預かる立場の一般論は委託先と個人情報のページで扱っています。

規約を三つに分ける：誰が誰と契約し、誰の名義で出すか

予約・会員管理のSaaSでは、画面を操作する人は三種類います。店舗の経営者やスタッフ、店舗の会員、そして店舗に属さずにアプリを使う個人です。この三者それぞれに、提供者が当事者になる契約と、提供者が当事者にならない契約が混ざります。

表の中でいちばん誤りやすいのは、会員向けの規約です。会員が店舗に払う会費や予約代金、キャンセルの扱いは、店舗と会員の契約の内容です。提供者の名義で「会員規約」を出して会費やキャンセルを書いてしまうと、提供者が会員に対する契約上の責任を負うように読まれます。会員用の規約は、提供者がひな形を提供しても、店舗が自らの名義で採用して会員に示す形にします。

民法の定型約款の規定では、不特定多数を相手に画一的な取引を行うときの規約を準備した者を「定型約款準備者」と呼びます（民法548条の2第1項）。会員規約を会員に示して契約する店舗は、この準備者にあたります。会員が個人で、店舗が事業者であれば、消費者契約法も働きます。事業者の債務不履行による損害賠償責任を全部免除する条項は無効とされ（消費者契約法8条1項1号）、キャンセル料などの違約金は、同種の契約の解除に伴い事業者に生ずべき平均的な損害の額を超える部分が無効とされます（同法9条1項1号）。ひな形に免責やキャンセル料の条項を広く入れておくと、店舗がそのまま採用した条項が無効と判断される危険が、店舗と会員の間に生じます。

会員用の規約とアプリの利用規約が食い違わないようにするため、次のように役割を分けておく方法があります。会費・予約・キャンセル・施設の利用条件は会員規約が決め、アプリの動作・禁止事項・提供者の責任はアプリの利用規約が決める、と各規約の冒頭に書きます。店舗向けの規約にも、会員に表示する規約の組み合わせを機能の仕様として書き、店舗が独自の規約を追加するときの手順を決めます。

店舗が契約を終えるとき、会員の契約はどうなるか

店舗が利用契約を解約したり、提供者が店舗の利用を止めたりすると、店舗に紐づいていた会員の予約や前払いの会費、会員のアカウントが宙に浮きます。規約には、少なくとも次の事項を書いておきます。

• 会員への終了の通知は店舗が行う。提供者は、通知を送る機能と協力を提供する。
• 前払いで受け取った会費や回数券の払戻しは、店舗が会員に対して負う債務である。提供者は、店舗の債務を引き受けない。
• 店舗に紐づく会員のデータは、一定の期間内に店舗が取り出せるようにし、その後は削除する（取り出しと削除の書き方は返還・削除のページ）。
• 会員のアカウントを、単独利用者としてアプリに残すのか、削除するのかを決め、会員に選ばせる場合は選択の画面と期限を定める。
• 提供者が決済代金の未払いなどで急に停止するときは、会員の画面に表示する文言を決めておく。

決済の二層構造：提供者が受け取るお金と、会員が店舗に払うお金

予約・会員管理のSaaSの決済は、二つの層に分かれます。上の層は、店舗が提供者に払う利用料です。下の層は、会員が店舗に払う会費や予約代金です。二つの層は債権者も債務者も違うので、混ぜて書くと、どちらの返金やどちらの停止の話か分からなくなります。

下の層の資金の流れは、大きく三つの型に分けて考えます。

型Bで確認が必要になる条文は、資金決済法2条の2です。金銭債権を持つ受取人からの委託などを受け、債務者などから弁済として資金を受け入れ、受取人に引き渡すことで資金を移動させる行為のうち、各号のいずれかに当たるものを、為替取引に該当するものとしています。第1号は「受取人が個人（事業として又は事業のために受取人となる場合におけるものを除く。）であることその他の内閣府令で定める要件を満たす行為」、第2号は国内から国外、国外から国内へ資金を移動させる行為です。為替取引を銀行等以外の者が業として営むのが資金移動業です（同法2条2項）。

店舗が事業として代金を受け取る限り、第1号のうち「受取人が個人」の類型には通常あたらないと読めます。ただし、内閣府令で定める要件の中身、海外の会員や海外の店舗が絡む場合（第2号）、決済事業者の側の登録の有無など、条文の組合せで結論が決まります。型Bを採るときは、条文と内閣府令、金融庁の公表資料で確認が必要であり、確認ができていない段階で「代金を預かって精算する」という文言を規約に置くことは避けます。

会員が個人で、店舗が事業者として代金を受け取る取引は、店舗から見て通信販売にあたることがあります（特定商取引法2条2項）。通信販売では、広告に価格・支払の時期と方法・提供時期・申込みの撤回や解除に関する事項などを表示し（同法11条）、申込みの画面にも、商品・役務の分量と、11条1号から5号までの事項を表示します（同法12条の6第1項）。会員の申込みが営業のために行うものであれば適用除外がありますが（同法26条1項1号）、個人の会員の通常の申込みは、これに当たらないのが普通です。

そこで、提供者は、店舗が自分の特定商取引法に基づく表記を登録する機能と、決済の前に会員の画面にそのリンクや事項を表示する機能を設計します。規約には、表示の内容は店舗が自己の責任で登録すること、未登録の店舗は決済機能を使えないこと、を書きます。リンクを表示するだけで足りる事項と、最終確認画面に直接表示すべき事項は分かれるので、画面の構成は個別に確認します。税込か税別かは、会費の表示で必ず明記します。

決済事業者の審査・停止・チャージバックによる損失を、誰が負うか

決済機能を提供すると、決済事業者の審査、停止、売上の取消し、残高のマイナスといった事態が、提供者・店舗・会員の三者に波及します。決済事業者の提供条件では、導入の形態によって、売上の帰属や、返金・チャージバックによる残高のマイナスを誰が引き受けるかが変わるものがあります。規約を書く前に、自分の導入がどの形態で、マイナスの責任が決済事業者と提供者のどちらに帰属するのかを確認します。提供者が責任を負う構成であれば、店舗の返金やチャージバックが、そのまま提供者の損失になり得ます。

規約で見落とされやすいのは、返金と会員との紛争対応は店舗の責任と書きながら、提供者が損失を負ったときに店舗へ負担を移す定めを置かない書き方です。定めがないと、損害賠償や不当利得（民法703条）で回収しようとしても、根拠として弱くなりやすくなります。前払いの会費や回数券を扱う店舗ほど、この点は重要です。

決済機能の停止や遅延について提供者の責任を「負いません」と書き切る場合も、責任制限の条項の全体と合わせて設計します（責任制限のページ）。決済が止まって店舗の売上が止まる損害は、店舗の逸失利益の請求につながりやすい場面だからです。

店舗名義のプライバシーポリシーを、提供者がひな形で用意する方式

会員の情報を取得するのは店舗です。会員が予約するとき、店舗は会員の氏名・連絡先・予約の履歴・体験や来店の記録を、自らの事業のために取得します。個人情報保護法の上で、利用目的を特定して本人に通知または公表し（17条1項・21条1項）、安全管理措置を講じ（23条）、委託先を監督する（25条）のは店舗の側です。提供者は、店舗から個人データの取扱いを委託された立場になるのが通常で、委託に伴って個人データが提供されることは、本人の同意が必要な第三者提供にあたりません（27条5項1号）。

そのため、会員の情報に関するプライバシーポリシーは、店舗の名義で公開されるべき文書です。ところが、小さな店舗はそれを自分で書けません。提供者がひな形を用意し、各店舗が自社名義で採用する方式があります。この方式で規約と運用に書いておくことは、採用の確認と更新の責任です。

ひな形方式で、規約に書いておく事項を整理します。

1. 店舗は、ひな形を自己の名義で公開する前に、自店の実際の取扱い（利用目的、第三者への提供、外部への委託、問合せ窓口）と照らして確認し、必要な修正を行う。
2. 店舗は、ポリシーを会員の登録の画面からたどれる場所に公開し、公開した旨を管理画面で確認する。
3. 提供者は、機能の追加や法令の改正でひな形を改めたときは、店舗に通知する。店舗は、合理的な期間内に自店のポリシーへ反映する。
4. 店舗が会員に対して独自の利用目的（たとえば広告メールの配信）を追加するときは、店舗の責任で追記する。ひな形に追記欄を設けておく。
5. 会員からの開示、訂正、利用停止の請求は店舗が受ける。提供者は、請求への対応に必要な範囲で協力する。

更新の責任は、提供者がどこまで負うかを決めます。通知は提供者、反映は店舗、と分けるのが現実的です。法改正のたびにすべての店舗のポリシーを提供者が書き換えることはできませんし、店舗の実際の取扱いを知っているのは店舗だけです。管理画面に「ポリシーの最終更新日」と「ひな形の最新版との差」を表示する機能を付ければ、通知の義務を機能の仕様として果たせます。

提供者自身が、店舗のデータを統計やサービス改善に使うときは、別の論点が生じます。委託を受けたデータを提供者の目的で使えば、委託の範囲を超えるおそれがあります。統計の利用は、集計して個人が識別できない形にする、店舗から許諾を得るといった整理が必要で、書き方は顧客データのページで説明しています。

会員の健康情報は、入力したら同意したとみなす、では足りない

サービスの内容によっては、持病、けが、服薬、妊娠の有無といった情報を予約の際に店舗が確認する場面があります。病歴は「要配慮個人情報」にあたり得ます（個人情報保護法2条3項）。要配慮個人情報は、法令に基づく場合などの例外を除き、あらかじめ本人の同意を得ないで取得してはなりません（同法20条2項）。取得するのは店舗ですが、予約フォームの項目や管理画面の入力欄は、提供者が設計します。

規約の書き方として考えられるのが、「会員が入力した時点で、情報の取扱いに同意したものとみなす」「店舗は、会員の同意を得て入力する」といった書き方です。この書き方には限界があります。

• 店舗のスタッフが会員から聞き取って代わりに入力する場合は、本人の意思表示が画面の上に現れません。
• 利用目的や、情報が誰に見えるかが示されないまま入力させると、同意の中身が薄くなります。
• 同意を撤回する道筋や、入力した情報を削除する手順が示されていません。
• 入力した人が未成年のときは、法定代理人の同意が絡みます（民法5条）。

同意を「みなす」ことで代用するのではなく、設計の段階で、次の三つのどれを選ぶかを決めます。

禁止事項の書き方にも工夫が要ります。「会員に要配慮個人情報の入力を求める行為」だけを禁じていると、会員が自由記入欄に自分で病歴を書き込む場合は、規約の対象外になります。取得の主体が店舗であっても、提供者は委託先として、要配慮個人情報を扱い得る点が安全管理の評価に影響します。自由記入欄への記載を促す表示を禁じ、記載があったときの削除の手順を定めておきます（禁止事項の書き方一般はアカウント管理のページで扱っています）。

取引デジタルプラットフォーム消費者保護法と外部送信規律：画面ごとに考える

予約・会員管理のSaaSには、会員が見る店舗ごとの予約ページ、店舗のスタッフが使う管理画面、提供者が営業のために公開するランディングページ（LP）があります。これらは、利用者も、設置するタグも、適用される規律も違います。まとめて「サイト」と考えず、画面ごとに分けて見ます。

取引デジタルプラットフォーム消費者保護法の「取引デジタルプラットフォーム」は、特定デジタルプラットフォームの透明性及び公正性の向上に関する法律2条1項のデジタルプラットフォームのうち、消費者が申込みの意思表示を行える機能などを持つものをいいます（同法2条1項）。そのデジタルプラットフォームは、多数の者が利用することを予定して構築した場で、商品等を提供しようとする者の情報を表示することを常態とし、提供者と利用者の間で便益が相互に増進していく関係を利用したものです。ここでいう消費者は、事業を行う場合を除く個人です（取引デジタルプラットフォーム消費者保護法2条3項）。

店舗ごとに独立した予約ページを提供する形であれば、この定義の「場」にあたらない可能性が高いと考えられます。他方で、利用者横断の検索や集客の場、おすすめの店舗の一覧があると、評価が変わり得ます。該当するかどうかは、条文と所管官庁の資料で確認が必要です。該当すると考えられる場合には、同法3条が、消費者と販売業者等が円滑に連絡できる措置、表示への苦情に対する措置、販売業者等を特定する情報の提供の求めといった措置を講ずる努力義務を定めています。どちらとも言い切れない段階では、これらの措置を機能と規約に取り込んでおく方法があります。

外部送信規律は、電気通信事業法27条の12に基づく規律です。電気通信事業者または第三号事業を営む者（総務省令で定める電気通信役務を提供する者に限ります）が、利用者の端末に情報送信指令通信を行おうとするときは、送信される情報の内容や送信先などを、あらかじめ利用者に通知し、または容易に知り得る状態に置かなければなりません。ウェブページに埋め込まれた解析や広告のタグが、利用者の端末から外部の事業者へ情報を送る仕組みは、典型的な情報送信指令通信です。サービスの提供に必要な情報や、利用者が同意した情報などは例外とされています。

誰が義務を負うかは、予約ページを誰の電気通信役務として提供しているか、タグを誰が設置するかで変わります。対象となる電気通信役務の範囲は総務省令で定められているので、条文と総務省令、総務省の資料で確認が必要です。規約では、提供者が標準で埋め込むタグの種類を提供者が公表する、店舗が自分でタグを追加できる機能を設けるなら、追加したタグについての通知や公表は店舗の責任とする、と分けておくと、責任の所在が明らかになります。

起きがちなこと：三者の責任を押し付け合う構造が残る

B2B2Cの規約でよく起きるのは、条文の不備というより、役割分担の不備です。誰が当事者かを曖昧にしたまま、機能が増えていきます。

よくあるご質問

あわせて読みたいページ

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