AIが書いたコードは信用できるか ~生成AI時代の開発パイプラインに潜む脆弱性リスクと、JFrogによる全方位防御~

ChatGPTやClaude Code、Devinといった生成AIツールの登場によって、ソースコードを書くスピードはここ数年で劇的に向上しました。プロンプト一つで関数が生成され、依存ライブラリの選定さえAIが提案してくれる時代です。しかしその裏側で、AIが生成したコードに古い脆弱性（CVE、CWE）が紛れ込んだり、実在しないパッケージ名を「提案」してしまう"ハルシネーション"が新種の攻撃の入り口になっていることは、意外と知られていません。

本記事では、AI時代の開発プロセスに潜むセキュリティリスクを整理したうえで、JFrogプラットフォームがソフトウェアのライフサイクル全体をどのように防御しているのかを解説します。詳細について、お問い合わせフォーム、　もしくは本書作者Alex Wang (王 子龍) wanga@jfrog.comへお気軽に問い合わせいただけたら幸いです。（日本語、英語の両方に対応）

AI時代のソフトウェア開発、5つのステップ

まず、現代のソフトウェア開発がどのようなステップで進むのかを整理しましょう。AIエージェントの登場により、開発フローそのものが次の5段階として捉え直されつつあります。

図1. AI時代のソフトウェア開発、5つのステップ

1. AIでコード作成（AI Agent）

開発者が要件やプロンプトを入力すると、AI Agentがソースコードや依存ライブラリを自動生成・補完します。開発スピードは飛躍的に向上する一方、AIの学習データに含まれるCVEやCWEを含むような古い脆弱なコードや、存在しないパッケージを呼び出してしまう「ハルシネーション」によってSlopsquatting（スロップスクワッティング）などが紛れ込むリスクが最も高まる瞬間でもあります。

2. 人間・SASTツールによるコードレビュー（IDE / CLI）

生成されたコードは、ローカル環境（IDEやCLI）上でレビューとマニフェストファイルを参照したソースコードベースのSCA（ソフトウェアコンポジション解析／サプライチェーン分析）やSAST（静的アプリケーションセキュリティテスト）ツールによる走査を受けます。コードをリポジトリにコミットする前の、いわば「シフトレフトの最重要拠点」です。

3. Gitでのマージ・ブランチ管理（GitHub、GitLabなど）

レビューを通過したソースコードはバージョン管理システムに統合され、チーム共有のブランチへ集約されます。複数人のコードがここで初めて交わるため、個別の脆弱性がシステム全体へ波及し始める境界線ともいえます。

4. ビルドとバイナリ（Artifact）管理（JFrog Artifactoryなど）

ソースコードはビルドされ、実行可能な成果物（バイナリ = Artifact）としてArtifactoryのようなリポジトリで一元管理されます。ここはソフトウェアサプライチェーンの安全性を担保する最後の保管庫であり、デプロイ直前の最終パッケージが置かれる場所です。

5. デプロイ後の継続モニタリング

本番環境にリリースされた後も、アプリケーションの挙動とセキュリティ状態はリアルタイムで監視され続けます。新たに発見されるゼロデイ攻撃や新種のCVEに対抗する、最後の防衛ラインです。ただし、この一見スムーズなサイクルには重大な落とし穴があります。次章で見る2つのリスクです。

見過ごせない2つのリスク：CVE混入とOSSハルシネーション

①  既知の脆弱性（CVE/CWE）の"再生産"

AIモデルは過去の学習データをもとにソースコードを生成するため、すでに修正済みのはずの古いライブラリの書き方や、脆弱な関数（例：SQLインジェクションを誘発しやすい文字列連結、XSSを引き起こすHTML処理）や悪意のパッケージバージョンをそのまま提案してしまうケースが報告されています。たとえば「JWTトークンの検証ロジックを書いて」と指示した際に、アルゴリズム指定の検証（alg: noneのチェックなど）が省略されたコードが出力され、署名検証不備の脆弱性（CWE-347等）が入り込む例もあります。

② 存在しないパッケージを狙う「Slopsquatting」

より新しい脅威が、AIの「ハルシネーション」を悪用する攻撃です。AIが実際には存在しないパッケージ名を提案してしまう現象を利用し、攻撃者がその名前を先回りしてPyPIやnpmに登録しておく手口は「Slopsquatting（スロップスクワッティング）」と呼ばれ、急速に増加しています。典型的な攻撃シナリオは次のとおりです。

1. AIが pip install react-utils-helpers のような、実在しない架空のOSSパッケージをコード内で提案する。
2. 開発者がその提案を十分に確認せずに、そのままコードを実行・ビルドしてしまう。
3. 攻撃者はAIが出力しやすい"それらしい"パッケージ名を先回りして正規のリポジトリ（PyPI、npmなど）に登録し、内部にマルウェアを仕込んでおく。
4. 結果として、開発者の手元環境やプロダクション環境に、気づかぬうちにマルウェアが自動インストールされてしまう。

この2つのリスクを整理すると、次のようになります。

実際に起きている被害

• Equifax（米大手信用情報機関）：既知の重大なCVE（Apache Strutsの脆弱性 CVE-2017-5638）を含むライブラリを放置・利用し続けた結果、約1億4,700万人分の個人情報が漏洩。米連邦取引委員会（FTC）等から巨額の制裁金を科され、経営陣の退任にまで発展した、2017年を代表する事例です。
• セキュリティ企業による報告（SentinelOneなど）：AIアシスタントが提示した「実在しない悪意あるOSSパッケージ」を開発者が誤って導入し、社内の開発環境がバックドアに感染したケースが報告されています。
• 暗号資産・Web3プロジェクト：人の目によるレビューを経ずにAI生成コードをスマートコントラクトとして本番デプロイした結果、ロジック不備やアクセス制御の欠陥を突かれ、数百万ドル規模の不正送金被害に発展した例も複数報告されています。

今後求められる対応：各プロセスへSASTとSCAの導入

こうしたリスクに対応するには、開発環境への「静的解析ツール（SAST）」の導入に加え、AIが提案した外部ライブラリ（OSS）が実在し、かつ安全であるかを検証する「SCA（ソフトウェアコンポジション解析／サプライチェーン分析）」のプロセスが不可欠です。JFrogのソリューションを重ね合わせると、開発フローは次の図のように変化します。

図2. 各フェーズにJFrogのセキュリティチェックを組み込んだ開発フロー

JFrog PlatformによるEnd to End防御 ― Shift Left × Shift Right

JFrogのセキュリティ思想の中核は、「コードが書かれる最初の瞬間から、本番環境（Kubernetes / k8s）で稼働し続ける瞬間まで、ソフトウェアのライフサイクル全体を一貫して防護する」という点にあります。従来の「ビルドが完了してからセキュリティ監査を行う」アプローチでは、脆弱性の修正コストが跳ね上がり、開発スピードも損なわれてしまいます。

JFrogは開発者の日常ツール（IDE、CLI、AI Agent、Git）にセキュリティチェックを透過的に組み込み、さらにバイナリ管理（Artifactory）や実行環境（Runtime）までを単一プラットフォームで一元管理することで、「安全性を保ちながら最速でリリースする」環境を実現します。

図3. JFrog包括的DevSecOpsプラットフォーム：ソフトウェアサプライチェーン・セキュリティの全体像

プロセス①：AI Agent（Claude Code、Devin等）危険CVEの自動修復

提供ソリューション：Zero-Touch Remediation／Compliant Version Replacement

AI Agentがリスクのある脆弱なパッケージをリクエストした場合でも、開発プロセスを止めることなく、安全な代替バージョンへ自動かつ透過的に置き換えます。開発者やAIが意識せずとも、高リスクなOSSパッケージの侵入を未然に防ぎます。

プロセス②-1：開発環境（IDE：VS Code、IntelliJなど）

提供ソリューション：JFrog Xray／JFrog Advanced Security（IDEプラグイン）

開発者がコードを書いている最中にリアルタイムで、依存パッケージの脆弱性（CVE）、静的バグ（SAST）、露出したシークレット（APIキーやパスワード）、著作権リスクのあるOSSコードの流用（スニペット検知）を検知します。エディタを離れることなく、その場で修正できるのが強みです。

プロセス②-2；コマンドライン（CLI）

提供ソリューション：JFrog CLI／JFrog Xray／JFrog Advanced Security／JFrog Curation

コマンド一つで、ソースコード・依存関係・ビルド後のバイナリをまとめてスキャンできます。SBOM（ソフトウェア部品表）の生成や、外部リポジトリからの安全なパッケージ取得（Curation）もCLIから自動化可能です。

プロセス③：SCM / CI/CD（GitHub、GitLab、Azure DevOps、Bitbucketなど）

提供ソリューション：Frogbot／JFrog Xray／JFrog Advanced Security／JFrog Curation

プルリクエスト作成時やCI/CDパイプライン実行時に、Frogbotが自動でコードと依存関係をスキャンします。脆弱性が見つかればPRに直接コメントを残したり、修正PRを自動作成したりすることで、問題のあるコードがメインブランチに混入するのを水際で防ぎます。

プロセス④：リポジトリ管理（Artifactory）

提供ソリューション：JFrog Xray／JFrog Advanced Security／JFrog Curation

社内で保管されるすべてのバイナリ・コンテナイメージに対して継続的なスキャンを実施します。特にJFrog Curationは、npmやPyPI、Mavenなど外部の公開リポジトリからOSSをダウンロードする際、ポリシー違反の高リスクパッケージのダウンロードをプロキシ制御でブロックします。

プロセス⑤本番・実行環境（Runtime / Kubernetes）

提供ソリューション：JFrog Runtime Security

Kubernetesクラスターなどで実際に稼働しているコンテナ・ワークロードを継続的かつ動的に監視します。稼働中に新たに発見された脆弱性（ゼロデイ攻撃を含む）や露出シークレットを検知し、本番環境の安全性を維持します。

まとめ：セキュリティ機能ごとの主要コンポーネント

早見表：プロセス別・必要なオプション一覧

最後に、各フェーズで「何をスキャンする必要があるか」「どのJFrog製品が対応するか」を一覧表にまとめました。自社の開発体制と照らし合わせながら、抜け漏れがないかチェックしてみてください。

おわりに

生成AIによる開発は、もはや後戻りのできない大きな流れです。だからこそ、"作るスピード"と"守る仕組み"を両立させることが、これからの開発チームに求められる差別化要因になります。あらためて、本記事の要点を振り返っておきましょう。

• 生成コードAIには、既存の学習データに起因する古い脆弱性（CVE/CWE）や、存在しないパッケージを狙う「Slopsquatting」という新しいリスクが潜んでいる。
• Equifaxの事例が示すとおり、依存ライブラリの脆弱性を放置するコストは、情報漏洩・制裁金・経営責任という形で跳ね返ってくる。
• JFrogは「AI Agent → IDE/CLI → SCM/CI/CD → Artifactory → Runtime」の全フェーズにXray、Advanced Security、Curation、Zero-Touch Remediation、Runtime Securityを組み込み、Shift LeftとShift Rightを同時に実現する。
• 自社の開発フローが早見表のどこに"穴"があるかを確認し、優先度の高いフェーズから対策を検討することが、次の一歩となる。