アプリ利用規約の作り方完全ガイド｜必須条項・課金・ストア審査まで行政書士が解説

アプリ利用規約は、単に「アプリに載せておけばよい文章」ではありません。ユーザーとの契約条件を定めるだけでなく、アプリ内課金、アカウント、投稿、停止措置、サービス終了、データの取扱いなど、アプリ運営で実際に起こるトラブルをあらかじめ整理するための重要なルールです。

特にiOS・Androidアプリでは、民法や消費者契約法などの日本法だけでなく、App Store・Google Playのルール、アプリ内課金の仕組み、プライバシーポリシーとの整合まで考える必要があります。

すでに利用規約を作成している場合や、ChatGPTなどの生成AI・テンプレートを利用して原案を作成した場合も、実際のアプリ仕様、課金方法、アカウント、データの取扱い、ストアポリシー等と規約内容が一致しているかをチェックし、必要に応じて修正することが重要です。

記事執筆・監修

DAN行政書士事務所 行政書士 塩坂 壇

IT法務・利用規約を専門とする行政書士。
Webサービス・SaaS・スマートフォンアプリ等の利用規約、プライバシーポリシー、IT契約書の作成・リーガルチェックを取り扱っています。

アプリに利用規約は必要？

すべてのアプリについて法律上「利用規約という名称の文書を必ず作成しなければならない」と一律に定められているわけではありません。

しかし、ユーザー登録、課金、投稿、アカウント、クラウド保存、ユーザー間取引などを含むアプリでは、事業者とユーザーの権利義務を明確にする必要があります。実務上は、利用規約を整備しないままサービスを提供することの方が大きなリスクになります。

たとえば、次のような場面です。

• 不正利用をしたユーザーのアカウントを停止したい
• サブスクリプションの更新・解約条件を明確にしたい
• 有償アイテムやアプリ内通貨の扱いを決めたい
• ユーザー投稿による権利侵害に対応したい
• サービス内容や料金体系を変更したい
• アプリ自体を終了するときの取扱いを定めたい

こうした運営判断を後から行おうとしても、利用規約に根拠がなければユーザーとの紛争につながることがあります。

Webサービスの利用規約との違い

アプリ利用規約も基本構造はWebサービスの利用規約と共通します。しかし、アプリでは端末・OS・アプリストア・アプリ内課金といった第三者の環境に依存する点が大きく異なります。

そのため、Webサービス用のテンプレートをそのままアプリに流用すると、実際のサービス仕様と規約が噛み合わないケースがあります。

利用規約全般の基本的な作り方については、利用規約の書き方・作成ポイントもあわせてご覧ください。

利用規約への同意はどう取得する？

利用規約は、作成しただけでは意味がありません。ユーザーとの契約条件として機能させるためには、アプリ内で規約を適切に表示し、ユーザーが確認できる状態を整える必要があります。

アカウント登録型のアプリであれば、登録画面などで利用規約へのリンクを表示し、

といったチェックボックスや同意ボタンを設ける方法が一般的です。

特に重要なのは、ユーザーが同意する前に利用規約を確認できることです。リンク先が存在しない、規約がログイン後しか見られない、同意後に初めて全文を確認できる、といった設計は避けた方が安全です。

利用規約への同意方法や、同意画面の具体的な設計については、利用規約への同意のさせ方で詳しく解説しています。

「規約はいつでも自由に変更できる」と書いてよい？

アプリ利用規約の相談で非常に多いのが、

という要望です。

運営上そうした柔軟性を確保したい気持ちはよく分かります。しかし、規約に「当社はいつでも任意に変更できる」とだけ書けば、どのような変更でも当然にユーザーを拘束できる、というわけではありません。

利用規約が民法上の定型約款に該当する場合、定型約款の変更については民法第548条の4との整合を考える必要があります。利用者一般の利益に適合する場合や、契約目的に反せず、変更の必要性・相当性その他の事情に照らして合理的といえる場合などが問題になります。

そのため実務では、単に「いつでも変更できる」とするのではなく、

• どのような場合に変更することがあるか
• 変更内容をどの方法で周知するか
• 変更後の規約の効力発生日
• 重要な変更の場合のユーザーへの通知方法

などをセットで設計します。

利用規約を変更する際の要件やユーザーへの周知方法については、利用規約の変更・改定で詳しく解説しています。

アプリ利用規約に入れる主な条項

アプリの内容によって必要な条項は変わりますが、一般的には次のような項目を検討します。

これらを全部入れればよいという意味ではありません。重要なのは、実際のアプリ仕様と条文を一致させることです。

アカウント・複数端末・退会・削除

ID・パスワード型のアプリでは、複数端末から利用できるケースもあります。この場合は、単に「ID・パスワードを第三者に貸してはいけない」とするだけでなく、アカウントの利用主体や端末変更時の扱いも考える必要があります。

また近年は、アカウント削除の設計も重要です。Appleは、アカウント作成をサポートするアプリについてアプリ内からアカウント削除を開始できることを求めています。Google Playでも、アプリ内でアカウントを作成できる場合、アプリ内およびアプリ外のWebリソースから削除を開始できる仕組みが求められています。

規約側でも、退会、アカウント削除、削除後のデータ、法令上保存が必要な情報などの関係を整理しておくことが重要です。

未成年者の利用

未成年者が利用する可能性があるアプリでは、親権者等の法定代理人の同意に関する条項を検討します。

特にゲーム、SNS、学習、フィットネス、コミュニティ系アプリなどは、成人だけを対象としているつもりでも未成年者が利用するケースがあります。

単に「未成年者は保護者の同意を得てください」と記載するだけでなく、課金上限、年齢確認、対象年齢、実際のUI設計との整合も重要です。

アプリ内課金・サブスクリプション

アプリ内課金を導入する場合、規約本文だけでなくApp Store・Google Playの課金ルールとの整合が必要です。

Appleでは、アプリ内の機能やデジタルコンテンツ、ゲーム内通貨等のアンロックについて、原則としてIn-App Purchaseのルールが関係します。Google Playでも、デジタル商品、アプリ機能、仮想通貨、サブスクリプション等についてGoogle Playの課金システムの利用が原則とされています。

サブスクリプション型では、少なくとも次の点を整理します。

• 契約期間
• 自動更新
• 料金
• 解約方法
• 解約後いつまで利用できるか
• 無料期間がある場合の移行条件
• App Store / Google Play側での解約との関係

有償通貨と無償通貨はなぜ分ける？

アプリ運営者からよく聞かれるのが、

という質問です。

理由の一つは、ユーザーがお金を払って取得したものと、運営者が無料で付与したものでは、法的・会計的な意味が同じとは限らないからです。

金融庁も、名称が「ポイント」であっても、利用者が対価を支払って発行されるものについては前払式支払手段に該当し、資金決済法の規制対象となる場合があると説明しています。

一方、ログインボーナスやキャンペーン等で無償付与したポイントは、同じ扱いになるとは限りません。

そのため、規約ではたとえば、

• 有償通貨
• 無償通貨
• 有償アイテム
• 無料配布アイテム

を必要に応じて区別します。

さらに、消費時に「有償分から先に減るのか」「無償分から先に減るのか」、有効期限、サービス終了時の扱いなども検討対象になります。

有償のアプリ内通貨に「有効期限」を設定したい場合の注意点

有償のアプリ内通貨を設計する際、事業者側からすると「できれば有効期限を設定したい」という事情があります。

その理由の一つが、資金決済法上の前払式支払手段に該当した場合の基準日未使用残高と発行保証金の問題です。

前払式支払手段発行者は、基準日未使用残高が基準額である1,000万円を超える場合、原則として基準日未使用残高の2分の1以上に相当する額について、発行保証金の供託等による資産保全が必要になります。

つまり、正確には「前払式支払手段発行者として届出をしたから供託が必要になる」という関係ではなく、基準日未使用残高が1,000万円を超えることによって、発行保証金の供託等の義務が問題になるという整理です。

利用されない有償通貨が長期間にわたって残り続けると、未使用残高が積み上がり、事業者側の資金負担にもつながります。そのため、アプリの設計段階では「有償通貨に有効期限を設定し、一定期間経過後に失効させたい」と考えることがあります。

これは、アプリ内通貨について日本の法令だけを見て設計しても解決できない典型的な問題です。

有償通貨を導入する場合には、たとえば次の事項をアプリの仕様設計段階から検討しておく必要があります。

• 資金決済法上の前払式支払手段に該当するか
• 自家型前払式支払手段か、第三者型前払式支払手段か
• 有償通貨と無償通貨をどのように区別して管理するか
• 基準日未使用残高がどの程度になると予想されるか
• 発行保証金の供託等による資産保全が必要になる可能性
• AppleのIn-App Purchaseに関するルール
• Android版を含め、各プラットフォームでどのような通貨設計にするか
• サービス終了時に未使用の有償通貨をどのように取り扱うか

一つの規約ですべてをまとめてもよい？

マッチングサービスやプラットフォーム型アプリでは、

という相談もよくあります。

一つの規約にまとめること自体が直ちに問題になるわけではありません。ただし、ユーザーごとに権利義務が大きく異なる場合、無理に一つの条文へ押し込むと、誰にどの条項が適用されるのか分かりにくくなることがあります。

たとえばマッチングサービスでは、

• サービスを探す側
• サービスを提供する側
• プラットフォーム運営者

という三者関係になる場合があります。

この場合、「共通条項＋提供者向け特則」のように一つの規約内で章を分ける方法もあれば、ユーザー類型ごとに別の規約を用意する方法もあります。

同じユーザーが「購入者」にも「販売者」にもなる場合

一方、フリマアプリなどのように、一人のユーザーが取引によって購入者にも販売者にもなるサービスでは、一つの利用規約にまとめる方が自然な場合もあります。

たとえば、あるユーザーが今日は商品を購入し、翌日は自分の商品を出品するというサービスで、「購入者用利用規約」と「販売者用利用規約」を完全に分けると、同じユーザーに複数の規約が適用されることになり、かえって規約の適用関係が複雑になることがあります。

このような場合には、一つの利用規約の中を、

といった形で整理する方法が考えられます。

重要なのは「規約を一つにすること」そのものではなく、誰に、どの場面で、どの条文が適用されるのかをユーザーが理解できる構成にすることです。

禁止事項・アカウント停止・不正利用

アプリの禁止事項は、一般的な違法行為だけでなく、そのアプリで実際に起こり得る不正行為まで想定して作成します。

たとえば、

• 複数アカウントの不正取得
• BOT・自動化ツールの使用
• チート行為
• アプリの解析・リバースエンジニアリング
• スクレイピング
• 他人へのなりすまし
• 決済の不正利用
• 他のユーザーへの迷惑行為

などです。

また、禁止事項を列挙するだけでなく、違反した場合に運営者が利用制限、投稿削除、アカウント停止、強制退会等を行えることも規定します。

知的財産権・投稿コンテンツ

アプリ本体のプログラム、画像、UI、文章、キャラクター等の権利帰属を明確にします。

ユーザー投稿型アプリではさらに、投稿された文章・画像・動画などを運営者がどの範囲で利用できるのかを定める必要があります。

「投稿した瞬間に著作権がすべて運営者に移転する」といった過度な規定が本当に必要なのか、それともサービス運営・宣伝に必要な範囲で利用許諾を受ければ足りるのかは、サービスごとに検討すべきです。

サービス変更・アップデート・終了

アプリは、公開後も継続的にアップデートされます。機能追加だけでなく、仕様変更、機能削除、料金変更、対応OSの変更なども起こります。

そのため利用規約では、運営者がサービス内容を変更できる旨を定めることがあります。

ただし、課金済みユーザーの重要な権利を一方的に奪うような変更まで無制限に認められるわけではありません。契約内容、消費者契約法、民法、ストアポリシーなどとの関係を踏まえて設計する必要があります。

サービス終了条項についても、終了の告知方法、未使用の有償通貨、サブスクリプション、ユーザーデータなどをあわせて検討します。

免責・損害賠償

アプリ利用規約では、通信障害、端末故障、OSアップデート、第三者サービス障害、データ消失等について免責条項を置くことがあります。

しかし、「当社はいかなる場合も一切責任を負いません」と書けば何でも免責できるわけではありません。特に消費者との契約では、消費者契約法との整合が必要です。

そのため、免責条項は単に強い文言を入れるのではなく、どのようなリスクを誰が負担すべきかを整理した上で作成します。

プライバシーポリシーとの違い

利用規約とプライバシーポリシーは役割が異なります。

Google Playでは、すべてのアプリについてPlay Console上の指定欄とアプリ内にプライバシーポリシーを表示することが求められています。またAppleでもApp Store Connectでアプリのデータ取扱いに関する情報の申告が必要です。

つまり「利用規約の中に個人情報のことも書いたから、プライバシーポリシーは不要」という考え方は避けるべきです。

プライバシーポリシーに記載する内容や、個人情報・ユーザーデータ、外部送信規律などの整理については、プライバシーポリシー作成ガイドで詳しく解説しています。

App Store・Google Playとの関係

アプリ利用規約を作成する際は、法律だけでなく各ストアのポリシーにも注意が必要です。

たとえばAppleでは、アプリ内機能、ゲーム内通貨、プレミアムコンテンツ等のアンロックにIn-App Purchaseを利用するルールが定められています。またアカウント作成をサポートするアプリではアプリ内でのアカウント削除も求められています。

Google Playでも、デジタル商品、仮想通貨、サブスクリプション、アプリ機能等の購入についてGoogle Playの課金システムに関するルールがあります。アカウント作成機能がある場合は、アプリ内・アプリ外の双方からアカウント削除を開始できる仕組みが必要です。

アプリの種類別｜専門ページ

必要な条項はアプリの種類によって大きく異なります。アプリの機能やユーザーとの関係に近いものから、種類別の解説をご確認ください。

作成前チェックリスト

規約を書く前に、まずアプリの仕様を整理します。以下に答えられる状態になっていると、条文設計が大幅にしやすくなります。

この段階で仕様が整理されていないと、利用規約を作成してから「実際のアプリではそんな動きになっていない」というズレが生じます。

参考となる公式情報

• Apple「App Reviewガイドライン」（3.1.1 アプリ内購入）
• Apple「アプリ内でのアカウント削除機能の提供」
• Apple「アプリのプライバシーに関する詳細情報」
• Google Play「お支払い」
• Google Play「ユーザーデータ」
• e-Gov法令検索「民法」
• 金融庁「資金決済法Q&A」