なぜこう書くのか
セキュリティのチェックリストをAIにそのまま頼むと、大抵は教科書的な目次が返ってきます。20個前後の項目のうち半分は使ってもいない機能に関するもので、肝心の今回のリリースで危険な箇所が抜け落ちてしまいます。リストを読み終えた後に「結局何を確認すればいいのか」が残りかねません。
役割を「少人数チームのリリースをレビューしてきた担当者」としたのは、対応可能なボリュームに抑えるためです。大企業のセキュリティ監査人の視点で答えると、組織ポリシーやドキュメントの要求が先行し、数人のチームでは到底手が回らない項目ばかりになります。実行不可能なリストは一度目を通して放置されるだけなので、最初から守れる範囲で抽出する方が実用的です。
リストをいきなり作成させず、攻撃経路の洗い出しとチェック項目の作成の2段階に分けたことがポイントです。経路を先に書かせることで、ログイン方式、ファイルアップロードの有無、管理画面の露出など、自チームの構成特有の弱点が浮き彫りになり、それに紐づく項目が作成されます。順序を逆にすると、一般的なリストにサービス名だけを当てはめたような結果になってしまいます。
出力形式の「確認方法」列が、リストを具体的な作業へと変えます。「入力値を検証する」といった記述は読んでも次に何をすべきか分かりませんが、どこを開いて何を見ればよいかが書かれていれば、そのまま手順に沿って作業できます。最後のセルフチェックの指示は、最初の段階で無意識に含まれてしまった不要な項目をふるい落とすための仕組みです。ただし、ChatGPTで作成したWebセキュリティチェックリストはあくまで出発点にすぎないため、個人情報や決済を扱う場合は別途専門家による診断を受ける必要があります。
用語が分からなければAha AIで: role-prompting, output-format
悪い例との比較
Webサービスのリリース前に確認すべきセキュリティチェックリストを教えて
どこにでもある汎用的なリストが出力されます。使っていない機能の確認に時間を取られ、独自実装したログイン機能や管理画面といった最もリスクの高い箇所が見落とされます。各項目に「何をどうやって確認するのか」がないためチーム内で分担もできず、結局詳しいメンバー1人が感覚で確認してリリースすることになります。
バリエーション
すでにリリース済みのサービスを点検する場合
すでに稼働中の {{サービスの種類}} を事後点検しようとしています。構成は {{技術スタック}} で、扱う情報は {{扱うデータ}} です。サービスを停止せずに確認できる項目と、メンテナンス時間を確保すべき項目に分けてください。各項目で問題が見つかった場合の暫定的な対処法を1行ずつ書き添えてください。
運用中とリリース前では確認の順序が変わります。サービスを止めずに見られる部分から着手することで、点検の後回しを防ぎます。
コードレビューで見るべきポイントだけを抽出する場合
{{技術スタック}} で書かれたコードにおいて、セキュリティ上の問題が発生しやすい箇所をコードレビュー用のリストとして作成してください。ファイルや関数の種類ごとにグループ化し、「このようなコードが見られたら要注意」という形式の短い文で記述してください。項目は10個以内とし、{{扱うデータ}} を扱う部分に該当する項目を前方に配置してください。
リリース直前ではなく、コードを読む段階で使うリストです。チームのレビューガイドラインにそのまま組み込めます。
モデル別の注意
ここで得られたリストは自社で確認するための出発点であり、正式なセキュリティ診断書ではありません。個人情報や決済データを扱う場合は、別途セキュリティ専門家による診断を受けてください。
関連プロンプト
最終更新 2026-09-02 · 誤りがありますか? 知らせる