メモリ安全性絶対主義の陥穽 Rust Fil-C Zig

メモリ安全性をめぐるコミュニティの議論が新たな様相を見せている。Lobstersに投稿されたPiotr Sarnacki氏の論考「Memory Safety Absolutists」（itsallaboutthebit.com via ekuber, 2026年7月25日）は、Rust開発者を「絶対主義者」と決めつける風潮への反論と同時に、Fil-CやZigの開発者が示す「Rustは本当は安全でない」という主張の不誠実さを鋭く指摘する内容だ。

絶対主義の実態

「メモリ安全性絶対主義者」という言葉を聞いて、多くの技術者がまず思い浮かべるのはRust開発者の姿だろう。Sarnacki氏も認めるとおり、これは根拠のない偏見ではない。Rustコミュニティの一部が他言語を「安全でない」と批判することに熱心であることは確かにある。しかし、問題はその批判が本当に安全性向上を目的としているのか、それとも単なる言語間の優劣競争に過ぎないのかという点だ。

著者はRust開発者の多くが「ソフトウェアをより安全にすること」を本気で願っていると信じたいと述べつつ、近年は異なる立場からの批判が増えていることを問題視する。その批判の源泉こそ、Fil-CとZigの両プロジェクトだ。

Rustへの認識と誤解

従来のメモリ安全性に関する議論は、ガベージコレクション（GC）を持たないシステムプログラミング言語——C、C++、Zig、Rust等——の間で行われてきた。Rustは原則としてメモリ安全性に違反するプログラムのコンパイルを許可しない代わりに、unsafeブロックによる逃避手段を備える。一方、CやC++ではプログラマの責任が全てであり、Zigではdefer等の補助機能はあるが根本的には同じだ。

ここで重要なのは、Rustのunsafeが全ての安全性保証を無効にするわけではないということだ。unsafeは生ポインタのデリファレンスなど限定された操作のみを許可し、残りの安全性機構は有効なままである。しかし、一部の批評家は「unsafeが存在する限りRustは安全ではない」と主張する。

Fil-Cの登場

状況を一変させたのがFil-Cの出現だ。Fil-CはCおよびC++のコードをコンパイルし、無効なメモリアクセス（範囲外アクセスや使用後解放）に対してパニックを発生させる。その仕組みはGCとInvisiCaps（ポインタがアクセス可能なメモリを追跡する方式）を組み合わせたものだ。

Fil-Cの作者はTwitter上でRustへの嫌悪感をあからさまにしており、「Rustはunsafeを使えば安全性を回避できるから安全でない」と公然と発言している。Sarnacki氏はこの姿勢を「不誠実」と評する。

Zigの「真の安全」主張

さらに、Zigの作者であるAndrew Kelley氏はFil-Cに触発された新しいコンパイルモードの導入を発表した。問題のissueタイトルには「introduce an actually memory safe (unlike Rust) compilation mode inspired by Fil-C」とある。直訳すれば「（Rustとは異なり）実際にメモリ安全なコンパイルモードをFil-Cに触発されて導入する」という意味であり、Rustは安全でないという立場を明確に打ち出している。

Kelley氏は以前からRustのunsafeが安全神話を損なっていると批判してきたが、今回の発表でその姿勢がさらに明確になった。この動きに対して、Rustコミュニティだけでなく、中立的な観測者からも疑問の声が上がっている。

批判の不誠実さ

Sarnacki氏の論旨の核心は、Fil-CやZigの開発者がRustを「安全でない」とレッテル貼りする一方で、自らの解決策を無条件に「真に安全」と称賛する二重基準にある。もし本当にメモリ安全性が重要なら、どのプロジェクトも互いの成果を歓迎するはずだと同氏は指摘する。

現実には、Fil-CでコンパイルされたC/C++プログラムも、ランタイムでパニックを発生させる可能性があり、それは完全な安全性ではない。また、Zigのfilモードもまだ開発段階であり、実際の脆弱性をどの程度防げるかは未知数だ。一方でRustはunsafeを最小限に抑える設計思想と型システムの厳格さにより、既に実証済みの成果を多数挙げている。

例えば、当サイトでも報じたMesa Rusticlの事例（Mesa Rusticl、Mali Panfrostを標準で有効化）のように、Rustで書かれたドライバが増えるにつれ、メモリ安全性関連のバグが実際に減少している。絶対的な安全を求めるあまり、実用的な安全向上策を否定するのは生産的ではない。

編集部の見解

短期的には、Fil-CとZigの動きによりRustコミュニティと他言語コミュニティの間で「真の安全性」を巡る論争が激化する可能性がある。これは開発現場で言語選択の混乱を招く一方、C/C++プロジェクトがFil-Cを採用するきっかけになるかもしれない。しかし、ランタイムチェックの性能コストを考慮すると、全てのプロジェクトがFil-Cに移行するとは考えにくい。 長期的には、この議論は「メモリ安全性とは何か」という根本的な問いを再定義させるだろう。Rustの所有権モデルが証明可能な安全を提供するのに対し、Fil-Cは実行時検証による安全を提供する。両方のアプローチを組み合わせたハイブリッド手法が普及する可能性もあり、結果としてソフトウェア全体の安全性底上げにつながるかもしれない。 編集部としては、Rustを「安全でない」と断じる絶対主義的な主張は、安全性向上という目的を見失わせる危険があると見る。重要なのは言語の優劣ではなく、脆弱性を減らすための実用的な手段を多様に提供することだ。絶対安全が存在しないことを認めた上で、どの手法がどの文脈で最も効果的か、冷静な評価が求められる。

参考

• 「Memory Safety Absolutists」, by itsallaboutthebit.com via ekuber — Lobsters, 2026-07-25T21:38:29.000Z (ARR)
• 元記事URL: https://itsallaboutthebit.com/memory-safety-absolutists/