プロンプトからWebアプリを作り、プレビュー画面で動作を確かめ、そのまま公開ボタンを押す。
AIコーディングでは、企画から公開までの距離が短くなった。
その一方で、ログイン後に別ユーザーの情報が見えないか、APIキーがブラウザへ渡っていないか、障害時に止められるかは、見た目から判断できない。
AI生成コードだけに固有の脆弱性があるわけではない。
問題は、実装の速度が確認工程を追い越しやすい点にある。
OWASP Top 10:2025ではアクセス制御の不備が最上位に残り、セキュリティ設定ミスやソフトウェア・サプライチェーンの失敗も上位に置かれた。
画面が完成していても、認証、権限、設定、依存関係が安全とは限らない。
この記事では非エンジニアでも公開前に確認できる10項目を、確認方法、危険な状態、AIへの修正依頼という順に整理する。
チェックを終えたことは安全の保証ではない。
自分で公開できる小規模アプリか、専門家レビューが必要なサービスかを見分けるための入口として使ってほしい。
機能テストは「正しい操作をしたときに期待どおり動くか」を確かめる。
セキュリティ確認では、権限のない人、予想外の入力、古いリンク、漏れた鍵、壊れた外部サービスに直面したとき、被害を限定できるかを見る。
たとえばログイン画面が動いても、URLのユーザーIDを書き換えるだけで他人の注文が見えるならアクセス制御は破綻している。
APIキーを環境変数へ移したつもりでも、フロントエンドへ配信される変数ならブラウザから読める。
バックアップが存在しても、復元を試したことがなければ障害対応には使えない。
自動診断ツールは、既知のパターンを効率よく探せる。
しかし、診断対象外の画面、事業固有の権限ルール、個人情報の扱い、運用担当者の停止判断までは保証しない。
検出ゼロを「安全」と読み替えず、何を調べ、何を調べていないかを確認する必要がある。
最初に、誰でも使える公開サイト、招待者だけのサービス、社員専用ツールのどれかを決める。
次に、氏名、メールアドレス、位置情報、決済情報、健康情報、社内文書など、入力・保存・外部送信されるデータを一覧にする。
最後に、漏えい、改ざん、消失、なりすまし、過剰請求が起きた場合の最大被害を想定する。
同じ診断フォームでも、回答を保存しない匿名ツールと氏名付きで長期保存する相談サービスでは必要な対策が違う。
社内限定だから安全とも限らない。
共有リンクが転送され、退職者のアカウントが残り、管理者権限が広すぎれば被害は起こり得る。
決済、医療、子どもの情報、本人確認、重要な顧客・従業員データを扱う場合、チェックリストだけで公開判断を完結させない。
法務、プライバシー、インフラ、アプリケーションセキュリティの専門家へ、データフローと権限設計を渡して確認する。
最初に、誰でも使える公開サイト、招待者だけのサービス、社員専用ツールのどれかを決める。
次に、氏名、メールアドレス、位置情報、決済情報、健康情報、社内文書など、入力・保存・外部送信されるデータを一覧にする。
最後に、漏えい、改ざん、消失、なりすまし、過剰請求が起きた場合の最大被害を想定する。
同じ診断フォームでも、回答を保存しない匿名ツールと氏名付きで長期保存する相談サービスでは必要な対策が違う。
社内限定だから安全とも限らない。
共有リンクが転送され、退職者のアカウントが残り、管理者権限が広すぎれば被害は起こり得る。
決済、医療、子どもの情報、本人確認、重要な顧客・従業員データを扱う場合、チェックリストだけで公開判断を完結させない。
法務、プライバシー、インフラ、アプリケーションセキュリティの専門家へ、データフローと権限設計を渡して確認する。
シークレットウィンドウと別端末でURLを開き、ログアウト状態で何が見えるか確かめる。
検索エンジンへの表示、共有リンク、プレビュー用URL、古いデプロイも対象だ。危険なのは「URLを知らなければ見つからない」をアクセス制御の代わりにすること。
AIには「公開経路を列挙し、未認証ユーザーが到達できるルートを一覧化して」と頼む。
新規登録、ログイン、ログアウト、パスワード再設定、メールアドレス変更を試す。
自作認証は避け、利用実績のある認証サービスを選ぶ。
再設定リンクが何度も使える、ログアウト後も戻るボタンで機密画面が見える、試行回数に制限がない状態は要修正だ。
認証は「誰か」、権限は「何をしてよいか」を扱う。
一般ユーザーと管理者のテストアカウントを作り、URLやリクエスト中のIDを書き換える。
画面上でボタンを隠すだけでは不十分で、サーバー側が対象データの所有者や役割を検証しなければならない。
フォーム項目ごとに、必要な理由、保存先、共有先、保持期間、削除方法を書く。
目的のない収集を減らすほど、漏えい時の被害も運用負担も小さくなる。
AIや外部APIへ送信するデータがあるなら、ユーザーへの説明と各サービスの条件を確認する。
リポジトリ、過去のコミット、ビルドログ、ブラウザの開発者ツールでキーを探す。
OWASPは秘密の集中管理、アクセス制御、監査、ローテーションを勧め、鍵をソースコードやバージョン管理へ入れないよう案内している。
露出を見つけたら、削除だけで済ませず失効させ、新しい鍵へ交換する。
AIが追加したライブラリの名前、用途、バージョン、配布元を一覧化する。
使っていない依存を削り、lockfileを保持し、脆弱性通知を有効にする。
OWASP Top 10:2025ではソフトウェア・サプライチェーンの失敗が独立した上位項目になった。
更新は本番へ一斉投入せず、テスト環境で確かめる。
存在しないURL、長すぎる入力、外部API停止などを試し、スタックトレース、DB接続文字列、鍵、個人情報が画面へ出ないかを見る。
ログは調査に必要だが、記録しすぎれば新しい漏えい源になる。
閲覧者、保存期間、削除手順を決め、機密値を伏字にする。
本番URLがHTTPSで、HTTPから安全に転送されるか確認する。
データベースやストレージがインターネットへ直接公開されていないか、アクセス権が最小限かも見る。
暗号化は設定の有無だけでなく、鍵の保管と交換まで含む。
バックアップの日時と保存先を確認し、テスト環境へ復元する。
削除事故だけでなく、不正変更やランサムウェアを想定し、本番と同じ認証情報だけに依存しない保管先を検討する。
復元に必要な担当者と所要時間も記録する。
エラー率、ログイン失敗、外部API利用量、クラウド請求の急増を通知できるようにする。
異常時に誰が判断し、どの機能またはデプロイを止め、ユーザーへ何を知らせるかを一枚にまとめる。
停止ボタンの場所が分からない状態で公開しない。
非エンジニアでも、ログアウト状態の表示、別ユーザーのデータ分離、ブラウザへ露出したキー、エラー画面、プライバシー説明、バックアップ日時、停止手順は確認できる。
開発者ツールのNetworkとSourceを開き、鍵らしい文字列や不要な個人情報が返っていないかを見るだけでも価値がある。
一方、認証方式の設計、複雑な権限、暗号鍵管理、決済、医療・本人確認、侵入試験、法令適合は専門家へ渡したい。
相談時は、コードだけでなく、利用者の種類、データ項目、外部サービス、データフロー、権限表、想定被害を提示する。
事業条件がなければ、技術レビューだけでは重要度を決められない。
境界が曖昧なら、公開範囲を狭める。
まず社内の少人数、匿名データ、読み取り専用、決済なしで試し、監視と停止が機能することを確かめてから広げる。
機能を減らすことも有効な安全対策になる。
AIへの依頼は「安全にして」で終わらせず、対象、期待する制御、確認方法を指定する。
認証と権限なら、「一般ユーザーAがユーザーBのデータへアクセスできないことを、画面の非表示ではなくサーバー側で検証してください。
対象APIを列挙し、拒否時は403を返し、自動テストを追加してください」と頼む。
秘密情報なら、「ソースコード、Git履歴、ビルド設定、フロントエンドの配信物に含まれる秘密情報を洗い出してください。
該当キーは失効が必要なものとして一覧化し、ホスティングの秘密管理へ移した後、ブラウザへ渡らない構成に変更してください」と指示する。
ログなら、「本番ログにパスワード、認証トークン、APIキー、氏名、メール、入力本文が残らないよう、記録項目を一覧化して伏字処理を追加してください。
エラー調査に必要な相関IDは残し、保持期間と閲覧権限も設定案を示してください」とすると、検収条件が明確になる。
ただし、AIが「修正済み」と答えたことは検証にならない。
変更差分、自動テスト、実際のブラウザ操作、診断結果を組み合わせ、人が合否を判断する。
結果は重大度だけでなく、到達可能性と扱うデータで読む。
同じ指摘でも、誰でも使える公開画面と社内限定のテスト環境では優先度が違う。
ただし「社内限定」を理由に放置せず、共有設定やアカウント管理が前提どおりか確認する。
誤検知はあり得るが理解できない指摘を機械的に除外しない。
ツール名、検出日時、対象URL、再現条件、影響、修正、再検査を記録する。
診断サービスがコードやデータを外部へ送る場合、保存場所、保持期間、学習利用、削除方法も確認する。
診断範囲外も明示したい。
事業上の権限ルール、プライバシー説明、バックアップ復元、運用担当者の対応、ソーシャルエンジニアリングは、自動スキャンだけでは評価しにくい。
検出件数ゼロより、未確認範囲が分かっている方が公開判断には役立つ。
安全確認は公開日で終わらない。
依存パッケージとクラウド設定は変わり、新しい脆弱性も見つかる。
月次で権限、不要アカウント、更新通知、ログ、バックアップ復元を見直し、重大な変更の前後には再検査する。
インシデント時は影響範囲を広げないことが先になる。
公開停止、キー失効、セッション無効化、アクセス遮断、証拠保全、関係者への連絡を、状況に合わせて行う。
連絡先と判断権限が決まっていなければ、技術的に停止できても対応が遅れる。
費用面の監視も欠かせない。公開APIが乱用されると、情報漏えいがなくても従量課金が膨らむ。
利用上限、レート制限、請求アラートを設定し、異常な増加を検知したら機能を止められるようにする。
AIでWebアプリを作る速度が上がったからこそ、公開前には利用者、データ、被害範囲を先に決める必要がある。
のうえで、認証と権限を分け、秘密情報、依存関係、ログ、暗号化、復元、監視、停止を順に確認する。
10項目を埋めても安全が保証されるわけではない。
むしろ、未確認の領域と専門家へ渡すべき論点を見つけることが目的だ。
扱う情報が重いほど公開範囲を狭め、第三者レビューと復元・停止訓練を加える。
公開ボタンを押せることと、公開後の責任を引き受けられることを分けて判断したい。
.png){kind=logo}
