バイブコーディングのセキュリティ対策｜AIアプリ公開前の確認リスト

01公開前に、自分のアプリが何を扱うか整理する

バイブコーディングのセキュリティ対策は、まず「何ができるアプリか」を書き出すところから始めましょう。作成に使ったAIの名前より、受け取る情報や許す操作に合わせて確認対象を決めます。

表示・入力・保存・ログイン・決済・外部送信を分ける

下の表は、この記事独自の分類です。どれか1つではなく、該当する機能をすべて選びます。例えば会員制のAIチャットなら、入力・保存・ログイン・外部送信が重なる場合があります。

機能の多さで安全・危険を採点する表ではありません。入力があっても端末内だけで処理するアプリはあります。実際の送信・保存の有無で判断してください。

誰の情報が、どこへ送られ、どこに残るかを書く

例えば文章を要約するアプリなら、「利用者のブラウザ → 自分のサーバー → AI提供元」という流れが考えられます。これは説明用の例です。実際には、データベースや、処理の記録であるログにも情報が残ることがあります。

自分のアプリについて、送る情報、送信先、保存先、読める人を書きます。「画面に保存ボタンがない」ことと「どこにも保存されない」ことは分けて確認しましょう。ブラウザ内の保存、アクセス解析、エラー記録も調べ、不明な箇所には未確認と書きます。

根拠：OWASP｜Logging Cheat Sheet

検証環境と、予定する公開範囲を決める

確認は、自分が管理する検証環境と架空データで行います。本番とは別の環境を使う場合は、接続先、APIキー、権限、公開設定の違いを記録し、公開前にその違いも確認対象にします。

「URLを知人にだけ教えた」は、認証によるアクセス制限とは別です。利用者を限定したいときは、許可した人だけが使える仕組みを確認してください。画面だけでなく、データを返すAPIなどの窓口にも制限が必要です。

根拠：OWASP｜Authorization Cheat Sheet

02APIキーと個人情報が公開物に含まれていないか

APIは、アプリから別のサービスを利用するための窓口です。APIキーには利用元を識別するものなどがありますが、ここで特に注意するのは、第三者に渡してはいけない秘密のAPIキーです。

コード・配布ファイル・ログ・画像を分けて見る

秘密のキーは、ブラウザへ配るコードに入れません。OpenAIも、ブラウザなどの利用者側の環境に秘密のキーを置かず、自分が管理するサーバーを経由するよう案内しています。

根拠：OpenAI｜Best practices for API key safety

確認するのは、編集中のコードだけではありません。少なくとも次の公開経路を分けて見ます。

• コードと設定：コードの保管場所であるリポジトリ、過去の変更履歴、設定ファイル。
• 配布するファイル：公開用に生成したHTMLやJavaScript、ダウンロードさせるファイル。
• 記録と共有物：エラーログ、画面のスクリーンショット、説明資料、AIへの相談文。

キーだけでなく、テスト用に入れた実名、メールアドレス、社内文書なども対象です。検索・スキャンの結果には調べた範囲を添え、実際の秘密値を確認メモに貼り直さないようにします。説明用の値なら、DUMMY_NOT_A_REAL_KEYのようなダミーを使います。

根拠：OWASP｜Secrets Management Cheat Sheet、OWASP｜Logging Cheat Sheet

環境変数は、コードとは別に設定値を渡す仕組みです。ただし、環境変数に入れただけでは秘密になるとは限りません。例えばViteでは、VITE_で始まる変数の値が、公開用のコードへ組み込まれます。秘密の値を入れないよう公式資料でも説明されています。

この命名規則はViteの例です。別の開発ツールでも同じ名前だと決めつけず、「最終的に利用者のブラウザへ渡る値か」を、そのツールの公式資料と配布物で確認してください。

根拠：Vite｜Env Variables and Modes

公開を前提にしたキーと、秘密の認証情報を区別する

「キー」という名前の値を、すべて一律に削除する必要はありません。例えばSupabaseには、ブラウザなどで使う公開用のpublishable keyと、サーバー側だけで扱うsecret keyがあります。

ただし、公開用キーがあればデータを守れるわけではありません。Supabaseでは、データの行ごとにアクセスを制限するRLSなどの権限設定を確認します。秘密キーはその制限を回避できる強い権限を持つため、公開用キーの代わりにブラウザへ置いてはいけません。

根拠：Supabase｜API keys

また、キーをサーバー側へ移しても、そのサーバーを誰でも無制限に呼び出せるなら別の問題が残ります。呼び出す人の権限と利用量は、キーの保管とは分けて確認します。

根拠：OWASP｜Authorization Cheat Sheet、OpenAI｜Best practices for API key safety

漏洩の疑いがあれば、公開作業を中断する

注意公開場所から消すだけでは、漏れたキーは無効になりません。秘密のキーが外へ出た疑いがある場合は、通常の公開作業を中断し、提供元の手順で旧キーの失効と安全な新キーへの移行を進めます。

失効とは、そのキーを使えなくすることです。不正利用が進んでいる場合などは停止を優先し、本番への影響があるときは担当者と切替を調整します。あわせて利用履歴と請求を調べ、新しいキーを同じ経路で漏らさないよう原因を直します。

根拠：OWASP｜Secrets Management Cheat Sheet、OpenAI｜Best practices for API key safety

詳しい順序は、AIセキュリティ入門の「APIキー漏洩時の対処」で確認できます。

03ログインと「他人のデータを扱えないこと」を分けて確認する

認証は「利用者が誰か」を確かめることです。認可は「その人に、どの操作を許すか」を判断することです。ログインに成功しても、他人のデータまで見られてよいことにはなりません。

根拠：OWASP｜Authorization Cheat Sheet

未ログインの人が使える機能を決める

まず、誰でも見られるページと、ログイン後だけ使える機能を書き分けます。例えば非公開メモアプリなら、案内ページは公開し、メモの閲覧・作成・変更・削除はログインした本人に限る、と決められます。

ログイン機能は、提供元が保守している認証サービスなどの仕様を確認して使います。ログアウトやログイン状態の有効期限、アカウントの復旧も確認対象です。ログイン後のページを含め、通信を暗号化するHTTPSで利用できることも確認してください。

根拠：OWASP｜Authentication Cheat Sheet

利用者AとBのデータが分離されることを確かめる

次の表は、利用者ごとに非公開のメモを持つアプリの設計例です。共同編集や一般公開をするアプリでは、許す範囲が変わります。

表を作るだけでは、設定や動作を確かめたことにはなりません。自分の検証環境で、次の順に確認します。

1. 期待する権限を決めます。誰が、どのデータを、どこまで扱えるかを書きます。
2. 設定・実装を確認します。サーバー、API、データベースのどこで権限を判断するかを調べます。
3. 架空のA・Bアカウントで結果を確認します。許す操作ができることと、許さない操作が拒否されることを確かめます。
4. 対象と結果を記録します。画面しか調べていない場合は、API側の確認まで終えたことにしません。

ボタンを隠すだけでは、操作を拒否する仕組みにはなりません。権限の判断は、サーバーやデータ基盤など、利用者が勝手に変更できない側で行う必要があります。

根拠：OWASP｜Authorization Cheat Sheet、OWASP WSTG v4.2｜Testing for Insecure Direct Object References

確認方法が分からない場合は、技術者へ「自分の検証環境で、AとBの閲覧・作成・変更・削除を分離したいです。確認できた設定は○○、未確認は○○です。許さない操作がどこで拒否されるか、確認方法と結果を教えてください」と依頼します。実データや秘密のキーは添付しません。

管理者の操作と、通常利用者の操作を分ける

管理者だから全データを無条件で読める、とは決めつけません。利用者の削除、権限変更、データ出力など、運用に必要な操作と理由を定めます。

アプリの管理者に加え、公開サービス、コード保管先、データベースの管理アカウントも確認します。担当者を明確にし、不要な管理権限を外し、利用可能ならパスワード以外の確認も組み合わせる多要素認証を設定します。

根拠：OWASP｜Authorization Cheat Sheet、OWASP｜Authentication Cheat Sheet

AIがメール送信やデータ更新を行うアプリでは、AIに渡す操作権限も別に定めます。これは利用者A・Bのデータ分離の確認を代わりに済ませるものではありません。

根拠：OWASP｜AI Agent Security Cheat Sheet

04入力・保存・決済・費用・更新を確認する

ここからは、該当する機能がある項目を確認します。コードだけでなく、利用しているサービスの設定と、公開後に管理する担当も対象にします。

入力とアップロードの制限をサーバー側でも確認する

サーバーへ情報を送るアプリでは、受け付ける文字数、数値の範囲、ファイルの種類・容量・件数を決めます。ブラウザの入力欄で制限していても、それだけに頼らず、受け取るサーバー側でも条件を確かめます。

ファイルは拡張子だけで判断せず、種類の確認、保存場所、閲覧できる人も確認対象にします。端末内だけで処理するアプリに、確認のためだけにサーバーを追加する必要はありません。

根拠：OWASP｜Input Validation Cheat Sheet、OWASP｜File Upload Cheat Sheet

入力制限だけで、すべての問題を防げるわけではありません。例えば、入力やAIの出力を画面へ表示するときは、意図せずプログラムとして実行させない処理が必要です。データベースへ渡すときも、命令と入力データを分ける方法などを確認します。実装の判断が難しい場合は、その処理を技術者へ見てもらいましょう。

根拠：OWASP｜Input Validation Cheat Sheet

保存先・外部送信先・削除方法を確認する

保存機能がある場合は、データベースやファイル置き場が、意図しない相手へ公開されていないか確認します。利用者がログインする画面とは別に、保存先そのもののアクセス設定も見ます。

本記事の確認表では、保存する理由、保存期間、削除する方法、不要なテストデータの除去まで記録します。ログやバックアップに残る情報は、通常の画面から削除した情報と分けて確認してください。秘密のキーや不要な個人情報を、調査用ログへそのまま残さないことも重要です。

根拠：OWASP｜Authorization Cheat Sheet、OWASP｜Logging Cheat Sheet

生成AIを呼び出すアプリなら、誰の文章やファイルを、どの提供元へ送るかを記録します。さらにAIが外部操作も行う場合は、読み込んだ文書やAIの出力を、そのまま送信・削除・決済の許可として扱いません。許す操作を絞り、影響の大きな操作には内容を確認して承認する仕組みを設けます。

根拠：OWASP｜AI Agent Security Cheat Sheet

決済と、運営側の利用料を分けて確認する

決済は、利用者から支払いを受ける処理です。「支払い成功」の画面が表示されたことだけで確定せず、サーバー側で決済結果を確認します。注文・金額・通貨が一致するか、決済サービスからの通知が本物か、同じ通知で二重に商品や利用権を渡さないかを確かめます。

確認には、提供元が用意するテスト環境や手順を使います。結果を判断できないまま、本番決済を有効にしないようにしましょう。

根拠：OWASP｜Third Party Payment Gateway Integration Cheat Sheet

一方、利用料は、運営者が公開サービスやAI APIなどへ支払う費用です。次の3つは役割が違います。

• 通知：利用量や金額が条件に達したことを知らせます。
• 停止条件：条件に達したとき、対象の処理や利用を止めます。
• 利用頻度の制限：一定時間内の呼び出し回数などを抑えます。総額の上限とは別です。

例えばGoogle Cloudの通知専用予算であるalerts-only budgetは、設定額に達しても、それだけでは利用や請求を自動停止しません。対応するサービスには別の支出上限機能もあるため、「予算」という名前だけで判断せず、自分が使う機能の停止対象と条件を確認します。

根拠：Google Cloud｜Create, edit, or delete budgets and budget alerts

上限を設定できる場合も、反映のタイミングや対象外の費用を確認してください。通知先、異常時に止める方法、利用者ごとの制限を確認表へ記録します。秘密のキーが見えないことと、運営側の費用が制御できることは別です。

根拠：OpenAI｜Best practices for API key safety、OWASP｜AI Agent Security Cheat Sheet

使っている部品と、AIが変更した箇所を確認する

アプリが利用する外部のプログラム部品を、依存パッケージと呼びます。名前、採用バージョン、配布元、既知の問題、更新情報の確認先を残します。アプリを動かす実行環境についても、公開サービスに任せる範囲と自分が更新する範囲を分けます。

根拠：OWASP｜Vulnerable Dependency Management Cheat Sheet

AIに修正を頼んだあとは、依頼した画面だけでなく、変更された設定、権限、依存パッケージ、テストも見ます。「テストが成功した」場合でも、必要なテストが削除されたり、確認条件が弱くなったりしていないかを確認します。

スキャナーの「問題なし」やAIの説明は、確認材料の一部です。対象範囲と結果を残し、未確認の設定や運用まで検証済みにしないでください。

根拠：OWASP｜Secure Coding with AI Cheat Sheet、GitHub｜Application card: GitHub Copilot Agents

05公開前チェック表で「確認できた根拠」を残す

確認表では、チェックの数よりも、どこで何を確かめ、何が残っているかを重視します。共通情報として、アプリ名、確認日、確認者、対象の版、検証環境、本番との差分、予定する公開範囲を記録してください。

「確認済み・要修正・未確認・対象外」に分ける

状態は、この記事では次のように使います。「相談が必要」は状態ではなく、未解決時の行動に記録します。

• 確認済み：決めた確認条件を満たし、設定や確認結果などの根拠が残っています。
• 要修正：問題が見つかり、まだ解決していません。
• 未確認：調べていない、情報が足りない、または判断できません。
• 対象外：機能がないなど、確認が不要な理由を確かめ、記録しています。

注意この表は、セキュリティ診断書や安全証明ではありません。全部を確認済みにしても、安全や無欠陥を保証しません。扱う情報や機能によって、追加の設計確認・専門的な検証が必要です。

以下は本記事独自の確認表です。「未確認」は記入を始めるための初期値で、あなたのアプリを検査した結果ではありません。横に長い表は横スクロールできます。

1行の中で確認状況が違う場合は、項目を分けて記録します。例えば利用者のログイン機能がなくても、公開サービスの管理アカウントの保護まで対象外にはしません。「決済機能なし」のように、対象外にした理由も残してください。

記入例：「利用者Aの画面にBのメモは表示されなかった。ただし、API側の権限設定と拒否される動作は未確認」。この場合、利用者間の権限全体は「未確認」とし、実データでの公開を保留して、技術者へ確認を依頼します。画面で見えなかった結果は、部分的な根拠として残せます。

公開を見送る条件と、相談先を決める

本記事では、実際に使う機能に関係する重要項目が未確認・要修正なら、実データを扱う公開や公開範囲の拡大を保留することを基準にします。特に、個人情報、秘密情報、利用者間のデータ分離、決済、外部送信・操作、費用を止める手段を重視します。

これは筆者が提案する運用上の判断基準で、公式の合格基準ではありません。不要な機能を外す、扱う情報を減らす、適切にアクセスを制限した環境で検証を続ける、といった見直しも選べます。

サービスの機能・契約・設定の疑問は提供元へ、実装やデータ分離の疑問は開発者・セキュリティ担当へ相談します。「相談した」で終わらせず、依頼範囲、確認結果、残る課題、対応者を記録してください。

すでに漏洩や無許可の操作が見つかった場合は、相談を待つだけでなく、該当機能や公開を停止・制限して対応します。調査に必要な記録は、閲覧できる人を限定して保全します。

異常の検知・停止・復旧まで担当を決める

異常な利用量や権限エラーなどを、どの通知・ログで知るかを決めます。通知を受ける人と、不在時の連絡先も確認しましょう。個人開発なら、自分が確認できる通知先と操作手順を残します。

根拠：OWASP｜Logging Cheat Sheet

停止方法は「ページを非表示にする」だけで終えません。API、定期実行、外部連携など、実際に動いている処理ごとに、どこまで止まるかを確認します。

復旧は、保存してあるバックアップの有無だけでなく、戻す対象と手順を決め、検証環境で結果を確かめます。以前のコードへ戻すことと、データを戻すことは別です。漏洩したキーや問題のある版へ戻さないことも、復旧の条件に含めます。

コピーして使う公開前確認記録

下の様式を手元のメモへコピーし、まず12項目の状態を記入します。そのあと「1項目の詳細記録」を複製して、各項目の根拠と次の行動を残してください。APIキー、パスワード、利用者の実データは書き込みません。

AIで作ったアプリの公開前確認記録
安全証明ではありません。秘密のキー・パスワード・実データは書かないでください。
【基本情報】
アプリ名：
確認日・確認者：
対象バージョン／公開版ID：
検証環境：
本番との差分：
予定する公開範囲：
該当機能（複数選択）：入力／保存／ログイン／決済／外部送信・操作
扱う情報・送信先・保存先：
利用サービスと、自分／提供元の管理範囲：
記録の保管先：
【状態の一覧】
確認済み＝条件を満たし根拠あり／要修正＝問題が未解決
未確認＝未実施・情報不足・判断不能／対象外＝不要な理由を確認済み
以下の「未確認」は記入前の初期値です。
01 アプリ種別・公開範囲：未確認
02 秘密情報・公開物：未確認
03 認証・管理アカウント：未確認
04 利用者間の権限：未確認
05 入力・アップロード・表示：未確認
06 保存・削除：未確認
07 外部送信・外部操作：未確認
08 決済：未確認
09 利用料・過剰利用の防止：未確認
10 更新・AIによる変更：未確認
11 異常の検知・停止：未確認
12 復旧：未確認
【1項目の詳細記録：項目ごとに複製】
対象：
確認場所・設定名：
確認日・確認者（基本情報と異なる場合）：
期待する結果：
実際の結果：
根拠・記録の保管先：
状態：
対象外の場合の理由：
未解決の点：
未解決時の行動／止める機能：
担当・相談先・依頼範囲：
対応期限・再確認の条件：
【公開と運用の判断】
現時点の判断：公開保留／条件を限定して再検討／予定範囲での公開を検討
判断の根拠：
公開前に必要な修正・確認：
相談後の結果と残る課題：
異常の通知先・確認担当：
停止する対象・方法・担当：
復旧する対象・方法・担当・確認結果：
次回確認日／再確認のきっかけ：

06よくある質問

根拠：GitHub｜Application card: GitHub Copilot Agents、OpenAI｜Best practices for API key safety、OWASP｜Logging Cheat Sheet