AIが書いたコードは安全なのか？AI時代に必要なセキュア開発力とは

AIがコードを書く時代において、エンジニアには「そのコードがセキュアであるかどうかを見極める力」、すなわちセキュア開発力がこれまで以上に求められています。

私たち神戸デジタル・ラボ（以下KDL）ではこのセキュアにシステム開発を行う力を高めるため、10年以上にわたり試行錯誤を重ねてきました。その結果たどり着いた答えは、「トレーニングによってセキュア開発力を鍛える」ということです。本ブログでは、AI時代においてどのようなスキルが必要なのか、私たちがどのようなトレーニングを行っているのかをご紹介します。

AIでコードを書いてみた

近年、開発現場ではAIを活用するシーンが着実に増えてきています。KDLでも業務導入を進める一方で、社内で「まずは気軽にAIを試してみよう」というチャレンジングな取り組みを色々と行っています。その中で、「AIだけでアプリを作ったらどうなるのか？」といった実験的な試みも実施しており、ここでその一部をご紹介します。

アプリを自作してみました

セキュリティクイズアプリをAIに生成させました。CDKのコードからバックエンド、フロントエンドまで、人間は1行も書かずに完成しました。

社内バイブコーディングコンテスト開催！

このようなコンテストも開催しました。2週間の実装期間を経て、実装された多種多様なアプリやツールは12個。各参加者が作ったアプリの紹介動画を共有・評価し合いました。

詳細については下記のブログで紹介しています。

AIが書いたコードはセキュアなのか

AIによるコード生成は、スピードや効率の面で大きなメリットがあります。しかしその一方で、「本当にそのコードは安全なのか」という観点ではどうでしょうか。生成されたコードをレビューしてみると、基本的なセキュリティ対策が抜けていたり、法的リスクにつながるライブラリが含まれていたり。

現在（2025年9月時点）では、ノーチェックでAIが書いたコードを採用することはできない、と判断しました。具体的には以下のような問題が確認されています。

• JWTの検証で署名の検証を実装していない（しかも敢えて）
  → 改ざんされたTokenを検知できず通過してしまうリスク
• 入力値検証が実装されていない
  → 最も基本的なセキュリティ対策が欠如し、脆弱性につながる
• セキュリティヘッダが付与されていない
  → Content-Security-Policyを含む重要なヘッダが不足
• GPLライセンスのパッケージが利用されている
  → 商用利用における法的リスク
• アクセスキーをハードコードするように求められることも
  → 深刻な情報漏洩の危険

それぞれのリスクについて、もう少し具体的に解説します。

JWTの検証で署名の検証を実装していない

JWT（JSON Web Token）は認証や認可の仕組みで広く使われていますが、署名の検証を省略すると「改ざんされたトークン」を正規のものとして受け入れてしまいます。例えば、攻撃者が有効期限を延長したトークンや、権限を“管理者”に書き換えたトークンを作成した場合でも、署名をチェックしていないために素通りしてしまいます。これは、認証基盤そのものを形骸化させる非常に危険な実装であり、最も注意が必要なポイントです。

入力値検証が実装されていない

入力値検証はセキュリティの基本中の基本です。これが欠如すると、SQLインジェクションやクロスサイトスクリプティング（XSS）、バッファオーバーフローなど、あらゆる攻撃の入り口となります。たとえば、ログイン画面で入力チェックを行わなければ、攻撃者が特殊な文字列を入力するだけでデータベースに不正アクセスできてしまうこともあります。AIが生成したコードは入力値の扱いが雑である場合があり、この点を放置すると重大な脆弱性を抱えたまま運用してしまうリスクがあります。

セキュリティヘッダが付与されていない

セキュリティヘッダは、Webアプリケーションを攻撃から守るための最後の砦です。特に Content-Security-Policy (CSP) が未設定だと、悪意あるスクリプトを自由に実行されるリスクが高まります。また、X-Frame-Options がなければクリックジャッキングの危険性が増し、Strict-Transport-Security (HSTS) がなければHTTPにダウングレードされて盗聴される可能性も残ります。

AIが生成するコードは機能実装が中心で、こうした細かいセキュリティヘッダの設定が抜け落ちることが多いため、人間による補完が不可欠です。

GPLライセンスのパッケージが利用されている

AIが提案するライブラリの中にはGPLライセンスが含まれることがあります。GPLはコードの公開を義務付けているため、商用サービスにそのまま組み込むとソースコード全体を公開しなければならない可能性があります。これは企業にとって深刻な法的リスクにつながり、知らないうちにコンプライアンス違反を引き起こす危険があります。

アクセスキーをハードコードするように求められることも

AIが生成したコードの中には、環境変数ではなくコード内に直接アクセスキーを書き込むようなものもあります。これは最悪の実装パターンで、一度リポジトリが公開されたり漏洩したりすると即座に不正利用される危険があります。アクセスキーやパスワードなどの秘密情報は必ず安全に管理し、コード内に直接記述しないことが大原則です。

以上のような点から、（2025年9月時点）ではノーチェックでの利用はできません。

AIが書いたコードであっても、責任は私たち開発者

AIを活用したシステム開発を行う上で私たちに求められるのは、

• AIにセキュアなコードを書かせること
• AIが書いたコードを適切にチェックすること

です。つまり、人間に「このコードがセキュアなのか？」を 判断する力 セキュア開発力 が必要です。

すでにセキュア開発を実践している方にとっては、従来の開発と特にかわりはありませんし、問題もないでしょう。ただし、AIの登場によってコードを書いたことがない人でもアプリを作れる時代になりました。そこに、セキュアでないコードが混じったとしても、わからないままになる可能性があります。 そのために、従来コードを書いていない方にこそセキュア開発力が必要になります。

セキュア開発力とは

セキュア開発力ですが、具体的にどのような知識やスキルが必要でしょうか。KDLでは以下が必要と考えています。

• 安全な設計を行う力
  セキュリティを後付けするのではなく、最初から考慮に入れた設計を行う力です。たとえば、認証・認可の仕組みをどう組み込むか、機密情報をどのように扱うかといった点を設計段階で盛り込むことで、実装後の修正コストを大幅に減らすことができます。

• 脆弱性を見抜く力
  コードやアーキテクチャをレビューした際に、「ここに入力値検証が不足している」「この依存ライブラリには既知の脆弱性がある」などを見抜ける力です。脆弱性を早期に発見できれば、攻撃者に先手を取られるリスクを減らせます。

• セキュリティ要件を組み込む力
  プロジェクトの要件定義や設計書に「暗号化必須」「ログには個人情報を残さない」といったセキュリティ要件を自然に盛り込める力です。セキュリティは後から追加するよりも、要件として明確にすることで抜け漏れを防ぎ、全体の品質を高めることができます。

• レビューやテストで安全性を担保する力
  実際に動くコードができあがった段階で、レビューやセキュリティテストを通じて安全性を検証する力です。ソースコードレビューに加えて、DAST（動的アプリケーションセキュリティテスト）やSAST（静的アプリケーションセキュリティテスト）などのツールを組み合わせることで、目視では見逃しやすい問題も検出できます。

AIとうまく付き合っていくためには

前提条件を教えてからコードを生成させる

AIは与えられた情報をもとにコードを生成します。そのため、あいまいな指示ではセキュリティ要件が抜け落ちた実装になる可能性が高いです。事前に「技術要件」「セキュリティ要件」「遵守すべきこと」「優先すべき事項」などの前提条件を教えておくことで、AIの出力の質を安定させることができます。

前提条件については、例えば、CLAUDE.md などのドキュメントで、セキュリティ要件を明示し、チーム全体で共有するようにしましょう。チーム全員が、同じルールを用いれるよう、前提、文脈などをAIに先に教えておくようにしましょう。

段階的に作らせて、セキュリティをチェックする

一度に大きなコードを生成させるのではなく、小さなステップに分けて生成し、その都度レビューすることでリスクを軽減できます。AIの提案をそのまま受け入れるのではなく、「本当に要件を満たしているか」「セキュリティ的に問題はないか」を確認しながら進めることが大切です。

段階的に作らせることで、チェックしやすく、前提を調整することができます。

必ず人間によるレビューとテストを行う

現在（2025年9月）では、AIが完全にセキュアなコードを自動生成できる段階には至っていません。したがって、生成されたコードは必ず人間によるレビューやテストを実施することが不可欠です。

• 要件通りか
• 入力値検証できているか
• エンコードできているか
• データと命令は分離されているか

ルールによって受け入れるかを判断

誰がどういうチェックをするのか。事前にチームで決めたルールによって判断することが重要です。たとえば、DAST（動的アプリケーションセキュリティテスト）やSAST（静的アプリケーションセキュリティテスト）を導入し、チェック結果を基準にコードの可否を確認、複数人でチェックを実施、チェック結果は、チーム全体で共有するなど。こうしたガバナンスを整えることで、属人的な判断に頼らず、組織として一貫したセキュリティ水準を維持できます。

ここまで紹介してきたように、AIがコードを書く時代においても、最終的に「そのコードがセキュアかどうか」を判断できるのは人間の開発者です。では、その判断力＝セキュア開発力はどう鍛えればよいでしょうか。

セキュア開発力を高めるための Proactive Defense のサービス

Proactive Defenseでは、開発者が現場で活かせるセキュア開発力を身につけるためのトレーニングサービスをご提供しています。KDLがセキュア開発に取り組んできた実績から企画・開発された実践的なトレーニングで、本トレーニング受講によりプロジェクトの初期段階から脆弱性を作りこまないセキュア開発の手法を身に付けることができます。

セキュア開発トレーニング

実際KDLでは、開発に関わる全てのエンジニアがこのトレーニングを受講しており、受講後、本番稼働までに修正が必要な指摘を受けたチームが30%減という成果が出ています。特にSQLインジェクションやXSSは、ほとんど見つからないようになりました。

脆弱性診断の指摘内容を分析し、ミスしやすい箇所をトレーニングに反映。よりよいカリキュラムになるよう改訂を繰り返しています。

• カリキュラムにはOWASPの豊富なプロジェクトを活用
• 実際の開発現場で発生しやすい脆弱性を題材に、明日から使える知識を学べる
• 脆弱なコードを「なぜ危険か」理解し、「どう修正すべきか」を実践的に学習できる
• 基礎編・実践編とレベルに応じたカリキュラムを用意

こうした日々の業務に直結するスキルを習得できます。無料相談も実施中ですので、「自社の開発チームに合ったセキュア開発教育を探している」「トレーニング内容を詳しく知りたい」という方は、お気軽にご相談ください。