認証とサブスク決済：請求モデルに合致したデータ連携を設計しよう

SaaS開発において、決済機能は特殊な位置にあります。基本機能とは直接関係なく、なくてもコア機能自体は動かせるため、「リソース最適化」の名目で組み込みを後回しにしがちです。「いざとなれば、別で請求書を出せばいい」という考えもよく聞かれます。

しかし、この考え方には大きな落とし穴があります。決済がないアプリは動くかもしれませんが、お金を生まないなら「会社の商品」ではありません。そして後から決済を組み込もうとすると、以下のような問題に直面します。

• プランごとの権限設定をどう実装するのか
• 契約情報はどこから取得するのか
• 追加のDBやデータモデルが必要になる
• プラン変更の仕組みをどう構築するのか

重要なのは、実装はしなくとも決済を見据えた設計を心がけることです。

ありがちなハマりどころと考慮漏れ

契約主体の考慮漏れ

ユーザーごと契約でリリースしたものの、見込み客から「法人契約が必要」と言われるケースです。個人向けに設計されたシステムを組織向けに拡張するのは、想像以上に困難な作業となります。

権限管理の考慮漏れ

プランベースで権限管理を実装していたところ、大口顧客から個別のカスタム契約相談があるケース。標準プランでは対応できない要件が発生すると、システム全体の見直しが必要になることがあります。

決済では、顧客の商習慣や契約体系に応じたデータモデルや設計が必要となります。「担当者退職したので、契約者と決済内容をこのアカウントに移して」といった運用面での要求も珍しくありません。

B2Bの取引・契約は開発者にとって複雑すぎる

B2B SaaSで押さえておきたい要件として、以下の2つが特に重要です。

1. ユーザーと契約の分離

組織（Organization）の概念

• ユーザーDBとは別のテーブルで管理
• サブスクや決済は組織に対して紐づける
• 個人の退職や異動に左右されない契約管理

2. 権限を独立管理

Feature Flagの活用

• プランと権限を別で管理
• 個別の権限付与に対応可能
• マーケティングや営業戦略に柔軟に対応

解決策としてのソリューション

Clerk Organization

Clerk OrganizationはIDaaSのprebuilt組織機能として提供されています：

• ユーザーと別に組織管理機能を提供
• IDaaSに統合されていることで、DB設計の複雑さを回避
• <OrganizationProfile /> のような組み込み済みUIコンポーネント

const { has } = await auth()
const canAccessPremium = has({ plan: 'pro' })
const isAdmin = has({ role: 'org:admin' })

Stigg.io

Stigg.ioは決済&Entitlement SaaSとして以下の特徴があります。

• 契約やプランに対する権限の管理に特化
• APIやダッシュボードも提供
• Stripeなどとも連携可能

const entitlements = {
  // feature gate entitlement
  'advanced-dashboards': {},
  // configuration entitlement  
  'data-retention-days': {
    value: 14,
  },

  // usage quota/limit entitlement
  'file-storage-mb': {
    usage: 128,
    limit: 1024,
  },
}

価格は変わる。絶対に

AWS Kiro（AIエディタ）の価格変更のように、どんな大企業でも価格は二転三転させます。価格変更は避けられない現実として、システム設計時から考慮する必要があります。

Stripe Subscription Schedule APIなどで価格改定に備える

const subscriptionSchedule = await stripe.subscriptionSchedules.create({
  customer: 'cus_NcI8FsMbh0eFs',
  start_date: 1787130418,
  end_behavior: 'release',
  phases: [{
    items: [{
      price: 'price_1Mr3YcLkdIwHu7ixYOj2',
      quantity: 1,
    }],
    iterations: 12,
  }],
})

将来の価格変更に対応できる柔軟な設計を心がけることが重要です。

B2Cならもっとシンプルにできる？

B2Cであっても、組織概念が必要になるケースがあります：

家族契約のケース例

• 育アプリやサービス
• 見守りサービス
• 回線契約や施設利用など

「ユーザーはどんな契約をするだろうか？」を企画調査フェーズで必ず行うことが重要です。個人向けアプリでも、実際の利用形態を想定した設計が必要になります。

B2B SaaSは商習慣も重要なドメイン

以下の3つのポイントを押さえることが重要です：

1. 契約主体が個人か組織（法人）かは必ずチェック

2. 契約主体に合わせてユーザーDBと決済データなどの連携を設計すべし

3. マーケティングや営業戦略を踏まえると、プランと権限も別で管理することを推奨

まとめ：ログインの先にある複雑さ

認証とサブスクリプション決済の連携において、以下の点を理解しておくことが重要です。

ログインユーザーと契約者/主体が常に同一人物とは限らない

• 組織内の複数ユーザー
• 家族契約での利用者と契約者の違い
• 管理者の退職や交代への対応

ユーザーとプランだけでなく、権限と組織についても設計を行おう

• Feature Flagによる柔軟な権限管理
• 組織レベルでの契約管理
• カスタム要件への対応力

設計・調査フェーズで「どう契約して、使われるか」も考慮しよう

• 商習慣の理解
• 契約形態の多様性への対応
• 将来の価格変更への備え

認証の先にある複雑さを理解し、ビジネスの成長に合わせて拡張可能な設計を心がけることで、持続的な成長を支える技術基盤を構築できるでしょう。