結論から
「ボタンを押すと反応する」「フォームを送信すると完了画面が出る」——これらは、あなたのアプリが「動いている」証拠です。しかし「安全に使える」証拠にはなりません。この2つは、確認する人の視点がそもそも違うからです。
- 「動く」の確認：自分がユーザーとして操作し、見た目どおりの結果が返るかを見る
- 「安全に使える」の確認：悪意ある第三者が操作したとき、見えてはいけないものが見えないか・できてはいけない操作ができないかを見る
- AIツールは前者（想定どおりの操作）を高い精度で作る。後者は、意識して確認しない限り抜けたまま公開される
「動く」けれど「安全ではない」実例
2026年2月、あるAIコーディングプラットフォーム（Lovable）上で公開されていたアプリが、セキュリティ研究者によって調査されました。そのアプリはプラットフォームの紹介ページに掲載され、10万回以上閲覧されていました。つまり「ちゃんと動いて」いて、多くの人が実際に使っていたということです。
しかし調べてみると、1つのアプリに16個の脆弱性（うち6個が重大）があり、AIが生成したログイン処理は判定が逆になっていました。ログイン済みの人を締め出し、ログインしていない匿名の訪問者にアクセスを許していたのです。結果として、大学生・高校生を含む約18,700人分のユーザー情報が、誰でも取得できる状態でした。
このアプリの作者が自分でログインして操作している限り、この問題には気づけません。ログイン済みの自分から見れば「動いている」からです。
数字で見る「動く」と「安全」の差
- ETH Zurich らのベンチマーク（BaxBench）では、主要なAIモデルが生成するバックエンドのコードの36%以上が安全でないとされた
- Veracode の2025年の調査では、AIが生成したアプリケーションの45%に、悪用可能なOWASP脆弱性が含まれていた
- セキュリティ企業 Escape が約5,600のバイブコーディング製アプリを調査したところ、2,000件を超える脆弱性、400件超の露出したAPIキーなど、175件の個人情報の露出が見つかった
AIは「想定どおりの操作」には強く、「想定外の入力・同時操作・ネットワークエラー・悪意ある第三者の操作」で崩れます。
2つの確認は「誰の視点で操作するか」が違う
「動く」の確認は、自分がユーザーとして普通に操作します。
「安全」の確認は、普通のユーザーがやらないことを、自分でやります。
- ログアウトする／シークレット（プライベート）ウィンドウで開く
- アカウントを2つ作り、片方でもう片方のデータを開こうとする
- URL やリクエストの中の ID（
?id=123の数字など）を書き換える - ブラウザの
F12（開発者ツール）を開いて、配信されているコードを読む
これらを一通り自分で試して「何も余計なものが見えない・できない」ことを確認して、はじめて「安全に使える」に近づきます。
このシリーズを1枚で振り返る
各記事が「画面の外」で扱っていたことと、それが公開前チェックのどの項目につながるかを並べます。
- クライアント/サーバー・フロントエンド/バックエンド — 画面と処理は別の場所にあり、フロントに書いた値は誰でも読める。→ 確認すること：フロントにキーや秘密が混ざっていないか
- データの保存先・個人情報 — 入力データは DB・ブラウザ・Cookie・ログ・通知メールに散らばる。→ 確認すること：データの居場所と、誰が見られるか
- APIキー・環境変数 — 外部サービスの鍵。コードへの直書きや GitHub 公開で漏れる。→ 確認すること：キーが直書き／公開されていないか、漏れていたなら再発行済みか
- 認証 — ログインできることは、他人のデータが守られていることを意味しない。→ 確認すること：ログアウト状態・別アカウント・ID 書き換えでのテスト
- HTTPS — 通信経路の暗号化。サイト運営者そのものの信頼性は別問題。→ 確認すること：鍵マークと「混在コンテンツ」警告
- デプロイ — ローカルと本番は別物（環境変数・DB接続先・デバッグ表示）。→ 確認すること：本番の環境変数・DB接続先・デバッグモード
どれも画面を見ているだけでは分かりません。だからこそ「動いている」という事実だけでは、これらが正しくできているかを判断できないのです。
AIツールへの指示例
修正の前に、まず現状を洗い出すところから頼めます。
「このアプリを、悪意ある第三者の視点でレビューしてください。『ログインせずにアクセスする』『別のユーザーになりすます』『URL やリクエストの ID を書き換える』『フロントエンドのコードを読む』といった操作で、見えてはいけないデータや、実行できてはいけない操作がないか、具体的な手順ベースで指摘してください。」
返ってきた指摘を、上の一覧の項目と照らし合わせて、1つずつ潰していきます。
よくある質問
AIツールに「安全に作って」と頼めば十分ではないですか。
指示すること自体は無駄ではありませんが、「安全」の範囲は非常に広く、AIがすべてのパターンを自主的に想定して実装してくれるとは限りません。前掲の Lovable の例のように、AIが生成した認証処理そのものが逆になっていることさえあります。このシリーズの項目を、1つずつ具体的に指示・確認する必要があります。
全部を自分で確認するのは大変そうです。どこから始めればいいですか。
まず「公開前チェックリスト」カテゴリーの記事を上から読むことをおすすめします。各項目が、この基礎知識シリーズのどの回に対応しているかが分かるようになっているので、不安な項目だけ基礎知識に戻って読み直せます。
一通り読んだうえで、自分だけで確認しきる自信がありません。
「動く」と「安全に使える」の間には、非エンジニアだけでは埋めきれない差が残ることがほとんどです。VibeCode本番化では、公開前のアプリを第三者の視点で診断し、見つかった問題の改修まで行っています。まずは無料相談で、自分のアプリのどこを見ればいいかだけでも整理できます。
