「予約の受付や、社内の申請を扱うアプリをAIで作れた。次は、お客様や社員に使ってもらいたい」。Lovableなどを使うと、画面からデータ保存まで短い時間で形にできます。公開を考える段階では、動くことに加えて、誰の情報を誰に渡すかを確かめたいところです。
株式会社MintSparkの堤です。情報処理安全確保支援士として私が重視するのは、利用者を入れ替えたとき、見える情報と使える機能が、決めた範囲に切り替わるかです。架空の会員向け予約アプリで、公開前の点検を考えてみます。
ログインの確認と、データを渡す範囲の確認を分ける
ログインは、利用者が誰かを確かめる仕組みです。それに続いて、「その人は、どの予約を読めるか」「変更や削除もできるか」を決めます。前者を認証、後者を認可と呼びます。Supabaseの公式説明も、この二つを分けて示しています。
例えば、会員Aさんが自分の予約を表示できたら、次は会員Bさんのアカウントへ切り替えます。BさんにはBさんの予約が表示され、Aさんの予約へのアクセスは拒否される、というところまで確認します。
画面で管理ボタンを隠す処理と、サーバー側で操作を許可する処理も、それぞれ確認します。データを返す窓口であるAPIにも、利用者と操作に応じた制御を持たせます。
公開前に、4種類の利用者で「期待する動き」を決める
予約アプリなら、次のような表を先に作れます。以下はMintSparkが作成した架空アプリの設計例です。○は許可、×はアクセスを拒否することを表します。管理者は予約業務を担当する人という想定です。
| 利用者 | 公開のお知らせ | Aさんの予約を閲覧 | Bさんの予約を閲覧 | 予約の一括出力 |
|---|---|---|---|---|
| 未ログイン | ○ | × | × | × |
| 会員A | ○ | ○ | × | × |
| 会員B | ○ | × | ○ | × |
| 予約管理者 | ○ | ○ | ○ | ○ |
この表なら、経営者や現場担当も「管理者に一括出力は必要か」「予約変更は本人が行うのか」と話し合えます。私たちは、ここを開発者と業務担当者の共通の確認表にすることを勧めます。仕様が分かる自社の立場を活かし、必要な動作を狙って確かめられるからです。
データベースと添付ファイルまで、表と照らし合わせる
Supabaseを使う場合、データベースには「どの操作を許すか」という権限と、「どの行のデータを扱えるか」というRLS（行単位のアクセス制御）があります。公式のAPI保護ガイドは、この二つを組み合わせる構成を説明しています。担当者には「会員本人の予約に絞る条件は、どこに設定していますか」と聞くと、確認する場所が具体的になります。
予約データに添付した書類、一覧を表示する機能、一括出力を処理する機能も、同じ表に沿って確かめます。管理用の秘密キーはサーバー側で管理し、ブラウザーへ渡す情報と分けます。公開用キーと管理用キーの使い分けも、実装担当者と確認しておきます。AIの要約機能などを組み込む場合は、API料金の異常と認証情報の管理も、公開前に担当を決めておきたいところですね。
Lovableのセキュリティ機能では、データベースのアクセス設定や依存ライブラリの脆弱性などを調べるスキャンが提供されています。その結果を読み、上の権限表と組み合わせて、アプリ固有の使い方まで点検します。
架空データで点検し、公開判断に使える記録を残す
確認用の環境にA・B・管理者のテストアカウントと架空の予約を用意し、表の組み合わせを試します。ログイン状態を切り替え、画面の表示と、データを取得・変更する処理の結果を照合します。拒否する操作では、対象データがそのまま保たれていることも記録します。
点検の記録は、確認した版、利用者、操作、期待結果、実際の結果、対応担当を一組にします。機能を追加したときも同じ表で確認すると、公開判断と、その後の改修に使えます。
MintSparkの初回30分の相談では、アプリの用途と扱う情報、利用者の種類から、公開前に確認する対象と範囲を整理します。詳しい調査や改修は、対象と作業内容を確認して別途お見積もりします。
初回30分無料・オンライン。お申し込み後、2営業日以内にご連絡し、メールで日程を調整します。フォームには「会員向けの予約アプリを公開したい」など、用途からお聞かせください。
公式情報確認日：2026年11月2日。権限表はMintSpark作成の架空の設計例です。