ここまで紹介した脆弱性に共通する対策の考え方は、「AIが生成したコードを、人間が書いたコードと同じ基準でレビューしない」ことです。その対応を個人の注意力に委ねるのではなく、チーム全体の仕組みとして実装することが重要です。
これから紹介する3つの対策は、脆弱性に個別対応するものではありません。AI生成コードに潜むさまざまなリスクに共通して有効な、基本的な対策です。
AIが提案したパッケージ名は、導入前に必ず公式レジストリで存在を確認します。この工程は個人の判断に任せるのではなく、チームのレビュープロセスやCI(継続的インテグレーション)パイプラインに明文化しておくことが重要です。
- name: Verify package existence
run: |
pip download --no-deps ${PACKAGE_NAME} --dest /tmp/check
上記例は、単に「そのパッケージ名が実在するか」を確認するものですが、さらにダウンロード数、公開履歴、メンテナ情報を確認する工程を組み込むのも一案です。
このような確認をその都度CIツールのスクリプトで実装する代わりに、使用したいOSS(オープンソースソフトウェア)パッケージを社内のプロキシ経由で取得させ、既知の脆弱性やマルウェア、ライセンス違反などをその時点でスキャンしてから配布するようなプロキシ型のリポジトリマネジャーを導入するのも有効です。危険なパッケージを開発者の環境に取り入れる前にブロックすることができるので、個々の開発者やCIスクリプトの実装に依存せず、組織全体で一貫した防御線を構築できます。
AIコーディングツールに読み込ませるルールファイルやプロンプト、エージェントに追加するスキルなども、ソースコードと同様にバージョン管理の対象にすることが重要です。
チームで標準化したプロンプトやスキルをリポジトリで管理し、レビューを経て更新する運用にすることで、個人のノウハウにとどめずにチームで共有、更新し続けられる資産として蓄積できます。
先ほども挙げましたが、セキュリティスキャンツールの活用も重要です。AIが提案するコードには、先ほど挙げたMD5の例のような非推奨な実装パターンが混入する可能性があります。
人間の目だけで見つけるのは限界があるので、静的アプリケーションセキュリティテスト(SAST)やソフトウェア構成分析(SCA)のツールを、AIコーディングのワークフローに組み込むことが重要です。これらのツールは、AIコーディングツール自体が生成するコードのスキャンだけではなく、導入するスキルやプラグイン、MCPサーバの検証にも今後活用が広がることが期待されます。
(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活用まで幅広い技術バックグラウンドを持ち、現在は日本市場における顧客の技術的成功およびソフトウェアサプライチェーンセキュリティの実践支援に従事。
「AIが書いたコードは人間より優秀」――だが本番で壊れる、なぜか?
99%の組織が直面「バイブコーディングが量産する脆弱なコード」 その具体例と理由、回避策
「バイブコーディングは危険」はもう古い “AI任せ”のコードに潜む4つのワナと回避策
「バイブコーダーの増加はサイバー攻撃者にとって養分でしかない」 その理由とは
バイブコーディングが“脆弱性の温床”に? APIへの攻撃が113%増――AI時代の攻撃実態Copyright © ITmedia, Inc. All Rights Reserved.