Stripe連携!Difyで始める会員課金入門
学習ポイント
- データの永続性を確保するためのデータベース(DB)の基礎とリレーションの仕組み
- Stripeのサンドボックス環境を利用した0円固定プランの課金実装手順
- Boltを活用した認証画面の作成とログインセッション管理の重要性
本日のゴール
アジェンダ
ウォームアップ(前回のおさらい)と今日のゴールを説明(5分)
データベースを開発・管理する上で必要な知識を押さえよう(10分)
実際にプロンプトを書いてみて、認証をつけてみよう(15分)
認証をつけたアプリケーションに月額課金を付与してみよう(15分)
認証を付与したアプリケーションの動作を確認してみよう(15分)
ウォームアップと今日のゴールの説明
本ウェビナー第4回では、前回までに作成したチャットアプリに「認証」「課金(Stripe)」「データベース連携」を実装し、Difyに“ユーザー名付き”で利用ログを残せる状態を完成させる。ノーコード寄りの手法でも、非エンジニアが実務レベルへ到達できる点に最大の価値がある。到達目標は三つ。第一に、プロンプトを書く前提としてデータベースの基本を押さえること。第二に、Stripeを最小構成で連携し、0円の月額プランを用いて月額課金の枠組みを体験すること。第三に、認証込みのDBでユーザー名をDifyへ渡し、利用をユーザー単位で管理できるようにすることだ。これにより「誰が・いつ・どれだけ使ったか」を可視化でき、月額や従量など現実的な課金設計の根拠が得られる。すなわち、MVPから収益化へ踏み出すための要となる回である。
設計面の勘所は「認証の後付けは極めて難しい」という一点に尽きる。最初のプロンプトで“認証を作る”と宣言し、必要なら一度設計を整理してゼロターンから組み直す方が、結果として早く、品質も安定する。実装では、既存の「YouTube URL+Note記事相談チャット」にログイン/ログアウトやゲスト表示の整理、メール認証、ユーザー単位の会話保存を追加し、UIのヘッダー・メッセージエリア・入力部に認証導線を組み込む。StripeはSandboxでアカウントを用意し、商品カタログに0円の月額固定プランを作成するだけでよい。Boltが実務の九割を自動化してくれるため、要はStripe操作に慣れることが肝心だ。進め方は、前回プロンプトの復習→認証設計の注入→DBスキーマ紐付け→Stripe連携→ユーザー名のDify伝搬→ログ確認という流れ。ここを越えれば、非エンジニアでも“できる人”の領域に踏み込める。
前回の作成したプロンプト
# 目的
テーマまたは YouTube URL から Note 用の記事草案を生成するチャットアプリを実装する。
Dify API(サーバ側プロキシ経由)でストリーミングで対話生成する。
# 画面構成
ヘッダー:
「Note記事制作ツール」+サブコピー「テーマまたはYouTube URLから記事を生成」。
モード選択ボタン:
横並びで以下の色で構成する
「キーワードから自動生成」= エメラルド
「YouTubeから自動生成」= グレー
メッセージエリア:
初回メッセージ送信後、永続的なチャットUIに遷移します。
入力フィールドと送信ボタンは画面下部に固定表示され、継続的な入力ができるようにする。
メッセージ入力ボタン:
選択モードに応じて文言を動的変更。
「キーワードから記事を生成」ボタン。
メッセージ表示:
ユーザーメッセージは右寄せのバブル、アシスタントメッセージは左寄せのバブルで表示します。
アシスタントメッセージにMarkdownが含まれる場合はレンダリングし、平文はそのまま表示します。
サイドバーと会話管理:
固定された左サイドバーを実装します。
上部: 「+ 新しい記事を作成」ボタンを配置します。
中央: 会話履歴をローカルストレージで表示します。履歴がない場合は「まだ会話履歴がありません」と表示します。
下部: 「ゲストユーザー」「オンライン」と歯車アイコンを含むユーザーカードを配置します。
確認アクションにおけるクイック返信機能:
アシスタントメッセージに「『はい』と入力してください」または「「はい」と入力してください」という確認メッセージが含まれる場合、「はい」のクイック返信バッジを表示します。
このバッジをクリックするか、「はい」と入力して送信すると、同一のconversation_idで継続メッセージを送信します。
チャットデータ:
一意のユーザーID(chat_user_id)を管理し、存在しない場合はuser_{timestamp}形式で生成します。
会話リスト(chat_conversations)をlocalStorageに保存し、更新があるたびに保存します。
新しい会話はリストの先頭に追加され、最初のメッセージの先頭50文字からタイトルを生成します。
Difyからの初回応答受信時、一時IDは URL/ストアの主キーとして 維持し、
Dify の conversation_id は difyConversationId として同レコードに保存する。
DifyAPI連携について:
localStorage と state に以下を保持:
userId(初回生成・以後固定)
conversationId(1ターン目の応答から取得)
## 4) 送信先・ヘッダ・認証
URL:https://dev-app.myuuu.co.jp/v1/chat-messages
APP_TOKEN="app-HPuaBLnKSlTCfY0gbVZ1VZqC"# 目的
テーマまたは YouTube URL から Note 用の記事草案を生成するチャットアプリを実装する。
Dify API(サーバ側プロキシ経由)でストリーミングで対話生成する。
# 画面構成
ヘッダー:
「Note記事制作ツール」+サブコピー「テーマまたはYouTube URLから記事を生成」。
モード選択ボタン:
横並びで以下の色で構成する
「キーワードから自動生成」= エメラルド
「YouTubeから自動生成」= グレー
メッセージエリア:
初回メッセージ送信後、永続的なチャットUIに遷移します。
入力フィールドと送信ボタンは画面下部に固定表示され、継続的な入力ができるようにする。
メッセージ入力ボタン:
選択モードに応じて文言を動的変更。
「キーワードから記事を生成」ボタン。
メッセージ表示:
ユーザーメッセージは右寄せのバブル、アシスタントメッセージは左寄せのバブルで表示します。
アシスタントメッセージにMarkdownが含まれる場合はレンダリングし、平文はそのまま表示します。
サイドバーと会話管理:
固定された左サイドバーを実装します。
上部: 「+ 新しい記事を作成」ボタンを配置します。
中央: 会話履歴をローカルストレージで表示します。履歴がない場合は「まだ会話履歴がありません」と表示します。
下部: 「ゲストユーザー」「オンライン」と歯車アイコンを含むユーザーカードを配置します。
確認アクションにおけるクイック返信機能:
アシスタントメッセージに「『はい』と入力してください」または「「はい」と入力してください」という確認メッセージが含まれる場合、「はい」のクイック返信バッジを表示します。
このバッジをクリックするか、「はい」と入力して送信すると、同一のconversation_idで継続メッセージを送信します。
データ保持要件:
一意のユーザーID(chat_user_id)を管理し、存在しない場合はuser_{timestamp}形式で生成。
会話リスト(chat_conversations)を更新があるたびに保存します。
新しい会話はリストの先頭に追加され、最初のメッセージの先頭50文字からタイトルを生成します。
Difyからの初回応答受信時、一時IDは URL/ストアの主キーとして 維持し、
Dify の conversation_id は difyConversationId として同レコードに保存する。
DifyAPI連携について:
localStorage と state に以下を保持:
userId(初回生成・以後固定)
conversationId(1ターン目の応答から取得)
## 4) 送信先・ヘッダ・認証
URL:https://dev-app.myuuu.co.jp/v1/chat-messages
APP_TOKEN="app-HPuaBLnKSlTCfY0gbVZ1VZqC"
HTTPヘッダ:
Authorization: Bearer <APP_TOKEN>(必須)
Content-Type: application/json
Accept: text/event-stream
---
## 5) マルチターン送信ルール(最重要)
1ターン目:response_mode: **"streaming"** で呼び出し、返却JSONの conversation_id を取得して保持。
2ターン目以降:毎回 同じ user と conversation_id を指定。inputs は毎回必須(空でも {} を送る)。
ファイル:フロントでテキスト抽出→ inputs.document_text に貼る、または別APIにアップロード→参照情報を inputs に含める。
response_mode: "streaming" + Accept: text/event-stream で逐次受信。
HTTPヘッダ:
Authorization: Bearer <APP_TOKEN>(必須)
Content-Type: application/json
Accept: text/event-stream
---
## 5) マルチターン送信ルール(最重要)
1ターン目:response_mode: **"streaming"** で呼び出し、返却JSONの conversation_id を取得して保持。
2ターン目以降:毎回 同じ user と conversation_id を指定。inputs は毎回必須(空でも {} を送る)。
ファイル:フロントでテキスト抽出→ inputs.document_text に貼る、または別APIにアップロード→参照情報を inputs に含める。
response_mode: "streaming" + Accept: text/event-stream で逐次受信。Stripeの準備
サンドボックス環境へログインしている前提で、
商品カタログを選択。
月額0円の固定プランで設定します。
データベースを理解する上で必要な知識を押さえよう
https://auth-chat-app-databa-j77h.bolt.host/
データベースは、アプリの大事な情報を安全に“永続化”し、いつでも取り出せるようにする基盤です。ローカルストレージは更新や履歴消去で消えるため、重要データはDBに置きます。構造は表(テーブル)=行(レコード)×列(カラム)で、各行を一意に識別する主キー(ID)が必須。さらにユーザー1人に複数スレッド、スレッドに複数メッセージがぶら下がる「1対多」のリレーションを外部キーで結びます。認証はメール+パスワード(ハッシュ化)を保存し、照合後にセッションで利用者を識別します。認証状態の保持場所は設計の難所ですが、多くはライブラリに従います。本講では最小構成として、users/threads/messagesの3テーブルとメール認証を実装し、現実のチャット運用に耐えるDB設計を体験します。
実際にプロンプトを書いてみて、認証をつけてみよう(15分)
プロンプト解説
完成図
# 目的
テーマまたは YouTube URL から Note 用の記事草案を生成するチャットアプリを実装する。
対話生成ロジックはDify APIで実装する。
# 画面構成
認証画面:
メールアドレスとパスワードを入力する認証画面からログインした場合に、
以下に記載しているチャット機能ページへ遷移する。
ユーザー登録時に、メールアドレスの存在を確認し、
ユーザー名はメールアドレスとしてアプリの処理を作成してください。
ヘッダー:
「Note記事制作ツール」+サブコピー「テーマまたはYouTube URLから記事を生成」。
モード選択ボタン:
横並びで以下の色で構成する
「キーワードから自動生成」= エメラルド
「YouTubeから自動生成」= グレー
メッセージエリア:
初回メッセージ送信後、永続的なチャットUIに遷移します。
入力フィールドと送信ボタンは画面下部に固定表示され、継続的な入力ができるようにする。
メッセージ入力ボタン:
選択モードに応じて文言を動的変更。
「キーワードから記事を生成」ボタン。
メッセージ表示:
ユーザーメッセージは右寄せのバブル、アシスタントメッセージは左寄せのバブルで表示します。
アシスタントメッセージにMarkdownが含まれる場合はレンダリングし、平文はそのまま表示します。
サイドバーと会話管理:
固定された左サイドバーを実装します。
上部: 「+ 新しい記事を作成」ボタンを配置します。
中央: ユーザー単位で会話履歴を表示します。履歴がない場合は「まだ会話履歴がありません」と表示します。
下部: 「ユーザー名称」、歯車アイコンを含む設定アイコン及びログアウトボタンを配置します。
確認アクションにおけるクイック返信機能:
アシスタントメッセージに「『はい』と入力してください」または「「はい」と入力してください」という確認メッセージが含まれる場合、「はい」のクイック返信バッジを表示します。
このバッジをクリックするか、「はい」と入力して送信すると、同一のconversation_idで継続メッセージを送信します。
チャットデータ:
メールアドレス(user_email)をIDとして、ID・会話履歴単位でデータを保持します。
Difyからの初回応答受信時、一時IDは URLもしくはキーワードをPrimary Keyとして保持し、
Dify の conversation_id は difyConversationId として同レコードに保存する。
## 4) 送信先・ヘッダ・認証
DBに以下を保持:
userId(初回生成・以後固定)
conversationId(1ターン目の応答から取得)
URL:https://dev-app.myuuu.co.jp/v1/chat-messages
APP_TOKEN="app-HPuaBLnKSlTCfY0gbVZ1VZqC"
HTTPヘッダ:
Authorization: Bearer <APP_TOKEN>(必須)
Content-Type: application/json
Accept: text/event-stream
---
## 5) マルチターン送信ルール
1ターン目:認証メールアドレスをユーザー名として、返却JSONの conversation_id を取得して保持。
2ターン目以降:毎回 同じ user と conversation_id を指定。inputs は毎回必須(空でも {} を送る)。
response_mode: "streaming"
Accept: text/event-streamhttps://bolt.new/~/sb1-2qyq4tsz
認証をつけたアプリケーションに月額課金を付与してみよう(15分)
本説明は、認証付きWebサイトにおけるBoltとStripe連携の手順を要点化したもの。まず認証はBolt側に仕組みが用意されており設定は容易。決済連携は管理画面の「Stripe」ボタンから開始し、案内に従ってプライベートAPIキー(秘密鍵)を入力、事前に登録しておいた商品カタログを選択して「決定」で連携完了。設定後は画面に購読プラン(購入ボタン)が表示され、押下でStripeの遷移画面(Checkout等)へ移動。決済が通過すると対象機能が自動で解放され、認証+課金の運用フローが成立する。なお動作確認にはクレジットカードが必要なため、実決済は本手順では割愛している。
https://bolt.new/~/sb1-ednqoyoz
認証を付与したアプリケーションの動作を確認してみよう(15分)
本デモでは認証付きアプリの動作確認手順を解説。まずログインし、キーワードとYouTube情報を入力。ユーザー名はメールアドレスで一元管理され、ログアウト→別アカウントで再ログインしても、ユーザーごとに認証状態とデータが正しく切り替わることを確認。今回はデモのためメール確認を省略し自由登録を許可。実運用ではメール検証(リンク認証等)やGoogle認証の追加が必要。さらにメールアドレスを主キーとして会話履歴をID×ユーザー単位で紐付け、他アカウントで見えないことを検証。セキュリティ面では重複チェック、強固なパスワード、レート制限、セッション有効期限とログアウト処理の実装が前提。