技術的概要：LLM 支援によるゼロ依存性 Python ライブラリの経験的パフォーマンスと正しさ

問題定義

Python パッケージエコシステムは豊富である一方で、透過的依存関係、サプライチェーンリスク、デプロイの摩擦を通じて、著しいオーバーヘッドをもたらします。経験的調査によると、単一の宣言された依存関係が中央値で 8〜10 の追加の透過的パッケージをトリガーし、依存関係閉包内のコードの 70% 以上が一度も実行されないことが示されています。さらに、コード生成型の大規模言語モデル（LLM）は、存在しないパッケージ名を幻覚（ハルシネーション）として生成することが多く、潜在的なセキュリティ脆弱性を生み出しています。

開発者は依存関係を回避するために、小規模なユーティリティに対して「コピー＆ペースト」による再利用に頼ることが多いですが、このアプローチには体系的な正しさの保証、バージョン管理、パフォーマンスの基準値が欠けています。本研究の中心的な問いは以下の通りです：人気のあるサードパーティ製ユーティリティライブラリを、正しさやパフォーマンスを犠牲にすることなく、単一ファイルかつ標準ライブラリのみ（stdlib）の実装にどの程度置き換えることが可能であり、LLM は厳格な制約下でそのようなコードを効果的に生成できるか？

手法

著者は、zerodep と呼ばれる 44 の単一ファイル Python モジュールからなるキュレーションされたテストベッドを導入しました。各モジュールは、Python 標準ライブラリのみを使用して、人気のあるサードパーティ製ライブラリ（例：PyYAML、httpx、Pillow、tenacity）を再実装したものです。

設計制約

• ゼロ依存性: 外部インポートは禁止され、すべての機能は Python 標準ライブラリに依存しなければなりません。
• 単一ファイル: 各モジュールは、監査と埋め込みを簡素化するために、単一の .py ファイル内に収められています。
• API 互換性: モジュールは、参照ライブラリとのドロップイン互換性を提供します。
• 正しさの検証: 各モジュールには、同一の入力を使用して参照ライブラリとの動作を比較するテストスイートがペアで付随しています。

開発ワークフロー

モジュールは、人間と LLM の反復的な協働プロセスを通じて開発されました：

1. 仕様定義: API 表面と意図的な簡略化を定義します。
2. 生成: LLM（主に Claude および o シリーズモデル）が厳格な制約下で初期実装を生成します。
3. オラクル検証: 生成されたコードを参照ライブラリに対してテストし、失敗した場合は LLM にフィードバックして改善を図ります。
4. パフォーマンス評価: 回帰を特定するためにベンチマークを実行し、人間が重要なパスの最適化（例：特定の stdlib プリミティブの選択）を指導します。

評価範囲

本研究は、12 のカテゴリ（ネットワーク、プロトコル、シリアライゼーション、テキスト、暗号など）と 3 つの複雑度レベル（シンプル、ミディアム、サブシステム）にわたる 44 のモジュールを網羅しています。評価の焦点は以下の通りです：

• 正しさ: 数百のテストベクトルにわたる参照ライブラリに対する動作の同等性。
• パフォーマンス: 参照ライブラリに対する実行時間のベンチマーク。ここで「同等性（parity）」は、速度比が 2 倍以内（$0.5 \le r \le 2.0$）であることと定義されます。

主要な貢献

1. zerodep テストベッド: 各モジュールに正しさのテストスイートとパフォーマンスの基準値を備えた、バージョン管理されベンチマークされた 44 の stdlib 専用モジュールのコレクション。
2. 経験的正しさの評価: 動作の同等性が成立する領域と、意図的な簡略化が適用される領域の体系的な分析。
3. パフォーマンス特性の特定: 3 つの明確なパフォーマンス領域の特定：
   • 同等性: 参照ライブラリに対して 2 倍以内のパフォーマンス。
   • アーキテクチャ上の勝利: 参照ライブラリのオーバーヘッドを排除することによる大幅な高速化（5〜115 倍）。
   • C 拡張の崖: 参照ライブラリがコンパイル済みの C/Rust 拡張に依存している場合の著しいパフォーマンス低下。
4. LLM 支援開発の分析: 複雑度レベル全体における LLM の有効性に関する観察。複雑なサブシステムには人間によるアーキテクチャ指導の必要性を浮き彫りにしています。

結果

正しさ

44 のモジュールすべてが正しさのテストスイートを合格しました。本研究では、動作の乖離は API の不一致というよりも、YAML の null 表現や JSON のコメントの端数ケースなど、微妙なものであることが判明しました。意図的な API の簡略化（例：あまり使用されないバリデーターの省略）を伴うモジュールは、これらの省略を明確に文書化しています。

パフォーマンス領域

• アーキテクチャ上の勝利（高速）: 19 のモジュールが参照ライブラリよりも一貫して高速であり、多くの場合、桁違いの差があります。
  • 例: jsonc は commentjson よりも 75〜115 倍高速（eval を回避）；httpclient は httpx よりも 18〜32 倍高速（ミドルウェア層を除去）；yaml は PyYAML の純粋な Python パスよりも 6〜7 倍高速。
  • 原因: 多くのサードパーティ製ライブラリは、ターゲットとした stdlib 実装が回避するアーキテクチャ上のオーバーヘッド（プラグインシステム、中間表現など）を有しています。
• 同等性: 11 のモジュールがパフォーマンスの同等性（2 倍以内）を達成しています。
  • 例: dotenv、cache、retry（デコレータのオーバーヘッドにおいて）は、ほぼ正確な同等性またはわずかな改善を示します。
• C 拡張の崖（低速）: 6 のモジュールは、参照ライブラリがコンパイル済み拡張に依存しているため、著しく低速（多くの場合 10 倍以上）です。
  • 例: protobuf（google-protobuf よりも 6〜72 倍低速）、png（Pillow よりも 7〜45 倍低速）、純粋な Python 実装の aes（PyCryptodome よりも 300〜17,000 倍低速）。
  • 軽減策: aes モジュールはハイブリッドアプローチを示しており、subprocess を介してシステム OpenSSL に委譲することで、パッケージング上のゼロ依存性を維持しつつ、参照ライブラリに対して 1.5〜8 倍の高速化を達成しています。

LLM の有効性

• シンプル/ミディアムレベル: LLM は 1〜5 回の反復でほぼ正確なドラフトを生成し、主に端数ケースの微調整を必要とします。
• サブシステムレベル: 複雑なモジュール（例：完全な HTTP クライアント、プロトコルスタック）は、LLM の支援が生産的になる前に、人間による大幅なアーキテクチャ指導を必要とします。LLM は実装の詳細を加速しますが、高レベルの設計を主導するわけではありません。

意義と主張

本論文は、stdlib 専用実装が、ユーティリティおよびインフラストラクチャライブラリの大半にとって実用的な代替手段となり得ると主張しており、パフォーマンスや正しさのためにサードパーティ依存関係が必要であるという仮定に挑戦しています。

• 充足範囲: 調査対象モジュールの約 3 分の 2 が、パフォーマンスの同等性またはそれ以上の性能を達成しています。主な制限は Python 自体のオーバーヘッドではなく、画像処理、バイナリシリアライゼーション、ハードウェア加速された暗号など、計算集約型タスクにおけるサードパーティ製ライブラリの C/Rust 拡張への依存です。
• アーキテクチャ上のオーバーヘッド: 本研究は、参照ライブラリにおける「肥大化」（抽象化レイヤー、プラグインシステムなど）が、ターゲットとした stdlib 再実装によって排除可能なパフォーマンスペナルティを課していることを浮き彫りにしています。
• LLM の役割: LLM 支援開発は、制約された単一ファイルの生成には効果的ですが、複雑なサブシステムには人間の監督が必要です。参照ライブラリを「オラクル」として使用することは、反復的な改善にとって決定的に重要です。
• 実用的含意: 依存関係管理にコストがかかる環境（制約されたデプロイ、サプライチェーンセキュリティなど）において、zerodep は、ネイティブコードの加速を必要としない作業負荷であれば、正しさやパフォーマンスに意味のある損失を伴わずに、ゼロ依存性ソフトウェアへのキュレーションされベンチマークされた道筋を提供します。

著者らは、純粋な Python 実装が特定の分野における生スループットにおいてネイティブコードと競合することはできないものの、stdlib 専用制約、LLM 支援による反復、および（適用可能な場合の）サブプロセスによるオフローディングの組み合わせが、広範な実用的なエンジニアリングタスクにとってのギャップを十分に埋めると結論付けています。