SaaS サイトには製品紹介ページ以外に何が必要か？ユーザーログイン、サブスクリプション決済、管理画面はどう実装するか？

「私たちが何を解決するか」を説明するだけの SaaS サイトは、最大でも問い合わせを得ることはできても、登録ユーザーは獲得できません。SaaS を成立させるのは4層の機能の重ね合わせです。マーケティング層は理解と試用意欲を生み、アカウント層は「あなたは誰か」を確認し、課金層は「いくら支払い、何を買ったか」を確認し、アプリケーション層と管理層は約束を日常利用へと実現します。どれか1層が欠けると、サイトはパンフレットに退化します。

起業家や小規模ソフトウェアチームにとって、改善順序はまずアカウント体系、次にサブスクリプション課金、最後に管理画面と権限です。3者には強い依存関係があります。アカウントがなければ帰属主体がなく、課金がなければ区別できる利用権がなく、管理画面がなければ人手で補う手段がありません。

SaaS 公式サイトと実際の製品画面は何が違うのか

これら2種類のページは、ユーザー、目的、技術要件がまったく異なります。一緒に作ることが多くのプロジェクトで最初につまずく原因です。

よくある間違いは、ワークスペースまで検索エンジンにクロールさせること、または料金ページをログインウォールの内側に閉じ込めることです。前者は製品構造を漏らし、サイトテーマを希薄化します。後者は潜在顧客が意思決定前に料金を見られず、そのまま離脱します。正しい方法はルーティング層で分けることです。公開ルートはインデックス可能なコンテンツを出力し、アプリルートは認証を強制し収録を禁止します。

動作する SaaS サイトに必要なモジュール

ページ単位で分けるより、層単位で機能を分解するほうがスケジュールを組みやすくなります。

時間が半分しかないなら、アカウント層、課金層、最小限使えるワークスペースを優先し、管理層は最後に補います。管理画面は最初は最も原始的な表でも構いませんが、必ず用意してください。そうでなければ最初の有料ユーザーで問題が起きたとき、手作業でデータベースを変更するしかありません。

ユーザー登録、メール認証、ログインはどう実装するか

実装経路は5ステップに圧縮できます。

1. ログイン方式を選ぶ：メールアドレス＋パスワードを主とし、Google、GitHub などの OAuth をショートカット入口として加えると、登録時の摩擦を明確に下げられます。
2. アカウントを書き込み、認証メールを送る：登録成功後すぐにワンタイム認証トークンを生成し、アカウントに紐づけて有効期限を設定します。未認証アカウントは認証待ちとして扱い、有料利用権を一切付与しません。
3. 認証と再送のレート制限：認証リンクは1回だけ使用可能にします。同じメールへの再送は頻度制限が必要です。そうしないと他人のメールを攻撃する道具になります。
4. セッションを維持する：サーバー側セッションまたは署名付きトークンを使い、HttpOnly、Secure の Cookie を併用します。フロントエンドにスクリプトから読める資格情報を長期保存しないでください。
5. パスワード再設定と連携解除：パスワードを忘れた場合はワンタイムリンクでリセットします。サードパーティログインは連携と解除を許可し、ユーザーがメールを変更した後でアカウントを永久に失わないようにします。

セキュリティの詳細では、暗号化とハッシュを自作せず、成熟したフレームワークのパスワードハッシュとセッション機構を使用します。メール認証、Google / GitHub ログイン、基礎的なアカウント体系は汎用インフラであり、We0 のフルスタック生成機能はこうした機能を生成範囲に含めています（We0 フルスタックコード生成）。チームは業務フィールドと権限ルールに集中できます。

無料ユーザーと有料ユーザーをどう区別するか

最も見落とされやすい点：利用権判定は必ずサーバー側で行い、フロントエンドは表示のみを担当します。フロントエンドでボタンを隠しても制限にはなりません。API が直接呼ばれればそのまま実行されます。

推奨モデルは3つのテーブルと1つのサーバー関数です。プランテーブルは各プランの利用権識別子を定義し、サブスクリプションテーブルはアカウントの現在状態、周期、外部サブスクリプション ID を記録し、利用権テーブルはアカウント単位のクォータ残量を記録します。

canUse(user, feature):
    if user.status != "active": return false        # 未認証または停止中
    plan = plans[user.plan_id]
    if not plan.features.contains(feature): return false
    if plan.quota > 0 and user.used >= plan.quota: return false
    return true

無料と有料の違いは通常3点に現れます。機能スイッチ（高度なレポート、複数人コラボレーション）、数量クォータ（プロジェクト数、メンバー数、生成回数）、データ保持期間です。「禁止」で階層化するよりクォータで階層化するほうが滑らかです。無料ユーザーが実際に価値を出せてこそ、自らアップグレードします。

Stripe サブスクリプション決済はどう接続するか

サブスクリプション接続の核心はボタンではなく「誰が決めるか」です。原則は1つだけです。決済プラットフォームのサブスクリプション状態を唯一の事実源とし、自社データベースのフィールドはコピーにすぎないということです。

1. 価格オブジェクトを作成：月払いと年払いの価格をそれぞれ作り、価格 ID を環境変数に書きます。金額をフロントエンドにハードコードしないでください。
2. チェックアウトを開始：サーバー側でチェックアウトセッションを作成し、アカウント ID を metadata に書きます。ユーザーはサイトを離れて決済を完了します。
3. コールバックを受信：Webhook エンドポイントを設定し、サブスクリプション作成、更新成功、決済失敗、サブスクリプション解約などのイベントをすべて処理します。コールバックが利用権有効化の唯一のトリガーです。
4. コールバックを再送可能にする：同じイベントが重複配信される可能性があるため、処理ロジックは冪等でなければなりません。イベント ID またはサブスクリプション ID で重複排除します。レスポンスは素早く返し、時間のかかる処理は非同期で実行します。
5. 状態マッピング：外部サブスクリプション状態を内部状態にマッピングし、業務コードは内部状態だけを参照し、外部フィールドを直接読まないようにします。
6. 請求入口を提供：決済プラットフォーム付属のカスタマーポータルへ遷移して請求書とカードを管理します。自前の請求ページを作るより保守コストを大幅に削減できます。

決済成功後に機能をどう開放するか

ここが最も事故りやすい部分です。ユーザーは決済成功ページで「ようこそ」を見ても、利用権がまだデータベースに書き込まれていない場合、入った後に空のワークスペースや再度の決済促しを見ることになります。

正しい方法は「決済成功」と「利用権有効化」を独立した2つのイベントとして扱うことです。コールバックが到達し検証に成功した後にのみ、サブスクリプションを書き込み、利用権を更新し、ウェルカムメールを送ります。決済成功ページは自分の API をポーリングして利用権が利用可能になるのを待つだけにし、タイムアウト時は「決済処理中です。後ほどメールで通知します」と表示し、そのまま通しません。

ダウングレードも設計が必要です。期限切れ、未払い、返金はすべて統一された権限降格フローを通すべきです。まず一定期間は読み取り専用アクセスを保持し、その後徐々に書き込みとエクスポートを閉じます。突然すべての権限を切るとユーザーを怒らせ、無期限にすべての権限を保持すると製品を無料で配るのと同じです。

ユーザーはどこでアカウントとプランを管理するのか

情報が完備されたアカウントページは大量のサポートチケットを減らします。少なくとも以下を含めます。プロフィールとパスワード、メール変更（再認証が必要）、現在のプランと更新日、使用量とクォータ残量、請求書履歴とダウンロード、アップグレード・ダウングレード・解約の入口、全デバイスからのログアウトとアカウント削除。

プラン変更は方向を区別します。アップグレードは即時反映し日割り請求し、ダウングレードは次の周期に回します。ユーザーが頻繁に切り替えて精算が混乱するのを避けます。解約時に連続表示される引き止めポップアップは不要です。1回の明確な確認と「権限は X 月 X 日まで保持されます」の一文のほうが、10段階のポップアップより有効です。

管理者画面は何を管理すべきか

管理画面は「経営者に見せるダッシュボード」ではなく、異常処理ツールです。

管理画面で最もよくある誤りは、管理者アカウントを万能鍵にすることです。少なくとも3段階に分けることを推奨します。読み取り専用の運用担当、注文とユーザーを処理できる担当、課金と権限を変更できる担当です。すべての機密操作を監査ログに書き込み、問題発生時に誰がいつ何を変更したかを追跡できるようにします。

公式サイトと管理画面は1つのプロジェクトに入れるべきか、2つに分けるべきか

初期チームはほぼ単一プロジェクトを選ぶべきです。ドメインとセッションを共有し、ユーザーはトップページで登録した後そのままワークスペースに入れ、複数システム間でシングルサインオンを行う必要がありません。コンテンツ、SEO、製品更新が同じルーティングとデプロイ内にあり、運用コストが最も低くなります。公開されている SaaS 認証とアカウント管理のサンプルもこの一体型形態を採用しており、認証、ロール権限、サブスクリプション、ドメイン、デプロイを同じアプリ内で完了します（SaaS Auth Dashboard サンプル）。

チームの分業が明確になり、トラフィックが独立したスケーリングを必要とするほど大きくなったら、公式サイト、フロントアプリ、バックエンドサービスに分割します。代償はクロスドメインセッション、統一認証、コンテンツ同期の維持です。判断基準は3つです。公式サイトが毎週複数回更新され、アプリは半年に1回しかリリースしないか。マーケティングと製品開発をそれぞれ複数人が担当しているか。アプリに独立したスケーリングとデータベース分離の要件があるか。3つすべてが成立してから分割し、そうでなければまず統合します。

単一プロジェクト内でも明確な境界が必要です。マーケティングルートは認証を行わないがインデックス可能でなければならず、アプリルートは認証を強制し収録を禁止し、API 層は利用権を統一的に検証し、管理画面ルートには追加のロール検証を加えます。We0 はページ構造、認証、サブスクリプションとクレジット、CMS と管理画面、多言語、SEO、デプロイを同じ生成パイプラインに置いています（We0 フルスタックコード生成）。公式サイトと製品入口を1つのプロジェクトで受けることを望むチームに適しています。具体的な業務ルールと権限境界は製品要件に応じて定義する必要があります。

プロジェクト管理 SaaS で完全な流れを一度たどる

小規模チーム向けのプロジェクト管理 SaaS を作ると仮定します。無料版は3プロジェクト、プロプランはプロジェクト無制限でメンバーコラボレーションをサポートします。

1. トップページ：「誰がどのような場面で使うか」を明確にし、無料登録入口を提示し、クレジットカードを要求しません。
2. 料金ページ：3つのプランを並べ、月払いと年払いの価格差を明示し、クォータと制限を書きます。
3. 登録と認証：メール登録後すぐに認証メールを受け取り、認証完了後にのみプロジェクト作成を許可します。
4. サブスクリプション決済：ワークスペース内でアップグレードをクリックし、ホスト型チェックアウトページへ遷移し、月払いまたは年払いを選択します。
5. 利用権有効化：コールバックがサブスクリプション状態を書き込み、ワークスペース更新後にプロジェクト上限が解除され、現在のプランと更新日が表示されます。
6. ユーザーワークスペース：そのアカウント自身のプロジェクトのみを表示し、メンバー招待はシート単位で検証します。
7. 管理画面：サポート担当がユーザーを検索し、サブスクリプションを確認し、延滞ユーザーを手動で1日延長してクッションにできます。

この流れで本当に時間がかかるのはページではなく、第5ステップの状態整合性と第7ステップの異常処理です。多くのチームは8割の時間をトップページのビジュアルに費やし、公開後は未払いと返金を人手で処理しています。

公開前のチェックリスト

• メール未認証のアカウントは有料利用権から除外されているか？
• すべての利用権判定はサーバー側で実行されているか？
• 決済コールバックは冪等で、プラットフォーム状態のみを参照しているか？
• 決済成功ページは利用権のデータベース書き込みを待ち、そのまま通していないか？
• 延滞、解約、返金にそれぞれ対応するダウングレード経路があるか？
• アプリルートは収録禁止で、公開ページはインデックス可能か？
• 管理者操作に監査ログと最小権限があるか？
• 公式サイトコンテンツとヘルプドキュメントは同一ソースで、長期的な分岐を避けているか？

FAQ

SaaS サイトは製品紹介ページだけでよいですか？
段階的なランディングページとしては可能ですが、獲得しか担えず、登録、トライアル、課金を支えられません。ユーザーが「無料で開始」をクリックした後の行き先がなければ、トラフィックを無駄にします。

コードを書けなくても SaaS は作れますか？
アカウント、サブスクリプション、管理画面、デプロイなどの汎用インフラは成熟したプラットフォームや AI 生成機能で素早く構築できますが、課金ルール、権限境界、データモデルは人が設計し検証する必要があります。ツールは重複作業を減らしますが、製品判断の代わりにはなりません。

サブスクリプション決済は必ず Stripe を使う必要がありますか？
いいえ。ただし選定は対象市場と決済サイクルによります。Stripe のサブスクリプション、請求書、カスタマーポータルは比較的整っています。国内ユーザー向けにはローカル決済手段も考慮する必要があります。どれを使う場合でも「外部状態を唯一の事実源とする」原則に従います。

無料ユーザーと有料ユーザーはどう区別するのが最も簡単ですか？
プランテーブル、利用権テーブル、サーバー側の判定関数です。各ページに条件判定を散らばせると、新しいプランを追加するたびに十数箇所を修正することになります。

公式サイトと管理画面は同じプロジェクトに置くべきですか？
初期は同じプロジェクトに置き、ドメインとセッションを共有すると運用コストが最も低くなります。チームとトラフィックがそれぞれ独立して反復する必要が出たら分割します。

決済は成功したのに機能が有効にならない場合は？
まずコールバックが届いているか、署名検証が通っているか、冪等性の重複排除が誤判定していないかを確認し、次に利用権が書き込まれているかを確認します。ユーザー側には「処理中」という明確なフィードバックと人手による救済チャネルを提示し、再決済させないようにします。

関連ツール

• Stripe 公式ドキュメント：サブスクリプション、チェックアウト、コールバック機構の原典説明
• React + Shadcn UI などのコンポーネントライブラリ：ワークスペースのテーブル、チャート、ページネーション操作を素早く構築（実装参考）
• デザイン稿からコードへのツール：管理画面デザインをそのまま実行可能なページに変換
• We0.ai：1つのプロジェクト内で認証、決済、CMS 管理画面、デプロイを組み合わせる

関連リンク

• We0 フルスタックコード生成機能
• SaaS Auth Dashboard：認証とアカウント管理のサンプル
• Build a SaaS Admin Dashboard with React, Shadcn UI & TypeScript

まとめ

製品紹介ページだけの SaaS サイトが解決するのは「信じてもらうこと」であり、ログイン、サブスクリプション決済、管理画面が解決するのは「実際に使ってもらい、継続課金してもらうこと」です。導入順序はアカウント体系、サブスクリプション課金、最小限使えるワークスペース、管理画面が推奨です。技術上は3つの厳格な制約があります。利用権判定はサーバー側に置く、決済プラットフォームの状態を唯一の事実源とする、決済成功と利用権有効化を分けて処理する、です。公式サイトと管理画面は初期には同じプロジェクトに置き、ドメインとセッションを共有できます。チームとトラフィックがそれぞれ独立して反復する必要が出た段階で分割します。