.png)
「動くけど、危ない」コードが生まれる仕組み
これらの事例から分かるように、問題はAIそのものではなく、AIを使う私たち開発者の「意識」にあります。では、なぜAIの普及と共にリスクが増大しているのでしょうか？
理由1：スピード優先の弊害と「動くコード」の罠
生成AIの第一目標は、プロンプトの指示通りに「正常に動作するコード」を生成することです。開発者がプロンプトで「SQLインジェクション対策を施して」「ユーザー入力は必ずサニタイズして」といった要件を明示的に指示しない限り、脆弱なコードが生成されてしまう可能性があります。
そして生成されたコードやアプリに対して、権限などを考慮した適切なテストが行われていないことがあります。そのため、十分なセキュリティ対策が施されないまま本番環境で稼働しているコードが存在するのです。
理由2：知識がなくても「完成」してしまう危険性
本来であれば数ヶ月、数年かかる学習や経験が必要だったセキュリティの知識がなくても、AIを使えば数時間でサービスをデプロイできてしまいます。その結果、以下のような「典型的な罠」に無自覚にはまってしまうのです。
BaaSの無防備な設定
まず1つ目は、FirebaseやSupabaseといったBaaS（Backend as a Service）のセキュリティルールをレビューせず、安易に全開放した状態で公開してしまうことです。
実際、先ほど例に挙げた女性向けアプリ「Tea」で発生したデータ漏洩の原因は、適切なセキュリティルールが実装されていなかったことです。具体的には、問題のFirebase Storageバケットは「認証」が全く要求されず、さらに「リスト表示の制限」もかけられていませんでした。この設定ミスにより、攻撃者はバケットのURLにアクセスするだけで、そこに保存されている全てのファイル（身分証明書の画像、セルフィーなど）の一覧を簡単に取得できました。
簡単な例を見てみましょう。
問題のあるルール
allow read は get（個別ファイルの取得） と list（ファイル一覧の取得） の両方を許可してしまいます。つまり、ファイル一覧にアクセスし、簡単に全ての写真データを取得できてしまう設定です。
対応後のルール（例）
ファイルの所有者本人だけが、そのファイルを上書き・削除でき、ファイル名を知っていれば閲覧もできるルールです。他のユーザーの写真データにはアクセスできない設定です。
セキュリティルールに関する詳しい仕様はこちらのFirebase公式のセキュリティルールの仕組みを確認すると良いでしょう。
他にもSupabaseでは、RLS（Row Level Security）が無効になっているテーブルがある状態でサービスが公開されているケースがよくある設定ミスのパターンとして見受けられます。
その場合、anon keyやPublishable key（ブラウザの開発者ツールなどを使えば、誰でも簡単に見つけることができます）を使うことでテーブルのデータに簡単にアクセスすることができます。
RLSはテーブル作成方法によって、デフォルトで有効になっているか、無効になっているかが変わる（2025/09時点）のですが、SQL（SQLエディタなど）で直接テーブルを作成した場合はデフォルトでRLSは無効です。そのため、以下のコマンドを実行して手動で有効にする必要があります。この設定を忘れてしまうことで、結果的にRLSが無効の脆弱なテーブルを持つサービスが生まれやすくなっています。
しかし、RLSが無効の状態でTable Editorにアクセスすると、下記のようにかなり強調して警告ラベルが表示されます。
さらに、定期的にsupabase/splinterというSupabaseのプロジェクトで使われるPostgreSQLの一般的なスキーマの問題を特定するための静的解析ツールの結果がメールで送られてくるのでRLSの未設定に関してはかなりの対策を取っています。
ここで重要なのは、「特定の製品やBaaSが問題」ということではなく、「仕様の理解と適切な設定が必須である」ということです。
代表例として、初心者フレンドリーで強力なSDKであるFirebaseやSupabaseを挙げました。サービス側も日々対策をしており、紹介した例も仕様が変われば問題は発生しなくなるかもしれません。しかし、利用するサービスの最新の仕様・挙動を理解し、正しく使うという、ごく当たり前のことを肝に銘じておく必要があります。
他にも参考として 「Cloud Storageでファイルは公開 & 一覧ページは非公開にする権限設定」などの記事も過去にZennに他の方が共有してくださっています。
あらゆる製品を利用する際に「正しく使えているだろうか？」という観点をもつ必要があります。
理由3：個人開発者は攻撃者にとって「格好の標的」
リソースの限られている個人開発者は生成AIをフル活用する方が多いです。また、利用するサービスの制限がなく、使いたいツールを自由に使うことができるという点は個人開発の醍醐味でもあります。
通常、企業が開発するサービスであれば、専門のチームによる脆弱性診断や網羅的なテストが行われます。しかし、リソースが限られている個人開発のアプリでは、そこまで手が回らないのも実情です。
マーク・ザッカーバーグの有名な言葉として「完璧を目指すよりまず終わらせろ」というものがありますが、攻撃者から見れば、対策が手薄な個人開発アプリは、簡単に個人情報を狙える「格好の標的」に他なりません。
例えば、サイトが使用しているテクノロジーを調べるツールなど（Wappalyzerやenthec/webappanalyzer）で、BaaSを使用したサービスをリスト化し、権限が適切に設定されていないか調べることで簡単に標的を見つけることができます。
責任はあなたに。AIが生み出すものへの向き合い方
「大いなる力には大いなる責任が伴う」
この言葉は、まさに生成AIという強力なツールを手にした現代の開発者やバイブコーダーに向けられたものだと私は考えます。AIは、私たちの生産性を飛躍的に高めてくれる魔法の杖です。しかし、その杖を振るう私たちには、生み出したものに対する 安全を確保する「知識」と「責任」が求められています。
本連載の目的は、このバイブコーディングなどの盛り上がりに水を差すことではありません。AIがもたらす素晴らしい恩恵を、誰もが安全に享受できる世界を目指して、共に学んでいくことです。
次回予告
私たちはどう立ち向かえば良いのでしょうか？
第2回では、今回触れたような開発者の知識不足によって生まれやすい「典型的なセキュリティホール」をさらに具体的に徹底解説します。
この連載を最後まで読み終える頃には、典型的なセキュリティホールを把握し、セキュリティ対策に有効なツールを活用することができるようになるでしょう。最後までお読みいただきありがとうございます。
ぜひ、ご意見やご感想などを、SNSでシェアしていただけると嬉しいです。
