Claude Code に Supabase の Security Advisor で確認させてアプリ保護を組み込んでもらった話

Claude Code に Supabase の Security Advisor で確認させてアプリ保護を組み込んでもらった話

Claude Code に Security Advisor での確認を指示し、その前後で Supabase アプリがどう変わるか比べました。指示する前は Claude Code の自動チェックが db lint にとどまり Advisor の警告 4 件が残りましたが、指示すると質問を経て保護が組み込まれ、警告は理由つきの 1 件になりました。
2026.10.22

はじめに

Claude Code に頼めば、Supabase を使ったアプリは短時間で動きます。しかし、そのまま公開してよいと言い切るのは難しいものです。本記事では、家族で共有する買い物リストを題材に、守りたい事項を Claude Code に伝える前後でアプリがどう変わるか比べました。

守りたい事項を「誰が何をできる」の形で伝え、また Security Advisor での確認を頼んだところ、回答に沿った保護がデータベース側に組み込まれました。 ただし、一部問題も残りました。

Supabase とは

Supabase とは、PostgreSQL のデータベースを中心に、認証・ストレージ・データベースから自動で作られる API をまとめて提供するサービスです。ブラウザから API を通じてデータベースへ直接問い合わせる構成を取れるため、データの保護はデータベース側の設定で行います。

Security Advisor とは

Security Advisor は、Supabase のダッシュボードにある、データベースのセキュリティ上の問題を検査する機能です。RLS の設定漏れや、ログインした利用者が呼べる SECURITY DEFINER 関数などを、あらかじめ決められた規則で指摘します。CLI の supabase db advisors からも同じ検査を実行できます。

検証環境

  • Claude Code 2.1.304 (モデル Opus 5.5)
  • Supabase CLI 2.121.0
  • macOS

対象読者

  • Claude Code などの AI で、Supabase を使ったアプリを作り始めた方
  • アプリは動いたものの、公開してよいと言い切れずにいる方
  • 権限の設計を AI に頼む方法に迷っている方

参考

背景

Supabase のアプリでは、ブラウザの画面に publishable キーを埋め込み、データベースへ直接問い合わせます。利用者ごとに読み書きできる範囲は、データベースの RLS (Row Level Security、行単位のアクセス制御) と権限の設定で決まります。

AI に「家族だけで共有」のように頼んでも、家族の範囲・メンバーの外し方・外した人の扱いは確定しません。確定していないルールは AI が勝手に決めるか、あるいは、AI が利用者に質問して決めるような形になります。

今回は、守りたいものをしっかり守るためには AI にどう伝えるのがよいか、また伝えた結果どうなったか、その確認の仕方について検証し、考察します。

検証方法

題材と実行の条件

題材は、家族で共有する買い物リストの Web アプリです。

事前に、作業ディレクトリで supabase init と supabase link を済ませました。.env には、URL と publishable キーだけを置きました。Claude Code は、筆者の環境にあるグローバルの設定・プラグイン・MCP を読み込まないよう、--safe-mode を付けて対話モードで起動しました。許可を求められたときは、利用者として普段どおりに判断しました。

最初に渡した依頼文は次のとおりです。特に保護については書いていません。

Supabase を使って、家族だけで共有して編集できる買い物リストの Web アプリを作ってください。画面は HTML 1 枚で構いません。Supabase プロジェクトはこのディレクトリにリンク済みで、接続情報は .env にあります。データベースへの変更もあなたが反映してください。終わったら、作ったものと確認したことを報告してください。

完成した後、同じセッションを --continue で再開し、守りたい事項とその確認の仕方を伝えました。

公開する前に、次の守りたいことをデータベース側で守れるようにしてください。ブラウザ側の処理には頼らないでください。
- ログインしていない人と、家族のメンバーでない人は、品物を見ることも変えることもできない。
- 家族のメンバーは、品物を見る・追加する・変更する・削除することができる。
- 家族を作った人は、メンバーを外せる。外された人は、その後は品物を見ることも変えることもできない。
変更する前に、守りたいことのうち決めきれない点があれば質問してください。

終わったら、変えたことと確認したことを報告してください。確認では、守りたいことを1つずつ、複数のアカウントで実際に試してください。あわせて Supabase の Security Advisor の指摘を確認し、指摘と対応を報告してください。

筆者による確認

Claude Code の完了報告とは別に、筆者が次の方法で確かめました。

  • 権限のテスト: 立場の異なるテストユーザーで、REST API から読み書きを試しました。判定には、HTTP ステータスではなく操作後のデータの状態を使いました。(※ RLS で対象が 0 件になった更新や削除も、HTTP 200 を返すため)
  • Security Advisor: supabase db advisors を実行しました。

検証結果: 守りたい事項を伝えなかった場合

Claude Code は質問をせずに作業を進め、約 4 分でアプリを完成させました。家族の範囲や外し方は、Claude Code が自分で決めていました。決めたルールでは、招待コードを知っていれば誰でも参加できます。管理者は置かず、他のメンバーを外す操作は誰にもできません。

完了報告では、他のメンバーを外せないことを保護の一つとして説明していました。

- 作成者のなりすまし、品物を別の家族へ移す操作、他のメンバーの名前変更や追い出しも、データベース側で拒否します。

報告どおりの実装で、筆者のテストでも作成者が他のメンバーを外す操作は 0 件で終わりました。

また、完了報告の「自動チェック」は supabase db lint でした。

2. **データベースの自動チェック:** `supabase db lint` では問題が見つかりませんでした。

筆者が Security Advisor を実行すると、WARN が 4 件出ました。いずれも、所有者の権限で動く関数 (SECURITY DEFINER) を、ログインした利用者が API から呼べるという指摘です。WARN の 4 件を抜粋します。

WARN authenticated_security_definer_function_executable | Function `public.create_family(family_name text, member_name text)` can be executed by the `authenticated` role as a `SECURITY DEFINER` function via `/rest/v1/rpc/create_family`. Revoke `EXECUTE` or switch it to `SECURITY INVOKER` if that is not intentional.
WARN authenticated_security_definer_function_executable | Function `public.is_family_member(fid uuid)` can be executed by the `authenticated` role as a `SECURITY DEFINER` function via `/rest/v1/rpc/is_family_member`. Revoke `EXECUTE` or switch it to `SECURITY INVOKER` if that is not intentional.
WARN authenticated_security_definer_function_executable | Function `public.join_family(code text, member_name text)` can be executed by the `authenticated` role as a `SECURITY DEFINER` function via `/rest/v1/rpc/join_family`. Revoke `EXECUTE` or switch it to `SECURITY INVOKER` if that is not intentional.
WARN authenticated_security_definer_function_executable | Function `public.rotate_invite_code(fid uuid)` can be executed by the `authenticated` role as a `SECURITY DEFINER` function via `/rest/v1/rpc/rotate_invite_code`. Revoke `EXECUTE` or switch it to `SECURITY INVOKER` if that is not intentional.

検証結果: 守りたい事項を伝えた場合

変更前の質問

Claude Code は変更の前に、選択肢つきの質問を 3 つ出しました。いずれも、依頼文の守りたい事項だけでは決まらない点です。

Q: 外された人が、前に受け取った招待コードを覚えていた場合、また参加できてよいですか?
  - 作成者が許可するまで不可 (Recommended): 外された人をデータベースに記録し、作成者が解除するまで同じ家族には参加できないようにします。招待コードを知っていても戻れません。
  - 外すと同時にコードを再発行: 外した時点で招待コードを自動で変えます。新しいコードを誰かが渡せば戻れます。
  - 制限しない: 招待コードを知っていれば、また参加できます。
Q: 家族を作った人自身は、外されたり自分で抜けたりできるようにしますか?
  - 作成者は外せず、抜けられない (Recommended): 家族には常に作成者が残ります。作成者を外すことも、作成者が抜けることもデータベースで拒否します。
  - 作成者も抜けられる: 作成者が抜けると、その家族ではメンバーを外せる人がいなくなります。
Q: 作成者以外のメンバーについては、どこまで認めますか?
  - 自分で抜けるのは可、他人は外せない (Recommended): 今の動きと同じです。他のメンバーを外せるのは作成者だけです。
  - 自分で抜けることも不可: メンバーが家族から外れるのは、作成者に外されたときだけになります。

筆者は 3 問とも Recommended の選択肢を選びました。

組み込まれた保護と確認の結果

Claude Code は回答に沿って、作成者だけがメンバーを外せるポリシーと、外した人を記録して再参加を拒否する仕組みをデータベース側に追加しました。Security Advisor の指摘にも対応し、完了報告では次のように説明していました。

守りたいこと 3 つは、すべてデータベース側(RLS、トリガー、関数)だけで守れるようにしました。複数のアカウントで実際に試して 68 項目すべて合格し、Security Advisor の警告は 4 件から 1 件に減りました。残る 1 件は意図して残したもので、理由は後述します。

筆者が実行した Security Advisor の結果も WARN 1 件 (join_family) で、報告と一致しました。筆者の権限のテストは 44 項目で、すべて期待どおりでした。守りたい事項の 3 つ目に当たる結果を、伝える前と並べます。

操作 伝える前 伝えた後
作成者がメンバーを外す 0 件、メンバーは残った 外れた
外された人が、外される前のログインのまま品物を読む - 0 行
外された人が、外される前の招待コードで再び参加する - 拒否

テストを通った後にも残された経路

外した人の記録は、アカウントごとに残ります。

一方、このアプリは誰でも新規登録できます。そこで、外された人が別のアカウントを作り、外される前に知っていた招待コードで参加する場面を試しました。

{"step":"X が S を外す","status":200}
{"step":"別アカウント S2 が外される前のコードで参加 (再発行なし)","status":200,"joined":true,"items":[{"name":"milk"}]}
{"step":"X が S2 を外す","status":200}
{"step":"X が招待コードを再発行","status":200}
{"step":"別アカウント S3 が古いコードで参加 (再発行後)","status":400,"returned":"invalid invite code","joined":false}

招待コードを再発行しないまま外すと、別のアカウントで再び参加でき、品物を読めてしまいました。外した後に再発行すると、古いコードでの参加は拒否されました。

考察

守りたい事項を伝える前も後も、Claude Code は決めたルールのとおりに実装していました。結果を分けたのはルールの中身だと考えています。特に「決めきれない点があれば質問してください」の一文は、利用者が決めていなかった点を、選択肢つきの質問として表に出しました。

Supabase では読み書きの判定がデータベースのポリシーに集まるため、アカウントを変えて読み書きを試せば保護を確かめられます。Security Advisor は、AI の報告とは別の経路で指摘を出すため、確認の手段として有効に感じました。

一方、テストがすべて通っても、別のアカウントでの再参加が残りました。守りたい事項に「外された人は、別のアカウントを作っても戻れない」まで書いていれば、Claude Code が対策を質問や実装に含めたかもしれません。あるいは、1 問目の選択肢にあった「外すと同時にコードを再発行」を選ぶ方法でも、より良い結果が得られたのかもしれません。(※どちらも今回試したわけではないので推測です。)

まとめ

AI に Supabase のアプリを作ってもらうときは、守りたい事項・質問・Security Advisor での確認を指示に含め、公開前には複数のアカウントでのテストを自分でも行うのが良さそうです。AI で Supabase のアプリを作る方にとって本記事が参考になれば幸いです。


Claudeならクラスメソッドにお任せください

クラスメソッドは、Anthropic社とリセラー契約を締結しています。各種製品ガイドから、業種別の活用法、フェーズごとのお悩み解決などサービス支援ページにまとめております。まずはご覧いただき、お気軽にご相談ください。

サービス詳細を見る

この記事をシェアする

AI白書

関連記事