血の気が引いた。
ダッシュボードのスクリーンショットを撮って、ハッチに送ろうとしたときだった。画面の右上に、テスト用に入れた従業員データが表示されていた。名前。部署。そして年収。
テストデータだから架空の情報だ。でも、もしこれが本番データだったら？
僕が作っていたのは、人事データの可視化ダッシュボードだった。HERP_Automationの一部として、採用候補者と既存社員のデータを一覧表示する機能。人事部長時代の経験を活かして「こういうのが欲しかった」を形にしていた。
問題は、僕が人事の感覚でデータを扱っていたことだ。
人事部にいたとき、従業員の個人情報を見るのは日常だった。名前、住所、家族構成、給与、評価。すべてExcelの中にあった。アクセス権限？ ファイルサーバーのフォルダ分けが一応あったが、正直、かなりザルだった。
その感覚のまま、Webアプリケーションを作っていた。
Dashboard shows:
- 従業員名: 山田太郎、佐藤花子、田中一郎…
- 部署: 営業部、開発部、人事部…
- 年収: ¥5,200,000、¥7,800,000、¥4,500,000…
- 評価: A、B+、A-… ⚠️ All data visible without role-based access control
URLを知っていれば、誰でもこのデータが見える状態だった。
冷や汗をかきながら、クロに指示を出した。
ハッチに相談した。
ハッチは厳しかった。でもそれは優しさだった。
[x] 個人名の匿名化（表示はID/イニシャルのみ） [x] 認証ミドルウェアの実装（未認証ユーザーはログインページへリダイレクト） [x] RBAC実装（admin / manager / viewer の3ロール） [x] 年収データの分離（/admin/salary-report、admin限定） [x] APIエンドポイントの認証チェック（フロントだけでなくバックエンドも） [x] CORS設定の見直し [ ] セキュリティヘッダー（CSP, X-Frame-Options等） [ ] 監査ログの実装
チェックリストを作った。人事時代、個人情報保護の監査対応で使っていたフォーマットと同じだ。
この経験で学んだことは2つある。
1つ目。技術的なセキュリティの知識は、プロダクトを作るなら必須だということ。「動くものを作る」と「安全なものを作る」は全く別のスキルだ。AIは指示されたものを作る。でも「セキュリティを考慮して」と言わなければ、考慮しない。それは僕の責任だ。
2つ目。人事の経験が、逆にセキュリティ意識を高めてくれたということ。
個人情報保護法。プライバシーマーク。ISMSの監査対応。人事部長時代に嫌というほどやった。「個人情報は最小限の開示に留める」「アクセス権限は職務に必要な範囲に限定する」。あのとき暗記したルールが、今になって生きている。
あの日以来、新しい機能を作るたびに「このデータが漏れたらどうなる？」と考えるようになった。
ダッシュボードを人に見せる前に気づいてよかった。テストデータだったからよかった。本番データだったら。本物の従業員の年収が、URLを知っている誰もが見られる状態で公開されていたら。
想像するだけでゾッとする。
セキュリティの穴は、空いているときには見えない。誰かに見せようとしたとき、初めて見える。だから、早い段階で人に見せることが大事なのだ。