AI エージェントが古い依存ライブラリを選ぶ理由と対策

AI コーディングエージェントにプロジェクトの雛形作成や依存追加を任せたところ、選ばれたライブラリのバージョンが妙に古かった。そんな経験はないでしょうか。この記事では、なぜ AI が古い依存ライブラリを選びがちなのか、その原因を仕組みから解きほぐし、AI に任せる際の落とし穴と回避の考え方までをまとめます。

TL;DR

• AI コーディングエージェントは、依存ライブラリのバージョンを「最新」ではなく「頻度の高い表記」で選ぶ傾向があります。結果として、1 つ前どころか既に非推奨（deprecated）にバージョンが選ばれることがあります。
• 主因は学習データのカットオフではなく、学習データの分布の偏りです。頻度が出力を左右することは複数の研究で示されており、この傾向は最新世代のモデルでも確認されています。
• この傾向は「新しい方が良い」という指示では直りません。AI の出力を検証前提で扱い、一次情報の参照と検証ゲートを開発フローに組み込むガードレール設計で担保します。

何が起きているのか

私たちが実際に観測した例を紹介します。AI エージェントに Next.js のプロジェクトを初期化させたところ、選ばれたのは Next.js 14 系でした。けれども、この生成を行った時点で最新の安定版は 16 系です。React も同様で、19 が既に公開されているのに 18 系が選ばれていました。

なぜここまで古いバージョンが選ばれるのか。これを理解すると、対策の打ち所が見えてきます。

古いバージョンが選ばれる理由

学習データのカットオフは「天井」にすぎない

最初に思い浮かぶ理由は、モデルの学習データに区切り（カットオフ）がある、というものです。確かにモデルはカットオフより後に登場したバージョンを知りません。ただし、これだけでは今回の現象を説明できません。先ほどの例では、より新しい安定版（Next.js の 15 や 16）が既に存在していたのに、さらに古い 14 が選ばれているからです。

カットオフが決めるのは「選べる上限（天井）」だけです。天井の下でなぜ床近くまで落ちるのか、という問いには別の説明が要ります。

主因は学習データの分布の偏り

ここが本質です。古いメジャーほど、チュートリアル、Q&A サイトの回答、公開リポジトリのサンプル、解説記事が、長い年月をかけて大量に蓄積します。逆に、新しい版は世に出てからの時間が短く、学習データ上の露出が極端に少なくなります。

つまり「情報量は古いバージョンほど多い」という偏りが、学習データの中に構造的に存在します。AI から見ると、あるパッケージに最も多く結び付いていたバージョン表記は、最新版ではなく、長年情報が積み上がった枯れた版なのです。

頻度の高い表記に引き寄せられる生成の性質

LLM（大量のテキストで学習した言語生成モデル）は、次のトークン（単語などの最小単位）の確率分布に従って文章を生成します。確率の高い系列ほど選ばれやすく、この傾向は厳密には貪欲法や低い温度での復号（出力のばらつきを抑える設定）で顕著になります。バージョンを書く場面でも、学習データ中で頻度の高い表記、すなわち情報量の多い古い版が選ばれやすくなります。モデルは「自分が知っている最大バージョン」を答えるのではなく、「データ中でありふれた表記」を再生産します。だから、選べる上限（15 や 16）よりも下振れして、頻度の高い 14 に落ち着きます。

学習データ中の頻度がモデルの出力を左右することは、複数の研究で報告されています。

• Kandpal らの研究（2023）は、事実に関する質問応答の正答率が、事前学習で見た関連文書の数と強く相関することを示しています。
• Razeghi らの研究（2022）は、数値推論の正答率が、その語の事前学習データ中の出現頻度と相関することを報告しています。出現頻度が上位 10% の語は、下位 10% の語より精度が高く、条件によっては 70 ポイント以上の差が見られたとされています。
• Carlini らの研究（2023）は、学習データの逐語的な記憶・再生産が、モデル規模や文脈長に加えて、学習データ中での重複回数が増えるほど対数線形に増加することを示しています。「頻出する文字列ほど再生産されやすい」というこの結果は、バージョン文字列のような短い定型表記の生成に最も近い知見です。

ここでお断りしておくと、これら 3 本はいずれも質問応答・数値推論・記憶化を対象とした研究であり、「ライブラリのバージョン選択」そのものを測定したものではありません。古い版が選ばれる件は、これらが共通して示す「頻度が出力を左右する」効果の現れとみなす妥当な解釈であって、直接実証された事実ではない、という位置づけです。

数年前のモデルだけの話ではない

ここまでの説明には、「それは少し前のモデルの話で、最新世代では解消しているのではないか」という疑問が自然に浮かびます。しかし、近年の研究でも、現行世代のモデルに同様の傾向が観測されています。

• Zhu らの研究（2025, NAACL 2025）は、LLM の時間的な汎化能力を評価する枠組み（FreshBench）を提案し、時間の経過に伴う有意なバイアスと性能の低下を確認しています。モデルが新しくなっても、時間軸に沿った陳腐化の傾向は残るという指摘です。
• Ashik らの研究（2026, arXiv プレプリント）は、Python ライブラリの実際の API 更新 270 件で 11 のモデルを評価しました。API が変化した場面で、ドキュメントを与えない場合に実行可能なコードを生成できた割合は 42.55%、構造化したドキュメントと大型モデルを組み合わせても 66.36% にとどまったと報告しています。これは、私たちが扱っているコード生成での古い・陳腐化したライブラリや API の問題に最も近い、直接的な証拠です。

基礎となる研究との役割分担を整理しておきます。Kandpal ら、Razeghi ら、Carlini らの研究（2022〜2023）は、頻度が出力を左右するという「メカニズム」を示すものでした。一方、Zhu らや Ashik らの研究（2024〜2026）は、現行世代のモデルでも陳腐化が実際に起きるという「実証」にあたります。前者はバージョン選択そのものを測ったわけではないという留保が残りますが、後者の Ashik らはコード生成を直接の対象としており、本テーマに最も近い知見です。

重要なのは、これが「推論」ではなく「生成の癖」だという点です。モデルが文脈上「新しい方が望ましいはず」と扱っていても、外部の情報源を明示的に参照しない限り、出力は頻度の高い古い版に戻ります。意志や心がけで直る種類の挙動ではありません。

対策：AI の出力を検証前提で扱うガードレールを設計する

ここまでの整理から導かれる原則はシンプルです。生成の癖は意志では直らないため、AI の判断そのものに依存せず、仕組みで最新性を担保します。鍵になるのは、AI を賢くしようとすることではなく、AI の周りに検証の枠組み（ハーネス）を設計することです。

原則：デフォルト信頼ではなく検証前提

出発点は、AI の出力を「デフォルトで信頼する」のではなく「検証を前提に扱う」という構えです。生成物は仮の答えであり、確定はその先の検証で行う。この前提を開発フロー全体の共通認識にしておくと、後続の打ち手が一貫します。

記憶ではなく一次情報を参照させる

頻度の高い表記への引き寄せは、AI が自分の記憶だけで答えるときに起きます。そこで、バージョンのような「いま正しい値が外部に存在する情報」は、記憶で答えさせず、権威ある一次情報を参照させる工程を挟みます。エージェントを公式の情報源に接続し、最新の事実を取りに行かせてから書かせる、という設計です。どのツールを使うかよりも、「記憶で確定させない」という工程上の取り決めが効きます。

生成結果を検証するゲートを工程に置く

ただし、一次情報を参照させるだけでは足りません。前節で触れた Ashik らの研究は、最新の API ドキュメントを文脈で与えても、モデルの古い内部知識が残って完全には直らないことを示しています。だからこそ、生成と採用の間に検証のゲートを置きます。人手のレビューでも、自動チェックでも構いません。狙いは、古い版や非推奨の選択が無検証のまま採用される経路をふさぐことです。ゲートを一箇所でも通す設計にしておけば、AI 生成かどうかにかかわらず取りこぼしを拾えます。

鮮度維持を継続的な仕組みとして持つ

一度新しくしても、放置すればまた古くなります。依存の鮮度は、その時々の判断ではなく、継続的に見直される仕組みとして持つことが望ましいです。更新の検知と反映を定期的なプロセスに組み込んでおけば、属人的な気づきに頼らずに鮮度を保てます。

任せる量ではなく検証の置き所で考える

これらに共通するのは、設計の重心の置き方です。AI 活用の成熟度は「どれだけ AI に任せるか」ではなく「どこに検証ガードレールを置くか」で決まる、と私たちは考えています。任せる範囲を広げることと、検証の枠組みを整えることは、対立しません。むしろ後者が整うほど、前者を安全に広げられます。

運用設計の視点

この話は技術論にとどまりません。AI に書かせたコードは「動くけれど古い、あるいは非推奨」というリスクをはらみます。古い版のままだと、セキュリティ修正の取りこぼし、サポート期限切れ、周辺ツールとの互換性といった観点で、後から問題になりえます。

対策の中心は、新しいツールの導入というより運用設計です。検証を、人またはツールによってワークフローへ組み込めているかどうか。DX 推進の現場では、この観点を経営層に説明できる形にしておくと、AI 活用の範囲を安全に広げる判断がしやすくなります。

まとめ

AI コーディングエージェントが古い依存ライブラリを選ぶのは、カットオフだけが理由ではなく、学習データの分布の偏りと、頻度が出力を左右する効果が主因です。しかもこの傾向は、近年・現行世代のモデルでも確認されています。指示や心がけでは直らないため、AI の出力を検証前提で扱い、一次情報の参照・検証ゲート・継続的な鮮度維持という枠組みを設計側に組み込むのが現実的な解です。AI の判断を賢くしようとするより、AI の周りに検証のハーネスを置く。この発想に立てれば、AI 活用の利点を保ったまま、古い依存に起因するリスクを抑えられます。

つくばAIラボでは、AI を前提とした開発・運用の設計についてもご相談を承っています。

出典

• Kandpal et al. (2023) "Large Language Models Struggle to Learn Long-Tail Knowledge" (ICML 2023), arXiv:2211.08411: https://arxiv.org/abs/2211.08411
• Razeghi et al. (2022) "Impact of Pretraining Term Frequencies on Few-Shot Reasoning" (Findings of EMNLP 2022), arXiv:2202.07206: https://arxiv.org/abs/2202.07206
• Carlini et al. (2023) "Quantifying Memorization Across Neural Language Models" (ICLR 2023), arXiv:2202.07646: https://arxiv.org/abs/2202.07646
• Zhu et al. (2025) "Is Your LLM Outdated? A Deep Look at Temporal Generalization" (NAACL 2025), arXiv:2405.08460: https://arxiv.org/abs/2405.08460
• Ashik et al. (2026) "When LLMs Lag Behind: Knowledge Conflicts from Evolving APIs in Code Generation"（arXiv プレプリント、査読前）, arXiv:2604.09515: https://arxiv.org/abs/2604.09515