この記事の目次
対象と前提
AIで作ったWebサービスを、他人が使える状態にする人向けです。画面が動くことと、実データを預かって運用できることを分けます。ここでのチェックは、安全を自動判定する機能ではありません。
まず、公開するサービス名、本番のURL、管理するアカウントを一つ選びます。プレビューと本番、テスト用と利用者用のデータを混ぜないことから始めます。
仕組みをつかむ
公開前に見るのは、画面だけではない
- 公開する範囲を決める
本番URLと、預かる情報を一つずつ特定。
- 権限・秘密
拒否の結果と、配信される内容を確認。
- 料金・復旧
利用制限と、隔離した復元テストを確認。
確認できた範囲から公開します。未確認を、問題なしの印に置き換えません。
AIへレビューを依頼する場合も、「セキュリティを見て」だけで終えず、下表の対象と根拠を示してもらいます。管理画面の実物やテスト結果と照合できない説明は、確認済みにしません。1回のレビューの合格が何を確かめていないかは、AIレビューの合格の教材で扱います。
想定リスク
表がはみ出す場合は、横にスクロールして読めます。
| 対象 | 起こりうること | 確認する証拠 |
|---|---|---|
| 公開ページと保存ファイル | 非公開の予定だった資料が見える | ログアウト状態での閲覧結果 |
| 会員データ | 他人の記録を読む・変える | テスト用A/Bでの拒否結果 |
| AIや外部API | 無制限の利用や繰り返し処理で料金が増える | 利用制限と監視の設定 |
| バックアップ | 保存したつもりの画像が戻らない | 対象範囲と隔離した復元テスト |
| 更新 | 依存やランタイムの変更で壊れる | 変更内容・動作確認・戻し方 |
過去の事例から学ぶ
分類：事故の公表。 GitLabは2017-01-31のデータベース障害とデータ損失を報告し、バックアップの発見と復元にも問題があったことを説明しています。当事者の振り返りに基づく過去事例です。
個人開発と同じ構成の事故ではありませんが、「バックアップがある」と「必要なデータを戻せる」を分ける重要性を学べます。現在のGitLabの安全性をこの過去事例だけで評価しません。
誰が何を確認するか
表がはみ出す場合は、横にスクロールして読めます。
| 役割 | 確認すること | 方法 |
|---|---|---|
| 公開を決める人 | 誰に何を提供し、何を預かるか | 公開範囲と収集項目の一覧 |
| 作る人 | 権限・秘密・入力処理・依存 | 設定、実装、テストの照合 |
| 運用する人 | 料金、通知、バックアップ、停止・復旧 | 各提供元の管理画面と手順 |
一人でも、見る役割を切り替えよう。
一人で兼任していても、役割ごとに対象を切り替えて確認します。分からない設定をAIの説明だけで変更せず、提供元やレビューできる人に確認します。
一つ確かめてみる
「ある」だけでは、足りない二つの確認
- 料金の通知
利用を止める上限と同じとは限らない。
- バックアップ
DB・画像・設定を必要な範囲まで戻せるか。
料金は「通知」と「上限」を分けます。 例えばGoogle Cloudは、通知だけの予算と、対象サービスで使える支出上限を区別しています。公式資料に従い、自分の契約で何が対象かを確認します。他サービスでも同じ停止条件とは限りません。利用量の反映遅延や、対象外の料金も確認します。
復旧はデータベース（DB）とファイルを分けます。 例えばSupabaseの説明では、DBバックアップにStorage APIのファイル本体は含まれません。利用するサービスで保存範囲を調べ、架空データを隔離した場所へ戻すテストを計画します。本番を練習の復元先にはしません。
確認チェックリスト
- 公開範囲： 本番URL、プレビュー、管理画面、添付ファイルを区別し、未ログイン時の見え方を確かめた。
- データ： 集める目的と必要な項目を説明でき、不要な個人情報を集めていない。
- 認可： テスト用A/Bと未ログインで、許可しない閲覧・編集・削除が拒否される。
- 秘密： 配信コード、履歴、ログ、エラー画面に秘密が含まれないことを点検した。
- 入力： 想定外の長さ・空欄・形式違いをテスト用データで確認し、サーバー側でも検証している。
- 料金： 課金対象、通知先、利用制限の範囲を管理画面で確認し、止める操作と影響を把握した。
- 依存と更新： 利用するランタイム・ライブラリと更新先を把握し、変更前後の動作を比較できる。
- 復旧： DB・ファイル・設定の保存範囲と保持期間が分かり、戻せることを隔離環境で確かめた。
- 対応窓口： 異常時の連絡先と、公開範囲を狭める方法が分かる。
次の行動
未確認項目が利用者の情報や料金に直結するなら、実データの受付や広い公開を見合わせ、確認できる範囲から始めます。公開後は異常時の対応と、使う実行環境の更新情報を確認します。
一次資料
- OWASP：認可の原則
- Google Cloud：予算・通知・支出上限の区別
- Supabase：バックアップの対象と復元
- GitLab：2017年の振り返り
- npm：依存の脆弱性監査 — 依存確認の一例。監査結果だけでアプリ全体の安全を保証しない
書いた人
マーケティングの現場から、AIをつくり、仕事で使う側へ。実際に試したことや、つまずいたことを、図解と具体例で伝えています。
この記事のURL：https://nekoai-lab.github.io/ai-security-playbook/learn/launch-checklist/
続けて読む
次に読む外部サービスが止まったら、自分のアプリはどうなる？
読む順番・ルートを見る
AIで作って公開する基本
- AIに渡す情報を、送る前に分ける
- 「学習しない」AIなら、仕事の個人情報を使える？
- AIで作ったアプリの、動く場所を知る
- AIに「APIキーを設定して」と言われた。どこに入れるのが正解？
- APIキーを替えたのに、古いキーが使われている？
- ログインと、データを使う権限を分ける
- 公開したのは、本当に見せたいファイルだけ？
- コードには書いていない。名前やメールは、どこから公開される？
- 緑のチェックが付いた。その変更を公開していい？
- AIレビューが合格した。その結果を、どこまで信じていい？
- AIにデプロイを頼んだ。その認証情報は、どこまでできる？
- AIで作ったサービスを、公開する前に確かめる
- 外部サービスが止まったら、自分のアプリはどうなる？
- 漏えい・異常・消失に気づいたとき、最初にすること
