セキュリティを学ぶ意味は、AIがコードを書く時代に薄れたか

AIにコードを書かせるのが当たり前になって、脆弱性診断までAIがやってくれるという話も増えてきた。そうなると、セキュリティという分野はどんどん専門のセキュリティエンジニアに閉じていき、普通の開発者がわざわざ時間を割いて学ぶ意味は薄れていく——という空気を感じることがある。コードはAIが書き、危ないところもAIが見つけてくれるなら、自分が覚えることは減るはずだ、という理屈だ。

この理屈は一見筋が通っている。だが実際にAIが書くコードの量が増えていく過程を見ていくと、むしろ逆の現象が起きていることに気づく。

AIが書く量が増えるほど、人が見る量も増える

脆弱性には、大きく二つの種類がある。一つは「書き方が悪い」タイプの不備だ。SQL文の組み立て方が甘くてインジェクションが入る、入力値をエスケープし忘れていてXSSが刺さる、といった類のものだ。これはコードの書き方そのものにパターンがあるので、AIによる静的解析や生成時点での注意喚起がよく効く。実際、この手の不備はAI支援が入ることで以前より減っている実感がある人も多いはずだ。

もう一つは「設計が悪い」タイプの不備だ。この管理者機能に、本当に管理者権限のチェックが入っているか。このAPIは自分のテナントのデータだけを返しているか、他社の情報が混ざっていないか。こうした不備は、コードの書き方の問題ではない。「そもそも何を許可し、何を拒否するつもりだったか」という意図と、実装が本当に一致しているかという検証の問題だ。

AIはコードを「書く」ことには長けている。だが、仕様書にも書かれていない業務上の意図を正しく推測し、それが本当に実現されているかまで検証する作業は、原理的に別の種類の仕事になる。AIが書くコードの量が増えれば増えるほど、この「意図と実装の一致」を検証すべき箇所の絶対数も増えていく。書く量を減らすテクノロジーは、検証する量を減らすテクノロジーではない。両者は別の軸にある。

「AIが書いたから安全」という奇妙な安心感

ここで厄介なのは、AIが書いたコードには一種の「それっぽさ」があることだ。構文は整っていて、命名は自然で、一見プロが書いたような見た目をしている。この見た目の整い方が、レビューする側の警戒心をわずかに緩める。人間が書いた雑なコードなら「ここ怪しいな」と目が止まるところを、AIが書いた整ったコードだと素通りしてしまう。

これは誰にとっても起こりうることで、経験の長さとはあまり関係がない。むしろ経験が長い人ほど「AIならきっと一般的なやり方に沿っているはずだ」という推測が働きやすく、権限チェックの有無を律儀に追う手間を省略してしまうことがある。AIの出力を疑わずに受け入れる癖がつくと、見た目の整った不備を見逃す確率はむしろ上がる。

つまり、AI時代に求められているセキュリティの知識は、「自分で安全なコードを書く力」よりも、「出てきたコードや設計が、本当に意図通りに権限や境界を守っているかを疑い、検証する力」の方に重心が移っている。これは書く力の延長ではなく、読む・疑う・確かめるという、もう少し地味な基礎教養の話だ。

任せていい所と、人が握る所の線引き

とはいえ、「だから全員が深くセキュリティを学べ」という話にしてしまうのも乱暴だ。実際、AIによる診断や静的解析は、よくあるパターンの不備を見つける作業では十分に役に立っている。書き方の問題は、AIに任せていい領域が広がっている。

人が握っておくべきなのは、その手前にある「そもそも何を守りたいのか」という意図の部分だ。この機能は誰が触れるべきで、誰が触れてはいけないのか。このデータは誰のものとして扱われるべきなのか。認証と認可はどの境界で切れているのか。こうした設計判断は、コードの外側にある業務の文脈を理解していないと下せない。AIに「このコードに脆弱性はありますか」と聞くことはできるが、「この機能はそもそも誰が使う前提ですか」という問いには、人間が答えを持っていないと始まらない。

学ぶべきは、セキュリティの全領域を暗記することではなく、この線引きの感覚そのものだ。権限設計、テナント分離、認証とセッションの境界、業務ロジックの不備——このあたりは、AIに任せるのではなく人が最後まで検証する領域だと知っておくこと。逆に、エスケープ処理や典型的なインジェクション対策のような、パターンがはっきりしている部分は、AIの指摘を活用しながら素早く潰していけばいい。この境界を自分なりに持っているかどうかが、AI時代のセキュリティ理解の実質になる。

ちなみに、この「パターン化しづらい領域ほど人の理解が要る」という構図は、学習リソースの実態にも薄く表れている。情報処理安全確保支援士の合格体験記で実際に引用されている教材をtasklogで集計すると、引用が集中しているのは目新しい本ではなく、毎年内容が変わらない定番の午後問題集やネットワーク基礎書だ。AIが生成するコードが増えても、人が理解すべき基礎の輪郭自体はあまり動いていない、という見立てを補強する材料だと思う。

境界線を持つための最初の一歩

AIがコードを書く時代だからセキュリティを学ばなくていい、という考え方は、半分だけ正しい。パターン化された書き方の不備については、確かにAIに任せられる範囲が広がっている。だが、権限設計やテナント分離、業務ロジックの不備といった「意図と実装の一致」を検証する仕事は、AIが書く量が増えるほど、むしろ人に求められる量が増えていく。

セキュリティを学ぶというのは、もう一人のエンジニアになるための専門訓練ではなく、AIが出してきたものを無条件に信じない習慣を身につけることだ。まずは自分が普段触れている機能について、「これは誰が使う前提で、誰を拒否するべきなのか」を一つ言語化してみるところから始めてもいい。

体系的に基礎を固めたいなら、情報処理安全確保支援士の参考書で実際に引用の多いものから手を付けるのも一つの道だし、手を動かしながら学びたいならセキュリティ講座を比較して自分に合うものを探すのもいい。

https://s-tasklog.com/certs/sc

https://s-tasklog.com/courses/security

tasklogは、資格の合格体験記や技術記事に登場する参考書・講座の引用を集計し、学習リソースの実態を可視化しているサービスだ。今回触れた引用の集計も含め、どの教材が実際に支持されているかは自分の目で確かめられる。