Claude Code Academia

第11章 認証と決済の組み込み（Supabase Auth + Stripe）

第10章で、Web アプリを作って世界に公開するところまで体験しました。

第11章は、その先の話。「特定の人だけ使える」「お金を払って使う」アプリを作るための、認証と決済の組み込みです。

第11章で扱うこと：

  • 認証（誰がアクセスしているかを識別する仕組み）
  • ロールベースのアクセス制御（admin と staff の区別）
  • 本番環境への認証移行
  • Stripe を使った決済組み込み

僕は訪看アプリで認証は本格実装したので、その実体験ベースで書きます。Stripe（決済）は僕も研究中の領域ですが、Code との対話で十分組める範囲です。

11-1. 認証の必要性と OAuth の基本概念

【学習目標】

  • 認証が必要なアプリと、不要なアプリを見分けられる
  • 「メール+パスワード」「OAuth」など認証方式の違いを理解する

【前提知識】

  • 第10章でアプリを公開できていること

【概念解説】

「認証」とは、アクセスしている人が誰かを識別する仕組みのこと。ログイン画面でメールアドレスとパスワードを入れる、あれです。

認証が必要なアプリ

  • 個人のデータを扱う（家計簿、健康記録、ToDo など）
  • 複数人で共有するけど、誰が誰かを区別したい（チーム ToDo、訪看アプリ）
  • 課金が絡む（有料機能、サブスク）
  • データを保護したい

認証が不要なアプリ

  • 誰でも見られる情報を表示するだけ（カフェ紹介、企業サイト、ブログ）
  • 個人特定不要な機能（公開ストップウォッチ、計算ツール）

訪看アプリのように「職員ごとに自分の訪問記録だけを見たい」場合は、認証が絶対に必要。

認証方式の種類

主な認証方式は3つあります。

1. メール + パスワード

  • 最も基本的
  • ユーザーがメールとパスワードを設定して、毎回それでログイン
  • 実装が比較的シンプル

2. OAuth（外部サービス経由）

  • Google や GitHub などのアカウントでログイン
  • ユーザーは新しいパスワードを覚えなくていい
  • 「Google でログイン」ボタンで完結

3. マジックリンク

  • メール送信のリンクをクリックしてログイン
  • パスワード不要
  • 簡単だがメールが届かないと使えない

OAuth とは（少し深掘り）

OAuth は「Google や GitHub に認証を委ねる」仕組み。

ユーザー「Google でログインしたい」
↓
アプリ「Google さん、この人本物ですか？」
↓
Google「本物です、メールアドレスは ○○ です」
↓
アプリ「OK、ログインさせます」

つまり、自分のアプリで「メールアドレス・パスワードの管理」をしなくていい。面倒なパスワード管理を Google に任せるということです。

初心者は何から始めるべきか

僕は訪看アプリで「メール + パスワード」から始めました。理由は：

  • 実装がシンプル
  • ユーザーの理解も簡単（誰もが慣れている）
  • Supabase Auth で簡単に組める

OAuth（Google ログインなど）は、その後で追加できます。最初の MVP（最低限の動くもの）では、メール+パスワードで十分。

【ハンズオン手順】

▼ ブラウザ側でやること（自分のアプリの認証要件を整理）

  1. ブラウザに次のように打つ
私が作っているアプリ：[簡単な説明]

このアプリに認証は必要ですか？
必要なら、どの認証方式（メール+パスワード、OAuth、マジックリンク）が
向いていますか？
  1. ブラウザがアドバイス
  2. 必要なら、どの方式から始めるか決める

▼ Code 側でやること（既存の認証状況を確認）

  1. プロジェクトを Code で開く
  2. 「現在、このプロジェクトに認証は実装されていますか？」と聞く
  3. 状態を把握

【つまずきポイント】

  • 「認証は難しいから後回し」と思わない。Supabase Auth で初心者でも実装可能
  • OAuth を最初から組み込もうとしない。メール+パスワードで動作してから追加

【確認問題】

  • 認証が必要なアプリの典型例を3つ挙げてください
  • OAuth とは何ですか？簡単に説明してください

【次のレッスンへの橋渡し】

認証の必要性が見えました。次は、実際に Supabase Auth を使った認証を実装していきます。

11-2. Supabase Auth を用いた認証の組み込み

【学習目標】

  • Supabase Auth の機能を理解する
  • アプリにログイン機能を追加できる

【前提知識】

  • 10-5 で Supabase に接続できていること

【概念解説】

Supabase には「Auth」というモジュールが組み込まれていて、認証機能を簡単に追加できます。

Supabase Auth でできること

  • ユーザー登録（サインアップ）
  • ログイン
  • ログアウト
  • パスワードリセット
  • メール認証
  • セッション管理（ログイン状態の保持）

これら全部、自分で書かなくていい。Supabase が提供してくれる。

実装の全体像

1. Supabase ダッシュボードで Auth を有効化
2. Code に「Supabase Auth でログイン機能を追加して」と依頼
3. Code がフロントエンドのコードを書く（ログイン画面、登録画面）
4. Code が Supabase との連携コードを書く
5. 動作確認

これ、Code に Plan モードでお願いすると、丁寧に進めてくれます。

僕の訪看アプリでの実装

僕が訪看アプリで実装した認証の構成：

  • メール + パスワード認証
  • 新規登録時に「承認待ち」状態（管理者が承認するまでログイン不可）
  • ロール管理（admin / staff）

「承認待ち」フローは少し凝った実装ですが、これも Code と対話しながら組みました。最初は普通のメール+パスワード認証で動かしてから、後で「承認待ち」を追加した、という順序です。

段階的に作るコツ

認証を一気に完璧に作ろうとしないこと。僕なりの段階：

段階1：ログイン・ログアウト・新規登録だけ動く
段階2：パスワードリセットを追加
段階3：メール認証を追加（メール確認しないとログイン不可）
段階4：ロール管理を追加（admin / staff）
段階5：承認フローを追加

各段階で動作確認しながら進める。これがスクショ伴走モデルの本領。

【ハンズオン手順】

▼ Supabase 側でやること（Auth の有効化）

  1. Supabase ダッシュボードを開く
  2. 「Authentication」を選ぶ
  3. 「Providers」で「Email」が有効になっていることを確認
  4. 必要に応じて「Enable email confirmations」（メール確認の要否）を設定
    • 開発時はOFFにしておくと楽

▼ Code 側でやること（認証の組み込み）

  1. Code に次のように依頼（Plan モード）
Supabase Auth を使って、アプリに認証機能を追加してください。

実装する機能：
- ログイン画面
- 新規登録画面
- ログアウトボタン
- ログイン状態によって画面を切り替え

まず Plan を提示してください。
  1. Code が Plan を出す
  2. 確認して OK
  3. Code が実装

▼ 動作確認

  1. アプリでログイン画面が表示される
  2. 新規登録 → メールアドレスとパスワードを入力 → 登録成功
  3. ログイン → 同じメール・パスワードで → ログイン成功
  4. ログアウトボタン → ログアウト

▼ スクショ伴走のチェックポイント

  • Supabase の Auth 設定画面
  • ログイン画面が表示された状態
  • 新規登録〜ログイン成功までのフロー

【つまずきポイント】

  • 開発初期はメール確認をOFFにする。確認メールが届かないと検証が進まないことがある
  • テストアカウントを複数作る。「自分」と「他のユーザー」を切り替えて動作確認するため
  • Supabase Auth のセッションは時間で切れる。長時間放置すると再ログインが必要

【確認問題】

  • Supabase Auth で実装できる認証機能を3つ挙げてください
  • 認証を「段階的に作る」コツを説明してください

【次のレッスンへの橋渡し】

認証の基本ができました。次は、もう一歩進んで「ロール管理」（admin / staff の区別）を組み込みます。

11-3. ロールベースのアクセス制御と RLS Policy

【学習目標】

  • ロール（admin / staff）の概念を理解する
  • RLS Policy でデータアクセスを制御できる

【前提知識】

  • 11-2 で認証ができていること
  • 10-6 で RLS の概要を知っていること

【概念解説】

訪看アプリのように、「役職によって見られるデータが違う」アプリを作る時に必要なのが、ロール管理とRLS Policy です。

ロール（Role）とは

ユーザーに付ける「役職」のようなもの。

  • admin（管理者）：全データを見られる、設定変更できる
  • staff（職員）：自分のデータだけ見られる
  • viewer（閲覧者）：見るだけ、編集不可

訪看アプリでは admin と staff の2つを使い分けています。

ロールはどこに保存する？

ロール情報は、Supabase の「profiles」のようなテーブルに保存します。

profiles テーブル：
- id（ユーザー識別子）
- name（氏名）
- role（'admin' or 'staff'）
- approved（承認済みかどうか）

これを、ユーザーが登録するタイミングで作成します。

RLS Policy で実際の制御

10-6 で軽く触れた RLS（Row Level Security）。これで「誰がどのデータを見られるか」を制御します。

訪看アプリの例：

-- visits テーブル（訪問記録）の RLS

-- 1. staff は自分のレコードだけ閲覧可
CREATE POLICY "staff_view_own_visits" ON visits
FOR SELECT
USING (staff_id = auth.uid());

-- 2. admin は全レコード閲覧可
CREATE POLICY "admin_view_all_visits" ON visits
FOR SELECT
USING (
  EXISTS (
    SELECT 1 FROM profiles
    WHERE profiles.id = auth.uid()
    AND profiles.role = 'admin'
  )
);

「staff は自分のレコードだけ、admin は全部」という制御を、SQL で書きます。これが RLS Policy。

僕が実際に詰まったポイント

僕は訪看アプリで admin / staff のロール管理を実装する時、何度かハマりました。

実際にあったやり取り：

僕：「ログインしたら『承認待ち』って表示されて、自分の管理者画面に
       行けないんだけど」

Code：「最初の登録でプロフィールレコードが既に作られていたため、
     2回目の登録が『2人目』と認識されてしまいました。

     Supabaseで直接ロールを管理者に変更します：

     UPDATE profiles SET role = 'admin'
     WHERE id = (
       SELECT id FROM auth.users
       ORDER BY created_at DESC
       LIMIT 1
     );

     これを Supabase の SQL Editor で実行してください」

このように、ロール管理は実装後にも修正がいるので、Code と SQL での対話が頻繁になります。

最初の admin をどう作るか

ロール管理を組み込んだ時、「最初の admin は誰？」という問題があります。アプリ上で「admin として登録する」機能を作ると、誰でも admin になれてしまう。

解決策：

  1. 最初のユーザーを SQL で手動で admin に昇格

    • 僕の方式
    • Supabase の SQL Editor で直接 UPDATE

  2. CLAUDE.md に admin のメールアドレスを記載

    • 認証時に「このメールアドレスなら admin」と判定

  3. アプリ起動時の初期化処理で admin を設定

    • 初回起動だけ特殊扱い

僕の方式が一番シンプル。最初は手動で SQL を1回叩けばOKです。

【ハンズオン手順】

▼ Supabase 側でやること（profiles テーブル作成）

  1. Supabase の SQL Editor を開く
  2. Code に「profiles テーブルを作る SQL を作って」と依頼
  3. 出てきた SQL を貼り付けて実行

▼ Code 側でやること（プロフィール作成の自動化）

  1. Code に次のように依頼
新規ユーザー登録時に、profiles テーブルにレコードを自動で
作成する仕組みを実装してください。
デフォルトロールは staff、approved は false にしてください。
  1. Code がトリガー（DB の自動処理）を提案
  2. SQL を実行

▼ Supabase 側でやること（自分を admin に昇格）

  1. SQL Editor で次の SQL を実行（自分の登録メールに合わせて）
UPDATE profiles
SET role = 'admin', approved = true
WHERE id = (
  SELECT id FROM auth.users
  WHERE email = '自分のメール'
);

▼ Code 側でやること（RLS Policy 設定）

  1. Code に次のように依頼
visits テーブルに対して、以下の RLS Policy を設定してください：
- staff は自分のレコードだけ閲覧・編集可
- admin は全レコード閲覧・編集可

Plan として SQL を提示してください。
  1. Plan を確認して OK
  2. SQL を Supabase で実行

▼ 動作確認

  1. staff アカウントでログイン → 自分のレコードしか見えない
  2. admin アカウントでログイン → 全レコードが見える

▼ スクショ伴走のチェックポイント

  • profiles テーブルが作られた状態
  • SQL を実行した直後の画面
  • staff・admin それぞれでログインした時の表示の違い

【つまずきポイント】

  • RLS Policy は強力だが、設定ミスで「何も見えない」状態になることがある。設定後の動作確認は必須
  • 自分を admin にする SQL を実行するタイミングを間違えると、誰も admin がいない状態になる。最初の1ユーザーは確実に admin にする
  • 複数のロールがある時、Policy が多くなるので整理する

【確認問題】

  • 「admin は全データ、staff は自分のデータだけ」を制御する仕組みは何ですか？
  • 最初の admin をどう作るのが現実的ですか？

【次のレッスンへの橋渡し】

ロール管理ができました。次は、ここまでの「開発用」設定を「本番用」に移すレッスンです。

11-4. 本番環境への認証移行

【学習目標】

  • 開発環境と本番環境の違いを理解する
  • 認証設定を本番用に切り替えられる

【前提知識】

  • 11-3 までを完了していること

【概念解説】

開発中は便利のために「ゆるい設定」にしていることがあります。本番（誰でも触れる状態）に出す前に、これらを「厳しい設定」に直す必要があります。

開発時と本番時で違うこと

1. メール確認

  • 開発時：OFF（メール確認不要、登録即ログイン可）
  • 本番時：ON（メール確認しないとログイン不可）

2. パスワード強度

  • 開発時：弱くてもOK（test1234 でも通る）
  • 本番時：強度を要求（記号・大文字・数字を含む等）

3. レート制限

  • 開発時：制限なし
  • 本番時：「同じ IP から10秒に1回まで」など

4. Site URL の設定

  • 開発時：localhost:3000 を許可
  • 本番時：https://your-app.pages.dev を許可

5. メールテンプレート

  • 開発時：Supabase デフォルト
  • 本番時：自分のブランドに合わせたメール文面

移行のチェックリスト

□ メール確認をONに
□ パスワード強度ポリシーを設定
□ Site URL を本番ドメインに変更
□ Redirect URLs を本番ドメインに変更
□ メールテンプレートを日本語化・カスタマイズ
□ レート制限を有効化
□ 環境変数を本番用に更新
□ テストアカウントを削除

これらを1つずつ Code とブラウザと相談しながら進めます。

僕の実例

僕は訪看アプリで、開発から本番に移す時に Code に次のように相談しました。

僕：開発から本番に移すために、Supabase で確認すべき設定を
       チェックリストにして教えて。

Code：以下のチェックリストです。
- メール確認：Authentication > Settings > Enable email confirmations を ON
- Site URL：Authentication > URL Configuration > Site URL を本番ドメインに
- Redirect URLs：同上、本番ドメインを追加
- メールテンプレート：Authentication > Email Templates で日本語に
- レート制限：Project Settings > API > Rate Limits を確認
...

僕はこのチェックリストを上から順にスクショ伴走で確認していきました。

「本番=完璧」を目指さない

本番に出した後でも、設定は変えられます。最初から完璧を目指さなくていい。「最低限のセキュリティだけ守って、まず公開してから磨いていく」のが現実的。

僕も、最初の v2.1 公開時はかなりシンプルな設定で出して、v2.5 までに少しずつ強化していきました。

【ハンズオン手順】

▼ ブラウザ側でやること（チェックリスト作成）

  1. ブラウザに次のように打つ
Supabase で運用している Web アプリを、開発環境から本番環境に
切り替えたいです。チェックすべき設定項目を、優先度順に
リストアップしてください。
  1. ブラウザがチェックリストを返す
  2. メモする

▼ Code 側でやること（順に設定）

  1. チェックリストを Code に渡す
  2. 「1番目から順に設定を進めましょう。最初の項目について教えて」と依頼
  3. Code が手順を提示
  4. Supabase ダッシュボードで設定
  5. 完了したら次の項目へ
  6. 全項目完了

▼ Supabase 側でやること（動作確認）

  1. 一度ログアウトしてから、新しいテストアカウントを作る
  2. 本番設定で問題なく動作するか確認

▼ スクショ伴走のチェックポイント

  • 各設定変更前後のスクショ
  • 本番用に切り替わった設定一覧

【つまずきポイント】

  • Site URL を間違えると、メール内のリンクが localhost のままになる。本番ドメインを正確に
  • メールテンプレートはユーザーの第一印象。日本語化・カスタマイズに少し時間をかける価値あり
  • 環境変数の更新を忘れない。Cloudflare Pages 側でも環境変数を本番値に

【確認問題】

  • 開発時と本番時で設定を変えるべき項目を3つ挙げてください
  • Site URL の設定を間違えるとどんな問題が起きますか？

【次のレッスンへの橋渡し】

認証の本番移行ができました。ここからは、もう1つの大きなテーマ「決済」に進みます。

11-5. Stripe の基本概念

【学習目標】

  • Stripe が何を提供するサービスか理解する
  • 決済の全体像を掴む

【前提知識】

  • 11-4 まで完了していること

【概念解説】

「お金を払って使うアプリ」を作るために必要なのが、決済サービス。代表的なのが Stripe です。

Stripe とは

  • アメリカの決済サービス会社
  • 個人開発者でも使える
  • クレジットカード決済を簡単に組み込める
  • 月額課金（サブスク）も対応
  • 日本でも問題なく使える

なぜ Stripe を選ぶか

決済サービスは他にも PayPay、PayPal、Square などありますが、Stripe が個人開発者に人気なのは：

  1. API が充実している：Code から制御しやすい
  2. ドキュメントが豊富：ブラウザに聞けば詳細な情報が手に入る
  3. テスト環境が充実：本番に出す前に十分テストできる
  4. 個人でも使える：法人不要

Stripe の基本概念

Stripe を使う時に出てくる用語：

1. Product（商品）

  • 売るものの名前と説明
  • 例：「プロプラン」「月額1,000円」

2. Price（価格）

  • 商品の値段
  • 月額・年額・一回払いなどを設定

3. Customer（顧客）

  • 支払いをした人
  • メールアドレスやカード情報を紐付ける

4. Subscription（サブスクリプション）

  • 定期的な支払い
  • 月額・年額の継続課金

5. Checkout（決済画面）

  • ユーザーが決済する画面
  • Stripe が提供してくれる（自分で作る必要なし）

6. Webhook（通知）

  • 「決済が成功した」「サブスクが解約された」などを Stripe からアプリに通知

決済の流れ

1. ユーザーが「プロプランに加入」をクリック
2. アプリが Stripe Checkout のセッションを作成
3. ユーザーが Stripe の決済画面に飛ぶ
4. クレジットカード情報を入力
5. 決済成功
6. Stripe から Webhook でアプリに通知
7. アプリがユーザーのプランを「プロ」に更新

ステップ2、3、4、5、6 のうち、3〜5 は Stripe が全部やってくれます。自分が書くのは2と6だけ。

「テストモード」で安全に練習

Stripe には「テストモード」があって、本番に影響しない仮想決済ができます。

  • テストカード番号（4242 4242 4242 4242）が用意されている
  • このカードで決済すると「成功」のシミュレーションができる
  • 実際にお金は動かない

開発時は徹底的にテストモードを使う。本番に出す時に「ライブモード」に切り替える、という流れ。

【ハンズオン手順】

▼ ブラウザ側でやること（Stripe を調べる）

  1. ブラウザに次のように打つ
私は個人で Web アプリを作っていて、月額課金（サブスク）を
組み込みたいです。Stripe の基本的な使い方と、必要な準備を
初心者にも分かるように教えてください。
  1. ブラウザが概要を返す
  2. メモして、次のレッスンで実装

▼ Stripe 側でやること（アカウント作成、まだの場合）

  1. ブラウザで https://stripe.com にアクセス
  2. アカウント作成
  3. ダッシュボードにアクセス
  4. 「テストモード」になっていることを確認（画面上部にトグルがある）

【つまずきポイント】

  • 「本番モード」で開発しない。必ずテストモードで動作確認してから本番化
  • Stripe アカウントの審査が入ることがある。事業内容を聞かれることがあるが、個人開発でも答えれば通る
  • 日本円対応かを確認。デフォルトは USD なので、JPY 設定にする

【確認問題】

  • Stripe のテストモードは何のためにありますか？
  • 決済の流れの中で、Stripe が肩代わりしてくれるのはどのステップですか？

【次のレッスンへの橋渡し】

Stripe の基本が見えました。次は、実際にテストモードで決済を組み込んでみます。

11-6. テストモードでの Stripe 組み込み

【学習目標】

  • Stripe Checkout を使った決済画面を組み込める
  • テストカードでの動作確認ができる

【前提知識】

  • 11-5 で Stripe の概念を理解していること

【概念解説】

Stripe を組み込む最もシンプルな方法が、Stripe Checkout を使う方法。

Stripe Checkout は「Stripe が提供している決済画面」のこと。自分で決済画面を作る必要がなく、ユーザーを Stripe の画面に飛ばすだけで決済が完結します。

実装の流れ

1. Stripe で Product と Price を作る
2. Code でアプリに「プロプランに加入」ボタンを実装
3. ボタンを押すと、Stripe Checkout に飛ばすコードを書く
4. Stripe からの戻り URL を設定
5. Webhook で決済成功を受け取って、ユーザーのプランを更新
6. テストカードで動作確認

これも、Code に Plan モードで頼めば順に進めてくれます。

API キーの管理

Stripe には2種類の API キーがあります。

  • Publishable key：公開してOK（フロントエンドで使う）
  • Secret key：絶対公開しない（バックエンドで使う）

これらを混同しないこと。

サブスクリプションを実装する

「月額1,000円のプロプラン」を実装する場合：

1. Stripe で Product を作る：「プロプラン」
2. Stripe で Price を作る：「月額1,000円」「JPY」「Recurring」
3. アプリの「プロプランに加入」ボタンに、Price ID を紐付け
4. ボタンを押すと Stripe Checkout に飛ぶ
5. 決済成功すると、Webhook が呼ばれる
6. Webhook 内で、ユーザーの profiles テーブルの plan を 'pro' に更新

テストカード

Stripe のテストモードで使えるカード：

  • 成功：4242 4242 4242 4242、有効期限は将来の日付、CVCは任意の3桁
  • 失敗：4000 0000 0000 0002（カード拒否）
  • 認証要求：4000 0027 6000 3184（3Dセキュア）

これらで挙動を確認できます。

【ハンズオン手順】

▼ Stripe 側でやること（Product と Price 作成）

  1. Stripe ダッシュボードで「Products」を開く
  2. 「Add product」をクリック
  3. 商品名（例：「プロプラン」）
  4. 価格情報を設定（月額1,000円、JPY、Recurring）
  5. 作成
  6. Price ID（price_xxx のような形式）をコピー

▼ Code 側でやること（決済組み込み）

  1. Code に次のように依頼（Plan モード）
Stripe を使って、プロプラン（月額1,000円）の決済機能を
追加したいです。

- Stripe Checkout を使う
- 決済成功すると、profiles テーブルの plan を 'pro' に更新
- Webhook で決済通知を受け取る

Publishable key：[キー]
Price ID：[ID]

実装の Plan を提示してください。
  1. Code が Plan を提示
  2. 確認して OK
  3. Code がフロントエンドとバックエンドのコードを実装

▼ 動作確認

  1. アプリで「プロプランに加入」ボタンをクリック
  2. Stripe Checkout に飛ぶ
  3. テストカード（4242 4242 4242 4242）で決済
  4. 成功画面が出る
  5. アプリに戻ると、自分の plan が pro に更新されている

▼ スクショ伴走のチェックポイント

  • Stripe で Product を作った画面
  • アプリの「プロプランに加入」ボタン
  • Stripe Checkout 画面
  • 決済成功後の戻り画面
  • profiles テーブルで plan が更新されている画面

【つまずきポイント】

  • Webhook の設定を忘れると、決済成功してもアプリ側で反映されない
  • Webhook の URL は外部からアクセス可能でないとダメ。Cloudflare Pages 上のエンドポイントを指定する
  • 本番モードに切り替える時、Webhook の URL も切り替える必要がある
  • テストカードを本番モードで使わない。本番では本物のカードでテストすることになる

【確認問題】

  • Stripe Checkout のメリットは何ですか？
  • テストモードで成功するテストカード番号は何ですか？

【次のレッスンへの橋渡し】

テストモードで決済を動かせました。最後のレッスンで、これを本番モードに切り替える話をします。

11-7. 本番モード移行と注意点

【学習目標】

  • Stripe の本番モード移行手順を把握する
  • 移行時の注意点を理解する

【前提知識】

  • 11-6 でテストモードの決済が動いていること

【概念解説】

テストモードで動作確認できたら、いよいよ本番モードに切り替えて、実際にお金を受け取れる状態にします。

本番モード移行のチェックリスト

□ Stripe アカウントの本番モード有効化（事業情報の登録）
□ 銀行口座の登録（売上の振込先）
□ Publishable key を本番用に切り替え
□ Secret key を本番用に切り替え
□ Webhook の URL を本番用に切り替え
□ Webhook のシークレットを本番用に切り替え
□ Product と Price を本番モードでも作成（テストとは別)
□ ライブモードでのテスト決済（少額で実際にお金が動く）
□ 利用規約・プライバシーポリシーの掲示
□ 法令確認（特定商取引法、消費税）

これを上から順に潰していきます。

Stripe アカウントの本番モード有効化

Stripe にサインアップしただけでは、本番モードでお金を受け取れません。事業情報の登録が必要です。

  • 個人事業主として登録
  • 法人として登録
  • どちらでも可

登録する情報：

  • 氏名・住所
  • 電話番号
  • 銀行口座
  • 事業内容（簡単な説明でOK）
  • 月間予想売上

法令周りの注意

日本で決済を組み込む時、いくつか法令的な注意点があります。

  1. 特定商取引法：通信販売事業者の表記が必要
  2. 消費税：売上が一定額を超えると課税事業者
  3. 個人情報保護法：プライバシーポリシーの公開が必要

これらは個人開発者にも適用される場合があるので、ブラウザや専門家に確認しながら進めるのが安全。

ライブモードでのテストはどうする？

本番モードに切り替えた後、「ちゃんと動くか」を確認するのが難しい。テストカードが使えないから。

僕が訪看アプリ（将来 Stripe を組み込む計画）でやろうとしている方法：

  • 自分のカードで最低額（100円とか）の決済をしてみる
  • 成功したら、Stripe ダッシュボードで返金処理

これで「本物のお金が動く流れ」を最低限のコストで確認できます。

「本番に出す前に必ずブラウザで相談」

本番モード移行の各ステップで、不安があれば必ずブラウザで相談する。

ブラウザに：
- 「Stripe の本番モード移行で、初心者がよくミスする点は？」
- 「日本で個人開発者が決済を組み込む時に、法的に必要な準備は？」
- 「特定商取引法の表記、Web アプリでは何を書けばいい？」

こういう質問をブラウザに投げて、答えを参考にしながら進める。Code は実装支援、ブラウザは法務・運用相談、という役割分担。

僕からのメッセージ

僕は現時点では訪看アプリで決済を実装していませんが、将来 Stripe を組み込む計画を持っています。「お金を取る、ということは責任も発生する」というのが、僕の感覚。「だからこそ、ブラウザでしっかり相談しながら進める」と考えています。

【ハンズオン手順】

▼ ブラウザ側でやること（本番移行のリスク確認）

  1. ブラウザに次のように打つ
個人開発者が、Web アプリに月額課金を組み込んで本番運用する
時の、法的・実務的な注意点をリストアップしてください。
特定商取引法、消費税、個人情報保護法の観点から。
  1. ブラウザがリスクと対応策を返す
  2. 各項目を理解して、自分のアプリに当てはまるものを整理

▼ Stripe 側でやること（本番モード準備）

  1. Stripe ダッシュボードで「Activate Account」または「事業情報の登録」を開始
  2. 必要な情報を入力
  3. 審査を待つ（数営業日）

▼ Code 側でやること（コード切り替え）

  1. Code に次のように依頼
Stripe をテストモードから本番モードに切り替えます。

新しい本番用 Publishable key：[キー]
新しい本番用 Secret key：[キー]
新しい本番用 Webhook シークレット：[シークレット]

環境変数を更新してください。
  1. Code が環境変数を本番用に切り替え
  2. デプロイ

▼ 動作確認

  1. 自分のカードで最少額の決済をテスト
  2. 動けば成功
  3. Stripe ダッシュボードで返金処理

▼ スクショ伴走のチェックポイント

  • Stripe の本番モード有効化の画面
  • 本番モードでの最初の決済画面
  • 返金処理の画面

【つまずきポイント】

  • Stripe アカウントの本番化に時間がかかることがある。早めに準備
  • 本番用キーをテスト用と混同しない。両方を明確に区別
  • 法令周りは「ブラウザに全部聞く」で済まさない。重要なところは専門家に確認

【確認問題】

  • Stripe の本番モード移行で、最初に必要な準備は何ですか？
  • 本番モードで動作確認するためのコツは何ですか？

【次のレッスンへの橋渡し】

第11章はこれで完了です。認証と決済、Web アプリの「本格運用」に必要な要素を組み込めるようになりました。

次の第12章は、本書最後の章。「ハーネス」という、Code をさらに高度に使いこなすための上位制御層の概念に進みます。

← 第10章
第12章 →