複数のサービス・プランの利用規約をまとめる方法

最初に結論：一本にまとめられるが、「共通の幹」「形態別の枝」「下位書類の優先順位」を先に決める

サービスを育てていくと、最初に作った規約に当てはまらない利用の形が増えます。アプリで始めたサービスに、後から運営者が代わりに作業する代行の窓口を足した。無料で始めたサービスに有料プランを足した。個人向けに作ったサービスを、法人にも売ることになった。そうした場面で、「規約は形態ごとに分けるのか、一本にするのか」「ガイドラインとの関係はどうするのか」という相談が出ます。

このページでは、複数の形態を持つサービスの運営者が、規約をどう設計し、どう移行するかを説明します。1つのサービスの規約の基本的な作り方はアプリの利用規約の作り方、同意の取り方の基礎は利用規約の同意の取り方と、定型約款のルール、規約の変更の手続は利用規約の変更で扱っているので、ここでは「複数の形態をまとめる」場面に絞ります。

まとめるか、分けるか：判断の軸と、起きやすい五つの食い違い

規約を一本にするか分けるかは、サービスの数ではなく、約束の共通部分の大きさで決まります。次の表のように、軸ごとに見ていきます。

一本にまとめるとき、特に食い違いが出やすいのは、次の五つです。

共通の幹と形態別の枝：規約の組み立て方

一本にまとめた規約の読みやすさは、章立てで決まります。全員に当てはまる条項を前半と後半に置き、形態に固有の条項を中ほどにまとめ、冒頭に「どの条項が誰に適用されるか」を示す条を置く構成が使えます。

条件付きの条項の書き方には、型があります。条件は、条項の最初に一言で付けると、読む人にも、後から条項を足す運営者にも分かりやすくなります。

定義語の置き方にも注意が必要です。複数の形態を一本にまとめた規約では、「本サービス」を、全形態の総称として定義するのか、特定の形態だけを指すのかが曖昧になりがちです。「本サービス」は総称とし、形態ごとには「セルフ型サービス」「代行型サービス」のように別の定義語を付けます。規約の途中で、「本サービス」が、ある条では総称、別の条では一つの形態を指す、という使い方をすると、条文の解釈が分かれます。初めて使う箇所で、その場で定義する書き方が基本です。

無料プラン、ベータ期間、有料プランが混在するサービスでも、同じ問題が起きます。「有料プランが終了したら無料プランになり、データは削除されない」という条と、「契約が終了したら30日以内にデータを削除する」という条が、同じ規約にあると、「契約の終了」がいつを指すのかが定まらず、二つの条が衝突します。「本サービスの契約」「有料プラン」「無料プラン」を定義し、どの時点でどのデータがどうなるかを一覧にして確かめます。

同意の取り方を、利用者の入口ごとに用意する

規約は、利用者が契約の内容にすることに合意するか、運営者があらかじめ契約の内容とする旨を表示してはじめて、個々の条項まで契約の内容になります（民法548条の2第1項）。一本の規約でも、利用者がサービスに入る入口は複数あり、入口ごとに、表示の場所と記録の方法を用意します。

入口ごとの同意の仕組みを作るとき、規約の正本の掲載場所を一か所に決めておきます。サイト上の一つのURLを正本とし、アプリの登録画面、申込みフォーム、請求書、見積書のいずれからも同じURLを指すようにします。更新が必要になったときに、その一か所を直せば、全ての入口に反映されます。入口ごとに規約のPDFを添付していると、更新のたびに古い版が残り、利用者によって適用される版が違ってしまいます。

同意の記録は、紛争になったときに、運営者が自分を守るための材料になります。ただし、記録を取ることと、同意の取り方が適切であることは別です。同意のチェックボックスが初期状態で選択済みになっている画面や、規約へのリンクが小さな文字で隠れている画面は、同意の記録が残っていても、契約の内容になったと言いにくくなります。同意を取る画面の設計を、規約の作成と一体で確認します。

責任の上限と料金の周期：形態ごとに基準を決め、全体の考え方は揃える

課金の形が分かれると、運営者が負う責任の上限をどう書くかも問題になります。上限を設けること自体は可能ですが、消費者契約法の規律があります。運営者が債務を履行しなかったときの賠償責任をすべてなくす条項は、無効になります（8条1項）。運営者に故意または重大な過失がある場合の責任を一部だけ免除する条項も無効です（同項2号）。さらに、軽過失の場合の責任の一部を免除する条項は、軽過失（重大な過失を除く過失）にだけ適用されることを条項の中で明らかにしていないと無効です（8条3項）。上限条項の中に「当社、その代表者又は使用する者の故意又は重大な過失による場合を除き」と書くのは、このためです。生命・身体の損害は、上限の対象から除きます。

上限の考え方を形態ごとに別々にしてしまうと、規約全体で責任の天井がばらばらになります。形態が違っても、「上限は課金サイクルに結び付ける」「下限の一定額を置く」「故意・重過失と生命・身体は上限の対象外」という三つの原則を揃えておけば、読む人にも筋が通って見えます。免責を場面ごとに散らして書くのではなく、サービスの変更、停止、外部サービスの障害による損害は、全て「責任の条の定めるところによる」と、一か所の条に接続する書き方にします。

課金の形が違うサービスをまとめたときは、返金の考え方も形態ごとに書き分けます。デジタルなサービスだからという理由だけで「返金しない」と書くと、運営者の債務不履行による解除と返金まで排除する趣旨に読めます。形態ごとの返金の定めは、アプリの特定商取引法に基づく表記と、課金・サブスクの規約の考え方に沿って整理します。

ガイドライン・ヘルプ・内部の運用基準との優先関係

規約本体のほかに、サービスには下位の書類が増えていきます。コミュニティガイドライン、ヘルプページ、料金表、プラン別の説明、運営者内部のアカウント停止の基準などです。これらと規約の関係を決めておかないと、利用者との間で、どれに従うのかが争いになります。

下位書類に優先関係を持たせるときは、一つ注意があります。規約に「個別規定は、本規約と矛盾するときは、個別規定が優先する」と書き、さらに「運営者は個別規定を新設または変更できる」と書くと、運営者が下位書類を変えるだけで、実質的に規約を変えられることになります。規約の変更には、民法548条の4の要件と周知の手続が必要ですが（効力が生じる時期を定めて周知すること、合理性を理由とする変更は、その時期の前に周知しておかなければ効力を生じないこと）、下位書類の変更は、その手続を迂回してしまいます。

下位書類との優先関係のほかに、個別契約との関係も決めておきます。規約が定型約款として全員に共通の条件を定める一方、高額なプランや法人との取引では、個別に契約書や申込書を交わすことがあります。この場合は、個別契約に定めがある事項は個別契約が優先し、定めがない事項は規約による、と書くのが通常です。外部のサービス（クラウドソーシングなど）を通じて申し込まれる取引では、そのサービスの規約と、運営者の規約のどちらを優先するかも、冒頭の条で決めます。

新しい形態を足すとき、旧い規約から置き換えるとき

サービスに新しい提供形態を足すときは、既存の規約の幹には触れず、枝を一本足すことを基本にします。たとえば、iOSで始めたアプリにAndroid版を足す場合、購入したストアによって、サブスクリプションの解約の場所と期限が違います。この違いは、「購入ストア」を定義し、解約その他の管理は購入ストアでのみ行えることを枝として書きます。画面の文言も、購入ストアに応じて解約先を切り替えます。幹にあたる禁止事項や責任の条は、そのままで済みます。

古い規約を新しい一本の規約に置き換えるときの手順は、既存の利用者がいるかどうかで変わります。既存の利用者がいない段階の改訂は、規約の変更の手続が要りません。両ストアで同じ日に公開し、書面も同じ日に掲載する場合に、規約に同意して登録済みの利用者がまだいなければ、事前に周知する必要はありません。ただし、ウェブ版やテスト版の登録者がいないかどうかの確認は必要です。既存の利用者がいる場合は、民法548条の4に従い、変更の効力が生じる時期をあらかじめ決め、その時期と、変更すること、変更後の内容を、ウェブ上の掲載などの適切な方法で知らせます。利用者に不利益な変更では、効力発生時期までに周知が済んでいることが効力の条件です（同条3項）。変更の手続の詳細は利用規約の変更：同意なく変更できる条件と周知の方法に書いています。

起きがちなこと

よくあるご質問

あわせて読みたいページ

本ページは一般的な情報提供です。個別のサービスに必要な対応は、提供する機能、取得するデータ、料金の受け取り方、利用者の範囲によって異なります。事務所の書類での扱いとして紹介している内容は、アトラス行政書士法人が作成・レビューしてきたアプリ・Webサービス・プラットフォーム・ホームページの利用規約、プライバシーポリシー、特定商取引法に基づく表記、業務委託契約書などを、個別の事業者が特定できない形に整理したものです。条文・ガイドラインは e-Gov法令検索と各官公庁の公表資料で確認しています（最終確認日：2026年10月18日）。参考: e-Gov法令検索 / 個人情報保護委員会 / 総務省 / 消費者庁 / 金融庁 / 観光庁