前回、「エンジニア、もういらなくない？」という記事を書いたところ、
想像以上にたくさんの方に読んでいただけました。ありがとうございます。
記事のきっかけになった友人にも見てもらい、面白かった、という評価をもらえました。
その記事の中で、「AIが作ったアプリで一番怖いのはセキュリティ」という話をちらっとしました。SQLインジェクションという単語も出しましたが、「細かい説明はしません」と逃げたので（笑）、今回はそこをちゃんと書きます。
テーマは、
AIが作ったアプリ、セキュリティの穴は誰が塞ぐ？
そもそも穴があるという前提を忘れてはいけません。
これはAIが作ったものに限らないのですが、穴は絶対にあると思っておいた方がいいです。
これに気付けないとエンジニアはみんな恐れるであろう、Yahoo!ニュースに
「XXXサイト個人情報XX件流出」
と出てしまいます。
攻撃は「外」からだけじゃない
前回、AIだけでアプリを作るのは「家をロボットだけで建てる」のに似ている、という話をしました。今回はその家の防犯編です。
家の防犯というと、外から泥棒が入ってくるイメージが強いですよね。でも実際の事故は、大きく2種類に分かれます。
- 内部から：家の中にいる人（合鍵を持っている人）が起こす事故
- 外部から：外の悪い人が仕掛けてくる攻撃
アプリも同じです。ニュースになる情報漏えいも、派手なハッカーの攻撃だけでなく、「中の人が持ち出した」パターンがかなりあります。
そしてAIにアプリを作らせると、「動くこと」は面倒を見てくれても、この防犯はほとんどノーチェックなことが多いです。
① 内部からの攻撃
内部からの攻撃は大きく2種類あります。
1. DBの直接のぞき見：合鍵を持った人が金庫を開ける
何が起きる？
データベース（DB）には、ユーザーの名前・メールアドレス・住所など、大事な情報がまとめて入っています。
ものによっては、アプリにお金を入れているものもあると思います。
お店でいうと、バックヤードの金庫みたいなものです。
問題は、この金庫を中の人なら誰でも開けられる状態になっていることです。
開発を手伝った人、運用している人、そしてAIで作る場合はAI自身に渡した情報等が、DBに直接つないで「全ユーザーの個人情報一覧」を検索できてしまう。
悪意があれば、それをこっそりコピーして持ち出せます。
なぜ起きる？
AIにアプリを作らせると、開発を楽にするために全部の権限を持った1つのアカウントで何でもできる構成になりがちです。
金庫の合鍵を1本作って、それをスタッフ全員で使い回しているようなものですね。誰がいつ開けたのか、記録も残りません。
どう防ぐ？（AI任せだと抜けやすい所）
- 権限を分ける：人やプログラムごとに「見られる範囲」を絞る。ホールのスタッフはレジまで、金庫は店長だけ、のように
- 記録を残す：誰がいつDBに触ったかのログ（監査ログ）を取る。金庫の前に防犯カメラを置くイメージです
- 個人情報はそのまま置かない：次の「暗号化」につながります
AIは頼めばやってくれます。でも頼まないと、まずやってくれません。「動くかどうか」に権限設計は関係ないからです。
2. 未暗号化：ハガキで送られるあなたの住所
何が起きる？
暗号化されていないデータは、ハガキと同じです。運んでいる途中で誰かに見られたら、中身が丸ごと読めます。
- 通信が未暗号化（httpのまま。暗号化はHTTPSを使用します）：あなたがフォームに入力したパスワードや住所が、ネットワークの途中で盗み見られる
- 保存データが未暗号化：さっきの「金庫」が実は施錠されていない棚で、開けたら個人情報が生のまま並んでいる。DBのファイルが1つ漏れただけで全部読まれます
なぜ起きる？
AIは手元のパソコンや外部のサービスを使い「動く」ことを最優先に作るので、通信はhttpのまま、パスワードもそのまま保存、というコードを平気で出してくることがあります。動作確認としては何の問題もないんですよね。問題ないからこそ、公開するときにも気づかない。
どう防ぐ？（AI任せだと抜けやすい所）
- 通信は必ずhttps（封筒に入れて封をするイメージ）。URLの鍵マークがそれです
- パスワードは「元に戻せない形」で保存（ハッシュ化といいます）。本人にも運営にも元のパスワードが分からない状態にします
- DBの中の大事な情報も暗号化して、ファイルごと盗まれても読めないようにする
最近の定番サービス（SupabaseやVercelなど）を使うと、httpsは自動でやってくれることが多いです。ただ「保存する側」の暗号化やハッシュ化は、コードを見て確認しないと分かりません。ここが「中身を知らないと事故る」ポイントです。
② 外部からの攻撃
細かく分けるとかなりの種類があるのでざっくり紹介します。
3. F5アタック（DoS）：お店に人が押し寄せてパンクする
何が起きる？
サーバは、一度にさばける仕事量が決まっています。10席のお店に1万人が同時に押しかけたら、注文どころか入口すら機能しなくなりますよね。
それをわざとやるのがこの攻撃です。ブラウザの更新キー（F5）を連打するように、大量のリクエストを送りつけてサーバをパンクさせます。プログラムを使えば、1人でも何万回でもリクエストを送れます。サーバが落ちれば、本当のお客さんが誰も使えなくなる。クラウドだと「落ちない代わりに料金が爆発する」パターンもあります。
なぜ起きる？
AIが作るアプリは、来たリクエストを全部まじめに受け付けます。「同じ人が1秒に100回注文してきたら変だぞ」という発想が、コードに入っていないんです。
どう防ぐ？（AI任せだと抜けやすい所）
- 回数制限（レートリミット）：「同じ人からの注文は1分に○回まで」という入場整理をつける
- CDNやWAFを前に置く：お店の前に整理券を配る警備員を立てるイメージ。Cloudflareなどがこれにあたります
- 監視とアラート：アクセスが急増したら通知が来るようにしておく
これらはアプリの「機能」ではなく「守り」なので、AIに「アプリ作って」と頼んだだけでは、まず入ってきません。
4. XSS：誰でも貼れる掲示板に、悪意のある貼り紙を載せられる
何が起きる？
XSS（クロスサイトスクリプティング）は、サイトの中に悪意あるプログラム（スクリプト）を貼り付けられる攻撃です。
町の掲示板を想像してください。誰でも貼り紙ができる掲示板に、悪い人が「見た人の財布から勝手にお金を抜く仕掛け付きの貼り紙」を貼ったとします。以降、その掲示板を見た人は全員被害に遭う。怖いのは、攻撃されるのがサイトの運営者ではなく、見に来たユーザーという点です。ログイン情報を盗まれたり、偽のログイン画面に飛ばされたりします。
なぜ起きる？
コメント欄や投稿欄など「ユーザーが自由に書き込める場所」で、書かれた内容をそのまま画面に表示してしまうのが原因です。文章のつもりで受け取ったものが、実はプログラムだった、ということが起きます。
家の中にこっそり盗聴器を仕掛けられて、被害に遭うのは住人ではなく遊びに来た客、と言ってもいいかもしれません。
どう防ぐ？（AI任せだと抜けやすい所）
- 書き込みは「ただの文字」として表示する（エスケープ処理）。貼り紙をガラスケース越しに見せて、仕掛けが動かないようにするイメージです
- 実は、ReactやNext.jsなどの定番フレームワークは標準でこの守りが効いています。AIの作るアプリが定番構成になりがちなのは、ここでは良い方向に働きます
- ただし抜け道があります。「HTMLをそのまま表示する」特別な書き方（Reactなら
dangerouslySetInnerHTML）を使うと、守りが外れます。AIは「リッチな表示にして」と頼むと、これをさらっと使ってくることがあります。名前に danger と入っていますが、なんの注意もなく使用します。
5. SQLインジェクション：注文票に余計な指示を書き足される
何が起きる？
前回の記事で予告した本命です。
アプリは、検索欄やログイン欄に入力された内容をもとに、DBへの「注文票（SQLという命令文）」を作って渡しています。「『田中』を含むユーザーを探して」みたいな注文ですね。
SQLインジェクションは、この入力欄に、注文票の続きになる文字を書き込む攻撃です。レストランの注文用紙の名前欄に「田中。あと金庫の中身も全部持ってきて」と書くようなもの。注文票を機械的に処理する厨房（DB）は、それを正式な注文として実行してしまいます。結果、全ユーザーの個人情報を抜かれたり、データを全部消されたり、他人としてログインされたりします。
なぜ起きる？
入力された文字を、そのまま注文票に貼り付けて命令文を組み立てているからです。「名前」と「命令」の区別がつかなくなるんですね。
どう防ぐ？（AI任せだと抜けやすい所）
- 注文票を穴埋め式にする（プレースホルダ／プリペアドステートメント）。「名前：＿＿＿」という枠を先に固定しておけば、枠の中に何を書かれても「ただの名前」としてしか扱われません
- ここも実は、定番構成の恩恵があります。SupabaseやPrismaのような仕組み（ORM）を通してDBを使っていれば、基本的には穴埋め式になっています
- 危ないのは、AIが「複雑な検索を高速化したい」ときなどに生のSQLを直接組み立てるコードを出してくる場合です。見た目は普通に動くので、知らないと見過ごします
6. 認可の抜け（IDOR）：会員番号を書き換えたら、他人のロッカーが開いた
何が起きる？
ログインは正しくできています。でも、たとえばマイページのURLが
https://example.com/mypage?user=1001
だったとして、この 1001 を 1002 に書き換えたら他人のマイページが表示された——これが認可の抜け（IDOR）です。ジムの会員証は本物なのに、ロッカーの番号を言えば他人のロッカーも開けてくれる受付、みたいな状態ですね。
なぜ起きる？
「ログインしているか」のチェック（認証）はAIも入れてくれます。でも「その人が、そのデータを見ていい人か」のチェック（認可）は別物で、こちらは画面の動作確認では絶対に気づけません。自分のデータは正しく表示されるからです。実際、AIで作られたアプリの情報漏えいは、派手なハッキングよりこの「認可の抜け」が目立ちます。
どう防ぐ？（AI任せだと抜けやすい所）
- データを返す前に「このデータの持ち主＝今ログインしている本人か」を毎回確認する
- Supabaseなら RLS（行レベルセキュリティ） という「自分の行しか見えなくする」設定がある。ただし自分でオンにしないと効きません。ここが一番の事故ポイントです
- テストのときに「他人のIDを入れてみる」。この一手間だけで見つかる穴です
今回触れなかった攻撃
有名どころでは、他にもこんな攻撃があります。名前だけ記載しておきます。
- CSRF：ログイン中のあなたを騙して、意図しない操作をさせる（定番フレームワークにはだいたい守りが入っています）
- パスワードリスト攻撃：他所で漏れたパスワードの使い回しを狙う（パスワードを使い回している人は絶対やめましょう！）
- フィッシング：偽サイトやメールで人間そのものを騙す
- ゼロデイ／サプライチェーン攻撃：修正前の穴や、アプリが使っている部品（ライブラリ）ごと汚染する
このあたりは、次回以降の「お店の外側の守り」の話とあわせて書きます。
なお、今回の防ぎ方はNext.js＋Supabaseのような定番構成を前提に書いています。
別の構成を使う場合は、その構成での注意点をAIに聞いたり、マニュアルを読んで個別に確認してください。
まとめ：AIは家を建てる。でも、鍵はまだ人間が確認する
6つ見てきましたが、共通点に気づいたでしょうか。
どれも、アプリは普通に動きます。
権限が全開でも、httpのままでも、レートリミットがなくても、認可が抜けていても、動作確認は全部通る。だから作った本人は気づけない。穴が見つかるのは、たいてい事故が起きた後です。
一方で、希望もあります。AIが選ぶ定番構成（Next.js＋Supabaseなど）には、XSSやSQLインジェクションへの守りが最初から組み込まれている部分がかなりあります。つまり今の時代のセキュリティは、「ゼロから防御を書く」ことよりも、
- フレームワークの守りがどこまで効いていて
- どこから先が自分の責任か
の境界線を知っていることが大事になっています。そしてその境界線は、中身をざっくりとでも理解していないと見えません。
他の構成の場合は注意点をAIに聞いたり使用する構成のマニュアルなどを読んで個別に防御策を考えてください。
その確認ができる人が、これからのエンジニアなんだと思います。
最近のAIはパスワードAIに教えないでねと忠告してくれるものもあるので、内部からのリスクは減っています。
アプリ開発したことある方ならWEBサイトなどに登録したときに出てくる謎の文字列を「.env.local」に入れてください、とアナウンスされたことがあると思います。
この仕組みが直接AIにパスワードを連携せずとも作れる仕組みを提供しています。
あと、先ほどのパスワードリスト攻撃への対策として、2段階認証は絶対、絶対入れてください。
パスワードが漏れても、もう1つの鍵（スマホの認証アプリなど）がないと入れないので、被害をかなり防げます。作る側としても、使う側としても、です。
それとフィッシングは年々巧妙になっています。私も2年ほど前、SMSに再配達のメールが届いて、クロネコヤマトさんだと思って開いたことがあります。幸いドメイン（URL）が違うことに気づいて、個人情報を入力せずにすみましたが、本当に身近に潜んでいます。
アプリの穴だけではなく、使うみなさん一人ひとりのセキュリティに関するリテラシーが上がって、AI開発が今後よくなっていくことを願っています。
おまけ：この記事の挿絵をAIに書かせました
実はこの記事の挿絵、有名どころのAI3社（ChatGPT・Claude・Gemini）に同じお願いをして描いてもらいました。
※画像向けじゃないとか言わないでね・・・
やってみて意外だったのですが、画像はまだ「一発でいい感じ」にはならないです。
指示と違うものが混ざったり、日本語の文字が崩れたり。今回は比較的、GeminiのNanobananaがイメージに近いものを出してくれました。
ChatGPT(GPT5.5)
Claude(Opus4.8)
Gemini(NanoBanana2)
Claudeがんばれ・・・
文章のコードと同じで、画像も「AIが作ったものを、私達が見て直す」作業がまだ必要みたいです。
ここまで読んでくれてありがとうございます。
次回は、今回さらっと名前だけ出した「WAF・CDN・レートリミット」あたりの"お店の外側の守り"を、もう少し詳しく書こうと思います。