89%問題：LLMはいかにしてオープンソースの「休眠多数派」を復活させているのか

AIコーディングアシスタントは、放棄された何百万ものオープンソースパッケージをひそかに再び呼び起こしています。この10年間、開発者はオープンソースのセキュリティを判断するために、シンプルな経験則に頼ってきました。それは、利用の多さ = 信頼。 週に何百万回もダウンロードされるパッケージ（lodash、react、requests）なら、何千もの人の目に触れているから「十分安全」だと考えていました。一方、あまり知られていないパッケージには慎重に対処していました。

人間の開発者は、人気度、メンテナンス状況、コミュニティでの採用といった信頼の社会的シグナルに従います。この「集合知」モデルが機能していたのは、人間の開発者が本質的に社会的な存在だからです。私たちは仲間が築いた「舗装された道」を選びます。しかし、生成AIはこのモデルを崩し始めています。

AIシステムは、インターネットの歴史全体にまたがるトレーニングデータの統計的パターンに基づいてパッケージを選択します。そこには、放棄されたプロジェクトや実験的なリポジトリが何百万も含まれます。LLMは確率的なシステムであり、人間のアーキテクトやエンジニアのように「人気度」や「メンテナンス状況」を理解しているわけではありません。インターネットの歴史全体から得たデータに基づき、良いものも悪いものも、放棄されたものも含めて、統計的な確率を理解しているのです。

オープンソースの情報とパッケージの健全性の隔たりを埋め、開発者やエージェントにセキュリティ、人気度、メンテナンス、コミュニティに関するさまざまなデータを提供するために、Snyk Advisorを構築し、後にSecurity DBへ統合しました。Snykのパッケージ健全性情報は、AIエージェントをどのように強化するのでしょうか。私たちの見解をご紹介します。

データで見る「休眠多数派」

オープンソースのエコシステムを分析すると、際立った傾向が見えてきます。現代のインターネットの大部分はごく少数のパッケージによって支えられている一方、圧倒的多数はほとんど使われていないか、完全に放棄されています。

リスクを理解するには、オープンソースのエコシステムの構造を振り返る必要があります。Snykはサプライチェーンの実態を明らかにするLinux Foundationとハーバード大学のCensus IIレポートに重要なデータを提供しました。パッケージの健全性データを利用率に重ねると、明確な階層が浮かび上がります。

オープンソースのエコシステムのほぼ90%は「休眠多数派」に属します。放棄された実験、フォーク、メンテナンスされていないプロジェクトが何百万も存在します。人間の開発者がこの階層からパッケージを選ぶことはほとんどありません。しかし、AIシステムは選ぶことがあります。

AIとの隔たり

人間の開発者は、広く使われるフレームワーク、信頼できるインフラライブラリ、成熟した専門分野向けツールなど、エコシステムの上位階層を自然に選びます。一方、LLMはインターネットの歴史全体にわたる膨大なコードリポジトリでトレーニングされているため、「休眠多数派」を含むエコシステムのあらゆる層からパッケージを提示する可能性があります。

その結果、LLMはエコシステムの下位89.5%にあたる、放棄されたプロジェクトやメンテナンスされていないフォーク、さらには単純な「Hello World」の実験までを推奨する可能性があります。たとえば、セキュリティ研究者のLuke Hindsは、LLMがGoパッケージgorilla/sessionsを推奨したやり取りを共有しました。

このLLMの推奨に問題があるのは、gorilla/sessionsがアーカイブ済みだからです。アーカイブされたリポジトリは更新されなくなるため、このパッケージを使うと、長期的なメンテナンス負債や、修正されないサプライチェーンのリスクが生じます。

さらに厄介なのが、LLMのハルシネーション（「AIによるパッケージの幻覚」）です。実在しないパッケージを自信満々に推奨することがあります。これにより、次の2つの新たな攻撃経路が生まれます。

1. ゾンビの復活：LLMが、特定のニッチな問題を解決できるという理由で、「休眠多数派」に属する5年前のメンテナンスされていないパッケージを提案します。誰も脆弱性を調べないためCVEは0件ですが、重大な欠陥が含まれている可能性があります。

1. スロップスクワッティング（AIのハルシネーションを悪用した攻撃）：攻撃者は、LLMが幻覚として出力しそうな一般的なパッケージ名（例：実在するhuggingface-cliに対するhuggingface-cli-tool）を予測して登録し、悪意のあるペイロードを仕込みます。AIがこの「それらしい」偽のパッケージを提案すると、開発者はマルウェアをインストールしてしまいます。

戦略の転換：「人気度」から「来歴」へ

CISOとして、開発者がAIの提案を一つひとつ手動で検証することには頼れません。開発のスピードが速すぎるからです。プログラムを「問題のあるものをスキャンする」ことから「良いものを確保する」ことへと転換する必要があります。これまでの記事では、CISOの役割と、変化し続ける責任について解説してきました。

同様に、エンジニアもnpmやPyPIからパッケージを選び、インストールする作業をAIコーディングエージェントに最初から最後まで任せることはできません。ソフトウェアサプライチェーン固有のリスクにより、マルウェアやデータ収集を仕込んだ不正なパッケージが使われる可能性があるためです。たとえば、npmのpostinstallパッケージマネージャー機能が悪用されるケースがあります。

より安全で自律的な成果を実現するために、AIコーディングエージェントやソフトウェアエンジニアにパッケージの健全性を判断する基準を提供するにはどうすればよいでしょうか。Snykが用意する「舗装された道」がその答えです。

1. security.snyk.ioで信頼できるパッケージを見つける

依存関係を選ぶ前に、開発者とAIシステムがオープンソースパッケージの評判と信頼性を把握できる必要があります。新しいSnyk Security Databaseのエクスペリエンスでは、パッケージの信頼性を示す情報を一元的に確認できます。サポート対象のエコシステム全体から、広く採用され、適切にメンテナンスされている、信頼性の高いプロジェクトをすばやく特定できます。

戦略：パッケージの調査時にSnyk Security Databaseの情報を活用するよう、開発者やプラットフォームチームに促しましょう。選定プロセスの早い段階で、成熟した信頼性の高い依存関係を優先できます。

2. Snyk Package Health APIで脆弱性だけでなく健全性も確認する

既知の脆弱性がないパッケージが、必ずしも安全とは限りません。放棄されていたり、メンテナンスされていなかったり、信頼できるコミュニティがなかったりする可能性があります。安全なソフトウェアサプライチェーンには、CVEだけでなくパッケージの健全性を評価することが欠かせません。Snyk Package Health APIは、主要なエコシステム（npm、PyPI、Maven、NuGet、Go）全体のパッケージ単位およびバージョン単位の情報を提供し、次のようなシグナルを明らかにします。

• セキュリティ状況。

• メンテナンス活動とライフサイクルの指標。

• 人気度と採用状況の指標。

• コミュニティの活動を示すシグナル。

これにより、エンジニアリングプラットフォーム、CI/CDパイプライン、AI駆動の開発ツールは、依存関係を検討する時点で、その品質、持続可能性、エコシステムにおけるリスクを自動的に評価できます。特に、依存関係を選択または導入するタイミングで評価できるようになります。

戦略：パッケージの健全性に関する情報を、依存関係の選定ワークフローやAI支援開発環境に直接組み込みましょう。依存関係を追加した後ではなく、追加する前に適合性を評価できます。

ツール：Snyk Package Health APIを活用して、パッケージ選定、アップグレード計画、自動化された依存関係ガバナンスを支援しましょう。実装の詳細は、パッケージ単位のエンドポイントとパッケージバージョン単位のエンドポイントをご覧ください。

CLI、CI、GitHub CIチェックを通じてSCAを統合している場合、ビルド中やビルド前に、Snyk Open SourceがLLMによる不適切なコーディング提案も検出します（コーディングエージェントが悪意のあるパッケージを対象にnpm install …を実行しようとする場面を想像してください）。

3. Snyk Studioで依存関係を導入する段階から安全性を確保する

健全性に関する情報があっても、開発者やAIコーディングアシスタントが依存関係を自動的に導入する可能性は残ります。セキュリティ対策はCI/CDのスキャン時だけでなく、依存関係を選ぶ時点でも適用する必要があります。

Snyk Studio Package Healthフローは、パッケージの健全性に関する情報をAI支援開発ワークフローに直接組み込みます。AIコーディングアシスタントが依存関係の追加や更新を提案すると、Snyk Studioがインストール前にパッケージの健全性チェックを自動的に実行し、リスクのシグナルをリアルタイムで評価できます。これにより、健全性に問題があるパッケージ、メンテナンスされていないパッケージ、リスクの高いパッケージがコードベースに入るのを、最も早い段階、つまり「導入時点で安全を確保する」タイミングで防止できます。

戦略：新しい依存関係を導入する前にPackage Healthチェックを自動実行するよう、AIコーディングアシスタントを設定します。リスクのシグナルが見つかった場合はインストールを一時停止またはブロックし、続行にはユーザーの明示的な承認を必須にします。

4. ハルシネーションから防御する

AIコーディングアシスタントが、公開レジストリに存在しないパッケージを推奨することがあります。このような「パッケージが見つからない」事象は、単なる開発者のミスではなく、サプライチェーンセキュリティに関わるシグナルとして扱うべきです。攻撃者が後から似た名前のパッケージを登録し、こうしたミスにつけ込む可能性があります。

戦略：依存関係の解決に失敗した場合（例：「パッケージが見つからない」）は、セキュリティ上重要な事象として扱います。依存関係が提案された経緯を調査し、先に進む前にパッケージ名が正当なものか検証しましょう。

次の画像では、WindusrfコーディングエージェントがSnyk Studioを呼び出し、Snyk MCP Serverの他のセキュリティツールの一部であるsnyk_package_health_checkツールを使ってパッケージの健全性を分析する様子を確認できます。Snyk Studioをインストールすると、AIエージェントはパッケージがメンテナンス可能で、セキュリティ上の問題がなく、悪意のあるものではないことを確認できます。

AI生成コードを安全にするSnykの使命

Snykは、開発者を第一に考えたセキュリティこそが、セキュリティを大規模に展開する唯一の方法だという信念のもとに設立されました。AIコーディングエージェントの時代には、その重要性はさらに高まります。Census IIのデータが示すように、オープンソースのエコシステムは広大で、その大部分は休眠状態です。

私たちの役割は、AIと開発者が、世界を支える健全で活発な上位10%に集中できるようにし、混沌とした残りの90%に対する防御を自動化することです。AIに信頼性を検証させるだけではありません。AIの信頼性を検証しましょう。

AIコーディングアシスタントがソフトウェアサプライチェーンのリスクをどう変えているのか、詳しく知りたい方は、AI時代のPythonを安全にするためのガイドをご覧ください。