ログインページ刷新と利用規約の全面改定

ログインページを開いた瞬間、「ここから先に進みたい」と思える画面になっているか。朝からその問いを軸に、サインインフローのUI刷新と利用規約の全面改定を一気に進めた。利用規約はテキストを書き換えるだけかと思っていたが、他サービスの規約を並べて読み比べているうちに、条文の構造そのものを組み直す作業に変わった。

ログインページのデザイン更新

サインインフローの改善

既存のログインページは、メールアドレス入力とソーシャルログインボタンが同じ重みで並んでいた。ユーザーの目線が分散して、最初のアクションまで数秒迷う構成になっていた。

今回の変更点:

ソーシャルログイン（Google / GitHub）をページ上部にまとめ、ワンクリックで入れる動線を最短にした
メールアドレスログインは下部に配置し、「その他のログイン方法」として折りたたみ可能に
ページ下部に利用規約への同意テキストを追加。「ログインすることで利用規約に同意したものとみなします」の一文を配置

同意テキストの配置判断

利用規約の同意をどこに置くかで少し迷った。チェックボックス方式にすると離脱率が上がるという話をよく聞くので、主要サービスのログイン画面を確認して回った。結果として「ログインボタンの下に同意文言を表示し、ボタン押下で同意とみなす」方式を採用した。法的にはチェックボックスの方が強いが、ログイン画面の摩擦を減らす方を優先した。

利用規約のリサーチ

他サービスの利用規約をいくつか横に並べて読んだ。見ていたのは主にこのあたり:

note, Zenn: クリエイター向けプラットフォームの規約構造
Udemy, Coursera: 有料教育コンテンツの課金・返金まわり
Notion, Figma: SaaS系サービスの料金変更通知ルール

共通して見えたパターンがあった。無料コンテンツと有料コンテンツの境界を明文化している規約は、後から料金体系を変えるときに揉めにくい。逆に「サービス内容は予告なく変更できる」と一文で済ませているサービスは、SNSで炎上している事例をいくつか見かけた。

この観察を踏まえて、eurekapuの規約はコンテンツの区分と料金変更ルールを先に整備しておく方針にした。

利用規約の構造変更

13条から14条への拡張

既存の利用規約は13条構成だった。今回、以下の2条を新設して14条に再編した:

第4条: コンテンツの区分（新設）
第5条: 料金および支払い（新設）

これに伴い、旧第4条以降の条番号が2つずつ後ろにずれた。条番号の付け替え作業が地味に手間だったが、ここで構造を整理しておかないと後で条文間の参照が破綻する。

第4条: コンテンツの区分

無料コンテンツと有料コンテンツの境界を条文として明確にした。ポイントは以下:

サービス内のコンテンツを「無料コンテンツ」と「有料コンテンツ」に分類する旨を明記
各コンテンツの区分はサービス上で表示し、ユーザーが判別できる状態にする
無料コンテンツの範囲変更は運営側の裁量で行えるが、既存の有料コンテンツを無料に格下げする場合の扱いも定義

現時点では全コンテンツが無料だが、将来的な有料化に備えて規約だけ先に整備した形になる。

第5条: 料金および支払い

将来的な課金を見据えて、2つの方式を想定した条文を用意した:

買い切り方式: コンテンツ単位での購入
サブスクリプション方式: 月額または年額での継続課金

具体的な金額や料金プランは規約には書かず、「料金はサービス上に表示する価格に従う」という形にした。料金の詳細を規約に埋め込むと、価格改定のたびに規約改定が必要になってしまう。

料金変更時の30日前通知義務

料金変更のルールは特に慎重に設計した。リサーチで見た限り、ユーザーへの通知義務を明記しているサービスは信頼感が高い。以下の内容を条文に盛り込んだ:

料金変更は30日前までにユーザーに通知する
通知方法はメールまたはサービス内通知
通知期間中にサブスクリプションを解約した場合、変更前の料金が適用される

30日という期間は、Notion や Figma の規約を参考にした。短すぎると不誠実に見えるし、長すぎると運営の機動性が落ちる。

コンセプト版とライブ版の同期

利用規約の編集は2段階で進めた:

memo/concept配下でドラフトを書く。Claude Codeと壁打ちしながら条文を練る段階
構造が固まったら**terms.vue（ライブ版）**に反映する

今回は概念設計の段階でかなり行ったり来たりしたので、コンセプト版とライブ版の乖離が一時的に大きくなった。最終的に差分を目視で確認しながら手動で同期した。

今後、規約を頻繁に更新するなら、コンセプト版をMarkdownで管理してビルド時にVueに注入する仕組みを検討してもいいかもしれない。ただ、利用規約の更新頻度を考えると手動同期で十分な気もする。

学びメモ

利用規約は「今必要な条文」だけ書くと、後から構造を変えるコストが跳ね上がる。最初にスケルトンを広めに用意しておく方が、結果として手戻りが減った
他サービスの規約を5つ以上並べて読むと、業界の「暗黙の標準」が浮かび上がってくる。1つだけ読んでも「これが普通なのか例外なのか」が判断できない
料金変更通知の30日ルールを入れたことで、自分自身の意思決定にも制約がかかる。でもその制約がユーザーとの信頼関係を作る。規約は「ユーザーへの約束」であると同時に「自分への制約」でもあるという感覚を、条文を書きながら初めて実感した

振り返り

朝はログインページのボタン配置を調整するだけのつもりだった。しかし「利用規約への同意テキストを追加する」という小さなタスクが、規約全体の見直しに発展し、気づけば条文を1条ずつ読み直して構造を組み替えていた。規約を書く作業は、サービスの将来像を言語化する作業でもあった。