納品前のセキュリティチェックリスト、制作会社の標準化キット──確認項目表、レビューの手順、顧客向け「安全性の説明書」、AIレビュー用プロンプト

この記事は、納品前のセキュリティチェックリストと、それを会社の標準・顧客への説明・単価の根拠に変えるための型一式を扱います。

SQLインジェクション、XSS、CSRF、ファイルアップロード、セキュリティヘッダーの考え方は、無料の記事で一本ずつ扱っています。

▶ SQLインジェクション対策を「担当者の腕」に任せない制作会社へ──プレースホルダを社内標準にし、レビューで確かめ、顧客に説明できる品質に変える

メンバーシップ「黒字化オペ室」では、これまでの有料記事を全て読めます。価格、外注、採用、給与を、一本の流れとして。

月額1,980円、単品記事2本分の金額です。合わなければ、いつでも退会できます。詳しくはプロフィールから。

「セキュリティは大丈夫ですか」に、紙1枚で答えられるか

大きめの案件の提案や、上場企業の子会社との取引では、セキュリティの確認票が届くことが増えています。
そのたびに、社長がエンジニアに聞き、記憶をたどって埋めていないでしょうか。
答えに時間がかかるほど、「この会社に任せて大丈夫か」という不安が相手に残ります。

確認票に毎回ゼロから答える会社と、自社の標準と納品前の記録を添えて返す会社。
同じ品質で作っていても、顧客から見える信頼は、まったく違います。

納品前セキュリティチェックとは、自社が決めた「安全な作り方」が、その案件で守られたことを、書いた人以外が確かめて記録に残す工程である

黒字化の外科医です。納品前のセキュリティチェックを、品質と単価の根拠にする仕組みとして解剖します。

なお私は弁護士ではありません。実務の指針として読み、個別の判断は専門家や公的な窓口に確認してください。

チェックリストを会社の仕組みにすべき理由は、三つあります。

第一に、確かめる物差しが、公的な資料にあるから。
IPAの「安全なウェブサイトの作り方」（改訂第7版）は、11種類の脆弱性について、根本的解決と保険的対策を示し、巻末に実装状況を確かめるチェックリストを付けています。
自社で一から考える必要はありません。公的な物差しを、自社の案件に合わせて絞り込めばよいのです。

第二に、記録がなければ、確かめたことにならないから。
口頭の「見ました」は、担当者が辞めれば消えます。誰が、いつ、何を確かめ、何を例外にしたか。この記録が、事故のときにも、次の提案のときにも効きます。

第三に、記録は、そのまま顧客への説明書になるから。
「当社はこの標準で作り、この手順で確かめています」と1枚で示せる会社は、価格だけで比べられにくくなります。確認の工数を、見積もりの項目として堂々と載せられます。

今すぐ試せる：自社の案件に合わせてチェック項目を絞り込むプロンプト

私はWeb制作会社の経営者です。納品前のセキュリティチェックリストを、
自社の案件の種類に合わせて絞り込んでください。

【前提】
・主な案件の種類（コーポレート／採用／EC／会員制／予約 など）：〔　　〕
・主に使うCMS・フレームワーク・言語：〔　　〕
・自作・改修することが多い機能（フォーム、検索、会員、アップロード など）：〔　　〕
・外注先に開発を出すか：〔　　〕

1. IPA「安全なウェブサイトの作り方」が挙げる11種類の脆弱性のうち、
   自社の案件で確認が必要なものと、通常は対象外のものに分ける。
2. 対象外にする理由を、1行ずつ書く。
3. 案件の種類ごとに、必ず確認する項目を5〜10個に絞る。
4. セキュリティヘッダーなど、運用の設定で確認する項目を別に挙げる。

攻撃の方法や再現手順は書かないこと。

このプロンプトの結果は、下の「確認項目表」の、どの行を残すかを決める下書きになります。

ここから先に、納品前の確認項目表、レビューの進め方と記録の型、顧客向け「安全性の説明書」の型、社内標準の文書テンプレート、AIレビュー用のプロンプト、見積もりへの載せ方を置きます。