State of Namespace──Namespace機能の設計と現在地

はじめに

こんにちは、さくらのナレッジ編集部です。2025年4月に愛媛県松山市で開催されたRubyKaigi 2025。その中でも注目を集めたセッションの一つ、さくらインターネット 田籠さんによるState of Namespaceについてレポートします。Namespaceとは、Rubyに対して田籠さんが提案している機能です。言語仕様としてはまだ提案段階ながら、その実装と検証の過程で得られた知見の数々が、今回の発表で共有されました。

Namespaceとは何か

Namespaceは、アプリケーションやライブラリを隔離された空間に閉じ込め、その空間内で行われた変更を他の空間に影響させないようにするための仕組みです。これにより、同一プロセス内でも複数バージョンのライブラリを安全に共存させることが可能になります。

現在のRubyでは、すべてのClassやModuleはプロセス全体で共有されており、異なるバージョンのライブラリを同時に使用すると、定義が衝突して意図しない動作を引き起こす可能性があります。Namespaceの導入により、これを防ぐことができます。

Namespaceの設計では、空間ごとにClassやModuleの定義を分離し、それぞれの空間内で独立して動作させます。さらに、Namespace内で定義されたメソッドや定数は、そのNamespaceに属するコードからのみ見えるようになり、外部には影響を与えません。

Namespaceの設計思想として、次のような機能的特徴が示されています。

• アプリケーションやライブラリをNamespace内に隔離して読み込む
• Namespace内で行われた変更を他に影響させない
• 同じメソッド名・定数名でもNamespaceが異なれば衝突しない
• Namespace内で定義されたメソッドは、その定義とともに実行される

このようにNamespaceは、Rubyにおけるコードの安全な分離と、ライブラリの共存を実現するための基盤的機能として提案されています。

実装と設計の背景

田籠さんはセッションの中で、「実は去年の発表以降、仕様は1ミリも変わってないんですよ」と語り、笑いを誘いました。ではこの1年何をしていたかというと、「ひたすらデバッグしてました」と率直に告白しています。make test-all がSEGV（セグメンテーション違反）で落ちる、テストが途中で止まるなど、数々の問題に直面したそうです。

「ASAN（AddressSanitizer）を使って、どこでSEGVしてるかを調べて、printfを100個以上埋め込んで、ようやく原因を突き止めた」と、愚直な手法で一つ一つ潰していった過程を語る様子には、粘り強いエンジニアリングの姿勢がにじみ出ていました。

Namespaceの実装にあたっては、Rubyのクラス構造であるRClassとrb_classext_tにNamespace対応のフィールドを追加し、Namespaceごとに異なるクラス拡張情報（classext）を保持する構造に改めました。当初はshallow copyによる実装が行われていたものの、const_tblのリソース共有によりGC（ガーベジコレクション）でSEGVが発生するなどの問題があり、のちにdeep copyへと変更されました。

autoload機能についても、Namespaceの境界をまたぐことでautoload entryの消費や再評価に不整合が発生し、NameErrorを引き起こす問題が見つかりました。これに対しても、autoload_tableをNamespaceごとにdeep copyして分離することで対応がなされました。

さらに、C拡張（.soファイル）をNamespaceごとに安全に読み込むために、dlopen() が同一ファイルを複数回読み込まない仕様を回避するため、.so ファイルをリネーム・コピーして a_cgi+escape.so のようにNamespace単位で別名化する工夫がなされました。

その他、method cacheのオーナー整合性（Bug #20767）や、callcc実行時のstack pop異常（Bug #20655）、prism parserの-O0オプションによるstack overflowなど、言語レベルでの深い不具合も次々に発見されました。

こうした設計や実装の試行錯誤の中で、Namespace機能の安定化とRuby本体への統合に向けた基盤整備が着実に進められています。

技術的課題と今後の展望

現在のNamespace実装は、スレッドやスタックベースの制御に依存しており、これが一部の不具合や実装上の制約につながっています。今後は、より安定的かつ予測可能な挙動を実現するため、control frame（cref）ベースでの管理への移行が検討されています。

また、Namespaceに関連するクラス拡張情報（classext）を不要になった段階で適切に破棄するための、Namespace対応のGC（ガーベジコレクション）機構の整備も重要な課題です。一時的に生成された.soファイルを適切なタイミングで削除するための仕組みや、Namespaceごとに異なる .rb ファイルや拡張ライブラリを識別し、ロード管理する仕組みも求められます。

さらに、method cacheの挙動やsubclass構造の再設計、「Implicit Refinements」との整合性の精査など、言語機能との密接な統合も含めて検討が必要です。これらの技術的課題をクリアすることで、Namespace機能の正式なリリースに向けた道が開けると見込まれています。

結論と見通し

Namespace機能は現在も進行中であり、Ruby 3.5またはRuby 4.0でのマージに向けて継続的に開発が進められています。その過程では、autoloadの扱いや.soファイルの読み込み、GC対応、デバッグ性の向上など、周辺の幅広い改善も並行して行われています。

こうした取り組みは、Ruby本体の柔軟性や保守性を保ちつつ、より複雑な利用ケースにも対応できるようにするための設計上の進化といえます。また、Namespace機能の導入によって既存のコードベースとの整合性を保ちながら新しい構造を取り入れるには、開発ブランチを長期にわたって維持することなく、できるだけ早い段階でのマージが望ましいとされています。

なお、Matz氏の発言によれば「Ruby 4.0が今年中に出るかも」との見通しもあり、Namespace機能はその中でも注目される柱のひとつとなる可能性があります。

最後に

発表の締めくくりには、「長く開発ブランチを維持するのはつらい。だからこそ、早くNamespaceを完成させたい」という本音もこぼれました。今後、NamespaceがRubyに正式に採用されることで、より安全で拡張性の高いアプリケーション開発が可能になるでしょう。本機能は既にRubyにマージされており、問題がなければ次バージョンのRubyとしてリリースされる予定です。その日を楽しみに、私たちも引き続き議論を見守っていきたいと思います。