これからのエンジニアはまずセキュリティに踏み込む

まずはセキュリティから

これからのエンジニアの仕事は、UXを作ったり、デザインを作ったりと、どんどん範囲が広がっていくと考えている。以前書いたWebプロダクト UI における Figma 不要論でも、職能の枠を超えられるビルダーだけが残るという話をした。

その中で、私がまず踏み込むべきだと考えているのがセキュリティだ。UXやデザインももちろん大事だが、優先度はセキュリティのほうが高いと思っている。使いにくい画面は後から直せるが、漏れた情報は取り戻せないからだ。セキュリティに責任を持ち、そこを軸に仕事を広げていく。それがこれからのエンジニアの姿だと考えている。
昨今、セキュリティの事故や、仕様の不備が原因のインシデントは本当にたくさん起きている。そして私見だが、その中身も、アプリケーションの不備が入口になる事案が増えてきているように感じている。データにはまだはっきりと表れていないが、そう考えている。

大規模な漏えいの入口がアプリケーションに

2026年9月前後、国内で不正アクセスによる大規模な個人情報の漏えいが相次ぎ、10月には個人情報保護委員会やJPCERT/CCなどが一斉に注意喚起を出した。経緯はpiyologのまとめが網羅的なので、詳しくはそちらに譲りたい。

注意喚起で挙げられた侵入経路の1つに、APIの認可の不備や、レスポンスに不要な情報が含まれていたといったアプリケーションの不備がある。攻撃者が事前に作成したアカウントでログインし、ログイン後の機能を探っていたという観測もある。
どれも高度な脆弱性ではない。仕様と実装を担うエンジニアが塞げる穴である。

もちろん、既製ソフトウェアの脆弱性や盗まれた認証情報など、ほかの入口も多く使われている。ただ、アプリケーションの穴だけは、それを作ったエンジニアにしか塞げない。

データベースを暗号化しても情報は抜かれる

アプリケーションの脆弱性を突く攻撃は、正規にログインしたのと同じ状況で行われることが多い。
セッションのクッキーを持った利用者として、アプリケーションに「正しい」リクエストを送ってくるのだ。

なので、データベースを暗号化していたとしても、アプリケーションが復号して返してしまう以上、情報はそのまま抜かれてしまう。
保存時の暗号化はディスクやバックアップの流出には有効だが、アプリケーション層の権限の不備に対してはほとんど意味を持たない。

だからこそ、アプリケーションを作るエンジニアとしては、まずアプリケーション層を徹底的に対応するのがよいと考えている。
認可のチェックが全てのエンドポイントで漏れなく行われているか、不必要な情報がUIに出ていないか、レスポンスに使っていない個人情報のフィールドはないか、パラメーターの受け取り方（RailsでいえばStrong Parameters）に穴はないか。地味だが、こういったところを1つずつ潰していくことが一番の対策になる。

長く持ち続ける要件を疑う

もう1つ、私がエンジニアの重要な仕事だと考えているのが、個人情報を長く持ち続けるような要件に疑問を持ち、問題があれば提言することだ。

わかりやすい例が、タイムズカーの漏えいである。約660万アカウントの情報が取得され、そのうち約160万件で運転免許証などの本人確認書類の画像が流出した。対象には現会員だけでなく、退会した人も含まれていた（ITmedia NEWS）。

退会者の免許証画像は、退会後7年間保管されていた。氏名や住所、生年月日については税法上の保存義務があると説明されているが、免許証画像には法令上の取り決めがなく、なりすまし対策や問い合わせ対応のために自社の判断で保存していたという（共同通信）。

7年保管という要件は、決めた時点ではもっともらしく見えたのだと思う。「なりすまし対策のため」「問い合わせが来たときのため」と言われれば、反対しにくい。
だが、その「念のため」の積み重ねが、漏れたときの被害を大きくする。

要件に「何のために、いつまで」を問う

こうした要件に一番早く気づけるのは、テーブルを設計し、保存先を決めるエンジニアだ。どの情報を、どこに、いつまで置くのかを実際に形にしているのは私たちである。

だから、仕様を受け取ったときには次のことを問いかけたい。

その情報は何のために必要で、いつまで必要なのか
保存の根拠は法令上の義務なのか、それとも自社の判断なのか
画像そのものではなく、確認済みであるという結果や必要な項目だけを残すことはできないか
どうしても残すなら、外部から届かない場所に置き、必要なときだけ取り出す形にできないか

そのうえで懸念があればステークホルダーに伝え、持つものは持つ、持たないものは持たない、と提言する。必要のない情報は保存を推奨しない、そもそも保存できないようにする、保存したとしても短期間で破棄する。
こういった提案ができることが、ユーザーを守り、そして会社をセキュリティリスクから守ることにつながる。

今回の注意喚起でも、国家サイバー統括室は保有する情報が少なければ漏えい時の被害の拡大を抑えられるとして、利用目的を終えた情報の削除を求めている。持たないことは、最も確実な漏えい対策なのだ。

生成AIで誰でもプロダクトを作れるようになった今だからこそ、漏れたときに何が起きるかまで考えて要件に向き合えることは、エンジニアならではの強みになるはずだ。

まとめ

大規模な漏えいでは、APIや認可などアプリケーションの不備が目立つ。その穴を塞げるのは、仕様と実装を担うエンジニアである。
ログインした状態で情報を抜かれるので、データベースの暗号化では守れない。アプリケーション層を徹底的に対応する。
個人情報を長く持ち続けるような要件には「何のために、いつまで」を問い、問題があれば提言して会社をセキュリティリスクから守る。

まずはセキュリティに踏み込み、責任を持つ。そこを軸に仕事を広げていくことがこれからのエンジニアのあり方なのだと私は考えている。