AIに指示するだけで、動くアプリが手元にできあがる時代になりました。うれしい変化です。ただ、そのアプリをそのまま世に出す前に、いくつか確かめておきたいことがあります。
先に結論をお伝えします。AIで作ったアプリで起きる事故の多くは、いくつかの決まった落とし穴に集約されます。この記事では、その代表的な8点をまとめました。1つずつは短く要約し、くわしく知りたいものは個別の記事へ進めるようにしてあります。ここを一度通して読んでおけば、公開前に「どこを見ればいいか」の地図が手に入ります。
そもそもなぜ「AIで作ったアプリは危険」と言われるのか
AIは、動くコードを書くのは得意です。ただ、そのコードが安全かどうか、なぜそう動くのかまで保証してくれるわけではありません。ここが出発点です。
動くことと、安全に公開できることは別の話です。AIに任せて開発すると、あなたが一度も中身を見ていない部品や設定が、裏側で静かに積み上がっていきます。その中に、外から狙われやすい穴が残っていても、見た目は普通に動くので気づきにくいのです。
こわがらせたいわけではありません。逆です。危ないポイントは数が限られているので、そこだけ知っておけば、大きな事故はかなり防げます。ここから8つを順に見ていきましょう。
落とし穴1：APIキーをクライアント側に置く
まず最初に、これがいちばん影響が大きい落とし穴です。ChatGPTなどのAPIキーは、あなたのアカウントに料金が計上される「財布につながった鍵」です。これをブラウザやスマホアプリといったクライアント側に書くと、実質的に全世界へ公開しているのと同じ状態になります。
なぜなら、ユーザーの手元に届くコードは、知識があれば誰でも中身を覗けるからです。露出したキーは、ネットを巡回するボットに機械的に見つけられます。盗まれると、あなたのカードで大量のAI処理を勝手に走らせられ、身に覚えのない高額な請求につながるおそれがあります。寝ている間にも料金が積み上がる、という事例は世界中で起きています。
対策の一言でいえば、鍵はユーザーから見えないサーバー側に置き、環境変数に隠すことです。くわしい仕組みと直し方はAIで作ったアプリでやりがちなAPIキーの漏洩と対策で解説しています。8つの中でもここが最重要なので、最初に読むのをおすすめします。
落とし穴2：便利ツールでのスクレイピングが規約違反や過負荷になる
AIに頼むと、他のサイトから情報を自動で集める「スクレイピング」のツールも、あっという間に作れてしまいます。ただ、集める相手のサイトには利用規約があり、自動収集を禁じている場合があります。
また、短時間に大量のアクセスを送ると、相手のサーバーに過負荷をかけてしまうこともあります。悪気がなくても、規約違反や相手先への迷惑につながりかねない、という点に注意が必要です。
対策の一言でいえば、集める前に相手の規約を確認し、アクセスの間隔を空けるなど負荷をかけない配慮をすることです。くわしくはAIで作ったスクレイピングツールの危険性をご覧ください。
落とし穴3：公開したアプリのサーバの守りが手薄になる
作ったアプリをインターネットに公開すると、世界中からアクセスできる状態になります。便利な反面、狙う側からも見える状態になった、ということでもあります。
AIに任せて立てたサーバは、動かすことが優先され、外からの攻撃に備える設定が手薄なまま公開されがちです。公開している分だけ、狙われる面が広がります。
対策の一言でいえば、公開するサーバに何を許して何を閉じるかを、動かす前に一度見直すことです。くわしくはAIで作ったアプリのサーバは安全かで整理しています。
落とし穴4：本番データベースを誤って操作する
アプリの利用者のデータは、データベースに保管されます。ここは、いちど壊すと取り返しがつきにくい場所です。
AIに「このデータを整理して」などと頼んだとき、テスト用のつもりが本番のデータベースに向いていて、大切なデータを消してしまう、といった事故が起こりえます。動かす対象がテスト用か本番か、あいまいなまま進めるのが危ういのです。
対策の一言でいえば、テスト用と本番の環境をはっきり分け、消す操作の前には必ず対象を確かめることです。くわしくはAIと一緒に扱うデータベースの安全な進め方をご覧ください。
落とし穴5：サーバレスの従量課金で高額請求になる
VercelやAWS Lambdaのような「サーバレス」の仕組みは、使った分だけ料金がかかる従量課金です。手軽に公開できて便利ですが、想定外にアクセスが増えると、料金も一気に膨らみます。
たとえば、公開したアプリにボットが大量のリクエストを送ってきた場合、その処理回数の分だけ課金が積み上がっていきます。上限を決めていないと、気づいたときには大きな金額になっていることもあります。
対策の一言でいえば、利用量や請求の上限アラートを設定し、使いすぎに早く気づける状態にしておくことです。くわしくはサーバレス開発に潜む従量課金の罠で解説しています。
落とし穴6：AIが勧めた定番ライブラリの罠（サプライチェーン攻撃）
AIにアプリ作りを任せると、必要な部品(ライブラリ)はAIが判断してどんどん取り込んでいきます。その中には、あなたが名前も知らない部品が大量に含まれます。
近年、その「みんなが信頼して使っている部品」そのものに悪意あるコードが仕込まれる、サプライチェーン攻撃という手口が増えています。2026年3月31日には、広く使われている定番ライブラリのaxiosの管理者アカウントが乗っ取られ、悪意あるバージョンが公開される事件も起きました。多要素認証を設定していた管理者でも乗っ取られており、対岸の火事とは言えません。
対策の一言でいえば、素性の確かな部品を選び、問題が見つかったとき自動で通知が届く状態を作っておくことです。くわしくはサプライチェーン攻撃とAIが勧めた定番ライブラリの守り方をご覧ください。
落とし穴7：秘密情報をGitHubに上げてしまう
サーバー側でキーを環境変数に隠していても、そのキーを書いた .env ファイルを、うっかりGitHubの公開リポジトリに上げてしまうと、そこから抜き取られてしまいます。せっかく隠したつもりが、別の入り口から漏れてしまうわけです。
コードを保管・共有するGitHubは便利ですが、公開設定のまま秘密情報を含むファイルを上げると、世界中から見える状態になります。ここも見落としやすい落とし穴です。
対策の一言でいえば、.gitignore という設定に .env を加え、鍵を含むファイルをアップロードしないようにすることです。この扱いは前述のAPIキーの話とセットなので、APIキーの守り方の後半とあわせて押さえておくと安心です。
落とし穴8：ログイン失敗メッセージの作り方
会員機能などを付けると、ログインの仕組みが必要になります。ここで見落としやすいのが、ログインに失敗したときのメッセージの書き方です。
「このIDは存在しません」「パスワードが違います」のように、どちらが間違っているかを丁寧に伝えると、一見親切に見えます。ですが、攻撃者から見ると「このIDは存在する」というヒントを渡すことになり、狙い撃ちされやすくなります。
対策の一言でいえば、失敗時は「IDまたはパスワードが違います」のように、どちらが違うか分からない書き方にそろえることです。理由のくわしい解説はログインエラーでID・パスワードのどちらが違うか教えない理由にあります。ログインの仕組み自体を知りたい方はログインの仕組みを、ログイン状態を保つトークン認証についてはトークン認証とはもあわせてどうぞ。
公開前チェックリスト
ここまでの8点を、一望できる形にまとめておきます。公開する前に、上から順に確認してみてください。
- APIキーをクライアント側に書いていないか。サーバー側の環境変数に隠せているか
- スクレイピングを含む場合、相手の規約を確認し、アクセスの間隔を空けているか
- 公開するサーバで、何を許して何を閉じるかを見直したか
- 本番とテストのデータベースを分け、消す操作の前に対象を確かめているか
- サーバレスの利用量・請求に上限やアラートを設定したか
- 使っている部品に問題が出たとき、通知が届く状態にしてあるか
.envなどの秘密情報をGitHubに上げていないか(.gitignoreを設定したか)- ログイン失敗のメッセージで、IDとパスワードのどちらが違うかを伝えていないか
すべてに自信を持って「はい」と言えなくても、落ち込む必要はありません。1つずつ、リンク先を読みながらつぶしていけば大丈夫です。
次の一歩
8つを並べてみて、こう感じた方もいるかもしれません。一つひとつは分かった。でも、自分のアプリでは「どこまで自分で守るべきか」の線引きが分からない、と。
正直なところ、これは独学でいちばん迷うところです。全部を完璧にやろうとすると手が止まりますし、逆に何も気にしないと事故につながります。AIとの付き合い方そのものにある落とし穴を先につかんでおきたい方は、バイブコーディングとはも入口としてヒントになります。
AIのおかげで、コードを書く力そのものは、以前ほど大きな壁ではなくなりました。だからこそこれからは、「何が危ないのかを見抜き、どこを自分で判断するか」というセキュリティの考え方や、体系的な基礎が、いっそう効いてきます。
独学でつまずきやすいのは、知識そのものよりも「何を、どの順番で学ぶか」です。AI時代のセキュリティの基礎も、あなたの目標から逆算した学ぶ順番の一部として、1対1で一緒に整理できます。
