AIが「クズコード」まで学習 “脆弱性の生まれ方”が変わったAIコーディング時代の「守り」の作法と始め方：レビュー時、どこを重点的に見るべきか（1/2 ページ）

AIコーディング一般化に伴い、新たな課題が生まれている。AIコーディングに特有の脆弱性の具体例を中心に、チームとして脆弱性を減らしながら開発スピードを加速させるための実践的な視点を提示し、今日から始められる対策について触れる。

[瀬戸幹生（JFrog Japan），＠IT]

　「ChatGPT」をはじめとする生成AIが個人で使われることが当たり前になり、組織でも導入が進んで業務プロセスに取り入れる企業が増えています。ソフトウェア開発業務では、2025年末から「AIコーディング」が個人レベルでは一般的になってきているのを実感する方も多いと思います。

　一方で、組織として開発プロセスにAIコーディングを組み込む上では、「レビューに十分な時間を確保できない中、AI生成コードのどこを重点的に確認すればよいのか」と悩んでいるエンジニアの方も多いのではないでしょうか。

　開発部門長の立場では「どのAIコーディングツールを許可すべきか」「チームとしてどこまでAIコーディングの結果を管理していくのか」といった判断が必要になってきているのかと思います。

　これらの悩みに共通する背景にあるのは、脆弱（ぜいじゃく）性の性質そのものの変化です。従来の脆弱性は、人間の不注意やスキル不足に起因するものが中心でした。それに対し、AIコーディングにおける脆弱性は、モデルの学習データや生成プロセスの不確実性に起因するものが増えており、原因の切り分けには工夫が必要になってきています。

　AIコーディングがもたらす開発速度の向上効果は非常に大きく、もはや活用そのものを止めるという選択肢は現実的ではありません。重要なのは、脆弱性が生まれる仕組みを理解し、それを検知、防止する仕組みやツールを整備した上で、AIコーディングを安全かつ積極的に活用し続けることです。

　そこで本記事では、AIコーディングに特有の脆弱性の具体例を中心に、チームとして脆弱性を減らしながら開発スピードを加速させるための実践的な視点を提示し、最後に今日から始められる対策について触れます。

AIコーディングが生み出す「新たな脆弱性」の例

　本記事では「AIコーディング」を、従来の「GitHub Copilot」のようにコードを提案、補完する「AI支援コーディング」と、「Copilot Agent Mode」「Claude Code」のように人間から与えられたタスクを複数の作業ステップに分解しながら自律的に遂行していく「エージェントコーディング」の両方を含む言葉として扱います。

　エージェントコーディングは、その遂行過程でローカルPC上のファイルや外部のWebページ、イシュー（GitHubなどで管理されるタスクやバグ報告の単位）、MCP（Model Context Protocol）経由で連携する外部サービスの情報などを、必要に応じて読み取ったり、操作したりすることもあります。

　まずAI支援コーディングに特有の脆弱性を中心に取り上げ、その上でエージェントコーディングに特有の脆弱性にも簡単に触れます。

【1】AIハルシネーションによる「存在しないライブラリ」による脆弱性

　AIコーディングツールは、実在しないパッケージ名を「あたかも存在するかのように」提案することがあります。学習データに含まれる命名パターンから、実在しそうなパッケージ名を生成してしまうことで起こる現象です。

　2024年に報告された例として「huggingface-cli」パッケージがあります。セキュリティ研究者のBar Lanyado氏は、Hugging FaceのCLIとして複数のAIモデルが繰り返し「huggingface-cli」という存在しないパッケージ名を提案することに気付き、検証用のパッケージをこの名前で公開したところ、3カ月で1.5万件以上のダウンロードを記録しました。

　この例では、無害なパッケージだったので問題にはなりませんでしたが、npmでは「unused-imports」という名前で、悪意あるコードを含むパッケージが公開されたケースもありました（本来は「eslint-plugin-unused-imports」が正しいパッケージ名）。

　このように攻撃者がAIの提案する架空の名前を先に公開レジストリに登録し、悪意あるコードを仕込むケースは「スロップスクワッティング（slopsquatting）」と呼ばれています。

【2】訓練データに由来する「レガシーな負債」の再生産

　AIモデルは、当時は一般的だったものの現在では非推奨とされる実装パターンも含めて学習しています。加えて、インターネット上に存在するいわゆる「クズコード」やバッドプラクティスも学習データとして含んでいます。AIモデルは「統計的によく使われている書き方」を提案する性質があるので、こうした古い実装をそのまま再生産してしまうこともあります。

　少し古い事例ですが、ニューヨーク大学の研究チームが2021年に行った調査では、GitHub Copilotに89種類のシナリオでコードを生成させ、得られた1689個のプログラムを分析したところ、およそ40％に脆弱性が含まれていました。原因としては、学習データに含まれる古くて安全でない実装パターンをそのまま再現してしまうことでした。

　下記コードは典型的な例です。

import hashlib
def hash_password(password):
return hashlib.md5(password.encode()).hexdigest()

　MD5は衝突攻撃に対して脆弱で、パスワードハッシュ化には適していないことは現在ではよく知られていますが、学習データ中にこのパターン存在することによって、AIが「一般的な実装」として提案してしまう可能性があります。実行結果としては正常にハッシュ値が生成されるので、テストだけでは問題を検知しにくいという点が、この脆弱性の見つけにくさにつながっています。

【3】プロンプトインジェクションによる「ロジック汚染」〜エージェントコーディングも狙われている〜

　AIコーディングツールは、与えられたタスクを複数の作業ステップに分解しながら自律的に遂行していく「エージェントコーディング」に進化しています。冒頭でも触れた通り、AIエージェントはローカルPC上のファイルや外部のWebページ、イシュー、MCP経由で連携する外部サービスの情報などを、必要に応じて読み取ったり、操作したりすることもあり、この自律性がAI支援コーディングとは異なる種類の脆弱性を生み出します。

　代表的な事例が、外部コンテンツにAIへの指示を埋め込む「プロンプトインジェクション」です。GitHub Copilotを対象に報告された「CVE-2025-53773」では、READMEファイルやソースコードのコメントなどに埋め込まれた指示によって、リモートでのコード実行が可能になることが報告されています。

　以上のようにAIコーディングツールを取り巻くエコシステムも標的となってきています。

　スキルやプラグインなどの拡張機能を狙った「MaliciousCorgi」キャンペーン、MCPサーバ「postmark-mcp」の事例、最近では2026年3月に報告されたAI関連ライブラリ「LiteLLM」への侵害事例など、悪意あるコードが仕込まれる事件が相次いでいます。