AIコーディングアシスタントの「隠れたリスク」とは何か
CopilotやCursor、あるいは各種AIチャットを使ってコードを書いている開発者は今や珍しくない。むしろ使っていない方が少数派になりつつある現場も多いだろう。
ただ、ここで一つ聞きたい。そのAIが提案したコードに含まれる依存ライブラリが、現在もメンテナンスされているかどうかを、あなたのチームは毎回確認しているだろうか。
今回取り上げるのは、AIコーディングアシスタントがEOL（End of Life＝サポート終了）済みのオープンソースライブラリを無自覚に引き込み、セキュリティ・コンプライアンスのリスクを積み上げているという問題だ。問題の本質は「AIが悪いコードを書く」ことではない。AIが依存パッケージを無差別に推奨することにある。
AIモデルの学習データは過去のコードベースで構成されている。そのデータは「今もメンテナンスされているか」を区別しない。だからAIは、すでにEOLになったライブラリでも「昔よく使われていたから」という理由で平然と提案してくる。
なぜ今この問題が急浮上しているのか
背景として押さえておきたい数字がある。2025年のSynopsys / Black Duck OSSRAレポートによると、商用コードベースの約96%にオープンソースが含まれている。現代のソフトウェア開発はほぼOSSの上に成り立っている、と言い切っていい状況だ。
その上で、AIコーディングアシスタントはこの傾向を3つの形で加速させている。
一つ目は導入量の爆発的増加だ。AIアシスタントは、従来のレビューサイクルでは追いつかない速度で依存パッケージを追加する。1回のオートコンプリートで、開発者が保存ボタンを押す前に3〜4個の推移的依存関係が追加されることもある。
二つ目はEOLライブラリの無差別選択だ。AngularJS、Spring 5、Bootstrap 3、Vue 2、.NET Framework 4.x、jQuery——これらはいずれも公式にEOLとなっているが、AIが生成するコードには今でも頻繁に登場する。
三つ目がサイレントな伝播だ。AIが生成したコードは見た目に正常で、テストも通過し、本番環境にリリースされる。EOLの依存パッケージが発覚するのは、セキュリティ監査・ペネトレーションテスト・CVE開示のタイミングになってから——しかもそのとき、上流のメンテナーはすでに存在しない。
実際に何が起きているか——2つの具体的な事例
抽象的な話で終わらせないために、元記事で紹介されている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に依頼した。AIはAngularJS 1.xが現役と判断し、EOL済みのコンパニオンライブラリを含むコードを生成。6ヶ月後、内部のHIPAA評価で認証フローがパッチ未適用のAngularJSを経由していることが発覚した。
いずれのケースも、AIは「要求された機能」を正しく実装した。コンプライアンスリスクは学習データから受け継がれ、組織がそれを丸ごと引き受ける形になった。ここが重要な点で、AIは機能要件には答えるが、コンプライアンス要件には無頓着なのだ。
SCAツールだけでは追いつかない理由
SCA（ソフトウェア構成分析）ツールは既知パッケージの既知脆弱性を検出する。AI以前の世界では、開発者が意図的に依存関係を追加・レビューしていたため、この仕組みが有効に機能していた。
AI時代には3つの問題が生じる。依存パッケージの追加速度がレビューキューを上回ること。EOLになったパッケージにはCVEがまだ登録されていない場合があること（上流が沈黙すると、脆弱性の開示自体が行われなくなるため）。そして監査のタイムラインでは、アップグレードや置き換えが間に合わないことがある。
SCAツールは「既知の問題を検出する」ツールだ。しかし上流メンテナーが沈黙した後は、新しいCVEが登録されない。つまりスキャンがクリーンでも、安全とは限らないという状況が生まれる。
ここからは見方の話——この問題の構造的な意味
元記事はHeroDevsという商用サポートサービスの訴求記事という側面もある。そのバイアスは差し引いた上で読む必要があるが、指摘している問題構造自体は的を射ている。
「AIが悪い」という話ではないし、「AIを禁止せよ」という話でもない。構造的に見ると、これはソフトウェア開発における「責任の所在」が再定義されつつある問題だ。
従来の開発では、ライブラリ選定は開発者の判断であり、そのリスクも開発者・組織が引き受けていた。AIアシスタントが介在すると、ライブラリ選定の一部がAIに委ねられ、その結果として生じるコンプライアンスリスクは依然として組織が引き受ける構造になっている。判断をAIに移譲したが、責任はまだ移譲されていない。
主要なAIポリシーフレームワーク（Google AI Principles、Microsoft's Responsible AI Standard、IBM's Principles for Trust and Transparency、GitLab's AI Transparency Centerなど）はいずれも「ソフトウェアが継続的にパッチ適用されている」という前提の上に成り立っているが、AIが引き込むEOLオープンソースはこの前提を壊す。
もう一つの視点として、これはAI規制の「次の論点」になりうると思っている。現在のAI規制論議はモデルの透明性やデータの取り扱いに集中しているが、「AIが生成したコードに含まれる依存関係の品質保証は誰の責任か」という問いが近い将来出てくるはずだ。EU サイバーレジリエンス法やDORAのような規制が成熟すれば、AI生成コードの依存関係も監査対象に含まれる議論は避けられない。
実務的に何をすべきか
AIコーディングアシスタントを禁止するのは現実的ではない。生産性向上効果が大きすぎるし、多くの組織はすでに標準ツールとして採用済みだ。では何をすべきか。
短期でできること：
まず、自社コードベースにどのEOLパッケージが含まれているかを把握する。元記事では、HeroDevs Vulnerability DirectoryとEOL Dataset（1,200万以上のパッケージバージョンを追跡）をSBOMとクロスチェックすれば半日で露出状況を把握できると述べている。ツールの選定はともかく、「現状把握」をやらないままにしているチームは多い。まずそこから始めるべきだ。
AIが提案するコードのライブラリ名を見て、EOLかどうかを都度確認する習慣を開発チームに根付かせることも効果がある。AngularJS、Spring 5、Bootstrap 3、Vue 2あたりはAIが今でも頻繁に提案してくるので、チームのチェックリストに入れておくといい。
中期で考えること：
SCAツールをEOLデータセットと組み合わせる体制を作ること。スキャンがクリーンでも安心しないこと。EOLパッケージのCVEは上流が沈黙すれば登録されないため、「脆弱性が見つかっていない＝安全」とはならない。
元記事ではHeroDevsのNES（Never-Ending Support）という商用サービスが提案されている。EOLパッケージに対してセキュリティパッチ済みのドロップイン代替品を提供するもので、AngularJS、Spring、Vue 2、.NET Framework、Bootstrap、jQuery、Node.js LTS系列など約40のEOLスタックが対象だという。監査上の扱いが「サポート終了コンポーネント」から「商用サポート済みサードパーティコンポーネント」に変わるため、PCI DSSやHIPAAの監査対応がしやすくなるというロジックだ。
この種の商用サポートサービスを使うかどうかはコストとリスクのバランスで判断することになるが、「すぐに移行できないが監査は受けなければならない」という状況の組織には現実的な選択肢の一つになりうる。ただし、これはあくまでブリッジであり、長期的なモダナイゼーションの代替にはならない。
まとめ
AIコーディングアシスタントが引き起こすEOL問題は、AIが「悪いコード」を書くから起きるのではない。AIが「過去に人気だったコード」を参照するから起きる。そしてその結果は、組織のコンプライアンス体制に静かに積み上がっていく。
コンプライアンスチームがすべてのコミットを手動でゲートするのは現実的ではない。だからこそ、「AIが前提になった時代の守り方」を設計し直す必要がある。AIポリシーは、その土台となるオープンソースと同じ強さしか持てない——元記事のこの一文は、実務的に正しい。
次にAI生成コードのレビューをするとき、機能の正しさだけでなく「このライブラリ、今もメンテナンスされているか」をチェックする習慣を持てるかどうか。そこが起点になる。
