AIが「クズコード」まで学習 “脆弱性の生まれ方”が変わったAIコーディング時代の「守り」の作法と始め方:レビュー時、どこを重点的に見るべきか(2/2 ページ)
AIコーディング一般化に伴い、新たな課題が生まれている。AIコーディングに特有の脆弱性の具体例を中心に、チームとして脆弱性を減らしながら開発スピードを加速させるための実践的な視点を提示し、今日から始められる対策について触れる。
AIコーディング時代の「脆弱性対策」3つの作法
ここまで紹介した脆弱性に共通する対策の考え方は、「AIが生成したコードを、人間が書いたコードと同じ基準でレビューしない」ことです。その対応を個人の注意力に委ねるのではなく、チーム全体の仕組みとして実装することが重要です。
これから紹介する3つの対策は、脆弱性に個別対応するものではありません。AI生成コードに潜むさまざまなリスクに共通して有効な、基本的な対策です。
(1)パッケージ検証とAI活用ルールを、チームの仕組みとして整備する
AIが提案したパッケージ名は、導入前に必ず公式レジストリで存在を確認します。この工程は個人の判断に任せるのではなく、チームのレビュープロセスやCI(継続的インテグレーション)パイプラインに明文化しておくことが重要です。
- name: Verify package existence
run: |
pip download --no-deps ${PACKAGE_NAME} --dest /tmp/check
上記例は、単に「そのパッケージ名が実在するか」を確認するものですが、さらにダウンロード数、公開履歴、メンテナ情報を確認する工程を組み込むのも一案です。
このような確認をその都度CIツールのスクリプトで実装する代わりに、使用したいOSS(オープンソースソフトウェア)パッケージを社内のプロキシ経由で取得させ、既知の脆弱性やマルウェア、ライセンス違反などをその時点でスキャンしてから配布するようなプロキシ型のリポジトリマネジャーを導入するのも有効です。危険なパッケージを開発者の環境に取り入れる前にブロックすることができるので、個々の開発者やCIスクリプトの実装に依存せず、組織全体で一貫した防御線を構築できます。
AIコーディングツールに読み込ませるルールファイルやプロンプト、エージェントに追加するスキルなども、ソースコードと同様にバージョン管理の対象にすることが重要です。
チームで標準化したプロンプトやスキルをリポジトリで管理し、レビューを経て更新する運用にすることで、個人のノウハウにとどめずにチームで共有、更新し続けられる資産として蓄積できます。
(2)SAST・SCAツールによる機械的なチェックを併用
先ほども挙げましたが、セキュリティスキャンツールの活用も重要です。AIが提案するコードには、先ほど挙げたMD5の例のような非推奨な実装パターンが混入する可能性があります。
人間の目だけで見つけるのは限界があるので、静的アプリケーションセキュリティテスト(SAST)やソフトウェア構成分析(SCA)のツールを、AIコーディングのワークフローに組み込むことが重要です。これらのツールは、AIコーディングツール自体が生成するコードのスキャンだけではなく、導入するスキルやプラグイン、MCPサーバの検証にも今後活用が広がることが期待されます。
(3)個人の学びを、チームのノウハウに変換
(1)(2)の仕組みを機能させる前提になるのが、チーム内での知見の共有です。
一人の開発者がAIの提案したコードに潜む問題や、拡張機能、MCPサーバの不審な挙動に気付いたとしても、それが個人の経験だけで終わってしまうと、同じ問題を別のメンバーが繰り返すことになります。このような個人の知見を、チームのレビュー基準やコーディングガイドライン、許可リスト、またはそれらを含むエージェントスキルに反映し、知的資産の拡充のサイクルを作って運用していくことが重要です。
前述のようなセキュリティスキャンやリポジトリマネジャーなどのツール選定においても、こうしたチームとしての知見や経験を踏まえて評価、採用を決定していくことが、脆弱性を減らす仕組みの土台になります。
今日から何をすればいいか
AIコーディングは、開発の生産性を大きく引き上げます。脆弱性の生まれ方が変化してきていることは事実ですが、これはAIコーディングを避ける理由ではなく、「守り方を更新する」きっかけとして捉えるべきものです。
従来は「人間の不注意やスキル不足」が主な原因でしたが、AIコーディングにおいては、これに加えて「生成プロセスの不確実性」「外部コンテンツ/ツールへの過信」という新たな原因が加わりました。重要なのは、確認作業を「個人の注意力任せ」から、「チームの仕組みとツール」に移行することです。パッケージ検証とプロキシ型のセキュリティスキャン、プロンプトやスキルの標準化とバージョン管理、SAST/SCAツールの活用、個人の学びをチームのノウハウに変換するサイクル。これらを整備することで、AIコーディングを止めることなく、より速く、より安全に開発を継続できるようになります。
後半で挙げたAIコーディング時代の「守り」の作法を実践したいと思った方は、次の2つから始めてみることをお勧めします。
1つ目は、チームが現在使っているAIコーディングツールや拡張機能、MCPサーバを一度全て棚卸しし、「誰が、何を、どんな権限で使っているか」を可視化すること。2つ目は、直近1週間でAIが提案したコードのうち数件を、SASTツールに通してみることです。
棚卸しで見えたリスクの範囲と、スキャンで見えた混入率、この2つがそろえば、次にどこから仕組み化すべきかの優先順位が見えてくるのではないでしょうか。
筆者紹介
瀬戸 幹生(せと みきお)
テクニカルサクセスマネージャー/JFrog Japan株式会社
東北大学大学院修了後、シャープ株式会社にて研究開発担当者として7年半従事。その後、Nuance Communicationsにてテクニカルリードを約8年務め、音声認識・自然言語処理領域の技術開発を牽引。マイクロソフトではData Scientistとして約2年間AI・機械学習の実務経験を積み、HCLTechにてテクニカルスペシャリストを経て、2025年10月よりJFrog JapanにTechnical Success Managerとして参画。ハードウェア研究から最先端のAI活用まで幅広い技術バックグラウンドを持ち、現在は日本市場における顧客の技術的成功およびソフトウェアサプライチェーンセキュリティの実践支援に従事。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
「AIが書いたコードは人間より優秀」――だが本番で壊れる、なぜか?
AIコーディングの実践拡大に伴い、開発現場では品質管理の課題も顕在化し始めている。New Relicの調査では、AI生成コードに対する評価が高いことが分かったが、一方では本番環境では問題への対応に追われている状況も明らかになった。
99%の組織が直面「バイブコーディングが量産する脆弱なコード」 その具体例と理由、回避策
生成AIによる「バイブコーディング」が急速に普及する一方で、脆弱なコードの増加が新たな課題として浮上しています。AIは何を間違え、どのような脆弱性を生み出すのでしょうか。
「バイブコーディングは危険」はもう古い “AI任せ”のコードに潜む4つのワナと回避策
Trend Microがバイブコーディングがセキュリティに与えるリスクやその対策について解説するブログを公開した。
「バイブコーダーの増加はサイバー攻撃者にとって養分でしかない」 その理由とは
Claude Mythosが象徴的に示すように、AIモデルのサイバー攻撃能力が急速に向上している。その能力を生かして攻撃者が一般企業を侵害する際、便利な攻撃経路の一つとなるのがバイブコーディングで開発されたソフトウェアだ。その脅威を解説した専門家による講演の内容をレポートする。
バイブコーディングが“脆弱性の温床”に? APIへの攻撃が113%増――AI時代の攻撃実態
Akamaiのレポート「インターネットの現状」(SOTI)によると、AIの普及がサイバー攻撃を変えつつある。APIが主要な攻撃対象となり、バイブコーディングが新たなリスクを招きかねないという。その実態とは。
