6月18日、Auth0が「The Part of Software Engineering AI Cannot Replace」と題した記事を公開した。Auth0はOktaグループ傘下のIDおよび認証プラットフォームであり、セキュリティ実装を日常業務とするエンジニアチームが知見を発信している点で、この種の「AIとセキュリティの交差点」に関する論考を語るのに高い信頼性を持つ媒体だ。記事の主張は明快で、AIがコード生成を担えるようになった今、ボトルネックはエンジニア自身の判断力に移ったというものだ。
AIが代替したのは「コーディング」であって「エンジニアリング」ではない
著者はAuth0（Okta）のエンジニアで、2022年当時はコードサンプルの作成とブログ執筆が主な仕事だったという。当時はシンプルなアプリでもスキャフォールディングからAPIエンドポイントの実装まで相当な時間がかかっていた。それが今ではClaude Codeを使えば数分で完成する。
ここで重要な問いが立ち上がる。AIが奪ったのは「コードを書く作業」であり、「何を作るか」「なぜ失敗しているか」「どのトレードオフを選ぶか」「そのコードは安全か」という判断は奪っていない、と著者は言う。
むしろ、今やボトルネックはエンジニア自身の判断力に移った。LLMが生成するコードはブラックボックスになりやすく、その判断の重みは以前より増している。
ジュニアエンジニアへの影響：「動くアプリを作れる」≠「システムを理解している」
著者が指摘する構造的な問題がある。ジュニアエンジニアがシステムの複雑さを理解する前に、動くアプリ全体を生成できてしまうという現実だ。
短期的な生産性は上がる。しかし「理解していないコードはリリースできない」、より正確に言えば「理解していないシステムはエンジニアリングできない」。
学習パスが変わったとも言える。スクラッチでコードを書いて覚える時代から、生成されたコードを読み、疑問を持ち、意図的に壊して学ぶ時代へ。機会は残っているが、能動的に「中身を理解しようとする姿勢」が必要になった。
著者はエンジニアリングの設計プロセスを以下の4段階に整理している：
- 問題定義：何を作るか決めるのは人間。ニーズを理解しているのは人間だけだ
- 概念設計：AIとブレストはできるが、解決策が問題にどう対応するかを理解するのは人間
- 詳細設計：ここが最もAIに負荷を移せる段階。実装・レビュー・反復をAIと協働する
- 学習と一般化：プログラム分析と保守。人間の問題理解とAIサポートの両方が必要
つまり、現代のエンジニアはタイプする時間より、読み・評価し・決断する時間の方が長い。スピードが上がった分、判断の価値が相対的に増した。
セキュリティこそ、AIの「自信」が崩れる場所
あらゆる工程（アーキテクチャ決定、パフォーマンストレードオフ、データモデリング）に判断は必要だが、セキュリティは失敗のコストが最も高い領域として著者は取り上げる。
AIが生成したコードはlintを通過し、テストもパスする。しかし入力バリデーションの抜け、レースコンディションといった振る舞いレベルでは見えない脆弱性が潜むことがある。コードは動く。ただ安全ではない。
AIはハッピーパス（正常系）の外にある攻撃面を想定しにくい。著者が「vibe coding」と呼ぶ、感覚や直感に頼りAIと対話しながら進めるスタイルのコーディング——その文脈で著者は特に生成コードを十分に精査せずセキュリティクリティカルなパスに適用することのリスクを強調している。
OWASP Top 10 for Agentic ApplicationsはAIエージェントを構築するエンジニア向けに書かれたものだが、コーディングエージェントを日常的に使うエンジニアにも参照価値がある。エージェントが起こしうる失敗を知ることで、自分のコードで何を見落としているかが分かる：
- 予期しないコード実行：レビューしていないコードの生成・実行、求めていないパッケージのインストール、不要なシェルコマンドの実行
- ツールの誤用：与えた権限の範囲内で動くが、その権限を賢く使うとは限らない。読み取り専用で十分な場面で書き込みアクセスを使う等
- 不適切な出力処理：有効そうに見えるコードでも、サニタイズされていない入力、ハードコードされた秘密情報、正常系では動くが敵対的な条件下で壊れるロジックが含まれることがある
エンジニアの新しい役割：「実装者」から「監査者」へ
監査は、実装を学ばないまま取り組むと実装より難しい、と著者は明言する。
セキュリティの文脈で言えば、脆弱性がどんな形をしているか知らなければ、生成コードの中に脆弱性を見つけられない。監査者として自分に問うべき問いは具体的だ：
- このツールに書き込みアクセスは本当に必要か？
- この入力はシェルに渡る前にバリデートされているか？
- なぜこのパッケージが引き込まれているのか？
- プロンプトが操作されても安全か？（AIアプリケーションを構築する場合）
スタック選定もその性質が変わった。以前は「どれだけ時間がかかるか」が議論の中心だったが、エージェントが何でもスキャフォールドできる今、問いは「そのスタックをエージェントが書いたコードを監査できるほど理解しているか」に移っている。
コーディングが速くなっても、エンジニアリングが楽になったわけではない。価値は「リリースしなかったコード」にある。なぜ間違っているかを理解したから、リリースしなかったのだ。コードを書くことしか学んでこなかったなら、今やツールと競争する立場になる。
AIの判断力が将来このギャップを埋めるかもしれない。しかし現時点では、モデルはあなたのシステムも、ユーザーも、脅威モデルも知らない。それを知っているのはエンジニアだけだ。
詳細はThe Part of Software Engineering AI Cannot Replaceを参照していただきたい。
