元記事URL： AI Coding Assistants Are Quietly Breaking Your Compliance Posture. Here's How to Get It Back.
TL;DR（要点まとめ）
AIコーディングアシスタントは急速に開発現場のデフォルトツールになりつつある。
しかしその裏側では、EOL（サポート終了）済みのオープンソースライブラリがAIによって無自覚に大量導入され、セキュリティ・コンプライアンス上の深刻なリスクが積み上がっている。
従来のSCAツールだけでは対応しきれないこの問題に、どう向き合えばよいかを解説する。
AIコーディングアシスタントが生み出す「見えないコンプライアンスリスク」
AIコーディングアシスタントはこの3年足らずで開発現場に急速に普及した。開発スピードは格段に上がった一方、ほとんどの組織が気づいていないリスクがある。
問題の本質はAIが悪いコードを書くことではない。AIが依存パッケージ（dependencies）を無差別に引き込むことにある。
AIモデルの学習データは過去のコードベースで構成されている。そのデータは「現在もメンテナンスされているか」を区別しない。つまりAIは、すでにEOLになったライブラリでも「よく使われているから」という理由で平然と推奨してくる。
その結果、EOLパッケージがコードレビューをすり抜けて本番環境にデプロイされ、誰も気づかないまま脆弱性が蓄積されていく。
あなたの社内AIポリシーが前提としている5つのコミットメント
Google AI Principles、Microsoft's Responsible AI Standard、IBM's Principles for Trust and Transparency、GitLab's AI Transparency Center など、主要なAIポリシーフレームワークはいずれも、次の5点にコミットしている。
- セキュリティと信頼性：AIで構築・変更されたシステムの安全性確保
- プライバシーとデータ保護：ソフトウェアサプライチェーン全体でのデータ保護
- 透明性と出所（プロベナンス）：システムの構成要素とその由来の可視化
- 説明責任と人的監視：AI生成アウトプットへの適切なガバナンス
- 規制コンプライアンス：PCI DSS、HIPAA、SOC 2、DORA、EU サイバーレジリエンス法への準拠
これら5つはすべて、「自分たちのコードに何が含まれているか把握できている」「ソフトウェアが継続的にパッチ適用されている」という前提に依存している。AIが引き込むEOLオープンソースは、この2つの前提を同時に崩壊させる。
なぜAI時代にEOL問題が加速するのか
2025 Synopsys / Black Duck OSSRA レポートによると、商用コードベースの約96%にオープンソースが含まれている。AIコーディングアシスタントはこの傾向を3つの形でさらに加速させる。
1. 導入量の爆発的増加
AIアシスタントは、従来のレビューサイクルでは追いつかない速度で依存パッケージを追加する。1回のオートコンプリートで、開発者が保存ボタンを押す前に3〜4個の推移的依存関係（transitive dependencies）が追加されることもある。
2. EOLライブラリの無差別選択
学習データは「人気があったもの」を反映するが、「現在もメンテナンスされているか」は反映しない。AngularJS、Spring 5、Bootstrap 3、Vue 2、.NET Framework 4.x、jQuery——これらはいずれも公式にEOLとなっているが、AIが生成するコードには今でも頻繁に登場する。
3. サイレントな伝播
AIが生成したコードは見た目に正常で、テストも通過し、本番環境にリリースされる。EOLの依存パッケージが発覚するのは、セキュリティ監査・ペネトレーションテスト・CVE開示のタイミングになってから——しかもそのとき、上流のメンテナーはすでに存在しない。
実際に起きた2つのインシデント事例
事例1：Spring Boot 2.7のスキャフォールド
開発者がAIアシスタントに「認証機能付きのJavaサービスを作って」と依頼したところ、Spring Boot 2.7 + Spring Security 5.8の動作するプロジェクトが生成された。しかしSpring Boot 2.7は2025年11月に商用EOLを迎えており、Spring Security 5.x の最新の脆弱性開示を含む新規CVEにはもはや上流パッチが提供されない。PCI DSS・DORA・SOC 2の監査では、このスキャフォールド1つが「指摘事項（finding）」となる。
事例2：AngularJS移行ヘルパーの導入
レガシーフロントエンドを刷新中のチームが、AngularJSから現代フレームワークへのブリッジコードを依頼した。AIはAngularJS 1.xが現役と判断し、EOL済みのコンパニオンライブラリを含むコードを生成。6ヶ月後、内部のHIPAA評価で認証フローがパッチ未適用のAngularJSを経由していることが発覚した。
いずれのケースも、AIは「要求された機能」を正しく実装した。コンプライアンスリスクは学習データから受け継がれ、組織がそれを丸ごと引き受ける形になった。
従来のSCAツールだけでは不十分な理由
SCA（ソフトウェア構成分析）ツールは既知パッケージの既知脆弱性を検出する。AI以前の世界では、開発者が意図的に依存関係を追加・レビューしていたため、この仕組みが有効に機能していた。
AI時代には3つの問題が生じる。
- 依存パッケージの追加速度がレビューキューを上回る
- EOLになったパッケージにはCVEがまだ登録されていない場合がある（上流が沈黙すると、脆弱性の開示自体が行われなくなるため）
- 監査のタイムラインでは、アップグレードや置き換えが間に合わないことがある
SCAツールは引き続き必要だが、それだけでは不十分。ここで登場するのが HeroDevs EOL Dataset だ。AIが引き起こすEOLのギャップを埋め、AIアシスト型ワークフローと完璧にペアを組むツールである。「現在EOLのパッケージ」と「近い将来EOLになるパッケージ」を追跡することで、コンプライアンス対応をリアクティブではなくプロアクティブに行えるようになる。
実際にどう対処するか？ 現実的な解決策
AIコーディングアシスタントを禁止するのは現実的ではない。生産性向上効果が大きすぎ、多くの組織はすでに標準ツールとして採用済みだ。
現実的なアプローチは、AIが必然的に引き込むEOLオープンソースに対して、商用サポートを提供する仕組みを用意することだ。
HeroDevsの提供する NES（Never-Ending Support） は、EOLとなったオープンソースに対してセキュリティパッチ済みのドロップイン代替品を提供する商用サービスだ。対象には AngularJS、Spring、Vue 2、.NET Framework、Bootstrap、jQuery、Node.js LTS系列 など約40のEOLスタックが含まれ、既存のパッケージマネージャーからそのまま利用できる。
NESがAI開発ワークフローにもたらす3つの変化：
- EOLパッケージが「サポート済みパッケージ」に変わる——監査上の扱いが「サポート終了コンポーネント」から「商用サポート済みサードパーティコンポーネント」になる
- SBOMが正確な状態を反映する——NESリリースには明確なプロベナンスとバージョンメタデータが付与されるため、監査人・顧客・規制当局が求める情報を正確に提供できる
- 移行タイムラインを組織が主導できる——規制当局ではなく、ビジネスの都合に合わせたペースでモダナイゼーションを進められる
よくある質問
「古いコードを永遠に使い続けることを許容するだけでは？」
NESはあくまでブリッジであり、永続的な代替策ではない。多くの組織は計画的なモダナイゼーション期間中のコンプライアンス維持のために利用し、ロードマップが許す範囲で移行を完了させていく。
「うちのAIアシスタントはサンドボックス環境で動いている。それでも関係ある？」
関係ある。EOL依存パッケージへの露出は、モデルがどこで動くかではなく、生成されるコードの性質に起因する。
「AIがすでに何を引き込んでいるか、どう調べればいい？」
HeroDevs Vulnerability Directory と EOL Dataset（1,200万以上のパッケージバージョンを追跡）から始めるとよい。SBOMとEOLデータセットをクロスチェックすれば、半日で自社の露出状況を把握できる。
「スタック全体でNESを契約する必要がある？」
不要。NESはフレームワーク／スタック単位で提供される。多くの組織は、監査でプレッシャーが最も高い1〜2のEOLフレームワークから始め、順次拡張していく。
まとめ：AIポリシーは土台のオープンソースと同じ強さしか持てない
AIコーディングアシスタントの普及は止まらない。コンプライアンスチームがすべてのコミットを手動でゲートすることも、もはや現実的ではない。
守られ続ける組織とは、AIが必然的に引き込むオープンソースの下に「商用サポートの土台」を敷いた組織だ。
自社のEOL露出状況を確認したい場合は、HeroDevs Vulnerability Directory と EOL Dataset が無料で利用できる。お問い合わせいただければ、規制要件に合わせたアセスメントも対応している。