セキュリティ・個人情報を含む開発で、発注前に決めること

「まず作って、セキュリティは後で。」——個人情報や機微データが絡む開発で、これをやると手戻りが最も高い部類に入る。本番コピーを検証環境に載せ、委託先の権限が広すぎ、ログが残っていない。後から直すコストは、最初に決めるコストの何倍にもなる。

要件が全部固まっていなくても、データ分類・環境分離・監査可能性は発注前に仮決めできる。

セキュリティは機能一覧の後ろに付け足す項目ではない。発注の前提条件だ。

結論：発注前に決める項目

項目	決めること
データ分類	何が個人情報／機微か。マスクや仮名化の方針
環境分離	開発・検証・本番で実データをどう扱うか
権限	委託先が触れる範囲。最小権限の原則
監査	誰が・いつ・何にアクセスしたかを追えるか
インシデント	連絡網と初動。契約上の通知義務
生成AI等	外部サービスに貼ってよいデータの境界

全部のポリシー文書が揃っていなくても、上表の仮決めはできる。仮決めがないまま「いい感じに」は危険だ。

事例1：本番コピーで炎上

匿名化した一例。検証を急ぐため本番DBをマスクなしで検証環境へ。委託先の複数名が閲覧可能だった。社内監査で指摘され、プロジェクトは2ヶ月停止。作り直しより、信頼と手続きのコストが大きかった。

分岐点は発注前の環境方針だ。「検証に実データは使わない／使うならマスク必須」を一文入れていれば、止まった理由は別になっていた。

事例2：段階的に権限設計したケース

別の一例。最初のスプリントはダミーデータのみ。個人情報を扱う機能の直前に、権限・ログ・委託範囲をレビューしてから実装。速度は落ちたように見えて、手戻りは少なかった。

判断軸

発注を進めてよい	止めて先に決める
データ分類と環境方針が仮決めされている	「後でセキュリティ」が前提
委託先の権限と監査の要求がRFPにある	本番データ前提の検証が暗黙
インシデント時の連絡が契約にある	外部AIへ貼る境界が現場任せ

次に確認すること

1. 取り扱うデータの分類表はあるか
2. 検証環境のデータの扱いを一文で言えるか
3. 委託先アカウントは最小権限か
4. アクセスログの要件はあるか
5. 外部ツール（生成AI含む）への持ち出しルールはあるか

まとめ

個人情報を含む開発の失敗は、暗号化アルゴリズムの知識不足より、発注前の仮決め不足で起きることが多い。分類・環境・権限・監査を先に置く。要件書が薄くても、そこだけは厚くしてよい。

---

セキュリティ前提の要件整理の相談は、お問い合わせフォーム からどうぞ。