Claude Code×Supabaseで会員機能とフォームを受託する──RLSと鍵の分け方、MCPの線引き、見積もりの計算例

この記事は、Claude Code×Supabaseで、会員機能やフォームのデータ保存を受託するときの範囲、鍵と権限の決め方、見積もりを扱います。

「ログインできるようにして」は、個人情報を預かる仕事の始まり

「会員だけが見られるページを作りたい。ログインがあれば十分です」

Supabaseを使えば、ログインとデータの保存は短い時間で動きます。
けれど、動いたことと、安全に預かれることは別です。
誰が、どの行のデータを読めるのか。退会したら何を消すのか。そこを決めずに受けると、納品後の責任だけが残ります。

会員機能の受託とは、ログインの画面ではなく「誰がどのデータに触れてよいか」の規則を設計し、検証して渡す仕事である

黒字化の外科医です。Supabaseでの会員機能とフォームの受託を、責任の範囲が見える仕事にする方法を解剖します。

規則の設計を中心に置くべき理由は、三つあります。

第一に、データを守るのは画面ではなく、行単位の規則（RLS）だから。
Supabaseの公式ドキュメントは、公開されるスキーマのすべてのテーブルでRLSを有効にするよう求めています（Supabase公式ドキュメント、2026年11月2日確認）。画面で隠しても、規則がなければデータは読めてしまいます。

第二に、鍵の種類を取り違えると、規則が効かないから。
公開してよい鍵（publishable key）と、サーバーだけで使う鍵（secret key）があります。secret keyはRLSを通らずに全データへ触れられるため、ブラウザに置いてはいけないと公式は明記しています。

第三に、AIに渡す接続も、同じ鍵の問題を持つから。
SupabaseのMCPサーバーは便利なぶん、つなぐ先を間違えると、顧客の会員データにAIが触れることになります。

公式ドキュメントで確かめた、Supabaseの事実

以下は、SupabaseとClaude Codeの公式ドキュメントで確かめた範囲です（2026年11月2日確認）。

• 認証は、パスワード、マジックリンク、ワンタイムパスワード、ソーシャルログイン、SSOなどに対応し、RLSと組み合わせて行単位でアクセスを絞れる
• RLSを有効にして規則がないテーブルは、公開用の鍵からはデータが返らない。規則には `auth.uid()` を使う
• secret keyは、漏れたらすぐに入れ替えるよう案内されている
• MCPサーバーは `https://mcp.supabase.com/mcp`。OAuthで認証し、`read_only=true` で読み取り専用、`project_ref` で1つのプロジェクトに限定できる
• 信頼できない内容に紛れた指示でAIが危険な操作をする「プロンプトインジェクション」の危険が書かれ、本番のプロジェクトには必要なときだけつなぐよう案内している

今すぐ試せる：RLSの規則を洗い出すプロンプト

私はWeb制作会社のエンジニアです。顧客の会員サイトをSupabaseで作ります。
次の要件から、テーブルとRLSの規則の案を作ってください。

【前提】
・会員が登録する情報：〔氏名、メール、会社名 など〕
・会員ができること：〔自分の情報の閲覧と変更、資料のダウンロード など〕
・管理者ができること：〔会員の一覧、問い合わせの確認 など〕
・フォームで受け取る情報と、保存する期間：〔記載〕
・退会したときに消す情報：〔記載〕

1. テーブルの一覧と、各テーブルの項目を出す。
2. テーブルごとに、誰が「読む・作る・変える・消す」をできるかを表で出す。
3. その表を、RLSの規則の案（SQL）にする。

案として出すこと。

会員機能工場：範囲、鍵、見積もりの型

範囲の型（見積書に書く）

【含む】
・テーブル設計とRLSの規則（テーブル〇個まで）
・認証の設定（方式：〔メールとパスワード〕）
・画面：登録、ログイン、マイページ、退会（〇画面）
・フォームの保存と、管理者への通知
・利用者ごとのアクセスの検証と、その記録
・運用手順書（退会、削除依頼、鍵の入れ替え）

【含まない】
・個人情報の取扱いに関する規程やプライバシーポリシーの作成
・Supabaseの利用料（お客様のご契約）

見積もりの計算例

（例：時間単価8,000円、テーブル5個、画面4つ）
要件の聞き取り　　　　　　　　　　　 8時間
テーブル設計とRLSの規則　　　　　　12時間
認証の設定　　　　　　　　　　　　　 6時間
画面の実装　4画面 × 6時間　　　　　24時間
フォームの保存と通知　　　　　　　　 6時間
RLSの検証（利用者ごと）　　　　　　 8時間
運用手順書　　　　　　　　　　　　　 4時間
合計　　　　　　　　　　　　　　　　68時間 × 8,000円 ＝ 544,000円

Claude Codeで画面が速く作れても、RLSの検証の8時間は削りません。ここが、預かる責任の中身だからです。

鍵とMCPの線引き

□ Supabaseのプロジェクトは、お客様の組織で契約する
□ ブラウザに置くのは、publishable keyだけ
□ secret keyは、サーバーの環境変数にだけ置き、リポジトリに書かない
□ MCPは、開発用のプロジェクトに、project_refとread_onlyを付けてつなぐ
□ 本番のプロジェクトには、MCPを常時つながない
□ 納品時に、発行した鍵と招待の一覧を渡し、不要な招待を外す

▶ APIキーの漏洩対策、制作会社は「書かない仕組み」と「漏れたら止める初動」──Git・.envの置き方、シークレットスキャン、鍵の無効化と再発行

個人情報を預かる前に、顧客と決めること

□ 保存する項目、目的、期間と、消す手順
□ 制作会社が本番のデータを見てよい場面と、その記録
□ 漏えいが疑われたときの連絡の順番

会員の情報を預かる仕事は、個人情報の取扱いの委託にあたる場面があります。必ず顧客の同意を得て、契約で範囲を決めてください。
なお私は弁護士ではありません。実務の指針として読み、個別の判断は専門家や公的な窓口に確認してください。

▶ 個人情報の委託と安全管理措置、制作会社は「受ける側」として何を問われるか──委託元の監督に応える体制と、覚書で決める10項目

構造的なリスク

逆説を指摘しておきます。

Supabaseで会員機能が早く作れるほど、顧客は「簡単なものだ」と受け取ります。
けれど、データを預かる期間は、作る期間よりずっと長く続きます。構築費だけで受け、鍵の入れ替えや削除依頼の対応を保守の月額に入れないと、責任だけが無償で残ります。

▶ WordPress会員サイトの見積もり、「ログインできれば完成」で受けると赤字になる──登録・退会・権限・個人情報・問い合わせ対応まで工数で積む型と計算例

よくあるQ&A

Q. 問い合わせフォームも、Supabaseに保存すべきか？

保存しなくてよい情報は、保存しない設計が一番安全です。

Q. Claude CodeにSupabaseのMCPをつないで、本番の不具合を調べたい。

公式も、本番には必要なときだけつなぐよう案内しています。顧客の許可を得て、読み取り専用で、調べた内容を記録に残してください。

Q. RLSの検証は、何をすればよいか？

会員A、会員B、未ログイン、管理者の4つの立場で、読める・読めないを確かめ、表で渡します。

最後に

会員機能の値段は、画面の数ではなく、誰がどのデータに触れてよいかの規則と、その検証で決まります。

RLSと鍵とMCPの線を引き、預かる範囲を契約に書いた会社だけが、速く作れる時代に、会員機能の受託を責任の見える仕事にできるのです。

これまでの記事は、メンバーシップ「黒字化オペ室」でまとめて読めます。月額1,980円、記事2本分の金額です。詳しくはプロフィールから。

#Web制作会社 #Supabase #ClaudeCode #会員サイト #個人情報 #セキュリティ #制作会社経営 #中小企業 #見積もり #受託開発