加速する開発が見落とすセキュリティの土台
A04：2021-安全でない設計
これは特定のコードの脆弱性ではなく、開発の初期段階（設計・要件定義）でセキュリティが考慮されていないことに起因する、より根本的な問題です。これは設計を飛ばしてノリで開発するバイブコーディングスタイルで開発されたシステムによく見受けられる問題です。
AIによる高速な開発は「まず動かすこと」を最優先させ、セキュリティ要件の定義や脅威モデリングといった「安全な設計」のプロセスを省略する文化を助長する可能性があります。
これは、開発ライフサイクルの早期にセキュリティを組み込む「シフトレフト」の考え方に逆行する動きです。AIに頼ることで設計段階のセキュリティ検討が疎かになるこの問題は、LLM特有のリスクである「LLM09：偽情報（ハルシネーション）」が引き起こす「安全でないコード生成」にも直接つながる、人間側の脆弱性と言えるでしょう。
解説：曖昧な要件が脆弱なシステムを生む
「ユーザー管理機能をいい感じでお願い」といった曖昧な指示から開発がスタートする現場は少なくありません。このような要件定義の欠如は、アプリケーションの土台に脆弱性を埋める最大の原因となります。なぜなら、セキュリティは「機能」ではなく「要件」だからです。
曖昧な要件は、必然的にセキュリティに関する考慮漏れを引き起こします。
- 脅威の未定義：どのような攻撃が想定されるか（総当たり攻撃、権限昇格など）が定義されていなければ、対策の打ちようがありません。
- 信頼境界の欠如：どこからどこまでを信頼できる範囲とし、どこで入力を検証すべきかという境界線が曖昧になります。
- 不十分なテスト：仕様が明確でないため、テストは「正常に動くか」という観点に偏りがちです。「悪意ある操作をされた場合にどうなるか」という異常系のセキュリティテストは網羅されません。
ハッピーパスを満たしているシステムは一見すると要件通りに「動く」ものの、攻撃者にとっては容易に侵入できる「穴だらけ」のシステムです。
安全なソフトウェアを開発するための第一歩は、コーディングを始める前に「何を」「どのような脅威から」「どう守るべきか」を明確に定義することです。
この設計プロセスを省略することは、たとえAIの力を借りたとしても、安全でない近道を選ぶことに他なりません。開発者の責任は、AIに実装を依頼する前に、要件を明示することにあります。
開発者が意識するべき3つのセキュリティ設計
生成AIは強力な開発支援ツールですが、そのコードを無条件に信頼するのは、見知らぬ他人が書いたコードをレビューなしで本番環境にデプロイするようなものと言えます。
AIの生成物は、あくまでインターネット上の膨大なコードに基づく統計的な出力であり、非機能要件のセキュリティやアプリケーション固有の文脈を理解したものではありません。
AIとの協業で致命的な欠陥を生まないためには、開発者自身が以下の原則を徹底する必要があります。
鵜呑みにしない：コードの意図を必ず理解する
AIが生成したコードが「なぜこう書かれているのか」「他にどんな選択肢があったのか」を理解せず、ブラックボックスのままコピー＆ペーストしてはいけません。
「とりあえず動く」状態は最も危険と言えます。特にエラーハンドリング、バリデーション、アクセス制御といった部分は、細部までその挙動を理解し、潜在的なリスクを評価する責任が開発者にはあります。
任せすぎない：最終的な品質責任者は常に人間である
AIはコードを書くことはできますが、そのコードが引き起こす結果に責任は持てません。アプリケーションの安全性を保証する責任をAIに委ねることはできません。
認可ロジックやビジネスルールといったシステムの根幹に関わる部分は、AIをたたき台としつつも、最終的には人間が設計し、その正しさを保証する必要があります。
徹底的にテストする：正常系だけでなく異常系を疑う
AIは「正常に動作する」コードの生成は得意ですが、悪意ある入力や想定外のケースまで考慮しているとは限りません。
開発者は、生成されたコードに対して、セキュリティの観点から能動的に脆弱性を探すテスト（単体テスト、結合テスト、ペネトレーションテストなど）を行う義務があります。AIによって作られたからこそ、より一層の注意を払ってテストすることが不可欠となります。
結局のところ、AI時代に開発者に求められるのは、細部に対する深い理解です。SQLインジェクションがなぜ起こるのか、CORSの設定が何を意味するのか、といった基本原則を理解していれば、AIが生成した脆弱なコードをすぐに見抜くことができます。
開発者の役割は、単なるコードの書き手から、AIという強力なアシスタントを的確に監督・指導し、その生成物の品質を保証する「専門家」へと進化しています。
この新しい責任を受け入れ、セキュリティの基本原則に立ち返ることこそが、AIの恩恵を安全に享受するための唯一の道と言えるでしょう。
まとめと次回
今回は、AIが生成する「コードそのもの」に潜む脆弱性について解説しました。しかし、現代のアプリケーション開発におけるリスクは、あなたが書いたコードの内側だけではありません。
次回は、OSSライブラリの脆弱性やサプライチェーン攻撃など、「依存関係」に潜む罠について深く掘り下げます。npmパッケージの週20億ダウンロードを超える人気ライブラリが、たった一人の開発者アカウントの乗っ取りで汚染された実例など、AIの利便性が見落としがちな「コードの外側」のリスクをお伝えします。
実際の開発現場で遭遇した落とし穴や、最新の脆弱性情報については、X（@labelmake）やYouTubeでリアルタイムに発信しています。記事では伝えきれない実践的なTipsや検証結果も共有しているので、ぜひフォローしてください。
第3回もお楽しみに。AIという強力なツールを、より安全に活用するための知識を一緒に深めていきましょう。
.png)
