AIでつくったアプリを公開する前の確認リスト

小さなアプリでも、公開すれば弱いところを探される

「自分がつくった小さなアプリなんて、わざわざ狙われないだろう」と思うかもしれません。ところが攻撃する側は、インターネットに公開された機器やシステムを探すサービスや自動のプログラム（ボット）を使って、弱いところのある相手を広く探しています。米国のサイバーセキュリティの機関 CISA も、この点に注意を呼びかけています。

相手は、あなたのアプリの存在を前もって知っている必要がありません。隠しておくべき APIキーが見える状態だったり、データベースに誰でも入れる設定だったりすれば、公開した本人が気づかないうちに、情報を抜かれたり、勝手に使われたりすることがあります。

すべてのサイトがいつも攻撃されている、というわけではありません。ただ、インターネットに公開した時点で、誰かに見つかり、弱いところを探される可能性がある、と考えておくのが正確です。

これは AI でつくったアプリに限った話ではありません。ただ、AI のおかげで専門の知識がなくても公開できるようになったぶん、「動いているから大丈夫」と判断しないことが大切になりました。

AIでつくったアプリで、問題になりやすい例

予約の管理アプリで、ほかのお客さんの予約が見えてしまう

小さなお店の予約の管理アプリ。ログインもでき、予約の登録・変更・取り消しも正しく動いています。ところが、予約を取り出す API で「その予約が本人のものか」を確かめていません。すると、URL に入っている予約の番号を書き換えるだけで、ほかの人の予約が見えてしまうことがあります。

ログインの機能があるだけでは、安全にはなりません。「誰がログインしたか」だけでなく、「その人がどの情報を扱ってよいか」を、サーバーやデータベースの側で確かめる必要があります。Web のセキュリティの危険をまとめた OWASP Top 10 の 2025 年版でも、この「アクセスの制御の不備」がいちばん上に挙がっています。

AIチャットのアプリで、利用料が膨らむ

生成AIの API を使ったチャットのアプリを、誰でも使えるように公開した例です。使える回数に上限がなく、しかも APIキーがブラウザの側に埋め込まれている。すると、第三者に API を大量に使われたり、キーを抜き取られて悪用されたりして、思わぬ請求が来ることがあります。

怖いのは、アプリが正しく動いているあいだにも被害が進むことです。キーを守るだけでなく、使う人ごとの回数の制限、サーバーの側での使用量の制御、予算の上限や通知の設定まで確かめます。

お客さんが上げたファイルを、誰でも見られる

お客さんが見積書や写真を上げられるアプリ。画面ではログインした本人にしかファイルが出ません。ところが、ファイルの置き場が「公開」の設定になっていて、ファイルの URL さえ分かれば、ログインしなくても誰でもダウンロードできてしまいます。

画面で隠していても、置き場が公開されていれば意味がありません。たとえば Supabase のストレージでは、公開の設定にした置き場のファイルは、URL を知っている人なら誰でも開けます。人に見せないファイルは、非公開の置き場に入れ、見てよい人を決めておく必要があります。

公開する前に確かめる 7 つのこと

どれも、最低限は自分で確かめられます。ただ、自分で問題を見つけられることと、安全だと言い切れることは別です。それぞれ、専門家に任せたほうがいいところも書きました。優先する順番はアプリによって変わりますが、個人情報やお客さんの情報を扱うなら、1 と 2 は公開前の必須の条件です。

「AIに診断させれば大丈夫」ではないの？

AI による診断は、ぜひ使ってください。ただし、AI が「問題ありません」と答えたことを、安全の証明にはしないでください。

AI のコードレビューは、たとえば次のような問題を見つける助けになります。

• コードにそのまま書かれた秘密の情報
• データベースの危ない公開の設定
• 入力のチェックや、権限の確認が足りないところ
• 古い部品（ライブラリ）にある、知られた弱いところ

一方で、実際に悪用できるかの確認、複雑な業務のルール、いくつもの機能を組み合わせた攻撃の検証には限りがあります。たとえば「予約を取り出す API にはログインの確認があるので安全」と AI が判断しても、実際には別の人の予約を取り出せることがあります。つくったときと同じ AI にレビューさせると、つくったときの思い込みを引きずることもあります。

私なら、次のように頼みます。

AI に指摘されたところを直し、テスト用の環境で実際に確かめる。そのうえで、個人情報やお金を扱うところは、第三者にも見てもらうのがよいと思います。

Lovable の Quick scan・Deep scan や、Bolt の公開前のセキュリティの監査のように、チェックの機能を備えたサービスも増えました。それでも Lovable の公式の資料は、機密の情報や重要な機能を扱うなら、専門家による追加のレビューを検討するよう案内しています。

Claude Code、Cursor、v0、Bolt、Lovable で、気をつけることは違う？

違いはあります。ただ「このツールは危ない、こちらは安全」という単純な比べ方はおすすめしません。使い方と、できあがるアプリの組み立てによって、気をつけるところが変わります。

Claude Code や Cursor のように、エージェントがコードを書き換えていくツールでは、書き換えの副作用にも気をつけます。何が変わったか（差分）とテストの結果を見ることが大切で、Cursor にはエージェントの変更を戻せるチェックポイントがありますが、公式の資料は、それを Git などのバージョン管理の代わりにしないよう案内しています。

v0 は見た目をつくるだけの道具ではなくなり、API やデータベースを使うアプリもつくれます。見た目だけでなく、裏側の処理も確かめる対象です。

いちばん大事なのは「何でつくったか」よりも、「何をつくって、どんな情報を扱うか」です。

Vercel、Cloudflare、Firebase、Supabase の設定の落とし穴

AI でつくったアプリの公開先としてよく使われる 4 つです。公開する前に、次の設定を確かめてください。

Supabase は、AI でつくるアプリでよく使われる組み合わせの一つなので、少しくわしく書きます。

RLS（行ごとに、誰が読み書きできるかを決める仕組み）は、有効にしただけでは安心できません。決まりの中身が正しいとは限らないからです。確かめたいのは「自分のデータは見える」と「ほかの人のデータは見えない」の両方です。

また、毎日の自動のバックアップは有料の Pro プラン以上のもので、データベースのバックアップには、ストレージに置いたファイルそのものは含まれません。無料のプランで使っている場合は、Supabase 自身も勧めているとおり、定期的にデータを書き出して、別の場所に控えを持っておいてください。

公開したあとも、続けたいこと

なかでも大事なのは、問題が起きたときに、誰が気づいて、誰が対応するのかを決めておくことです。止まっても、情報が漏れても、通知を見る人がいなければ動けません。

小さなサービスなら、最初から高度な見張りの仕組みは要りません。ただ、少なくともエラーの通知と、料金の通知の送り先は設定しておきたいところです。

ここまでなら、自分で公開しても大丈夫？

アプリの種類で、3 つの段階に分けて考えるのがよいと思います。

もちろん、単純なアプリだから絶対に安全、というわけではありません。ただ、「不具合が起きても被害が小さく、利用者の大事な情報やお金を扱わない」という条件がそろうほど、自分で公開しやすくなります。

いきなり誰にでも公開するのが不安なら、最初はテストの利用者だけに絞って試すのも手です。ただし、公開を絞ることは、セキュリティの対策の代わりにはなりません。

まとめ

東山紡では、AI でつくったアプリを公開する前の診断をお受けしています。「何を確かめればいいか分からない」「AI には問題ないと言われたけれど不安」という方は、AIでつくったアプリの公開のページもご覧ください。