Terms of ServiceとTerms of Useに違いはあるのか？

公開する前に、次のリストを確認しましょう。

1. 製品の種類と読み手に基づいて、主となる名称を1つ選びます。
2. フッター、登録フロー、決済画面、アプリストアの掲載情報、取引関連のメールで、まったく同じ名称を使います。
3. EULAや利用ポリシーも使う場合は、それらの文書がどう関係し、矛盾した場合にどれが優先するかをメインの規約に記載します。
4. 新しいTerms of Serviceのページの隣に、古いTerms of Useのページを公開したままにしないでください。リダイレクトするか、発効日を付けてアーカイブしましょう。
5. 契約当事者を正確な法人名と連絡先で記載していることを確認します。
6. すべてのバージョンに日付を付け、それぞれの写しを保管します。

最後のステップは忘れやすく、後から再構成するのが大変です。2年前の購入について紛争が起きた場合に必要なのは、今公開されているバージョンではなく、その利用者が当時同意したバージョンです。日付入りの写しを保存したシンプルなアーカイブフォルダーと、各アカウントがどのバージョンに同意したかの記録があれば、小規模な事業者には通常それで十分で、何もないよりはるかに優れています。

結論から言えば、一般的な法的意味での違いはありません。契約法が見るのは当事者が何に合意したかであり、ページの見出しではありません。明確な同意の手順と公正な条項を備えたTerms of Useという名称の文書のほうが、誰も読むよう求められたことのないTerms of Serviceのページよりも重みを持ちます。

とはいえ、よく使われる3つの名称は、それぞれ少しずつ異なる重点を示す傾向があります。

• Terms of Service（サービス利用規約）は、SaaS製品、プラットフォーム、オンラインアカウントなど、継続的なサービスを連想させます。
• Terms of Use（利用条件）は、多くの場合支払いを伴わない、Webサイト、アプリ、コンテンツを利用する際のルールを連想させます。
• Terms and Conditions（取引条件・利用規約）は最も広い名称で、ネットショップやイギリス英語でよく使われます。

これらは慣習であってルールではありません。大企業は3つすべてを使っており、ほぼ同じ構成の文書に使い分けていることもあります。サブスクリプションを販売していて、その契約をTerms of Useと呼んでも何も問題はありません。

問題になるのは、異なる名称で矛盾するルールを持つ2つの文書を公開することです。たとえば、Terms of Useのページでは30日以内の返金を約束し、Terms of Serviceのページではあらゆる返金を拒否している場合です。EUと英国の消費者契約では、定型的な条項の曖昧さは消費者に有利に解釈されるため、この混乱は事業者にとって不利になります。

利用者が想定する名称を選び、フッターのリンク、登録時のチェックボックス、決済画面、メール、アプリストアの掲載情報など、あらゆる場所で同じ名称を使いましょう。どれを選ぶかよりも、一貫性のほうが重要です。

製品の種類別の実践的な目安は次のとおりです。

• ネットショップ：Terms and Conditions。購入に関するルールとしてTerms of Sale（販売条件）を併用することもあります。ネットショップ用利用規約作成ツールをご覧ください。
• SaaSやサブスクリプション製品：Terms of Service。大口の法人顧客向けには、注文書や別個の契約を併用することがよくあります。
• コンテンツサイトやブログ：Terms of Use。コンテンツの権利、許容される利用、外部リンクに重点を置きます。
• モバイルアプリやゲーム：Terms of ServiceまたはTerms of Useに、使用許諾の付与を加えます。ここでEULAの問題が出てきます。
• コミュニティやマーケットプレイス：Terms of Service。コミュニティガイドラインや出品者向けの規約を参照によって組み込むことがよくあります。

他の言語にはそれぞれ独自の名称があります。ドイツの事業者はAllgemeine Geschäftsbedingungenを、チェコの事業者はobchodní podmínkyを公開しますが、すべての顧客に提示する定型的な条件という役割は同じです。

迷った場合は、オンライン製品の一般的な名称として最も広く認知されているTerms of Serviceを選びましょう。

EULA（エンドユーザー使用許諾契約）はライセンスです。事業者自身またはそのライセンサーが権利を持つソフトウェアの複製をインストールして使用する許可を利用者に与えるものです。EULAの典型的な条項には次のものがあります。

• 利用者が所有または管理する端末での、個人的で譲渡不可能な使用などのライセンスの範囲
• 複製、改変、再配布、リバースエンジニアリングの制限
• ソフトウェアとそのアップデートの権利の帰属
• ライセンスの終了
• 保証の否認と責任の制限

Terms of Serviceは、アカウント、行為、ユーザーコンテンツ、支払い、モデレーション、サポートなど、継続的なサービスとの関係を規律します。現代の製品の多くはソフトウェアであると同時にサービスでもあるため、規約の中に使用許諾のセクションを設け、別個のEULAは不要になります。

1つ注意点があります。制限の中には、事業者が一方的に課せるとは限らないものもあります。EUでは、ソフトウェア指令2009/24/ECにより、正当な利用者が必要なバックアップコピーを作成すること、プログラムの動作を観察・テストすること、または狭い相互運用性の例外の範囲で逆コンパイルすることを妨げる契約条項は無効とされます。例外なくあらゆるリバースエンジニアリングを禁止するEULAは、そうした場合には単に適用されない可能性があります。

専用のEULAが必要になりやすいのは、サーバーをほとんど、またはまったく介さずに動作し続けるソフトウェアを利用者がインストールする場合です。デスクトップアプリケーション、ダウンロード型のゲーム、プラグイン、オンプレミスのツール、オフラインで動作するモバイルアプリなどです。

アプリストアでは事情が変わります。Appleは、App Store ConnectでカスタムEULAを提供しない限り、App Storeのアプリに独自のLicensed Application End User License Agreement（使用許諾契約）、いわゆる標準EULAを適用します。カスタムEULAには、契約がAppleではなく事業者と利用者の間のものであることを認める条項など、Appleの最低限の条件を含める必要があります。

Google Playでは、デベロッパー販売契約により、アプリに独自のEULAを添付できます。また、Google Play自体の規約が、そこで入手したコンテンツについて利用者に基本的なライセンスを与えています。

アカウントやサブスクリプションも運営するほとんどのアプリにとって、実践的な答えは、ソフトウェアについてはストアのライセンスまたはカスタムEULAに依拠し、サービス自体についてはTerms of Serviceを公開することです。アプリの利用規約のガイドでは、それぞれのリンクをどこに表示すべきかを含め、この構成を詳しく解説しています。

大規模なサービスでは、規約を複数の文書群に分けることがよくあります。それぞれの文書は通常、参照によって組み込まれます。つまり、メインの規約に、他の文書が契約の一部を構成すると記載します。

• 利用ポリシー（Acceptable Use Policy）：禁止行為の詳細な一覧で、ホスティング、API、AI製品でよく使われます。
• コミュニティガイドライン：投稿、コメント、交流に関する平易なルールで、モデレーションの判断を支えます。
• 販売条件：注文、配送、返品、返金に関する購入のルールです。
• サブスクリプションまたは請求に関する条件：更新、解約、無料トライアル、価格変更です。
• プライバシーポリシー：契約の一部ではまったくありませんが、契約からリンクされます。

分割が役立つのは、ある分野が頻繁に変わる場合や、マーケットプレイスの出品者のように読み手が異なる場合です。逆に、文書同士が同じトピックを異なる言葉で繰り返すと害になります。良いルールは、各トピックはちょうど1つの文書に置き、他の文書はそこにリンクすることです。

EUの利用者向けにコンテンツをモデレーションする場合、デジタルサービス法はコンテンツの制限とモデレーションの手続きを利用規約に記載するよう求めていることを忘れないでください。そのため、メインの規約から別個のガイドラインへの参照を明確に示しましょう。

米国の裁判所は20年にわたり、オンライン契約をその提示方法によって分類してきましたが、結論を左右したのは一度も文書の名称ではありませんでした。

• クリックラップ（Clickwrap）：利用者が、リンクされた規約に同意すると明記されたチェックボックスにチェックを入れるか、ボタンをクリックします。通知が明確であれば、裁判所は一般にこれを執行可能と認めます。
• サインインラップ（Sign-in-wrap）：登録ボタンの近くに、続行すると同意したことになるという通知があります。結果は通知がどれだけ目立つかによって変わります。
• ブラウズラップ（Browsewrap）：規約はサイトのどこかにリンクされているだけで、利用することが同意とみなされるとされています。裁判所はこれを執行可能と認めることにしばしば消極的です。

Specht v. Netscape（第2巡回区控訴裁判所、2002年）では、無料ソフトウェアをダウンロードした利用者は、ダウンロードボタンの下までスクロールしなければ見えなかったライセンス条件に拘束されませんでした。Nguyen v. Barnes & Noble（第9巡回区控訴裁判所、2014年）では、Webサイトの下部にリンクされていた規約は、買い物客がそれを知っていた証拠がない限り、その買い物客を拘束しませんでした。Berman v. Freedom Financial Network（第9巡回区控訴裁判所、2022年）では、クリックが同意を意味すると明確に示していない、小さな灰色の通知文では不十分とされました。

この教訓はどの名称にも当てはまります。同意の時点で規約を明確に提示し、利用者が同意したことを記録しましょう。規約の書き方のステップ別ガイドでその方法を紹介しています。

Legal Policy Generatorは、回答に基づいて選択されるバージョン管理された条項から、Terms of Service（他社がTerms of UseやTerms and Conditionsと呼ぶのと同じ契約）を作成します。実行時にAIが条項を書くことはないため、同じ回答からは常に同じ文書が作成されます。

質問票では製品が実際にどう機能するかを尋ね、該当するセクションだけを有効にします。

• アカウント、利用資格、許容される利用
• ユーザーコンテンツ、モデレーション、EUデジタルサービス法に関する情報
• サブスクリプションと自動更新（カリフォルニア州の自動更新に関する文言を含む）
• EU、英国、オーストラリア、ブラジル、カナダ、ニュージーランドにおける返金と消費者の権利
• 米国のDMCA通知と米国の仲裁
• 責任、紛争、規約の変更

質問票と完全なプレビューはアカウントなしで無料で、シンプルなHTMLとPDFのダウンロードも無料です。地域別の高度なモジュールやオプションのモジュールは$5です。まず出力のイメージをつかみたい場合は、SaaS向け利用規約の参考サンプルや利用規約テンプレートのページをご覧ください。生成される規約は入力した事実を反映したものであり、法的助言ではありません。