部門での試験導入はうまくいきました。紙の申請書がアプリになり、月20時間の手作業が消えた。役員会でも評価された。そこで「全社に広げよう」と号令をかけた瞬間、情報システム部門から連絡が来ます。「その前に、統制の設計を出してください」。
ここで多くの企業が止まります。止まる理由は、統制の設計が難しいからではありません。何を統制すべきかの一覧を誰も持っていないからです。ツールの機能表を眺めても、そこには「SSO対応」としか書いておらず、自社の規程のどこに当てはめるべきかは書かれていません。
この記事では、Lovableを数百人から数千人規模の組織へ展開するときに設計すべき論点を、2026年9月1日時点の公式ドキュメントにもとづいて整理します。扱うのはアプリ内部の実装ではなく、組織側のガバナンスです。
部門導入と全社展開は、同じツールを配る作業に見えて、管理すべき対象がまったく違います。部門では「誰が何を作ったか」を人が覚えていられますが、全社では覚えていられません。
具体的には、3つの前提が崩れます。第一に、作った本人が保守し続けるという前提。異動と退職があるからです。第二に、扱うデータの機微性が低いという前提。部門をまたげば顧客情報や人事情報に近づきます。第三に、誰が使っているか把握できているという前提。招待が連鎖すれば追えなくなります。
したがって全社展開で設計すべきは、この3つの前提を人ではなく仕組みで置き換えることです。ID管理、安全性の点検、そして棚卸しの3点に集約されます。
「野良アプリを作るな」という通達は効きません。作った本人に悪意がないからです。悪意がなくても構造的に生まれる、という理解から始める必要があります。
典型的な経路はこうです。ある担当者が自分の業務を効率化するアプリを作ります。便利なので同僚に共有します。同僚がさらに他部署へ広げます。半年後、その担当者が異動します。この時点で、アプリは業務に組み込まれているのに、中身を説明できる人が組織内にいません。
従来のシャドーITは「情シスが知らないSaaSの契約」でしたが、これは「情シスが知らない自社製アプリの稼働」です。後者のほうが厄介なのは、ベンダーに問い合わせても解決しないからです。責任は組織の内側にあります。
そして障害が起きるのは、たいてい繁忙期です。復旧できる人がいない状態で業務が止まったとき、経営が問うのは「なぜ許可したのか」ではなく「なぜ把握していなかったのか」です。統制の目的は禁止ではなく、把握可能な状態を保つことにあります。
統制の出発点はIDです。誰がワークスペースに存在し、誰が退職時に確実に消えるか。ここが既存のID基盤に載っていなければ、他の統制はすべて砂上の楼閣になります。
2026年9月1日時点の公式料金ページによれば、SSOはBusinessプラン以上の機能です。FreeプランとProプランにはSSO、ロールベースアクセス、チームワークスペースのいずれもありません。個人が自分のメールアドレスで登録している状態が続くということです。各プランに含まれる機能の詳細はプラン一覧のドキュメントで確認できます。
Enterpriseのドキュメントによれば、SSOはOIDCとSAML 2.0の両方に対応し、Okta、Auth0、Microsoft Entra IDに向けたガイドが用意されています。既存のID基盤がこのいずれかであれば、接続の技術的な障壁は低いといえます。
ここで実務上の判断が生じます。全社展開を前提にするなら、評価の段階からBusiness以上で試すべきだということです。Proで数十人が使い始めてから移行すると、プロジェクトの引き継ぎとアカウントの整理が同時に発生します。
SSOだけでは、退職者のアカウントは自動では消えません。ログインできなくなるだけで、ワークスペース上のメンバーとしては残ります。これを解決するのがSCIMによる自動プロビジョニングです。
公式ドキュメントによれば、SCIMプロビジョニングはEnterprise限定で、Okta、Microsoft Entra ID、SCIM 2.0準拠のサービスに対応し、グループとロールのマッピング、JIT（ジャストインタイム）プロビジョニングの制御が可能です。監査ログもEnterprise限定で、約13週間（およそ90日）保持され、JSONL形式でエクスポートできます。SIEMとの連携は専任チーム経由とされています。
監査ログの保持期間は、社内規程と突き合わせるべき数字です。ログの保存を1年と定めている企業であれば、13週間を超える分は自社側でエクスポートして保管する運用が必要になります。この一点を見落とすと、監査の場で指摘されます。
Enterpriseではさらに、公開や招待を行える人の制限、放置されたアプリの自動退役といった機能が提供されます。前者は「誰でも外部公開できる」状態を塞ぎ、後者は棚卸しの一部を自動化します。
統制のもうひとつの柱が、生成されたアプリ自体の安全性です。ここは2025年から2026年にかけて、Lovable側の機能が大きく変わった領域なので、古い情報で判断しないよう注意が必要です。実際、2025年5月に公開されたCVE-2025-48757は、生成されたサイトの行レベルセキュリティ（RLS）ポリシーが不十分で、認証されていない攻撃者が任意のテーブルを読み書きできる可能性を指摘したものでした（CVSS 3.1 基本値9.3・深刻度Critical、対象は2025年4月15日までのLovable）。ただしNVDの記載には、各利用者が自身のアプリのデータ保護に責任を負うという理由でベンダーがこれを争っている旨も併記されています。現在の自動スキャン機能は、この論点への実装上の回答として読むことができます。更新の履歴は公式チェンジログで追えます。
公式ドキュメントによれば、公開ダイアログを開くとバックグラウンドでBasic Scanが自動実行されます。内容は設定と依存関係の検査で、行レベルセキュリティ（RLS）ポリシーのリンティングやデータベースの設定ミス、パッケージの脆弱性が対象です。一般的なRLSとデータベースアクセスの問題については、条件を満たす検出結果をLovableが自動修正できるとされています。
より踏み込んだ検査がDeep Scanです。これはエージェント型のコードレビューで、アクセス制御の欠落、シークレットの漏洩、安全でない入力処理などを検査します。Deep Scanは自動実行されず、セキュリティビュー、セキュリティセンター、または公開ダイアログから手動で起動します。公式ドキュメントによれば、手動実行するBasic ScanとDeep Scanはいずれも無料で、クレジットを消費しません。
ただし、これで人の点検が不要になるわけではありません。自動検査が見るのは既知のパターンであり、「この業務データをこの範囲の人に見せてよいか」という業務判断は含まれません。公開前チェックリストは依然として必要です。何を確認すべきかの出発点はアプリのセキュリティに関する実践ガイドと公開手順のドキュメントに整理されています。
プロジェクトが数十を超えると、個別のスキャン結果を追うのは現実的ではありません。ここで使うのがセキュリティセンターです。
公式ドキュメントによれば、セキュリティセンターはBusinessプランとEnterpriseプランで利用でき、アクセスできるのはワークスペースの管理者とオーナーに限られます。ワークスペース内の全プロジェクトのセキュリティ状態を一覧し、エラー・警告・情報のレベルで分類して表示します。依存関係の脆弱性を監視するサプライチェーンセキュリティのビュー、全プロジェクトのシークレットを一元表示するビュー（秘密の値そのものは表示されない）も含まれます。
統制の観点でとくに重要なのが、各プロジェクトの最終スキャン日時が表示され、スキャンが未実施のプロジェクトを検出できる点です。「点検していないアプリが何本あるか」を数値で言えるかどうかが、監査対応の質を分けます。CSV形式でのエクスポートにも対応しています。
Enterpriseではさらに、Deep Scanを週次または月次で自動実行するスケジュール設定が可能です。対象は全プロジェクトか公開プロジェクトのみかを選べます。スケジュール実行の場合は、実行のたびにプロジェクトごとに1クレジットを消費するとされているため、対象範囲は費用と合わせて決めてください。クレジットの消費と枯渇時の挙動は公式ドキュメントに明記されています。
機能で統制できるのはここまでです。残りは業務側のルールになります。そして実際の事故の多くは、機能の不足ではなくルールの不在から起きます。
定義の軸は3つです。扱うデータの機微性、失敗したときの影響範囲、そして保守の担い手が決まっているか。この3軸で領域を切ると、多くの企業では安全圏をかなり広く取れます。
| 区分 | 具体例 | 必要な統制 |
|---|---|---|
| 自由に作ってよい | 部門内の申請・点検記録、Excel台帳の置き換え、社内向け集計ダッシュボード | 公開前のBasic Scanと保守担当の登録のみ |
| 条件付きで許可 | 顧客情報を扱う社内ツール、複数部門が使う業務アプリ、外部公開する申込フォーム | Deep Scanの実施、権限設計のレビュー、公開承認者の設定 |
| 許可しない | 会計・給与など基幹の中核、決済処理そのもの、法令上の保存義務を負う記録の唯一の保管先 | 従来型の開発プロセスへ回す |
この表で運用の成否を分けるのは、中段の「条件付き」です。条件を書いたまま承認フローを用意しないと、現場は条件を無視するか、あるいは萎縮して何も作らなくなります。どちらも失敗です。承認者を誰にするか、承認にかかる日数の目安はどれくらいか、までを決めて初めてルールとして機能します。
全社展開の審査で必ず問われるのが、業務データがどこへ行くのかという論点です。ここはプランによって前提が異なり、運用の工夫では埋められません。
公式ドキュメントによれば、2026年9月9日以降、FreeプランとProプランの顧客データ（プロンプト、コード、ファイル、生成出力、利用データ）はLovableのAIモデルの学習に利用される可能性があります。利用者はアカウント設定の「AI model training」から個別にオプトアウトできます。一方、BusinessプランとEnterpriseプランのワークスペースデータは契約にもとづき既定で学習対象外です。アプリのエンドユーザーのデータ、アカウント・請求情報は学習対象外とされています。
数百人規模で「各自でオプトアウト設定をしてください」という運用は成立しません。設定漏れが1件でもあれば統制は崩れますし、それを監査で証明する手段もありません。全社展開ではBusiness以上を前提にすべき最大の理由がここにあります。
契約面の根拠資料としては、データ処理契約（DPA）、プライバシーポリシー、セキュリティページ、トラストセンターがあります。公式ドキュメントによれば、SOC 2 Type II、ISO 27001:2022、GDPR対応が示されています。データの所在についても、Enterpriseでは GitHub Enterprise Cloud のリージョン指定により、リポジトリのデータとWebhookのトラフィックを指定リージョン内に留める構成が可能とされ、GitHub Enterprise Server の自社ホストにも対応するとされています。
Enterpriseではさらに、機密データの検知と送信前の制御（記録・確認・ブロックの3モード）が提供されます。プロンプトに実データを貼ってしまう事故を、規程ではなく機能で防ぐ手段です。認証・準拠状況の一次情報はトラストセンターのドキュメントとEnterpriseの窓口から確認してください。
統制の最後のピースが、時間の経過に耐える仕組みです。導入直後は誰もが丁寧に運用しますが、1年後に効くのは仕組みだけです。
登録すべき項目は4つで足ります。アプリ名と用途、扱うデータの区分、保守担当者、そして最終点検日です。専用のツールは要りません。既存のIT資産管理台帳に列を足すのが最も定着します。新しい管理簿を作ると、それ自体が更新されなくなるからです。
棚卸しの頻度は、半期に1回を基本とし、人事異動の直後に臨時で回すのが現実的です。異動は保守担当が空席になる唯一の契機だからです。セキュリティセンターの最終スキャン日時と、ワークスペースの利用状況を突き合わせれば、使われていないアプリと点検されていないアプリを機械的に抽出できます。
そして退役のルールを先に決めてください。「3か月アクセスがなく、保守担当が不在のアプリは停止する」といった基準です。Enterpriseの放置アプリ自動退役はこれを機能で支えますが、基準そのものは自社で決める必要があります。
ガバナンスの議論では、統制の利点だけが並べられがちです。しかし統制には確実にコストがあり、それを認めない設計は現場で無視されます。
| 統制施策 | 得られるもの | 副作用・コスト |
|---|---|---|
| SSO・SCIMの導入 | 入退社時の権限が自動で整う | Business以上またはEnterprise契約が前提になる |
| 公開権限の制限 | 意図しない外部公開を防げる | 承認待ちが発生し、試行の速度が落ちる |
| Deep Scanの定期実行 | 点検の網羅性が数値で示せる | Enterpriseではプロジェクトごとに1クレジット消費 |
| 作ってよい業務の限定 | 重大な事故の芽を摘める | 厳しすぎると現場が使わなくなる |
| 棚卸しの定例化 | 放置アプリを検出できる | 運用工数が継続的に発生する |
この表で最も注意すべきは、上から2行目と4行目です。承認と制限を厚くしすぎると、Lovableを導入した意味である「見積もりの前に動くものを出せる速さ」が失われます。統制の目的は速度を殺すことではなく、速度を維持したまま把握可能にすることだと、設計の各所で確認してください。
いきなり全社に配ると、統制の設計が追いつかないまま利用者だけが増えます。3段階に分けるのが現実的です。
第1段階は、1部門・10名程度での実運用です。ここでの目的は効果測定ではなく、ルールの原案を書くことです。実際に作ってみて初めて、どの判断が承認を要するかが分かります。第2段階は、3〜5部門への拡大とBusinessプランへの移行です。SSOを接続し、セキュリティセンターで全プロジェクトを可視化できる状態を作ります。第3段階が全社展開で、ここでSCIM、監査ログ、公開権限の制限、定期スキャンを含むEnterpriseの統制が必要になります。
各段階で「次に進む条件」を決めておくと、議論が感情論になりません。たとえば第2段階へ進む条件を「棚卸し台帳が3か月連続で更新されていること」とすれば、運用が回っていないまま拡大することを防げます。
全社展開の設計、情報システム部門向けの説明資料、そして日本円での法人契約に関するご相談は、株式会社100のLovable公式パートナーページで承っています。
まず稼働しているアプリと扱っているデータを棚卸ししてください。禁止から入ると地下化して把握できなくなります。実態を把握したうえで、業務データを扱っているものから優先してワークスペースへ移す進め方が安全です。
人手で全プロジェクトを見る前提だと回りません。セキュリティセンターの最終スキャン日時で未点検を抽出し、公開権限の制限で外部公開だけを承認制にする、といった形で人が見る対象を絞ってください。全数を見るのではなく、リスクの高い部分だけを人が見る設計にします。大きな変更を実装前に検討させるPlan modeを標準運用にすると、レビュー対象そのものが減ります。
社内規程の保存期間によります。1年保存が要件であれば、定期的にエクスポートして自社側で保管する運用を設計してください。この作業を誰がいつ実施するかを決めていないと、監査時に不備として指摘されます。
技術的には可能ですが、社内利用とは審査の水準が変わります。外部公開するアプリはDeep Scanの実施と権限設計のレビューを必須とし、公開の承認者を明示してください。認証していない訪問者に何が見えるかの確認は必ず人が行ってください。
守られないルールは、たいてい承認の待ち時間が読めないことが原因です。承認者と標準的な所要日数を明示し、自由に作ってよい領域を広く取ってください。全件承認制にすると、現場は承認を回避する方向に動きます。
扱っているデータの区分、権限設計、外部公開の有無、最終スキャン日時、そして依存しているシークレットの一覧です。セキュリティセンターのシークレット一覧とサプライチェーンのビューで、後半3項目は機械的に確認できます。
統制の設計とは別に、定着の設計が必要です。IPAが2026年7月に公表した国内企業のDX・AI活用動向でも、AI導入は広がる一方で業務効率化から価値創出への発展が課題とされています。作れる状態にすることと使われる状態にすることは別の仕事です。
Lovableの全社展開で設計すべきは、ID管理・安全性の点検・棚卸しの3点です。IDはSSO（Business以上）とSCIM・監査ログ（Enterprise）で情報システム部門の統制下に置き、安全性は公開前のBasic Scanと必要に応じたDeep Scan、そしてセキュリティセンターによる全体監視で担保します。棚卸しは既存のIT資産台帳に4項目を足し、半期と異動直後に回します。
データの扱いだけは運用で埋められません。2026年9月9日以降、Free・Proのデータは既定で学習利用の対象になりうる一方、Business・Enterpriseのワークスペースデータは契約で既定除外です。数百人規模で個人の設定に依存する運用は成立しないため、全社展開ではBusiness以上が前提になります。
そして忘れてはならないのは、統制を厚くしすぎれば導入の目的そのものが失われるということです。自由に作ってよい領域を広く取り、リスクの高い部分だけを人が見る。この配分の設計が、全社展開の成否を分けます。
Lovableの全体像はLovableとは？できること・料金・使い方を日本公式パートナーが徹底解説を、導入設計のご相談は株式会社100の問い合わせ窓口をご利用ください。