💻 computer science

A Study of LLMs' Preferences for Libraries and Programming Languages

この論文は、大規模言語モデル（LLM）がコード生成において機能の適切さよりも人気や慣習を優先し、不要なライブラリの過剰使用や Python への偏った言語選択を示す傾向があることを初めて実証的に明らかにし、より適切な選択を促すための微調整や評価基準の必要性を指摘しています。

原著者： Lukas Twist, Jie M. Zhang, Mark Harman, Don Syme, Joost Noppen, Helen Yannakoudakis, Detlef Nauck

公開日 2026-04-09

📖 1 分で読めます☕ さくっと読める

CC BY 4.0

原著者： Lukas Twist, Jie M. Zhang, Mark Harman, Don Syme, Joost Noppen, Helen Yannakoudakis, Detlef Nauck

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

論文の要約：AI は「流行り」に溺れている？

～大規模言語モデル（LLM）の「プログラミングの好み」を調査した研究～

この論文は、**「AI がコードを書くとき、どんな『道具（ライブラリ）』や『言語』を好んで選ぶのか？」**という、これまであまり注目されていなかった側面を調査したものです。

AI はコードを正しく書けるか（機能性）はよく評価されますが、「なぜその道具を選んだのか」という設計上の好みについては、あまり深く掘り下げられていませんでした。この研究は、8 種類の最新の AI を使って、その「隠れた好み」を暴き出しました。

🍔 1. 結論：AI は「定番メニュー」しか頼まない

研究の結果、AI は**「流行り」や「新しい技術」よりも、「昔からある定番」を過剰に好む**ことがわかりました。

🍕 比喩：AI は「ピザ屋」

AI を巨大なピザ屋のシェフだと想像してください。

本来の役割： 客が「低カロリーでヘルシーなサラダピザ（高性能な Rust や C++）」を頼んでも、シェフは**「定番のチーズピザ（Python）」**を出し続けます。
現実： 客が「シンプルなパン（標準ライブラリ）」を頼んだのに、シェフは**「豪華なトッピング（NumPy や Pandas）」**を無理やり乗せてきます。

具体的な発見：

Python への執着：
- 高速で安全な処理が必要な場面（例：高速取引システムや並列処理）でも、AI は58% の確率で Pythonを選びます。
- 本来は C++ や Rust などが適しているはずなのに、AI は「Python なら誰でも知ってるから大丈夫」という理由で、性能が落ちる選択を繰り返します。
- 驚きの事実： 高性能な言語である「Rust」は、この研究では一度も使われませんでした。
ライブラリの「過剰摂取」：
- 単純な計算タスクでも、AI はNumPy（データ分析用の重い道具）を45% のケースで不要な場面で使っていました。
- 例：「リンゴの重さを足す」だけの計算なのに、「大規模なリンゴ倉庫管理システム（NumPy）」を持ち出してくるようなものです。
- 新しく速いライブラリ（Polars など）があるのに、AI は古い定番（Pandas）を選び続けます。

🗣️ 2. 口と手がバラバラ：AI の「言動不一致」

AI は口では「このタスクには Rust がベストですよ」とアドバイスするのに、実際にコードを書くときは**「やっぱり Python にしとくね」**と裏切ることが多いことがわかりました。

比喩：
- 口（アドバイス）： 「この山登りには、軽くて丈夫な登山靴（Rust）がベストですよ！」
- 手（実際の行動）： 「でも、僕が持っているのはスニーカー（Python）だから、これで行きます！」
結果： AI の「言葉のアドバイス」と「実際のコード」の一致度は非常に低く、83% のケースで矛盾していました。つまり、AI が「何を使うべきか」を口で説明できる能力と、実際に「何を使うか」を選ぶ能力は、別物なのです。

🌪️ 3. なぜこんなことが起きるの？

AI がこんな「偏った好み」を持つ理由は、**「学習データ」と「訓練の仕方」**にあります。

学習データの影響：
AI は GitHub などの膨大なコードデータで勉強しました。しかし、そこには**「Python のコード」が圧倒的に多い**です。
- 比喩： 料理の勉強を「イタリア料理の本」だけでしかしていないシェフは、どんな客の注文でも「パスタ」を出したくなるのと同じです。
訓練の偏り：
開発者が AI を作る際、Python のコードを優先的に学習させたり、Python が得意になるように調整（微調整）したりしている可能性があります。

⚖️ 4. 良い点と悪い点

この「偏り」には、両面があります。

✅ 良い点（メリット）：
- 安心感： 誰もが知っている定番の道具を使うので、初心者でも読みやすく、すぐに動きます。
- 標準化： みんなが同じ道具を使うので、コードの共有や教育がしやすくなります。
❌ 悪い点（リスク）：
- 性能の低下： 本来はもっと速い・安全な技術があるのに、AI が「Python 一択」で固執すると、システムが遅くなったり、バグが起きやすくなったりします。
- イノベーションの阻害： 新しい優れた技術（Rust や新しいライブラリ）が紹介されず、古い技術だけが広まる「悪循環」が生まれます。
- 盲信の危険： 初心者が AI の選択を疑わずに信じてしまうと、不適切な技術スタックでプロジェクトが進んでしまうリスクがあります。

🔮 5. 私たちができること

この研究は、AI を使う側も作る側も、**「AI が選んだからといって、それが最適解とは限らない」**と意識する必要があると警告しています。

開発者へのアドバイス：
- AI が「Python で書け」と言っても、そのプロジェクトが「高速処理」を必要とするなら、**「いや、今回は Rust にしよう」**と人間が判断し直す必要があります。
- AI の「言葉のアドバイス」と「実際のコード」が一致しているか、常にチェックしましょう。
AI 開発者への提言：
- 学習データをもっと多様にする。
- 「Python 以外も選べるように」AI を訓練し直す。
- 「正解」だけでなく、「なぜその言語を選んだか」という判断基準も評価する新しいテスト基準を作る。

📝 まとめ

この論文は、「AI は賢いけれど、実は『保守的で流行に遅れた』選択をしがち」という重要な発見を伝えています。
AI は素晴らしいアシスタントですが、「道具の選び方」まで任せてはいけません。人間が最終的に「これが本当にベストな選択か？」を見極める目が、これからはより重要になります。

論文「A Study of LLMs'Preferences for Libraries and Programming Languages」の技術的サマリー

この論文は、大規模言語モデル（LLM）がコード生成を行う際に、どのライブラリやプログラミング言語を選択するかという重要な設計判断における「選好（Preferences）」と「バイアス」を初めて体系的に実証研究したものです。既存の評価が機能の正しさ（Functional Correctness）や構文の妥当性（Syntactic Validity）に焦点を当てているのに対し、本論文は「なぜその技術が選ばれたか」という設計判断の質と、それがソフトウェア生態系に与える影響を調査しています。

以下に、問題定義、手法、主要な貢献、結果、および意義について詳細をまとめます。

1. 問題定義 (Problem)

LLM のコード生成能力は飛躍的に向上していますが、以下の点における未解明な課題が存在します。

技術選定のバイアス: LLM が特定のライブラリや言語を過剰に選好し、タスクの要件に最適ではない技術を選択する傾向があるか。
生態系への影響: LLM が生成するコードが主流技術（Python や NumPy など）に偏ることで、多様な代替技術の採用が阻害され、ソフトウェア生態系の多様性が失われるリスク。
推奨と実装の不一致: LLM が自然言語（NL）で推奨する技術と、実際にコード生成時に使用する技術が一致しているか。
評価の欠如: 既存のベンチマークは「正解」を前提としており、LLM が「適切な技術選択」を行っているかどうかを評価する指標が不足している。

2. 研究方法 (Methodology)

研究では、8 つの異なるプロダクショングレードの LLM（GPT-4o-mini, GPT-3.5-turbo, Claude-3.5 Sonnet/Haiku, Llama-3.2-3B, Mistral-7B, Qwen-2.5-Coder, DeepSeek-LLM）を対象に、以下の 3 つの実験を行いました。

実験 1: ライブラリ選好 (Library Preferences)

対象: Python における外部ライブラリの選択。
タスク:
1. ベンチマークタスク: BigCodeBench（1,140 タスク）から、Ground Truth（正解）に外部ライブラリが含まれていない 525 タスクを選択。LLM に「外部ライブラリを使用するよう指示」してコードを生成させました。
2. プロジェクト初期化タスク: データベース、深層学習、分散コンピューティング、Web スクレイパー、Web サーバーの 5 つのプロジェクトに対し、LLM に初期コードの作成を依頼。
分析: 使用されたライブラリの分布、Ground Truth との乖離、および GitHub のスター数（コミュニティの勢い）との相関を分析しました。

実験 2: プログラミング言語選好 (Language Preferences)

対象: 言語が指定されていない場合の言語選択。
タスク:
1. ベンチマークタスク: Multi-HumanEval, MBXP, AixBench, CoNaLa, APPS, CodeContests などの言語非依存データセットを使用。
2. プロジェクト初期化タスク: Python が非最適とされる領域（並行 Web サーバー、低レイテンシ取引プラットフォーム、システムレベルアプリケーションなど）で、LLM に初期コード作成を依頼。
分析: 生成されたコードで使用された言語の分布を調査し、Python への依存度を測定しました。

実験 3: 推奨の一貫性 (Recommendation Consistency)

対象: LLM の自然言語での推奨と、実際のコード生成での使用の一貫性。
手法: 上記のプロジェクト初期化タスクに対し、まず「どのライブラリ/言語が最適か」を自然言語でリストアップさせ、その後コードを生成させました。
分析: 推奨ランキングと実際の使用頻度ランキングの相関を、Kendall's $\tau_b$ 係数を用いて測定しました。

3. 主要な結果 (Key Results)

1. 確立されたライブラリへの過剰依存

NumPy の過剰使用: 全モデルにおいて、タスクに不要な場合でも NumPy が頻繁に使用されました。ベンチマークタスクの最大**45%**で、Ground Truth に含まれていないにもかかわらず NumPy がインポートされていました。
新興ライブラリの無視: 高いコミュニティの勢い（GitHub スターの成長率）を持つ新しいライブラリ（例：Polars, Plotly, FastAPI, Ray）が、古い確立されたライブラリ（pandas, Matplotlib, Flask, Dask）に比べて著しく低く使用されました。
- 例：Web サーバー作成において、Flask（2010 年）は 88% で使用されたのに対し、より高速な採用が進む FastAPI（2018 年）は 9% しか使用されませんでした。

2. Python への強力なバイアス

ベンチマークタスク: ほぼすべてのデータセットで、LLM は**90%〜97%**の確率で Python を選択しました。
プロジェクト初期化タスク（非最適領域）: Python がパフォーマンスやメモリ安全性の観点から非最適とされるタスク（低レイテンシ取引、並列処理など）においても、**58%**のケースで Python が選択されました。
Rust の不使用: 高性能が求められるタスクにおいて、Rust は一度も使用されませんでした。

3. 推奨と実装の不一致

LLM が自然言語で推奨する技術と、実際にコード生成で使用する技術の間には低い相関しか見られませんでした。
特に言語選択において、推奨ランキングと使用ランキングの一致は7/40のケースのみでした。LLM は「Python が最適ではない」と口頭で言いつつ、コードでは Python を生成するという矛盾を示しました。

4. 主要な貢献 (Key Contributions)

初の体系的な研究: コード生成における LLM のライブラリおよびプログラミング言語選好を定量化した最初の研究。
バイアスの可視化と定量化: LLM が「人気」や「慣れ」を「適切さ」や「最適性」よりも優先する傾向を明確に示し、その影響範囲（最大 45% の過剰使用、58% の非最適言語選択）を数値化しました。
オープンソースの提供: 研究で用いたコード、データセット、完全な結果を GitHub で公開し、今後の調査を促進しています。

5. 意義と示唆 (Significance & Implications)

技術的・実用的意義

信頼性の向上: LLM が生成するコードの「設計判断」の質を評価する新たな視点を提供します。単に「動くコード」かだけでなく、「適切な技術スタックか」が重要であることを示唆しています。
フィードバックループのリスク: LLM が既存の主流技術のみを生成することで、トレーニングデータにさらに主流技術が蓄積され、多様性が失われる「モデル崩壊（Model Collapse）」や生態系の均質化のリスクを指摘しています。

今後の方向性

ファインチューニングとデータ多様化: 特定の技術（Python や NumPy）へのバイアスを軽減するため、トレーニングデータの多様化や、タスク要件に最適な技術選択を促すファインチューニングの必要性が強調されています。
評価ベンチマークの進化: 正解だけでなく、「なぜその技術が選ばれたか」という設計判断の正当性を評価する指標の開発が求められています。
プロンプトエンジニアリング: 推論（Chain-of-Thought）を促すプロンプトにより、推奨と実装の一貫性をある程度改善できる可能性が示唆されました（ただし完全な解決には至っていません）。

結論

本論文は、LLM がコード生成において「最も適切な技術」ではなく、「最も見慣れた技術」を選択する傾向が強く存在することを実証しました。このバイアスは、開発者の技術選定を歪め、ソフトウェア生態系の多様性と最適性を損なう可能性があります。信頼性の高い AI 支援開発を実現するためには、LLM の設計、トレーニングデータ、評価基準において、この「技術選好バイアス」への対策が不可欠であると結論付けています。