結論
生成AIで作ったアプリは、画面が動いていても、見えないところに事故の種が残っていることがあります。公開する前に、少なくとも次の5つを確かめてください。
- APIキー（外部サービスを使うための秘密の文字列）が、コードや公開される設定に入っていないか
- データベースのアクセス制限（Supabase では RLS：行ごとのアクセス制限）が設定されているか
- 使っているパッケージ（ライブラリ。アプリが使う外部のプログラム）に、既知の脆弱性（攻撃に使われるおそれのある不具合）がないか
- 秘密の設定ファイル（.env）を、GitHub などに上げていないか
- 元のコードがそのまま読める形で公開されていないか（ソースマップ）
確かめ方は、自動の点検ツール → 自分のAIに確かめさせる → 人の診断の順に、手軽なものから使うのがおすすめです。
「生成AIで作ったアプリ」と「生成AIを組み込んだアプリ」は別の話
「生成AI アプリ 品質」で調べると、チャットボットの回答の正しさを評価する話（生成AIを組み込んだアプリの品質保証）がよく出てきます。この記事が扱うのは、生成AIがコードを書いて作ったアプリです。違いは「「AIでつくる」と「AIを組み込む」の違い」で説明しています。
なぜ、AIで作ったアプリは確かめが要るのか
AIは、頼まれた機能を「動く形」にするのが得意です。一方で、頼まれていないこと（だれに見せてはいけないか、何を秘密にするか）は、こちらが言わないと抜けやすくなります。
- 試しに動かすために、APIキーをコードに直接書いたまま残る
- 手元で動かすために、データベースのアクセス制限をゆるくしたまま残る
- パッケージのバージョンを決めずに入れたため、古いバージョンのまま残る
どれも、画面の見た目では気づけません。そして、公開してから気づくと、APIキーの作り直しやデータの確認など、後始末が大きくなります。
公開前に確かめる5つの点
1. APIキーなどのシークレットがコードに入っていないか
決済（Stripe など）やAI（OpenAI など）のAPIキーがコードにあると、公開した瞬間に、だれでも読める状態になります。APIキー以外のシークレット（パスワード・トークン・Webhook 署名シークレット・秘密鍵など）も対象です。とくに、ブラウザーに公開される設定（NEXT_PUBLIC_・VITE_ で始まる名前など）にシークレットを入れると、ブラウザーから読めてしまいます。
- 確かめ方：コードの中にシークレットの形の文字列がないか、ブラウザーに公開される設定の名前にシークレットが入っていないか。
- もし入っていたら：見つかったシークレットの種類に応じて無効化・更新し、新しいシークレットはサーバー側の設定に置きます。Webhook 署名シークレットは Webhook の設定から更新します。コードから消すだけでは足りません。
2. データベースのアクセス制限（RLS）
Supabase では、画面から使う anon キー（公開用のキー）はブラウザーに公開される前提です。そのかわり、テーブルごとのアクセス制限（RLS とポリシー）で「だれが、どの行を読み書きできるか」を決めます。公開用のキーからアクセスできるテーブルで RLS が無効だと、許可された読み書きの操作を、行ごとの制限なしに実行できる状態になります。
- 確かめ方：すべてのテーブルで RLS が有効か、ポリシーが「自分の行だけ」などになっているか。Supabase の管理画面の Security Advisor も手がかりになります。
- service_role キー（管理用のキー）は RLS を飛び越えるので、クライアント側のコードに入れてはいけません。
3. パッケージの既知の脆弱性
アプリは、たくさんのパッケージの組み合わせでできています。パッケージには、あとから脆弱性が公表されることがあります。とくに、画面やサーバーで実際に動くパッケージの重い脆弱性は、公開前に直しておきたいところです。
- 確かめ方：使っているパッケージの名前とバージョンを、既知の脆弱性のデータベースと照らし合わせます（
npm audit、pip-auditなど）。 - 脆弱性の情報は日々増えるので、一度確かめて終わりではありません。公開のあとも、ときどき確かめます。
4. .env を GitHub に上げていないか
.env は、シークレット（APIキー・パスワード・トークン・Webhook 署名シークレット・秘密鍵など）やデータベースの接続 URL を書く設定ファイルです。.gitignore に入れ忘れると、GitHub に上がってしまいます。いったん上げると、あとで消しても履歴に残ります。
- もし上げていたら：中のシークレットを種類に応じてすべて無効化・更新し、
.envを Git の管理から外して、.gitignoreに足します（.gitignoreに足すだけでは、上げたファイルは残ります）。
5. 元のコードを読める形で公開していないか（ソースマップ）
ソースマップは、開発のときに便利な「元のコードの地図」です。本番でも公開し、元のコードを含める設定だと、元のコードがそのまま読めます。コードに秘密がなければ大きな事故にはなりにくいものの、本番では出さない設定にしておくのが基本です。
確かめ方の3つの種類と、使い分け
| 種類 | 向いていること | 苦手なこと |
|---|---|---|
| 自動の点検ツール | APIキーの形・設定・パッケージのバージョンなど、形で分かることを、決まった規則で、すばやく確かめる | ログインの確かめ方や決済の処理など、コードの意味を読まないと分からないこと |
| 自分のAI（Claude Code・Codex など）に確かめさせる | コードの意味を読んで、ログイン・決済・入力の扱いなどを確かめる。そのまま直せる | 頼み方しだいで見落とす。直すたびに別のところを壊すことがある |
| 人の診断 | 症状の再現、原因の切り分け、直す順番と範囲を決める。AIの直しが堂々巡りになったとき | 費用と日数がかかる |
表は横にスクロールできます。
おすすめの順番は、次のとおりです。
- 自動の点検で、形で分かる点をつぶす
- 自分のAIに、意味を読む点を確かめさせる（直す前に、Git でいまの状態を残しておく）
- 直せない・直すと壊れる、ときは人に相談する
どの方法でも、「指摘がない＝問題がない」ではありません。確かめた範囲を知ったうえで使ってください。
Qz AI Labs のツールとサービス
- 点検日和（無料・登録不要）：アプリのフォルダか ZIP を選ぶか、GitHub の公開リポジトリの URL を入れると、上の1〜5のうちコードの形で分かる点をブラウザーの中で点検し（管理画面の設定は見ません。細かい範囲は点検日和の「確かめること・確かめないこと」）、見つけた点を、あなたのAI（Claude Code・Codex など）に直させるプロンプトを出します。あなたのアプリのソースコードは預かりません。意味を読む点は、あなたの Claude Code・Codex に貼る「確かめるプロンプト」を出します。→ 点検日和で点検する
- AI製コードの診断と修復（有料）：自分で直せないとき、症状を再現して原因・直す順番・確定した見積もりをまとめた診断の報告から始めます。修復の料金は、直ってからのお支払いです。診断は29,800円（税込）から。相談は無料です。→ AI製コードの診断と修復
よくある質問
生成AIで作ったアプリの品質をチェックするサービスはありますか？
形で分かる点（APIキー・データベースのアクセス制限・パッケージの脆弱性など）は、自動の点検ツールで確かめられます。Qz AI Labs の点検日和は、無料・登録不要で、アプリのソースコードを預からずに点検します。コードの意味を読む点は、ご自分の Claude Code・Codex に確かめさせるか、人の診断を使ってください。
バイブコーディングで作ったアプリは、そのまま公開して大丈夫ですか？
画面が動いていても、APIキーの漏れやデータベースのアクセス制限の抜けが残っていることがあります。公開する前に、この記事の5つの点を確かめてください。
AIを組み込んだアプリの品質保証とは違いますか？
違います。この記事は、AIがコードを書いて作ったアプリの確かめ方です。AIの回答の正しさの評価は扱っていません。
点検で何も見つからなければ、安全ですか？
いいえ。点検は、確かめた範囲で気づいた点を示すもので、安全を保証するものではありません。点検日和は、確かめること・確かめないことをページに書いています。
自分で直せないときは？
直し方が分からない、直すと別のところが壊れる、というときは、AI製コードの診断と修復にご相談ください。相談は無料です。