Lovableで作った、それでデータが漏洩したら誰の責任なのか?

プロダクトマネージャーが社内ダッシュボードを必要としているとします。チケットを申請してエンジニアリングチームが対応するまで四半期も待つ代わりに、Lovableを開き、欲しいものを平易な英語で説明し、会社のGoogle Workspaceに接続すれば、その日の午後には動くアプリが出来上がります。Driveからデータを読み込み、いくつかのスプレッドシートを取得し、週次サマリーをメールで送信する——それだけの仕組みです。動作します。みんな満足です。

半年後、セキュリティレビュアーや規制当局が問いかけるまで、誰もその重要な問いを口にしません。そのアプリが触れるデータの扱いについて、誰が責任を負うのか?

答えは、コードを生成したプラットフォームではありません。それを導入した企業です。本記事では、「AIで作ったから」が抗弁にならない理由、AI製アプリで具体的に何が問題になるのか、そして怒りをぶつけられる前に可視性を確保する方法について解説します。

「AI製アプリ」とは実際何を指すのか

Lovable、Base44、Bolt.new、Cursorをはじめとする新しいカテゴリのツールが増え続けており、人々は自然言語のプロンプトから実際に動くWebアプリケーションを構築・デプロイできるようになっています。これらはしばしば「バイブコーディング」プラットフォームと呼ばれます。その魅力は明らかです。開発者でなくても、以前はチームが必要だったものを作り出すことができ、しかもわずか数時間で実現できます。

これらのアプリはおもちゃではありません。実際のユーザーに向けてデプロイされ、Google Workspace、Salesforce、社内データベースといった実際の企業システムに、通常のOAuth認可を通じて日常的に接続します。データの視点から見れば、プロンプトによって午後のうちに作られたアプリと、エンジニアリングチームが何か月もかけて作ったアプリは同一に見えます。どちらもアクセストークンを保持し、そのトークンが許可する範囲を読み取ることができます。

この対称性こそが問題の核心です。AIビルダーを魅力的にしているそのスピードは、誰もそのデータの扱いをレビューすることなく、アプリが機密データに到達してしまうスピードでもあるのです。

AIで作ることは、安全であることと同じではない

ここは正確かつ公平に述べておく価値があります。LovableやBase44で作られたアプリが本質的に安全でないわけではありません。これらのプラットフォームは十分に妥当なアプリケーションを生成することができますし、実際に多くはそうなっています。リスクは、AIが悪いコードを書くことではありません。リスクはガバナンスにあり、それは3つの予測可能な形で現れます。

導入者はコードをほとんど読まない。 バイブコーディングの価値提案全体は、読む必要がないという点にあります。そのため、アプリをリリースした本人が、データがどのように保存されているか、機密フィールドをログに記録しているか、情報をどこに送信しているか、何をどれだけの期間保持しているかを説明できないことがよくあります。責任を負う当事者が、自らが責任を負う対象について最も把握していないのです。

アクセス範囲は広く、かつ見えない。 AIビルダーは、デモを動作させるために必要なスコープを要求しますが、「動作させる」ことはしばしば広範な読み取りアクセスを意味します。1つのフォルダしか読む必要がなかった社内ダッシュボードが、Drive全体への読み取りアクセスを保持している場合があります。この付与は通常のOAuth同意画面を通じて行われたため、誰のセキュリティレーダーにも決して映らず——定義上、これはシャドーITです。

文書化されたデータ取り扱いポリシーが存在しない。 手作りの本番システムの保持ポリシーを尋ねれば、通常は答えが返ってきます。同僚が先週の火曜日に生成したアプリの保持ポリシーを尋ねても、記録には何もありません。データ保護法の下では、「どれくらいの期間データを保持しているか分からない」は中立的な回答ではなく——それ自体が指摘事項なのです。

なぜプラットフォームではなく企業が責任を問われるのか

ここが人々を驚かせる部分です。AI製アプリがデータを不適切に扱った場合、法的・規制上の責任は、それを生成したAIビルダーではなく、それを導入した組織に及びます。

これは、AI法制全般を今再構築しつつあるのと同じ責任のシフトです。EUの一般データ保護規則(GDPR)の下では、個人データの処理の目的と手段を決定する主体がデータ管理者であり、管理者が適法性の根拠、データ最小化、保存制限、そしてそれらすべてを証明する義務といった責務を負います。あなたの会社が顧客データを処理するアプリを導入すれば、あなたの会社が管理者です。ビルダープラットフォームは、せいぜい使用したツールに過ぎません。

2026年のより広範な法的状況も同じ方向を示しています。裁判所は、AIシステムを使用する企業をその挙動について責任があるとみなし始めています——米国の*Mobley v. Workday*訴訟は代理理論に基づいて進行し、その後全米規模の集団訴訟としての条件付き認証を勝ち取りました。ドイツでは、OLGハムがAIシステムが顧客に伝える内容についての責任を扱い、一般的な「保証なし」の免責事項だけでは導入企業を単独で保護しないことを示唆しました。EU AI法はこれに加えて導入者固有の義務を重ねており、高リスク用途には重大な罰則が課されます。この変化については、AIエージェントがデータを漏洩した場合の責任の所在に関する概要記事で詳しく取り上げています。

共通するテーマは、AI製アプリを導入することは組織が下した決定であり、法律は決定に責任が伴うものとして扱うということです。AIがコードを書いたという事実は、それを会社のデータに接続することを選んだのが誰かという点を何も変えません。

その盲点を具体的に見る

これらの要素を組み合わせると、特定の、よくある失敗パターンが浮かび上がります。

• 非技術系の従業員がAIビルダーでアプリを作る。
• そのアプリがOAuthを通じてGoogle Workspaceに接続し、広範なスコープが付与される。
• アプリが顧客や従業員の個人データ——連絡先、メール内容、ファイル——に到達する。
• 誰もデータの取り扱いをレビューしておらず、記録上の保持ポリシーもない。
• セキュリティ部門にはそのアプリの棚卸し記録がない。レビューを一度も経ていないためです。

個々のステップはそれぞれ妥当です。しかし、それらが組み合わさると、個人データを処理し、あなたの会社が法的責任を負い、しかもあなたのセキュリティチームがその存在を知らないアプリケーションが生まれます。それこそが、監査人が探る隙間であり、侵害が突く隙間なのです。

この隙間を埋めるには

解決策はAIビルダーを禁止することではありません——その競争はすでに決着がついており、生産性の向上は本物です。解決策は可視性と証拠です。どのAI製アプリが接続されているかを把握し、それぞれが何にアクセスできるかを把握し、それらを統治してきたことを示せるようにすることです。

それこそが8200.devが行っていることです。8200.devは、あなたのGoogle Workspaceに接続されているOAuthアプリを検出し、Lovable、Base44、Bolt.new、Cursorなどをはじめとする、AIビルダー由来のものをアプリ名やリダイレクトホストのシグネチャから、そして未検証で最近作成されたにもかかわらずすでに広範なスコープを保持しているという特徴的なパターンから、フラグを立てます。それぞれについて、ビルダープラットフォーム、付与された正確なスコープ、誰が認可したか、そしてリスクスコアを、他のAIエージェントやOAuthアプリと並んで専用のAI-Built Appsビューで確認できます。

AI製アプリが顧客のPIIに到達できる場合、あるいは文書化された保持ポリシーのないまま広範なアクセスを保持している場合、特定の指摘事項が発生します——こうして、その隙間は監査における驚きではなく、担当者のいるタスクになります。そして、あらゆるAI製アプリはAI Agent Registryに記録できるため、どのコネクタも到達できないものであっても、1つの完全なインベントリに表示されます。こちらで全機能セットをご確認いただけます。

重要なのは、チームの速度を落とすことではありません。規制当局、監査人、あるいは顧客のセキュリティレビューから問いが投げかけられたとき、それに答えられるようにすることです。「AIで作ったので、それはプラットフォームの問題です」——これは抗弁にはなりません——ではなく、「これがそのアプリです。これが正確にアクセスできる範囲です。そして、これが私たちがレビューした証拠です」と言えるようにすることです。レビュアーが今何を期待しているかについてさらに深く知りたい方は、2026年に監査人がAIガバナンスに求めるものをご覧ください。

AIで作ることは速い。しかし、作ったものに対して責任を負うことは選択の余地がありません。この両者を両立させるものはただ一つ——あなたのAI製アプリが実際に何にアクセスできるかを知ることです。

まずは、あなたのWorkspaceにすでに接続されているものを確認することから始めましょう。無料プランで、AI製アプリをマッピングし、そのアクセスをスコアリングし、最初の証拠を生成することができます——プランを見て無料で始める。

*本記事は一般的な情報であり、法的助言ではありません。組織固有の状況に応じたガイダンスについては、資格のある弁護士にご相談ください。*