Lovableで社内申請アプリを作る前に｜権限表・RLS・公開範囲の確認手順

Lovable社内申請の権限設計ガイドのイメージ — 記事内容を表すイメージ図です。製品の操作画面ではありません。

情報確認日：2026年10月14日（本文で引用した公式資料を再確認）。

社内申請アプリは、入力画面と承認ボタンがあれば完成するわけではありません。申請者が他人の申請を読めたり、自分で承認状態を変えられたりすれば、業務の前提が崩れます。

この記事では、Lovableで試作する前に用意する権限表と、公開前の確認手順を整理します。公式情報にもとづく設計ガイドであり、掲載する申請アプリは説明用の想定例です。実機テスト済みの実装ではありません。

画面より先に、誰が何をできるかを決める

例えば備品購入申請なら、申請者、承認者、管理者の役割を分けます。部署全体の申請を誰でも見られる設計が必要かどうかも、業務側で決めます。

操作	申請者	承認者	管理者
自分の申請を作成	可	可	業務ルールに従う
提出前の申請を編集	自分のみ	自分のみ	原則、代理編集しない
提出後の申請を閲覧	自分のみ	担当範囲のみ	必要な範囲のみ
承認・却下	不可	担当範囲のみ	別途権限を定める
役割の変更	不可	不可	指定担当者のみ

これは権限モデルの例です。管理者に無条件の全操作を与える必要はありません。代理操作を認めるなら、対象と記録方法まで決めてください。

状態の変更も仕様にする

申請は「下書き→提出済み→承認済み／却下」のように状態を分けます。提出後の金額変更を認めるのか、承認者が自分の申請を承認できるのかを明記します。

Lovableへの依頼では、権限表と一緒に次の条件を伝えます。

備品購入申請の試作品を架空データで作成してください。
画面を隠すだけでなく、保存側でも操作権限を確認してください。
申請者IDと部署IDは、利用者が入力した値を信用せず、認証情報から判断します。
承認操作は担当承認者だけに許可し、本人の申請は承認できない仕様にします。
まずデータ項目、状態遷移、各操作の権限を表にして提示してください。

指示文だけで実装の正しさは保証されません。生成後に、どこで権限を確認しているかを調べます。

RLSとサーバー側の認可を両方確認する

Lovableの公式資料は、データベースの行ごとのアクセスを制御するRLSと、サーバー処理の権限確認を扱っています。[1] RLSでは「自分の申請だけ読める」といった条件を確認します。

一方、サーバー処理が強い権限で動く場合には、RLSだけで目的の制限を実現できるとは限りません。承認APIが、呼び出した人の役割、担当部署、対象申請を確認しているかも点検します。

公式のセキュリティスキャンは確認の補助になりますが、すべての安全性を保証するものではありません。[1] 特に「自分の申請を承認できない」などの業務条件は、仕様に対応するテストが必要です。

2つの利用者で、読めない・変えられないことを確認する

架空の申請者A・Bと承認者を用意し、テスト環境で確認します。

試す操作	期待する結果
BがAの申請IDを使って取得	内容を取得できない
Aが承認状態の変更を要求	拒否される
別部署の承認者が承認	拒否される
提出後に金額を変更	決めた再申請ルールに従う
ログアウト後に再取得	保護対象を取得できない

自分が管理する試作品で、許可したテストアカウントだけを使います。画面からボタンが消えていることに加え、保存側で処理を拒否できることを確認してください。

編集プロジェクトと公開アプリは別のアクセス設定

Lovableでは、編集画面のプロジェクトアクセスと、公開URLのWebsite accessは独立しています。[2] プロジェクトを限定共有しても、公開アプリが自動で社内限定になるわけではありません。

公式資料では、Free／Proでも招待した人だけが閲覧できる「Invite only」を選べる一方、ワークスペースのメンバーやグループ単位で閲覧者を指定する設定はBusiness／Enterpriseの条件として案内されています。[2] 契約時点の条件を確認し、公開設定、アプリ内の認証、データの認可を別々に点検します。

APIキーはSecretsへ保管し、ブラウザーに渡さない処理にします。[1] 公開後は、権限変更、退職者のアクセス停止、認証やデータ構造を変えた後の再確認も運用に含めます。

AIGNALの実務見解

申請アプリの完成条件は「正しい人が操作でき、対象外の人は操作できないこと」です。権限表とテスト結果をセットで残すと、機能追加のたびに同じ基準で確認できます。