ソフトウェアのバベルの塔

巨大で複雑な城を建設しているところを想像してみてください。現実の世界では、ある採石場からレンガを、別の場所からモルタルを、そしてまた別の場所からステンドグラスを用意する必要があるかもしれません。もしこれらのサプライヤーたちが同じ言語を話さず、異なる測定テープを使っていたら、あなたの城は完成する前に崩れてしまうかもしれません。これは、まさにデジタル世界のソフトウェアが直面している問題です。

コンピュータサイエンス、特にプログラミング言語とソフトウェア工学という分野において、開発者は多くの異なる「言語」（Python、Rust、OCamlなど）で書かれたコードを使用してアプリケーションを構築します。これらのプログラムを動作させるために、彼らはパッケージと呼ばれる、あらかじめ構築されたコードの断片に依存しています。パッケージを、あなたの城のための「プレハブの部屋」と考えてください。ツール、データベース、あるいはグラフィックスエンジンといったライブラリのことです。

しかし、あらゆるプログラミング言語には、独自の「パッケージマネージャー」が存在します。これは、部屋を見つけ出し、設置するためのデジタルな現場監督のようなものです。Pythonの現場監督（pipと呼ばれます）はRustの現場監督（Cargo）を理解できず、どちらもLinuxシステムの現場監督（APT）と会話することはできません。彼らはそれぞれ、どのように部屋を組み合わせるかについて異なるルールを持っています。もしあなたがPython、Rust、C言語を同時に使用するプロジェクトを構築しようとすれば、Pythonの部屋がRustの壁に適合せず、全体がどのように接続されているのかという完全な設計図が見えないため、構造全体がセキュリティリスクとなるような、混沌とした混乱状態に陥ってしまいます。

ソフトウェアの部屋のためのユニバーサル・トランスレーター

ケンブリッジ大学の研究者と業界パートナーによるこの論文**「Package Managers à la Carte（アラカルトのパッケージマネージャー）」は、この混沌に対する解決策を提案しています。彼らは、すべてのパッケージマネージャーに即座に全く同じ言語を話させることを目的としているわけではありません。その代わりに、彼らは「パッケージ計算（Package Calculus）」と呼ばれるユニバーサル・グラマー（普遍的な文法）**を発明しました。

パッケージ計算を、ソフトウェア依存関係のための「リンガ・フランカ（共通語）」、あるいはユニバーサル・トランスレーターと考えてください。著者たちは、パッケージマネージャー間の激しい違いにもかかわらず、それらすべてが極めて小さな、共通の核を共有していることに気づきました。その核心において、すべては以下の3つの単純なことを行います：

1. ルート包含（Root Inclusion）：構築しようとしているメインのプロジェクトを含めなければならない。
2. 依存関係の閉包（Dependency Closure）：ある部屋をインストールする場合、その部屋が自立するために必要な、より小さな部屋もすべてインストールしなければならない。
3. バージョンの唯一性（Version Uniqueness）：通常、同じ場所に同じ種類の部屋の異なるバージョンを2つ同時に設置することはできない。

研究者たちは、この小さな核が、古代のPerlアーカイブから現代のRustツールに至るまで、30種類以上の異なるパッケージマネージャーの挙動を記述するのに十分強力であることを証明しました。彼らは単に推測したのではなく、厳密な数学的モデルを構築し、さらにその論理が健全であることを証明するために、Lean 4というツールを用いたコンピュータプログラムを作成しました。

「アラカルト」な機能のメニュー

この論文の真の魔法は、その「違い」の扱い方にあります。著者たちは、複数のバージョンのライブラリを共存させたり、「ライブラリAまたはライブラリBのいずれかが必要」とパッケージに言わせたりするような、パッケージマネージャーをユニークにする複雑な機能は、単なるシンプルな核への「アドオン（追加機能）」に過ぎないことに気づきました。

彼らはこのアプローチを、メニューから注文する**「アラカルト（à la carte）」**と呼んでいます。基本的な核を注文し、そこに以下のような特定の拡張機能を加えることができます：

• 競合（Conflicts）：「このパッケージをあのパッケージと一緒にインストールすることは絶対にできない」
• 並行バージョン（Concurrent Versions）：「このライブラリの異なる2つのバージョンを並行して実行する必要がある」
• ピア依存関係（Peer Dependencies）：「直接は使用しないが、隣のパッケージが特定のバージョンのライブラリを持っている必要がある」
• フィーチャー（Features）：「『グラフィックス』オプションをオンにするなら、これらの追加ツールが必要である」

この論文は、これらすべての複雑な機能が、数学的にシンプルな核へと「還元」できることを示しています。それは、複雑なスフレのレシピが、混ぜる、熱を加える、折りたたむといった基本的なステップに分解できることを示すようなものです。あらゆるエコシステムのルールをこの共通の核へと翻訳することで、研究者たちは、複数の言語にまたがるプロジェクトにおいて、依存関係のパズルをようやく解くことができることを実証しています。

なぜこれが重要なのか：ポリグロット・リゾルバー

この論文で説明されている究極の目標は、**ポリグロット・リゾルバー（多言語対応の解決器）**です。現在、Python、Rust、Cを使用するプロジェクトを構築したい場合、それらが互いに壊さないことを願いながら、3つの別々のパッケージマネージャーを実行しなければなりません。著者たちは、将来的に、単一の「スーパー・リゾルバー」を持つことができるだろうと示唆しています。

その仕組みは以下の通りです：

1. プロジェクトのPython部分は、自身のニーズをパッケージ計算へと翻訳します。
2. Rust部分は同様に行います。
3. Cの部分も同様に行います。
4. スーパー・リゾルバーはこれらをすべて統合して一つの巨大で統一されたパズルとし、Pythonのライブラリ、Rustのライブラリ、およびCのドライバが、どのバージョンを使用すべきについて合意できるように解決します。

論文は、これが単に「素晴らしいアイデア」であるだけでなく、セキュリティと安定性のための「必要なステップ」であると主張しています。依存関係が異なるエコシステム間で隠されていたり、バージョン指定されていなかったりすると、セキュリティの脆弱性を追跡することが不可能になります。セマンティクス（意味論）を統一することで、ソフトウェアが依存しているすべてのコードの完全なマップである「依存関係グラフ」を見ることができるようになります。

著者たちは、これがすべてのパッケージマネージャーが明日消滅することを意味するのではない、という点にも注意を払っています。代わりに、この形式的なモデルは、エコシステム間を翻訳するためのツールを構築するための理論的基礎を提供するものです。彼らは、最適なバージョンのセットを見つける問題が数学的に困難（具体的には「NP完全」であり、プロジェクトが大きくなるにつれて指数関数的に難しくなること）であることを示しながらも、基礎となるルールを理解することで、この複雑さを乗り越えられることを示しています。

要するに、この論文は現在のシステムが壊れているという指摘にとどまらず、異なる世界からのソフトウェアが、バラバラにならずに共に構築できる新しい建設現場の設計図を提供しているのです。それは、孤立したツールの混沌とした集まりを、一貫性のある統一されたシステムへと変え、より安全で信頼性の高い、真にクロスランゲージなソフトウェアプロジェクトへの道を切り拓いています。