Correct Code, Vulnerable Dependencies: A Large Scale Measurement Study of LLM-Specified Library Versions
大規模な測定研究は、LLM が特定のリスクのあるリリースに対する構造的バイアスにより、生成された Python コードにおいて脆弱で互換性のないサードパーティ製ライブラリのバージョンを頻繁に指定することを明らかにし、AI 支援型ソフトウェア開発においてこれまで見過ごされてきた重要なリスク領域を浮き彫りにしている。
原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
超優秀で驚くほど速い個人秘書を、あなたのソフトウェアプロジェクトのコード作成のために雇うと想像してください。この秘書は大規模言語モデル（LLM）によって駆動されており、「ドアを施錠する方法」や「メッセージを送信する方法」といったロジックの記述には長けています。
しかし、落とし穴があります。コードを動作させるためには、この秘書は既存の「ツール」（サードパーティ製ライブラリ）を使用する必要があります。この論文が調査している問題は、秘書が単にツールを手に取るだけでなく、それらのツールから特定の、古びた、そして時として破損したバージョンを、あなたが気づかないうちに手に取ってしまうという点です。
以下に、研究の発見を簡単なアナロジーを用いて解説します。
1. 「レシピ」と「買い物リスト」
研究者たちは、秘書にコードを依頼する2つの方法をテストしました。
- 「インライン」モード: コードスニペットを依頼すると、秘書はコードを書き、各ツールの隣に「ツールX、バージョン1.0を使用する」といった小さな注記を追加します。
- 「マニフェスト」モード: コードスニペットと、ツール用の別々の買い物リスト（
requirements.txtファイル）の両方を秘書に書かせます。
発見:
「インライン」の注記を求められた場合、秘書は非常に熱心に正確なバージョンを指定しました（95% の頻度）。しかし、「買い物リスト」を求められた途端、急に怠惰で曖昧になり、バージョン番号を空白にする傾向が見られました（6%〜59% の頻度のみ）。
- アナロジー: 料理人にレシピを書くよう頼むと、「2015 年産の塩を正確に使用すること」と言うのに、キッチン全体の買い物リストを書くよう頼むと、単に「塩」と書き、どの年の塩を買うかはあなたに任せてしまうようなものです。
2. 「賞味期限切れの牛乳」問題（セキュリティリスク）
研究によると、秘書が特定のバージョンを選択する場合、その選択はしばしば危険であることが分かりました。
- 統計: 37%〜56% の頻度で、秘書が選択した特定バージョンには既知のセキュリティ脆弱性（CVE）が含まれていました。
- 深刻度: これらの脆弱性のほとんどは「クリティカル」または「高」の深刻度でした。
- 意外な事実: これらの脆弱性は秘密ではありませんでした。それらは秘書がトレーニングされる以前から公開されていた情報です。秘書は単にそれらを回避すべきだと知らなかっただけです。
- アナロジー: 秘書が常に 3 年前に賞味期限が切れた牛乳を選ぶタイムトラベラーだと想像してください。賞味期限は箱に何年も前に印刷されていたにもかかわらず、秘書はその賞味期限切れの牛乳を「新鮮だ」と思い込んであなたに渡し続けるのです。
3. 「収束」効果（誰もが同じ悪いものを選ぶ）
異なる AI モデルが異なるバージョンを選ぶかもしれないと思うかもしれません。しかし、そうではありません。
- 発見: Google、OpenAI、Alibaba などの 10 種類のモデルすべてが、同じ小さなセットのリスクのあるバージョンに収束しました。秘書が「ツール X」を選ぶ場合、より新しく安全なバージョンが存在しても、ほぼ常に「バージョン 2.31.0」を選びます。
- アナロジー: 街中のすべての人が、背景に関係なく、ソールが壊れていることが知られている全く同じ靴を買うと決めたようなものです。これは偶然ではなく、同じ古い教科書から学んだ共有された習慣です。
4. 「壊れた鍵」問題（互換性）
ツールが危険でなくても、適合しない可能性があります。
- 発見: 秘書が選択したバージョンは、インストールできなかったり、書かれたコードと互換性がなかったりすることが多かったです。
- 静的チェック: コードがインストールすらされませんでした（四角い杭を丸い穴に無理やり入れようとするようなものです）。
- 動的チェック: インストールできたとしても、実行しようとするとコードはクラッシュしました。
- 原因: 秘書は非常に古いバージョンのツールを選ぶことを好みます。これらの古いバージョンは、現代のコンピュータから削除されたシステムの一部に依存しています。
- アナロジー: 秘書は「電気を点けろ」というコードを書きますが、2026 年の家のソケットには存在しない 1990 年製の電球を指定します。コードは完璧ですが、電球はネジ込むことができません。
5. なぜ単に「秘書に良くなるよう指示する」だけではダメなのか？
研究者たちはこれを修正するためにいくつかの試みを行いました。
- 「安全にしてください」というプロンプト: 秘書に「セキュリティの穴があるバージョンは使用しないでください」と伝えました。
- 結果: 機能しませんでした。秘書は依然として悪いバージョンを選びました。
- 理由: 秘書はルールを「忘れている」のではなく、単に最新の安全警告データベースに接続されていないだけです。2023 年の教科書を暗記した学生に、2025 年に制定された新しい法律を回避するよう頼むようなものです。彼らの頭の中には、その情報が物理的に存在しないのです。
- 「外部アンカー」修正: 研究者が秘書に、人間が提供する厳格な買い物リストのような、承認済みの安全バージョンのリストを使用させるように強制したところ、問題は消えました。
- 結果: セキュリティリスクは低下し、コードは実際に動作しました。
結論
この論文は、LLM はコードの「ロジック」を書くのは得意ですが、ツールの「サプライチェーン」を管理するのは不得意であると結論付けています。
彼らは、一見完璧に見えるが実際には危険で古びた版の書籍を渡す、親切だが信頼できない図書館司書のようです。彼らが提案する特定のバージョン番号を信頼することはできません。それらをラフドラフトとして扱い、使用する前にセキュリティツールで必ずバージョン番号を再確認する必要があります。
問題は AI が「愚か」だからではありません。AI は古いデータでトレーニングされており、人気のあるが古いバージョンを好むように設定されており、現在の安全警告へのライブ接続を欠いているからです。AI がライブの安全ツールに接続されるまで、人間の開発者が賞味期限をチェックする役割を担わなければなりません。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。