WIREDの記事が伝えているのは、かなりシンプルだけど、かなり怖い話です。
AIを使えば、誰でもあっという間にWebアプリを作れる時代になりました。Lovable、Replit、Base44、Netlifyのようなサービスは、コードが書けない人でも「こんなアプリがほしい」と指示するだけで、Webアプリを組み立ててくれます。いわゆる vibe coding です。
ざっくり言うと、「設計から実装まで、雰囲気でAIに任せてしまう」ような開発スタイルですね。便利さは本物です。正直、ここはめちゃくちゃ面白い。昔なら何日もかかった試作品が、数分でできてしまうわけですから。
でも、その“速さ”が、今回はそのまま“危うさ”にもなっていました。
セキュリティ研究者のDor Zvi氏とRedAccessのチームが、これらのAI開発ツールで作られたWebアプリを調べたところ、5,000件以上がほとんどセキュリティも認証もない状態で公開されていたといいます。
認証というのは、簡単に言えば「その人が入っていい相手かを確認する仕組み」のことです。普通ならログインが必要だったり、権限のある人だけが見られたりします。ところが今回見つかったアプリの中には、URLを知っているだけで見えてしまうものが多かった。
しかも問題は、単に「見えてもいい試作品」レベルではありませんでした。Zvi氏によれば、その約**40%**で機密性の高いデータが露出していたそうです。
たとえば、医療情報、財務データ、企業のプレゼン資料、営業戦略のドキュメント、顧客とチャットボットがやり取りした会話ログなどです。中には、フルネームや連絡先が入った記録まで見えていたケースもあったとのこと。
これはかなり生々しい話です。
単なる「技術的な不備」ではなく、会社の中身がそのまま外に漏れているわけですから。
この問題の本質は、「AIがバグを作る」という話より一段深いところにあります。
もちろん、AIが書いたコードはミスを含みやすいです。これは昔からある「自動化したら便利だけど、雑なものも増える」という話に見えます。
でも今回のケースは、それ以前に**“安全に公開するための最低限の設定”が抜けている**のが大きい。
Zvi氏によると、Lovable、Replit、Base44、Netlifyは、ユーザーが作ったアプリを自分たちのドメイン上でホストできる仕組みを持っています。つまり、研究者はGoogleやBingで検索するだけで、こうしたアプリを大量に見つけられたそうです。
ここがまた厄介で、見つけるのに特別な技術はいらない。検索エンジンで探せるなら、悪意のある人だって当然見つけられるわけです。
WIREDが確認したスクリーンショットには、病院の業務割り当て、広告購入の詳細、会社の市場投入戦略、配送会社の貨物記録、小売企業のチャット履歴、営業・財務情報などが写っていたとのこと。
さらに、一部では管理者権限まで取れてしまい、他の管理者を削除できる可能性まであったそうです。これはもう「見えてしまった」では済まないレベルです。
もちろん、各社は黙ってはいませんでした。
Netlifyはコメントせず、Replit、Lovable、Base44は研究者の指摘に反論しました。
ただし、公開されているアプリが存在したこと自体は否定していないのがポイントです。争点は「それがプラットフォームの欠陥なのか、それともユーザーの設定ミスなのか」という点でした。
ReplitのCEO Amjad Masad氏は、公開アプリはインターネット上でアクセスできて当然であり、公開・非公開はユーザーが選べると説明しました。
Lovableは、露出したデータやフィッシングサイトの報告を重く見て調査中だとしつつ、最終的な設定責任はアプリの作成者にあるとコメント。
Base44の親会社Wixも、アクセス制御や公開設定のツールは提供しており、公開状態になっていたのはユーザーの選択だと主張しました。
このやり取り、個人的にはかなり“今のAI開発あるある”だと思います。
サービス側は「道具はちゃんと用意している」と言う。
一方で現場は「そんな細かい設定まで気が回らない」となる。
そして、その隙間に機密情報が落ちる。いや、落ちるというより、ぽろぽろこぼれ続ける感じです。
ここは少し慎重に読む必要があります。
記事では、RedAccessやWIREDが確認したいくつかの事例について、本当に機密情報だったと完全に証明できたわけではないとも触れています。
たとえば、テスト用のダミーデータや、AIが自動生成した見せかけのデータだった可能性もあるからです。Base44側も、いくつかはテストサイトかAI生成データに見えたと指摘しています。
つまり、「全部が本物の流出」と断定するのは危険です。
ただし、それでも問題が小さくなるわけではありません。なぜなら、実際に利用者へ連絡してデータ露出を知らせたところ、本物の情報漏えいだったケースが複数確認されたからです。研究者に感謝して修正したユーザーもいた、と記事は伝えています。
このあたりはセキュリティの世界ではよくある話で、外から見た時点では「本物かダミーか」がすぐには分からない。でも、見える状態になっていること自体が危険なんです。
悪意のある第三者にとっては、真偽の判定より「取れるかどうか」のほうが大事ですから。
Zvi氏は、この現象を、過去に大問題になった Amazon S3 bucket の公開ミスになぞらえています。
S3 bucketというのは、Amazonのクラウドストレージの入れ物みたいなものです。設定を間違えると、ファイルが丸見えになります。昔、これで大企業が大量の情報を公開してしまったことが何度もありました。
今回もそれに近い、と。
ただし、昔はクラウド設定を間違えたのが原因でしたが、今はAIが“誰でもアプリを作れる”ようにしたことで、セキュリティの弱い人がそのまま本番環境に触れてしまう。ここがかなり違います。
研究者Joel Margolis氏も、まさにこの点を強調しています。
マーケティング担当者のような、もともとエンジニアではない人が「とりあえずサイトを作りたい」と思ってAIツールを使う。すると、AIは「言われた通り」作るけれど、**“安全に作る”ように特別に頼まれていなければ、そこまでは面倒を見ない**。
これはすごく本質的だと思います。AIは気が利く相棒というより、かなり正直な下請けです。言われていないことは、基本的にやらない。
私がこの記事でいちばんゾッとしたのは、単に漏えい件数が多いことではありません。
「会社の正式な開発プロセスを通らずに、誰でも勝手に本番アプリを生み出せてしまう」という点です。
普通の企業なら、アプリを公開する前に、エンジニアやセキュリティ担当が確認します。
でもAIツールがあれば、そうした手順を飛ばして、現場の誰かがその場で公開できてしまう。
Zvi氏が「誰でも会社のどこかでアプリを生成でき、開発サイクルもセキュリティチェックも通らない」と指摘しているのは、まさにそこです。
便利さは生産性を上げます。これは間違いない。
でも、便利すぎるツールは、ときに組織の安全確認をすり抜ける穴にもなります。
AI時代の怖さは、コードを自動生成すること自体よりも、**“作成の敷居を下げすぎることで、公開の重みまで薄めてしまう”**ことにあるのではないかと思います。
この記事は、AI開発ツールを単純に「危険だから使うな」と言っているわけではありません。
むしろ、使い方次第で革命的に便利だが、設定を甘くすると情報漏えいが大量発生する、という現実を突きつけています。
だからこそ大事なのは、
このあたりだと思います。
結局のところ、AIは魔法ではありません。
でも、魔法みたいに簡単に使えるからこそ、人間側の確認責任がむしろ重くなる。
この当たり前の話を、この記事はかなり派手な形で思い出させてくれます。
参考: Thousands of Vibe-Coded Apps Expose Corporate and Personal Data on the Open Web
