Rust言説を解体する

Wed, Jul 9 2025 11:13:07
Last updated on August 30, 2026

キム・ホドン <hodong@nimfsoft.com>

はじめに

本書は、プログラミング言語 Rust の技術的特性と、その周囲に形成された特定の技術的・社会的言説をあわせて分析します。ここでいう解体とは、ある技術や主張をあらかじめ否定する作業ではありません。技術的事実、言語が提供する保証、工学的コスト、因果関係についての解釈、価値判断、修辞的表現を互いに分離し、それぞれの根拠と適用範囲を検討することを意味します。本書では、Rust が安全性・性能・並行性を実現するために選択した設計と、それらの選択に伴うコストおよび制約を、歴史的・技術的文脈の中で考察します。

本書は、次の問いを中心に議論を進めます。

Safe Rust はどのような種類のメモリエラーとデータ競合を防止し、その保証は unsafe、外部関数インターフェース（FFI）、論理エラー、運用障害に直面したとき、どこまで有効なのか。
Rust の所有権、借用、ライフタイム、型システム、ゼロコスト抽象化は、C++、ガベージコレクタ（GC）¹ を利用する言語、Ada、SPARK のアプローチと比較したとき、どのような利点とトレードオフを持つのか。
企業およびオープンソースプロジェクトの導入事例と定量的成果は、Rust 自体の効果をどの範囲まで立証し、アーキテクチャ、アルゴリズム、ランタイム、ハードウェア、組織変化の効果とどのように区別できるのか。
既存システムのリファクタリング、段階的な近代化、危険な構成要素の選択的置換、全面的な書き直しは、どのような条件のもとで区別し、組み合わせるべきか。
条件付きの技術的利点が、あらゆるシステムに当てはまる普遍的優越性や、開発者の知性・資格に関する判断へ変換されるとき、どのような論理の飛躍が生じるのか。
特定の言語が「唯一の代替案」であるという主張は、どのような要件と候補集合を前提とし、その前提と比較過程が省略されたとき、どのような論理的誤謬が生じるのか。

これらの問いに答えるため、本書は言語仕様と標準、公式プロジェクト文書、政府報告書、CVE 記録、企業の原技術報告、査読研究などの一次資料を優先します。定量的主張を検討するときは、調査対象と標本、分子と分母、基準線、ワークロード、ハードウェア・ソフトウェア環境、比較期間を確認します。観測結果、統計的推定、因果的帰属、著者の解釈を区別し、成功事例と失敗事例に可能な限り同じ証拠基準を適用します。資料が特定の組織やシステムだけを扱う場合は、その範囲を越えて一般化せず、不確実性と代替的説明をあわせて示します。

比較対象には C++、Java、C#、Go、Ada、SPARK が含まれます。この比較は、ある言語を別の言語の単純な代替として順位付けするためのものではなく、異なる言語とエコシステムが、性能、メモリ制御、開発生産性、検証可能性、リアルタイム性、ツール、長期保守性の間でどのようなコストを選択しているかを考察するためのものです。Ada と SPARK は、GC に依存せず安全性と信頼性を確保してきた別の歴史的アプローチを示す比較対象です。また、言語の特性と変更戦略を分離し、既存システムの維持か廃棄かという二者択一ではなく、リファクタリング、近代化、部分置換、書き直しを独立した工学的手段として評価します。

本書におけるRust言説は、Rust Foundation、コア開発チーム、またはコミュニティ全体の公式見解を意味しません。Rust プロジェクトの公式チャネルは、コンパイル時間、非同期プログラミング、ツール、安全境界などの課題を公開の場で議論し、改善してきました。本書が分析するのは、一部の公開技術フォーラムやソーシャルメディアで繰り返し観察される特定の論証パターンです。これらのオンライン事例は、その主張がコミュニティ全体でどの程度頻繁に現れるかを証明する統計標本ではなく、主張の構造とその言説的機能を分析するための定性的資料として用います。

Rust は、GC を用いずに強いメモリ安全性保証と高度な制御を組み合わせ、実際の産業およびオープンソースプロジェクトで重要な成果を挙げた言語です。本書は、その成果を過小評価したり、特定の技術選択を推奨したりするために書かれたものではありません。目的は、利点と限界、保証とコスト、観測と解釈を同じ基準で検討することにあります。したがって本書の結論も最終宣言ではなく、現在確認できる証拠に基づく判断であり、より優れた資料や反例が提示されれば修正される可能性があります。

この作品はクリエイティブ・コモンズ表示－非営利－改変禁止 4.0 国際ライセンスの下に提供されています。

はじめに
第1部：Rustの登場と技術的特性
- 1. Rust言語の紹介と主要な特性
- 2. Rust採用の要因：技術、エコシステム、物語の相互作用
第2部：主要設計原則の技術的分析
- 3. 「安全性」物語の多角的分析
- 4. 所有権モデルの再評価と設計思想
第3部：エコシステムの現実と構造的コスト
第4部：技術コミュニティの言説分析
- 8. 「銀の弾丸の物語」と集団的防御機制の形成
第5部：総合分析と結論
- 9. Rust の再評価：効用、制約、技術選択戦略
- 10. 結論：エコシステムの持続可能性に向けた課題と展望
  - 10.1 エコシステムの構造的改善に向けた課題
  - 10.2 総合：技術、変更戦略、能力、測定、組織環境をともに扱う思考枠組み
エピローグ
付録：技術討論で観察される論証上の誤謬の事例分析

第1部：Rustの登場と技術的特性

第1部では、プログラミング言語 Rust がシステムプログラミング分野の課題にどのように取り組み、どのような特性を通じて論じられてきたかを分析します。

第1章では、Rust 誕生の背景となった性能と安全性のトレードオフを考察し、それに対応するため導入された所有権モデル、ゼロコスト抽象化（ZCA）の哲学、Cargo に代表されるエコシステムなど、主要な技術的特性を紹介します。

第2章では、こうした技術的基盤が開発者体験（DX）、物語、組織的支援と相互作用し、採用に影響を与えた複合的要因を分析します。

1. Rust言語の紹介と主要な特性

本章では、Rust の特性を単に列挙するのではなく、メモリ安全性の保証範囲と設計上の利点・トレードオフを分析するための二つの問題を検討します。第一に、Rust がシステムプログラミングで解決しようとした欠陥とコストは何か。第二に、所有権・借用・ライフタイム・型システム・ゼロコスト抽象化が提供する保証はどこまで及び、どのようなトレードオフを伴うのか、という問題です。

そのために、言語の設計目標、仕様上の保証、コンパイラとライブラリの実装、実際のワークロードで観測される結果を区別します。所有権と借用、ゼロコスト抽象化、型とパターンマッチ、Cargo エコシステムを順に検討しますが、特定の設計目標をあらゆるプログラムの性能や安全性に関する普遍的な結果へ拡張しません。産業導入の成果と変更戦略は、後の章で別の証拠基準に基づいて扱います。

1.1 誕生の背景：性能と安全性のトレードオフ

システムプログラミングでは、ハードウェア制御、予測可能な資源管理、スループットとレイテンシ、メモリ安全性、並行性エラーの防止が同時に要求される場合があります。しかし、これを単純に「性能か安全性か」という二者択一で表すと、歴史的な選択肢を過度に縮小してしまいます。C と C++ は低水準制御と手動の資源管理を中心に発展し、Ada と SPARK は強い型付けと実行時検査に契約と形式検証を組み合わせ、GC ベースの言語は自動メモリ回収と管理実行環境を使用します。どの方式が適切かは、欠陥モデル、リアルタイム性、ワークロード、運用環境、検証要件によって異なります。

Rust は Mozilla Research で始まり、メモリ安全性、並行性、低水準制御、性能を同時に追求するシステムプログラミング言語へ発展しました。² 「GC なしでメモリ安全性を提供し、C++ と競争可能な性能を目指す」という説明は、設計目標と価値提案です。すべての Rust プログラムがすべての C++ プログラムと同じ性能を示すことや、実行時コストと失敗が消えることを普遍的に保証するものではありません。したがって、以下の三つの目標も、設計目標、言語上の保証、実装特性、観測結果を区別して読む必要があります。

安全性

Safe Rust は、所有権、借用、型規則を通じて、特定の不正なメモリアクセスとデータ競合を防ぎます。この保証は、コンパイラとライブラリ、unsafe で実装された抽象化、FFI 境界がそれぞれの契約を守ることを前提に成立します。³ panic、デッドロック、資源の漏洩や枯渇、論理エラー、あらゆるセキュリティ脆弱性、サービス継続性まで自動的に保証するものではありません。正確な保証境界は 1.2 節と 3.2 節で具体的に検討します。

性能

Rust は必須のガベージコレクタなしでネイティブコードを生成し、高水準の抽象化が回避可能な追加の実行時オーバーヘッドを要求しないよう設計するゼロコスト抽象化の原則を採用しています。⁴ この原則は、あらゆる抽象化が常に同じ速度で動作することや、コンパイル時間、バイナリサイズ、メモリ使用量、デバッグの難しさ、開発者の認知コストがゼロであることを意味しません。実際の性能は、ワークロード、アルゴリズム、最適化、割り当て、入出力、ライブラリ、ハードウェア条件を明示して測定する必要があります。

並行性

Safe Rust の所有権と型システムはデータ競合を防ぎますが、一般的な競合状態、デッドロック、スターベーション、優先度逆転、分散システムの一貫性問題まで除去するものではありません。⁵ したがって「恐れのない並行性」は、すべての並行性欠陥が存在しないという意味ではなく、特定のメモリ安全性違反とデータ競合をコンパイル段階で防ぐ、範囲の定まった表現として理解すべきです。

本章の重要な出発点は、Rust が安全性、性能、並行性を一つの設計の中で同時に追求することと、その目標があらゆる環境での観測結果を意味するわけではないことを区別する点にあります。次節以降では、所有権と借用が提供する具体的な保証、拒否される有効なプログラム、実行時検査と実装依存性、他の設計とのトレードオフを順に検討します。

1.2 所有権、借用、ライフタイムによるメモリ管理

本節では、所有権を一つの標語として扱うのではなく、三つの層に分けて検討します。所有権は値と資源を後始末する責任を示し、借用は所有権を移さずにアクセス権限を制限し、ライフタイムは参照が指す値より長く使用されないよう関係を記述します。三つの層は相互に関連しますが、同じ概念ではありません。⁶

1. 所有権：値と資源を後始末する責任

Rust では各値に所有者があり、代入や関数呼び出しによって所有権が移動する場合があります。移動後の値を元の変数から再び使用しようとすると、コンパイル時に拒否されます。ただし、整数のように Copy を実装した値は代入時に複製されるため、元の変数も引き続き使用できます。したがって、「すべての代入は移動である」という説明は正確ではありません。

所有者が有効範囲を外れると、値は Drop に従って後始末されます。ヒープ割り当てを所有する型はこの時点で割り当てを解放でき、ファイル、ソケット、ロックなどの資源も型の破棄処理に結び付けられます。この規則は Safe Rust で二重解放や解放後使用を防ぐ基盤ですが、あらゆる終了経路でデストラクタが必ず実行されるという意味ではありません。プロセスの強制終了や abort、意図的なリーク、参照カウントの循環などでは、資源が直ちに回収されない場合があります。

2. 借用：所有権とは異なるアクセス権限

参照は対象を所有しません。共有参照 &T は有効な間、読み取りアクセスを提供し、可変参照 &mut T はその期間の排他的アクセスを表します。一般には「複数の共有参照、または一つの可変参照」と要約されますが、重要なのは、参照が実際に使用されている間にエイリアスと変更が同時に生じないよう制限することです。⁶

この規則は Safe Rust で、同期されていない同時読み取り・書き込みによるデータ競合を防ぎます。しかし、実行順序によって結果が変わる一般的な競合状態、デッドロック、スターベーション、優先度逆転まで除去するものではありません。また、UnsafeCell に基づく内部可変性、raw ポインタ、unsafe コードでは、安全な外部インターフェースが維持すべき別の不変条件が必要です。

3. ライフタイム：参照の有効性を表す関係

ライフタイムは、値がいつ破棄されるかを直接制御する実行時の仕組みではなく、参照同士が満たすべき有効期間の関係を表す静的契約です。ライフタイム注釈が参照をより長く生存させるわけではありません。関数が受け取る参照と返す参照の関係などを記述し、コンパイラが検査できるようにするだけです。⁶

現在の借用チェッカーは非字句的ライフタイム（NLL）を使用し、単純なブロック末尾ではなく参照の最終使用地点を考慮します。それでも静的解析は、停止するすべてのプログラムの意味を完全には判定できないため保守的にならざるを得ず、実行時には安全な一部のプログラムを拒否します。Rust プロジェクトが 2026 年に Polonius alpha の安定化を目標とした理由の一つも、条件付き借用や lending iterator など、現在の解析では表現できない有効なパターンをより多く受け入れるためです。⁷

4. Safe Rust の保証が成立する前提と境界

Safe Rust の中核的な保証は、安全なコードだけでは未定義動作を引き起こせないという soundness の性質です。しかし、この保証はコンパイラ、標準ライブラリと外部ライブラリ、アロケータ、unsafe で実装された抽象、OS インターフェース、FFI コードがそれぞれの契約を守るという前提の上に成立します。unsafe は未定義動作を許可する印ではなく、コンパイラが確認できない義務を実装者が検証しなければならないことを示します。³

したがって所有権と借用は、ダングリング参照、不正なエイリアス、二重解放、データ競合の重要な部類を防ぎますが、メモリ不足、資源枯渇、panic、abort、論理エラー、デッドロック、外部コードの契約違反、コンパイラの欠陥まで除去するものではありません。FFI 境界の C コードが未定義動作を起こせば、その影響は Rust 部分を含むプログラム全体へ及ぶ可能性があります。

5. 基本規則の外にある所有パターンとコスト

現実のデータ構造は、単一所有権と静的借用だけでは表現しにくい場合があります。Rust はそのため、安全な抽象を保ちながら検査時点や同期方式を変更する型を提供します。⁸

Rc<T> は単一スレッド内で複数の所有者を表しますが、ヒープ割り当てと参照カウントの増減が必要であり、強参照の循環はメモリリークを起こし得ます。
RefCell<T> は内部可変性を提供し、借用規則をコンパイル時ではなく実行時に検査します。規則違反では未定義動作の代わりに panic が発生しますが、状態追跡と分岐のコストが加わります。
Arc<T> はスレッド間共有のためにアトミックな参照カウントを使用します。そのアトミック操作のコストにより、スレッド安全性が不要な場合は Rc<T> より不利になり得ます。
Mutex<T> はロックを取得したコードだけに内部値への可変アクセスを許します。型と RAII はロック解放を構造化しますが、ロック取得と競合のコスト、デッドロックの可能性は残ります。

これらの型は所有権規則を取り除くものではありません。静的検査では表現しにくいパターンを安全な API の背後にカプセル化する一方、実行時検査、ヒープ割り当て、参照カウント、アトミック操作、ロックというコストと新しい失敗条件を選択するものです。

中間結論

メモリ安全性保証の境界を見ると、所有権、借用、ライフタイムは sound な Safe Rust の境界内で、特定のダングリング参照、二重解放、解放後使用、不正なエイリアス、データ競合を強く防ぎます。しかし、この保証は unsafe 実装と外部境界の契約に依存し、あらゆるバグや運用障害を含むものではありません。

設計上の利点とコストを見ると、この設計は実行時ガベージコレクタなしで強い静的保証を提供する代わりに、所有関係を型とインターフェースに表す必要があり、一部の有効なプログラムを拒否する場合があります。共有所有権や内部可変性を選ぶと、静的なコストが消えるのではなく、参照カウント、実行時検査、アトミック操作、ロックのコストへ移動します。したがって Rust のメモリ管理モデルは、「コストのない安全性」ではなく、特定のエラーを静的に防ぎ、必要に応じて代替コストを型として明示的に選ばせる設計と評価する方が正確です。

1.3 ゼロコスト抽象化の系譜

ゼロコスト抽象化は、プログラムのあらゆるコストがゼロであるという事実命題ではなく、言語とライブラリを設計するための原則です。使用しない機能のために時間や空間のコストを負担せず、使用する抽象は、合理的に手作業で記述した低水準実装と競争できるよう設計するという意味です。この原則は C++ の zero-overhead principle として体系的に表現され、Rust はメモリ安全性と低水準制御を同時に追求する設計軸として受け継ぎました。⁹

C の struct、マクロ、inline、sizeof のようにコンパイル段階に関与したり低水準制御を提供したりする機能は、この歴史に影響を与えました。しかし、あらゆるコンパイル時技法をゼロコスト抽象化の初期形態と呼ぶと、概念の範囲が広がりすぎます。本節では、低水準の実装技法、言語レベルの抽象化原則、特定のコンパイラが生成した観測結果を区別します。

1. 静的ディスパッチと単相化

使用されるジェネリック関数と静的にディスパッチされるトレイトは、具体型ごとに単相化（monomorphization）されます。この方式は呼び出し先をコンパイル時に確定し、直接呼び出しやインライン化などの最適化機会を与えます。最適化器が具体型と演算を同時に確認できるため、抽象化の境界が最終的な機械語から消える場合もあります。⁹

ただし、単相化は「常に同じ機械語を生成する」、あるいは「手書きコードより常に速い」という保証ではありません。生成結果は rustc と LLVM のバージョン、最適化レベル、クレート境界、LTO、コード生成単位、対象 CPU と有効な機能、周辺コードによって変わり得ます。同じソースでも、開発用ビルドとリリース用ビルドでは大きく異なる最適化結果になる可能性があります。¹⁰

2. 動的ディスパッチ、割り当て、実行時検査

Rust のすべての抽象が静的に除去されるわけではありません。dyn Trait はデータポインタと仮想メソッドテーブル（vtable）を使い、実行時に呼び出し先を選択します。これには間接呼び出しのコストがあり、一般にインライン化の機会を減らす一方、具体型ごとのコード複製を避けてコードサイズを小さくできる場合があります。¹¹

動的ディスパッチとヒープ割り当ても同じ概念ではありません。&dyn Trait は既存の値を借用できるため、それ自体はヒープ割り当てを要求しませんが、Box<dyn Trait> は Box によるヒープ所有表現を選択します。Vec と String の割り当て・再割り当て、Box のヒープ所有は、選択したデータ構造の動作であり、「抽象」と呼ぶだけで消えるものではありません。配列とスライスの安全なインデックス参照も、範囲外では panic するという意味を持ちます。範囲検査が除去されるかどうかは最適化の結果であって、言語の普遍的保証ではありません。¹¹

3. 実行時コストを減らす代わりに生じ得るコスト

単相化は具体型ごとに機械語を生成するため、実行性能やインライン化に有利な場合がありますが、コンパイル時間とバイナリサイズを増加させる可能性があります。コードサイズが大きくなると命令キャッシュへの圧力が高まる可能性もありますが、実際の影響は呼び出し頻度、コード配置、対象プロセッサ、ワークロードによって異なります。反対に、動的ディスパッチは間接呼び出しを残す一方で、コード重複を減らせます。¹⁰

ビルド設定にもトレードオフがあります。高い最適化レベルと LTO はより多くの最適化機会を与える代わりに、コンパイル時間とリンク時間を増やし得ます。また、最適化されたコードはソース順序や実行状態が再配置されるため、デバッグが難しくなる場合があります。コード生成単位を増やすと並列コンパイルは速くなる一方、生成コードの性能が低下する可能性があります。保守性についても、抽象によって減ったコード重複と、ジェネリック API、エラー診断、ビルド追跡の複雑さを併せて評価する必要があります。したがって、コンパイル時間、バイナリサイズ、命令キャッシュ、デバッグ、保守コストは、実行時スループットとは別の評価項目です。¹⁰

4. イテレータ例が保証する範囲

// 1 から 99 までのうち、3 の倍数を二乗した値の合計を求めるコード
let sum = (1..100).filter(|&x| x % 3 == 0).map(|x| x * x).sum::<u32>();

このコードは filter、map、sum を組み合わせ、計算を宣言的に表現します。最適化ビルドでは、アダプタの呼び出しがインライン化され、中間状態が除去されて、一つのループに近いコードが生成される場合があります。しかし、この例だけから、すべてのイテレータ連鎖が手書きループと同じ性能や機械語を持つとは結論できません。Rust 公式書籍の比較も、一つの検索ワークロードでループとイテレータが似た結果を示したという観測であり、多様な入力と条件にわたる包括的な同等性証明ではありません。¹²

5. 性能主張を比較するための条件

ゼロコスト抽象化に関する性能比較では、少なくとも次の条件を明示する必要があります。

rustc、Cargo、主要クレートのバージョン
ターゲットトリプル、CPU、有効化された命令セット機能、OS
開発用・リリース用・独自プロファイル、最適化レベル、LTO、コード生成単位、panic 戦略
入力データ、ワークロード、反復回数、ウォームアップ、測定方法
比較基準となるループや別実装のアルゴリズム、割り当て、入出力条件
レイテンシとスループットに加え、コンパイル時間、バイナリサイズ、メモリ使用量

これらの条件が異なれば、同じ構文上の抽象でも異なる結果が生じ得ます。したがって、一つのベンチマークで観測された優位性を、言語全体やすべての抽象の固定的な性質として一般化してはなりません。

中間結論

設計上の利点とコストを見ると、静的ディスパッチと単相化は、高水準インターフェースを直接呼び出しと最適化が可能な具体コードへ変換する強力な手段です。しかし、ゼロコスト抽象化の原則は、すべての抽象が同じ機械語や性能を生成するという仕様上の保証ではありません。動的ディスパッチ、ヒープ割り当て、範囲検査、ライブラリの実行時動作は、選択した表現とデータ構造に応じて残ります。

Rust はコストをなくすというより、どこでどのコストを支払うかを選択できる設計に近いものです。実行時の間接呼び出しを避ければ、単相化によるコンパイル時間とコードサイズのコストを負う可能性があり、コード重複を減らせば動的ディスパッチのコストを選択する場合があります。したがって、ゼロコスト抽象化は標語ではなく、具体的なワークロード、ビルド条件、生成コード、ライフサイクル全体のコストを併せて比較して評価すべきです。

1.4 型システムとパターンマッチによる安全性の確保

Rust の静的型システムは、値の表現と、その値に許される操作を制限します。データが取り得る状態を型に記録し、その型と整合しない操作をコンパイル時に拒否できるということです。ただし、型検査器が保証するのは型に表現された条件です。業務規則、外部環境、実行結果のすべてが自動的に正しくなるわけではありません。

1. Option と Result：状態を明示的に表現する範囲

Rust の列挙型は、各バリアントが異なるデータを持てる直和型です。Option<T> は値の有無を Some(T) と None で、Result<T, E> は成功と失敗を Ok(T) と Err(E) で表します。API がこれらの型を使えば、呼び出し側は不在や失敗の可能性を型から確認し、その経路を伝播させるか分岐して処理できます。¹³

この利点を「Rust には null も例外も存在しない」という普遍的主張へ拡張してはなりません。安全な参照 &T と &mut T、および Box<T> は有効な値への非ヌルポインタを前提としますが、生ポインタはヌルになり得ます。FFI や OS インターフェースは、ヌルポインタ、エラーコード、外部言語の例外を渡す場合があります。Option はそのような境界を自動的に浄化する仕組みではなく、検証済みの不在可能性を Rust の型として表す手段です。¹³

未使用の Result には #[must_use] が適用されますが、これは既定では lint です。lint レベルを下げたり、let _ = で明示的に捨てたりできるため、コンパイラがすべてのエラーに意味のある回復方針を強制するわけではありません。? 演算子も、通常はエラーを処理するのではなく現在の関数の呼び出し側へ伝播させます。記録、再試行、代替値の使用、中断のどれを選ぶかは、依然として API とアプリケーションの設計課題です。¹³

2. パターンマッチと網羅性検査が保証すること

match は、対象型について現在構築可能な値を、すべてのアームが合わせて覆っているかを検査します。次のコードから None アームを削除するとコンパイルできません。

fn describe(value: Option<i32>) -> &'static str {
    match value {
        Some(number) if number > 0 => "正数",
        Some(_) => "0 または負数",
        None => "値なし",
    }
}

この保証にも境界があります。¹⁴

ワイルドカードアーム _ は残りのすべての値を覆うため網羅性検査を通過しますが、どのバリアントを意図的に処理したかは示しません。API に新しいバリアントが追加されても、既存のワイルドカードが静かに吸収する場合があります。
パターンガードは条件が偽になり得るため、そのパターンに一致するすべての値を処理した証拠にはなりません。上の例で Some(number) if number > 0 の後に別の Some アームが必要なのはこのためです。
if let、let ... else、while let、matches! は関心のある一部のパターンだけを扱うための道具であり、すべての場合の処理を要求しません。
他クレートの #[non_exhaustive] 列挙型は、将来のバリアントに備えてワイルドカードアームを要求します。これは API の進化を容易にする一方、現在の全バリアントを列挙し、新しい状態の追加をコンパイルエラーとして検出する能力を弱めます。

したがって網羅性検査が保証するのは、「現在の型定義と記述されたパターンを基準に、抜けた場合がないか」です。各アームの動作が正しいこと、ワイルドカードが新しい状態を適切に処理すること、外部状態が型定義と一致することまでは証明しません。

3. 不正な状態は、不変条件が型に入っている場合にだけ遮断される

列挙型、newtype、非公開フィールド、検証済みコンストラクタを使えば、特定の不正な状態を表現しにくくできます。たとえば、範囲を検証した識別子や状態遷移を別型にすれば、安全な公開 API を使うコードが検証を迂回できないよう設計できます。

しかし、開始時刻が終了時刻より前であること、複数フィールド間の整合性、ファイルの実在、権限方針、ネットワーク応答の信頼性は、型名だけでは生まれません。これらの条件をコンストラクタとメソッドの不変条件として実装し、フィールドの公開範囲と変換経路を制御する必要があります。構造上は型に合っていても、業務上の意味が誤った値は作れます。

この境界は unsafe、FFI、デシリアライズ、外部入力で特に重要です。不正な列挙型の判別値や無効な参照を Rust の値として扱うと、未定義動作になり得ます。外部バイト列、C 構造体、データベース行、ネットワークメッセージは、Rust 型として扱う前に、長さ、範囲、エンコーディング、判別値、フィールド間関係を検証しなければなりません。型システムの保証は、有効な型付き値が構築された後から適用され、境界でその前提を作る責任までは代替しません。¹⁵

4. 実行時失敗と制御フローのコスト

Option と Result が失敗を値として表しても、実行時失敗がなくなるわけではありません。unwrap と expect は予期しないバリアントで panic し、ビルドの panic 戦略に応じてスタックを巻き戻すか、プロセスを中断します。unwrap_unchecked は検査をなくす代わりに、誤ったバリアントで未定義動作を引き起こします。¹⁶

状態で分岐するコードは実際の制御フローを作ります。コンパイラは単純な match を条件分岐、ジャンプテーブル、条件付き移動、分岐のないコードへ変換できますが、具体的な結果はバリアント数、データ配置、最適化レベル、対象 CPU、周辺コードに依存します。パターンマッチやコンビネータの使用自体が無コストだという保証はありません。頻繁に実行される経路では分岐予測とエラー値生成のコストを測定する必要があり、大きなエラーバリアントを列挙型内に直接置くか、Box などで間接化するかも、表現サイズと割り当てコストの選択です。

5. 表現方式、API の進化、保守コスト

既定の repr(Rust) 列挙型について、正確なフィールド順序、判別値の配置、全体サイズは一般に固定 ABI ではありません。Option<&T> のように公式文書がヌルポインタ最適化を保証する特定型は例外ですが、一例のサイズ最適化をすべての Option<T>、Result<T, E>、ユーザー定義列挙型へ一般化することはできません。FFI や保存形式で配置に依存する場合は、適切な repr と別個の互換性設計が必要です。¹⁶

状態を細かく型へ分ければ、抜けをコンパイルエラーとして発見し、コードレビューとテストの対象を明確にできます。一方、バリアントやエラー型が増えるほど、match アーム、変換コード、文書、テストも増え、汎用的なエラー階層や長いコンビネータ連鎖はデバッグ経路を複雑にする場合があります。公開列挙型への新バリアント追加は下流コードの網羅的マッチを壊す可能性があり、#[non_exhaustive] とワイルドカードは互換性を高める代わりに、新状態を自動検出する能力を弱めます。型の精密さ、API の安定性、診断の明瞭さ、保守コストを一緒に設計する必要があります。

中間結論

メモリ安全性保証の境界を広げて見ると、Option、Result、網羅的パターンマッチは、不在・失敗・状態分岐を型で表したコードにおいて、重要な抜けをコンパイル時に遮断します。しかし、生ポインタと FFI のヌル、panic、無視されたエラー、ワイルドカードに吸収された新バリアント、誤った業務規則、外部入力までは除去しません。不正な状態が遮断される範囲は、不変条件が型と安全な API にどれだけ正確に表現され、すべての境界で保持されるかに依存します。

設計上の利点とコストを見ると、状態を型で細分化する方法は、実行時の暗黙的失敗を明示的なインターフェースとコンパイラ診断へ移す強い手段です。その代わり、API 設計、分岐と表現サイズ、エラー変換、互換性、デバッグ、保守のコストを負う可能性があります。したがって型システムとパターンマッチの価値は「すべてのエラーを除去すること」ではなく、どのエラー状態を表現し、どの境界で検証するかを明示的に選べることにあります。

1.5 エコシステム：Cargo と Crates.io

プログラミング言語の利用体験は、構文と型システムだけで決まるものではありません。プロジェクトを作成し、依存関係を選択し、ビルド・テスト・デプロイし、長期にわたって更新するためのツールとエコシステムも、開発コストと失敗可能性に影響します。Rust では Cargo が公式のパッケージマネージャ兼ビルドツールであり、crates.io が既定の公開パッケージレジストリです。本節では、この二つを 言語レベルの安全性保証とは区別されるツール・エコシステム層 として分析します。

1. Cargo が標準化する作業フローとその範囲

Cargo は Cargo.toml を中心にパッケージのメタデータと依存関係を宣言し、cargo new、cargo build、cargo check、cargo test、cargo doc、cargo package、cargo publish などの共通の入口を提供します。rustc を直接呼び出してプロジェクト固有のシェルコマンドと組み合わせる代わりに、一つのツールが依存関係の取得とコンパイル順序、標準的なディレクトリ構造、ビルドプロファイルを調整します。これは開発環境間の差を減らし、自動化・CI・文書化について共通の慣行を作りやすくする利点があります。¹⁷

しかし、共通の作業フロー、言語が保証するプログラムの性質、そして どの環境でも同一の成果物を生成する再現可能ビルド は別の概念です。Cargo が同じ依存関係バージョンを選択しても、最終結果は rustc と Cargo のバージョン、ターゲットトリプル、ビルドプロファイルとフラグ、環境変数、ビルドスクリプト、手続きマクロ、ネイティブライブラリ、外部ツールの影響を受ける可能性があります。したがって、cargo build という共通コマンドが存在するという事実だけでは、メモリ安全性、機能的正しさ、ビット単位の再現性を保証できません。

2. 依存関係解決、Cargo.lock、feature の統合、SemVer と MSRV

Cargo の resolver は各パッケージが宣言したバージョン要件を満たす依存関係グラフを計算し、ロックファイルを使用する場合はその結果を Cargo.lock に記録します。ロックファイルが存在すると Cargo は記録されたバージョンを優先し、依存関係の選択を安定させます。--locked はロックファイルを変更する必要が生じた場合をエラーにし、--frozen はこれにオフライン動作を組み合わせます。ただし --offline ではローカルにすでに存在するパッケージしか利用できないため、オンライン時とは異なる依存関係解決結果になる場合があります。つまりロックファイルは依存関係選択の決定性を大きく高めますが、ネットワークやキャッシュの状態、ビルド環境全体を固定するものではありません。¹⁸

また、ロックファイルの効果はパッケージの役割によって異なります。最終アプリケーションでは検証済みの依存関係の集合を固定するのに有用ですが、ライブラリを別のプロジェクトが利用する場合、その利用側の Cargo.toml とグラフ全体を基準に依存関係解決が再度行われます。Cargo の公式 FAQ も、ライブラリの Cargo.lock が利用側の依存関係選択を支配しないことを注意事項として示しています。¹⁸

resolver は可能な場合には同じパッケージバージョンを再利用しますが、バージョン要件が競合すると、同じ crate の複数バージョンが一つのグラフに共存することがあります。これは重複コンパイルとコードサイズを増やし、異なるバージョンで定義された同名の型が、実行時の型識別や公開 API の境界で互換にならない問題を生じさせる可能性があります。cargo tree -d はこのような重複バージョンの検出に利用できます。¹⁸

feature も単純な独立スイッチではありません。複数のパッケージが一つの依存関係を共有する場合、既定では有効化された feature の和集合が使われます。resolver version 2 では、ターゲット固有依存関係、ビルド依存関係と手続きマクロ、開発依存関係に関する一部のケースで不要な feature 統合を減らします。したがって、どのワークスペースメンバーを同時にビルドするか、どのターゲットと feature を選ぶかによって、実際のコンパイルグラフとコストが変わることがあります。¹⁸

Cargo は SemVer 互換性を前提としてバージョンを選択しますが、公式の互換性ガイドライン自体も、すべてのプロジェクトに強制される規則ではないと説明しています。構文上互換な変更であっても実行結果に影響する場合があります。rust-version はパッケージが対応する最小 Rust バージョン（MSRV）を表現し、resolver がバージョン選択で考慮できるようにしますが、これは省略可能なメタデータであり、--ignore-rust-version で無視することもできます。したがって SemVer と MSRV は更新リスクを管理するための契約とツールであり、新しいバージョンが常に互換で回帰がないことの証明ではありません。¹⁸

3. ビルド中に実行されるコードとネイティブ・ターゲット依存関係

Cargo の依存関係は、Rust ソースファイルを rustc に渡すだけで終わるとは限りません。パッケージの build.rs はそのパッケージのビルド直前に実行され、C ライブラリをコンパイルしたり、システムライブラリを探索したり、ソースコードを生成したり、プラットフォーム固有の設定を行ったりできます。Cargo の文書は、ビルドスクリプトが実行中に任意の処理を行えると説明しています。¹⁹

手続きマクロ（proc macro）もコンパイル時に実際のコードとして実行されます。Rust Reference によれば、手続きマクロはファイルアクセスなどコンパイラが持つ資源を利用でき、Cargo のビルドスクリプトと同種のセキュリティ上の考慮事項を持ちます。したがって、信頼していない依存関係のビルドスクリプトと手続きマクロは ビルド時コード実行の境界 として扱う必要があります。Safe Rust の構文で書かれたアプリケーションコードのメモリ安全性保証と、ビルド中に実行される第三者コードへの信頼は、同じ層の性質ではありません。¹⁹

ネイティブ依存関係も別の環境上の前提を生みます。ビルドスクリプトは links メタデータとリンカ指示によって C/C++ ライブラリなどへ接続でき、ターゲット固有依存関係は OS やアーキテクチャによって変わることがあります。クロスコンパイルではビルド依存関係がホスト上で実行される一方、最終 crate は別のターゲット向けにコンパイルされることがあります。そのため、同じ Cargo.lock を使っていても、ホストツール、リンカ、システムライブラリ、ターゲット SDK が異なれば、ビルド結果やビルドの成否が変わる可能性があります。¹⁹

したがって、長期保存や高い保証が必要なビルドでは、ロックファイルだけでなく、ツールチェインのバージョン、ターゲット、プロファイルとフラグ、ネイティブツールとライブラリ、必要な環境変数、ビルド時コードの実行条件も記録して管理する必要があります。

4. crates.io が提供する完全性・配布機能とサプライチェーン保証の境界

crates.io は Cargo の既定の公開レジストリとして、パッケージの検索と配布に共通の経路を提供します。レジストリインデックスには公開された .crate ファイルの SHA-256 チェックサムが記録され、Cargo はダウンロードしたデータがそのチェックサムと一致するかを検証します。これは転送やキャッシュを経て取得した、選択済みパッケージのバイト列がレジストリのメタデータと一致することを確認する重要な完全性機構です。²⁰

公開済みバージョンの管理も安定性を考慮しています。crates.io は公開バージョンを恒久的に保持することを目標としており、問題のあるバージョンは削除ではなく yank できます。yank されたバージョンは新しい依存関係解決では通常選ばれませんが、既存の Cargo.lock にすでに記録されていれば引き続き利用できます。所有者は新しいバージョンの公開と既存バージョンの yank に関する権限を管理でき、公開メタデータにはライセンス表現またはライセンスファイルが必要で、標準ライセンスは SPDX 式で記録できます。²⁰

これらの機能をサプライチェーン全体のセキュリティ保証へ拡張して解釈すべきではありません。チェックサムが検証するのは レジストリに登録されたパッケージのバイト列が同一であること であり、そのコードが安全に設計されているか、公開リポジトリの特定コミットやどのレビュー手続きと対応しているか、メンテナが長期にわたって保守するかまで証明するものではありません。ライセンスメタデータがあっても、推移的依存関係全体のライセンスがプロジェクトの方針や法的要件に適合するかは別途確認が必要です。yank も、ロックファイルにすでに含まれるバージョンを自動的に除去したり修正したりするものではありません。

したがって、crates.io のアクセス性と集中型配布経路、パッケージチェックサム、所有権、yank 機能はいずれも有用ですが、発見可能性・配布の完全性・権限管理 と コードの来歴検証・セキュリティ・保守品質・長期サポート は異なる評価項目です。

5. ネットワーク・キャッシュ・vendoring・監査・更新のライフサイクルコスト

Cargo はレジストリ依存関係と Git 依存関係を取得し、$CARGO_HOME などにキャッシュします。キャッシュは反復ビルドのネットワークと処理コストを減らしますが、新しい環境や空のキャッシュでは再びネットワークアクセスとダウンロードが必要です。cargo fetch で依存関係を事前取得し、その後 --offline または --frozen を利用できます。また cargo vendor は crates.io と Git 依存関係のソースを、プロジェクトが管理するローカルディレクトリへコピーできます。しかし vendoring は外部依存関係をなくすのではなく、保存・同期・更新の責任をプロジェクト内部へ移す 選択です。²¹

依存関係グラフが大きくなるほど、ダウンロードするデータ量とキャッシュ領域、コンパイル作業、重複バージョンと有効 feature、ビルドスクリプト・手続きマクロの実行範囲、ライセンス・脆弱性・保守状態を確認する対象も増える可能性があります。Cargo の文書も、ビルド依存関係を追加する際にはコンパイル時間、ライセンス、保守への影響を考慮するよう勧めています。特にホストとターゲットが異なるクロスビルドでは、同じ依存関係が異なる役割のために再コンパイルされることがあります。¹⁹

cargo update はロックファイルで選択されたバージョンを意図的に更新します。したがって更新は、単に新しいバージョン番号を取得する作業ではなく、変更履歴、テスト、SemVer の前提、MSRV、セキュリティ勧告、ロールバック可能性を合わせて確認する保守作業です。RustSec の cargo audit は Cargo.lock を既知のセキュリティ勧告データベースと照合しますが、未報告の脆弱性や設計上の欠陥が存在しないことを証明するものではありません。監査の自動化はサプライチェーンレビューを支援する手段であり、レビューそのものを不要にする保証ではありません。²¹

C と C++ のエコシステムとの比較でも、基準を対称にする必要があります。「C/C++ にはパッケージマネージャや標準化されたビルド慣行がない」と表現するのは不正確です。CMake や Meson のようなビルドシステム、vcpkg や Conan のような C/C++ パッケージマネージャ、OS ごとのパッケージマネージャを利用できます。違いはツールの存在そのものより、Rust が Cargo と crates.io を公式ワークフローの中心に置き、プロジェクト作成から依存関係解決・ビルド・テスト・公開まで強い共通の既定経路を提供している点にあります。一方で、C/C++ のより多様なツール選択は統合コストを増やす可能性がある反面、既存のビルド体系、システムパッケージ、バイナリパッケージング、組織固有のリポジトリ方針に適合する選択肢を提供することもあります。²¹

中間結論

Cargo と crates.io は Rust の重要な工学的利点です。共通の manifest とコマンド体系、依存関係 resolver とロックファイル、チェックサムを備えた既定レジストリは、プロジェクト構成と依存関係の選択を明示的にし、自動化しやすくします。特に検証済みの Cargo.lock と固定したビルド条件を合わせて管理すれば、時間や開発環境が変わっても同じ依存関係の集合を再利用しやすくなります。

しかし、この利点は言語レベルの安全性保証と同じものではありません。ロックファイルはビルド環境全体や第三者コードの信頼性を固定せず、チェックサムはコード品質を審査せず、SemVer・MSRV・yank・セキュリティ勧告は保守判断を代行しません。小さな依存関係を容易に組み合わせられる利便性は、推移的依存関係、ビルド時コード実行、ネットワークとキャッシュ、コンパイル時間、ライセンス・脆弱性監査、更新、長期サポートのコストも伴う可能性があります。

したがって、大規模・長期運用・高保証環境では、「Cargo を使っている」あるいは「crates.io のエコシステムが大きい」という事実だけでツール体系の優劣を判断するのではなく、実際の推移的依存関係グラフと有効 feature・ターゲット、ビルドスクリプトと手続きマクロ、ネイティブ依存関係、オフライン復旧と vendoring の戦略、監査・更新・ロールバック手順を合わせて評価する必要があります。Cargo はこの作業を一貫して行うための強い基盤を提供しますが、サプライチェーンとライフサイクルに関する責任そのものを取り除くものではありません。

1.6 結論：保証の境界と設計コスト

本章の第一の問いは、Rust がシステムプログラミングにおいてどのような欠陥とコストを減らそうとしたのか、というものでした。前節までの分析で確認した要点は、Safe Rust が所有権・借用・型規則によって、ダングリング参照、解放後使用、二重解放、不正なエイリアシング、データ競合の重要な種類をコンパイル段階で強く阻止し、Option・Result と網羅的パターンマッチが不在・失敗・状態分岐を明示的な型と制御フローへ移せることです。Cargo と crates.io も、プロジェクト構成、依存関係解決、ビルド・テスト・公開を共通ワークフローとして整理するツール上の利点を提供します。ただし、この三つの層の性質と保証は同じではありません。

第二の問いは、これらの設計がどこまで保証し、どのようなトレードオフを伴うのか、というものでした。Safe Rust のメモリ安全性は、コンパイラとライブラリ、unsafe で実装された抽象化、FFI 境界がそれぞれの契約を守るという前提の上に成り立ち、panic、一般的な競合状態、デッドロック、メモリや資源のリークと枯渇、論理エラー、サービス継続性まで保証するものではありません。型で状態を明示する方式も、不変条件が型と安全な API に実際に表現され、外部入力や FFI などの境界でその前提が検証される場合にのみ、該当する種類のエラーを阻止します。また、状態を細かく型で表すほど、API の進化・互換性、エラー変換、デバッグ、保守のコストも伴います。したがって、メモリ安全性や型レベルの保証をシステム全体の正確性・可用性・信頼性と同一視してはなりません。

性能の面でも、ゼロコスト抽象化は普遍的な速度保証ではなく、回避可能なランタイムオーバーヘッドを減らそうとする設計原則です。静的ディスパッチと単相化はランタイム呼び出しコストを減らし、最適化の機会を生み出せる一方、コンパイル時間、コードサイズ、デバッグコストを増やす場合があります。動的ディスパッチ、ヒープ割り当て、境界検査、ライブラリのランタイム動作は、選択した表現によって残ることがあります。したがって、スループットとレイテンシだけでなく、コンパイル時間、バイナリサイズ、メモリ使用量、デバッグ、保守コストまで、実際のワークロードとビルド条件で合わせて評価する必要があります。

ツールとエコシステムにも同じ境界が当てはまります。Cargo の共通ワークフロー、Cargo.lock、crates.io のチェックサムと配布機能は依存関係の選択と自動化を構造化しますが、ビルド環境全体の再現性や第三者コードの品質・セキュリティ・長期保守を代わりに保証するものではありません。大規模・長期運用環境では、toolchain の固定と更新、ビルドスクリプトと手続きマクロ、ネイティブ依存関係、ネットワーク・キャッシュとオフライン復旧、サプライチェーン・ライセンス・脆弱性監査、更新とロールバック、既存コードやビルド体系との統合・移行コストも合わせて管理する必要があります。C と C++ にも実際のビルド・パッケージ管理ツールが存在するため、比較の中心はツールの有無ではなく、共通の既定経路の統合度と既存資産に合わせられる選択肢の幅とのトレードオフです。

したがって Rust は、ランタイム GC を置くことが難しい、または望ましくない一方で低水準の制御が必要であり、メモリ寿命・エイリアシング・状態の見落としに関する一部のエラーをできるだけ早い段階で阻止することが重要な環境では、有力な選択肢になり得ます。逆に、静的規則が拒否する有効なパターンを扱うために共有所有権・ランタイム検査・同期を頻繁に必要とする場合や、コンパイル時間・コードサイズ・FFI・ネイティブ依存関係・既存ツール・移行コストが支配的な環境では、トレードオフは変わります。これは、他のアプローチが常に優れているという意味でも、Rust が常に優れているという意味でもありません。

第1章の結論は、Rust の中核的な価値がコストをなくすことよりも、特定のエラーをコンパイル段階と明示的な型・インターフェースでより強く制御し、一部のコストと責任の置かれる場所を変えることにある、というものです。言語の保証、実装とランタイムの挙動、ツール・エコシステムの利便性、実際のプロジェクトで観測された結果を区別して初めて、この利点とコストを正確に評価できます。次章では、こうした条件付きの技術的利点とツール特性が実際の採用判断にどの程度寄与したのかを、別個の経験的・因果的問題として扱います。

2. Rust採用の要因：技術、エコシステム、物語の相互作用

言語が実際に使われたという観察と、なぜ採用されたのかという因果説明は区別する必要があります。特定の組織やプロジェクトが Rust を使用したという事実は、その条件で採用が可能だったことを示す事例ではありますが、言語そのものが意思決定の唯一の原因だったことや、同じ効果が他の組織でも再現されることを意味しません。また本書でいう「採用」は、試験的利用、新規コンポーネントへの導入、既存システムの部分置換、組織標準化など異なる範囲を含み得るため、各資料が実際に示す水準を超えて一般化しません。

本章では、Rust 採用について提示される説明を、技術的適合性、開発者体験とツール、組織・エコシステムの条件、物語と大衆認識に分けて検討します。これらの要因は互いに影響し得ますが、一つの要因が存在するだけで別の要因の効果や採用全体の原因が証明されるわけではありません。そのため、技術的利点、ツールの利便性、組織的支援、言説の効果をそれぞれ別個の証拠問題として扱います。

2.1 技術的背景：メモリ安全性と性能の目標

Rust 採用の技術的説明でしばしば提示される主張は、Rust がランタイムのガベージコレクタ（GC）なしにメモリ安全性を強化しつつ、低水準の制御と高い実行性能を同時に目標とすることで、システムソフトウェアに新たな選択肢を提供した、というものです。Rust の公式文書は、所有権規則をコンパイラが検査し、このモデルが Safe Rust の範囲で GC なしにメモリ安全性の保証を提供するよう設計されていると説明しています。借用規則は同時に存在する可変参照を制限することで、データ競合をコンパイル時に防ぐことに寄与し、Rust Reference はデータ競合、寿命が尽きたポインタや適切にアラインされていないポインタを介したアクセス、無効な型の値の生成などを未定義動作に分類しています。²²

ここでは、設計目標と観測された性能結果を区別する必要があります。所有権規則そのものが別個のランタイム GC を必要としないという事実は、すべての Rust プログラムが C や C++ のプログラムより高速、または同等の性能になることを保証しません。1.3 節で検討したように、実際の性能はアルゴリズム、割り当て、境界検査、ディスパッチ、ライブラリとコンパイラの実装、対象ハードウェア、ワークロードによって変わります。

とりわけ現代の C++ を単に「安全機構のない手動メモリ管理言語」と表現するのは不正確です。RAII、スマートポインタ、コンテナ、span など、資源と寿命をより安全に管理するための言語・ライブラリ上の慣行があり、C++ Core Guidelines も生の所有ポインタや直接の new/delete を避け、資源ハンドルによる自動管理を推奨しています。ただし、こうした慣行や解析ツールの適用は、Safe Rust で所有権・借用規則をコンパイラが既定で検査する方式とは、保証が置かれる位置が異なります。²³

GC ベース言語全体を一つの性能特性で一般化すべきではありません。たとえば Oracle の HotSpot GC 文書は、ガベージコレクションの主要な性能指標としてスループットとレイテンシを区別し、コレクタと設定によって停止時間・スループット・メモリ使用量のトレードオフが異なると説明しています。したがって、「GC には停止があるためシステムソフトウェアには不適切だ」と一般化するのは過度です。実際の適合性は、コレクタとランタイム、ヒープサイズと生存オブジェクト、ワークロード、レイテンシ要件、メモリ制約、対象環境によって異なります。²⁴

この比較における Rust の技術的な差異は、「GC がないから自動的に速い」という命題ではなく、メモリの寿命とエイリアシング関係の相当部分を所有権・借用規則で静的に検査し、別個のランタイム GC なしにメモリ安全性を強化するという設計選択にあります。ランタイムコレクタを置くことが難しい、または望ましくない環境や、低水準の制御と明示的な資源寿命管理が重要な環境では、この特性が強い採用理由になり得ます。反対に、Safe Rust もすべての論理エラー、一般的な競合状態、メモリリーク、資源枯渇を除去するわけではなく、unsafe と FFI を含む境界では追加の健全性上の義務が残ります。²²

中間結論

メモリ安全性とランタイムコストを合わせて考慮する Rust の設計は、特定のシステムソフトウェアで実質的な技術的適合性を提供し得ます。しかし、その適合性が実際の採用判断にどの程度寄与したかは別の経験的問題です。組織の意思決定記録、調査、移行報告、比較資料がなければ、技術的利点の存在だけから採用の唯一の原因や平均的効果を確定することはできません。したがって本節は、Rust が採用され得る技術的理由と適用条件を整理し、採用全体の原因に関する結論は、後に続くツール・エコシステム・物語の分析と合わせて判断します。

2.2 開発者体験（DX）：Cargo とツールチェーン

Rust の採用を説明する際、Cargo を中心とする一貫したツール体験はしばしば利点として挙げられます。しかし、この主張には異なる二つの層があります。一つは Cargo や rustup などが実際にどの作業フローを共通化するかという機能上の事実であり、もう一つは、その共通化が開発者の生産性・オンボーディング・組織の採用判断にどの程度寄与するかという経験的・因果的主張です。前者は公式文書で確認できますが、後者には別途、測定と比較が必要です。

Cargo は Rust の公式パッケージマネージャ兼ビルドツールであり、manifest と共通コマンド体系を通じて、異なる Cargo プロジェクトでもビルド・検査・テスト・文書生成などの入口を標準化します。rustup はコンパイラと関連ツールの toolchain を管理し、既定のインストールプロファイルには rustfmt と Clippy が含まれます。rust-analyzer もインストール可能な公式 component であり、プロジェクトは rust-toolchain.toml に toolchain の channel・component・target を記録できます。²⁵ この共通の既定経路は、プロジェクトごとに異なるコマンドやツール選択を学び直すコストを減らす可能性があります。ただし、公式の機能文書そのものはオンボーディング時間や開発生産性がどれだけ改善するかを測定していないため、ツールが統合されているという事実と、開発者の生産性が高いという結論を同一視してはなりません。

実際の利用資料も両面を示しています。Rust プロジェクトの 2025 年コンパイラ性能調査には 3,700 人以上が回答し、約 60% が型検査・ビルド・テストに Cargo の端末コマンドを使用すると答えました。これは、その調査の回答者の実際の作業フローで Cargo が中心的な位置を占めることを示す直接資料です。

しかし同じ調査で、ビルド時間の問題が最も大きいプロジェクトを選んで回答した人のうち 55% は、小さな変更後の再ビルドに 10 秒を超えて待つと答え、Rust の利用を中止したと答えた人の約 45% は、長いコンパイル時間を中止理由の一つに挙げました。2025 State of Rust Survey も、遅いコンパイルとストレージ使用量を生産性を制約する問題として引き続き報告し、調査チームは約 7 千人の回答を利用者全体へ過度に一般化すべきではないと明記しています。²⁶

したがって、これらの資料は Cargo 中心の作業フローの実利用とそのコストを示しますが、Cargo が他のエコシステムより平均生産性を高めたことや、Rust 採用の原因だったことを立証するものではありません。

C と C++ のエコシステムを「ビルド・パッケージ管理ツールのない環境」と対比するのも不正確です。CMake は構成・ビルド・インストール、テスト・パッケージング用のツールと Presets を提供し、Meson はビルドやテストなど共通の開発作業を統合します。vcpkg は manifest で依存関係とバージョン制約を直接宣言でき、Conan は複数のビルドシステム・プラットフォームにまたがって C/C++ の依存関係とバイナリパッケージを管理します。²⁷ 違いはツールの存在の有無よりも、既定経路の統合度と選択構造にあります。Rust エコシステムでは Cargo と Rust プロジェクトが配布する複数のツールが強い共通慣行を形成する一方、C/C++ では組織・プラットフォーム・既存資産に応じて複数の組み合わせを選ぶ場合が多くあります。前者は共通規約による調整コストの削減に有利な可能性があり、後者は既存のビルド・バイナリ配布・社内リポジトリ方針に合わせる選択の幅を提供できます。したがって、どちらの構造も常に総コストが低いと断定することはできません。

統合された既定ツールチェーンも、組織レベルの統合コストをなくすわけではありません。rustup target add はクロスコンパイル対象の Rust 標準ライブラリをインストールしますが、外部 linker や SDK まですべて提供するわけではなく、Rust の公式インストール文書も通常のビルドには linker が必要で、一部の crate は C コードを含むため C コンパイラを必要とする場合があると説明しています。²⁸ 既存の monorepo、社内 build farm、private registry、セキュリティ・ライセンス検査、パッケージング・デプロイ体系を持つ組織では、Cargo をそれらの体系へ接続するか、並行して運用する必要がある場合があります。大規模・長期運用環境では、共通コマンドの利便性だけでなく、toolchain の固定と更新、CI cache とビルド時間、ネイティブ依存関係、オフライン復旧、セキュリティ監査、移行と rollback のコストまで含めて評価する必要があります。依存関係・vendoring・サプライチェーンの境界自体は、前の 1.5 節で扱った分析に従います。

中間結論

Cargo、rustup、rustfmt、Clippy、rust-analyzer へとつながる公式ツール経路は、Rust の明確な工学的利点の一つです。共通 manifest とコマンド体系、toolchain 管理と Rust プロジェクトが提供する公式ツールの統合は、プロジェクト間の作業フローを予測しやすくする可能性があり、調査資料は Cargo が多くの回答者の実際の開発フローで広く使われていることを示しています。しかし、広く使われている、生産性を高める、採用を引き起こしたという三つの命題は別物です。生産性や採用効果を主張するには、プロジェクト規模・チーム経験・既存ツール・ビルド環境・同時変更を統制した比較資料や、組織の意思決定記録が追加で必要です。したがって本節で確認できるのは、統合されたツール体験という技術的特性とその適用条件であり、Cargo が Rust 採用の普遍的原因だという結論ではありません。

2.3 物語の構築と「アジェンダ設定」の分析

この節で 物語（narrative） とは、ある技術が解決しようとする問題と、それを選択する理由を理解できるよう、問題設定・価値提案・比較基準を一定の構造で提示する説明の仕方を指します。この用語は、単一の中央主体がメッセージを統制していることや、意図的な操作が行われたことを前提としません。アジェンダ設定（agenda-setting） は、より狭い意味で用います。McCombs と Shaw の 1972 年の研究は、メディアがどの争点をどの程度強調したかと、有権者がどの争点を重要と認識したかの関係を、特定の選挙・地域・標本・期間の中で比較しました。したがって、ある主題が公式文書やオンライン議論で繰り返されるという事実だけでは、開発者集団が何を重要とみなすかが変化したというアジェンダ設定効果を確定できません。²⁹

Rust プロジェクトの公式資料からは、どの価値が伝えられたかを直接確認できます。2015 年の Rust 1.0 Alpha 発表は、言語の焦点を安全性・性能・並行性として説明し、公式の書籍は、所有権と型検査を用いて多くの並行性エラーをコンパイル段階で扱うアプローチを「fearless concurrency」と呼んでいます。2018 年の rust-lang.org 改訂に関する記事は、従来のトップページがゼロコスト抽象化、メモリ安全性、データ競合のないスレッドなどの機能を列挙していた構成を見直し、新しいサイトでは「Why Rust?」を前面に置くとともにスローガンも修正したと説明しています。本書のこの改訂時点の公式トップページは、Performance、Reliability、Productivity を主要な価値項目として提示しています。³⁰

これらの資料から直接確認できるのは、Rust プロジェクトが安全性、性能、並行性、生産性、ツール体験を公式の価値提案として示してきたこと、そしてその提示方法を意識的に調整してきたことまでです。そこから直ちに「Rust コミュニティ全体が同じ物語を共有していた」「Rust 言説がシステムプログラミングの評価アジェンダを変えた」「これらのメッセージによって開発者や組織が Rust を採用した」と結論づけることはできません。公式プロジェクトのメッセージ、非公式なコミュニティ言説、受け手が何を重要とみなすかという認識、実際の採用判断は、それぞれ異なる観察単位です。

とりわけ「Rust 言説によってメモリ安全性がシステムプログラミングの中心的な評価基準になった」という命題は、公式資料にメモリ安全性が繰り返し現れるという事実よりも強い主張です。これを経験的に検証するには、分析対象となる文書・投稿の母集団または標本、採用・除外基準、期間、比較対象、主題ごとの強調度を測る方法、そして受け手がどの基準を重要視したかを示す資料が必要です。そのような設計がなければ、この節で述べられるのは、Rust の公式コミュニケーションがメモリ安全性と関連する価値を継続的に前面に示してきたことと、それが関心や解釈の枠組みを提供した可能性までです。コミュニティ全体におけるアジェンダ設定効果やその大きさは確認されていません。²⁹

非公式なオンライン言説にも同じ証拠基準を適用する必要があります。一部の投稿や繰り返される表現は、ある論証構造が存在することを示す質的な事例にはなり得ますが、それが一般的または支配的だという結論には、定義された母集団、標本抽出方法、期間が必要です。また、「Rust を学ぶことで特定の問題を理解する助けになる」という教育上の主張と、「Rust の利用者だからより知的である、あるいはより資格がある」という人に対する地位判断は、論理的な層が異なります。後者の表現が実際にどの程度存在し、どのような機能を持つかは、選択された事例だけから一般化せず、第 8.5 節と第 9.2 節で別の言説資料とともに検討します。

物語が実際の採用に与えた影響も、別個の因果問題です。公式メッセージが特定の利点を目立たせ、比較基準を提供した可能性はありますが、それが開発者の学習・選好や組織の採用判断をどの程度変化させたかを判断するには、露出・認識・意思決定を結びつける調査、実験、縦断データ、組織の意思決定記録などの直接的な証拠が必要です。組織や企業による支援が信頼や採用に与えた影響は、この問題とは混同せず、次の第 2.4 節で別に扱います。

中間結論

Rust プロジェクトが安全性、性能、並行性、生産性、ツール体験を重要な価値として公式に提示し、ウェブサイトや文書でその伝え方を調整してきたことは、文書から確認できます。しかし、公式な価値提案の存在、非公式言説での反復、受け手が感じる重要度の変化、実際の採用に対する因果効果は、それぞれ別の命題です。したがって、この節は Rust の 公式コミュニケーションと物語構築の存在 は確認しますが、定義された言説標本と受け手側の資料なしに、コミュニティ全体のアジェンダ設定や採用効果を確定しません。

2.4 組織的支援とコミュニティ文化

機関や企業が Rust を支援したという事実と、その支援が信頼・正当性・採用を高めたという効果の主張は区別する必要があります。Rust Core Team は 2020 年、Rust が Mozilla Research のプロジェクトとして始まり、2015 年の Rust 1.0 以降はプロジェクトの方向性とガバナンスが Mozilla 組織から独立した一方、Mozilla は引き続き主要な財政・法務上の支援者であったと説明しました。2021 年の Rust Foundation 発足時には AWS、Huawei、Google、Microsoft、Mozilla が創設メンバーとして参加し、財団理事会はこれらのメンバー企業側の理事 5 名と Rust プロジェクト側の理事 5 名で構成されました。³¹

この歴史では、Rust Foundation による制度的支援と Rust プロジェクトの技術的意思決定も同一視してはなりません。財団設立の議論で Rust Core Team は、財団が法務・財政とメンテナ支援の基盤を提供する一方、多くの Rust チームの業務範囲と意思決定権限は変わらないと説明しました。本書の改訂時点でも Rust プロジェクトの公式ガバナンスには Leadership Council と複数の top-level team が別途存在します。したがって、財団メンバー企業の参加は、その企業が言語やコンパイラの技術的決定を直接統制することを意味しません。一方、法人主体、財政支援、インフラ、メンテナ支援体制の存在はプロジェクトの運営条件を説明しますが、それが外部組織の信頼や採用判断をどの程度変えたかは別個の経験的問題です。³¹

財団の発足発表は、創設企業による長期的な財政的コミットメントを、Rust が企業環境で production-ready な技術として定着したことを示すシグナルと解釈しました。しかし、これは財団自身による公式な解釈であり、外部組織の認識や採用効果を独立に測定した資料ではありません。企業の支援が信頼・正当性・採用に影響したと主張するには、意思決定記録で支援が実際の評価要素であったか、支援の前後で認識がどう変化したか、他の技術的・組織的要因をどのように統制したかを示す調査や比較資料が追加で必要です。³¹

コミュニティ文化についても、公式な規範と資源の存在と コミュニティ全体の実際の行動や結果を分ける必要があります。Rust の行動規範は、公式 Rust 空間で親切で安全かつ歓迎的な環境を目標とし、違反に対するモデレーションと制裁の手続きを定めています。Rust の公式学習ページは The Rust Programming Language を入門資料として提示し、Book 自体もインストール、Cargo の利用、所有権などを含む言語学習の経路を構成しています。³² これらの資料は Rust プロジェクトがどのような規範と学習資源を公式に提供しているかを示しますが、すべての相互作用がその規範を満たしていたことや、非公式な Rust コミュニティ全体でも同じ文化が観察されることの証拠ではありません。

同様に、行動規範や学習資料が存在するという事実だけでは、参入障壁が実際に下がった、学習時間が短縮した、新規参加者の定着率や多様性が高まった、と結論づけることはできません。そのような効果を評価するには、新規利用者や貢献者の経験、離脱・定着データ、学習時間と成功率、文書の利用状況を結びつけた調査や比較研究が必要です。大規模・長期運用の観点では、支援機関の数だけでなく、法的・財政的責任の持続性、特定の支援者への依存度、ガバナンスと技術的意思決定の分離、インフラやメンテナ支援が中断・変更された場合の対応能力も合わせて評価する必要があります。Rust プロジェクトが 2020 年の財団設立過程で、単一の支援者への依存を減らすためにインフラ支援の多様化を明示したことも、この区別に関係します。³¹

中間結論

Mozilla による長期的支援、独立した Rust Foundation の設立、企業とプロジェクトの代表がともに参加する財団構造、Rust プロジェクトの行動規範と公式学習資源は、いずれも文書で確認できる制度的・コミュニティ上の基盤です。しかし、支援体制の存在、公式規範と資源の存在、信頼・学習・コミュニティ行動の変化、実際の採用に対する因果効果は、それぞれ異なる命題です。したがってこの節は、Rust に制度的支援と公式なコミュニティ実践が存在することは確認しますが、直接的な結果資料なしに、それらが採用やコミュニティ上の結果の普遍的原因だとは確定しません。

2.5 採用要因の総合と第2章の結論

前節までで確認したのは、Rust の採用を説明する際に検討できる、互いに異なる要因です。第 2.1 節はメモリ安全性と低レベル制御を同時に必要とする一部の環境における技術的適合性を、第 2.2 節は Cargo と公式ツールチェーンが提供する共通のワークフローを、第 2.3 節は Rust プロジェクトが公式に提示してきた価値と物語の構成を、第 2.4 節は Mozilla の支援、Rust Foundation の制度的基盤、行動規範、学習資源を確認しました。しかし、これらの要素が同時に存在するという事実だけでは、それらが一つの因果連鎖を形成して Rust の採用を引き起こした、あるいは互いの効果を増幅したとは結論づけられません。

この区別は、本章でいう 採用の範囲 に応じてさらに重要になります。試験的利用、新規コンポーネントへの導入、既存システムの部分置換、チーム単位での利用、組織レベルでの標準化はそれぞれ異なる意思決定であり、同じ技術的特性やツールでも各範囲で異なる重みを持ち得ます。したがって、ある事例で Rust が使われたという事実は、その条件では採用が可能で実際に選択されたことを示しますが、どの要因が決定的だったのか、その効果が別の範囲や組織でも再現するのかまでは示しません。

第 2.1～2.4 節の証拠上の境界も維持する必要があります。技術的適合性は選択理由となり得ることを説明しますが、実際の意思決定への寄与度を測定したものではありません。また、Cargo 中心のワークフローが広く使われている程度と、生産性や採用に対する効果は別の命題です。公式な価値提案、制度的支援、行動規範、学習資源の存在も文書から確認できますが、受け手の認識変化、コミュニティ全体の行動、外部組織の信頼、実際の採用への効果には別の結果資料が必要です。本章の資料だけでは、これらの要因の相対的重要度に順位を付ける根拠もありません。

これらの要因が互いに 相互作用した という説明は、可能な仮説ではありますが、それ自体が観測結果ではありません。経験的に主張するには、技術評価、ツール体験、メッセージへの接触、制度的条件と実際の意思決定を結び付ける調査、意思決定記録、縦断データ、またはそれに相当する研究設計が必要です。さらに、既存のコードとインターフェース、チームの経験と人員構成、アーキテクチャと運用上の制約、セキュリティ・調達方針、日程と費用、同時に進められた再設計やプロセス変更といった代替説明も検討しなければなりません。こうした条件を統制しない成功事例や採用事例だけでは、言語、ツール、支援、物語それぞれの独立した効果を分離することは困難です。

第2章の結論

文書と資料から確認できるのは、Rust が一部のシステムソフトウェア環境に適合し得る技術的特性、統合された公式ツール経路、繰り返し提示されてきた公式な価値提案、そして制度的支援と公式なコミュニティ実践を備えているという点です。これらは、特定の組織や開発者が Rust を検討し選択する際に考慮し得る理由と条件を提供します。しかし、採用理由となり得る要素の存在、実際の意思決定への寄与度、複数要因の相互作用、他の組織へ一般化できる平均的な因果効果は、それぞれ異なる命題です。

したがって本章は、Rust の採用を単一の技術的優位性や単一の物語効果によって説明しません。ここまで確認した資料は、複数の候補要因と適用条件を特定するには十分ですが、どの要因がどの採用範囲でどの程度決定的だったのかを一般的に確定するには不十分です。以後の産業事例や比較分析でも、採用そのものを技術的優位性の証拠として用いるのではなく、各事例の意思決定記録、システム条件、同時に行われた変更、代替選択肢を分けて検討する必要があります。第2部では、この因果問題とは分けて、安全性・所有権など Rust の主要な設計原則そのものが提供する保証、コスト、歴史的関係を分析します。

第2部：主要設計原則の技術的分析

第1部では Rust の技術的特性と関連する物語を考察しました。第2部では Rust の主要設計原則である安全性と所有権を技術的に分析します。

これらの原則が「革新」と評価される背景、工学的トレードオフ、そして C++ や Ada などプログラミング言語の歴史的先例とどのように関係するかを多角的に検討します。さらに既存コードベースのリファクタリング、近代化、部分置換、全面的な書き直しを異なる変更戦略として区別し、言語レベルの保証とプロジェクトレベルの改善効果を同一視しない分析基準を確立します。

3. 「安全性」物語の多角的分析

本章で扱う「安全性（safety）」は、単一の属性として一括りにできるものではありません。Rust の言語保証、コンパイラやライブラリの実装、運用中の失敗モード、既存システムを変更する戦略、そして技術言説で使われる「安全性」という表現は、それぞれ異なる分析単位です。したがって本章は、「Rust は安全である」「既存言語は安全ではない」といった包括的命題を前提にせず、どの属性がどの条件で保証されるのかを分けて検討します。

まず第 3.1 節では、Rust の設計と先行する言語・技法の歴史的関係を検討しつつ、歴史的先例、概念的類似性、公式資料で確認できる直接的影響を区別します。第 3.2 節では Safe Rust の技術的保証と、unsafe、panic、メモリリーク、論理エラーなどの境界を分析します。第 3.3 節では C/C++ の段階的改善、部分置換、Rust による書き直しを異なる変更戦略として比較します。第 3.4～3.5 節では Ada/SPARK と GC ベース言語を共通の比較基準で検討し、第 3.6 節では技術的事実と分けて「安全性」が言説の中でどのように使われるかを扱います。最後に第 3.7 節で、これらの結果を設計上のトレードオフとして総合します。

この順序は、歴史的先例を現在の保証そのものと同一視すること、強い言語保証をプロジェクト移行の成功保証とみなすこと、ある言説表現の存在を技術的優位性の証拠とみなすことを避けるためのものです。

3.1 「革新」の意味と歴史的先例の分析

技術における「革新」は、必ずしも「先行する概念が何も存在しなかった」ことを意味しません。新しい組み合わせ、適用範囲、規則を強制する位置、使いやすさ、実装方式も革新の対象になり得ます。逆に、二つの技術が似ているという事実だけで、一方が他方から直接派生したと断定することもできません。本節では、Rust プロジェクトの一次資料が影響を明示している場合にのみ 直接的影響 と呼び、それ以外の関係は歴史的先例または概念的類似性に限定します。

C++ RAII と Rust の所有権：文書化された影響と異なる強制位置

Rust Reference は、C++ の references、RAII、smart pointers、move semantics を Rust 設計への影響として明記しています。Rust 公式 Book も、値の寿命が終わるときに drop で資源を解放するパターンが C++ では RAII と呼ばれると説明しています。C++ Core Guidelines は、資源をオブジェクトにカプセル化し、コンストラクタとデストラクタの寿命規則によって取得と解放を対にするとともに、資源解放の責任を持つオブジェクトを owner として扱うことを推奨しています。³³ したがって、C++ RAII と関連する資源管理技法が Rust に影響したという関係は、単なる外見上の類似ではなく、公式資料で確認できる歴史的なつながりです。

ただし、これは「資源所有という一般概念が C++ で初めて発明され、Rust がそのまま拡張した」という意味ではありません。Rust では決定的な資源解放に加え、所有権の move 後に元の binding の使用を制限する規則と、借用規則によって可変アクセスと共有アクセスの aliasing 関係を静的に制限する別の規則が組み合わされています。同じ Rust Reference は、ML Kit と Cyclone の region-based memory management も別の影響として列挙しています。³³ したがって、Rust のメモリ・寿命設計を単一の C++ 系譜だけに還元するのも不正確です。本節では関係の存在と規則が強制される位置の違いまでを確認し、Safe Rust が正確に何を保証するかは第 3.2 節で、RAII と Rust 所有権の詳細な比較は第 4.1 節で扱います。

Ada と SPARK：先行する高信頼性・検証の系譜だが、同一の所有権系譜ではない

Ada 1983 規格は Rust より前に存在し、Ada Reference Manual は元来の設計における主要な関心事として、プログラムの信頼性と保守性、人間によるプログラミング活動、効率性を挙げています。Ada の型・subtype 体系と、言語で定義された実行時検査は、一部のエラーを明示的な検査失敗として扱う伝統を形成しました。元来の SPARK 言語も Ada 83 を基盤としており、静的解析と verification condition を用いて、初期化、情報フロー、実行時エラーの不在、明示された contract などの属性を検証する別個の高信頼性の系譜を発展させました。³⁴ この意味で Ada/SPARK は、「安全性と効率性をともに扱うシステム言語や検証技法は Rust 以前には存在しなかった」という種類の主張を検討する際の重要な歴史的比較対象です。

しかし、これをそのまま「Ada/SPARK は Rust と同じ GC のないメモリ安全性モデルをすでに実装していた」あるいは「Rust は Ada/SPARK から直接影響を受けた」という主張に変えると、証拠の範囲を超えます。本節で確認した Rust Reference の影響一覧は C++、SML/OCaml、ML Kit、Cyclone などを明記していますが、Ada や SPARK を直接的影響として列挙していません。さらに、現在の SPARK の pointer ownership policy は後年追加された機能であり、AdaCore はその pointer support が Rust ownership model に基づくと説明しています。³⁴ したがって本節では Ada/SPARK を 高信頼性の目標と静的・形式検証の歴史的先例として比較し、Rust ownership の直接の祖先としては扱いません。また SPARK の proof は明示された属性、仮定、解析範囲に対する証明であり、Rust borrow checker の自動検査とは保証単位が異なります。そのため、比較する属性を定義せずに、どちらか一方を包括的に「より広い」「より強い」と序列化しません。

代数的データ型とエラー表現：直接的影響の範囲を限定する

Rust Reference は、SML と OCaml の algebraic data types、pattern matching、type inference を Rust 設計への影響として明記しています。Rust の Option<T> は None と Some(T)、Result<T, E> は Ok(T) と Err(E) を持つ enum であり、OCaml の標準 option も None と Some によって値の不在と存在を型で表現します。³⁵ したがって、値の不在や成功・失敗を sum type 系のデータ型で表現する Rust の方式は、関数型言語の伝統と関連付けて説明できます。

ただし、公式の影響一覧が直接確認している範囲は、SML/OCaml の ADT、pattern matching、type inference からの影響です。これらの資料だけでは、Result と Option の具体的 API が Haskell や OCaml の特定のエラー処理 API から直接派生した、あるいは Rust が「モナド的エラー処理」をそのまま借用したと断定することはできません。また exhaustive な match は variant の処理範囲を静的に検査できますが、Rust のすべてのエラー処理コードにすべての場合を常に明示させるわけでもありません。ここで確認できるのは、型による状態表現という設計上の系譜と Rust における具体的な表現であり、あらゆるエラー処理方式に共通する単一の系譜ではありません。³⁵

中間結論

歴史的に直接確認できる関係と比較を分けると、全体像はより明確になります。C++ の RAII、smart pointers、move semantics と SML/OCaml の ADT などは、Rust Reference が直接的影響として記録している要素です。Ada と初期 SPARK は Rust 以前の高信頼性・形式検証の系譜に属する歴史的比較対象ですが、本節の資料だけでは Rust への直接的影響とは断定できず、現在の SPARK の pointer ownership はむしろ後年 Rust モデルを参照して追加されました。したがって Rust の独創性は、「先例がまったく存在しなかった」という命題よりも、複数の先行アイデアを特定の所有権・借用規則と、言語・ツール体系の中で組み合わせて強制した方法として検討する方が正確です。その組み合わせがどのような保証を提供し、どのようなコストを伴うかは歴史的な先後関係とは別の工学的問題であり、以降の節で属性ごとに分析します。

3.2 Rustの「安全性」の定義、境界、限界

この節の問いは「Rust は安全か」ではなく、Safe Rust がどの条件で何を保証し、その保証がどこで終わるかです。言語レベルの安全契約、unsafe 実装の soundness、コンパイラ・ライブラリ・OS などの実装や外部システムの正しさ、そしてサービス可用性は、互いに異なる分析単位です。これらを一つの「安全性」にまとめると、Rust の実際の長所も実際の限界も誇張することになります。

そこで 3.2.1 では Safe Rust と未定義動作（Undefined Behavior, UB）の関係を整理し、3.2.2 では unsafe と FFI を「保証の放棄」ではなく、明示的な safety contract と proof obligation の境界として分析します。3.2.3 では panic の unwind・abort 戦略と隔離・回復の限界を、3.2.4 ではメモリおよび資源リークが memory safety の保証外にある理由を、3.2.5 では論理エラー、一般的な race condition、デッドロック、資源枯渇、セキュリティ脆弱性と memory safety の違いを検討します。

3.2.1 「安全性」の定義：未定義動作の防止

Rust Reference では、UB はプログラムが行ってはならない動作の集合です。現在の一覧には、data race、dangling または不正に整列された pointer に基づく不正なメモリアクセス、aliasing 規則違反、誤った ABI による関数呼び出し、invalid value の生成などが含まれます。Reference はこの一覧自体を完全な形式意味論だとは主張せず、将来調整され得る境界であることも明記しています。³⁶

Safe Rust の中核契約は、safe caller が sound な safe interface を使用するとき、その interface を通じて UB を引き起こせないようにすることと理解するのが正確です。これは「ソースコードに unsafe という語がなければ、プログラム全体でどのような理由からも UB は起こらない」という経験的予言とは異なります。Safe Rust のコードは、標準ライブラリやサードパーティライブラリの safe API を呼び出せ、その実装内部には unsafe が含まれる場合があります。その内部実装が safety contract を守れず、safe caller が UB を引き起こせるなら、Rust Reference の用語ではその実装は unsound です。³⁶

具体的なエラー型も同じ基準で区別する必要があります。すでに生存していない allocation を参照解除したり、不正な reference を生成して使用したりすることは UB になり得ます。Rust の reference は適切に整列され、non-null で、dangling でない必要があります。data race も UB です。一方、安全な配列・slice の通常の indexing が動的に範囲外になった場合、実行時の bounds check を経て panic となり、それ自体を直ちに buffer overflow による UB と呼ぶことはできません。範囲検査を省略する get_unchecked のような操作は、追加の safety condition を持つ unsafe 操作であり、その条件違反が UB の境界に入ります。³⁷

この区別は、言語保証と実装の正しさを分けるために重要です。Rust の言語モデルが safe interface に要求する契約、特定の rustc バージョンがその意味を正しく実装しているか、標準ライブラリや crate 内部の unsafe が sound か、OS・ハードウェア・foreign code がそれぞれの契約を守るかは、別々の問題です。コンパイラの誤動作や unsound なライブラリ実装が実際の実行でメモリ安全性を破ることは重要な実装リスクですが、それを「Safe Rust の言語規則が UB を許している」という別の命題に置き換えてはいけません。

3.2.2 `unsafe`キーワードとFFI・外部契約の境界 {#322-unsafeキーワードとc-abiへの依存}

unsafe は所有権・型・lifetime 規則全体を無効にするスイッチではありません。Rust Reference は unsafe を、コンパイラが検査しない追加の safety condition に対する proof obligation を作る、または別の場所で作られたその義務を満たしたと宣言する印として説明しています。unsafe fn は caller が満たすべき追加条件を定義でき、unsafe { ... } はブロック内で実行する unsafe operation の条件をプログラマが満たしたと主張します。unsafe 内部でも UB は依然として不正なプログラム動作であり、ほかの型検査や言語規則が消えるわけでもありません。³⁸

したがって、責任の位置も一か所に固定されません。unsafe fn の文書化された前提条件は caller が満たす必要がありますが、内部に unsafe を隠す safe abstraction では逆に、すべての safe input に対して内部条件が維持されるよう実装者が保証しなければなりません。safe API が sound であるには、safe caller が未文書化の safety condition を知らなくても UB を引き起こせない必要があります。そのため「unsafe を使った瞬間にすべての安全責任が caller に移る」という説明は正確ではありません。どの contract を誰が定義し、どの境界で誰が proof obligation を果たすかを API ごとに見る必要があります。³⁸

FFI は、この境界が明確に現れる代表例です。external block は現在の crate 外で定義された item を宣言する FFI の基盤であり、Rust Reference はこれを unchecked import に近い境界として扱います。Rust 2024 Edition では external block 自体に unsafe extern の表記が必要で、宣言の作成者は関数や static の signature が実際の外部定義と一致することに責任を負います。外部 item は明示的に safe と宣言されない限り、通常は unsafe に呼び出すかアクセスする必要があります。³⁹

しかし FFI を C ABI への普遍的な構造依存と同一視してはいけません。"C" ABI は非常に重要な相互運用経路であり、external block で ABI 文字列を省略した場合の既定値でもありますが、Rust は "system"、"C-unwind" などほかの ABI も定義しています。また、低水準機能は FFI 以外の unsafe operation やプラットフォーム固有インターフェースで実装される場合もあります。実際のシステムが C ABI をどの程度使用するかは、対象 OS・ライブラリ・ハードウェア・統合アーキテクチャの属性です。Rust の言語レベルの境界は「C を使うこと」ではなく、コンパイラが検証できない外部契約を誰がどの根拠で保証するかにあります。³⁹

大規模システムでは、この違いが保守性と障害隔離に直接つながります。FFI wrapper が pointer の有効性、長さ、ownership、lifetime、aliasing、ABI、error と unwind の規約を狭い内部境界で検証し、外部には sound な safe API だけを公開すれば、リスクを局所化できます。逆に、safe API 内部の unsafe、外部ライブラリ、または ABI 宣言が誤っていれば、呼び出し側が Safe Rust だけで書かれていてもプログラム全体が影響を受け得ます。つまり Safe Rust の強みは、未検証の義務をすべて消すことではなく、多くの義務を safe caller から隔離して狭い境界へ集中できる点にあります。

3.2.3 「安全な失敗」と `panic` の意味

panic を一つの普遍的な「安全な失敗（safe failure）」モデルとして定義するのは正確ではありません。安全な配列 indexing の bounds check のように、定義された safe operation がエラー条件を検出して panic すること自体は UB ではありませんが、その後プログラムやサービスがどう動くかは panic strategy と隔離構造によって異なります。

Cargo と rustc は panic strategy を大きく unwind と abort に分けます。unwind では panic が stack を巻き戻し、その経路で cleanup を実行できますが、abort では process が終了します。対象プラットフォームやビルド設定によって実際の strategy は変わり得るため、「panic は既定で常に stack を unwind し、現在の thread だけを終了する」と一般化してはいけません。より広くは、Rust の安全契約そのものも、すべての destructor が必ず実行されることを保証しません。⁴⁰

std::panic::catch_unwind も一般的な例外処理やサービス回復の保証ではありません。この関数が捕捉するのは unwinding panic だけであり、aborting panic は捕捉できません。標準ライブラリ文書は、通常の動作中に発生し得る失敗には Result の方が適切であり、catch_unwind を一般的な try/catch 手段として使うことを推奨していません。また closure には UnwindSafe の境界が適用され、panic の途中で部分的に変更された状態や壊れた論理 invariant を後続コードが観測し得る点は別途扱う必要があります。⁴⁰

thread 境界も「自動回復」と同じではありません。unwind 方式で子 thread が panic した場合、JoinHandle::join はそれを Err として観測できるため、thread を一つの隔離単位として設計できます。しかし、これを実際のサービス回復にするには、caller がその Err を処理し、共有状態の一貫性を確認し、失敗した作業の retry・破棄・restart 方針を定義する必要があります。panic = "abort" なら process 自体が終了し得ますし、join の結果を再び unwrap したり panic を上位境界へ伝播させたりする設計もサービス停止につながり得ます。⁴⁰

したがって memory safety と availability は別の属性です。panic が UB ではなく定義された制御フローであるという事実だけでは、request isolation、thread/process 境界、supervisor と restart、状態回復、retry policy、障害伝播範囲は保証されません。長時間稼働する server や embedded・mission-critical system では、どの panic strategy を使うかとともに、失敗がどの execution boundary まで伝播し、その後どのようにサービスを復元するかを別途設計する必要があります。

3.2.4 「安全な」メモリリークの問題

Rust Reference は、メモリやほかの資源の leak を unsafe とみなさない動作に明示的に含めています。ここで「safe」とは運用上望ましい、あるいは障害が起きないという意味ではなく、leak 自体が Rust の memory-safety contract に違反する UB ではないという意味です。⁴¹

この境界は標準ライブラリの std::mem::forget で特に明確です。mem::forget は値の ownership を受け取り、destructor を実行せずにその値を忘れる safe 関数です。文書は、Rust の safety guarantee に destructor の必須実行が含まれないため、この関数を unsafe にする必要がないと説明し、Rc<T> の reference cycle や process 終了も destructor が実行されない場合の例に挙げています。Rust Book も、Rc<T> と RefCell<T> による reference cycle が Safe Rust でメモリ leak を起こし得ることを説明しています。⁴¹

これは単なる用語の問題ではありません。漏れた heap memory、file descriptor、socket、lock などの有限資源は、長時間実行される process で資源枯渇、latency 増加、request failure、最終的にはサービス停止につながり得ます。したがって、memory-safe な leak は availability-safe な動作ではありません。大規模・長期運用環境では、memory だけでなく descriptor、connection、task、queue など有限資源の上限と回収経路を別の invariant として管理する必要があります。

また unsafe 実装は、「caller が最終的に Drop を実行する」という仮定に soundness を依存させてはいけません。safe caller は値を mem::forget でき、process は destructor を実行せず終了する場合があるためです。この原則は Rust の安全境界が単純な RAII の説明より広く、resource lifecycle と memory-safety proof obligation を区別すべきことを示します。

3.2.5 保証範囲外の問題（論理エラー、デッドロックなど）

Safe Rust の強い保証は、すべての correctness・security・availability 属性へ自動的に拡張されるわけではありません。Rust Reference は deadlock や memory/resource leak を unsafe とみなさず、safe code が追加の論理条件に違反した場合でも、結果が panic、誤った計算結果、abort、non-termination などになることはあっても、それだけで UB を意味するわけではないと説明しています。⁴²

特に、data race と一般的な race condition を区別する必要があります。data race は Rust では UB であり、Safe Rust が防ぐ中核的な対象です。しかし実行順序によって結果が変わる一般的な race condition、TOCTOU、不正な protocol state transition、livelock、starvation まで borrow checker が除去するわけではありません。Rustonomicon も、Safe Rust が data race の不存在を保証する一方、一般的な race condition までは防止しないと区別しています。⁴³

整数 overflow も同じように境界を慎重に見る必要があります。Rust Reference は arithmetic overflow をプログラマエラーとして扱いますが、それを直ちに UB とは分類しません。debug_assert! が有効な構成では動的検査を挿入して overflow 時に panic する必要があり、それ以外の build では実装が panic するか暗黙に wrapping することができます。暗黙の wrapping が行われる場合、結果は two’s-complement 規則で定義されます。Cargo profile の overflow-checks は実行時 overflow 検査の有効化を制御するため、「debug は panic、release は常に wrapping」という固定規則に単純化するのは不正確です。⁴²

セキュリティ脆弱性も memory safety より広い概念です。Rust Security Response WG が 2024 年に公開した CVE-2024-24576 は、Windows で std::process::Command が batch file を実行する際の argument escaping が不十分で、攻撃者が信頼できない argument を制御できる条件では任意の shell command 実行につながり得る問題でした。この API は safe に呼び出せましたが、中核原因は memory corruption ではなく、command argument の処理と API contract における論理的欠陥でした。元の問題は Rust 1.77.2 で修正され、その後 trailing whitespace と period により緩和策を回避できる別の不完全修正問題 CVE-2024-43402 が報告され、Rust 1.81.0 で追加修正されました。⁴⁴

この事例から導ける結論は限定的です。特定の過去バージョンの標準ライブラリに論理的なセキュリティ欠陥があったという事実は、Rust エコシステム全体の脆弱性頻度や現行バージョンのリスクを示しません。逆に、Safe Rust の memory-safety contract が強いという事実も、command injection、認証・権限エラー、protocol bug、resource exhaustion、deadlock、不正な状態遷移、サービス回復失敗が自動的に排除されるという根拠にはなりません。

中間結論

Safe Rust の重要な工学的利点は、sound な abstraction 境界の内部で、safe caller が特定の UB と data race を引き起こせないよう強制する点にあります。しかしこの保証は、compiler correctness、unsafe implementation の soundness、FFI と外部システムの contract、一般的な race condition、論理的正しさ、資源上限、panic の隔離、サービス回復までを一つの保証にまとめるものではありません。memory safety、security、correctness、availability、resilience は互いに関連し得ますが、同一の属性として評価すべきではありません。この区別は、次節でほかの言語や変更戦略を比較するときの基準となり、それ自体で特定の言語移行戦略の優越性を結論づけるものではありません。

3.3 比較分析1：C/C++の多層的な安全性確保と変更戦略

本節の問いは「C/C++ を Rust に置き換えるべきか」ではなく、既存システムの欠陥モデルと資産、移行リスク、保証要件を考慮したとき、どの変更戦略を選択または組み合わせるべきかです。3.2 節で確認した Safe Rust の保証は言語選択における重要な入力ですが、その保証だけで、保守、近代化、選択的置換、新規開発、全面書き直しのどれが最適かは決まりません。

変更戦略を比較する際には、少なくとも二種類の効果を分ける必要があります。一つは変更後の実装がどの欠陥を予防、検出、緩和するかであり、もう一つは変更そのものが生む仕様復元、互換性、配備、ロールバック、二重運用、人員、長期保守のコストです。前者は目標状態の品質、後者は移行過程のリスクです。片方だけを計算すると、言語保証または既存資産の価値を過大評価しかねません。

3.3.1 リファクタリング、近代化、書き直しの区別

本書では、変更戦略を次のように区別します。これはあらゆる方法論に共通する普遍的な分類体系ではなく、本節の比較単位を明確にするための作業定義です。

保守と欠陥の補強： 既存実装と外部動作を置き換えずに、欠陥修正、入力検証、隔離、ハードニング、テスト、観測性を強化する作業です。
リファクタリング： 外部から観察可能な動作を維持しながら内部構造を改善する作業です。Martin Fowler も、リファクタリングを観察可能な動作を変えずに内部構造を変更することと定義しています。⁴⁵
近代化： 新しい言語機能やライブラリ、ビルド・解析ツール、API、モジュール境界、配備構造などを改善する、より広い作業です。必要であれば外部動作や運用方式を意図的に変更することもあります。
選択的置換： リスクまたは変更価値の高い一部の構成要素だけを新しい実装に置き換え、残りのシステムと共存させる戦略です。言語を変更する場合も、同じ言語で再実装する場合もあります。
新規構成要素の導入： 既存実装を置き換えず、新しい機能やサービスを別の言語で作成する戦略です。
全面書き直し： 既存実装の広い範囲を新しい実装で置き換える戦略です。言語移行は部分的にも可能なので、「言語移行」と「全面書き直し」も同義語ではありません。

したがって、C/C++ を Rust で書き直すことはリファクタリングの同義語ではありません。 それは選択的置換、全面書き直し、あるいはより広い言語移行の一形態になり得ます。逆に Rust の導入も必ずしも書き直しを意味せず、新規構成要素だけを Rust で作成したり、狭い高リスクモジュールだけを置き換えて周囲の C/C++ を維持したりできます。

3.3.2 C/C++内部のリファクタリングと近代化の実質的価値

C と C++ の改善手段は、Safe Rust と同等の一つの言語保証に還元できません。設計規則、型と資源管理の慣用句、静的解析、実行時 instrumentation、テストと fuzzing、隔離、exploit mitigation は異なる層で機能します。したがって、予防（prevention）、検出（detection）、緩和（mitigation）を区別する必要があります。

C++ Core Guidelines は、RAII と resource handle による自動資源管理、unique_ptr と shared_ptr による ownership の表現、span のような範囲表現を推奨します。同時に Guidelines は既存コードベースへ段階的に導入できるよう設計されており、言語自体がすべての規則を強制するわけではありません。clang-tidy も cppcoreguidelines-*、clang-analyzer-*、bugprone-* など選択可能な検査を提供しますが、その範囲は有効化した解析が診断できるパターンに限られます。⁴⁶

動的ツールの性格はさらに明確です。Clang の AddressSanitizer は heap、stack、global の out-of-bounds、use-after-free、invalid free など複数のメモリエラーを計測された実行で検出し、ThreadSanitizer は data race を検出します。UndefinedBehaviorSanitizer も選択した UB 検査を実行時に計測します。これらは C/C++ の欠陥を見つける強力なツールですが、実行されなかった経路まで含めた言語レベルの不存在証明ではありません。

コストもあり、現在の Clang 文書は AddressSanitizer の典型的な実行時間オーバーヘッドを約 2 倍、ThreadSanitizer を約 5～15 倍の実行時間と約 5～10 倍のメモリオーバーヘッドと説明しています。また ASan と TSan の runtime は production executable へリンクする用途に設計されておらず、セキュリティ上敏感な環境での production 使用がそれ自体リスクになり得ると警告しています。

したがって大規模、高負荷、リアルタイム環境では、ASan・TSan のような検出 runtime は主として CI とテストに配置し、canary や production ではその環境への適合性が別途確認された instrumentation や mitigation を選ぶなど、ツールごとの適用境界を区別する必要があります。⁴⁶

C コードでも allocator/free 契約、長さを伴う buffer interface、単一の ownership 規則、狭い foreign interface、静的・動的解析、fuzzing によってリスクを減らせます。ただし、これらの規則が組織の convention、API discipline、特定の toolchain 設定に依存する場合、sound な Safe Rust interface が提供する言語レベルの契約とは保証の位置と強さが異なります。

層	代表的な手段	主な効果	保証または運用上の限界
設計・型・資源管理	RAII、smart pointer、`span`、明示的な ownership/length 契約	危険な lifetime・buffer 操作の範囲を縮小	raw pointer、legacy API、FFI、規則を回避する経路は別途管理が必要
静的解析	`clang-tidy`、Clang Static Analyzer など	有効化した解析で推論可能なソース上の欠陥・規則違反を早期診断	有効化した検査と解析精度に依存し、言語全体の不存在保証ではない
動的解析	ASan、TSan、UBSan	計測された実行で特定の memory/UB/data-race 欠陥を検出	実行経路と環境に依存し、時間・メモリコストが発生
テスト・fuzzing	回帰テスト、property-based test、coverage-guided fuzzing	既存動作と境界条件を実行ベースで検証	test oracle や coverage が不完全なら見逃し得る
隔離・ハードニング	sandbox、memory tagging、hardened allocator、exploit mitigation	欠陥の到達可能性、影響、悪用可能性を低減	欠陥そのものをすべて除去せず、性能・メモリ・運用コストが生じ得る

この多層的アプローチが Safe Rust と同じ保証を提供しないという事実は重要です。しかし、保証がより弱い、または別の層にあることと、工学的効果がゼロであるという主張は別です。 逆に sanitizer や guideline を多数使用しているというだけで、C/C++ コードが Safe Rust と同じ memory-safety contract を得たとも主張できません。

現在の Android 文書も、この区別を実際の運用戦略として採用しています。AOSP はほとんどの新規 native project で Rust を選好すると説明する一方、既存の memory-unsafe code 全体を Rust で書き直すことは現実的ではなく、Rust は memory-safety tooling を補完すると明記しています。既存 C/C++ には HWASAN、KASAN、GWP-ASan、memory tagging などの検出とハードニングを引き続き適用します。⁴⁷ この事例は、C/C++ の改善と Rust 導入が反対概念ではなく、大規模な移行期に併用できることを示します。ただし Android のコード構造や脆弱性分布が他のプロジェクトにもそのまま当てはまることを意味しません。

3.3.3 Rustによる書き直しが追加する保証と新たに生むリスク

Rust で新規作成または置換した範囲では、3.2 節の条件の下で Safe Rust の memory-safety contract を設計上の既定値にできます。これは guideline や sanitizer による検出とは異なる強い利点です。memory-safety 欠陥の影響が大きく、unsafe・FFI 境界を狭くでき、その構成要素を予定寿命にわたって保守できる能力がある場合、言語レベルの予防価値は特に高くなります。

しかし、言語の目標状態における保証と、変更手段としての書き直しは別の分析単位です。書き直しでは、新実装が既存システムに必要な動作、互換性、性能特性、運用契約を改めて満たす必要があります。Martin Fowler が段階的置換を論じる際に指摘するように、既存システムの実際の動作には置換開始時に想定した以上に詳細な仕様が含まれている場合があり、大規模な cut-over はリスクを一つの時点に集中させます。Strangler Fig はこうした問題を避けるための段階的 replacement pattern であり、すべてのシステムで部分置換が常に優れるという実証法則ではありません。⁴⁸

言語置換には、次のような別個の検証項目が生じます。

動作仕様と test oracle： どの legacy behavior を必ず維持し、どの behavior を意図的に削除するか決める必要があります。既存テストが不十分なら、新実装の「同等性」そのものが曖昧になり得ます。
interop と safety boundary： 既存 C/C++、OS、driver、library と共存する場合、FFI、ABI、ownership、error、unwind の契約を改めて明示する必要があります。境界が unsound なら Safe Rust だけで書かれた caller にも影響し得るという 3.2 節の限界はそのまま残ります。
配備・rollback・状態互換性： 旧実装と新実装を並行または段階的に移行するなら、protocol、data format、persistent state、rollback 可能性を設計する必要があります。
性能と運用成熟度の再検証： 新実装は平均性能だけでなく、tail latency、peak memory、startup、failure mode、rare input、observability、recovery behavior を対象 workload で再検証する必要があります。
長期的な組織コスト： 二つの言語と toolchain、dependency、build、debugging、code review、採用、教育を移行期間または長期共存期間に維持できるか評価する必要があります。

Android はこの問題をinterop 中心の段階的移行として扱った代表例です。Android team は C++ 全体の書き直しを非現実的と判断し、既存コードと Rust の相互運用を実用上の前提条件として分析しました。2024 年の firmware 事例では、新規コードとセキュリティリスクの高い既存コードを優先し、既存 C API を維持する thin Rust shim を使った選択的置換経路を説明しています。⁴⁹ これは部分導入が大規模システムで実行可能な戦略になり得ることを示します。ただし 2021 年の interop 分析は Android platform で実際に使われる exported C++ API と type を対象に互換性と実用性を評価したものであり、一般的なコードベースの interface cost や適合性を測定した普遍的資料ではありません。

逆に、これらの事例から「full rewrite は常に誤りである」という結論も導けません。Android team は Android Virtualization Framework の protected-VM firmware を Rust で書き直し、pVM root of trust の memory-safe foundation としました。⁵⁰ 保証上の利益が大きい境界が狭く、要件と検証範囲を制御でき、既存構造そのものを維持する理由が乏しい場合、構成要素レベルの書き直しは合理的な選択になり得ます。

したがって言語置換はリスクを単純に除去するのではなく、リスクの種類と位置を変えます。 sound な Safe Rust へ移した範囲では特定の memory-safety リスクを減らせますが、移行範囲が大きいほど仕様復元、interop、配備、rollback、運用成熟度、組織能力に関わるリスクを同時に管理する必要があります。純効果はコード行数ではなく、この二種類のリスクを同じ基準で比較して判断すべきです。

3.3.4 変更戦略の連続線と選択的導入

実際のプロジェクトでは、次の戦略を相互排他的に選ぶ必要はありません。一つのシステムで成熟した C++ モジュールを維持・ハードニングし、新規 native component を Rust で作成し、untrusted input を扱う高リスク parser だけを選択的に置換し、構造的に寿命を終えた小さな subsystem だけを書き直すこともできます。

変更戦略	先に確認すべき条件	得られる主な効果	主な移行・運用リスク
現行実装を維持し欠陥を補強	欠陥が局所的で変更リスクの方が大きい	最小の移行範囲、既存の動作資産を保存	構造的負債と memory-unsafe 領域が残り続ける可能性
C/C++ 内部で近代化	動作資産を維持しつつ ownership、boundary、検証を改善できる	段階的なリスク低減と迅速な rollback	規則・ツール適用の完全性が toolchain と組織 discipline に依存
新規構成要素を Rust で作成	既存動作を再実装する必要がない新機能	rewrite regression なしで Safe Rust の既定値を新コードへ適用	既存 API、build、runtime との統合コスト
高リスクモジュールを選択的に Rust へ置換	欠陥リスクが狭い interface に集中	保証上の利益を高リスク部分へ集中	FFI/ABI と dual-language lifecycle コスト
全面または広範囲の書き直し	既存 architecture 自体が要件を阻害し、仕様・test oracle・移行資源が十分	architecture と implementation model を同時に再設計	最も広い回帰、cut-over、rollback、日程、組織上のリスク

戦略を選ぶ前に、少なくとも次の問いを明示すべきです。

欠陥モデル： 実際に減らしたい問題は use-after-free、data race のような memory safety か、それとも論理エラー、可用性、性能、運用複雑性か。
欠陥の分布： リスクは新しく変更されるコードや特定の parser、driver、protocol boundary に集中しているか、それともシステム全体に分散しているか。
仕様と検証資産： 動作仕様、regression test、corpus、fuzz target、benchmark、production telemetry は新実装を判定するのに十分か。
境界と共存性： module interface は狭く、ownership、lifetime、error、state 契約を明示できるか。
配備と rollback： 部分 rollout、shadow/canary、旧実装への rollback、data/state compatibility は可能か。
性能と資源予算： throughput だけでなく tail latency、worst-case behavior、memory、code size、startup、energy、build/test cost を満たせるか。
保証要件： 規制、threat model、assurance case が convention と detection より強い言語レベル prevention または formal proof を要求するか。
組織とライフサイクル： 二つの toolchain と二つの言語を移行期または長期共存中にレビュー、デバッグ、更新できる人員とプロセスがあるか。

これらへの答えが異なれば、同じコードベースでも別の戦略が合理的になり得ます。Android の公式戦略が新規 memory-safe code、既存 C/C++ の hardening、interop、高リスク領域の選択的置換を併用することも、このような混合戦略の一例です。⁴⁷ これは「段階的導入が常に最善」という証拠ではなく、全面書き直しだけが memory safety を改善する唯一の経路ではないという可能性の証拠です。

評価指標も言語選択だけで終わるべきではありません。対象欠陥の再発率と severity、機能回帰、tail latency と resource ceiling、build/test 時間、障害回復時間、rollback 成功、運用複雑性、dependency と tooling の維持コストを変更前後で同じ定義により測定する必要があります。測定せずに「より安全」「より保守しやすい」と結論すると、言語保証と実際のプロジェクト結果を再び混同することになります。

3.3.5 主張分析：「唯一意味のあるリファクタリングはRustによる書き直しである」

次の文は、特定の人物や Rust Project の直接引用ではありません。「C/C++ で意味のある改善は Rust による書き直しだけである」という論理構造を検証するための合成的な分析命題です。

合成例：「C/C++ のリファクタリングとは Rust で書き直すことであり、それ以外のリファクタリングには何の意味もない。」

これを一般命題として受け入れると、次の問題が生じます。

カテゴリー錯誤： 観察可能な動作を保存する refactoring と、新実装で置換する rewrite を同じ作業として定義します。
偽の二者択一： 保守・ハードニング、同一言語での近代化、新規 Rust code、選択的置換、広範囲の書き直しという実際の選択空間を、「放置」と「全面 rewrite」の二つへ縮約します。
完全性の誤謬（nirvana fallacy）： C/C++ のツールと近代化が Safe Rust と同じ memory-safety guarantee を提供しないという理由だけで、欠陥検出、影響縮小、保守性改善という部分的効果までゼロとして扱います。
保証と結果の混同： Safe Rust の言語契約を、migration 後のシステム全体の security、availability、correctness、maintainability の結果と同一視する危険があります。
移行コストの欠落： 仕様復元、FFI/ABI、dual-language build、rollout、rollback、data・protocol compatibility、組織学習を比較から除外します。
非対称な証拠基準： C/C++ の改善には完全な欠陥除去を要求する一方、Rust 移行には言語保証だけでプロジェクト全体の成功が十分証明されたと扱うなら、二つの戦略に異なる証拠基準を適用しています。

反対方向の一般化も避ける必要があります。「C/C++ を十分に近代化すれば Rust へ移す理由はない」も普遍的には成立しません。 memory-safety 欠陥が主要な threat であり、process と testing だけではリスクを許容可能な水準まで下げられない場合、または要求される assurance がより強い prevention を必要とする場合、Safe Rust の強制的保証は選択的置換や書き直しを正当化する重要な根拠になります。

中間結論

3.3 節の結論は、どの言語が常に優れているかではなく、言語保証と変更戦略を分けて評価すべきだということです。Safe Rust は sound な境界内で特定の UB と data race を予防する強い既定値を提供し、これは C/C++ の guideline、解析、testing とは保証水準で明確な差があります。一方で既存 C/C++ のリファクタリング、近代化、ハードニングも別の層で実際のリスクを減らし得て、大規模な既存システムでは新規 Rust 導入や選択的置換と併用できます。

したがって、保守、近代化、新規 Rust 導入、選択的置換、全面書き直しのどの戦略が適切かは、欠陥モデル、保証要件、既存の動作資産、interface と testability、rollout・rollback の可能性、性能・資源上限、組織能力、総ライフサイクルコストによって異なります。これらの条件を明示しない「Rust rewrite だけが意味を持つ」と「既存 C/C++ の改善で十分である」という二つの普遍命題はいずれも、現在の根拠より強い主張です。

3.4 比較分析2：Ada/SPARKの数学的証明と保証水準

本節の問いは「Ada/SPARK は Rust より安全か」ではなく、各技術がどの属性を、どの時点と条件で予防・検出・証明し、その保証がどこで終わるのかです。3.2 節で整理した Safe Rust の memory-safety contract と比較するには、Ada の型・run-time check・例外処理と、SPARK の制限された言語サブセット・flow analysis・proof を一つの「安全性レベル」にまとめてはいけません。

比較単位も分ける必要があります。Safe Rust の中心は、sound な safe interface の内部で特定の UB と data race を言語規則によって予防することです。Ada は strong typing、language-defined run-time check、並行性・同期構文、例外処理機構を提供します。SPARK は Ada の解析可能なサブセットに追加制約と contract を置き、GNATprove により flow property、run-time error の不在、integrity property、functional contract を段階的に静的検証します。⁵¹ この三つのモデルは、保証の対象、時点、前提条件、コストが異なります。

Ada：実行時検出と例外処理は、自動的な回復保証ではない

Ada 2022 は、array index、scalar range、signed integer overflow、null access など多くの language-defined condition に run-time check を要求し、検査に失敗すると Constraint_Error などの例外を送出します。signed integer の overflow と modular integer の定義された wraparound も区別されます。例外が発生すると現在の実行系列の残りは破棄され、適用可能な handler に制御が移ります。局所的に処理されなければ、言語規則に従って伝播します。⁵²

これは C の unchecked memory access とは異なる重要な防御層です。しかし、「エラーを例外として検出する」ことと「システムが回復する」ことは同じ保証ではありません。 handler が状態を安全に復元するのか、失敗した request だけを隔離するのか、task や process を再起動するのか、persistent state の一貫性を保つのか、deadline や failover 要件を満たすのかは、プログラムとシステムアーキテクチャが別途保証する必要があります。Ada の exception mechanism は recovery policy を表現し実行する手段を提供しますが、service availability や mission continuity 自体を言語が保証するわけではありません。

Ada の dynamic check にも境界があります。Suppress によって language-defined check の省略を許可でき、抑制された検査が本来失敗する状況に実行が到達すると、標準はその実行を erroneous と規定し得ます。Unchecked_Deallocation、Unchecked_Access、Unchecked_Conversion、または外部 interface から不正な access value や representation が入る場合にも、別個の検証義務が生じます。⁵² したがって、Ada を「すべての memory error の不在を自動的に保証する」と要約するのも正確ではありません。

SPARK：「形式検証を利用できる」と「プログラム全体が証明済みである」は異なる

SPARK は Ada 全体ではなく、形式解析を可能にするため一部機能を制限した言語サブセットです。現在の SPARK User’s Guide は assurance level を次のように区別します。⁵¹

レベル	主な検証目標	本節での意味
Stone	有効な SPARK サブセットであることを検査	解析可能な言語境界を確立するが、プログラムの正しさを意味しない
Bronze	初期化と正しい data flow	uninitialized read や特定の parameter/global interference を静的に除去
Silver	Absence of Run-Time Errors (AoRTE)	解析範囲内で、`Constraint_Error` や assertion failure など予期しない例外を起こす run-time error の不在を証明
Gold	key integrity property の証明	invariant や state transition など、明示した中核的な安全・完全性属性を証明
Platinum	functional requirement の形式化と証明	contract が機能要件を十分に表現する範囲で、実装が specification を満たすことを証明

したがって、「SPARK は run-time error の不在を数学的に証明する」という表現には、解析対象と proof obligation が実際に閉じているという条件が必要です。 Silver の AoRTE は division by zero、buffer/index error、overflow など Ada check に対応する多くの run-time error の不在を証明できますが、公式文書は Storage_Error を SPARK の解析範囲外と明記しています。また Skip_Proof、SPARK_Mode => Off の領域、外部 Ada/C/assembly code、imported data、hardware model には別途 assumption や検証手段が必要です。⁵³

並行性：data race の不在と race condition の不在は異なる

Ada 自体は protected object、atomic/volatile object など shared-state synchronization の仕組みを提供しますが、これを「すべての data race を実行時に自動遮断する」と表現するのは強すぎます。Ada 2022 は、task が shared variable を読み書きする場合に適切な synchronization を必要とする言語規則を定め、atomic object の read/update が indivisible であることなどの semantics を定義します。⁵²

SPARK の concurrent subset はさらに狭くなります。Ravenscar または Jorvik profile では task 間共有を synchronized object に制限し、GNATprove が possible data race を診断できます。Ravenscar の単一コアでは protected-object locking に Priority Ceiling Protocol を適用して deadlock を防ぐよう制限し、GNATprove も protected subprogram 内の potentially blocking action や tasking 関連制約を検査します。しかし公式文書の atomic counter 例が示すように、data race がなくても、二つの task が同じ値を読み、その後互いに上書きする lost-update race condition は残り得ます。 この種類のエラーを防ぐには protected operation やより強い protocol invariant が必要です。⁵⁴

現在の GNATprove の project-wide tasking analysis にも範囲上の制約があります。解析は処理中の source file が直接・間接に with する unit の context を用いるため、互いに接続されていない library unit の task が同じ resource にアクセスする構成では、一部の tasking check を見逃す可能性があると公式文書が記載しています。⁵⁴ したがって SPARK の文書化された data-race・deadlock 保証は、対応 profile、該当する場合の単一コア条件、実際の GNATprove 解析 context とともに読む必要があります。この区別は 3.2 節の Safe Rust にも同様に適用されます。data race を予防することは、TOCTOU、誤った state transition、deadlock、starvation など一般的な concurrency defect の不在証明と同じではありません。

証明の境界：contract、assumption、外部システム

GNATprove の modular proof は caller を解析するとき callee の contract を仮定し、callee body を解析するときその contract を検証します。プログラム全体が SPARK として解析されない現実のシステムでは、non-SPARK Ada、C、assembly、device register、imported value、compiler と target behavior に関する前提が残り得ます。SPARK 文書は --assumptions と別途 review によってこれらの残存 assumption を管理するよう求め、pragma Assume のような assumption が verification process に誤りを持ち込む可能性があるため慎重に正当化すべきだと明記しています。⁵³

したがって proof result を解釈するときは、少なくとも何を証明したか、どの code scope を解析したか、どの contract を specification としたか、どの assumption を信頼したか、外部環境と compiler/runtime/hardware をどのように検証したかを併記する必要があります。不正確または不完全な specification に対する完全な proof は、実際の要求に対する完全な correctness と同義ではありません。

保証メカニズムの比較

属性	Safe Rust	Ada	SPARK	主な境界
memory access と lifetime	sound な safe boundary 内で特定 UB を静的に予防	index/range/null access など language-defined check を行うが、一般的な dangling-access lifetime error の不在を一括保証しない	制限された pointer/aliasing model と proof により関連 AoRTE を静的に証明可能	Rust の `unsafe`/FFI、Ada の suppressed/unchecked operation、SPARK 外 code と assumption
配列範囲	safe indexing は範囲外で `panic`、unchecked access は `unsafe` 境界	`Index_Check` 失敗で例外	check が失敗しないことを proof obligation として証明可能	proof されていない code と外部入力 contract
整数 overflow	3.2 節の profile・operation 別 semantics に従い、memory safety とは別	signed integer は overflow check 失敗で例外、modular integer は定義された wraparound	解析範囲内で overflow check failure の不在を AoRTE として証明可能	`Storage_Error`、別個の resource bound、external arithmetic assumption
data race	sound な Safe Rust で予防	synchronization construct を提供するが、すべての shared access を自動検出・遮断しない	対応する concurrent subset で data race を静的に排除	一般的 race condition と protocol bug は別問題
general concurrency correctness	deadlock・livelock・starvation・TOCTOU を一般には保証しない	protected/tasking mechanism を提供するが、correct protocol は設計責任	対応 subset で data race を静的に排除し、Ravenscar 単一コアの deadlock 防止制約と protected/tasking rule を検査し、明示した invariant を解析可能	lost update など一般 race と liveness は別で、現在の project-wide tasking analysis には context 範囲の制約がある
logical/integrity property	type system が表現する一部 invariant を除き、一般的な機能正確性は別	contract を表現し dynamic check 可能	Gold/Platinum で明示した integrity/functional contract を証明可能	specification completeness と assumption に依存
recovery と availability	panic strategy と isolation/restart architecture は別問題	exception handler で response policy を実装可能	AoRTE により特定の unexpected exception 自体を除去可能	いずれも service recovery、redundancy、deadline、resource ceiling を自動保証しない
resource exhaustion	memory/resource safety とは別	`Storage_Error` など別 failure mode	`Storage_Error` は SPARK analysis 対象外	capacity planning、bounded allocation、admission control など別 invariant が必要

この表で重要なのは、どれか一つの列を単一スコアへ変換しないことです。Safe Rust の強みは、比較的少ない specification annotation で特定の memory-safety invariant を通常コードの既定制約として強制する点にあります。Ada は型、dynamic check、exception、tasking abstraction により別の防御層を提供します。SPARK は、より制限された言語、明示的 contract、proof effort を受け入れる代わりに、AoRTE を越えて key integrity property と functional requirement まで静的 proof の対象を拡張できます。

性能・リアルタイム・ライフサイクルコスト

保証メカニズムをどこに置くかは、性能と保守コストにも影響します。Ada の run-time check は実行中の検出を提供するため、対象 workload における時間コストと worst-case execution time への影響を評価する必要があります。SPARK の AoRTE が実際に完了した範囲では、GNAT/SPARK workflow は proof を根拠として対応 check を除去した executable を作成できますが、「proof が無料」という意味ではありません。公式文書は、大規模プログラムの proof に数時間かかる場合があり、loop invariant・contract・manual proof・justification の保守コストが生じ、Platinum 水準の full functional proof は一般的ではなく、通常は小さな範囲に適用されると説明しています。⁵¹

大規模・極限環境では、runtime overhead だけでなく proof latency、CI 資源、incremental verification の可能性、contract 変更の波及範囲、external assumption の寿命、toolchain qualification、worst-case timing、memory ceiling、failure containment も合わせて比較する必要があります。強い静的 proof により特定の run-time check コストを除去できても、resource exhaustion、hardware fault、誤った要求、運用上の recovery まで自動的に解決するわけではありません。

中間結論

Ada/SPARK との比較が示すのは、「Rust が C/C++ と SPARK の間の一点に位置する」という単純な安全性序列ではありません。より正確な結論は、安全保証には複数の次元があり、言語ごとにその異なる部分を異なるコストで扱うということです。

Safe Rust には、sound な safe boundary 内で特定の UB と data race を既定で予防するという強い利点があります。Ada は strong typing、language-defined run-time check、exception、synchronization mechanism によりエラー検出と対応を構造化します。SPARK は解析可能なサブセットと明示的 specification を前提として、AoRTE、integrity property、functional contract まで静的 proof の範囲を拡張できます。逆に SPARK の proof も、Storage_Error、non-SPARK code、external system と assumption、specification completeness を越えて自動的に拡張されるわけではありません。

したがって、「Rust はコンパイルされれば安全だ」「Ada は例外があるので回復が保証される」「SPARK はプログラム全体が数学的に正しいことを保証する」という三つの文はいずれも、必要な条件を省略した過度に強い要約です。比較すべきなのは言語名ではなく、保証したい属性、保証範囲、失敗条件、検証コスト、実行時コスト、そしてシステム全体に残る proof obligationです。

3.5 比較分析3：代替的なメモリ管理方式（GC）の再評価

本節の問いは「GC は Rust より遅いか」または「GC 言語はシステムプログラミングに不適切か」ではなく、自動メモリ回収と ownership/lifetime 中心の管理がそれぞれどの欠陥を減らし、どの実行時・資源・開発・運用コストを残すかです。3.2節と同様に、言語保証、メモリ回収方式、特定 runtime の実装、実際の workload で観測された結果を分離する必要があります。

GC と memory safety は同じ概念ではない

Tracing GC の直接の役割は、root から到達可能な（reachable）object を追跡し、到達不能になった managed heap のメモリを再利用可能にすることです。GC が管理する object では手動 free が不要なので、managed 領域における premature free や、すでに解放された object の再利用といった種類のエラーを減らす強い手段になります。しかし、garbage collection はメモリ回収方針であり、それ自体が言語全体の memory-safety の定義ではありません。 bounds/type check、native・unsafe code、FFI、論理エラー、concurrency protocol、resource exhaustion は別の言語・runtime・system rule に依存します。⁵⁵

Reachability と「application から見てもう不要であること」も同義ではありません。global cache、collection、event registration などの root が object を参照し続ければ、tracing GC はその object を正しく live と判断して回収しません。

そのため GC を使っていても、誤った retention によって heap が増え続けたり OutOfMemory に到達したりし得ます。file descriptor、socket、lock、memory mapping などの非メモリ資源も、GC の reachability だけで望む時点に解放されると仮定してはいけません。

Go の runtime.AddCleanup 文書は、cleanup が object の到達不能後に任意に遅れて実行され得ること、program 終了前に実行される保証がないことを明記しています。.NET 文書は unmanaged resource を包む object に Dispose などの明示的な cleanup path を提供するよう推奨します。したがって release 時点そのものが correctness の一部である資源は、GC reachability や cleanup/finalizer だけで管理すべきではありません。⁵⁵

「現代の GC」にも単一の latency・throughput 特性はない

GC を一つの実装として扱い、「Stop-the-World だから遅い」あるいは反対に「現代の GC では pause 問題が解決された」と一般化すると、実際の選択空間を失います。同じ runtime に serial、parallel、generational、mostly-concurrent、fully-concurrent collector や複数の latency mode が共存する場合があり、collector 実装自体も release ごとに変化します。たとえば Go 1.26 では、それまで experimental だった Green Tea collector が既定値になりました。⁵⁶

現在の Java SE 26 HotSpot 公式文書は、この違いを明示的に示します。既定の G1 は高い throughput とともに pause-time goal を高い確率で満たすよう設計され、ZGC は最大 pause を 1ms 未満に保つ low-latency collector と説明される一方、一部の throughput をコストとして支払います。Oracle も collector 選択は heap size、live data、CPU、workload に依存すると限定しています。この事例は「すべての GC は長い pause を持つ」という主張への強い反証ですが、ZGC の数値を他の collector や runtime の普遍的属性として移す根拠にはなりません。⁵⁶

Go の公式 GC guide も、throughput だけでなく memory と CPU の trade-off を GOGC と memory limit によって説明します。memory limit を live heap に近づけすぎると GC が過剰に実行され、thrashing と深刻な進行低下を起こし得るため、Go の memory limit は hard limit ではなく soft limit と定義されます。tracing の大半が application と concurrent に実行されても、短い stop-the-world transition、GC CPU scheduling、mutator assist、write barrier、root scan などの latency source は残ります。⁵⁶

.NET も同種の trade-off を文書化しています。low-latency mode は一部の collection を抑制して pause 介入を減らしますが、managed heap が大きくなり fragmentation が増えることがあり、memory pressure が生じれば collection が再び実行され得ます。したがって latency を減らす方針も、CPU・memory・fragmentation・failure risk と独立した無料の最適化ではありません。⁵⁶

短い pause と hard real-time 保証は区別しなければならない

ZGC の文書化された 1ms 未満の最大 pause は、low-latency system における重要な工学的選択肢になり得ます。しかし、短い GC pause、p99 latency、pause-time target は、hard real-time deadline を満たすことの証明と同じ命題ではありません。 G1 は pause-time goal を確率的な目標として表現し、.NET low-latency mode でも memory pressure があれば collection が介入し得ます。Go 文書も GC pause とは別に、concurrent GC の CPU 占有や mutator assist など end-to-end latency に影響する要因を列挙しています。⁵⁷

反対に「GC が存在すれば hard real-time は原理的に不可能だ」と一般化することも、これらの資料が立証する結論ではありません。real-time 適合性は、特定 collector の scheduling、allocation、barrier、pause bound、heap policy、OS scheduler、hardware、workload を含む実行モデル全体に依存します。通常の low-pause goal や平均・percentile 測定だけで hard deadline を保証したと見なしてはいけません。Rust が tracing GC の pause と tracing CPU という一種類の変動要因を除去することは利点ですが、allocator、page fault、I/O、lock contention、destructor work、scheduler に起因する deadline miss まで言語が自動的に除去するわけではありません。

Rust と tracing GC のコストは「開発者時間対機械時間」の二つに分けられない

従来の「Rust は開発者時間を使い、GC 言語は機械時間を使う」という比喩は、一部のコスト移動を説明しますが、比較モデルとしては単純すぎます。Rust にも heap allocator、Drop、reference counting、atomic operation、locking、cache behavior などの実行時コストがあり得ます。GC 言語も heap sizing、allocation-rate 管理、profiling、tail-latency tuning、deterministic resource release に開発・運用コストを支払います。反対に tracing GC は複雑な object graph や cycle のメモリ回収を自動化して明示的な lifetime 表現の負担を減らし得る一方、Rust は通常の scope/ownership 境界で resource lifetime をより直接的に表現できます。

比較次元	Rust の ownership/lifetime 中心管理	tracing GC 中心管理	確認すべき境界
managed memory の回収	ownership の終了と `Drop` に回収時点を直接結び付けやすい	reachability と collector cycle に従って自動回収	Rust の `Rc` cycle・意図的 leak・abort、GC の retained root と delayed collection
use-after-free・double-free	sound な Safe Rust boundary 内で静的に予防	reachable な GC-managed object は回収されないため managed heap でこれらのエラーを減らす	Rust `unsafe`/FFI と managed runtime の native/unsafe boundary は別
cyclic object graph	`Rc`/`Weak`、arena、index など別の構造が必要になる場合がある	unreachable cycle も tracing で回収可能	reachable だが不要な cycle・cache は GC も回収しない
latency	tracing pause・write barrier・GC thread はないが allocator・drop・scheduler コストは残る	collector ごとに pause、concurrent work、barrier、mutator assist が異なる	workload 上で end-to-end tail latency と worst case を測定
CPU・throughput	heap graph tracing コストはないが allocator・drop・refcount・synchronization コストは存在	tracing・barrier・GC worker が CPU を使い、collector が latency と throughput を交換	平均 throughput だけから tail latency や energy を推論しない
memory footprint	GC 用 heap headroom は必須ではないが allocator fragmentation と working set は残る	live set に加えて allocation headroom と GC metadata が必要で、tuning により footprint が変わる	RSS、peak committed memory、fragmentation、OOM/thrashing を同じ定義で測定
非メモリ資源	通常の lifetime では `Drop`/RAII により release を構造化可能	GC reachability だけでは release 時点を保証できず explicit close/dispose が必要な場合がある	abort/process death/external resource semantics は両側で別
hard real-time	tracing GC がないだけでは deadline は保証されない	low-pause collector だけでは deadline は保証されない	WCET、allocation policy、scheduler、page fault、I/O、failure containment まで含める

大規模・極限環境での評価基準

したがって GC と Rust を比較するときは、単一 benchmark の平均 throughput や GC pause 一つの数値だけを比べてはいけません。少なくとも、allocation rate、live-set の大きさと変動、object graph の pointer density、heap headroom と RSS、GC/allocator CPU、p50・p99・p99.9 および最大 pause、end-to-end tail latency、throughput、peak memory、OOM または thrashing、startup、resource-release 遅延、deadline miss、observability・tuning コスト、長期運用コストを同じ workload と deployment 条件で測定すべきです。collector や compiler version が変われば、その測定の有効性も再確認する必要があります。

中間結論

3.5節の結論は「現代の GC は十分速いので Rust の利点が消える」でも「GC は pause があるためシステムプログラミングに不適切だ」でもありません。現在の collector はそれぞれ異なる latency・throughput・memory 特性を持ち、Java ZGC のように非常に短い pause を明示的に目標とする実装もあります。同時に Go と .NET の文書が示すように、低 latency を得る過程には CPU、heap headroom、collection frequency、fragmentation といった別のコストと失敗条件があります。

Rust には tracing GC なしで、sound な Safe Rust boundary 内の特定 memory-safety エラーを静的に予防し、resource lifetime を明示的に構造化できる強みがあります。GC ベース環境は managed object graph の回収を自動化し、複雑な共有・循環構造の lifetime 管理を単純化できます。どちらが適切かは、必要な memory-safety boundary、latency と deadline、allocation pattern、live set、memory ceiling、native/FFI の比率、非メモリ resource lifetime、開発・運用能力、総 lifecycle costによって異なります。これらの条件を明示しない「GC は遅い」と「GC があるので lifetime 問題は解決する」という二つの一般化はいずれも、現在の根拠より強い主張です。

3.6 言説分析：「実用性」と「責任」の再定義

3.1–3.5節では、Rust の概念的先例、Safe Rust と unsafe の保証境界、変更戦略、Ada/SPARK、tracing GC を技術的に比較しました。3.6節の問いは、その技術的結論をもう一度証明することではなく、条件付きの技術命題が公開言説の中で実用性、責任、優越性、開発者の地位に関する判断へ変換されるとき、どのような追加の推論段階が持ち込まれるかです。これは研究質問5（RQ5）の問題です。

この分析では、まず資料の層を分けます。Rust Project の公式文書と Rust Reference は、プロジェクトが表明する目標と言語保証の境界を確認する一次資料として使用します。Reddit、Rust Users Forum、ブログなどの公開投稿は、特定の論証形式が実際に現れ得ることを示す定性的事例としてのみ使用します。現在本書が用いる公開事例は確率標本でも、事前定義された代表 corpus でもないため、本節は「Rust コミュニティは概して」「Rust 利用者の大半は」といった頻度・代表性の命題を導きません。⁵⁸

Rust Project 自身の公開説明も、この区別を確認する助けになります。現在の公式サイトは、誰もが “reliable and efficient software” を構築できるようにする言語として Rust を説明し、公式リポジトリも performance、reliability、productivity をそれぞれの利点として掲げています。したがって生産性、ツール、アクセスしやすさは Rust の公式な価値提案に含まれますが、それだけから Rust が各概念を最初に発明したことや、あらゆる領域で優越することは導かれません。⁵⁹

3.6.1 「実用的革新」の言説的機能

3.1節の歴史分析と「Rust は実用的革新である」という評価は、互いに矛盾する必要はありません。概念的新規性（conceptual novelty）と、既存概念の統合・デフォルト化・ツール化・普及（engineering integration and adoption）は異なる評価軸だからです。ownership、RAII、affine/linear 系のアイデア、静的検証に先例があっても、言語・コンパイラ・Cargo・診断・ライブラリエコシステムを一つの開発体験へ統合した工学的成果は別に評価できます。

実際の公開議論にも、現代的なツールと抽象化によって、以前は強い C/C++ 知識を必要とした領域への参入障壁を Rust が下げたという意味で “democratization” という表現を使う例があります。同じ議論には、エコシステムの成熟度、チームの熟練度、変更の激しいドメインでは別の言語のほうが生産的になり得るという反論も存在します。この事例が立証するのは、そのような論証形式と反論が公開言説に存在することであり、どちらがコミュニティの多数意見かという頻度ではありません。⁵⁸

したがって「実用的革新」は、次の問いを分けて扱う必要があります。

問い	必要な根拠	「実用的革新」が答えられる範囲
この概念を Rust が最初に作ったか？	言語・論文・標準・実装の歴史	直接は答えられない
先行概念を使いやすく統合したか？	言語設計、ツール、DX、エコシステム、採用事例	直接評価できる
特定の組織・製品でより実用的か？	workload、人員、性能、assurance、移行・運用コスト	条件付きで評価できる
あらゆるシステムでより優越するか？	主張する全適用範囲を支える比較根拠	限定された事例だけでは答えられない

「概念的に新しいか」という問いに「広く使われ実用的だ」とだけ答え、評価基準が変わった事実を隠すなら、論点は移動しています。反対に、「概念的発明とは別に、統合・普及という工学的革新がある」と基準を明示するなら、それは論点回避ではなく別の軸における正当な主張です。この区別は Rust に有利な方向にも不利な方向にも同じように適用すべきです。

3.6.2 「責任」の帰属：メモリリークと `unsafe` の議論方法

責任を分析するには、まず言語が保証しないこととシステムにとって重要でないことを分けなければなりません。Rust Reference は memory/resource leak や destructor が実行されないことを unsafe に分類していません。標準ライブラリの mem::forget も safe 関数であり、その文書は Rust の safety guarantee が destructor の実行自体を保証しないことを理由として説明しています。したがって「leak は Safe Rust の memory-safety guarantee 違反ではない」という文は、公式の保証境界に一致します。⁶⁰

しかし、そこから「したがって leak は重要ではない」または「したがって全責任はアプリケーション開発者にある」とは導けません。長時間稼働するサービスでは、retained object や resource leak が OOM、file-descriptor exhaustion、latency 増加、再起動、可用性低下を引き起こし得ます。これらは memory-safety の定義とは別の運用上の性質です。公開 Rust 議論にも、safe code が leak し得るという説明と、それが実サービスでは深刻な資源問題になり得るという議論が同時にあります。これは guarantee boundary と operational severity が異なる軸であることを示す定性的事例です。⁵⁸

unsafe を単に「コンパイラ検査を切るコード」や「問題が起きたとき責任を作成者へ隔離する印」と説明するのも不正確です。Rust Reference は unsafe を、安全であることを証明する義務（proof obligation）を生成または解消（create or discharge）するキーワードと説明します。unsafe fn・unsafe trait などは別の場所で守る必要のある追加 safety condition を定義し、unsafe {}・unsafe impl などは関連する safety condition が満たされたとプログラマが宣言する側にあります。より重要なのは soundness 境界です。Reference は、内部の unsafe 実装を通じて safe client が UB を引き起こせる abstraction を unsound と定義します。⁶⁰

したがって、ライブラリ内部の unsafe 欠陥については次の層を分ける必要があります。

層	問うべきこと
言語・コンパイラ保証	Safe Rust の静的規則が約束した範囲を外れたのか、それとも外部 proof obligation が誤って解消されたのか？
unsafe abstraction の soundness	safe caller が文書化されていない追加条件を破ることなく UB を引き起こせるか？
ライブラリ・API責任	invariant、safety contract、review、test は適切だったか？
アプリケーション・運用責任	dependency 管理、隔離、観測、資源上限、更新、事故対応は適切だったか？
組織・lifecycle責任	危険な境界の所有者、audit 周期、toolchain と supply chain の検証が定義されているか？

この枠組みでは、「Safe Rust の言語規則自体が直接失敗したわけではない」と「safe API を提供するライブラリに soundness 欠陥がある」は同時に真になり得ます。公開された unsafe バグの議論でも、UB が実際に現れる unsafe operation と、その operation が依存する invariant を壊した safe code が離れて存在し得る事例について責任の位置が議論されています。これは責任が一つの unsafe ブロックへ単純に隔離されないことを示す定性的事例であり、その構造の頻度を立証する資料ではありません。⁵⁸ 反対に、一つの unsafe 欠陥から「Rust 全体の memory-safety model は無意味だ」と一般化することも同じ理由で過剰です。責任は一語で移転されるのではなく、保証境界と契約境界に沿って分解されなければなりません。

3.6.3 条件付きの工学的利点と普遍的な地位判断の分離

RQ5 で最も重要な境界は、技術命題から人や技術全体の地位に関する命題へ移る段階です。次の最初の三段階は、それぞれ十分な根拠があれば工学的に成立し得ます。

sound な Safe Rust 境界では safe client だけで undefined behavior を引き起こすことはできず、data race は Rust が undefined behavior と分類する行為に含まれる。⁶⁰
特定のシステムでは、その欠陥群のリスクが大きく、Rust の導入コストは許容できる。
したがって、そのシステムでは Rust が強い採用候補、またはより良い選択になり得る。

ここから直ちに「したがって Rust はあらゆるシステムで優越する」「他の言語は時代遅れだ」「別の選択をする開発者は能力・資格・責任感に欠ける」へ進むには、まったく別の証拠と規範的前提が必要です。特定の欠陥群を防ぐ言語特性は、workload、既存資産、hard-real-time 要件、エコシステム、要員、移行リスク、lifecycle cost を自動的に決めず、条件付きの技術選択は開発者の知性や道徳的価値を測る指標でもありません。

この基準は対称的です。borrow checker のコスト、unsafe 境界の欠陥、エコシステムの不足を根拠に「Rust はどのシステムにも不適切だ」と結論したり、Rust 利用者の能力を低く評価したりすることも、同じ種類の過剰一般化です。本書が分析する対象は言語集団の優劣ではなく、条件付き技術命題が適用範囲を失い、普遍的・社会的な地位命題へ変換される推論過程です。

大規模・極限環境では、この区別は修辞上の礼儀以上の問題です。実際の事故対応では defect locus、proof obligation、API contract、dependency owner、deployment・rollback、resource ceiling、audit、incident ownership を具体的に指定する必要があります。「言語が保証しない」という言葉は運用責任を消さず、「開発者の責任だ」という言葉も、どの検証・観測・復旧手順が必要かを定める代わりにはなりません。責任の正確な分解は、安全性だけでなく信頼性・保守性・長期 lifecycle cost の一部です。

中間結論

3.6節の結論は Rust の実用性を否定することでも、すべての unsafe 問題を言語自体の失敗へ帰すことでもありません。「実用的革新」は概念的発明とは別の統合・普及の成果を説明する有効な評価軸になり得ます。memory/resource leak が Rust の memory-safety guarantee 外にあるという説明も技術的に妥当です。unsafe も外部 proof obligation を明示する重要な設計装置です。

同時に、この三つの事実はそれぞれ概念的独創性の証明、運用上の無害性の証明、システム責任の除去を意味しません。公式文書と公開言説の事例を区別し、定性的事例から頻度を推論せず、技術的保証から普遍的優越性や開発者の地位判断へ進むために必要な追加前提を明示することが RQ5 の分析基準です。ここで確認した公開事例は、このような論証形式が実際に存在することを示しますが、Rust Project 全体や Rust 利用者集団の代表的態度を立証しません。⁵⁸

3.7 結論：性能、安全性、生産性のトレードオフ

第3章は、Rust と代替案を一つの「性能・安全性・生産性」の三角形上に順番に配置する結論では閉じられません。前節までの分析が示したのは、どの欠陥を減らすのか、どの保証をどの境界まで要求するのか、その保証を静的規則・動的検査・自動回収・形式証明のどこで得るのか、そしてその選択が runtime・検証・移行・運用コストをどこへ移すのかを同時に見る必要があるということです。

したがって、言語とエコシステムを比較するときは、少なくとも次の六つの軸を分離する必要があります。

欠陥モデルと保証範囲： use-after-free、double-free、data race、一般的な race condition、論理エラー、resource exhaustion、availability failure のうち何を予防・検出・緩和するのか。
保証メカニズム： 言語・型システムによる静的 prevention、run-time check と exception、tracing GC、contract と formal proof、sanitizer・static analysis・fuzzing のような検出手段をどう組み合わせるのか。
実行コストと資源特性： throughput、tail latency、worst-case timing、allocator/GC CPU、memory headroom、code size、startup、synchronization、resource-release のコストが対象 workload でどう現れるのか。
assurance と real-time 要件： どの属性を proof する必要があり、どの assumption と外部 code を信頼し、hard deadline と failure containment をどう立証するのか。
変更戦略と既存資産： 維持・hardening、同じ言語での modernization、新規 component 導入、選択的置換、全面 rewrite のうち、どの範囲の変更が必要なのか。
組織・lifecycle コスト： 学習、code review、build/test、proof と CI、dependency と toolchain、observability、deploy・rollback、採用、長期保守を組織が維持できるのか。

この軸で見ると、各アプローチの違いは単一スコアではなく、異なる保証とコストの配置として現れます。

アプローチ	強みが現れる条件	残る主な境界とコスト
C/C++	既存資産・エコシステム・低水準制御が重要で、RAII、smart pointer、guideline、static analysis、sanitizer、hardening を段階的に導入できるとき	言語がすべての memory-unsafe access を既定で静的に遮断するわけではなく、規則とツールの適用範囲・完全性、legacy boundary、検証 discipline を別途管理する必要がある
Go、Java、C# などの tracing-GC 環境	managed object graph の自動回収と、複雑な共有・循環構造で明示的 lifetime 管理の負担を減らすことが workload にとって重要なとき	collector ごとの latency・CPU・memory trade-off、retained object、native/unsafe boundary、非メモリ資源の明示的 release、hard-real-time の証明は別問題として残る
Ada	strong typing、language-defined run-time check、exception、tasking abstraction、明示的 control flow が要求されるとき	check suppression、unchecked operation、external representation などの境界があり、検出はそれ自体で recovery や availability を保証せず、run-time check の timing cost も評価する必要がある
SPARK	制限された言語 subset と contract・proof effort を受け入れ、AoRTE を越えて明示した integrity property と functional requirement まで proof 範囲を拡張する価値が大きいとき	assurance level、code scope、specification completeness、`Storage_Error`、non-SPARK・external code、assumption、proof/CI 維持コストによって保証範囲が制限される
Rust	tracing GC なしの低水準制御と、sound な Safe Rust 境界内の memory-safety・data-race prevention を同時に必要とし、ownership/lifetime 関係を型と interface に構造化できるとき	`unsafe`、FFI、library/compiler correctness、一般 race condition、logic・availability・resource bound は別問題であり、allocator、`Drop`、refcount、atomic、locking などの runtime cost と学習・compile・統合コストも残る

この表は「どの言語が最も安全か、最も速いか」という順位を作るためのものではありません。3.4節が示したように、Safe Rust の既定 memory-safety invariant と SPARK の明示的 contract proof は異なる種類の保証であり、Gold/Platinum のような SPARK の assurance objective も specification と assumption の範囲を越えて自動的に拡張されません。3.5節が示したように、tracing GC は managed memory の回収を自動化する一方で collector ごとの資源・latency 特性を持ちますが、そのコストを単純に「機械時間」と呼ぶことはできず、Rust のコストも単純に「開発者時間」へ還元できません。

言語選択と変更戦略は同じ決定ではない

3.3節の重要な結論は、目標言語の保証が強いという事実と、既存システムをどこまで変更すべきかは別の問題だという点です。C/C++ システムでは、特定の欠陥を減らすために、維持・hardening、modernization、新規 Rust component、高リスク module の選択的置換、bounded rewrite、広範な rewrite を一つのシステム内で組み合わせられます。Rust の memory-safety の利点がすべての legacy code の全面 rewrite を自動的に正当化するわけではなく、migration risk があるという理由だけで新規・高リスク領域への Rust 導入を排除することもできません。

変更の純効果は、減少する欠陥リスクと新たに生じる移行リスクを同じ基準で比較して判断する必要があります。仕様復元、test oracle、FFI/ABI、data・protocol compatibility、dual-language build、rollout・rollback、performance regression、運用成熟度、組織能力を言語保証とともに評価しなければなりません。この観点では、「Rust を使うか」よりも「どのリスク境界をどの戦略で変えるか」のほうが正確な問いです。

安全性は単一軸ではなく、技術選択は地位判断ではない

3.2節と3.4節の比較では、memory safety、security、functional correctness、concurrency correctness、availability、resilience、real-time assurance は相互に関連し得ても同じ属性ではありませんでした。ある言語が一つの次元で強い保証を提供しても、他の次元の保証が自動的についてくるわけではありません。したがって「compile できれば安全だ」「exception があるから recovery が保証される」「proof したからシステム全体が正しい」「GC があるから lifetime 問題は解決する」といった文は、いずれも適用条件と境界を確認する必要があります。

3.6節の言説分析も同じ原則を技術選択へ適用します。条件付きの工学的利点は、該当条件とコストについて十分な根拠があれば強い採用判断を正当化できますが、それだけで全システムにおける普遍的優越性や、異なる選択をした開発者の能力・資格・責任感についての判断にはなりません。反対方向の過度な一般化にも同じ証拠基準を適用する必要があります。

大規模・極限環境での最終評価基準

大規模・長時間運用・mission-critical・hard-real-time 環境では、平均 benchmark や言語の代表的特徴一つだけでは結論として不十分です。

少なくとも、対象欠陥の発生率と severity、tail latency と worst-case timing、throughput、CPU budget、code size と storage budget、peak memory と resource ceiling、energy/power budget、OOM・thrashing、deadline miss、failure containment と recovery、startup、build/test と proof latency、CI 資源、dependency・supply-chain・toolchain 検証、observability、rollout・rollback、incident response、人員、長期 lifecycle costを実際の workload と deploy 条件で合わせて測定または立証する必要があります。

compiler、collector、proof tool、dependency、hardware、workload が変われば、以前の結果の有効性も再確認する必要があります。

章の結論

第3章の結論は、特定の言語を一つの総合スコアで順位付けすることではありません。Rust は sound な Safe Rust 境界で特定の UB と data race を既定で遮断しながら、tracing GC なしで低水準制御を維持できる重要な工学的選択肢です。C/C++ は既存資産と低水準制御を維持しつつ段階的 hardening・modernization を適用できます。tracing-GC 環境は managed memory と unreachable cycle の回収を自動化し、複雑な object graph の lifetime 管理負担を減らせます。Ada は strong typing、language-defined run-time check、exception といった防御層を提供し、SPARK は制限された subset と明示的 contract を基盤に、AoRTE を越えて integrity property と functional requirement まで proof 範囲を拡張できます。

どの選択がより適切かは、欠陥モデル、必要な assurance level と境界、workload と real-time 制約、resource ceiling、既存資産と変更範囲、検証資産、interop、deploy・recovery 戦略、エコシステム、組織能力、総 lifecycle costによって異なります。これらの条件を明示し、同じ証拠基準で代替案を比較することが、この章でいう工学的結論です。

4. 所有権モデルの再評価と設計思想

第4章では、Rust の ownership を、一つの概念がどこで「最初に発明されたか」という単一起源の物語として扱いません。まず4.1節で、C++ の RAII、smart pointer、move semantics と Rust ownership の間にある文書で確認できる直接的影響、歴史的先例、概念的類似性、標準化の年代を分離します。4.2節では、これらの先行技法と比較しながら、Rust が ownership・move・borrowing の規則を型システムとコンパイラ検査のどこに配置しているかを分析します。最後に4.3節では、Ada/SPARK の contract ベースの検証と比較し、異なる保証メカニズムが特定のデータ構造や workload でどのような制約とコストを生むかを検討します。歴史的な影響関係は、現在の保証強度、性能、安全性、あるいは特定プロジェクトへの適合性をそれ自体で証明するものではありません。

4.1 Rust の所有権と C++ RAII・スマートポインタの歴史的関係

3.1節で用いた歴史的帰属の基準を、この節でもそのまま適用します。二つの技術が似ているという事実は概念的類似性を示せますが、それだけで直接の系譜を証明することはできません。一方、公式資料が特定の影響を明示している場合、その範囲では文書で確認できる直接的影響と呼べます。Rust Reference は C++ の references、RAII、smart pointers、move semantics を Rust の設計への影響として挙げると同時に、ML Kit と Cyclone の region-based memory management も別の影響として列挙しています。³³ したがって、この節の問いは「ownership という一般概念を C++ が最初に発明したのか」ではなく、C++ の資源管理技法のうち何が Rust への影響として確認でき、両者の規則と強制位置がどこで同じでどこで異なるのかです。

C の手動メモリ管理は問題空間の背景であり、系譜の証拠ではない

C の malloc() と free() は、動的メモリの割り当てと解放をプログラマが明示的に制御できるようにします。lifetime の対応を誤ると memory leak、double free、use-after-free などのエラーが生じ得ます。この事実は RAII、smart pointer、ownership system などが扱う問題空間を説明しますが、ある技法が別の技法の直接の祖先であることをそれ自体で証明しません。

memory leak： もはや必要でない allocation が解放されずに残り、メモリ使用量や長期運用時の resource pressure を増加させる可能性があります。
double free： 同じ allocation を二度解放し、allocator state を破壊したり undefined behavior を引き起こしたりする可能性があります。
use-after-free： lifetime が終了した storage を再び使用し、memory corruption や security vulnerability につながる可能性があります。

これら三つのエラーは、同じ「手動管理」という大きな分類の中でも原因と保証境界が異なります。ある言語機能がその一つを減らしても、logical correctness、availability、resource bound まで自動的に保証されるわけではありません。この区別は3.2節と3.7節で定めた安全性の境界をそのまま引き継ぎます。

C++ RAII：資源解放を scope と object lifetime に結び付ける先行技法

C++ の RAII は、資源の取得と解放を object lifetime に結び付ける技法です。C++ Core Guidelines は resource handle と RAII による自動資源管理を推奨し、資源の解放責任を持つ entity を owner として扱います。Rust Book も、値が scope を離れると drop によって資源を整理する Rust の動作を説明し、C++ の RAII を明示的な比較対象にしています。³³ したがって、RAII が Rust の scope/object-lifetime に結合された resource cleanup と歴史的・概念的に関連するという主張には根拠があります。

しかし、この関連を「ownership という一般概念が C++ で最初に確立された」という主張に拡張する根拠は、ここでは得られていません。Rust ownership は scope 終了時の cleanup に加え、move 後に以前の binding を使用することへの制限、shared/mutable borrowing の規則、そしてそれらの規則に対する compiler checking を組み合わせています。Rust Reference が C++ 以外に ML Kit と Cyclone も影響として挙げていることも、Rust の memory/lifetime 設計を単一の C++ 系譜へ還元すべきでない境界になります。³³

スマートポインタの標準化年代と意味論的比較を分けて見る

「C++11 でスマートポインタが初めて導入された」という表現も正確ではありません。C++ 標準ライブラリには C++11 より前から auto_ptr が存在し、WG21 資料は unique_ptr を追加して auto_ptr を deprecated とする方向が2007年に受け入れられたことを記録しています。2011年の C++ 標準化資料には、unique_ptr と shared_ptr がすでに C++11 時代の標準ライブラリ設計に含まれています。⁶¹ したがって、特定の smart pointer の存在時期と標準化過程は、Rust への直接的影響の主張とは分けて扱います。

現代 C++ の代表的な二つの ownership 表現は、Rust との意味論的比較に有用です。

std::unique_ptr： exclusive ownership を表し、copy ではなく move によって ownership を移転します。C++ の move construction 後も source unique_ptr はオブジェクトとして存在しますが、もはや pointer を所有しません。一方 Rust の non-Copy 値では、値全体が move された後、以前の binding の使用が静的に拒否されます。双方とも ownership transfer を copy と区別しますが、moved-from state の規則まで同一ではなく、この類似性だけで unique_ptr を Rust ownership 全体の直接的原型とみなすことはできません。⁶²
std::shared_ptr： reference counting によって shared ownership を表します。Rust の Rc<T> と Arc<T> も reference-counted shared ownership を提供するため、比較対象として有用です。しかし、この節で用いる資料は shared_ptr が Rc<T> や Arc<T> の直接の「基盤」であるという一対一の系譜を立証しません。⁶²

重要な違いは、これらの道具が存在するかどうかだけでなく、規則がどこに適用され、既定の境界がどこにあるかです。C++ では RAII と standard smart pointer を強く利用しながら、raw pointer、manual allocation、custom lifetime protocol も併用できます。Rust では move と borrowing の規則が Safe Rust の既定の値 semantics に組み込まれ、compiler は use-after-move や衝突する shared/mutable borrow のようなパターンを静的に拒否します。その境界の外側では unsafe が別の safety obligation を要求します。この差は「一方は規律、他方は安全」という単純な区分よりも、どの規則が既定で強制され、どの escape hatch と proof obligation が残るかとして比較すべきです。

中間結論

C++ の RAII、smart pointers、move semantics が Rust に影響したことは Rust Reference で直接確認できます。同時に、Rust の ownership/lifetime 設計には C++ だけでなく ML Kit や Cyclone などの影響も公式に記録されています。したがって、「C++ と Rust の間に歴史的影響がある」という命題と、「ownership という概念自体が C++ に起源を持つ」という命題は同じではありません。unique_ptr と Rust move/ownership、shared_ptr と Rc/Arc の比較は設計差を説明する上で有用ですが、その類似性だけから一対一の系譜を推論すべきではありません。

この歴史的整理は、現在の工学的優劣を決めるものでもありません。どちらのモデルがより適するかは、memory-safety guarantee、unsafe/FFI boundary、concurrency model、allocator と reference-counting cost、latency と resource ceiling、existing codebase、migration risk、verification assets、lifecycle cost を別々に評価する必要があります。次の4.2節では、この歴史的関係を前提としつつ、Rust の実際の違いを概念を最初に発明したかどうかではなく、規則の構成と compiler enforcement の位置から分析します。

4.2 Rust 所有権規則の強制位置と保証境界

4.1節で歴史的影響と概念的類似性を分けた以上、ここで問うべきなのは「C++ では選択で、Rust では強制なのか」という二分法ではありません。より正確な問いは、どの property をどの層で検査し、その検査がどの前提と境界の下で保証を与え、何が依然として library・developer・運用環境の責任として残るのかです。

ownership・move・borrowing の強制位置は一つではない

Rust Book は ownership を Rust program の memory 管理を規律する規則の集合として説明し、compiler がそれらを検査して違反する program の compile を拒否すると説明しています。non-Copy 値の assignment や function への受け渡しでは ownership が move されることがあり、値全体が move された後に以前の binding を再び使おうとすると静的エラーになります。reference と borrowing には別の規則が適用され、reference validity と衝突する shared/mutable borrow の関係が compile 時に検査されます。⁶³

しかし、これを「Rust の ownership 関連規則はすべて borrow checker が compile 時に強制する」と広げるのも不正確です。たとえば RefCell<T> は safe API の背後で interior mutability を提供し、borrowing rule の一部を実行時に検査します。borrow() と borrow_mut() は衝突する borrow に対して panic しますが、try_borrow() と try_borrow_mut() は同じ衝突を Result のエラーとして返します。したがって run-time checking 自体と、違反を panic にする個々の API は区別する必要があります。Rust 内でも同じ設計目的を static type/borrow checking、library abstraction、run-time check が異なる位置で担えます。⁶⁴

属性またはメカニズム	主な強制・検査位置	残る境界
ownership と move	type system と compiler check	logical correctness、resource policy、外部 system state は別問題
shared/mutable reference	borrow checking と reference validity rule	raw pointer・`UnsafeCell`・unsafe abstraction の条件は別に残る
`RefCell<T>` borrowing	safe API 内部の run-time check	`borrow()`/`borrow_mut()` の衝突は panic、`try_borrow()`/`try_borrow_mut()` はエラーを返す。recovery と availability は別問題
`unsafe` contract/operation	compiler が `unsafe` の使用位置と形式を制限し、compiler が検証できない safety condition は作者が責任を持って満たす	UB 防止と safe-client soundness obligation が残る
`Result` 処理と panic policy	library API と application control flow	recovery 可能性、failure isolation、availability は application/operation 設計の問題

unsafe は安全検査をすべて無効にするモードではない

Rust Reference は unsafe を、compiler が検証できない追加の safety condition を定義する、またはその条件を満たしたと作者が主張する位置として説明します。unsafe block は raw pointer の dereference や unsafe function の呼び出しなど特定の operation を許可しますが、Rust Book が明記するように borrow checker やその他の通常の安全検査を無効にはしません。また Rust Reference の undefined-behavior rule は unsafe code の中でもそのまま適用されます。⁶³

したがって unsafe は「Rust の規則の外にある自由領域」ではなく、proof obligation の位置が変わる境界として見る方が正確です。ここで Rust Reference が用いる proof obligation は、SPARK のような machine-checked formal proof を要求するという意味ではありません。

Reference は run-time check や data-structure invariant など、複数の方法で obligation を discharge できると説明しています。本節ではこれを、compiler が検証できない safety condition を根拠を持って確認し、維持する責任という意味で用います。unsafe implementation が必要な invariant を維持し、safe client が UB を引き起こせない API を構成できれば、その abstraction は safe interface を提供できます。

逆に safe API だけを使う client が UB に到達できるなら、3.2節と3.6節で見た意味で abstraction の soundness が壊れています。責任は compiler から developer へ丸ごと移るのではなく、compiler check・unsafe contract・library soundness・application invariant に分かれます。⁶³

C++ も「developer の選択」だけで動くわけではない

C++ との差も「選択的 pattern 対強制的 compiler rule」だけで説明すると広すぎます。C++ の object lifetime と destructor semantics は言語規則であり、std::unique_ptr を選択すれば copy 制限や ownership-transfer interface のような制約は type system と compiler が実際に強制します。C++ Core Guidelines も ownership の表現に unique_ptr と shared_ptr を使うことを推奨し、unique_ptr parameter は ownership transfer を文書化するだけでなく enforce すると述べています。⁶⁵

同時に C++ は raw pointer、明示的な new/delete、custom lifetime protocol を利用でき、Core Guidelines の一部は compiler 自体ではなく guideline checker や static-analysis tooling による検査を前提とします。したがって比較すべきなのは「C++ には強制がなく Rust にはある」ではなく、ownership と aliasing の制約が既定で適用される範囲、opt-in type の役割、escape hatch の広さ、違反をどの tool がどの時点で検出するかです。Rust の Safe Rust boundary は move と reference borrowing rule を通常の言語利用へ広く適用する一方、C++ の RAII と ownership-aware type も強い言語・library mechanism ですが、raw/custom boundary がより広く開かれています。⁶⁵

静的検査の保守性と safe abstraction の役割

静的検査が強いことと、あらゆる memory-safe implementation を compiler が直接受理することも分けて考える必要があります。Rust Reference は type system を dynamic safety requirement の保守的近似として説明します。公式 Rust 文書の split_at_mut 例では、二つの slice が重ならないという invariant を人間は確認できますが、単純に二つの mutable borrow として書いた形から borrow checker がその disjointness を直接認識することはできません。標準的な解法は、小さな unsafe implementation で raw pointer と長さ条件を用いて invariant を確立し、その上に safe API を提供することです。⁶⁴

したがって compile rejection だけで「意図した operation が実際に unsafe である」とは言えません。逆に、人間が安全だと信じていることだけを理由に compiler rejection が誤りだとも言えません。工学的に重要なのは、compiler が直接証明できる表現、run-time check へ移せる条件、unsafe abstraction 内で明示的に立証すべき invariantを区別することです。この区別は複雑な graph、intrusive structure、FFI、device memory のように lifetime と aliasing が複雑な領域で特に重要です。

unwrap() は ownership 保証に関する心理的推論の証拠ではない

以前の記述は compiler の安全保証を信頼すると防御的 coding が減り unwrap() 利用が増える可能性があると推論していましたが、本節にはその developer behavior の因果関係を裏付ける資料がありません。その主張は削除します。Result::unwrap() について標準 library 文書が直接述べる内容はより限定的です。値が Err なら panic し、一般には ? や明示的 error handling などの代替を推奨しています。⁶⁴

unwrap() を使うかどうかは memory-safety guarantee とは別のerror-handling と failure-policy の選択です。ある invariant により Err は発生しないはずだと判断する code もあり得ますが、その仮定が誤れば panic します。その panic が unwind するか abort するか、service が隔離・再起動されるか、failure が availability にどう影響するかは3.2節で区別した別問題です。ownership や borrow checker がこれらの運用 policy を決めるわけではありません。

責任は「移転」より階層化して見る方が正確である

以上を踏まえると、「Rust は安全性の責任を developer から compiler へ移す」という表現も広すぎます。compiler と type system は指定された move・borrow・reference rule を自動的に検査します。unsafe code 作者は compiler が検証できない safety condition を満たし、library 作者は safe API の soundness を保つ必要があります。application は domain invariant、Result と panic policy、resource exhaustion、timeout、recovery を扱い、deploy・operation では dependency、FFI、observability、failure containment、rollback など別の責任が残ります。

大規模・長期運用・極限環境では、これらの層をまとめて「compile できれば安全」と評価すべきではありません。少なくとも unsafe/FFI surface、dependency と compiler/library soundness assumption、run-time borrow check や reference counting などの実行コスト、panic と recovery policy、resource ceiling、tail latency、build/verification cost を実際の workload とともに評価する必要があります。これは3.7節の多軸評価基準を ownership enforcement に適用したものです。

中間結論

Rust の工学的特徴は「既存のアイデアを compiler が強制した」という一文より具体的に説明できます。Safe Rust では ownership・move・borrowing の重要な制約が通常の言語利用と type checking に広く結び付けられ、一部の条件は RefCell のような safe abstraction で run-time check へ移り、compiler が直接検証できない低水準 invariant は unsafe の明示的な proof obligation と sound abstraction の境界になります。C++ も RAII と ownership-aware type を通じて compiler が実際に強制する規則を持ちますが、raw/custom lifetime boundary と guideline/tool enforcement の範囲が異なります。

したがって比較の核心は「developer か compiler か」または「選択か強制か」ではなく、どの property がどこでどの条件の下に enforce され、その外側の proof・logic・failure・resource・operation の責任がどこに残るかです。この基準なら Rust の memory-safety 上の利点を認めつつ、compiler enforcement を functional correctness、panic recovery、availability、system 全体の安全性へ拡張せずに済みます。次の4.3節では、この保証 mechanism の違いを Ada/SPARK の contract と proof の観点まで広げて比較します。

4.3 Rust・Ada・SPARK：所有権、アクセス、契約、証明の境界

4.2節で見たように、保証 mechanism を「compiler が自動的に防ぐか」と「developer が contract を書くか」という二つの箱に分けることはできません。本節では Rust の ownership/borrowing、Ada の access type と language-defined run-time check、SPARK の Memory Ownership Policy と contract/proof を、表現可能なデータ構造、aliasing・mutation 制約、検査位置、proof scope、escape boundary、実行コストという共通軸で比較します。4.2節で整理したとおり Rust の unsafe proof obligation は machine-checked formal proof と同義ではなく、SPARK の proof も分析対象、contract、assumption が閉じた範囲で解釈する必要があります。

双方向連結リストはこの違いを示す有用な事例ですが、まず比較単位を狭める必要があります。標準 container のように node を外部へ公開しないカプセル化された双方向連結リスト、複数 object が node handle を長期間共有する共有 graph 型構造、node 自体が別 object に埋め込まれる intrusive structure は異なる問題です。一つのコード例をすべての代表として扱うと、言語の表現力、library 設計、安全境界、性能コストが混同されます。

Rust：循環構造そのものを禁止するのではなく、安全な表現と所有関係を区別する

Rust 標準ライブラリは安全な public API を持つ双方向連結リスト std::collections::LinkedList<T> を提供します。公式文書はこれを owned node を持つ doubly-linked list と説明し、多くの一般的 workload では Vec や VecDeque の方が高速で、メモリ効率と CPU cache 利用も良いと明記しています。⁶⁶ したがって「Rust では双方向連結リストを安全に実装できず、必ず Rc<RefCell<...>> を使わなければならない」という主張は正しくありません。

node identity と外部共有 handle を直接公開するデータ構造では問題が変わります。Rc<T> は single-threaded shared ownership を提供し、RefCell<T> は borrow rule の検査を run time へ移せます。また back-reference を Weak<T> にして strong reference-count cycle を避ける設計も可能です。ただしこれは可能な library-level 表現の一つであり、Rust の双方向連結リストに対する唯一の答えではありません。arena/index handle、generational handle、カプセル化された container API、または必要な invariant を狭い unsafe implementation 内で維持する方式なども選べます。

Rust が language level で reference cycle を禁止すると表現するのも不正確です。Rust Book は Rc<T> と RefCell<T> によって strong-reference cycle を作成でき、その結果 value が drop されず memory leak が生じ得ると説明しています。Weak<T> は ownership を表さない reference であり、この ownership cycle を切る手段です。⁶⁶ 3.2節で区別したとおり、この leak は memory-safety UB ではなく resource/availability の問題です。

Ada：access type は循環・共有表現を許すが、その表現力は自動的な memory-safety proof ではない

通常の Ada access type は node の Prev と Next が別の node を指す構造を直接表現できます。language-defined check は null access の dereference や複数の range/overflow 条件などで実行時エラーを検出し、例外を発生させられます。しかし3.4節で確認したように、unchecked operation、explicit deallocation、外部 interface、lifetime protocol には別の proof または review obligation が残ります。したがって構造を直接表現できることと、dangling access、double deallocation、leak、protocol error が自動的に存在しないことは同じ命題ではありません。⁵²

Ada の contract も別の層です。precondition、postcondition、type invariant などは run-time check 用に構成でき、SPARK analysis の specification としても利用できます。そのため「Ada/SPARK は contract を書く代わりに pointer を自由に許す」という一つの model にまとめると、Ada language と SPARK subset の差を失います。

SPARK：Ada より pointer aliasing を強く制限し、この軸では Rust と比較可能な ownership discipline を持つ

SPARK User’s Guide は access value に Memory Ownership Policy を適用して arbitrary aliasing を制限すると明記しています。mutable memory には一時点で一つの read-write owner を許すか、複数の名前には read-only permission のみを許します。access object の代入によって ownership が move され、source の read/write permission が失われる場合があり、borrowing と observing も別の規則で扱われます。⁶⁷

この制約は pointer が指す memory を formal verification 可能な形で扱うためのものです。その重要な帰結として、SPARK は unrestricted Ada よりも循環・共有 pointer graph に対して制限的です。現在の SPARK User’s Guide は、cycle や sharing を含まない pointer-based data structure は実装・検証でき、典型的な singly linked list や tree は対応例ですが、doubly linked list と DAG は conventional pointer 形式では対応しないと説明しています。⁶⁷

ただし、この制限は SPARK の ownership model 内に direct cyclic/shared pointer graph を表現する場合の話であり、双方向連結リストという抽象データ構造そのものを SPARK で利用できないという意味ではありません。

SPARK Libraries は SPARK.Containers.Formal.Doubly_Linked_Lists と SPARK.Containers.Formal.Unbounded_Doubly_Linked_Lists を提供し、公式 guide は可能な場合 pointer-intensive structure よりこの種の container abstraction を使うことを推奨します。

同時に formal container の visible specification と contract は SPARK ですが、private part と implementation は SPARK 外です。そのため GNATprove は client code が contract に従って container を利用することは証明できますが、その client proof 自体が container implementation が specification を満たすことまで証明するわけではありません。⁶⁸

したがって従来の「Rust は restrictive by default、Ada/SPARK は permissive by default」という表は維持できません。unrestricted Ada の表現力と SPARK verification subset を分け、SPARK 自身も ownership と aliasing の制約を verification の前提としていることを明示する必要があります。doubly linked relation が必要な場合は、explicit pointer graph を直接 verification target として維持するか、SPARK formal container または wrapper を使うか、data structure や traversal algorithm を ownership policy に合わせて変更するか、implementation の一部を full Ada boundary の背後に置くかを区別する必要があります。最後の選択は SPARK proof の解法というより GNATprove の analysis scope を狭める境界であり、それぞれ proof scope、信頼する implementation、run-time/resource cost を変えます。⁶⁸

SPARK proof と Rust unsafe obligation は同じ種類の「証明」ではない

SPARK では GNATprove が flow analysis と proof を行い、3.4節で整理した Stone/Bronze/Silver/Gold/Platinum は異なる verification objective を表します。Silver の AoRTE は分析範囲内で Ada run-time error が存在しないことを proof する目標ですが、Storage_Error はその範囲外です。Gold/Platinum の integrity・functional property も、関連 contract が要求を十分に表現し、未分析 code と external assumption が正当化された範囲でのみ意味を持ちます。⁵³

Rust unsafe の proof obligation は compiler が検証できない safety condition を author が正当化し維持する責任を意味し、run-time check や data-structure invariant で discharge される場合もあります。これに対して SPARK proof は指定した verification condition を GNATprove で機械的に discharge する手続きを含みます。両 mechanism には「自動化境界の外側の条件を誰かが責任を持つ」という工学的共通点がありますが、evidence の形式、自動化水準、proof target、trusted assumption は異なります。

双方向連結リスト事例を同じ単位で比較する

比較軸	Safe Rust / Rust library	Ada	SPARK
一般的な双方向連結リスト利用	標準 `LinkedList<T>` の safe API を利用可能	library/container または access type で表現可能	SPARK Libraries の formal doubly-linked-list abstraction を利用可能。direct cyclic pointer graph は ownership-policy 制約を受ける
direct `Prev`/`Next` pointer graph	safe reference だけで長寿命の cyclic mutable graph を直接表現するのは難しく、別 abstraction が必要	通常の access type で直接表現可能	cycle/sharing を含む conventional pointer graph は Memory Ownership Policy により制限
shared ownership・back-reference	`Rc`/`RefCell`/`Weak` の組合せなどが可能。strong `Rc` cycle は leak し得る	access/controlled abstraction などの設計選択	ownership・borrowing・observing rule の範囲でのみ許可。arbitrary aliasing は制限
mutation の検査	native borrow は compile time、`RefCell` は run time	language check と application protocol に分散	flow/proof + ownership policy + 必要な run-time check
低水準 escape boundary	`unsafe` invariant と safe-abstraction soundness	unchecked operation、raw representation、deallocation/FFI boundary	`SPARK_Mode => Off`、external/non-SPARK code、assumption が proof boundary を形成
より広い correctness proof	general functional correctness には別の specification/tool が必要	contract を表現し run-time check 可能	明示した contract と assumption に対して AoRTE・integrity・functional proof を段階的に実施可能。formal-container client proof は private implementation 自体の specification 適合を証明しない

この表は、どの言語が単純に「より柔軟」または「より安全」かを一つの順位にするためのものではありません。同じ doubly linked list でも、標準 container を再利用するか、node identity を外部公開するか、intrusive layout が必要か、allocator を制御する必要があるか、worst-case latency と memory ceiling があるかによって cost structure は変わります。

大規模・極限環境では特にrepresentation cost を benchmark と resource bound で確認する必要があります。 Rust 標準文書は array-based Vec/VecDeque が一般に LinkedList より高速で、メモリ効率が高く、CPU cache をより活用すると直接説明しています。⁶⁶

SPARK formal container も単一の cost model ではありません。bounded definite formal container は dynamic allocation を使わない一方、unbounded indefinite formal container は element と内部 storage の拡張に dynamic allocation を使います。⁶⁸

したがって Rc の reference counting、RefCell の run-time borrow check、Ada で選択した access/allocation representation、SPARK の container variant または pointer representation、proof effort はそれぞれ異なる CPU・memory・latency・verification cost を生みます。どの cost が支配的かは workload、hardware、lifetime pattern、allocator policy、proof objective を測定せずに決められません。

中間結論

双方向連結リストの事例は「Rust ownership は複雑なデータ構造を阻み、Ada/SPARK は contract で自由に解決する」という結論を支持しません。Rust は safe API で双方向連結リストを提供でき、shared node graph を直接設計する場合は ownership・borrowing と runtime/unsafe abstraction の cost を明示する必要があります。Ada は cyclic pointer structure を直接表現しやすいものの、その表現力自体が lifetime safety や whole-correctness proof ではありません。SPARK は Ada subset として pointer aliasing に ownership restriction を課し conventional cyclic pointer graph を制限する一方、formal doubly-linked-list container abstraction も提供します。この場合も client proof と library implementation の specification 適合は異なる verification boundary です。⁶⁸

したがって比較の核心はどちらがより制限的かではなく、必要な data structure と property に対してどの representation を選び、どの error を language/type/runtime/proof が排除し、どの invariant と assumption を人が維持し、その選択が performance・resource・verification cost にどう影響するかです。この観点により、3.4節の Ada/SPARK assurance boundary と4.2節の Rust enforcement boundary を同じ工学的基準で結び付けられます。

第3部：エコシステムの現実と構造的コスト

第3部では、Rust エコシステムが直面する実際の課題と、その背後にある構造的コストを分析します。Rust の開発者体験、ゼロコスト抽象化の原則、実際の産業適用の制約を評価するとき、問題を性質に応じて二種類に分けて理解することが重要です。

成熟度の問題： ライブラリ不足、一部ツールの不安定性、文書不足などは、時間とコミュニティの努力が蓄積することで自然に解消・緩和され得ます。成長中の技術エコシステムが共通して経験する成熟度問題です。
設計に内在するトレードオフ： 実行時性能や GC なしのメモリ安全性といった中核価値を達成するため、学習容易性、コンパイル速度、特定パターン実装の柔軟性など別の価値を意図的に犠牲にした結果です。欠陥ではなく選択の問題なので、時間が経っても本質的には消えにくいものです。

以下の章では、この分析枠組みに基づき、Rust の各技術課題がどの性質に属するかを明確に区別して評価します。

5. 開発者体験の成果とコスト

第5章で問うのは、Rust が単純に「難しいか」「生産的か」ではありません。より正確な問いは、言語・コンパイラ・ライブラリ・ツールのどの機構がどのような開発体験を生み、個人の学習経験からチームや組織の生産性へ、どの範囲まで根拠を拡張できるのかです。

ここで開発者体験（DX）は一つの数値ではありません。学習とメンタルモデル形成、コンパイラ診断と edit-build-test のフィードバック、実装・リファクタリング・コードレビュー・デバッグ、ライブラリと依存関係の探索、build/CI 資源、運用・保守経験は別々の軸です。生産性も「コンパイルが速かったか」や「コード行数が少なかったか」だけには還元できず、タスク完了時間、手戻り、欠陥流出、レビューサイクル、training/mentoring コスト、長期保守コストを、どのワークロードと組織で測定したかを併記する必要があります。

5.1節では、借用検査器と所有権・ライフタイムの学習を事例として、この証拠境界を整理します。5.2節は技術選択を別の問題領域へ一般化する推論を、5.3～5.4節は async とエラー処理の具体的コストを、5.5～5.7節はライブラリ・ツールチェーン・ビルド環境を扱います。各節では、言語機構についての事実と、利用者・チーム・組織で観測された結果を分離します。

5.1 借用検査器、学習曲線、生産性：証拠の境界

「borrow checker が難しいため Rust の生産性は低い」という文は、異なる四種類の主張を一文にまとめています。

主張の層	確認すべきこと	適切な根拠
言語・コンパイラの動作	どの move・borrow・参照関係がコンパイル時に拒否されるか	Rust Reference、公式 Book、コンパイラ診断
learnability	どの概念を、どの学習者が難しいと感じたり誤解したりするか	学習実験、ユーザー研究、範囲を明示した survey
task-level productivity	特定タスクの実装・修正・デバッグ・レビュー時間がどう変わるか	比較可能な task、観察研究、実験
team/organization outcome	onboarding、日程、保守、欠陥・incident コストの純効果は何か	長期 project data、組織単位の比較、交絡要因分析

第一の層は言語文書から直接確認できますが、後の三層には別の経験的資料が必要です。特に、コンパイラがあるコードを拒否するという事実だけから、組織の日程やコストを推論することはできません。

技術的保証：所有権全体と借用検査器を同一視しない

Rust では所有権規則をコンパイラが検査します。代入や by-value の関数引数のように所有権を渡す文脈では、non-Copy 値は move され、Copy 値は copy され得ます。また、参照の有効性や shared/mutable borrow の衝突なども静的に制限します。しかし4.2節で区別したように、所有権に関係するすべての機構が借用検査器一か所で同じ方法により処理されるわけではありません。Rc<T> はライブラリ水準の shared ownership を提供し、RefCell<T> は一部の borrow 検査を実行時へ移し、unsafe は通常の検査を単に無効化する例外ではなく、コンパイラが直接検証できない safety condition に対する別個の obligation を生みます。⁶⁹

したがって、教育上の「one owner」という説明を「すべての値には常に binding が一つしか存在しない」と拡張するのは不正確です。Copy 値は代入や関数渡しで copy され得ますし、borrowing は所有権を移さずにアクセスを許し、複数の shared reference が同時に存在できます。Rc<T> のようなライブラリ抽象は、参照カウントによる shared ownership など別の所有関係を表現します。Safe Rust の参照規則は sound な Safe Rust の範囲で dangling reference と禁止された mutable aliasing を遮断しますが、3.2節で整理した unsafe・FFI・soundness の境界を含むシステム全体の correctness や availability を自動的に保証するものではありません。

ライフタイム注釈も、実行時にオブジェクトの寿命を延ばしたり新しい寿命を付与したりする表記ではありません。公式 Book が説明するように、注釈は複数の参照ライフタイム間の関係を記述し、多くの場合は lifetime elision と inference によって直接書く必要がありません。注釈が必要な状況の不慣れさは学習コストになり得ますが、「明示した lifetime 自体が dangling pointer を防止する」というより、コンパイラが参照の有効性を検証できるよう関係を表現する、と説明する方が正確です。⁶⁹

コンパイルエラーは直ちに「アルゴリズムが安全でない」または「データ構造を表現できない」ことを意味しない

静的解析は許容される表現を制限でき、プログラマが意図する invariant をコンパイラが直接確認できない場合もあります。4.2節の split_at_mut の例のように safe API の内部で狭い unsafe invariant を確立することもでき、4.3節のように container、index/arena、reference counting、run-time checking など別の representation を選ぶこともできます。したがって借用検査器による拒否が直接確立するのは、現在のプログラム表現が Safe Rust の静的規則を満たさず拒否されたという事実です。それだけで問題自体の semantic unsafety や特定データ構造の不可能性が証明されるわけではありません。

この区別は学習にも重要です。初心者が出会うコンパイルエラーには、実際に禁止すべき参照関係、別の所有権表現が必要な設計、ライフタイム関係を signature に明示すべき場合が混在します。コンパイラ診断はこの過程で摩擦コストになり得る一方、学習ツールとしても働きます。2024 State of Rust Survey は、「learned by doing」と答えた人の中に rustc の error message と Clippy を guide として使った事例を報告しています。2025年に実施された Rust Vision Doc 研究をまとめた2026年の学習フォローアップ記事でも、複数の interviewee がコンパイラ診断を lifetime・borrow 関係を学ぶ主要資源として説明しています。⁷⁰

学習困難は観測されるが、一つの固定された「Rust の学習曲線」へ一般化できない

学習コストそのものには経験的根拠があります。ICSE 2022 の mixed-methods 研究は Rust 関連の Stack Overflow 質問100件を分析し、Rust programmer 101人を対象に survey を行い、ownership/lifetime safety rule の理解と適用に繰り返し困難が生じることを確認しました。OOPSLA 2023 の研究は、ownership 概念の誤解を測定する道具と新しい pedagogy を評価し、initial deployment で original version と比べた Ownership Inventory score が平均9%高かったと報告しました（N = 342, d = 0.56）。OOPSLA 2024 の後続研究は、62,526人の Book 読者が13か月間に提出した1,140,202件の quiz 応答を分析し、ownership type のような難しい概念の区間で学習離脱を観測するとともに、12の教育介入によって対象設問の得点が平均20%向上したと報告しました。⁷⁰

これらの結果は二点を同時に示します。第一に、ownership・borrowing・lifetime は実際に測定可能な学習上の難点を生み得ます。第二に、その難しさは固定された言語定数ではなく、説明方法、diagnostics、練習、prior experience、mentoring などの条件で変わり得ます。2024 State of Rust Survey では Rust 非利用者の約31%が「難しいという認識」を主な非利用理由に挙げ、survey 回答者の53%が自身の Rust expertise を productive 水準と評価しました。しかし完了回答7,310件の約92%は Rust 利用者で、survey は主に既存の Rust 開発者へ届いているため、この数値を開発者全体の学習時間や生産性分布へ一般化できません。⁷⁰

Rust Vision Doc process は約4,200件の survey 回答と70件を超える interview を集めました。2026年の学習フォローアップは、prior experience、組織の training、mentoring、低リスクの初期 task といった文脈が学習経路に影響した事例を示します。しかし研究者は、Rust を拒否したり使用を中止したりした人を十分に募集しにくかったという selection bias と、組織全体より individual developer experience に重点を置いたという範囲を明示しています。したがって、これらの質的 pattern は経験の多様性と可能な支援方法を示しますが、頻度、標準的な ramp-up 期間、組織生産性への因果効果を推定するものではありません。⁷¹

学習コストと純生産性は別の変数である

コンパイル時の拒否は、実装中に直ちに処理しなければならない作業を増やし得ます。反対に、一部の誤った参照関係を実行前に遮断すれば、後のデバッグや欠陥修正を減らす可能性もあります。どちらの効果が大きいかは task、codebase、defect mix、コンパイラフィードバックの品質、チーム経験、review・test・CI 過程によって異なるため、言語機構だけから純効果を決めることはできません。

この点は Rust Project 自身の survey にも表れます。2021 survey では、職場で Rust を導入したと答えた回答者の83%が導入を challenging と評価した一方、Rust がチームを遅くしたと答えたのは13%で、82%はチームの目標達成に役立ったと回答しました。これは self-report と self-selection を伴う標本なので Rust の生産性優位を証明しません。

むしろ、導入が難しかったという回答とチームに役立ったという回答が同時に存在し得るため、学習困難から純生産性を直ちに推論できない反例として用いるのが適切です。

2025 State of Rust Survey でも non-trivial productivity problem として slow compile time、storage usage、debugging などが報告され、survey team は7,156件の回答と、それより少ない optional-question の回答を母集団全体へ過度に外挿しないよう明示的に警告しています。⁷¹

したがって本書で「生産性」を主張するには、少なくとも測定単位を示す必要があります。初期学習では time-to-first-change、独力で保守可能になるまでの時間、mentoring 時間などを評価でき、開発フローでは実装時間、review cycle、rework、defect escape、debugging 時間を評価できます。大規模リポジトリや極限環境では、平均だけでなく p50/p95 edit-build-test latency、CI の CPU・memory・storage コスト、専門家ボトルネックと bus factor、長期 refactoring コストまで分離して見る必要があります。安全性欠陥の減少と開発時間の増加が同時に観測されたなら、一方を隠さず両方をコストモデルへ含めなければなりません。

言説上の境界

学習困難は開発者の知性や専門的地位の指標ではなく、逆に速い学習や単純な言語が工学的に劣ることを意味するものでもありません。このような地位・能力の判断は技術的保証と生産性測定から分離し、頻度や因果を主張する場合は3.6節で定めた discourse sampling の基準が必要です。5.1節ではオンラインの逸話から学習者行動や組織文化を一般化しません。

中間結論

現在の根拠は、Rust の ownership・borrowing・lifetime が一部の学習者に実質的な学習コストを生み得るという結論を支持します。同時に、pedagogy と diagnostics が理解を改善し得ること、学習経験が prior experience と組織支援によって異なることを示す根拠もあります。一方、借用検査器が存在するという事実だけでプロジェクト生産性が低下する、または日程予測可能性が悪化するという普遍的な因果結論は、現在の根拠を超えています。

工学的に必要な比較は「学習曲線が急か」という単一の評価ではなく、特定の組織とワークロードで、学習・実装・build・debugging・review・欠陥・運用・保守コストが時間とともにどう再配分されるかです。この基準を保てば、Rust の compile-time 保証の利点を認めながら、それを自動的な生産性優位へ拡張せず、学習コストを認めながら、それを自動的な生産性劣位へ拡張しないことができます。

5.2 技術選択の一般化傾向と工学的トレードオフ

「Rust が特定の問題で有利である」と「したがって Rust の適用範囲をさらに広げるべきである」は同じ命題ではありません。前者は言語・compiler・library・toolchain の特性と特定の workload の適合性に関する主張であり、後者はその結果を別の workload、project、organization に移せるという一般化の主張です。本節では、ある技術の適用範囲をあらかじめ広げたり狭めたりするのではなく、条件付きの利点がより広い技術選択の推奨へ移るとき、どのような追加根拠が必要かを検討します。

技術選択の論証は、少なくとも次の4段階に分けられます。

主張の段階	確認すべきこと	適切な根拠
技術特性	言語・compiler・runtime・library がどのような保証やコスト特性を提供するか	specification、公式文書、再現可能な benchmark
workload 適合性	その特性が現在の system の defect model、latency、throughput、memory、real-time、deployment 要求で重要か	要求事項、production profile、load test、incident・defect data
比較適合性	同じ要求条件で候補技術の総コストとリスクがどう異なるか	同一 workload 比較、prototype、migration experiment、lifecycle cost 資料
一般化可能性	ある project の結果を別の domain・組織・期間にも移せるか	複数 project・組織の資料、明示的 sampling、longitudinal data、confounder 分析

第1段階の利点が強くても、その後の段階が自動的に成立するわけではありません。逆に、特定の project で Rust が選ばれなかったことも、Rust に技術的利点がないことを意味しません。3.7節で整理したように、defect model、保証範囲、実行コスト、assurance、変更戦略、組織・lifecycle cost は異なる比較軸です。

「道具の法則」は Rust 固有の因果法則ではなく、方法論上の警告である

Abraham Kaplan の1964年の著書 The Conduct of Inquiry で論じられた “law of the instrument” と、Abraham Maslow の1966年の The Psychology of Science にある hammer の比喩は、慣れた、あるいは熟達した方法が問題の定義の仕方まで狭める可能性があるという方法論上の警告として利用できます。⁷² しかし、これらは Rust developer を調査した研究ではなく、特定の programming language の学習時間が sunk-cost-like な心理を生み、適用範囲を広げるという因果効果を測定したものでもありません。

したがって、旧原稿のように「Rust の習得に投資した努力が、より広い適用の試みに結び付くことがある」という説明を Rust 採用の観察されたメカニズムとして扱うなら、別の根拠が必要です。たとえば、技術学習の前後で候補群と判断基準を追跡した longitudinal data、実際の architecture decision record、比較可能な組織標本、要求事項と既存 stack を統制した研究などが必要です。そのような資料なしに、選択結果だけから developer の動機や心理を逆推論しません。

さらに、慣れそのものが常に bias であるわけではありません。 Software architecture の technology choice では、利用可能な tool、組織内部の familiarity、外部 support、選択による side effect、既存 stack との compatibility なども考慮します。⁷³

2024 State of Rust Survey では、職場で Rust を使う回答者の21%が、すでに Rust を知っているため default choice として使っていると答えました。⁷⁴ これは、この標本で familiarity が選択理由として self-report された根拠であり、その選択が非合理的、あるいは “golden hammer” であるという証拠ではありません。

既存の専門性、運用知識、build infrastructure、training 資産は実際の switching cost と failure risk を変え得るため、選択結果だけでは認知的 bias と合理的な lifecycle cost を区別できません。

技術選択は一つの利点の順位表ではなく、明示された要求条件の比較である

memory safety、GC 不在、低 latency、迅速な開発、library ecosystem、formal assurance のいずれかが重要でないという意味ではありません。特定の環境では、一つの要求が hard constraint となり、候補群を大きく絞ることもあります。問題は、その条件を示さないまま一つの軸の利点を技術全体の順位へ変換する場合です。

大規模または極限環境で候補技術を比較するときは、少なくとも次の項目を decision record に残す方が再現可能です。

評価軸	確認する質問
workload・resource	steady-state だけでなく p50/p95/p99 tail latency、peak throughput、memory headroom、startup、code size、worst-case timing で何が必要か
defect・assurance	memory error、data race、logic error、resource exhaustion、availability failure のどれを、どの boundary まで予防・検出・立証すべきか
ecosystem・integration	必要な protocol、database、SDK、library、platform、native dependency、observability、既存 build/deploy stack を実際に支援しているか
staffing・workflow	現在の expertise、hiring、onboarding、mentoring、review、debugging、expert concentration、bus factor のコストはどの程度か
migration・operation	既存資産との interoperability、段階的移行、rollback、incident response、data migration、並行運用が可能か
lifecycle・toolchain	build/CI の CPU・memory・storage、dependency update、security response、toolchain support、長期 refactoring、rewrite opportunity cost がどう累積するか

この表は、特定言語の平均効果を報告する empirical result ではなく、比較で重要な条件を落とさないための decision procedure です。実際の重みと合格基準は project の要求事項から定める必要があります。

この基準も、特定の言語が常に優越するという結論を作るためのものではありません。たとえば memory-safety defect が主要なリスクで、同時に low-level control と厳しい resource budget が必要な workload なら、Rust の条件付き利点に高い重みを置くことは合理的です。反対に、application の bottleneck が database や外部 service にあり、組織の主要リスクが機能変更速度、既存 framework との統合、人材供給にあるなら、別の軸の重みが大きくなり得ます。いずれの場合も、実際の要求と測定なしに「GC があるので不適切」「static type がないので不安定」「Rust は難しいので生産性が低い」のように一つの特性を全体判定へ拡張しません。

Web backend は「過剰適用」の証拠ではなく、条件を明示すべき実際の利用領域である

旧原稿は、Rust を一部の一般的な web backend に適用しようとする主張を、そのまま一般化の事例として提示していました。この表現は範囲が広すぎます。2024 State of Rust Survey は、回答者の technology domain の中で server backend、web/networking service、cloud technology が特に多いと報告しています。⁷⁴ 5.1節で確認したとおり、この survey は7,310件の完了回答の約92%が Rust user であり、既存の Rust developer を主な対象としているため、backend 市場全体の share や相対的優越性は推定できません。しかし、backend という domain 自体が Rust の例外的な、あるいは本来の目的外の利用だという前提も、この資料からは支持されません。

したがって検討対象は「Rust を backend に使うか」ではなく、その主張に付く条件です。特定の API gateway や service で tail latency、memory footprint、memory-safety 要求、concurrency defect model が実際の中核要件であり、benchmark と運用資料が適合性を示すなら、その条件では Rust 採用に直接の工学的根拠があります。逆に、SaaS、社内 system、commerce service といった名称だけで Go、Java、C#、Python、Rust のどれがより適切かを決めることもできません。database latency、deployment model、framework dependency、team expertise、security requirement、traffic distribution、既存資産を同じ基準で比較する必要があります。

この対称性は否定的な一般化にも適用されます。「Rust の memory safety と runtime performance が利点なので、すべての backend の default であるべきだ」という主張には他の workload へ拡張する根拠が必要であり、「Rust には学習コストがあるので一般的な web backend には不適切だ」という主張にも同じ水準の比較資料が必要です。条件付きの成功例やコスト事例は可能性と failure condition を示しますが、標本設計なしに domain 全体の平均効果を決めるものではありません。

言説の存在・頻度と、技術選択の原因を分離する

3.6節で定めた sampling 基準もそのまま適用します。選択した公開投稿で「ある技術に利点があるので別の domain にも使うべきだ」という論証を見つけたなら、それはその論証形式の存在を示すことはできます。しかし、あらかじめ定義された corpus と sampling なしには、それが Rust community で一般的か、支配的か、実際の adoption decision をどの程度変えるかを推定できません。⁵⁸ 逆方向の逸話を数件見て、Rust user は一般化しないと結論するのも同じ誤りです。

中間結論

現在確認した資料が直接支持する結論は三つです。第一に、「道具の法則」と hammer の比喩は、慣れた方法が問題定義を狭める可能性を点検するための方法論的な問いを提供します。第二に、technology choice では workload と quality attribute だけでなく tooling、expertise、compatibility、migration、operation、lifecycle cost をあわせて比較する必要があります。第三に、Rust は実際に server backend と web/networking の領域で利用されているため、backend 採用それ自体を一般化の証拠として扱うことはできません。

一方、現在の根拠だけでは、Rust を学習した developer が投資コストのため適用範囲を広げる、Rust community が他言語の利用者より頻繁に golden-hammer reasoning を行う、あるいは Rust が一般的な web backend で普遍的により優れている、または劣っているという因果・頻度・平均効果の結論は出せません。そのような結論には、あらかじめ定義した developer・organization の母集団または discourse corpus、候補技術と要求条件を記録した decision data、同一または比較可能な workload のコスト・defect・運用指標、expertise・legacy・deadline・architecture 変更などの confounder を扱う研究が必要です。本節の工学的結論はさらに限定的です。技術の利点は採用根拠になり得ますが、適用範囲は利点の名称ではなく、明示された要求条件と比較資料によって決めるべきです。

5.3 非同期プログラミングモデルの複雑性と工学的トレードオフ

Rust の async/await を評価するときは、言語が定義する Future model、executor と I/O runtime の実装、library ecosystem の API 選択、FFI boundary、そして特定 workload で観察されるコストを分離する必要があります。旧原稿はこれらの層を一つの「非同期モデル」にまとめ、概念的複雑性、ecosystem fragmentation、interoperability cost を Rust の固定的特性のように記述していました。本節の問いはより限定的です。Rust async はどのコストを減らすよう設計され、その選択はどのような別のコストと integration boundary を作り、そのコストを現在の根拠からどこまで一般化できるのか。

async は executor を消す機能ではなく、実行 policy を言語の外に置く Future model である

Rust Reference によれば、async fn を呼び出しても関数本体が直ちに実行されるのではなく、引数を capture した Future が返され、その future が poll されたときに本体が進行します。標準 Future trait の中核 operation も poll(self: Pin<&mut Self>, cx: &mut Context<'_>) です。公式 Async Book はこれを “zero-cost” async と説明する一方、Rust が built-in runtime を提供せず、community crate が runtime を提供すると明記しています。⁷⁵

したがって “zero-cost” を「executor、scheduler、I/O driver、timer、task management のコストが存在しない」という意味に読むべきではありません。公式資料が直接述べる範囲は、async で heap allocation や dynamic dispatch が必須ではなく、少数の OS thread 上で多数の I/O-bound task を実行できるという設計上の利点です。実際の application には future を継続的に poll し、I/O readiness と timer を伝える実行層が必要になり得るため、その実装・設定コストは言語構文そのものとは別に測定する必要があります。

Pin の複雑性は実在するが、露出する範囲を区別する必要がある

compiler-generated future は await をまたいで保持される local state を保存し、その state の間に address dependency が生じることがあります。Pin は、このような address-sensitive value が有効なアドレス関係を維持するための contract であり、compiler-generated Future は代表的な利用例です。ただし公式 Async Book は、通常の async/await 利用では compiler が pinning を処理するため、developer がこの詳細を意識しなくてもよい場合が多いと説明しています。⁷⁶

Pin が利用者に直接現れる境界はさらに具体的です。future や stream を直接 poll する場合、boxed future の具体型を扱う場合、custom Future を実装する場合、pin projection が必要な low-level library を書く場合には、Pin、Unpin、projection と safety contract を理解する必要があります。したがって「Rust async を使うにはすべての developer が self-referential structure と Pin を深く理解しなければならない」という一般化も、逆に「Pin は compiler 内部の詳細なのでコストはない」という一般化も正確ではありません。

この usability 問題は単なる外部批判でもありません。Rust project は2025年、async Rust を sync Rust の使用経験に近づけ、Pin ergonomics を改善する作業を進め、2026 project goals にも Continue Experimentation with Pin Ergonomics が含まれています。2024 State of Rust Survey の open answer 要約でも、async programming の難しさが productivity を制限する問題として言及されています。⁷⁷ ただし survey の open answer は、母集団全体での発生率や Go・Java・C# に対する相対的学習コストを測定した controlled study ではありません。この根拠は問題が存在し、改善対象として認識されていることを支持しますが、「Rust async の生産性が平均でどれほど低いか」という結論までは支持しません。

runtime の多様性と ecosystem coupling は同じ設計選択の二つの側面である

Rust standard library は Future という最小の実行 interface を提供しますが、特定の executor を標準 runtime として固定しません。この構造は single-thread、multi-thread、embedded など異なる実行戦略を選ぶ余地を与えます。同時に、application に必要な task spawning、I/O driver、timer、asynchronous I/O type、shutdown などの機能は runtime または library API に置かれるため、二つの library がともに Future を返すという事実だけでは end-to-end の互換性は保証されません。⁷⁸

しかし、これを「Tokio に依存すると他の runtime との互換性を失う」という全面的な命題へ変えるのも広すぎます。現在の Tokio 文書は、runtime が I/O driver、scheduler、timer をまとめて提供すると説明する一方、tokio::sync の synchronization primitive の多くは runtime-agnostic であり、timer を必要とする timeout 系 operation などは例外だと明記しています。したがって coupling の単位は「Rust async 全体」ではなく、実際に dependency が利用する API と resource driverです。別の runtime や library へ移行するときは、必要な adapter、feature flag、I/O trait 変換、task-local state、timer・cancellation semantics を dependency graph で確認する必要があります。

この違いは maintainability に重要です。runtime 選択の自由は特定環境に合った scheduler と resource policy を可能にしますが、長期間運用される大規模 system では、runtime-specific API が public interface へどの程度広がるか、一つの process に複数 runtime を置く理由とコストがあるか、blocking operation が executor thread を占有するか、shutdown と backpressure がどの library boundary を越えるかも検討する必要があります。「標準 runtime がない」という事実自体は長所や欠点の判定ではなく、これらの選択コストをどこで負担するかを決める設計条件です。

非同期 FFI の問題は「不可能」なのではなく、ABI が実行 protocol を定義しないことにある

Rust は C ABI を通じて foreign function と値を交換できますが、C ABI が Rust Future の polling protocol まで標準化するわけではありません。Rust Reference の external block で宣言する foreign function には async qualifier を使えず、Rust の async fn は呼び出し時に opaque future を返します。また Future::poll は Pin、Context、wake-up protocol を前提とします。⁷⁹ したがって同期関数の call ABI を共有するだけでは、foreign event loop が Rust future を自動的に drive できません。

だからといって、旧原稿のように「block するか callback wrapper を手作業で書くしかない」と限定する必要もありません。実際の境界は callback、opaque handle と explicit poll function、completion queue、file descriptor/event notification、message passing、専用 Rust runtime thread、host-language binding が提供する bridge など、複数の protocol として設計できます。重要な比較対象は bridge の有無ではなく、ownership、wake-up、cancellation、lifetime、error propagation、shutdown、thread-safety の contract をどちら側が担うかです。FFI コストは Rust async 固有の一つの値ではなく、host runtime と ABI protocol の組合せで変わります。

機械時間と developer 時間を一つの「コスト転嫁」物語にまとめない

公式 Rust Async Book は、多数の I/O-bound task で OS thread 中心のモデルより CPU と memory overhead を減らせると説明する一方、async function の state machine と runtime の組込みにより binary が大きくなり得ることも明記しています。さらに 2026 Rust Project Goals には Async Future Memory Optimisation と Async statemachine optimisation が含まれ、前者の problem statement は nested future の memory bloat、一部 cloud/network workload の stack overflow、embedded・kernel のように memory budget が厳しい環境への懸念を明記しています。⁸⁰

これは「async は無償である」「async は developer 時間を犠牲にして runtime cost を最小化する」といった単一の交換式より、はるかに具体的な図を与えます。runtime CPU、allocation、future size、binary size、compiler optimization、debugging、integration、maintenance は異なるコスト軸です。一つの軸での削減が別の軸での増加を自動的に証明するわけではありません。2024 survey の open answer に async と debuggability の問題が現れることも、実際の困難の存在は示しますが、error tracing 時間がどれだけ増えるか、他言語より debugging が難しいかまでは定量化しません。

Go goroutine との比較も、同一の workload とコスト軸で行う必要がある

Go specification の go statement は、関数呼び出しを同じ address space 内の独立した concurrent thread of control、すなわち goroutine として開始すると定義します。これに対して Rust の async call は inert future を作り、executor が poll したときに進行します。⁸¹ これは実際の設計差ですが、次の表のように機構の差と性能・生産性の結果を分離して読む必要があります。

比較軸	Rust `async`/`await`	Go goroutine	結論の限界
実行単位	呼び出し時に `Future` を作り、poll されたとき進行	`go` statement が goroutine の実行を開始	言語レベルの実行 model の違い
runtime 関係	built-in runtime なし、executor/runtime を選択	goroutine と GC を含む Go runtime を使用	どちらが安いかは workload の測定が必要
resource 制御	allocation・dispatch を避けられ、runtime 構成を選択可能	runtime が scheduling と memory management を提供	peak task 数、stack/heap、scheduler、GC 条件を記録すべき
library 統合	runtime-specific I/O・timer・spawn API が integration boundary になり得る	goroutine 自体は言語機能だが library・Cgo・external loop の境界は別	「統合性が高い/低い」という単一評価へ還元不可
usability	`Pin`、`Send`、runtime context などが特定の low-level boundary で露出し得る	goroutine の生成構文は単純だが race、cancellation、leak、blocking policy は別途設計が必要	相対的な学習・debugging コストには user research が必要

したがって旧原稿の「CPU-bound なら Rust async が有利で、I/O-bound なら Go が有利」という文も、根拠なしに一般化できません。Rust async 自体の代表的な目的が大規模 I/O concurrency であり、CPU-bound work はむしろ別の thread pool や blocking strategy を必要とする場合があります。一方、Go runtime の scheduling・GC コストが特定の latency budget で重要かどうかは workload、runtime version、allocation pattern、GOMAXPROCS、hardware 条件に依存して測定すべきです。言語名だけから bottleneck の位置は決められません。

大規模・長時間・極限環境では、平均 throughput より先に failure condition を記録する

async architecture を選択するときは、平均 benchmark 一つよりも、task 数増加に伴う peak live future memory、allocator pressure、scheduler queue と wake-up storm、p95/p99/p999 latency、blocking call による executor 占有、timer 数、cancellation safety、graceful shutdown 時間、resource leak、binary size、stack headroom、runtime upgrade、dependency compatibility をあわせて測定すべきです。

embedded、kernel、long-running service のように resource ceiling や recovery 要求が厳しい環境では、特に worst-case と degradation behavior が重要です。

これらの資料があって初めて、runtime 選択の自由が実際の利点なのか、integration surface が保守コストなのか、compiler optimization の問題が deployment risk なのかを区別できます。

中間結論

現在の primary・official 資料が直接支持する結論は次のとおりです。Rust async は lazy Future と外部 executor を組み合わせる model であり、多数の I/O task を少数の OS thread で処理しつつ、heap allocation と dynamic dispatch を必須にしないことができます。

一方、runtime を standard library に固定していないため、scheduler・I/O・timer・shutdown API の選択と integration boundary を application と ecosystem が担います。

Pin は compiler-generated future を安全に扱うための重要な low-level contract ですが、多くの high-level async/await code では隠され、custom future・stream・projection のような境界でより直接的に露出します。

2026年にも Pin ergonomics と async future の memory/layout 最適化が project goal に残っていることは、この領域のコストと usability が固定的な属性ではなく、継続中の実装・言語設計課題であることを示します。

一方、現在の根拠だけでは、Rust async が一般的に Go より学習しにくい、または生産性が低い、Tokio 中心の ecosystem が本質的に互換不可能である、非同期 FFI が実用上不可能である、あるいは I/O-bound backend では Rust async の実行効率より developer cost が常に大きいとは結論できません。その比較には、同一または比較可能な service で task 数、latency distribution、CPU・memory・binary size、failure/recovery、implementation effort、defect・incident、staffing、maintenance の資料をあわせて収集する必要があります。本節が RQ2 と RQ3 に与える結論はより限定的です。Rust async の利点とコストは “zero-cost” という標語から推論するのではなく、実行 model、runtime/library boundary、workload、resource ceiling、組織の運用条件ごとに分解して評価すべきです。

5.4 明示的エラー処理モデル `Result<T, E>` の実用性再考

Rust のエラー処理を評価するには、型によるエラー表現、伝播構文、別個の失敗経路としての panic、application の回復方針を分ける必要があります。従来の本文は Result<T, E> がすべてのエラー処理を compile time に強制すると述べていましたが、その境界はもっと狭いものです。Result は成功と失敗を Ok(T) / Err(E) で表し #[must_use] が付くため、単に捨てると既定では警告されます。しかしこれは lint であり、常に hard compile error になるわけではありません。呼び出し側は上位へ伝播したり、unwrap/expect で panic に変えたり、明示的に無視したりできます。⁸²

したがって問うべきなのは「Rust がエラー処理漏れを完全に禁止するか」ではなく、回復可能な失敗を通常の戻り値型と制御フローに露出させる設計がどのような利益と費用を生み、application がその契約を運用方針へどう接続するかです。

Result と例外を「明示的対暗黙的」の一軸だけで比較しない

Result に対する ? は Err(e) で enclosing function から早期 return し、戻り側のエラー型が異なる場合には From::from による変換も行えます。したがって同一エラー型だけに限定されません。⁸³ 例外ベースの言語も一種類ではありません。Java の checked exception は処理するか throws に宣言しなければ compile-time error となり、同時に RuntimeException と Error のような unchecked 系統もあります。⁸⁴ Rust にも panic!、unwrap、expect、abort の経路があります。どちらも「すべての失敗が型にある」「すべての失敗が型から隠れる」とは言えません。

実務上は、エラー契約が API のどこに現れるか、正常・失敗フローの伝播、変換・合成、cleanup、FFI、logging/retry/fallback 方針で比較します。Result はエラーを通常の戻り型にし、例外は handler まで非局所的に制御を移せます。可読性や保守性は call depth、エラー分類、回復位置、library boundary、team convention に依存し、構文だけで生産性や信頼性を順位づけできません。

成功・失敗を sum type で表す設計は Rust より古い

Haskell 2010 には Maybe と Either があり、F# の Result<'T,'TError> は Ok と Error を持つ discriminated union です。⁸⁵ これは類似した algebraic-data-type 表現が Rust より前から存在したことを示しますが、Rust Result の直接の系譜や「Rust が普及させた」という影響関係までは示しません。そのためには初期 Rust の設計記録や設計者資料が必要です。

エラー変換には依然として設計コストがある

大規模 application では filesystem、parser、database、network など異なる error type を統合するため public error taxonomy が必要です。custom enum、source error の保持、context、retryability の分類にはコードが要ります。ただし各 call site で必ず map_err(...) を書くわけではなく、適切な変換があれば ? が From::from を使えます。⁸³ それでも dependency の具体的エラーを public API に露出するか、context を文字列に潰すか構造化して残すか、variant 追加を compatibility 上どう扱うかという判断は残ります。anyhow や thiserror の利用だけで標準機能が実用不足だとも、helper を使わない方が優れるとも結論できません。

panic と Result は排他的な体系ではなく異なる failure policy である

Rust は一般に unwind と abort の panic strategy を持ちます。unwind では frame を巻き戻しながら Drop cleanup が実行され、一部の panic は catch_unwind boundary で観察できますが、abort は process を終了します。Cargo profile で方針を選べ、target による制約もあります。⁸⁶ したがって Result に対する unwrap() は単なる「compiler rule の回避」ではなく、value-level の回復可能な失敗を panic path に昇格させる明示的選択です。運用上の影響は thread/process termination、supervisor、request isolation、shared-state invariant、FFI によって異なります。

Cloudflare 2025 は unwrap の存在だけでなく failure boundary 設計を示す

Cloudflare の 2025年11月18日 postmortem では、database access-control 変更により Bot Management の feature 生成 query が予想以上の metadata row を返し、生成 configuration が事前確保された 200-feature limit を超えました。FL2 Rust module で error となり、その処理境界の Result::unwrap() が panic に変換され 5xx 応答へつながりました。⁸⁷ unwrap は実際の escalation point でしたが、configuration generation、schema/query assumption、resource limit、validation placement、module isolation、kill-switch も防御層の一部でした。したがって直接支持されるのは typed error があっても recover/reject/isolate/panic/abort の境界を設計する必要があるという結論です。

大規模・長期運用・資源制約 system では recoverable/retryable/fatal 分類、public API への伝播、causal context、panic/exception isolation、cleanup/cancellation、FFI、logging cardinality、retry amplification、graceful degradation、restart time、error type 変更時の downstream rebuild と migration cost を測ります。重要なのは error が resource leak、partial state update、retry storm、process loss へ変換される経路です。

中間結論

Rust Result<T, E> は回復可能な失敗を通常の戻り型として表し、? は early return と From 変換を支援します。#[must_use] により無視は既定で警告されますが、すべてのエラーを hard compile error にしたり panic path を消したりするものではありません。checked exception にも compile-time contract があります。したがって RQ2/RQ3 では 明示的 error type、伝播・変換コスト、non-local flow、cleanup、API compatibility、observability、recovery boundary を同等 workload で比較する必要があり、Result と例外のどちらかを本質的に優位としません。

5.5 Rustエコシステムの質的成熟課題とコミュニティ言説分析

crates.io と Cargo は Rust library の公開・組合せに共通基盤を提供します。しかし package 数、download 数、有名 crate の存在だけで ecosystem 全体の「質的成熟度」を一つの値にはできず、少数の abandoned crate、文書不足、incident から全体の未成熟も推定できません。本節では 個々の dependency の production suitability と ecosystem 全体への一般化に必要な sampling を分けます。

0.x はそれ自体 API 不安定性の測定値ではない

Cargo は left-most non-zero component が同じ version を compatible と扱うため、0.2.3 は通常 >=0.2.3, <0.3.0 を許します。SemVer guide も 0.y.z の y 変更を major-like、z 変更を minor-like と扱います。⁸⁸ これは convention であって全 project の hard guarantee ではありません。production dependency は数字 0 だけでなく release history、changelog、MSRV、breaking-change policy、deprecation window、CI target、実際の upgrade test で評価すべきで、1.0 も runtime/operational compatibility を自動保証しません。

文書化と保守は crate ごとに観察する

cargo doc と docs.rs は文書を生成・hosting できますが品質までは保証しません。一方、source を読む必要があった数例から ecosystem 平均を推定することもできません。候補 dependency について API completeness、example、safety contract、platform limit、upgrade guide、MSRV、feature documentation を確認します。

crates.io/Cargo は複数 owner と yanking を提供し、yank された release は新規 resolution から外れながら既存 lockfile を壊しません。⁸⁹ RustSec と cargo-audit などは既知 vulnerability の確認経路を提供します。⁹⁰ これらは risk mitigation であって個別 crate の永続保守保証ではありません。

現在の根拠は challenge の存在を示すが平均品質を測定しない

2025 State of Rust Survey は7,156件の回答を集め、過度な外挿を警告しつつ developer/maintainer support への関心と、依存する crate author/contributor への企業支援を求めています。⁹¹ registry 全体の bus-factor 分布は示しません。約70件の Vision Doc interview でも crate discovery/trust と一部 domain の未成熟 coverage が課題として報告されます。⁹² これは qualitative challenge であり registry-wide reliability、documentation、abandonment rate、他 ecosystem との ranking ではありません。

したがって「量的には大きいが質的に未成熟」という総評は強すぎます。より限定された結論は、大きな選択空間と有用な infrastructure がある一方、project が dependency selection、trust、maintainer sustainability、domain coverage のコストを負うというものです。

成功・失敗例と community reply の双方に sampling discipline が必要

serde や tokio は高品質に維持された crate が可能であることを示しますが全 crate の平均 maturity ではありません。abandoned/malicious package も可能な failure mode を示すだけです。registry 全体、download threshold、production の transitive dependency、domain-specific candidate など sampling frame を先に定義し、activity、owner concentration、compatibility、MSRV、documentation、CI/test、advisory response、unsafe boundary、dependency depth、license、platform、replacement cost を同じ基準で測る必要があります。

同様に「Pull Requests are welcome」は文脈によって責任転嫁にも正当な協働招待にもなり得ます。3.6節の基準に従い、事前定義 corpus と coding rule なしの forum 事例から、どちらが一般的か、Rust community が他より批判を回避するか、contribution や bug report を減らすかは推定しません。

大規模・長期運用では dependency 一つを小さな supply chain として扱い、direct/transitive depth、owner concentration、provenance、lockfile reproducibility、advisory response、emergency patch/fork、feature combination、build-script/proc-macro、native dependency、unsupported platform、compliance、replacement lead time、update frequency、CI rebuild cost、abandonment/transfer/yank 時の復旧手順を記録します。

中間結論

Rust には publication、resolution、ownership transfer、yanking、vulnerability advisory の infrastructure があり、同時に survey/interview は maintainer support、crate discovery/trust、一部 domain coverage の課題を示します。しかし crates.io 全体の平均品質や cross-language maturity ranking は示しません。RQ2/RQ3/RQ5 では明示した dependency population に対して compatibility、maintenance、security、documentation、integration、replacement cost を測定し、言説 pattern と ecosystem quality 指標を分ける必要があります。

5.6 開発ツールチェーンの技術的課題と生産性

Rust toolchain は compiler、build system、language server、debugger のコストを分けて評価します。compile latency と memory/disk は測定可能な tool cost、IDE diagnostic latency と debugger coverage は別の workflow cost であり、codebase、CI、cache、linker、dependency graph、debug workflow によって生産性効果が変わります。

5.6.1 コンパイラの資源使用量とその影響

2025 Rust Compiler Performance Survey は3,700件超の回答を得て、build-performance 満足度平均は6/10、最頻値は7でした。報告書は experience が大きく分散し「Rust builds are slow」と一括りにできないとしつつ、Rust を使わなくなった回答者の約45%が長い compile time を理由の一つに挙げたと報告します。⁹³ 回答者が自ら選んだ「build time で最も困る project」では55%が code change 後の rebuild に10秒超を要しましたが、これは全 Rust project の distribution ではなく意図的に troublesome workload を選んだ質問です。

monomorphization は一つの mechanism です。rustc guide は concrete generic instance が compile time と binary size を増やし得ると明記します。⁹⁴

しかし build には parsing、macro、type/borrow checking、codegen、link、proc macro/build script、dependency rebuild、debuginfo、cache も関与します。survey も incremental compilation、cargo check/cargo build cache、linking、workspace rebuild、CI cache を別の bottleneck として扱います。

dev profile の full debuginfo は debugging を助ける一方 build/link と target storage を増やし、survey が参照する benchmark では line-tables-only により条件によって2–30%の cycle-count 改善も報告されました。この変更自体も workflow trade-off です。Cranelift、parallel frontend、faster linker、workspace rebuild 改善は継続中です。

評価には p50/p95 incremental rebuild、type-check/link latency、peak RSS、target growth、CI cold/warm cache、parallel memory pressure、developer idle time を含めます。

5.6.2 IDE統合とデバッグ環境：抽象化の背後にあるコスト

同 survey では約87%が editor inline annotation を主な compiler-error 確認手段とし、その約33%が annotation 待ちを大きな blocker と回答しました。open answer では rust-analyzer の performance/memory が多く挙がり、35%超が IDE と Cargo の resource contention を大きな問題としました。⁹³ これは self-selected survey の結果で全開発者平均ではありません。

従来の「debugger では Vec<String> が常に raw field だけ見える」という断定も強すぎます。Rust には debugger visualizer があり tool/OS/version で品質が変わります。2026 compiler-team debugging survey は debugging 自体は可能だが一部状況で不十分とし、複数 debugger/OS、type visualizer、first-class async debugging、Rust expression evaluation を改善領域に挙げます。⁹⁵ 実際の比較では optimized/generic code stepping、visualizer coverage、async causality、backtrace/core dump/sanitizer/profiler、remote/cross target、incident artifact・symbol・reproducible build・postmortem time を測ります。

5.6.3 ビルドシステムCargoの柔軟性

Cargo は dependency resolution、metadata、profile、workspace、feature、build command を共通化します。「非標準 build は build.rs では対応困難」という従来の一般化は広すぎます。公式文書は bundled C library、native library 探索、Rust module generation、platform-specific configuration を代表的 build-script use case としています。⁹⁶

複雑な build graph のコストは残ります。build script は compile/run され、change detection が粗いと不要に再実行されます。feature には unification/resolver rule があり、workspace は Cargo.lock と output を共有する一方、package selection、feature combination、cross target、native dependency が rebuild surface を広げ得ます。⁹⁷ よって trade-off は単純な「convention over configuration は硬直的」ではありません。共通 model は reproducibility/tool integration を助けますが、generated code、non-Rust toolchain、multiple target、hermetic build、制約された feature set、monorepo cache policy には integration layer が必要です。graph invalidation、feature-state 数、native build reproducibility、cross-compile parity、cache hit ratio、build-script time、external-build integration を測ります。

中間結論

公式資料は一部 Rust workflow で compile、editor、disk、debugging cost が実在することと、experience の分散・複数 bottleneck を同時に示します。RQ2/RQ3 では monomorphization や language complexity 一つに還元せず、同じ project/workflow の feedback latency、peak resource、CI cost、diagnostic quality、debugger capability、reproducibility、integration maintenance を比較します。

5.7 開発環境の比較：成熟度と設計思想の交差点

「Java/C# は integrated IDE、Rust は VS Code と分離 toolchain」という比較は異なる configuration を混ぜます。editor+language server、build/debug/profiler 統合 IDE、command-line automation はどの ecosystem でも比較対象になり得ます。重要なのは UI 分類ではなく、同じ開発 task をどれだけ正確・低遅延・省資源・自動化可能に実行できるかです。

成熟度は一つの軸ではない

tooling maturity には feature coverage、correctness、latency、resource use、platform coverage、compatibility、documentation、support lifecycle、recovery が含まれます。歴史の長さや language complexity 一つでは決まりません。Rust の現資料でも 2025 survey に build/editor の満足・不満足が共存し、rust-analyzer/resource contention の具体問題があり、2026 debugging status は tool/OS 差と visualizer、async debugging、expression evaluation の gap を示します。⁹⁸ これは global な「初期段階」評価ではなく capability gap の特定です。

同じ task と project で比較する

symbol rename なら macro/generated/config reference と compile/test 成功まで、completion は p50/p95 latency と memory、diagnostic は compiler との不一致、debugging は breakpoint/watch/expression/async causality/core dump、build は cross target/native/generated/cache を測れます。「integrated IDE 対 LSP」自体は quality score ではありません。integration は installation/discoverability を改善し得る一方 update coupling/footprint を増やし、modular tooling は交換・automation に有利な一方 compatibility/setup surface を増やし得ます。

組織規模では個人 IDE 満足度と、多数 target、複数 OS/architecture、air-gapped build、hermetic CI、長期 branch で toolchain を運用するコストを分けます。installation/index size、update、extension trust、compiler-debugger compatibility、CI image、pinning、offline mirror、support escalation、onboarding、rollback、symbol/source retention、古い release branch の build/debug の可能性を記録します。

5章結論

5章は developer experience を単一 productivity score にせず、learning、technology choice、async、error handling、dependency ecosystem、compiler/IDE/debugger/build workflow に分解しました。Rust の実際の learning/workflow challenge は確認できますが、その大きさは population、task、codebase、tool version、organization で変わり、一部は固定 language property ではなく変化する implementation/ecosystem state です。

RQ2/RQ3 では compile-time guarantee や runtime performance を自動的に productivity に変換せず、learning curve や tooling friction を自動的に technical unsuitability に変換しません。同等 project で onboarding、edit-build-test latency、review/debugging、defect escape、dependency maintenance、CI resource、incident recovery、long-term refactoring を測ります。RQ5 では選択 forum の rhetoric と population behavior/outcome を分離します。大規模・長期・極限環境では p95/p99 feedback latency、peak build memory/disk、expert concentration、toolchain outage/rollback、security response、reproducible debugging artifact、multi-year support cost も含めます。

6. 「ゼロコスト抽象化」の実際のコスト分析

「Zero-Cost Abstraction（ZCA）」という表現を評価するには、まず何に対するコストがないという主張なのかを限定する必要があります。Rust 公式 Book は iterator を例に、高水準の abstraction を使っても同等の lower-level code と比べて追加の runtime overhead が生じないよう最適化されることを zero-cost abstraction と説明し、C++ の zero-overhead principle と結び付けています。⁹⁹

これは program 全体の CPU・memory cost がゼロという主張でも、すべての abstraction が常に最適な assembly になるという保証でもありません。iterator の例自身も、より包括的な benchmark には多様な input と query が必要だと注意しています。したがって6章の問いはより限定的です。Rust が runtime abstraction overhead を減らすとき、compile、code size、dispatch、linking、deployment にどのような条件付きコストが生じ、それらのどこまでが language mechanism で、どこからが build configuration と workload に依存するのか。

6.1 コスト転嫁の仕組み：単相化の役割

Rust generic は多くの場合 monomorphization により concrete type ごとの machine-code instance を生成します。rustc development guide は、この方式が高速な実行 code を作り得る一方、複数 copy の生成に compile time がかかり、binary space も消費し得ると明記しています。⁹⁴ したがって generic-heavy code では monomorphization が build cost と code-size growth の実際の原因になり得ます。

しかしここから「すべての ZCA で節約した runtime cost が compile time と binary size に転嫁される」という普遍則は導けません。すべての zero-cost abstraction が monomorphization を使うわけではなく、zero-sized typestate や optimizer が消去する abstraction は別の mechanism です。compile time と binary size には macro、type checking、MIR optimization、codegen、linking、debuginfo、dependency、profile、target も関与します。5.6節の compiler-performance evidence も複数の build bottleneck を区別しています。

monomorphization は機械的コストを作り得るが、最終サイズは最適化と reuse に依存する

Vec<i32> と Vec<String> のような異なる concrete type で generic function を使えば別々の mono item が必要になることがあります。しかし生成されたすべての instance が同じ比率で最終 artifact に残るとは限りません。inlining、dead-code elimination、linker section garbage collection、利用可能な場合の identical-code folding、cross-crate codegen、LTO、実際に到達可能な call path が結果を変えます。source-level の instantiation 数をそのまま binary byte 数に変換してはいけません。

dyn Trait による dynamic dispatch は設計によって code duplication を減らせますが、「dynamic dispatch なら compile time と binary size が必ず減る」という一般化もできません。indirect call、optimization opportunity、object-safety/API shape、allocation・pointer representation、branch prediction、code locality が変わり、compiler が一部 dispatch を再び最適化する場合もあります。static と dynamic dispatch は runtime latency、instruction-cache footprint、compile time、size、API flexibility を同時に比較する必要があります。

cost shifting は会計上の恒等式ではなく測定仮説として扱う

ある project で iterator/generic abstraction を導入し、runtime work が同等以下になり、同時に build time または artifact size が増えたなら、その workload では実際の trade-off が観測されています。しかし一軸の改善が他軸の悪化原因を自動的に証明するわけではありません。baseline、feature set、compiler version、optimization profile、codegen unit、LTO、linker、target を可能な限り固定して比較する必要があります。

大規模 codebase では clean build の平均より incremental fan-out が重要な場合があります。generic API 変更後に再compileされる crate 数、monomorphized code の codegen unit への分散、peak linker memory、target cache growth、CI cold build と developer warm build の差を記録します。embedded/kernel では flash・RAM、build-host memory、worst-case build time も別に測ります。

中間結論

primary documentation が直接支持するのは、monomorphization が Rust generic の重要な実装 mechanism であり、compile time と binary space のコストを作り得るということです。同時に zero-cost abstraction は追加 runtime overhead を避ける設計目標であって lifecycle 全体の cost-free guarantee ではありません。RQ2/RQ3 では「cost は必ず runtime から compile へ移る」と仮定せず、特定の abstraction mechanism が明示した workload で runtime、compile、code size、dispatch、maintenance cost をどう変えるかを測定します。

6.2 バイナリサイズ分析：設計原則が適用領域へ与える影響

「Rust binary は C/C++ binary より大きい」を比較条件なしに言語の固定属性として扱うことはできません。executable size は linked library、static/dynamic policy、feature set、panic strategy、debuginfo と stripping、optimization/LTO、target runtime、libc、linker、package format に左右されます。異なる program の size 差をそのまま language-level effect に還元することはできません。ただし、同一 distribution・architecture の最新 stable repository における実際の deployment artifactは再現可能な運用資料として価値があります。

2026年8月28日、当時の公式最新 stable release である Alpine Linux 3.24.1 の v3.24 stable x86_64 repository から busybox、GNU coreutils、Rust uutils の APK を取得し、各 package の主要 multicall ELF を直接測定しました。¹⁰⁰ 3ファイルはいずれも stripped、dynamically linked x86-64 PIE でした。

表 6.1: Alpine Linux 3.24 stable x86_64 の multicall executable snapshot

実装	言語	package version	測定ファイル	file size
BusyBox	C	`1.37.0-r31`	`/bin/busybox`	804,616 B
GNU coreutils	C	`9.11-r0`	`/bin/coreutils`	1,138,944 B
uutils	Rust	`0.9.0-r0`	`/bin/uutils`	9,171,040 B

これは deployment snapshot であり、言語間の controlled experiment ではありません。command coverage、dependency graph、shared-library closure は同一でなく、表の file size は shared library 自体を含みません。この条件で uutils executable がより大きいことは再現できますが、差全体を Rust、monomorphization、static linking のどれか一つへ帰属させることはできません。むしろ version、architecture、linkage、stripping、feature set、dependency closure を binary-size claim と共に記録すべきことを示す snapshot です。

Rust は static dependency を既定で優先するが dynamic linking も支援する

rustc 文書は dependency を既定では statically link することを優先し、-C prefer-dynamic で可能な場合に dynamic linkage を優先できると説明します。Rust Reference も rlib、Rust dylib、system staticlib、FFI 向け cdylib を定義します。¹⁰¹ したがって「ABI が不安定なので Rust は dynamic linking を使えない」は正確ではありません。

別の問題は Rust-native ABI を独立配布される長期 plugin contract として扱えるかです。Reference は extern "Rust" ABI に stability guarantee がないと明記し、default repr(Rust) layout にも限られた guarantee しかなく compilation 間で変わり得ます。一方 extern "C" と #[repr(C)] のような明示的 interoperability boundary があります。¹⁰² 問うべきなのは dynamic linking の可否ではなく、どの ABI/representation をどの version boundary まで compatibility contract とするかです。

binary size は build profile と dependency graph の結果である

Cargo release profile の既定値も strip = "none"、lto = false、panic = 'unwind' であり、release build が自動的に minimum-size build になるわけではありません。Cargo は opt-level = "s"/"z"、strip、LTO、codegen-units、panic strategy などを提供します。公式文書は強い optimization が compile time を増やし得ること、s/z がすべての program で必ず小さくなるわけではないこと、LTO が whole-program optimization と長い link time の trade-off を作ることを明記します。¹⁰³

panic = 'abort' は unwinding machinery が不要な条件で size を減らし得ますが、効果は target/program 依存であり、5.4節の unwind cleanup と catch_unwind boundary を放棄する failure-policy 変更でもあります。stripping は shipped artifact を小さくできますが production postmortem 用に debug symbol を別保存する必要が生じ得ます。

no_std は collection を手で再実装するという意味ではない

#![no_std] は std の自動 link を止め core を使います。heap-backed type は core にはありませんが、allocator を提供できる環境なら alloc crate を明示的に link して Vec、Box、String を利用できます。¹⁰⁴ 従来の「no_std ではこれらを直接実装しなければならない」という記述は誤りです。

代わりに責任の境界が移ります。no_std binary は target-specific startup/entry と panic handling、heap を使う場合の allocator、filesystem/thread/network などの platform integration を明示的に用意する必要があります。この境界は firmware、kernel、bootloader では利点になり得ますが application server では不要なコストになり得ます。

shipped file size だけでなく deployment footprint を測る

小容量 flash target では .text/.rodata/.data、relocation、unwind table、allocator metadata、stack/heap budget を分けて測ります。container/serverless では compressed image size、cold-start I/O、page cache、shared dynamic page、update transfer、symbol sidecar が重要になり得ます。desktop では数 MiB の executable 差より shared-library compatibility、installer size、security patch propagation が重要な場合もあります。

大規模 fleet では複数 binary に複製される static copy、dynamic dependency の page sharing と compatibility risk、vulnerability fix 時の full-artifact redeploy、debug-symbol retention、rollback image storage も計算します。binary size は lifecycle footprint の一要素です。

6章結論

現在の根拠は、Rust が一部 high-level construct の追加 runtime overhead を減らそうとし、generic monomorphization が条件によって compile time と code size を増やし得ることを支持します。また rustc が static dependency を既定で優先しつつ dynamic linking を支援すること、Rust-native ABI stability と C ABI/representation boundary が区別されること、Cargo profile と no_std/alloc の選択が artifact footprint を大きく変え得ることを示します。

一方、この資料だけでは Rust abstraction の runtime benefit が必ず同量の compile time/binary size に転嫁される、Rust binary は本質的に C/C++ より大きい、dynamic linking が使えない、小さい binary のためには Rust の safety feature を捨てる必要があるとは結論できません。そのような主張には functionality、target、dependency、linkage、optimization、symbol、panic policy を統制した reproducible comparison が必要です。

したがって6章の RQ2/RQ3 結論は、“zero-cost” という名称や package-size anecdote ではなく、一つの明示 configuration の runtime latency/throughput、compile time、peak build memory、code/deployment size、link/ABI strategy、failure policy、maintenance cost を同時に測定することです。大規模・長期・極限環境では flash/RAM headroom、cold start、shared-page effect、update bandwidth、patch/rebuild time、rollback storage、postmortem symbol retention まで含めます。

7. 産業適用の制約条件

第7章では、Rust の産業適用を単一の「成熟度」や adoption percentage に還元せず、各証拠が何を示すのか（RQ3）、どの変更戦略がどの条件で適切なのか（RQ4）を分析します。言語保証、production deployment、tool qualification、ecosystem と staffing、legacy asset、interoperability、migration risk は異なる分析層なので分離します。

embedded/kernel 環境の現在の支援と source snapshot（7.1）、safety-critical qualification/certification boundary（7.2）、一般組織の staffing・dependency・legacy・migration 戦略（7.3）、Google・Microsoft・AWS の production adoption case が支持する範囲と限界（7.4）を順に検討します。各事例では feasibility、observed outcome、prevalence、causation を区別し、最後に maintenance から selective replacement、full rewrite までの条件付き選択を統合します。

7.1 組込み・カーネル環境：適用の現実と工学的課題

Rust が C/C++ の代替として評価される領域の一つが、組込み system と OS kernel 開発です。ただし境界は単に std が使えるかどうかではありません。6.2節で確認したように、#![no_std] は core を中心に実行環境の責任を明示し、allocator があれば alloc により Vec、Box、String などの heap-backed type も利用できます。一方、thread、filesystem、network、process といった user-space OS の std API は kernel や firmware にそのまま存在しないため、allocator、synchronization、I/O、panic、startup、device abstraction を platform に合わせる必要があります。

Linux kernel の Rust support はこの差を kernel 固有 API と abstraction で扱います。現在の kernel documentation は CONFIG_RUST で Rust support を有効にし、rust/ の support code と samples/rust/ を開発入口として案内しています。complete LLVM toolchain を現時点で最もよく support される build setup とし、GCC-based Rust build は一部 configuration で very experimental と区別しています。¹⁰⁵ したがって kernel Rust の cost と benefit を一般的な std application と同じ library surface を前提に評価することはできません。

Rust for Linux の重要な設計方向は、C で実装された kernel API の上に Rust-facing abstraction を構築し、Safe Rust caller に約束する invariant を unsafe implementation boundary で担保することです。これは unsafe を除去するという意味ではなく、proof obligation をより小さな境界へ集中させる戦略です。lock、reference counting、device registration、memory allocation などの kernel resource は同名の application type と条件が異なるため、wrapper の lifetime・aliasing・concurrency contract が実際の kernel invariant と一致しなければなりません。

最新 stable Linux 7.2.1 source tree は、初期の infrastructure 中心段階より Rust の範囲が広がっています。drivers/android/binder/ には Rust Binder、drivers/gpu/drm/nova/ と drivers/gpu/drm/tyr/ には Rust driver code が含まれます。ただし source の Kconfig は Nova と Tyr を work in progress で、機能しない可能性もあると明記します。したがって「kernel に Rust code がある」と「その subsystem が production で C 実装を置き換えた」は区別すべきです。¹⁰⁵

Linux kernel の Rust integration を最新 stable snapshot として再測定しました。2026年8月30日時点で kernel.org が stable と表示する Linux 7.2.1（2026-08-27）の公式 tarball を取得し、cloc v2.04 で source root から cloc . を実行しました。¹⁰⁶ comment と blank line を除く総 SLOC は 30,518,591 行、cloc が Rust と分類した code は 114,481 行で、全体の約 0.375% でした。

この 0.375% は Linux 7.2.1 tarball 全体で Rust と分類された source SLOC の比率です。Rust code の約 92,808 行は rust/、19,726 行は drivers/、残りは samples/、scripts/、lib/、mm/、tools/ に分布します。したがって Rust driver の比率や実行される kernel code の比率とは読めません。SLOC は code の重要性、実行頻度、安全性への効果、maintenance cost も重み付けしません。

本書の以前の Linux 6.15.5 snapshot は Rust 14,194 行、約 0.05% でしたから、最新 snapshot で量的 footprint が大きくなったことは明らかです。以前の測定と今回の測定はいずれも cloc v2.04 を使うため、tool version の差は比較から除かれました。それでも source tree 自体が大きく変化し、SLOC は code の重要性や実行比率を重み付けしないため、二つの snapshot の比率を精密な Rust adoption growth rate として扱いません。現在の技術状態には最新 stable の 0.375% を使い、8.4節では長期的に陳腐化しにくい 1%未満という category 表現で参照します。

表 7.1: Linux 7.2.1 source tree の cloc 言語分布（SLOC, %）

順位	言語	code lines	比率 (%)
1	C	19,623,126	64.30
2	C/C++ Header	8,400,038	27.52
3	JSON	553,644	1.81
4	reStructuredText	540,837	1.77
5	YAML	518,483	1.70
6	Assembly	230,041	0.75
7	Bourne Shell	159,494	0.52
8	Rust	114,481	0.38

総 30,518,591 SLOC から丸めた比率で、上位8個の cloc language category のみ表示します。

表 7.1 の量的 snapshot とは別に、kernel Rust の中心的な工学問題は safe abstraction がどの unsafe proof obligation の上に成立するかです。CVE-2025-68260 はこの境界の具体的 failure です。Rust Binder の death_list 処理で unsafe list removal と並行 access 条件が整合せず、data race と pointer corruption が発生しました。¹⁰⁷ これは Rust が data race を許すという意味ではなく、Safe Rust に提供する invariant を unsafe implementation が誤って成立させた場合、その境界外の guarantee が成立しない可能性を示します。

CVE record は Linux 6.18 を affected とし、6.18.1 および 6.19 series で fix を記録しているため、ここで測定した最新 stable 7.2.1 を未修正状態と説明してはいけません。¹⁰⁷ 分析単位は「Rust kernel は unsafe」ではなく、unsafe operation の aliasing・locking・lifetime precondition をどう review、regression test、subsystem boundary で isolate するかです。

中間結論

最新 stable snapshot は Linux kernel 内の Rust source footprint が本書の以前の測定より拡大し、Binder や GPU driver を含む実際の driver code が存在することを示します。同時に Rust は総 source SLOC の 1%未満であり、その数字は adoption の価値や safety effect を直接測定しません。embedded・kernel 環境での Rust の適合性は no_std という label だけでは判断できず、target/toolchain support、allocator と panic policy、platform API coverage、unsafe boundary の reviewability、subsystem maturity、binary/RAM budget、debugging、upgrade、長期 maintenance cost を合わせて評価する必要があります。

7.2 ミッションクリティカルシステムと国際標準の不在

本節でいう「国際標準の不在」とは、Rust 言語自体が C、C++、Ada のように ISO/IEC などの国際標準言語として標準化されていないことを意味します。これは、安全・ミッションクリティカル開発に利用できる qualified Rust ツールチェーンや商用の認証支援経路が存在しないという意味ではありません。航空宇宙、自動車、産業制御、医療機器のように高い保証水準が求められる分野では、言語仕様の標準化、コンパイラと開発ツールの qualification、ライブラリの certification、最終システム・製品の certificationを別の層として区別する必要があります。

Rust 自体が国際標準言語ではないことは、現在も C/C++/Ada との制度上の違いです。ただし国際標準そのものも改訂され、長期保守性や認証可能性が言語の標準化だけで決まるわけではありません。実際のプロジェクトでは、使用する言語仕様、特定のコンパイラ版、検証資料、対応ターゲット、ライブラリの範囲、ベンダーの長期サポート条件を併せて確認する必要があります。

この区別を示す例が Ferrocene です。Ferrous Systems とその子会社 Critical Section GmbH は2021年、安全上重要な領域で Rust 言語と compiler を qualification する取り組みとして Ferrocene を公開し、2022年には Ferrous Systems と AdaCore が安全・ミッションクリティカル市場向けの共同開発を発表しました。2026年7月28日公開の最新 release Ferrocene 26.05.0 の compiler は TÜV SÜD qualification に基づき ISO 26262 ASIL D、IEC 61508 SIL 3、IEC 62304 Class C の安全関連開発を支援し、upstream Rust 1.93.0 から 1.95.0 までの変更を含みます。¹⁰⁸ したがって Rust ecosystem に安全規格対応の商用 compiler や qualification path が存在しないと一般化することはできません。

ただし、この qualification を Rust 言語全体、すべての Rust program、または Ferrocene とともに配布される development tool 全体の certification へ拡大解釈してはいけません。Ferrocene Safety Manual は qualification を Ferrocene Language Specification（FLS）、指定 target environment、usage restriction、適用 Tool Confidence Level と利用環境を確認する user obligation によって限定します。公開 qualification 文書は qualified tool を rustc とし、cargo、Clippy、rust-analyzer、debugger、rustdoc/rustfmt、各種 LLVM tool を unqualified と区別します。ただし現在公開されている main 文書は development-branch preview なので、そこで示される次期 rolling version number を release 済み 26.05.0 の qualification version として扱いません。¹⁰⁸

compiler qualification と library certification も別です。最新 26.05.0 release は Rust core のcertified subsetを ISO 26262 ASIL B と IEC 61508 SIL 2 の範囲で提供し、core::fmt まで certification scope を拡大しましたが、core 全体が compiler と同じ ASIL D/SIL 3 水準で certified されているわけではありません。航空宇宙分野でも Ferrocene は DO-178C DAL C に向けた customer certification effort を支援すると説明していますが、これを ISO 26262/IEC 61508 と同じ意味で完了済みの qualification と扱うべきではありません。¹⁰⁸

したがって、ミッションクリティカル分野で Rust を評価する際の中心的な問いは、単に「Rust は国際標準言語か」ではありません。どの Rust 仕様とツールチェーンを使うのか、その版とターゲットプラットフォームが qualification の範囲に含まれるのか、必要なライブラリが certification の範囲に入るのか、そして最終製品のシステムレベル認証と長期保守の責任を誰が負うのかを併せて検討する必要があります。Ferrocene は、国際標準言語でないことが直ちに安全認証経路の不在を意味しない反例である一方、ツールの qualification が個別製品の certification を自動的に代替しないという境界も示しています。

7.3 一般産業導入の障壁と変更戦略

一般産業で Rust 導入を評価するとき、「言語が優れているか」と「その組織が現在この言語を安全に運用できるか」は分ける必要があります。人員、dependency、既存 system、FFI、deployment、observability、support は language semantics とは別層の制約であり、project ごとに値が異なります。したがって本節では市場全体の単純 ranking ではなく、組織ごとの capability と変更戦略を比較します。

人員問題は市場 ranking ではなく組織の実能力で測る

2025 State of Rust Survey は Rust developer を追加採用する予定の組織が引き続き増えていると報告しています。しかし 7,156 人の Rust-oriented self-selected sample であり、report 自身も過度な外挿を戒めています。¹⁰⁹ この資料だけから「Rust の labor pool は Java/C#/Python より小さい」「採用は常に難しい」「賃金が一貫して高い」といった言語間労働市場 ranking は確定できません。

project では実際に利用可能な Rust expertise、code review 可能人数、unsafe/FFI reviewer の bus factor、新規人員の ramp-up 期間、incident on-call coverage、教育時間、外部採用 lead time、長期 retention を記録すべきです。ある組織では既存 C++ engineer の再教育が最短かもしれず、別の組織では既に十分な Rust 経験者がいるかもしれません。市場平均の slogan より、team が持続的に維持できる expertise が直接的な制約です。

ecosystem の「成熟度」も domain と dependency 単位に限定する

5.5節で扱った Rust Project の 2026 Vision Doc 関連資料は crate の選択・信頼や一部産業 domain の coverage 不足を実際の課題として記録する一方、sample と一般化の限界も明示します。⁹² ORM、cloud SDK、authentication など一部の例から Rust enterprise ecosystem 全体を Java/.NET より一律に未成熟と ranking するのは証拠範囲を超えます。

実務では必要な protocol、database、cloud、cryptography、GUI、embedded、safety library ごとに maintainer capacity、release cadence、security advisory 対応、API stability、platform coverage、license、transitive dependency、offline/vendor 対応、replacement candidate、long-term support を確認します。必要な crate がない、または要求 assurance level を満たさないことは実際の導入 cost ですが、別 domain の成功・失敗をそのまま転用してはいけません。

legacy は廃棄判定ではなく、現在状態と将来 cost の集合である

長期運用 system には code だけでなく test、deployment script、data format、operational workaround、顧客や device との互換性といった暗黙 specification が蓄積されます。software 自体は物理的に摩耗しませんが environment と requirement は変化するため sustainment cost は続きます。¹¹⁰ 古いという事実だけで維持・廃棄を決めることはできません。

既に支出した開発費は sunk cost ですが、今後の maintenance、security remediation、migration、parallel operation、data conversion、retraining、outage、rollback、regression risk は将来 cost です。CMU SEI の legacy modernization 研究も、大規模で複雑な system では incremental modernization や coexistence を含む複数戦略を system 条件に応じて比較します。¹¹¹

Google Android はこの境界を具体的に示します。Android team は既存の数千万行の C/C++ 全体を書き直すのは現実的でないと説明し、新規 code を memory-safe language で書く方向と Rust↔C++・Rust↔Kotlin interoperability を優先しています。firmware でも既存 C codebase に Rust を段階的に導入し、新規 code と security risk の高い component を優先する方式を文書化しています。¹¹² これは Rust の価値を否定するのではなく、full rewrite と incremental adoption が異なる risk profile を持つ実例です。

FFI と移行期間は独立した cost center である

段階的 Rust 導入では既存 C/C++ ABI との boundary を維持する必要があります。6.2節の通り extern "Rust" と default Rust layout を長期安定 ABI とみなすことはできず、C ABI と repr(C) など明示的 contract が必要になり得ます。¹⁰² さらに ownership transfer、allocator ownership、string/buffer lifetime、error mapping、callback、cancellation、thread affinity、panic/exception boundary を設計します。5.4節の error model と同様に、同じ failure を両言語でどう表現し、cleanup と retry を誰が担うかも決める必要があります。

「incremental adoption は安全だから安い」「FFI があるから full rewrite がよい」という一般則はいずれも成立しません。小さく安定した boundary を持つ module は selective replacement に適する一方、fine-grained crossing が hot path 全体に広がったり ownership が頻繁に往復したりすれば performance、debugging、maintenance cost が増え得ます。

変更戦略は ranking ではなく条件付き選択肢である

戦略	適し得る条件	主な利点	主な cost・失敗条件
既存実装の強化	defect が局所的で検証済み behavior asset が大きい	transition・regression risk が小さい	構造的 memory-safety risk や technical debt が残り得る
同一言語で modernize	architecture/test/observability を先に改善できる	既存 ABI と運用知識を再利用	safety rule が process と tooling に依存し続ける
新機能を Rust で実装	旧 behavior の再現が少なく boundary が明確	rewrite せず経験と safety boundary を蓄積	二重 toolchain と interoperability を維持
高リスク module を選択的に置換	memory-safety exposure が集中し interface が安定	assurance 投資を高リスク領域に集中	FFI・data ownership・performance boundary が新たな failure mode になり得る
full rewrite	既存 architecture が要求を満たせず specification・test・予算・cutover plan が十分	言語と architecture を同時に再設計	schedule 超過、暗黙 specification の欠落、parallel operation・rollback failure の影響が大きい

大規模・長期運用環境では、戦略ごとに migration 期間と double-run cost、p95/p99 request 影響、peak memory、build/CI capacity、incident rate、rollback 時間、FFI crossing volume、duplicated tooling、security patch latency、expert bus factor、multi-year support cost を追跡すべきです。selective adoption が成功しても boundary が増え続ける可能性があり、rewrite では old/new 両 system の operational complexity が長く続く可能性があります。

中間結論

RQ3 と RQ4 について、現在の証拠は Rust 導入障壁を固定的な「人材不足」や「未成熟な ecosystem」に還元しません。組織の実際の staffing capability、必要 dependency の assurance、legacy asset と暗黙 specification、FFI boundary、migration/cutover risk が判断を左右します。Android のような大規模既存 C/C++ codebase でも new-code-first と interoperability が実際の移行戦略として使われ、full rewrite は複数選択肢の一つです。Rust 導入は code の置換率ではなく、どの変更単位で defect、cost、operational risk を減らせるかで判断すべきです。

7.4 「巨大企業の採用」物語の多角的分析：文脈、限界、戦略的含意

Google、Microsoft、AWS のような大規模 technology company が Rust を production で使用している事実は重要な証拠です。しかし「企業 X が Rust を使う」という一文には、production deployment が可能か、特定 workload で何が観察されたか、組織全体でどの程度使われるか、Rust が結果の原因か、他組織でも再現するかという別々の問いが混在し得ます。

したがって本節では corporate adoption を logo ranking ではなく case-study evidence として扱います。

事例	確認できる実使用	直接支持する範囲	この事例だけでは確定できないこと
Google Android	native system code、kernel/firmware、security-critical component への Rust 導入	大規模既存 codebase で new-code-first・interoperability が運用でき、Android 内部結果を測定可能	全 Rust project の productivity/security 優位、Google 全体の標準言語、他組織で同一結果
Microsoft Windows	Windows 11 24H2 の GDI region を `win32kbase_rs.sys` で実装	正式 Windows release の kernel component に Rust が出荷	Windows kernel 全体の移行、一般的 Rust-vs-C/C++ defect/cost ranking
AWS	Rust 製 Firecracker が AWS Lambda 等の serverless 基盤で使用され、EC2 は新 Nitro System component に Rust を使用	高性能 isolation/infrastructure workload で production technology として運用可能	AWS 全 workload の最適性、他規模・team で同じ経済性

Google Android の数値は強い case evidence だが、external validity は別問題である

Google の 2025 Android report は、Rust code の memory-safety vulnerability density が Android の C/C++ code より約 1000 倍低く、同程度の大きさの change で revision が約 20% 少なく、code review 滞在時間が約 25% 短く、medium/large change の rollback rate が C++ より約 4 倍低いと報告します。¹¹³ これは単に「Google も Rust を使う」という情報よりはるかに有用な観察です。

ただし、これを直ちに language-only causal effect と解釈してはいけません。code の役割・年齢・作成時期・team 構成・review process は無作為割付ではなく、Google 自身も review-time の変化に Android team の Rust expertise 増加が影響した可能性を述べています。したがってこの資料は Android の大規模 production environment で Rust adoption とともに観察された outcome を強く支持しますが、同じ倍率が他組織でも再現するという普遍命題は支持しません。

Microsoft と AWS は異なる adoption mode を示す

Microsoft の Windows 11 24H2 documentation は win32kbase_rs.sys の Rust GDI-region 実装を明記します。¹¹⁴ 重要なのは Rust が research prototype に留まらず正式 OS release の kernel component に入ったことです。一つの component から「Windows が Rust に移行した」と拡大するのは adoption scale の誤読です。

AWS は別の mode です。Firecracker は Rust で実装された microVM technology で AWS Lambda 等の基盤に使われ、AWS は EC2 の新 Nitro System component にも Rust を使うと述べています。¹¹⁵ これは virtualization・isolation・infrastructure workload での production operation を示しますが、enterprise CRUD、data science、GUI、firmware、safety certification 等の suitability を代わりに証明しません。

つまり「巨大企業採用」は homogeneous sample ではありません。Android の new-code-first、限定された Windows kernel component、Rust-centric な Firecracker/Nitro では adoption unit、legacy boundary、performance requirement、assurance goal、組織投資が異なります。 条件を除去して企業名だけを数えるなら、それは evidence ではなく logo counting です。

選択された成功事例には selection effect がある

企業は全 module に言語を無作為配分しません。memory-safety guarantee や predictable low-level control の価値が期待され、component boundary を作れ、必要な expertise と tooling を確保できる領域から Rust を選ぶ可能性があります。したがって成功 case は「この条件で可能だった」「この条件でこの outcome が観察された」を支持しますが、Rust を選ばなかった workload の counterfactual を自動的には提供しません。

しかし selection effect が case study を無価値にするわけでもありません。production deployment は toy benchmark では示せない build、incident response、dependency、upgrade、observability、staffing の問題を実 system で扱えた証拠です。ただし証拠単位は 会社全体ではなく特定 product・component・期間・team に留める必要があります。

他組織へ移すべきなのは logo ではなく mechanism と条件である

Google の new-code-first/interoperability、Microsoft の bounded kernel component、AWS の infrastructure-specific deployment から抽出できるのは「大企業も Rust を使う」という authority appeal ではなく変更 mechanism です。有用な既存 asset を残し、boundary を定め、必要な tooling と training を整備し、security・rollback・review・latency・resource 指標を測り、結果に応じて範囲を広げるか止めます。

小規模組織では専用 interoperability tool、compiler expertise、security research capacity、長期 training budget が不足するかもしれません。逆に小さい codebase と単純な deployment boundary により移行が容易な場合もあります。組織規模だけから adoption 難度を単調に推論できません。

第7章の結論

第7章の証拠を総合すると、Rust の産業適用は「まだ未成熟」または「大企業が使うから検証済み」という一軸では整理できません。7.1 の Linux 7.2.1 snapshot は Rust source footprint の増加と Binder/GPU driver code の存在を示す一方、全 source SLOC ではなお 1% 未満であり、その比率自体は safety effect や adoption value を測りません。7.2 の Ferrocene は ISO/IEC 標準言語でなくても qualified toolchain と一部 certification path が存在し得ることを示しますが、compiler qualification が全 library や最終 product certification を代替しません。

7.3 は staffing、dependency assurance、legacy asset、FFI、cutover が組織別 change strategy を左右することを示し、7.4 は Android、Windows kernel component、AWS infrastructure という異なる production 条件で Rust が実運用できることを確認します。どの case も industry-wide prevalence、language-only causation、全 workload の comparative superiority を単独では確定しません。

RQ3 では adoption case と measurement を実際の unit で解釈する必要があります。production use は feasibility、内部 longitudinal metric はその environment の observed outcome、qualification は指定 assurance scope を支持します。これらを組み合わせても universal superiority や将来の market dominance を自動推論できません。

RQ4 では maintenance、same-language modernization、new-component Rust、selective replacement、full rewrite は ladder ではなく条件付き戦略です。defect profile、code age、暗黙 specification、interoperability boundary、staffing、assurance goal、migration 期間、rollback capability、long-term support を同じ decision record で比較すべきです。

大規模・長期・極限環境では adoption percentage より memory/resource headroom、p95/p99 latency、failure containment、patch latency、toolchain reproducibility、dependency replacement time、incident recovery、expert bus factor、certification evidence の維持、multi-year upgrade/rollback cost が直接的な判断材料になり得ます。Rust が production で成功している事実と、特定組織が Rust へ移行すべきという結論の間には、なお workload と組織条件を結ぶ比較証拠が必要です。

第4部：技術コミュニティの言説分析

第3部までは、Rustの言語保証、開発者体験、ビルド・デプロイのコスト、産業適用の条件を分析しました。第4部では、分析単位を技術そのものから、技術について公開の場で提示される主張と論証のパターンへ移します。中心となる問いは、ある言語を好むか嫌うかではなく、条件付きの工学的利点が、どの時点で普遍的な選択命題、他の代替案の排除、あるいは人に対する地位判断へ拡張されるのかを、どのように判定するかです。

本部では証拠の層を厳密に区別します。Rust Projectの公式文書とproject goalsは、公式の価値提案、保証範囲、改善課題を確認する一次資料として用います。Reddit、Rust Users Forum、技術ブログなどの公開投稿は、特定の論証形式が実際に存在しうることを示す定性的事例としてのみ用います。現在の本書には、Rust関連のオンライン言説全体を代表するよう事前定義されたcorpusや確率標本がないため、選択した事例からコミュニティ全体の頻度・代表性・合意を推定しません。⁵⁸

同じ測定、incident、投稿が後続節で再び現れても、新しい独立観測として数え直しません。技術的事実と数値は最初に監査した技術節を一次的な扱いとして固定し、後の登場は論証構造、総合、意思決定に適用する分析上の再利用として扱います。したがって反復そのものは証拠の重みを増やさず、より強い結論には別の独立資料が必要です。

同じ理由から、少数の公開投稿だけで、投稿者の心理状態、集団アイデンティティの強さ、エコーチェンバーの存在、新規開発者の技術選択の変化、実際の組織採用への因果効果を判定しません。こうした説明は、観察された論証を解釈するための検証可能な仮説にはなりえますが、別途のインタビュー、実験、縦断データ、ネットワーク分析、あるいは定義済みの言説標本なしには、本書の経験的結論にはなりません。Web由来の学習資料の分布が言語モデルの挙動に影響しうることを示す一般研究もありますが、特定のRust言説がAda/SPARKなどの代替案に比べてLLMの回答をどの程度偏らせるかは、別途corpusとモデル実験を必要とする未検証の問題として残します。¹¹⁶

第8章では、この証拠規則の下で、本書が「銀の弾丸の物語（silver-bullet narrative）」と呼ぶ論証形式を分析します。¹¹⁷ この表現はRust Projectの公式見解を指すものでも、Rust利用者全体の心理を診断するものでもありません。適用条件付きの技術的利点から条件が失われ、「唯一の解決策」「あらゆる環境で最善」「他の変更戦略は無意味」といったより強い結論へ移る推論パターンを示す分析上のラベルです。第9章と第10章は技術選択と生態系への含意を総合しますが、第8章で確認できていない頻度や因果効果を前提にはしません。

第4部の目的は特定の技術や利用者を評価することではなく、主張の範囲がどこで変化し、その変化を立証するにはどのような資料が必要かを明らかにすることです。

8. 「銀の弾丸の物語」と集団的防御機制の形成

第8章でいう「集団的防御機制」は、臨床的・心理学的診断名ではありません。批判や反例が示された際に、論点の移動、比較基準の変更、反例の分類、相手の資格判断などによって元の主張を防御する公開論証パターンをまとめて呼ぶ表現です。そのパターンが特定事例に存在することと、Rustコミュニティ全体で一般的であることは別の問いです。

本章は三つの問いを分けます。第一に、Rust Projectが公式に主張する価値と保証はどこまでか。第二に、公開事例でそれより強い普遍化・置換・地位判断が現れるなら、正確にどの追加前提が挿入されているか。第三に、その論証の頻度、投稿者の動機、受け手への効果、技術選択への因果効果まで述べるには、どの追加資料が必要か。この区別はRQ5、すなわち技術的事実と修辞的な一般化・地位判断をどう分離するかに直接対応します。

8.1節はこの分析の証拠境界と「銀の弾丸」分類基準を定めます。8.2節は「完全置換」と「書き直しだけが改善」という強い変更戦略を、8.3節は歴史的比較の利用範囲を、8.4節と8.5節は批判への応答と資格・地位判断の具体的論証を検討します。8.6節と8.8節は公式ガバナンスと改善活動を非公式言説から分離し、8.7節は政府勧告と企業事例がどの範囲の結論を支えるかを問います。

8.1 「銀の弾丸の物語」の形成過程と効果

この節の題名には「形成過程と効果」が含まれますが、現在の資料だけでRustオンライン言説の歴史的形成過程や社会的効果を経験的に再構成できるという意味ではありません。事前定義された期間別corpus、投稿の包含・除外基準、プラットフォーム別の露出量、受け手の資料がないためです。そこで本節はまず、確認済みの事実、定性的事例、説明可能性をもつ仮説、まだ測定されていない効果を分離し、後続節で使う判定規則を定めます。⁵⁸

公式の価値提案と非公式の一般化を分離する

Rust Projectの公式文書は、reliability/robustness、performance/resource consumption、long-term maintenance/extensibilityのような目標を掲げる一方、2025 project goalsではこの三軸のうち「二つ以上」を重視するプロジェクトを、Rustが有力候補になりうる領域として示しました。同じ目標文書は、async Rustのergonomics、低水準プロジェクトに必要なcompiler/tooling、maintainer協働などの未完了課題を明記し、2026 project goalsも具体的な問題と必要資源を列挙しています。RFCとproject-goalsの手続きも、提案、trade-off検討、チームの支援、資源制約を前提とします。¹¹⁸

これらの資料が直接示すのは、Rust Projectが強い価値提案を行う一方、適用条件と改善課題も扱っているという事実です。したがって「Rustはすべてのシステムプログラミング問題を解決する」や「すべてのC/C++システムはRustで書き直すべきだ」という文をRust Projectの公式見解として帰属させるには、別の公式根拠が必要です。 本章は、そのような根拠なしに非公式投稿の強い表現をプロジェクト全体の公式主張へ統合しません。

分析では、次の四つの証拠層を互いに置き換えません。

証拠層	資料が直接示せること	資料だけでは言えないこと
公式Rust文書・RFC・project goals	公式の価値提案、保証説明、改善課題と手続き	全Rust利用者の態度、非公式言説の頻度
選択した公開投稿・討論	特定の文と論証形式の存在、その文脈での反論	コミュニティ全体の代表性、多数意見、長期傾向
事前定義されたcorpusとsampling	定義した母集団内の頻度、期間変化、プラットフォーム差	投稿者の内的動機や因果効果そのもの
インタビュー・実験・縦断・ネットワーク資料	設計に応じ、動機、露出、態度変化、拡散経路の一部	他の母集団・時期への無条件な一般化

この区別により、後続節で強い文を引用しても、その事例がまず立証するのは「その論証が存在する」ことだけです。同じ形式が一般的か、Rust利用者集団のアイデンティティを表すか、実際の採用を変えるかは別の問いとして残ります。

「銀の弾丸」と分類する推論形式

本書が問題にするのは、Rustの利点を強く述べる行為そのものではありません。技術的根拠と適用条件が保たれる限り、「Safe Rustは特定範囲のmemory-safetyエラーをコンパイル時に拒否する」「ある新規コンポーネントでRustを導入すると欠陥リスクを下げられる可能性がある」「Cargoの統合ワークフローが特定チームに有利である」といった主張は、それぞれ検証可能な工学命題です。「銀の弾丸」分類は、そのような条件付き命題から次のような追加推論が行われるときに適用します。

条件付き命題	より強い推論	追加で必要な証拠
Safe Rustは定義された範囲でmemory-safety保証を提供する	したがってすべてのシステムでRustが最も安全、または唯一責任ある選択である	他の危険分類、workload、FFI/`unsafe`、運用・保証/認証条件を含む比較
特定組織の新規Rustコードで良い結果が観察された	したがって既存システムの全面Rust書き直しが一般に最善である	代替戦略、migrationコスト、同時変更、長期保守、失敗事例を含む比較
選択した公開事例でC/C++とRustが頻繁に比較される	したがって他言語は意図的に排除され、言説のアジェンダが掌握された	定義済みcorpus、比較対象選択の原因、露出・受け手資料
一部投稿で批判者の資格・地位を判断する表現が現れる	したがってRustコミュニティ全体が批判を排除する	代表標本、プラットフォーム・期間別頻度、反対事例、moderation文脈

右端の証拠が満たされないなら、本書は強い結論を採用しません。反対に、Rust批判的な事例を数件選び、「Rustには実質的利点がない」や「Rust利用者は一般に非合理的だ」と結論するのも同じ誤りです。分析基準は賛否の双方に対称的に適用します。

「形成過程」は現時点では検証対象のモデルである

2.3節で確認したとおり、Rust Projectが安全性、性能、並行性、生産性、ツール体験を公式価値として繰り返し提示してきたことは文書から確認できます。³⁰ しかし、公式メッセージが非公式言説でどの程度繰り返されたか、反復の過程で限定条件がどの程度失われたか、その結果として受け手の評価基準が変わったかは別の経験的問題です。²⁹

したがって本節は、「公式の価値提案 → 非公式な反復 → 限定条件の消失 → 普遍化された選択命題 → 批判への防御的反応」という経路を、すでに立証された歴史的事実ではなく、将来のcorpus分析で試験できるモデルとして扱います。各矢印には異なる資料が必要です。公式文書の頻度分析だけでは非公式な反復を立証できず、非公式な反復だけでは受け手への効果を立証できず、強い反論文だけでは投稿者の心理的動機を判定できません。

C/C++が比較対象として頻繁に現れ、Ada/SPARKは少なく見えるという現象にも同じ原則を適用します。第7章の実際の産業事例のように、既存C/C++コードと新規Rustコードの変更戦略が直接の争点である文脈では、C/C++比較が技術的に自然な場合があります。一方、情報アクセス、教育経験、市場露出、意図的フレーミングのどれが比較対象選択にどの程度寄与したかを判定するには、定義された言説資料と露出・背景資料が必要です。代替案への言及が少ないという観察だけで、意図的排除や「言説主導権の確保」を原因として確定しません。

心理・集団説明は診断ではなく競合仮説である

認知的不協和理論は矛盾する認知と態度調整の可能性を、社会的アイデンティティ理論は集団分類と内集団バイアスの可能性を説明する一般理論です。ソーシャルメディアのエコーチェンバー研究も、プラットフォーム別の相互作用構造や同質的な接続が情報拡散に影響しうることを示します。¹¹⁹ しかし、こうした一般理論の名前をRust投稿に付けるだけで、そのメカニズムがそこで立証されるわけではありません。

たとえば、ある投稿者がRust学習に多くの時間を投じ、批判的意見に強く反応したことが同時に観察されても、それだけで認知的不協和が反応の原因だとは判定できません。技術的誤解を訂正しようとしたのかもしれず、質問の前提が誤っていると判断したのかもしれず、単に強い修辞的習慣かもしれません。同様に、少数の同質的な討論だけでRust関連空間全体がエコーチェンバーだと結論することはできません。その主張には、利用者間の接続、接する情報、相互作用の同質性、時間変化、比較プラットフォームの測定が必要です。

memory safetyの公式強調と「アジェンダ掌握」主張の分離

Rustの公式コミュニケーションがmemory safety、reliability、performanceなどを重要な価値として前面に掲げてきたことは、2.3節の一次資料で確認しました。³⁰ しかし「Rustがシステムプログラミングのmemory-safetyアジェンダを掌握した」あるいは「開発者はRustのためにmemory safetyを重要な基準と認識するようになった」という文は、受け手の重要度認識の変化まで含む、より強い主張です。元来のagenda-setting研究のように、メッセージの強調度と受け手の認識を結びつける資料がなければ、本書が確認できるのは公式の強調とそのメッセージの存在までです。²⁹

したがって、Ada/SPARK、GC言語、あるいはmodernized C/C++が公開討論で相対的に少なく見えるという印象を、直ちにRustによる「アジェンダ掌握」の効果とは解釈しません。その命題の検証には、期間とプラットフォームを定めたcorpus、言語別・話題別露出量、検索・推薦環境、受け手調査または実験が必要です。現段階では研究可能な仮説であり、本章の確定結論ではありません。

情報生態系とLLM効果の境界

Web由来の学習データの分布とフィルタリングが、言語モデル出力の分布に影響しうる一般的根拠はあります。¹¹⁶ しかし、そこから「Rustを肯定する文章が多いのでLLMはRustを過大評価する」と直結させることはできません。まずRust、C/C++、Ada/SPARKなど関連技術の実際のcorpus比率と文脈を測定し、どのモデルがどの資料で学習されたか、または代替可能な評価corpusを定め、質問表現と評価基準を統制した反復実験が必要です。

したがって本書でLLMは可能な二次情報経路としてのみ扱います。特定モデルがRustを先に挙げた数回の回答は、そのモデルの学習資料分布や共同体言説の因果効果を立証しません。逆に、その効果がないと断定する根拠もありません。この問題は、再現可能なモデル・プロンプト・評価設計が整った時点で、別の研究課題として扱うのが妥当です。

中間結論

現在の資料から確認できるのは三点です。第一に、Rust Projectは安全性・性能・信頼性・生産性などの強い価値提案を公式に提示する一方、適用条件と未完了の改善課題も扱っています。第二に、後続節の選択事例は、条件付き技術命題が普遍化・置換・地位判断へ拡張される論証形式の存在を検討するために使えます。第三に、その形式の頻度、コミュニティ全体のアイデンティティ、投稿者の心理、新規開発者・組織・LLMへの効果は、現在のcorpusと研究設計からは確定できません。

この境界がRQ5の核心です。技術の実際の保証と利点はそれ自体として評価し、その利点から「唯一の選択」や人の資格判断へ移る追加前提は別に明示し、選択された事例が示す範囲を超えてコミュニティ全体へ一般化しません。次の8.2節では、この基準を「完全置換」と「書き直しだけが改善」という変更戦略の主張に適用します。

8.2 「完全置換」と「書き直しだけが改善」という物語の限界

本節は、将来RustがC/C++の一部領域でより大きな比率を占めるかを予測する市場予測ではありません。また、以下のような主張が公開言説でどれほど一般的かを測定するものでもありません。分析対象は、次のように異なる命題を一つの結論へまとめる際に生じる推論の飛躍です。

Rustは特定の欠陥分類に対してより強いデフォルト保証を提供する。
既存システムの中にはRust導入から利益を得られるものがある。
特定分野では長期的にRustの利用比率が高まる可能性がある。
したがって、すべての既存C/C++システムはRustで全面的に書き直すべきである。
したがって、同一言語内のrefactoring・modernization・hardeningには意味がない。

前の三文はそれぞれ、保証比較、条件付き変更戦略、将来の採用予測に関する別々の命題です。後ろの二文は、あらゆるシステムと変更戦略を対象にするはるかに強い処方です。前の命題が真でも、後ろの結論は自動的には導かれません。本節の「完全置換」と「書き直しだけが改善」という表現は、特定人物やRust Projectからの直接引用ではなく、そのように普遍化された論理構造を検査するための合成命題です。公開事例における頻度や代表性を論じるには、8.1節のcorpus基準を別途満たす必要があります。⁵⁸

1. 変更戦略の名称を変えると選択空間が消える

3.3節では、保守と欠陥hardening、refactoring、modernization、selective replacement、新規コンポーネント導入、full rewriteを異なる変更単位として定義しました。狭義のrefactoringは観察可能な動作を保ちながら内部構造を変える作業であり、別言語による新実装はselective replacementやrewriteに該当しえます。⁴⁵

したがって「C/C++の本当のrefactoringはRustへのrewriteだけだ」という合成命題は、まず用語のカテゴリを変更します。refactoringをあらゆる改善という意味に広げたうえで、その中の一戦略である言語置換を再び唯一のrefactoringと定義すれば、結論が定義の中に入ります。すると次の問いは比較される前に消えてしまいます。

既存動作と互換性をどの程度保存する必要があるか。
リスクはシステム全体に分布しているか、特定境界に集中しているか。
同じ言語のままownership・interface・testability・observabilityを改善できるか。
新機能だけをRustで書く、または高リスクmoduleだけを置換できるか。
既存architecture自体が要件を妨げ、広範な再設計が必要か。

答えが異なれば、同じcodebase内でも異なる戦略が合理的になりえます。戦略名を先に一つへまとめても、その比較を代替できません。

2. 「完全な保証ではない」と「効果がない」は別の命題である

C/C++内部のguideline、RAII、smart pointer、静的解析、sanitizer、fuzzing、隔離、hardeningは、Safe Rustと同じ言語レベルのmemory-safety contractを提供しません。3.3節で確認したように、一部の手段はconventionやtoolchain設定に依存し、動的解析は実行された経路で欠陥を検出し、計測には資源コストとproduction適用境界があります。⁴⁶

しかし、Safe Rustと同じ保証を提供しないことは、工学的効果が0であることを意味しません。 raw pointerの範囲を縮小し、ownership境界を明示し、CIで欠陥をより早く検出し、危険なコードを隔離し、rollbackとobservabilityを改善すれば、対象リスクの発生確率や影響範囲を下げられます。その効果で十分かは、対象threat modelとassurance requirementに対して別途測定する必要があります。

逆方向にも同じ対称性が必要です。Safe Rustはsoundなsafe boundary内で特定のmemory-safety errorとdata raceを強く予防しますが、言語置換そのものが論理エラー、resource exhaustion、deadlock、性能回帰、機能欠落、unsafe・FFI contract error、deploymentやrollback failureを除去するわけではありません。C/C++改善には「すべてのリスク除去」を要求しながら、Rust rewriteには「特定の言語保証が存在する」だけでシステム全体の成功を十分に証明したと扱えば、非対称な証拠基準になります。

比較の核心は完全性競争ではなく、同一のdefect modelと運用目標に対して各戦略がどのリスクをどの程度予防・検出・緩和し、どの移行リスクを新たに作るかを同じ指標で見ることです。

3. 言語保証と変更方式は独立した二軸である

強い言語保証に価値があることと、その保証を得るためにどの範囲をどの方式で変更すべきかは別の問いです。Rustを導入しても新規コンポーネントだけに使うことも、狭いmoduleをselective replacementすることも、より広いrewriteを選ぶこともできます。逆にC/C++を維持しながらarchitecture、ownership discipline、test、analysis、isolationをmodernizeすることもできます。

Androidの公式memory-safety戦略は、この二軸を併用する実例です。新規native codeではmemory-safe languageを優先しつつ、既存C/C++にはsanitizer、memory tagging、hardeningを継続し、Rustと既存コードのinteroperabilityを投資対象としています。⁴⁷ Firmwareの事例でも、新規コードとセキュリティリスクの高い既存コンポーネントを優先する段階的なRust導入が文書化されています。¹¹²

これらの事例は「段階的導入が常に最善」という法則を立証しません。しかし、memory safetyを改善するには既存システム全体を先に廃棄しなければならない、という必要条件は成立しないことを示す可能性証拠です。逆に3.3節のbounded rewrite事例のように、境界が狭く、要件と検証範囲を制御でき、新実装の保証利益が大きい場合には、コンポーネント単位のrewriteも合理的です。変更戦略は成熟度の序列ではなく、条件付きの選択肢です。

4. interoperabilityは「共存の運命」でも「全面rewrite命令」でもない

従来の文面は、OS・driver・libraryがC ABIを標準interfaceとして使うため、RustはC ecosystemと長期共存せざるを得ない、と広く述べていました。この範囲は広すぎます。実際、既存C/C++ code、OS API、libraryとRustを接続する多くのmigrationでは、C ABIやrepr(C)のような明示的representation contractが重要な境界になります。しかし、すべてのsystem interfaceが一つのC ABIに還元されるわけではなく、この事実だけで共存期間や最終migration形態が決まるわけでもありません。¹⁰²

FFIがあれば独自のコストが生じるのは事実です。ownership transfer、allocator、buffer/string lifetime、error mapping、callback、cancellation、thread affinity、unwind/panic boundaryを明示する必要があり、細粒度crossingがhot path全体に広がれば性能・debugging・maintenance costが増える可能性があります。しかし結論はここでも条件付きです。

境界が狭く安定していれば、selective replacementと共存が費用効率的な場合があります。
境界が過度に複雑、または既存architectureが新要件を妨げるなら、より広いrewriteの方が単純な場合もあります。
新規コンポーネントなら、既存behaviorを再現せずにRustを導入できます。

したがって「FFIが必要だからRustは既存ecosystemを置換できない」と「FFIが面倒だからfull rewriteだけが答えだ」は反対方向の主張ですが、どちらも必要条件を省略した一般化です。7.3節のとおり、実際の判断単位はcrossing volume、boundary stability、ownership contract、latency/resource budget、dual-toolchain維持費、rollback capabilityです。

5. legacyは年齢ではなく将来リスクと資産で評価する

「legacy」という言葉も、記述から価値判断へ変わりやすい用語です。古い実装にはtechnical debtやsupport終了リスクが蓄積しうる一方、regression test、deployment手順、data format、顧客・機器互換性、operational workaround、incident-response knowledgeといった検証済み資産や暗黙仕様も蓄積しえます。software sustainment研究が指摘するように、softwareは物理的に摩耗する物体ではなく、実行環境・要件・欠陥・性能条件の変化によって保守費用が発生します。¹¹⁰

したがって「古いから捨てるべきだ」も「長く検証されたから変えるべきではない」も十分な命題ではありません。過去の開発費はsunk costになりえますが、今後保存すべきbehavior、migrationとparallel operationの費用、data conversion、retraining、outage risk、rollback riskは実際の将来費用です。Legacy modernization研究も、大規模・複雑システムでincremental modernization、coexistence、replacementをプロジェクト条件に応じて比較します。¹¹¹

したがってlegacyを「悪いもの」「保存すべきもの」と道徳化するのでなく、現在の欠陥・support stateと将来のmaintenance・transition costを同じdecision recordに入れるべきです。 使用言語の年齢から人の能力や責任感を判断しても、技術比較に必要な証拠にはなりません。具体的な資格・地位判断の論証構造は8.5節で別途扱います。

6. 「完全置換」は予測・処方・測定結果を区別する必要がある

「RustがC/C++を置換する」という文は、文脈によって少なくとも三つの機能を持ちます。

文の機能	必要な証拠	本章での判定基準
市場・ecosystem予測: Rustの利用比率が長期的に増える	定義されたpopulation、時系列adoption data、domain区分、予測modelと不確実性	一部企業事例やonline enthusiasmだけで市場全体の将来shareを確定しない
project処方: このsystemはRustへ広く置換した方がよい	defect distribution、assurance goal、specification/test資産、interop、migration/rollback、性能・resource、staffing/lifecycle costの比較	当該project条件で代替戦略と比較する必要がある
普遍命題: 意味のある改善はRust full rewriteだけである	実質的にすべての関連workloadと代替戦略を含む非常に強い比較根拠	現在の証拠では支持されず、反例可能性を閉じる過剰な一般化である

7.3節と7.4節のAndroid、Windows、AWS事例は、Rustが異なるproduction条件で実際に使用できることを示し、Androidはnew-code-firstとinteroperability戦略も文書化しています。しかしproduction feasibility、特定組織のobserved outcome、adoption scale、language-only causation、future market dominanceは別々の命題です。大企業の成功事例がfull rewriteの普遍的処方を作らないのと同様、あるlegacy migrationの難しさもRustの長期adoption見通しを反証しません。

大規模・長時間・極限環境では、特にmigration期間、old/new二重運用費、p95/p99 latency、peak memory、build/CI capacity、incident recovery、security-patch latency、FFI crossing volume、duplicated tooling、expert bus factor、rollback time、multi-year support costを戦略別に追跡する必要があります。「何％がRustか」より、どのリスクをどの変更単位で減らし、その移行のfailure costがいくらだったかの方が直接的な判断資料になりえます。

中間結論

RQ4について、保守、refactoring、modernization、新規Rust導入、selective replacement、full rewriteは互いを否定する段階ではなく条件付き戦略です。Safe Rustの強いmemory-safety保証はselective replacementやrewriteを正当化する重要な根拠になりえますが、それだけで変更範囲やmigration方式が自動的に決まるわけではありません。

RQ5について、「完全置換」や「書き直しだけが改善」という主張を分析する際には、保証命題から変更戦略へ、特定事例から普遍的処方へ、技術評価から人の地位判断へ移る追加前提を明示する必要があります。選択された公開事例を使う場合、まず示せるのはその論証形式の存在だけであり、定義されたcorpusなしにRustコミュニティ全体の頻度や意図を推論しません。

したがって本節の結論は「full rewriteは誤りだ」でも「Rust adoptionは不要だ」でもありません。現在の証拠が支持するより狭い結論は、言語保証と変更戦略を分離し、同一のdefect model・運用指標・移行費用で代替案を比較すべきだということです。次の8.3節では、技術コミュニティの競争的な物語を歴史的事例と比較するとき、どの類似性が説明に役立ち、どこで類推を止めるべきかを検討します。

8.3 技術言説の歴史的先例：1990～2000年代の OS 競争

本節の歴史比較は、「1990～2000年代のLinuxコミュニティと現在のRustコミュニティが同じ集団行動を繰り返している」という命題を立証するためのものではありません。当時のhacker culture、GNU/free software運動、open-source運動、Linux利用者・開発者、Unix関連のonline spaceは重なり合っていましたが、同一の母集団ではありませんでした。現在のRust ecosystemも、公式project、企業利用者、library maintainer、複数のonline spaceを一つの集団心理へまとめることはできません。したがって本節は、過去の事例を類似する論証構造を見つけるための比較資料として用いますが、その類似性自体を現在のRust言説の頻度・原因・効果の証拠にはしません。⁵⁸

歴史資料がまず示すのは単一のアイデンティティではなく内部の差である

1990年代末のfree softwareとopen sourceだけを見ても、価値のframingは一つではありませんでした。GNU/Free Software Foundationはsoftware freedomとcommunityを規範的価値の中心に置きました。一方、Open Source Initiativeの公式historyは、1998年に「open source」という名称を作った際、source-sharingの実用的・business-case上の利点をより効果的に伝え、哲学的・政治的含意の強い「free software」という標識と区別しようとしたと記録しています。¹²⁰ 同じsource-availableな共同開発の世界の中でも、何を中心価値として前面に出すかには差がありました。

Eric S. RaymondのThe Cathedral and the BazaarもLinux communityを一つの声として描かず、異なるagendaとapproachが混在する開発世界をbazaarにたとえました。¹²¹ これは当時の公開言説に強い物語やアイデンティティ表現がなかったという意味ではありません。むしろ、同時代資料を安全に読むなら、「Linux community」という名称だけで単一の価値・態度・論証を代表させてはならないということです。

M$とRTFMは存在が文書化された文化的標識だが、代表性は別問題である

The Jargon File 4.2.2（2000）は、当時のhacker slangの歴史的snapshotとして、M$をMicrosoftを指すnet abbreviationとして、RTFMをUnix hacker contextで質問を取るに足らない、または煩わしいとみなす際に用いられうる表現として記録しています。同文書の序文はhacker culture自体を、共通のrootsとvaluesを持ちながら緩やかにつながった複数のsubcultureの集合として説明し、slangがinclusion/exclusionの標識になりうると述べています。¹²²

この資料から言える範囲は限定されています。M$やRTFMのような表現が当時の技術文化の一部で実際に使われ、技術的言語が所属と境界を表現する機能を持ちえたことは文書化できます。しかし「Linux利用者の大半がMicrosoftを道徳的な敵と見なした」「初心者排除がLinuxコミュニティの一般規範だった」「CLI利用者がGUI利用者を体系的に劣っていると評価した」といった母集団レベルの命題は導けません。そのような主張には、mailing list、Usenet、forumなどについて定義した歴史的corpusとsamplingが必要です。

歴史的類推で比較できるのは「人」ではなく主張変換の構造である

現在のRust言説と過去のOS・FOSS言説を比較する際、比較単位として比較的安全なのは特定集団の性格ではなく、条件付き技術命題がより広い価値・アイデンティティ・地位命題へ変換される仕方です。時代や技術が異なっていても、次のような構造は分析できます。

比較可能な論証構造	歴史資料が示せること	Rust言説へ自動転移できないこと
技術的属性に価値言語が結びつく	freedom、community、pragmatic development modelなど複数の価値フレームが技術選択に実際に結びついた	Rust利用者が同じ価値・アイデンティティ構造を持つという結論
集団内のshorthandが所属・境界を表現する	hacker slangにinclusion/exclusion機能と`M$`、`RTFM`の用例が文書化されている	現在のRust空間に同じ強度・頻度のgatekeepingが存在するという結論
競争技術が物語上の比較対象に使われる	proprietary/open development、Microsoft/open sourceなど対立的framingの文書化事例がある	Rust対C/C++比較が同じ歴史的原因や動機で形成されたという結論
将来展望と現在の技術評価が混ざりうる	過去の運動・組織がadoptionとdiffusionを明示的目標としていた資料がある	現在のRustの将来market shareやcommunity-wideな楽観の程度

このように歴史資料は、可能な論証mechanismと分類基準を作る助けになります。しかし「過去にもそうだったからRustも同じだ」という推論は、歴史的類推そのものを本来提供できない証拠へ変えてしまいます。

差が大きいところでは類推を止めなければならない

1990～2000年代のOS・FOSS競争と現在のRust adoptionは、技術単位から異なります。OSはkernel、userspace、driver、application ecosystem、distribution、hardware supportが結合したplatform競争でした。Rustは複数OSや既存言語・libraryの内部へ部分導入できるprogramming languageであり、8.2節で見たselective replacementやnew-component adoptionが可能です。一つのdesktop OSを別のOSへ置き換える移行費用と、一つのcodebaseの一部moduleを別言語で実装する移行費用を同じ単位として扱うことはできません。

組織構造とmedia environmentも異なります。1990年代のUsenet、mailing list、hacker lexiconは、現在のReddit、social media、corporate engineering blog、Foundation governanceとは露出とmoderationの構造が異なります。またGNU、OSI、Linux kernel、distribution communityが別組織だったのと同様、Rust Foundation、Rust Project governance、企業のRust adoption、個別online forumの発言も別々の証拠単位です。歴史的表現一つを現在の公式Rust見解や利用者文化全体へ対応させることは、これらの差を消してしまいます。

したがって本節は、認知的不協和やsocial identityのような心理mechanismを歴史事例から現在へ「移植」しません。過去と現在で似た表現が観察されても、それが同じ心理原因や同じcommunity-level effectから生じたかは別の研究質問です。

中間結論

RQ5に対する歴史的先例の役割は限定的ですが有用です。同時代資料は、1990～2000年代のhacker、free-software、open-source、Linux周辺で技術的主張、価値frame、group shorthand、競争的物語が実際に共存していたことを示します。同時に、同じ資料はその世界が複数のsubcultureと異なる哲学的・実用的frameに分かれていたことも示します。

したがって過去事例から現在のRustコミュニティの心理や頻度を推論しません。代わりに、技術的事実 → 価値命題 → 普遍的選択命題 → 人への地位判断のように主張の範囲が変わる地点を探す比較ツールとしてだけ使用します。この歴史的境界を置けば、次の8.4節の公開討論事例も「過去と同じ集団行動」の証拠ではなく、個々の論証構造と反論可能性を検討する定性的資料として読むべきです。

8.4 批判的言説への論証パターン分析

8.1節で定めた証拠規則に従い、本節では少数の公開事例から Rust コミュニティ全体の反応頻度や心理を推定しません。分析単位は、主張 A に対して応答 B が実際に同じ命題を反駁しているのか、それとも範囲・比較基準・発話者評価へ移動しているのかです。公開事例を特定できる場合は事実関係と参加者の評価を分離し、直接の出典がない文は特定個人の引用ではなく論理構造を検討するための 合成例 と明示します。⁵⁸

また、すべての範囲限定が論点回避なのではありません。たとえば「この脆弱性は memory-safety vulnerability ではない」という文は、元の主張が「Rust の memory-safety contract が破れたのか」であれば直接的な範囲訂正です。しかし元の主張が「この safe API が重大な security bug を生みうるのか」であれば、その文だけでは security impact に答えていません。したがって、誤謬の名称を先に当てはめるのではなく、元の命題、応答が実際に扱う命題、未解決のまま残る命題を分けます。

8.4.1 Linux 7.2.1 における Rust 比率：測定値と重要性判断の分離

7.1節の最新 stable 再測定では、Linux 7.2.1 source tree の Rust SLOC は 114,481 行、総 30,518,591 SLOC の約 0.375%でした。この値から直接言えるのは、明示した cloc v2.04 手順による当該 tarball の source-tree compositionだけです。¹⁰⁶

したがって次の二文は同時に真でありえます。

「現在の stable kernel source における Rust の量的 footprint は 1% 未満である。」
「source footprint が小さくても、特定の driver や security boundary では技術的に重要でありうる。」

最初の文に対して「Rust code は重要な subsystem にあるので SLOC は無意味だ」と答えるなら、それは 重要性には関係する反論ですが、SLOC の測定値自体を反駁してはいません。逆に 0.375% だけから「Rust は kernel で重要ではない」「将来成長しない」と結論するのも測定範囲を超えます。

Google・Microsoft・AWS の別の production 事例を提示する応答にも同じ原則を適用します。これらは Rust が production で運用可能だという別の命題を支持しますが、Linux 7.2.1 の source 比率を変えません。元の論点が「Rust は production で使われているか」なら有効な反例になりえますが、「この kernel snapshot の何 % が Rust か」なら論点が移動しています。

発話者の使用言語や動機を指摘しても、測定手順の誤りは示せません。「測定者は Ada ユーザーだから信用できない」という 合成例 は、artifact、checksum、tool version、counting rule のどこが誤っているかを示さない限り source criticism ではなく発話者評価にとどまります。反対に、再現結果が異なる、または cloc の分類方法が不適切だという根拠を示すなら正当な方法論批判です。

8.4.2 memory leak：保証境界と運用上の重大性の分離

Rust Reference は memory/resource leak と destructor が実行されないことを unsafe と見なされない挙動に含め、std::mem::forget は safe function です。Rust Book も Rc<T> と RefCell<T> の strong-reference cycle により Safe Rust で leak が生じうることを説明します。⁴¹ したがって「この leak は Rust の memory-safety contract 違反ではない」という文は技術的に正しい場合があります。

しかし、長時間稼働 service で retained object が OOM、latency 増加、restart、availability 低下を引き起こしうるという運用上の問いは別です。「memory-safe だから問題ではない」と拡張すると、保証範囲と運用上の重大性を混同します。逆に leak が可能という事実だけで Safe Rust の use-after-free や invalid access に対する保証が無意味になるわけでもありません。

「開発者が Weak<T> を使うべきだった」という責任論も二層に分ける必要があります。特定の reference cycle の直接原因が application design にあるという説明は妥当な場合があります。しかし API が cycle をどれほど作りやすくするか、observability・quota・restart policy が十分か、library design でリスクを減らせるかは別の system design の問いです。責任帰属だけで運用リスクは消えません。

8.4.3 rav1d/dav1d：安全性範囲、性能帰属、保守の三つの問い

rav1d は仮想例ではなく、実際の公開論争を追跡できる事例です。ISRG の Prossimo は 2023 年、VideoLAN の C ベース AV1 decoder dav1d を Rust に移植する rav1d project を開始し、Immunant と協力しました。公式目標は dav1d の C code を Rust に移して memory safety を高めつつ、性能のため 既存 native assembly を維持し、dav1d との drop-in C API compatibility を保ち、assembly と upstream 変更を頻繁に同期しやすくすることでした。¹²³

2024 年の Prossimo/Immunant 技術報告は、性能上重要な多くの低水準処理が dav1d の native assembly で実装されているため再利用したと明記しています。同時に、利用可能な assembly をすべて有効にした測定でも decoding runtime の約半分は Rust code が占めると報告し、C2Rust の unsafe 出力を safe で idiomatic な Rust に段階的に変換しながら bounds check、threading model、buffer ownership のコストを分析しています。¹²³ したがって「rav1d の性能はすべて Rust が生み出した」と「Rust 部分は性能に何も寄与しない」はどちらも公式資料より強い主張です。

2025 年、Prossimo は rav1d が dav1d と同じ test を通過し Chromium でも動作する一方、当時 benchmark・input・platform により概ね 5% 遅いと報告し、性能差を縮める $20,000 bounty を公開しました。同年の rav1d 1.1.0 は dav1d 1.5.1 の性能改善を backport して同期したことを明記しています。¹²⁴

この構造をめぐる公開討論では三種類の批判が実際に提示されました。第一に native assembly を unsafe boundary で再利用する場合に「memory-safe decoder」と呼べる範囲はどこまでか。第二に dav1d の改善を rav1d に継続して backport する保守モデルは長期に持続可能か。第三に、別 fork が codec expertise と迅速な upstream bug response を同じ水準で維持できるか、という問いです。¹²⁵ この公開事例が示すのは そうした論点が実際に提起されたことであり、FFmpeg・VideoLAN 開発者全体や C/Rust コミュニティの合意ではありません。

この事例で最も重要なのは、異なる問いを一つにしないことです。安全性の問いは Rust に移した parser・control code と残る assembly/FFI boundary がそれぞれどの memory-safety invariant を持つかを問います。性能帰属の問いは Rust、reused assembly、algorithm、compiler、threading、optimization が結果にどれほど寄与するかを問います。保守の問いは upstream 同期費用、fork ownership、codec expertise、support horizon を問います。

したがって「assembly を再利用するから Rust port の安全性価値は 0」という結論は parser や higher-level C code を safe Rust に移した効果を無視します。逆に「memory-safe Rust decoder」を assembly とすべての外部境界まで無条件に保証する表現として読むべきでもありません。Prossimo 自身が assembly を unsafe native routine として残したと明記しているため、より正確には memory-unsafe C 領域を大きく減らしつつ性能上必要な native-assembly boundary を維持した port と表現できます。¹²³

同様に upstream 成果の帰属や協業倫理への批判は性能・安全性測定とは別の層です。rav1d が dav1d を基盤とし upstream assembly と変更を再利用することは公式に公開されています。その構造が正当な再利用か、credit が十分か、funding/maintenance model が長期的に望ましいかは governance と価値判断を追加で必要とします。「非対称的な貢献構造」や「知的誠実性」といった評価は前提を明示して論じるべきであり、その表現自体が benchmark や memory-safety の結果を代替しません。

8.4.4 `std::process::Command` CVE：memory safety と security の分離

2024 年に Rust Security Response WG が公開した CVE-2024-24576 は、Windows で std::process::Command が batch file の引数を十分に escape せず、攻撃者が argument を制御できる条件で任意の shell command 実行につながりうる欠陥でした。元の問題は Rust 1.77.2 で修正され、その後 mitigation bypass の別問題 CVE-2024-43402 が報告され Rust 1.81.0 で補完されました。⁴⁴

ここで「memory-safety vulnerability ではない」という説明は 欠陥分類として正しいものです。これは buffer overflow や use-after-free ではなく command argument/API contract の論理的 security flaw でした。しかし問いが「Safe Rust API にも重大な security bug が生じうるか」であれば、memory-safety の範囲だけを繰り返しても問い全体への回答にはなりません。

逆にこの CVE 一件から Rust の memory-safety contract が失敗したとも結論できません。正確な教訓は memory safety は security の一部分であり、safe API でも shell escaping、authorization、protocol、state-machine logic など別の security contract を誤って実装しうるということです。

8.4.5 Linux Rust Binder CVE：`unsafe` 境界と責任帰属

CVE-2025-68260 は Linux Rust Binder の death_list 処理で unsafe list removal と concurrent access の条件が一致せず、data race と pointer corruption が発生した実例です。この欠陥は Linux 6.18 に影響し、6.18.1 および 6.19 系列で修正されました。¹⁰⁷

「言語仕様自体が data race を safe として許可したわけではない」と「Rust abstraction の unsafe proof obligation が実装で失敗した」は同時に真でありえます。unsafe は欠陥が起きても language/library design の評価から除外する免責印ではなく、compiler が直接検証しない invariant を人が負う境界です。

問題を一人の開発者だけに帰属して「したがって Rust design とは無関係」と終えると、reviewability、abstraction boundary、synchronization contract、regression test という system-level の問いが残ります。逆に一件の CVE から「Rust kernel code も C と同じ程度に unsafe」と一般化するには matched workload と defect denominator が必要です。どちらも事例が直接示す範囲を超えます。

8.4.6 「Rust 以外に代替はない」：候補集合と要件の省略

以下は特定個人の直接引用ではなく、公開技術討論に現れうる構造を圧縮した 合成命題です。

合成例：「deployment environment を自由に選べない実戦 project では C++ を使えない。したがって Rust 以外に代替はない。」

第一の前提が特定 project で C++ を除外する十分な理由になる場合はあります。しかし 一つの候補を除外したことは、他のすべての候補も除外したことを意味しません。 「唯一の代替」を立証するには、少なくとも workload、latency・memory・real-time 要求、GC/VM の許容、binary・deployment 条件、認証、既存 ABI/library、support platform、組織人員、lifecycle を明示し、現実的な候補集合に同じ基準を適用する必要があります。

managed runtime を許容する backend・業務 system、GC なし native executable が必要な low-level software、強い run-time check や formal proof が要求される safety system では候補集合が異なります。既存 C/C++ asset が大きい system では、同一言語 modernization、高リスク module の選択的 Rust replacement、mixed-language architecture も候補です。したがって 「実戦 project」は要件ではなく、異なる domain を覆い隠す修辞的カテゴリです。

より正確な命題は条件付きです。GC なし native 実行、強い静的 memory safety、対象 platform support、組織の長期保守能力が同時に必要で、他の現実的候補がその条件を満たさないなら Rust は最も強い選択肢になりえます。しかしその比較が示されるまでは 有力な選択肢 と 唯一の代替 を区別すべきです。

8.4.7 応答を判定する共通手順

上の事例を一つの「Rust 防御パターン」にまとめて頻度を主張するのではなく、個々の応答を次の順序で判定する方が再現可能です。

段階	問い	判定例
1. 元の命題を固定	実際に何が主張されたか？	source 比率、memory-safety contract、全体 security、運用 severity、migration suitability などを分離
2. 応答命題を特定	応答は同じ命題を扱うか？	scope correction、別の長所の提示、発話者評価を区別
3. 証拠単位を確認	artifact・公式 advisory・benchmark・case・opinion のどれか？	測定値と解釈、公式事実と参加者の価値判断を分離
4. 比較基準の対称性	賛否に同じ denominator と基準を使うか？	C/C++ には全 security を、Rust には memory safety だけを要求するような非対称を点検
5. 未解決命題を記録	応答後も何が未解決か？	運用影響、causal attribution、external validity、maintenance cost など

本節で red herring、ad hominem、genetic fallacy といった名称は 判定の出発点ではなく分析後の要約ラベルです。発話者の理解水準が evidence quality に実際に関係する専門領域もあり、別企業の事例が元の普遍命題への直接反例になる場合もあります。文脈を除いて表現一つだけで誤謬を宣言すれば、本書が批判する過剰一般化を繰り返すことになります。

中間結論

RQ5 で重要なのは批判への応答が強いか弱いかではなく、論証の範囲がどう移動するかです。Linux の 0.375% は source composition、memory leak は memory-safety UB と異なる operational risk、rav1d/dav1d 論争は safety scope・performance attribution・fork maintenance を分離すべき事例であり、Command と Binder CVE はそれぞれ logical security contract と unsafe proof obligation の境界を示します。

これらの事例は Rust の長所を否定せず、Rust コミュニティが一般に防御的だとも立証しません。逆に「定義上 memory-safe」「大企業が使っている」「開発者のミスだ」といった文が現れたという理由だけで元の批判が自動的に誤りになるわけでもありません。各応答が元の命題のどの部分を実際に反駁し、どの部分を別の層へ移したのかを分解する必要があります。

次の 8.5 節では、この論証の移動が技術そのものを越えて発話者の 資格・正常性・知能といった地位判断へ変わる場合を別に検討します。

8.5 技術選択の地位化：資格、正常性、知能序列と言説的排除

技術的な議論では、発言者の経験や専門性が、証拠からどこまで結論を導けるかを判断するうえで関係する場合があります。特定言語がどの条件でより強い選択肢になるかを評価し、その言語を実際に扱う能力があるかを確認することも、正当な工学的判断に含まれます。しかし、技術の長所が、その技術を選んだ人の一般的優越性へ変換され、非利用者の知能・資格・正常性を低く評価する根拠として用いられるなら、議論は技術評価から人と集団の地位判定へ移ります。

本書では、この移動を技術選択の地位化と呼びます。これは広く合意された単一の心理学用語や形式的誤謬の名称ではなく、技術言説で生じ得る次の連鎖を分解するための記述的カテゴリーです。現在、本書にはこの連鎖の頻度や代表性を推定できる事前定義 corpus がないため、以下の段階は共同体全体の経験的な順序モデルではなく、論証分類の枠組みとして用います。

特定技術の条件付きの長所が、普遍的優越性へ拡張されます。
その技術を理解または選択した事実が、利用者の知的・職業的優越性を示す標識として使われます。
非利用者は、異なる条件で異なる選択をした人ではなく、無知または遅れた外集団として分類されます。
技術的反論はその内容よりも、発言者の劣等感、恐怖、埋没費用、理解不足によって説明されます。
反対や不快感まで既存の地位分類を確認する証拠として吸収されると、論証は自己封鎖的な構造を持ちます。

本節は、特定個人の性格、精神状態、臨床的特性を推定するものではありません。分析対象は、公開文から判別できる分類基準、証明責任、論証構造です。また、本節の引用形式の文は特定個人の逐語引用ではなく、論理的な移動を明確にするために再構成した合成例（composite example）です。したがって合成例は、実際の頻度・代表性や Rust 利用者全体の態度を示す証拠ではありません。実際の公開事例を用いる場合も 8.1 節の sampling boundary をそのまま適用します。⁵⁸

1. 専門性の検討と発言者排除の区別

専門知識の不足を指摘することが、常にゲートキーピングになるわけではありません。特定の unsafe コードの健全性、コンパイラ実装、OS カーネルインターフェースのように高度な専門知識を要する問題では、関連経験と証拠の質を確認することは正当です。ただし、次のような場合、専門性の検討は論点を評価する手段ではなく、発言者を排除する装置になり得ます。

批判内容と関係のない所属、使用言語、職名だけを理由に主張を退ける場合
提示された資料や再現可能な結果を検討せず、資格不足を結論とする場合
反例が現れた後にだけ「真の開発者」や「真のシステムプログラミング」の基準を新たに設定する場合
同程度の証拠に対して、支持者と批判者へ異なる専門性基準を適用する場合

合成例：「あなたのプロジェクトはイベントループやスケジューラを自前で実装していないので、真のシステムプログラミングではありません。したがって、エコシステムや生産性に関するあなたの経験には評価価値がありません。」

この応答は、問題の評価にどのような経験が必要なのかを先に説明せず、発言者の仕事を範囲外へ押し出すことで批判の効力を消します。ただし、すべての範囲区分が真のスコットランド人の誤謬（No True Scotsman Fallacy）であるわけではありません。この誤謬が成立するには、一般に、ある集団についての一般化が先に提示され、それに反する事例が現れた後、反例を排除するために集団の定義が恣意的に狭められる必要があります。¹²⁶ そのような先行する一般化と事後的な再定義が確認できない場合、その発言をゲートキーピングや不当な範囲制限として批判することはできても、直ちに真のスコットランド人の誤謬と断定すべきではありません。

2. 技術的優越性と利用者の地位の結合

ある言語が特定条件で他の選択肢より安全または生産的だという判断は、利用者個人の一般知能や人間的価値を含みません。技術に関する命題と、その技術を選んだ人に関する命題は、異なる証拠を必要とします。次の合成例は、技術の条件付き優越性 → 利用者の一般的優越性という移動を検討します。

合成例：「この言語の根本原理を理解できる開発者なら、最終的にはこの言語を選びます。別の選択に固執する人は、思考水準が低いか、過去の経歴に埋没しています。」

この構造では、技術の優越性と利用者の優越性が循環的に互いを保証します。優越した人だから優越した技術を選び、その技術を選んだから優越した人に分類されます。しかし、言語選択は、要件、既存コード、人員、ツール、認証、配布環境、リアルタイム制約、移行コスト、組織のリスク許容度によって異なり得ます。同じ事実を理解する開発者でも、条件が異なれば異なる結論に到達し得ます。

技術が利用者の地位標識として機能し始めると、技術批判の意味も変わります。言語の性能、安全保証、エコシステムへの批判が、特定主張の適用範囲を検討する行為ではなく、その言語を選んだ利用者や内集団の洞察力・先駆性・職業的価値を否定する行為として解釈されることがあります。その結果、技術的反論に答える代わりに、批判者の資格や心理を評価する応答が増えます。

この分析は、強い技術的選好や共同体への所属感自体を問題にしません。適用条件と反例を明示しながら技術を強く推奨し、非利用者の能力と価値を別に評価するなら、技術的主張と利用者の地位は分離されています。問題は、一つの技術選択が人全体の序列を判定する代理指標として使われるときに生じます。

3. 正常性の規定と内集団・外集団の構成

本書では、独立した根拠なしに特定エコシステムの慣行を普遍的基準として扱う修辞パターンを、便宜上「正常性の規定（defining normality）」と呼びます。これは広く合意された単一の形式的誤謬の名称ではなく、技術言説を分析するための記述的カテゴリーです。

「正常」「標準」「一般的」という表現自体が誤りなのではありません。国際標準、明示された組織規則、市場占有率、互換性要件、測定された利用頻度によって範囲を限定するなら、有用な技術表現になり得ます。問題は、評価基準と対象母集団を示さず、自分が慣れたエコシステムの選択を、すべての言語と組織が従うべきデフォルトとして提示する場合に生じます。

合成例：「正常な言語なら、ビルド、パッケージ管理、コード解析、エディタ支援を一つの決められた方式で提供すべきです。新しい標準を受け入れられない開発者は、すでに遅れた世代です。」

この例は、技術構成の正常性と利用者の正常性を一つの文の中で結合します。第一文はツール構成の基準を提示しますが、第二文はその基準に従わない人を遅れた外集団に分類します。このとき「正常」「現代的」「真の」「責任ある」といった表現は、技術的属性を記述するだけでなく、内集団の資格と外集団の欠陥を規定する役割を果たします。

実際の開発環境には、統合 IDE 中心、独立した言語サーバ中心、コマンドラインツール中心、組織内プラットフォーム中心のモデルが併存します。各モデルは、導入の容易さ、自動化可能性、交換可能性、オフライン運用、長期サポート、組織統制において異なるコストを持ちます。したがって、特定のツール構成や言語が利用者の現代性や正常性を普遍的に証明すると宣言するのではなく、どの利用者と運用条件にどの選択が適するかを比較すべきです。

4. 言語熟達、認知効果、職務成果の区別

次の合成例は、特定言語を学ぶ能力や意思を一般知能およびプログラマとしての職業的適性へ直接結び付ける命題を検討します。

合成例：「Rust を学ぶ知能がない、または学ぼうとしない人には、結局、職業プログラマとしての資格もありません。」

この主張は、互いに異なる四つの問題を一つにまとめています。

学習と認知課題への転移：プログラミング教育には、言語の概念や道具だけでなく、一部の問題解決戦略の学習も含まれます。105研究・539効果量を統合したメタ分析は、プログラミング学習について中程度の全体転移効果（g = 0.49）と遠転移効果（g = 0.47）を報告しました。これは、プログラミング教育が一部の認知課題へ肯定的影響を与える可能性を支持します。¹²⁷
一般知能と人の序列：特定課題の成績向上や学習転移は、それだけで心理測定上の一般知能が包括的に上昇したことや、学習者と非学習者の人間的・職業的序列を意味しません。そのような強い結論には、別個の測定と研究設計が必要です。
Rust 固有効果と選択効果：上記メタ分析は複数のプログラミング言語と教育環境を統合したもので、Rust に固有の認知効果を検証していません。また、Rust を自発的に選んだ集団に高い事前知識や技術関心が見られても、教育機会、業務経験、自己選択を統制しなければ、言語学習が差を生んだとは断定できません。
職務関連性：Rust コードの作成と保守が中心業務である職種では、Rust の熟達や学習能力が直接の選考基準になり得ます。一方、他の言語、ドメイン、役割の開発者を評価する場合は、設計、デバッグ、テスト、運用、セキュリティ、協働、ドメイン知識など実業務に必要な能力を個別に検討する必要があります。方法論的な参考例として、米国の Uniform Guidelines on Employee Selection Procedures は、選考基準の妥当性を重要な職務と、それに必要な知識・技能・能力へ結び付け、評判や逸話だけで妥当性を仮定しないよう求めています。¹²⁸

したがって、「Rust を熟達している」という事実は Rust に関する特定能力の証拠にはなり得ますが、それだけであらゆるソフトウェア開発業務の成果や一般知能を代表するわけではありません。逆に、まだ Rust を学んでいない、または学習に困難を感じるという事実だけで、プログラマとしての可能性を否定することもできません。

5. 技術的反論の心理化と動機推定

認知的不協和、社会的アイデンティティ、埋没費用のような心理・社会的説明は、技術選択を解釈する競合仮説になり得ます。しかし 8.1 節で区別した通り、一般理論の存在だけで特定の Rust 発話者の動機や共同体レベルのメカニズムが立証されるわけではありません。¹¹⁹ 教育・コード・経歴への投資や新技術への不確実性が特定の判断に影響したと述べるには、その人物と状況に関する別の資料が必要です。動機推定だけで反論の内容を退けることもできません。

合成例：「既存言語の限界を認められないのは、これまで投資した経歴とコードが無価値になることを恐れているからです。技術的理由を述べていますが、実際には自分の地位を守るための抵抗です。」

この応答は、性能、生産性、エコシステム、認証、採用、既存システムとの統合といった争点を検討せず、発言者の推定動機に置き換えます。埋没費用や地位防衛が一部存在するとしても、既存システムを維持または段階的に移行すべきだという技術的主張が偽になるわけではありません。動機の事実性と主張内容の真偽は別々に評価すべきです。

動機推定は対称的に適用されなければなりません。批判者が既存技術へ投資したという理由だけで主張を退けられないなら、支持者が新言語の学習、プロジェクト、評判、集団アイデンティティへ投資したという理由だけで、その主張を退けることもできません。いずれの場合も、コード、測定結果、コスト、リスク、適用範囲を先に検討すべきです。

6. 選好技術の普遍化と反復的承認

技術選択が利用者の地位と結合すると、特定技術の実際の長所が本来の適用範囲を越えて拡張されることがあります。メモリ安全性の強みが、すべてのソフトウェアのデフォルト言語であるべきだという結論へ、特定サービスや新規コンポーネントの成功が、すべての既存システムを書き直すべきだという結論へ移る場合です。このとき、選好技術は複数の工学的手段の一つではなく、多様な問題へ繰り返し適用される既定の答えとして扱われます。

合成例：「セキュリティ、性能、生産性、保守性、開発者水準の問題は、結局同じ原因から生じます。この言語をデフォルトにすれば、古い技術と古い思考様式を一緒に置き換えられます。」

異なる問題は異なる比較基準と証拠を必要とします。メモリ安全性、スループット、レイテンシ、認証可能性、開発生産性、人材確保、レガシー統合は、一つの指標へ還元できません。ある領域の強い結果を別領域の優越性へ移すには、追加の根拠が必要です。産業事例と政策資料の適用範囲は8.7節で別途検討します。

ある空間で同じ主張と地位分類が反復して承認されると仮定すれば、その反復が主張自体の証拠として受け取られる可能性を分析できます。しかし本書は、Rust 関連空間の network homophily、exposure、echo-chamber の程度を測定していません。¹¹⁹ したがって実際の内集団合意の大きさや反復頻度を前提とせず、観察された同意と独立した技術検証を区別するという規則だけを適用します。

7. 自己封鎖的論証

本書における自己封鎖的論証（self-sealing argument）とは、反対証拠や反応まで既存結論の証拠として吸収し、どの観察も結論を弱められないようにする論証構造を指します。ここでは分析のための記述的名称として用いており、心理的動機の推定がすべて自動的に同じ誤りになるという意味ではありません。

合成例：「正常な知能を持つプログラマなら、Rust の優越性と学ぶ価値を認めます。反対する人は理解能力が不足しており、この評価に不快感を示すことは、自分の劣等性を自覚している証拠です。」

この論証は次のような閉じた構造を持ちます。

結論の先取り：Rust の普遍的優越性と賛同者の正常性を、検証すべき結論ではなく分類の前提にします。同意は正常性の証拠、反対は劣等性の証拠になります。
技術と利用者地位の循環的保証：優越した人だから Rust を選び、Rust を選んだから優越した人だという分類が互いを支えます。どちらも独立した測定で検証されていません。
技術的反論の心理化：性能、生産性、エコシステム、認証、採用、既存システムとの統合に関する反論を検討せず、劣等感、恐怖、埋没費用、抵抗といった推定動機へ置き換えます。
反証可能性の除去：反対、不快感、無関心、説明の試みをすべて既存結論の証拠として解釈するなら、どの観察も主張を修正させることができません。
非対称な証明責任：批判者には言語の長所をすべて認め、学習障壁を克服する義務を課す一方、優越性を主張する側には比較資料、適用範囲、失敗条件の提示を求めません。
条件付き技術判断と人の序列の混同：メモリ安全性と性能が同時に重要な領域で Rust は強い選択肢になり、その条件では学習コストを負担する価値があります。しかし、すべてのプログラマが同じ技術を選ぶべきことや、別の選択が知能の劣等性を示すことは導けません。

8. 地位化主張を検討する基準

技術的な議論で資格、正常性、利用者の地位に関する主張を評価する際は、次の問いを区別する必要があります。

問題の真偽を判断するために、実際にどの専門知識が必要か。
その専門性基準は、反論が提示される前に明示されていたか。
発言者の背景とは独立して、コード、資料、測定結果、再現手順を検討したか。
技術の長所に関する証拠が、利用者の一般知能や職業的優越性まで実際に測定しているか。
非利用者の選択を、要件やコストではなく、無知、劣等感、恐怖、埋没費用だけで説明していないか。
支持者と批判者に、同じ証拠・専門性・動機推定の基準を適用しているか。
特定領域の成功を、他の問題やすべての既存システムへ拡張する追加根拠があるか。
内集団の反復的同意と、独立した技術検証を区別しているか。
どの反例や結果が出れば、既存判断を修正するか。
言語熟達を評価するなら、それが当該職務の重要な作業とどのように関係するか。

結論として、専門性、標準、言語熟達、技術的勧告はいずれも正当な評価要素になり得ますが、適用範囲と証拠を明示しなければなりません。特定言語の長所をその利用者の一般的優越性へ変換し、非利用者を劣った外集団に分類し、反対意見を発言者の欠陥だけで説明する言説は、技術的事実と職務関連性を検討する前に人の地位を決定します。

技術は、利用者の知能や人間的価値を代わりに測定する標識ではありません。強い技術的成果を認めることと、その成果をすべての問題、すべての組織、すべての開発者の序列へ拡張しないことは両立します。技術選択の地位化を分離する目的は、特定共同体を評価下げすることではなく、条件付きの工学判断を検証可能な主張へ戻すことにあります。

8.6 2023年商標政策論争とガバナンス

2023年の Rust 商標政策論争は、「Foundation が一方的に政策を押し付け、community の反発で撤回した」という一文だけでは正確に要約できません。公式記録を時系列で見ると、draft 作成、公開 consultation、feedback と手続きへの批判、長期の revision、最終 approval は別の段階でした。本節では公開反応の量を community 全体を代表する投票結果とは見なさず、各段階でどの組織がどの責任を担い、当事組織が何を認めたのかを確認します。

8.6.1 2023年の文書は施行済み政策ではなく consultation draft だった

Rust Foundation は2022年に商標政策の review と survey を始め、2023年4月6日に更新版 Rust Trademark Policy の draft を公開 feedback form とともに提示しました。Foundation の4月17日の説明によれば、draft と10日間の consultation は Rust Foundation、Rust Project Directors、Trademark Working Group、open-source policy の経験を持つ legal counsel の協働で作成されました。したがって Foundation staff だけが draft を独自に作成し Rust Project に一方的に課そうとしたと記述するのは、公式記録と一致しません。¹²⁹

同時に、手続き上の問題も当事者自身が認めています。4月12日、Project Directors などの参加者は、より広い Rust Project が過程に十分含まれておらず、process と communication がより良くあるべきだったと述べました。Foundation も consultation 終了後、透明性が不十分だったことを謝罪し、initial draft には対応すべき妥当な批判が多数あると認めました。¹²⁹ したがって Foundation 単独の強行 と 手続き上の問題はなかった という両方の説明が証拠より強いものです。

2023年4月 draft に多くの公開批判と feedback-form 回答が寄せられたこと自体は公式資料で確認できます。しかし回答者は無作為標本ではなく、feedback form は政策に関心を持つ人が自発的に参加する consultation 手段です。したがって「Rust 利用者の大半が反対した」としたり反対率を推定したりする資料には使えません。2024年に Foundation が公開した feedback summary が直接示すのは、提出された回答で、意図しない misuse の結果、法律用語の明確性、blog・talk・crate 名・merchandise・logo modification などの範囲が繰り返し懸念されたことまでです。¹³⁰

8.6.2 「撤回」ではなく長期の revision と最終 approval

2023年 consultation の終了後、Foundation は draft を施行すると発表しませんでした。代わりに feedback を共同で検討し、新しい draft を作成し、Foundation と Rust Project leadership の双方が納得できる政策になるまで何も施行しないと述べました。¹²⁹ 作業は短期間では終わりませんでした。2023年に Rust Leadership Council は Foundation との interaction と Project Directors の役割を明確化することを優先課題とし、2024年6月の Foundation board minutes は legal counsel の availability により trademark work が遅れていたと記録しています。¹³¹

2024年11月、Leadership Council と Foundation は revised draft を再公開して final feedback を求めました。Foundation の説明では、2023年の提出意見を踏まえ、package-name restriction を削除し、logo の色変更や一部の非商用 merchandise・event・publication のルールをより permissive または明確にするなど複数項目が変更されました。¹³⁰ この段階も最終施行政策ではなく final feedback のための draft でした。

2025年1月23日、Rust Foundation は Project Directors を含む Foundation Board が更新政策を承認したと発表しました。現在の Rust Language Trademark Policy は Foundation が Rust と Cargo の trademarks/logos を所有・保護するとしつつ、Rust programming-language project は Leadership Council により govern されると区別しています。現在の policy は、Rust との互換性を正確に述べること、crate/repository 名で Rust を使うこと、小規模な非営利 event、book・blog・publication など多くの用途を事前承認なしで認める一方、official affiliation を示す用途や一部の商業的・modified distribution には permission を求めます。¹³²

8.6.3 Foundation governance と Rust Project governance を同一視しない

現在の Rust governance 文書は、Leadership Council を Rust Project 全体の成功と組織調整を担う top-level body とし、主要な technical decision は RFC と関連 Project team の deliberation を通じて行われると説明します。一方 Rust Foundation は独立した nonprofit として trademark、legal/administrative work、finance、infrastructure support などの stewardship を担います。Project Directors は Rust Project の利益を Foundation Board に反映する経路であり、現在の説明では Project と Foundation の関係を担当する elected group です。¹³¹

したがって trademark controversy を language feature decision、moderation、Foundation の legal responsibility と一つの権力軸にまとめると、組織構造を誤読します。

問題	主な制度的単位	この事例から確認できる範囲
Rust/Cargo trademark の所有・保護と使用許可	Rust Foundation と Foundation Board	legal trademark stewardship と最終 policy approval
Rust Project の組織方向と cross-team coordination	Leadership Council	Project-level governance と Foundation relationship の調整
language・compiler・library 等の technical decision	各 Rust Project team と RFC process	technical trade-off と consensus procedure。trademark policy とは別
Foundation Board で Project interest を代表	Project Directors	Foundation-related decision に Project perspective を接続する制度的経路
conduct standard の執行と conflict mediation	Rust Project Moderation team	Code of Conduct と community-standard の領域。trademark ownership とは別

8.6.4 この論争から何を governance evidence として使えるか

この事例が強く示すのは、policy content だけでなく policy-making process も trust と acceptability に影響し得ることを当事組織が自ら認め、process を変更した事実です。2023年、Project 側参加者と Foundation は communication と wider-project inclusion の不足を認め、その後 Leadership Council は Foundation interaction と Project Director role の明確化を優先課題として扱いました。2024 revision は公開 feedback の具体的懸念を反映し、2025 final policy は Board approval を経ました。¹²⁹¹³⁰¹³²

しかし、より強い結論には追加の境界が必要です。feedback の量だけでは全 Rust user population の trust level や opposition rate を測れず、Crab-lang のような protest fork discussion の存在だけで実際の ecosystem fragmentation risk の確率も推定できません。また process problem の認識は、Foundation や Project participant が意図的に community control の拡大を狙ったという心理的・政治的 motive を立証しません。

逆に、final policy が2025年に approved されたことだけで2023年の criticism が根拠不足だったとも言えません。実際の revision では crate/package naming、logo modification、publication、merchandise、non-endorsement など複数の issue が変更または明確化されました。¹³⁰ draft への criticism の妥当性、revision process の改善、current policy の適切性は別々の評価対象です。

中間結論

RQ5 の観点では、2023 trademark controversy は Rust community の性格を判定する事例ではなく、institutional authority、public consultation、criticism の scope、policy revision を区別する事例です。initial draft は採用済み final policy ではなく Foundation 単独の成果物でもありませんでしたが、wider Project involvement と communication が不足していたことは公式に認められました。その後は2024 revised draft と final feedback、2025 Foundation Board approval に進み、current policy は当時争点となった複数の領域を具体的に異なる形またはより明確に規定しています。

したがって一般化できる教訓も条件付きです。法的 asset を持つ Foundation、technical work を govern する Project、Project を Foundation Board に接続する Project Directors、moderation と technical teams を区別し、draft・feedback・adoption を時間順に分ける必要があります。そうすることで、公開論争を直ちに「Foundation 対 community」という単一の power narrative に変えることも、後の agreement を理由に初期 process problem を消してしまうことも避けられます。

8.7 政府勧告と産業成功事例の引用範囲

政府 guidance と産業事例は強い evidence になり得ますが、異なる種類の命題を支持します。memory-safety vulnerability を減らすべきである、memory-safe language は重要な手段である、Rust はその一つである、特定 project で Rust が最適である、すべての system で Rust を default にすべきであるは同じ主張ではありません。本節は online discourse でこうした結論がどれほど頻繁に現れるかを推定せず、これらの命題を一つに結合するとき何の追加前提が必要かを分析します。

8.7.1 NSA/CISA の勧告は複数の memory-safe language と条件付き adoption を前提とする

NSA の Software Memory Safety は2022年に初版が公開され、2023年4月に Version 1.1 へ更新されました。現在公開されている v1.1 は、C/C++ や assembly のように inherent memory protection が少ない言語から、可能な場合には memory-safe language への戦略的移行を検討するよう勧告します。例として Python、Java、C#、Go、Delphi/Object Pascal、Swift、Ruby、Rust、Ada を並べ、MSL ごとに保護の程度が異なること、compiler option・analysis tool・OS configuration などの hardening も引き続き必要であることを説明します。¹³³

2025年の NSA/CISA 共同 Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development はこの境界をさらに明示します。Ada、C#、Delphi/Object Pascal、Go、Java、Python、Ruby、Rust、Swift を例示し、言語選択は concurrency や performance などの条件で変わると説明します。また MSL adoption がすべての状況・solution area で現実的とは限らず、大規模 existing codebase や mission-critical system では大きな移行コストがあり得ると明記します。¹³⁴

重要なのは、2025共同 guidance が existing code の complete rewrite を要求していないことです。interoperability による incremental integration と、MSL adoption が現実的でない場合の non-MSL hardening も扱います。¹³⁴ これらの資料が強く支持するのは memory safety を高い設計目標とし MSL adoption を積極的に検討する policy/engineering direction であり、政府が Rust 一つだけを唯一の承認言語に指定したという結論ではありません。

8.7.2 2024 ONCD 報告も Rust を例示するが適用限界を同時に記録する

2024年の米国 Office of the National Cyber Director による Back to the Building Blocks は、memory-safe language adoption を secure-by-design の high-leverage measure として提示します。新規 product は最初から MSL を選べ、既存 codebase では risk の高い function/library から移す hybrid approach を使えると説明します。同じ報告は “one-size-fits-all solutions” はなく、memory-safe language だけですべての cybersecurity risk を除去できないと明記します。¹³⁵

とくに space system の節は Rust の引用範囲をよく示します。報告は kernel に近い制御、deterministic timing、garbage collector がないか override 可能であることを要求する edge case を説明し、Rust をこの三条件を持つ memory-safe language の一例として挙げます。しかし直後に、当時 Rust は space system でまだ十分に proven ではなく、toolchain development、workforce education、fielded case study がさらに必要だと述べます。memory-safe hardware と formal methods も complementary approach として扱います。¹³⁵

したがって「White House が Rust を systems programming の standard に指定した」という文は報告より強い主張です。報告が直接支持するのは memory safety という security objective、MSL adoption の高い価値、Rust が一部 constrained native workload で有望な一例であること、そして applicability 判断では workload と maturity を同時に見る必要があるという境界までです。

8.7.3 政府勧告から「Rust だけが現実的代替」へ移るには別の比較が必要である

以下は特定機関や個人の直接引用ではなく、異なる政府資料を結合したときに作り得る推論を点検するための 合成命題です。

政府機関は memory-unsafe language への依存を減らし MSL adoption を拡大するよう勧告する。
Rust は政府資料に登場する MSL の一つであり、DARPA は C-to-Rust 自動翻訳研究も進めている。
したがって systems programming では Rust だけが現実的な代替である。

第一・第二の前提は文書で支持できますが、第三の結論には candidate comparison がありません。NSA/CISA が挙げる言語は runtime model、deterministic behavior、FFI、platform coverage、ecosystem が異なり、一覧には GC-free native execution と high-assurance domain を支援できる Ada のような別候補も含まれます。一方、特定の low-level workload では Rust の ecosystem、interoperability、performance、memory-safety model の組合せが最も有利な場合もあります。どちらの結論が正しいかは 一覧に名前があるかではなく、project requirement と candidate-specific evidenceで決めるべきです。

政府資料の言語一覧も exhaustive standard として読んではいけません。NSA と NSA/CISA は複数言語を “examples” または “such as” として提示します。¹³³¹³⁴ 一覧にない言語が自動的に memory-unsafe または policy 上禁止されたわけではなく、一覧にあるだけで特定 workload への適合認証を受けたわけでもありません。

project-level の排他的選択を正当化するには、少なくとも threat/defect model、latency と worst-case timing、memory/resource budget、GC・runtime の許容、target/toolchain support、certification・assurance 要求、existing code/ABI、interoperability cost、staffing、multi-year lifecycle を比較する必要があります。他の現実的候補がそれらの要求を満たさないなら Rust が事実上唯一の選択になることはあり得ますが、その結論は政府の権威ではなく当該比較から生じます。

4. 産業成功事例の因果帰属と外的妥当性

産業事例は技術選択の有効性を示す重要証拠です。しかし言語置換の前後で、データ構造、アーキテクチャ、並行モデル、接続再利用、展開、ハードウェア、チーム熟練、観測指標も変わり得ます。成果全体を言語だけに帰属するには、同一ワークロードと基準線、同時変更要素、比較期間、反実仮想を明示する必要があります。

Android の安全成果：Google はメモリ安全脆弱性比率が2019年76%から2024年24%へ低下し、2025年に初めて20%未満になったと報告しました。2025年分析は約500万行の Android Rust コードでリリース前に発見・修正された潜在脆弱性一件を基に、C/C++ 歴史資料より密度が1,000倍以上低いと推定しました。¹³⁶ ¹³⁷ 新規・活発な Android コードと高危険境界での強い成果を示します。ただし全体低下には Java/Kotlin を含むメモリ安全言語戦略、既存コードの成熟、サンドボックス、防御層も作用し、すべてを Rust に帰属できません。
Discord の遅延事例：特定 Read States サービスを Go から Rust へ再実装後、周期的遅延スパイクが消え、遅延、CPU、メモリが改善したと報告しました。原文は Go 1.9.2 系、巨大 LRU キャッシュ、2分周期の強制 GC という条件を説明し、全システムの Rust 書き直しを勧告していません。P99 遅延50%減という数値も原文にはありません。¹³⁸
Pingora の資源節減：Cloudflare は同一トラフィックで旧 NGINX/OpenResty と比較し、CPU 約70%、メモリ約67%削減を報告しました。公式説明は Rust コード効率だけでなく、マルチスレッド構造、C–Lua 境界のコピー除去、接続再利用向上を複数原因として挙げます。遅延改善はコード速度より共有接続プールの新アーキテクチャが主因と説明します。¹³⁹ これは Rust を使った再設計の成果で、言語だけを変えた統制実験ではありません。
Firecracker 起動時間：AWS の125ms未満は i3.metal、デフォルト microVM サイズ、最小デバイスモデルという条件のシステム成果です。AWS がメモリ・スレッド安全性で Rust を選んだのは事実ですが、起動時間を言語の独立効果として分離測定した資料ではありません。¹⁴⁰
Linux カーネルの継続採用：2025年メンテナ会議後、Miguel Ojeda は Rust 支援実験終了と継続を説明しました。同じ説明は、全設定・アーキテクチャ・ツールチェーン組合せが完成しておらず、多くの作業と実験的組合せが残ると明記します。¹⁴¹ 継続性を示しますが、カーネル全体のデフォルト実装言語が Rust になった意味ではありません。

5. 数値、脆弱性、ロードマップの出典追跡

定量主張は数値が大きく具体的なほど説得的に見えますが、調査年、母集団、分母、脆弱性記述、ロードマップ状態が変われば結論も変わります。

エコシステム規模：226.7万人は JetBrains が2024 Developer Ecosystem データを基に過去12か月の Rust 利用者を推定した値です。¹⁴² 2025 State of Rust Survey は7,156回答を集め、約7千回答から全共同体を過度に外挿しないよう注意します。¹⁴³ 目的と母集団が異なり、単一集計として引用できません。
CVE 帰属：CVE-2025-30388 の公式説明は Windows Win32K-GRFX のヒープバッファオーバーフローで、ローカル実行と利用者操作が必要です。Rust コードという帰属はなく、「Windows カーネル Rust コード初の RCE」として使えません。¹⁴⁴ 一方 CVE-2025-68260 は Linux Rust Binder の unsafe リスト削除への並行アクセスがデータ競合とポインタ破損を起こしました。¹⁴⁵ unsafe 契約と共有状態の監査を要求しますが、Safe Rust 保証が存在しないことも、影響が自動的にブロック内に限定されることも支持しません。
非同期機能の状態：Rust 2026 ロードマップは現状が同期デストラクタのみで非同期クリーンアップが必要とし、保証デストラクタと async drop の基盤を2026～2027探索対象にします。¹⁴⁶ 方向であり、特定の「2027 edition」への収録確約ではありません。

6. security guidance、Rust-specific research program、「standard」宣言の区別

2025年 NSA/CISA 共同 guidance は MSL adoption を強く勧告する一方、適切な言語と移行戦略は状況で異なり、complete rewrite は必須ではなく、MSL adoption が現実的でない場合は non-MSL hardening も必要だと明記します。¹³⁴ したがってこれは memory safety を優先する security guidance であり、Rust だけを指定する procurement standard や language mandate ではありません。

DARPA の TRACTOR は、より狭く Rust-specific な evidence です。program goal は legacy C を skilled Rust developer が書く水準の safe、idiomatic Rust へ自動変換する研究です。¹⁴⁷ これは C-to-Rust translation が具体的な米国 defense-research investment の対象であることを直接示します。しかし research-program goal は、すべての C code をすでに正確かつ経済的に自動変換できるという deployment result でも、他の MSL を禁じる policy decision でもありません。

したがって「standard になった」「政府が選んだ」という表現には、少なくとも三つの層を区別すべきです。

Security objective と guidance： memory-safety vulnerability を減らし、現実的な領域で MSL adoption を計画する方向は複数の米国政府資料が一貫して支持します。
特定 research・procurement・project choice： TRACTOR のように Rust を明示する program はありますが、その選択範囲は program mission と evaluation criteria に限定されます。
Universal language mandate： 引用した guidance は、すべての software producer が Rust を使うことや、非 Rust 選択をすべて例外として正当化することを要求していません。そのような義務を主張するには、適用可能な statute、procurement rule、contract term、domain-specific standard と scope が別途必要です。

産業成果にも同じ規則を適用します。Android、Pingora、Firecracker、Discord、Linux の事例は各環境で production feasibility と observed outcome を示せますが、政府 policy と組み合わせても自動的に universal Rust mandate にはなりません。memory safety への強い政策方向、Rust の重要な実運用成果、特定 project で Rust-first を選ぶことは同時に真であり得ますが、それでも software domain 全体の言語選択は別の比較問題として残ります。

8.8 言説の背後：公式改善努力と共同体ガバナンス

前節では、一部の非公式言説に見られる誇張、排他的な技術選択、資格・地位判断を分析しました。しかし、そうした事例を Rust Project 全体の態度へ一般化してはなりません。公式プロジェクトには、言語・ライブラリ・ツール・ガバナンス上の課題を提案・検討する別個の手続きがあり、非公式なオンライン言説とは異なる分析単位です。

RFC（Request for Comments）プロセスは、言語の意味や標準ライブラリの大きな変更など実質的変更について、公開提案、設計レビュー、欠点と代替案の議論、関係チームの決定を行う経路を提供します。RFC リポジトリが説明するように、すべての変更が RFC を必要とするわけではなく、RFC のマージが実装や安定化を自動的に保証するわけでもありません。したがって RFC の存在が示すのは 公式の提案・レビュー経路が存在することであり、すべての批判が受容されることや、すべての参加者の態度ではありません。¹¹⁸

Project Goals と各チームの作業記録も同じ境界を示します。2025-2026 年の公式資料は async の ergonomics、build/editor 性能、debugging、low-level project 支援、borrow checker 改善など未解決課題を公開し、チームの支援、利用可能な資源、実装難易度も扱います。¹¹⁸ これは未完了課題を認識している証拠ですが、goal 文書は完了した成果ではありません。実際の改善は実装状態と測定結果で別に判定する必要があります。

公式ガバナンスの評価では、少なくとも四層を区別すべきです。1) 問題が公式に認識されたか、2) RFC・project goal・issue・team decision などの経路が実際に機能したか、3) 実装と安定版提供まで到達したか、4) compile time、error rate、usability、maintenance cost などの指標が実環境で改善したか、です。前段階の存在だけで後段階を推定してはならず、未完了課題があるというだけで改善手続き全体を無意味とも言えません。

この区別により、第8章の分析は一方向の批判になりません。非公式空間の防御的論証は論証自体として評価し、公式プロジェクトの改善活動は公式記録と実際の結果で評価すべきです。両者が影響し合う可能性はありますが、一方の事例を他方全体の代表標本とみなす根拠はありません。

第8章の結論は限定的です。Rust をめぐる言説には、条件付きの工学的利点を普遍的優越性や人の地位判断へ拡張する論証が見られます。同時に Rust Project には、未解決問題を公式に記録し変更を検討する制度的仕組みがあります。前者は言語自体の欠陥を自動的に証明せず、後者も技術的成功や健全な共同体文化を自動的に証明しません。主張、手続き、実装、測定結果をそれぞれの証拠水準で評価する必要があります。

第5部：総合分析と結論

第5部は前章までの監査済み分析を統合しますが、新たな強い因果主張は追加しません。第9章は五つの研究質問について現在の証拠が支持する範囲の結論を示し、第10章はその上で改善課題と技術選択の枠組みを扱います。

9. Rust の再評価：効用、制約、技術選択戦略

第9章の役割は Rust を再び称賛したり反駁したりすることではなく、第1-8章で確認した保証、費用、産業事例、変更戦略、言説の境界を一つの選択問題に統合することです。

9.1 Rust の技術的特性と適用分野の分析

Rust の重要な工学的利点は、Safe Rust の規則と sound な下位抽象が成立する範囲で、特定のメモリエラーと data race を compile-time constraint に変える点です。use-after-free、不正な参照寿命、Safe Rust の参照規則が禁じる aliasing pattern などを実行前に遮断でき、低遅延、資源使用への直接的な制御、native performance、memory safety を同時に求める構成要素では強い選択理由になります。ただし実際の latency と resource bound は allocator、同期、OS、workload を含めて別途測定または立証する必要があります。

ただし保証境界は明示しなければなりません。unsafe 実装の soundness、FFI contract、library/OS interface は別の義務を生み、Safe Rust でも logic error、deadlock、resource exhaustion、memory leak、誤った authorization check、panic による service interruption は消えません。「compile できた」を「program は安全」「security vulnerability はない」へ拡張するのは保証範囲を超えます。

Android、Pingora、Firecracker、Discord、Linux の事例は Rust が特定の production workload で実用可能であることを示します。一部の事例では memory safety、GC の除去、resource use、latency、maintenance に関する利点が報告されています。ただし rewrite と同時に architecture、algorithm、workload、hardware、deployment、testing、staffing が変わる場合が多く、観測結果全体を言語だけの因果効果に帰属させてはなりません。

したがって適合性は defect model と運用条件に依存します。memory safety と low-level control の両方を重視する新規 system component、network/storage/virtualization、security boundary では優先度が高くなり得ます。一方、成熟した legacy asset、hard real-time や certification 制約、既存 platform ecosystem、GC cost が重要でない business application では他の選択肢が低い lifecycle cost を持つ場合があります。正確な問いは「良い言語か」ではなく「どの failure を減らし、そのためにどの cost を受け入れるか」です。

9.2 技術エコシステムの現実と多次元的な開発者能力モデル

言語の技術的価値と開発者個人の価値は同じ変数ではありません。Rust が必要な職務では Rust proficiency が直接的な能力ですが、特定言語の好みや熟練度を一般的な知能・専門性・道徳性の代理指標にする根拠はありません。

software engineering は requirements、design、implementation、testing、security、performance、operations、maintenance、collaboration、domain knowledge を含みます。採用と能力評価は実際の役割に結び付いた work sample と structured criteria を中心にすべきです。Rust role では ownership、borrowing、async、FFI、ecosystem experience を直接評価できますが、別の role では中心基準でないことがあります。一つの言語の難しさを通過したことも、その言語を使わないことも、全体の engineering ability を十分に説明しません。

survey 上の Rust satisfaction、特定企業の adoption、job-posting market size も別の母集団と指標です。これらを結ぶには独立した labor-market data と sampling definition が必要であり、「人気が高いから career market も大きい」「求人が少ないから技術的価値が低い」という結論はいずれも成立しません。

教育でも同様です。ownership と borrow checking は memory と aliasing の有用な思考法を教えますが、data structure、OS、network、concurrency、compiler、manual memory management の基礎すべてを代替しません。逆に C/C++ で pointer bug を直接経験することが system understanding の必要条件だとも立証されていません。

9.3 技術共同体、組織評価、エコシステムの持続可能性

持続可能性は言語設計だけで決まりません。maintainer capacity、資金と時間、release/security response、documentation、onboarding、decision procedure、長期投資能力が作用します。第8章の RFC と project-goals は調整の制度的仕組みを示しますが、その存在だけで良い結果を保証しません。

online discourse にも同じ推論限界があります。一部の議論に、技術的反論ではなく相手の資格・知能・道徳性を問題にしたり、Rust 以外の選択を無責任とみなしたりする論証があっても、sampling design なしに Rust user 全体の性向や頻度を推定できません。逆に Code of Conduct や RFC process の存在だけで全 interaction が健全とも言えません。

組織では technology choice と evaluation system を共に見る必要があります。予防、testing、documentation、refactoring、observability は短期 feature output より見えにくく、評価が lines of code、overtime、emergency recovery などの可視信号に依存しすぎると、それらを最適化する誘因が生じます。これは個人の知能や国籍よりも goal、incentive、authority/responsibility、resource allocation、psychological safety、labor-market condition で検証しやすい問題です。

第9章の総合結論は限定的です。Rust は sound な Safe Rust 境界で特定の memory error と data race を強く遮断する重要な systems-programming tool です。複数の産業環境で production feasibility が確認され、一部では Rust adoption とともに条件付きの利点が観測されています。同時に保証は unsafe、FFI、logic/resource/operational boundary の外へ自動拡張せず、compile-time、tooling、learning、integration、transition cost も存在します。新規 Rust 実装や selective adoption が合理的な project もあれば、modernization、hardening、partial replacement、既存言語の継続がよい project もあります。

したがって五つの研究質問への共通回答は language ranking ではなく 境界を明示した選択手続きです。制御すべき failure class を定義し、候補技術の guarantee と failure condition を比較し、既存資産、transition risk、operations、staffing、ecosystem cost を含めて判断します。adoption case は feasibility と条件の証拠として用い、causal effect と universal suitability は別に検証し、技術的選好を人の地位判断へ拡張しないことが必要です。この境界内で Rust の強みは十分に大きく、普遍命題へ変える必要はありません。

10. 結論：エコシステムの持続可能性に向けた課題と展望

第10章の役割は、新たな技術的優越性の主張を追加することではなく、第1-9章で監査した技術・産業・組織上の結論を、条件を明示した勧告へ変換することです。ここで優先する価値は、重大な欠陥の削減、性能と資源使用の予測可能性、サービスの回復力、長期保守性、変更の可逆性、サプライチェーンの安全性、そして判断根拠の追跡可能性です。どの価値も常に他の価値を上回るとは前提しません。

したがって本章は、「Rust が将来支配的な言語になるか」を予測しません。すでに確認した保証境界と実際のコストを基に、Rust Project と採用組織がどの問題をどの証拠で扱うのが合理的かを提案します。

10.1 エコシステムの構造的改善に向けた課題

構造的改善は機能数を増やすことと同義ではありません。長期間運用されるシステムでは、相互運用境界、保証文書、開発フィードバックの遅延、サプライチェーンと保守能力、ガバナンス結果の追跡可能性がいずれもボトルネックになり得ます。現在の公式資料で確認できる課題も、これら複数の層にまたがっています。

1. 相互運用性と ABI：「安定 ABI がない」を実際の問題に分解する

Rust Reference は、native extern "Rust" ABI が stability guarantee を提供せず、既定の repr(Rust) も soundness に必要な限定的なレイアウト保証しか提供しないと明記しています。同時に Rust は dylib・cdylib などの動的リンク成果物と、extern "C"、repr(C) のような明示的な相互運用境界をサポートします。¹⁰² したがって問題を「Rust は dynamic linking ができない」と表現するのは不正確です。

実際の問いは、どの境界を、どの期間、互換性契約として維持する必要があるかです。長期間独立配布される plugin、system library、Rust/C/C++ 混在コードのように binary compatibility が重要な場合、ABI、representation、allocator ownership、error と unwind、lifetime、version negotiation を明示的に設計する必要があります。反対に、単一 toolchain で一緒に build・deploy する application では、Rust-native ABI の長期安定性の優先順位は低い場合があります。

2026 Rust Project Goals には C++/Rust interoperability の問題空間を整理する作業が含まれ、関連する公式資料も、大規模な既存 C++ 資産を短期間で全面的に書き直すことが現実的または望ましいとは前提していません。¹⁴⁸ エコシステム改善を単一の libstd stable ABI という目標に固定するより、実際の migration 境界で必要となる相互運用契約と tooling を測定可能な問題に分ける方が妥当です。

2. 高保証領域：言語保証と検証可能な safety case の間を埋める

Safe Rust の保証は強力ですが、高保証システムでは、その保証がどの unsafe 実装、compiler、library、target、toolchain に依存しているかを追跡できなければなりません。Rust の2026年公式目標には、sound な unsafe pattern の規範的文書化、Formalized Language Specification の継続的更新、sanitizer support、MC/DC coverage、Rust-for-Linux compiler 機能など、保証・検証基盤を強化する作業が含まれています。¹⁴⁹

特に公式 goal 文書自体が、現在の unsafe に関する権威的文書に空白があることを記録しています。これは Rust が高保証領域に不適切だという結論でも、goal が登録されたから問題が解決済みだという結論でもありません。高い assurance level を要求する project では、利用する compiler・library の qualification 状態、normative contract、coverage と static/dynamic analysis、traceability、長期 support を実際の認証・運用条件と照合する必要があります。Ada/SPARK、C/C++ の検証 tool、他の memory-safe language も同じ要求で比較すべきです。

3. build・IDE・debugging cost：エコシステム全体の等級ではなく対象 workload の feedback loop を測る

第5章・第6章で確認したように、2025 compiler-performance survey には build と editor latency に満足する回答と、重大な blocker を報告する回答が共存します。特に self-selected sample と「最も問題の大きい project」を尋ねる設問は、Rust workload 全体の平均へ一般化できません。⁹³ debugging capability gap も debugger と OS によって異なります。⁹⁸

したがって「Rust tooling は成熟している／未成熟だ」という単一等級より、導入対象 repository で clean build、incremental build、CI queue、rust-analyzer latency と memory、link time、debugger 機能、artifact size を測定すべきです。これらの cost が実際の開発・運用目標を損なうなら、compiler・Cargo・IDE 改善、dependency 構造調整、profile と linker の選択、build cache などを試し、結果を再測定します。公式 project goal は改善方向の根拠にはなりますが、完了した効果の測定値を代替しません。¹¹⁸

4. サプライチェーンと保守：crate 数や version number より、運用可能な信頼の連鎖を作る

package ecosystem の持続可能性は、crate が多いか少ないか、version が 1.0 を超えたかだけでは判断しにくいものです。長期運用には、必要な dependency を誰が保守しているか、release provenance と update path を追跡できるか、脆弱性対応と maintainer succession が可能か、registry や配布 infrastructure の障害から回復できるかの方が直接的です。

Rust Foundation は ecosystem security を変化し続ける問題と位置づけ、audit、threat modeling、security tool 開発を行っています。2026 Rust Project Goals には Rustup/Cargo の検証可能な mirroring prototype と Cargo SBOM precursor の安定化作業も含まれます。¹⁵⁰ これは現在の supply chain が全面的に危険だという判定でも、新しい tool がすべての risk を解決するという保証でもありません。組織は threat model に応じて dependency inventory、lock/update policy、provenance、SBOM、advisory response、private/official mirror policy、maintainer continuity、rollback 手順を構成する必要があります。

5. ガバナンス：計画の公開より、計画-実装-効果の接続性を高める

8.8節で見た RFC と Project Goals は、問題と提案を公開し、team review と resource commitment を接続する制度的仕組みです。2026 goals process も、contributor が goal を提案し、関連 team が champion と review support を提供する bottom-up structure を明記しています。¹¹⁸ この構造は改善可能性を高め得ますが、goal の存在自体が completion・adoption・effect を意味しません。

したがって持続可能な governance では、問題公開 → 決定 → 実装・安定化 → 観測された効果を追跡できる必要があります。完了した goal だけでなく、遅延・中断した goal や不足した resource を記録することも将来の優先順位設定に役立ちます。逆に一つ二つの goal の失敗から project 全体の無能を一般化してもいけません。公式 process の質は文書の存在だけでなく、決定理由、resource allocation、implementation result、user に観測された effect を長期比較するとき、より適切に評価できます。

この五つの課題の優先順位は適用領域で異なります。plugin ABI が中心の製品と単一 static binary appliance では必要事項が異なり、safety-critical controller と一般 web service では assurance case も異なります。したがって「Rust ecosystem が成熟するには必ず X を最初に解決すべきだ」という単一 roadmap より、対象 workload の failure condition と lifecycle に結び付いた改善順序の方が検証可能です。

10.2 総合：技術、変更戦略、能力、測定、組織環境をともに扱う思考枠組み

第1-9章の経験的結論と、本章の勧告は区別しなければなりません。経験的結論は Safe Rust の保証境界、実際の産業利用で示された実用可能性、build/tooling と migration cost、公式 project が認める未完了課題、そして実際に観察した言説の範囲を説明します。勧告はその事実の上で、どの価値を優先するかを選ぶ規範的判断です。

本書の勧告が優先する価値は次の通りです。重大な欠陥と security risk を減らすこと、performance と resource constraint を満たすこと、service interruption と change failure から回復できること、検証済みの既存 asset を理由なく捨てないこと、長期 maintenance・staffing・supply-chain cost を含めること、失敗した transition を戻せること、そして技術選好を人の地位判断に変えないことです。project が異なる価値を優先するなら、結論も合理的に異なり得ます。

この価値前提の下では、次の 条件付き default を提案できます。

状況	優先して検討する戦略	前提となる価値と制約
新規 low-level・security-sensitive component	Rust を含む memory-safe native language を強い候補とする	memory-safety defect の削減が重要で、GC/runtime constraint、performance/resource requirement、ecosystem fit も満たす必要がある
安定運用中の大規模 C/C++ system	hardening・modernization・new Rust component・selective replacement・full rewrite を併せて比較する	regression risk、implicit specification、ABI、rollback、長期 coexistence cost を判断に残す必要がある
safety/mission-critical system	language name より実際の assurance evidence と toolchain を比較する	certification、normative contract、timing/resource bound、traceability、長期 support が要求 assurance level を満たす必要がある
GC と managed runtime を許容できる一般 application	Rust を自動 default にせず、productivity・ecosystem・operation model も比較する	memory-safety guarantee 以外に development speed、staffing、framework、fault isolation、operating cost が支配的になり得る
新技術を組織全体へ拡大する場合	bounded pilot 後、測定結果に基づき拡大を決める	language effect と redesign effect を分離し、training・tooling・operation・supply-chain capacity が持続可能である必要がある

Android の new-code-first と interoperability strategy、そして NSA/CISA の memory-safe language guidance は、全面 rewrite や単一言語 mandate だけでなく、条件付き・段階的 approach が実際の選択肢であることを示します。¹¹² ¹³⁴ ただし、これもすべての project で incremental migration が最善だという証明ではありません。

意思決定手順

問題と価値の優先順位を定義する。 latency、throughput、worst-case timing、memory、security、availability、certification、development speed、maintainability のどれが実際の constraint かを定めます。
baseline と defect model を測定する。 現在の defect class、incident impact、repair time、build/CI feedback、performance、resource usage、operational burden を記録します。baseline がなければ、改善効果と redesign effect の区別は困難です。
候補技術の保証境界を同じ形式で書く。 Safe Rust、unsafe、FFI、GC、runtime、static analysis、formal proof など各候補が何を保証し、何を保証しないかを明記します。
change strategy を language choice から分離して比較する。 継続 maintenance、hardening、same-language refactoring/modernization、new Rust component、selective replacement、full rewrite を候補にし、specification recovery、interop、rollout、rollback cost まで含めます。
代表 workload で pilot し、帰属を記録する。 runtime performance だけでなく defect discovery、build/IDE latency、memory と binary footprint、development time、incident、maintenance cost を測定し、architecture・algorithm・hardware・staffing の変更も記録します。
lifecycle と組織能力を確認する。 dependency・supply-chain management、security response、maintainer continuity、toolchain support、hiring・training、dual-language operation、on-call load、knowledge concentration が project lifetime を通して持続可能か確認します。
拡大条件と停止条件を先に決める。 target metric、rollout stage、observability、rollback boundary、failure budget を定め、objective を満たすときだけ範囲を広げます。結果が悪ければ、language identity を守るために失敗を再解釈せず、停止・修正・回帰できなければなりません。
判断を再検討させる証拠を記録する。 compiler、ecosystem、standard、competing technology、組織条件は変化します。どの measurement や event が現在の判断を変えるか decision record に残し、技術選択を反証可能な仮説として保ちます。

この手順は RQ3-RQ5 に対する本書の最終勧告を具体化します。RQ3 では産業 case は feasibility と条件付き outcome を示しますが、一つの言語に帰属する普遍的 effect size ではありません。RQ4 では maintenance、modernization、selective replacement、rewrite は順位ではなく、異なる risk profile を持つ strategy です。RQ5 では条件付き技術的利点は強い採用判断を正当化できますが、非使用者の知能・資格・道徳的価値に関する結論を与えません。

Rust の持続可能性に必要なのは弱点を隠すことでも、逆に弱点そのものを identity にすることでもありません。強い保証は正確な境界とともに説明し、未完了作業では plan と result を区別し、adoption effect は measurement と attribution で検証し、失敗した選択は戻せるようにする必要があります。その条件が保たれるなら、Rust は一部領域で非常に強い工学的選択として評価でき、別の領域で他の言語や change strategy の方が合理的だという結論も同じ証拠基準で受け入れられます。

エピローグ

本書が最後まで問い続けてきたのは、「Rust は良い言語か、悪い言語か」ではありません。より正確な問いは、どの失敗を減らそうとしているのか、どの保証がどの境界まで成立するのか、その保証を得るためにどのようなコストと変更リスクを引き受けるのか、そしてどのような証拠が得られれば現在の判断を修正するのかです。

第一に、Rust の最も強い工学的価値は、Safe Rust の契約と sound な下位実装が成立する範囲で、特定のメモリエラーと data race をコンパイラが強制する制約へ変える点にあります。この保証は重要で実用的です。しかし、unsafe に伴う義務、FFI と外部契約、論理エラー、deadlock、resource exhaustion、memory leak、誤った権限検査、panic、運用障害まで自動的に取り除くものではありません。この境界を明示することは Rust の価値を下げるのではなく、その価値が実際に成立する範囲を正確にすることです。

第二に、その保証は他の技術を一つの序列に並べるものではありません。C/C++ の modernization と hardening、garbage-collected language の runtime model、Ada/SPARK の強い契約と検証ツールは、それぞれ異なる失敗モデルとコスト構造を持ちます。どの候補が適するかは、性能と worst-case timing、資源上限、assurance 要求、既存資産と ABI、ecosystem、staffing、lifecycle によって変わります。したがって比較の目的は勝者を決めることではなく、必要な保証と負担できるコストの組み合わせを見つけることです。

第三に、産業事例は Rust が実際の production 環境で利用でき、特定の条件では意味のある利点を提供できることを示します。しかし言語の変更と同時に architecture、algorithm、hardware、deployment、testing、組織能力が変わることも多いため、観測された結果のすべてを言語だけの普遍的な因果効果へ換算することはできません。事例は実現可能性と条件についての証拠であり、別のプロジェクトの結果をあらかじめ保証する認証書ではありません。

第四に、既存システムの変更戦略も二者択一ではありません。継続保守、hardening、同一言語での refactoring と modernization、新規 Rust コンポーネント、高リスク領域の選択的置換、全面 rewrite は、それぞれ異なるリスクを持つ別個の戦略です。良い判断は、過去の投資への感情や新技術への期待ではなく、現在の欠陥、暗黙の仕様、回帰リスク、interoperability、rollout と rollback、長期運用コストを同じ基準で比較することから生まれます。

第五に、技術選択は人の地位を判定する道具ではありません。Rust の熟練は Rust を必要とする職務では重要な能力になり得ますが、一般知能、ソフトウェア工学全般の能力、道徳的責任感の代理指標ではありません。本書で分析したオンライン事例も、特定の論証構造を示す質的資料であり、Rust 利用者全体の性向や態度の頻度を推定できる代表標本ではありません。公式プロジェクトのガバナンスと非公式の言説も同じ対象として扱うべきではありません。

結局のところ、Rust の強みは誇張しなくても十分に強いものです。あるプロジェクトでは Rust を積極的に導入することが最も合理的な結論になり得ますし、別のプロジェクトでは既存システムを modernization する、別の言語を選ぶ、あるいは移行を保留する方が合理的かもしれません。重要なのは、その結論が 明示された要件、検証可能な証拠、失敗時に戻せる変更戦略から導かれ、新しい証拠に応じて修正可能であることです。

本書の目的は技術論争を終わらせることではなく、その論争が何を立証し、何をまだ立証していないのかを、より正確に語れるようにすることです。言語名より失敗モデルを、スローガンより測定を、地位競争より検証可能な選択を先に置くこと——それが本書の提案する最後の基準です。

付録：技術討論で観察される論証上の誤謬の事例分析

この付録の目的は、特定のコミュニティや個人を評価することではなく、技術的議論で主張の妥当性を曖昧にし得る論証の形式を見分ける練習を提供することです。以下の応答文はすべて説明のために作成した合成例であり、実在する投稿の直接引用、特定ユーザーの発言再現、頻度調査、代表標本ではありません。したがって、これらの例の存在から Rust 利用者や他の技術コミュニティ全体の傾向を推定することはできません。

また、誤謬を特定したからといって相手の結論が自動的に偽になるわけではありません。結論が真でも、提示された理由が十分な根拠になっていない場合があります。各事例では、①本来検討すべき命題、②応答が実際に扱っている命題、③欠けている前提や証拠、④検証可能な形への組み直し、を区別します。

事例 1：技術的批判を発話者の能力問題へ置き換える — 人身攻撃

文脈: ある開発者が、Rust async の学習コストや特定コードベースでの生産性コストを指摘します。
合成応答: 「その機能が難しいと感じるのは言語の問題ではなく、あなたの実力の問題だ。」
分析: 発話者の熟練度は利用経験の解釈に関係し得ますが、それだけでは API の複雑さ、誤りの起きやすさ、開発時間に関する主張を反駁できません。技術命題が人物評価に置き換わっています。
検証可能な再構成: workload、チーム経験、実装時間、defect、latency、保守コストを定義し、別の実行モデルや以前の実装と比較します。熟練度は変数にできますが、結論そのものにはしません。

事例 2：主張ではなく背景や動機を反駁する — 発生論的誤謬と動機推定

文脈: C++ 経験者が、borrow checker は特定設計で追加の再構成を要求すると主張します。
合成応答: 「それを制約と呼ぶのは、C++ のやり方に執着し、新しいパラダイムを恐れているからだ。」
分析: 過去の経験が好みに影響する可能性はありますが、推定された動機は、その設計で borrow checker がどの制約と利益を生むかの証拠ではありません。主張の内容と主張者の心理説明が置き換わっています。
検証可能な再構成: 問題となる ownership と aliasing の関係をコードや最小例で示し、Rust が要求する再設計、得られる保証、実装コストを比較します。

事例 3：限定された批判をより強い主張へ変える — 藁人形論法

文脈: Rust のエラー処理が特定の API 設計では冗長、または他言語より不便だという主張が出ます。
合成応答: 「つまり Rust のエラー処理は全部役に立たないと言うのか？」
分析: 「ある条件でコストがある」と「機能全体が無価値だ」は別の命題です。強い命題を作って反駁しても、元の比較は残ります。
検証可能な再構成: 元の条件と比較対象を維持し、対象の error model で Result、例外、panic、その他の方針がどの trade-off を持つかを評価します。

事例 4：リファクタリングと再実装を一つにする — 範疇錯誤、偽の二分法、完全性の誤謬

文脈: 古い C/C++ システムの欠陥をどう減らすかを議論します。
合成応答: 「本当のリファクタリングとは Rust で書き直すことで、それ以外の改善は無意味だ。」
分析: 同一言語での refactoring、hardening、selective replacement、full rewrite は変更範囲と失敗様式が異なる戦略です。ある戦略が全 memory-safety defect を言語レベルで除去できないからといって、部分的な欠陥削減や保守性改善の価値がゼロになるわけではありません。
検証可能な再構成: 現在の defect 分布、test と暗黙仕様、migration・rollback risk、FFI/ABI、性能、人員、lifecycle cost を基準に複数戦略を同じ decision record で比較します。

事例 5：レガシー状態を道徳的属性へ変える — 誤った類推と価値判断の飛躍

文脈: 古いシステムを維持、モダナイズ、置換するかを決めます。
合成応答: 「レガシーはそれ自体が悪いので、古い技術を維持する選択は非合理だ。」
分析: 年数は support 終了、technical debt、人員リスクと相関することがありますが、独立した品質指標ではありません。逆に過去投資だけを理由に維持するのも十分ではありません。重要なのは将来のコストとリスクです。
検証可能な再構成: defect rate、運用安定性、supply chain と support 状態、変更容易性、置換費用、regression risk、将来保守費を測定し、維持・modernization・部分置換・全面置換を比較します。

事例 6：言語熟練を一般知能や総合能力と同一視する — 構成概念の混同

文脈: Rust 職種の採用基準や開発者能力全般を議論します。
合成応答: 「Rust をよく学べる人ほど知能が高いので、Rust 熟練度を開発者評価の中心にすればよい。」
分析: Rust 熟練は Rust 業務には直接関連し得ますが、一般知能、要件分析、設計、debugging、運用、協働、domain knowledge を自動的に測りません。学習者に見られる特性が学習の因果効果か self-selection かも別問題です。
検証可能な再構成: 職務が実際に必要とする行動と成果を先に定義し、Rust が必要な役割ではその知識を直接評価し、他の能力は別の work sample と構造化基準で測定します。

事例 7：組織問題を構成員全体の本質へ変える — 過剰一般化と単一原因論

文脈: 過剰な業務量、不公平な評価、知識集中、離職などの組織問題を説明します。
合成応答: 「有能な人は全員辞め、無能な人だけが残るので、業界の問題は構成員の低い能力で説明できる。」
分析: 労働条件や評価構造が retention と performance に影響するという仮説は検証できます。しかし限定された経験から業界全体の selection effect と構成員の知能まで推論すると、母集団、代替説明、測定変数を飛ばします。
検証可能な再構成: 離職率、workload、報酬、評価基準、incident burden、team tenure、bus factor、採用、performance data を収集し、組織条件と個人能力を別変数として分析します。

事例 8：反対意見をすべて既存信念の証拠に吸収する — 自己封鎖的論証

文脈: Rust の長所や採用必要性について意見が分かれています。
合成応答: 「賛成する人は技術を理解しており、反対する人は理解していないか劣等感を持っている。」
分析: 賛成も反対も同じ結論の証拠になるなら、どの観察も主張を弱められません。反証条件が消え、相手の動機推定だけが残ります。
検証可能な再構成: どの benchmark、defect data、migration cost、ecosystem change が現在判断を変えるかを事前に書きます。異論はその条件と証拠に照らして評価し、心理推定と分離します。

事例 9：観察しやすい代理指標と集団属性を同一視する — proxy の誤用と標本一般化

文脈: 残業、コード量、目立つ緊急復旧を報酬する組織評価を議論します。
合成応答: 「このような評価慣行があるから、ある国の開発者は全般に技術力と知能が低い。」
分析: コード量や残業が品質の十分条件ではないという批判と、国家単位の能力判断は別の命題です。少数企業やオンライン例は代表標本ではなく、国家レベルの因果説明に必要な比較変数もありません。
検証可能な再構成: 組織では予防、再発 incident、change failure rate、review quality、maintainability、実際の成果を評価します。集団比較が本当に必要なら、母集団と標本を定義し、職種構成、教育、産業構造などの交絡要因を別途設計します。

事例 10：複数の成功事例を一つの普遍的標準にまとめる — 帰属の混合と一般化範囲の拡大

文脈: Android、network service、cloud infrastructure、Linux、memory-safe language に関する政府勧告など、性質の異なる Rust 関連根拠を一緒に提示します。
合成応答: 「すべての証拠が同じ方向を示す以上、どのシステムでも Rust を選ばない側が例外を証明すべきだ。」
分析: 独立した複数事例は Rust の実用性や特定の利点を強く支え得ます。しかし異なる workload、metric、denominator を一つの effect size に統合できず、rewrite と同時に変わった architecture、algorithm、hardware、運用の効果も分離する必要があります。memory-safe language を推奨する政策と Rust 単独の義務化も別の命題です。
検証可能な再構成: 各事例が feasibility、特定組織の観測結果、因果効果、普遍的適合性 のどれを支えるかを分けて表示します。そのうえで対象 project の defect model、assurance、runtime・resource 条件、既存資産、migration risk、現実的候補技術を同じ基準で比較します。

この付録の使い方

技術討論では、誤謬名を素早く付けるより次の質問を順番に確認する方が有用です。

相手が実際に述べた命題は何で、その条件と範囲はどこまでか。
応答はその命題を直接扱っているか、それともより強い別の命題へ置き換えているか。
結論までに必要な前提と証拠が明示されているか。
case study、survey、benchmark、policy document は本当に代表性、因果性、普遍性を支えるか。
どの観察が出れば現在の判断を修正するのか。

この手順は Rust を支持する議論にも批判する議論にも同じように適用すべきです。良い技術討論は参加者の資格やアイデンティティを序列化する競争ではなく、主張の範囲、保証境界、比較可能な証拠、反証条件をより正確にする過程です。

ランタイムがオブジェクトの到達可能性などを追跡し、使用されなくなったメモリを自動的に回収するメモリ管理手法。 ↩
Rust Core Team, Laying the foundation for Rust’s future; Aaron Turon, Abstraction without overhead: traits in Rust。前者は Rust が Mozilla Research のプロジェクトとして始まり独立プロジェクトへ移行した経緯を説明し、後者はメモリ安全性、データ競合の防止、抽象化コストという設計軸を説明しています。 ↩
The Rust Reference, Behavior considered undefined および Behavior not considered unsafe; The Rustonomicon, How Safe and Unsafe Interact。公式文書も、unsafe 契約の健全性に関する責任、意味規則が未完成であること、デッドロック・資源漏洩・論理エラーがメモリ非安全性とは区別されることを明記しています。 ↩ ↩²
Aaron Turon, Abstraction without overhead: traits in Rust。この記事はゼロコスト抽象化を Rust 設計の中核原則として説明しますが、特定のプログラムの性能結果を普遍的に保証するものではありません。 ↩
The Rustonomicon, Data Races and Race Conditions; The Rust Programming Language, Using Threads to Run Code Simultaneously。公式文書は、Safe Rust がデータ競合を防ぐことと、一般的な競合状態やデッドロックが別の問題であることを区別しています。 ↩
The Rust Programming Language, Understanding Ownership, References and Borrowing, Validating References with Lifetimes。公式文書は、所有権、アクセス権限、参照の有効性の役割を区別し、ライフタイム注釈が参照の実際の生存期間を変えないことを説明しています。 ↩ ↩² ↩³
Rust Project Goals, Stabilize and model Polonius Alpha および The Borrow Checker Within。2026 年の公式目標は、現在の NLL 解析が拒否する条件付き借用と lending iterator を受け入れる一方、完全なフロー感度を必要とする一部のパターンは将来の課題として残ると説明しています。 ↩
The Rust Programming Language, Rc<T>, the Reference-Counted Smart Pointer, RefCell<T> and the Interior Mutability Pattern, Reference Cycles Can Leak Memory, Shared-State Concurrency。これらの文書は、実行時借用検査、参照カウント、循環リーク、アトミック参照カウントの性能コスト、ロック、デッドロックの可能性を説明しています。 ↩
Standard C++ Foundation, What is the zero-overhead principle?; Aaron Turon, Abstraction without overhead: traits in Rust。両資料は、この原則を C++ の設計原則と、それを受け継ぐ Rust の抽象化目標として説明していますが、特定プログラムの普遍的な性能結果を規定してはいません。 ↩ ↩²
Rust Compiler Development Guide, Monomorphization; The Cargo Book, Profiles; The rustc book, Codegen Options; Richard Uhlig et al., Instruction Fetching: Coping with Code Bloat。これらの資料は、単相化によるコンパイル時間とバイナリサイズのコスト、最適化・コード生成単位・LTO のトレードオフ、コード規模が命令フェッチへ与え得る影響を説明しています。 ↩ ↩² ↩³
The Rust Reference, Trait object types; Rust 標準ライブラリのキーワード文書、dyn; Rust 標準ライブラリ、Box<T>、Vec<T>、String; The Rust Reference, Panic。これらの文書は、トレイトオブジェクトによる実行時ディスパッチ、ヒープ割り当てと再割り当て、範囲外インデックス参照の panic をそれぞれ区別しています。 ↩ ↩²
The Rust Programming Language, Performance in Loops vs. Iterators。公式例は一つのワークロードで似た性能を観測したものであり、より広い比較には多様な入力と条件が必要だと明記しています。 ↩
The Rust Programming Language, Defining an Enum および Recoverable Errors with Result; Rust 標準ライブラリ、Option および Result; The Rust Reference, Pointer types。公式文書は、Option と Result による状態表現、未使用の Result に対する must_use 警告、非ヌル参照とヌルになり得る生ポインタの境界を区別しています。 ↩ ↩² ↩³
The Rust Reference, match expressions, Patterns, The non_exhaustive attribute。これらの文書は、パターンガードの条件付き動作、網羅性検査、ワイルドカード、外部の非網羅型に関する API 進化規則を説明しています。 ↩
The Rust Reference, Behavior considered undefined。公式参照は、不正な列挙型の判別値、参照、型付き値の構築を未定義動作として分類し、unsafe と FFI の境界でも実装者が有効性の前提を保持しなければならないと説明しています。 ↩
The Rust Reference, Type layout および Panic; Rust 標準ライブラリ、Option representation, Option::unwrap, Result::unwrap。これらの資料は、既定の列挙型配置に対する限定的な保証、特定型のヌルポインタ最適化、unwrap 系の panic と panic 戦略を区別しています。 ↩ ↩²
The Cargo Book, Why Cargo Exists および cargo。公式文書は Cargo を Rust のパッケージマネージャ兼ビルドツールとして定義し、依存関係の取得・ビルド・検査・テスト・文書化・パッケージング・公開を共通コマンド体系で提供する範囲を説明しています。 ↩
The Cargo Book, Dependency Resolution, Features, FAQ — Why have Cargo.lock in version control?, SemVer Compatibility, Rust Version および cargo。これらの文書は、ロックファイルによる決定性の範囲、オフライン解決の差、重複バージョン、feature の統合、SemVer の前提、rust-version/MSRV の限界を区別しています。 ↩ ↩² ↩³ ↩⁴ ↩⁵
The Cargo Book, Build Scripts および Specifying Dependencies; The Rust Reference, Procedural macros。公式文書は、build.rs の実行、ネイティブライブラリとのリンク、ターゲット固有・ビルド依存関係、手続きマクロのコンパイル時実行やファイルアクセスなどのセキュリティ境界を説明しています。 ↩ ↩² ↩³ ↩⁴
The Cargo Book, Registry Index, Publishing on crates.io, cargo owner および The Manifest Format。これらの資料は、.crate の SHA-256 チェックサム、公開済みバージョンの恒久的保持と yank、所有権管理、ライセンスメタデータの範囲を説明しています。 ↩ ↩²
The Cargo Book, Cargo Home および cargo vendor; RustSec, cargo audit および RustSec Advisory Database; CMake, cmake(1); Meson, Overview; Microsoft, vcpkg overview; Conan, Conan 2 documentation。これらの資料は、キャッシュ・vendoring・脆弱性監査ツール、および C/C++ エコシステムに実際のビルド・パッケージ管理ツールが存在するという比較上の境界を裏づけます。 ↩ ↩² ↩³
The Rust Programming Language, What Is Ownership?, References and Borrowing および Reference Cycles Can Leak Memory; The Rust Reference, Behavior considered undefined; The Rustonomicon, Data Races and Race Conditions。これらの資料は、GC なしの所有権ベースのメモリ管理、データ競合と未定義動作の境界、一般的な競合状態とメモリリークが保証の外に残ることを区別しています。 ↩ ↩²
C++ Core Guidelines, C++ Core Guidelines。このガイドラインは、RAII と資源ハンドル、スマートポインタとコンテナによる自動資源管理、生の所有ポインタと直接の new/delete の使用を減らす現代 C++ の安全性慣行を説明しています。これは C++ に安全な資源管理技法がないかのような比較を避けるための根拠であり、このガイドラインの推奨が Rust のコンパイラ強制と同一の保証を提供するという意味ではありません。 ↩
Oracle Java SE, Garbage Collector Implementation および Available Collectors。公式文書は、ガベージコレクションのスループットとレイテンシを別個の指標として説明し、コレクタごとに停止時間・スループット・メモリ使用量のトレードオフと適用条件が異なることを示しています。 ↩
The Cargo Book, Why Cargo Exists および cargo; The rustup book, Components, Profiles および Overrides; The Rust Programming Language, Useful Development Tools。これらの資料は、Cargo の共通作業フロー、rustup の toolchain/component 管理、既定プロファイルの rustfmt・Clippy、インストール可能な rust-analyzer、rust-toolchain.toml によるプロジェクトごとの toolchain 指定の範囲を説明しています。 ↩
Rust Compiler Performance Working Group, Rust compiler performance survey 2025 results; Rust Survey Team, 2025 State of Rust Survey Results。前者は 3,700 人以上の回答に基づいて Cargo コマンドの利用とビルド・CI の待機コストを報告し、後者は 7,156 件の完了回答に基づいて生産性を制約する問題を扱っています。どちらも自発的に参加した Rust 関連の回答者集団の資料であるため、他言語との統制比較や Cargo の因果効果を直接推定する資料としては用いません。 ↩
CMake, cmake(1) および CMake Presets; Meson, Overview; Microsoft, vcpkg overview および Manifest mode; Conan, Introduction。これらの資料は、C/C++ エコシステムにも、ビルド・テスト・パッケージング、manifest ベースの依存関係・バージョン管理、バイナリパッケージ、private repository を支援する実際のツールが存在することを示しています。 ↩
The rustup book, Cross-compilation; The Rust Programming Language, Installation。公式文書は、rustup target add が対象の標準ライブラリを提供しても外部 linker・SDK が別途必要な場合があり、通常の Rust ビルドにも linker が必要で、一部の crate が C コンパイラを要求する場合があることを説明しています。 ↩
Maxwell E. McCombs and Donald L. Shaw, The Agenda-Setting Function of Mass Media, Public Opinion Quarterly 36(2), 1972, pp. 176-187. 原研究は、1968 年の米国大統領選挙における Chapel Hill の有権者調査と、彼らが利用したメディアの内容分析を比較し、メディアによる争点の強調と受け手が認識する争点の重要度との関係を検討しました。したがって本書で「アジェンダ設定」を Rust 言説に適用するには、単なる表現の反復ではなく、比較可能な言説資料、期間、受け手側の重要度測定、因果推論の限界を別途示す必要があります。 ↩ ↩² ↩³ ↩⁴
Rust Core Team, Announcing Rust 1.0 Alpha; The Rust Programming Language, Fearless Concurrency; Rust Core Team, A new look for rust-lang.org; Rust Project, Rust Programming Language。これらの資料は、安全性・性能・並行性という初期の価値提案、「fearless concurrency」という公式表現、2018 年のウェブサイトにおけるメッセージとスローガンの改訂、そして本書の改訂時点におけるトップページの Performance・Reliability・Productivity という構成を示しています。これは公式メッセージの内容と変化を示す資料であり、受け手への効果やコミュニティ全体の言説頻度を測定した資料ではありません。 ↩ ↩² ↩³
Rust Core Team, Laying the foundation for Rust’s future および Next steps for the Foundation Conversation; Rust Foundation, Hello World!; Rust Project, Governance。2020 年の資料は Mozilla の財政・法務支援、財団設立の目的、多くの Rust チームの意思決定権限を維持するための境界を説明し、2021 年の発足資料は当時の創設メンバーと理事会構成を記録しています。Governance ページは、本書の改訂時点における Rust プロジェクトの別個のガバナンス構造を示します。これらは制度的支援と構造を確認する資料であり、外部からの信頼や採用効果を独立に測定した資料ではありません。 ↩ ↩² ↩³ ↩⁴
Rust Project, Code of conduct および Learn Rust; The Rust Programming Language, The Rust Programming Language。行動規範は公式 Rust 空間に適用される行動基準とモデレーション手続きを、学習ページと Book は公式学習資源の存在と範囲を示します。これらの存在だけで、コミュニティ全体の行動、参入障壁の低下、学習成果、貢献者の定着効果が測定されたとはみなしません。 ↩
The Rust Reference, Influences; The Rust Programming Language, What Is Ownership? および References and Borrowing; C++ Core Guidelines, C++ Core Guidelines。Rust Reference は C++ の references、RAII、smart pointers、move semantics を直接的影響として、ML Kit と Cyclone の region-based memory management を別の影響として列挙しています。Rust Book は scope 終了時に drop で資源を解放するパターンと C++ RAII の関係を説明し、C++ Core Guidelines は RAII と resource handle による自動資源管理を定義しています。これらの資料は、歴史的影響と各技法で規則が強制される位置を確認するために用い、「ownership」という一般概念の最初の発明を特定の言語に帰属させる根拠にはしません。 ↩ ↩² ↩³ ↩⁴ ↩⁵
Ada Resource Association, Ada 83 Rationale, LRM, & Guides; Ada Reference Manual, Introduction; Ada 95 Rationale, Part Two, Chapter 3; Altran Praxis/AdaCore, SPARK - The SPADE Ada Kernel; SPARK User’s Guide, Applying SPARK in Practice; AdaCore, Programming Languages for Space Software。Ada の資料は 1983 規格と当初の信頼性・保守性・効率性という目標、型・subtype に対する実行時検査の伝統を示し、古い SPARK 文書は元来の SPARK が Ada 83 に基づいていたことを記録しています。現在の SPARK 資料は AoRTE と contract proof の範囲および仮定を説明し、AdaCore の現在の概要は後年の SPARK pointer support が Rust ownership model に基づくことを明記しています。したがって、この脚注は Ada/SPARK を Rust ownership の直接の祖先として扱わず、歴史的比較と検証範囲を区別するために用います。 ↩ ↩²
The Rust Reference, Influences; Rust standard library, Option および Result; OCaml, Options。Rust Reference が直接明記しているのは、SML/OCaml の algebraic data types、pattern matching、type inference からの影響です。Rust と OCaml の公式資料は、それぞれ Option/Result と option の variant 構造を示しますが、これらの資料だけで Rust の具体的なエラー処理 API やモナド的エラー処理全体の直接的な系譜まで確定するものではありません。 ↩ ↩²
The Rust Reference, Behavior considered undefined。この文書は data race、dangling または misaligned pointer を通じたアクセス、aliasing 違反、誤った ABI による呼び出し、invalid value の生成などを UB の例として列挙し、unsafe 内部でも UB 自体が許されるわけではないと規定しています。また、safe code が unsafe 実装と相互作用するときに safe client が UB を引き起こせないという性質を soundness の境界として説明しています。 ↩ ↩²
The Rust Reference, Array and array index expressions および The unsafe keyword。通常の配列・slice indexing は静的に判定できない場合に実行時 bounds check を行い、失敗すると panic します。一方、get_unchecked のような unsafe 関数は index が範囲内であるという追加の safety condition を caller に要求します。 ↩
The Rust Reference, The unsafe keyword および Behavior considered undefined。Reference は unsafe fn や unsafe trait などが追加の safety condition を定義し、unsafe block や unsafe impl などがその条件を満たしたという proof obligation を示すと説明しています。また、safe client が unsafe コードを通じて UB を引き起こせないとき、そのコードは sound だと定義しています。 ↩ ↩²
The Rust Reference, External blocks および Application binary interface。External block は foreign item 宣言の境界であり、Rust 2024 Edition では unsafe extern が要求されます。ABI には "C"、"system"、"C-unwind" など複数の形式があり、ABI と signature が実際の外部コードの契約と一致するかは、その境界で別途検証すべき責任です。 ↩ ↩²
Cargo Reference, Profiles: panic; Rust standard library, std::panic::catch_unwind、UnwindSafe、JoinHandle::join; The Rust Reference, Destructors。これらの資料は unwind と abort 戦略の違い、catch_unwind が unwinding panic だけを捕捉するという制限、thread panic を join の結果として観測できる範囲、そして soundness を destructor の必須実行に依存させてはならないという境界を説明しています。 ↩ ↩² ↩³
The Rust Reference, Behavior not considered unsafe; Rust standard library, std::mem::forget; The Rust Programming Language, Reference Cycles Can Leak Memory。これらの資料は leak や destructor が実行されないことを Rust の unsafe カテゴリと同一視しないこと、Safe Rust でも reference cycle や mem::forget によって資源リークが起こり得ることを明記しています。 ↩ ↩² ↩³
The Rust Reference, Behavior not considered unsafe; Cargo Reference, Profiles: overflow-checks。Reference は deadlock、memory/resource leak、destructor を実行せず終了する動作などを unsafe と区別します。また debug_assert! が有効な場合は overflow 検査が panic する必要があり、ほかの build では panic または定義された two’s-complement wrapping が可能であることを説明し、Cargo profile は overflow-checks 設定で実行時 overflow 検査を制御します。 ↩ ↩²
The Rustonomicon, Data Races and Race Conditions。この文書は data race を UB と区分しながら、Safe Rust が一般的な race condition まで防ぐわけではないと明記しています。 ↩
Rust Security Response WG, Security advisory for the standard library (CVE-2024-24576) および Security advisory for the standard library (CVE-2024-43402)。最初の advisory は Windows batch file 実行時の Command argument escaping が不十分だった条件と Rust 1.77.2 での修正を、二つ目はその緩和策を特定条件で回避できたことと Rust 1.81.0 での追加修正を記録しています。これらの事例は memory-safety 欠陥の頻度を測る資料ではなく、safe API の論理的・セキュリティ上の contract が memory safety と別であることを示す限定的な事例として用います。 ↩ ↩²
Martin Fowler, Definition Of Refactoring, 2004。Fowler は refactoring を、観察可能な動作を変えずに内部構造を変更することと定義しています。本節ではこの定義を、言語置換や新規実装と狭義の refactoring を区別するために用います。 ↩ ↩²
C++ Core Guidelines project, C++ Core Guidelines; LLVM/Clang, Clang-Tidy, AddressSanitizer, ThreadSanitizer, UndefinedBehaviorSanitizer。Core Guidelines は現代 C++ の資源・memory・concurrency 規則と段階的導入を説明し、Clang 文書は各解析・sanitizer の診断範囲と計測コストを説明しています。AddressSanitizer と ThreadSanitizer の文書は、それぞれ runtime が production executable へのリンク用途に設計されておらず、セキュリティ上敏感な制約の下で開発されたものではないと明記しています。これらの資料は、ツールによる検出と言語レベルの保証、そしてテスト用計測と production 配備の境界を同一視しないために用います。 ↩ ↩² ↩³
Android Open Source Project, Memory safety, updated 2026-07-16; Google Security Blog, Rust in the Android platform, 2021; Google Security Blog, Safer with Google: Advancing Memory Safety, 2024。Android は新規 native code で memory-safe language を採用し、既存 C/C++ では検出・ハードニングを続け、sandbox と hardware mitigation も併用します。この事例は混合戦略が可能であることを示す特定の大規模プラットフォーム事例として用い、すべてのコードベースの最適戦略として一般化しません。 ↩ ↩² ↩³
Martin Fowler, Strangler Fig, 2024 update。この文書は、重要な既存システムの置換で詳細仕様を把握する難しさと大規模 cut-over のリスクを説明し、段階的 replacement を設計 pattern として示します。本節では変更戦略の選択肢を定義するために用い、段階的移行が全面書き直しより常に低コストまたは高品質であることを示す母集団レベルの証拠としては用いません。 ↩
Google Security Blog, Rust/C++ interop in the Android Platform, 2021; Google Security Blog, Deploying Rust in Existing Firmware Codebases, 2024。前者は Android で C++ 全体の書き直しを前提とせず相互運用性を実用上の要件として分析し、後者は新規・高リスクコードを優先する段階的 Rust 導入と C API を維持する shim を説明します。特に前者は分析範囲を Android platform に限定しているため、これらの戦略を他のコードベースへ一般化するには追加の根拠が必要です。 ↩
Google Security Blog, Bare-metal Rust in Android, 2023。Android team は AVF の protected-VM firmware を Rust で書き直したと記録しています。この事例は特定のセキュリティ境界で bounded rewrite が選択され得ることを示すものであり、Android 全体または一般の大規模 legacy system の全面書き直しを正当化する根拠へ拡張しません。 ↩
AdaCore, SPARK User’s Guide 27.0w — Levels of Software Assurance および Prove Absence of Run-Time Errors。文書は Stone、Bronze、Silver、Gold、Platinum を異なる verification objective として区別し、Silver の AoRTE では Storage_Error が解析対象外であり、Platinum は contract が functional requirement を十分に包含していることを前提にすると説明しています。 ↩ ↩² ↩³
Ada Resource Association, Ada 2022 Reference Manual、特に 11.5 Suppressing Checks、11.4 Exception Handling、9 Tasks and Synchronization、C.6 Shared Variable Control、13.9.1 Data Validity。Ada 2022 Reference Manual は ISO/IEC 8652:2023(E) に対応します。これらの資料は、language-defined check の失敗と exception semantics、check suppression が作る erroneous-execution の境界、atomic/protected synchronization と unchecked access の限界を区別するために用います。 ↩ ↩² ↩³ ↩⁴
AdaCore, SPARK User’s Guide 27.0w — Managing Assumptions および How to Write Subprogram Contracts。GNATprove の結果は modular contract や未解析 code・external environment に関する assumption に依存し得ます。文書は、それらを testing、manual analysis、review などにより別途正当化するよう求めています。 ↩ ↩² ↩³
AdaCore, SPARK User’s Guide 27.0w — Concurrency and Ravenscar Profile。文書は、shared data への erroneous concurrent access、すなわち data race を避けるため tasking を制限する一方、atomic read-modify-write の例では data race がなくても lost-update race condition が残り得ることを明記しています。また Ravenscar の単一コア protected-object locking には Priority Ceiling Protocol を用いて deadlock の不在を確保し、GNATprove が potentially blocking action と複数の tasking 制約を検査すると説明しています。同時に、現在の project-wide tasking analysis は処理中 source file の with closure に依存するため、一部の分離された library/task 構成で関連 check を見逃し得る実装上の限界も文書化しています。したがって、文書化された data-race/deadlock 保証を、一般的な concurrency correctness や解析 context 外の whole-system 保証へ拡張しません。 ↩ ↩²
Microsoft, Fundamentals of garbage collection および Debug a memory leak; Go Project, A Guide to the Go Garbage Collector および runtime.AddCleanup。Microsoft の資料は managed reachability、retained-object leak、unmanaged resource に対する明示的な Dispose path を説明し、Go の資料は reachability ベースの回収と、cleanup が任意に遅延したり実行されなかったりする境界を説明します。したがって GC-managed memory reclamation を deterministic resource-release contract へ拡張しません。 ↩ ↩²
Go Project, Go 1.26 Release Notes および A Guide to the Go Garbage Collector; Oracle, Java SE 26 HotSpot VM Garbage Collection Tuning Guide — Available Collectors, Garbage-First (G1) Garbage Collector, Ergonomics; Microsoft, .NET GC latency modes。Go GC guide は implementation detail が version によって変わり得ることを明記し、Go 1.26 release note は Green Tea が現在の既定 collector であることを記録しています。本節では古い固定 pause 数値ではなく、文書化された cost/latency の範囲と collector ごとの trade-off を使用します。Oracle と Microsoft の資料と合わせ、pause-time goal と hard deadline を区別する根拠としても使用します。 ↩ ↩² ↩³ ↩⁴
Oracle, Java SE 26 G1 Garbage Collector および Ergonomics; Microsoft, .NET GC latency modes; Go Project, A Guide to the Go Garbage Collector — Latency。三つの資料はそれぞれ、pause-time goal の確率的・heuristic な性質、low-latency mode の memory-pressure 境界、concurrent GC でも残る latency source を示します。本節ではこれらを application-level hard real-time 保証へ拡張しません。 ↩
公開言説の定性的事例として、Reddit r/rust の backend/Rust 経験の議論、unsafe soundness bug の議論、Rust Users Forum の長時間稼働サービスと memory leak の議論を使用します。これらは論証の存在と構造を示すための事例であり、標本設計がないため Rust コミュニティ全体の頻度・代表性・合意を推定する資料としては使用しません。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹²
Rust Project, 公式サイト — Why Rust? および rust-lang/rust README — Why Rust?。現在の公式サイトとリポジトリ紹介は、Rust を誰もが reliable and efficient software を構築できるようにするツールとして説明し、performance、reliability、productivity を別々の価値提案として示します。ここでは、それらを概念的先取権や普遍的優越性の主張へ拡張しません。 ↩
Rust Project, The unsafe keyword, Behavior considered undefined, Behavior not considered unsafe, std::mem::forget。Reference は unsafe を proof obligation の生成・解消（create or discharge）として説明し、safe client が UB を引き起こせる unsafe abstraction を unsound と定義します。また leak と destructor の未実行は unsafe とみなされず、mem::forget はこの保証境界を理由に safe API です。 ↩ ↩² ↩³
ISO/IEC JTC1/SC22/WG21, N1128 — auto_ptr proposal wording, 1997, N4168 — Removing auto_ptr, N3245 — C++ Standard Library Active Issues List, 2011, N3296 — C++ FCD Comment Status. N1128 は C++11 より前の auto_ptr とその strict-ownership transfer semantics を記録しています。N4168 は、2007年に N1856 の方向が受け入れられ、unique_ptr の追加方向と auto_ptr の deprecation が進んだことを記録しています。2011年の委員会資料は、C++11 時代の標準ライブラリ設計に unique_ptr と shared_ptr が含まれていることを示します。これらの資料は年代と標準化の文脈を確認するために用い、特定の C++ smart pointer から Rust への因果的系譜を立証する資料としては用いません。 ↩
C++ Core Guidelines, Resource management; ISO/IEC JTC1/SC22/WG21, N3025 — Specifying Pointer-Like Requirements; The Rust Programming Language, What Is Ownership?; Rust standard library, std::rc::Rc および std::sync::Arc. これらの資料は exclusive ownership、move semantics、moved-from unique_ptr state、RAII、reference-counted shared ownership の意味論的比較を支えます。unique_ptr や shared_ptr が Rust の型、または Rust ownership 全体の一対一の歴史的祖先であることを示す証拠としては用いません。 ↩ ↩²
The Rust Programming Language, What Is Ownership?, References and Borrowing, Unsafe Rust; The Rust Reference, The unsafe keyword, Behavior considered undefined. これらの資料は compiler-checked ownership/borrowing rule、unsafe に限定して許される operation、unsafe code でも通常の検査が有効であること、compiler verification の外側に残る proof/soundness obligation を確認するために用います。Rust Reference は、この種の proof obligation が run-time check や data-structure invariant によって discharge され得ることも明記しているため、本節ではこの語を machine-checked formal proof の証拠として用いません。 ↩ ↩² ↩³
The Rust Reference, The unsafe keyword; The Rust Programming Language, Unsafe Rust, RefCell<T> and the Interior Mutability Pattern; The Rustonomicon, Splitting Borrows; Rust standard library, RefCell, Result::unwrap. Rust 文書はこの文脈で type system を保守的近似として説明し、borrow checker が直接推論できない disjointness を unsafe implementation で確立する safe abstraction、RefCell の run-time borrow checking、panic する borrow/borrow_mut と panic せずエラーを返す try_borrow/try_borrow_mut の違い、unwrap() が Err で panic することを記録しています。これらの資料は developer psychology や defensive-programming behavior の因果関係を示すものではありません。 ↩ ↩² ↩³
C++ Core Guidelines, I.11: Never transfer ownership by a raw pointer or reference, R.20: Use unique_ptr or shared_ptr to represent ownership, R.32: Take a unique_ptr<widget> parameter to express that a function assumes ownership. Guidelines は段階的導入と、language/library semantics と tool-enforced guidance の混在を説明し、unique_ptr parameter が ownership transfer を文書化すると同時に enforce するとも述べています。ここでは enforcement scope を比較するために使い、C++ と Rust が同等の既定 memory-safety guarantee を提供するという主張には用いません。 ↩ ↩²
Rust standard library, std::collections::LinkedList および linked_list module; The Rust Programming Language, Reference Cycles Can Leak Memory. 標準ライブラリ文書は owned node を持つ safe doubly linked list を説明し、Vec または VecDeque が通常より高速でメモリ効率と cache locality に優れると述べています。Rust Book は strong Rc cycle が memory leak を起こし得ること、Weak は ownership を表さず ownership cycle を切れることを記録します。これらの資料から一つの representation が普遍的に最適だとは主張しません。 ↩ ↩² ↩³
AdaCore, SPARK User’s Guide 27.0w — Language Restrictions, Memory Ownership Policy, Pointer Support, Ownership, and Dynamic Memory Management, Applying SPARK in Practice. これらの資料は access value に対する SPARK の ownership-based restriction、moving/borrowing/observing semantics、cycle や sharing を含む pointer-based structure が現在一般に supported ownership pattern の外側にあることを記録し、supported linked list/tree と unsupported conventional doubly linked list/DAG を具体的に対比します。 ↩ ↩²
AdaCore, SPARK User’s Guide 27.0w — Formal Containers Library, Applying SPARK in Practice — Pointer-Based Data Structures. 公式 guide は実用的な場合 pointer-intensive structure の代替として SPARK container abstraction を推奨し、SPARK.Containers.Formal.Doubly_Linked_Lists と SPARK.Containers.Formal.Unbounded_Doubly_Linked_Lists の両方を提供しています。また bounded formal container は dynamic allocation を使用せず、unbounded variant は dynamic allocation を使用することを区別し、GNATprove が SPARK-visible contract に対する client の正しい利用を proof できても non-SPARK private implementation が specification を満たすことまで証明するわけではないと説明します。これらの点は explicit pointer-graph restriction と container-level availability を区別し、library implementation を別の trust/verification boundary として残します。 ↩ ↩² ↩³ ↩⁴
The Rust Programming Language, What Is Ownership?, References and Borrowing, Validating References with Lifetimes; The Rust Reference, Borrow operators, Pointer types — References。これらの資料は move/copy と borrowing の動作、参照の有効性規則、shared borrow と mutable borrow の区別、ライフタイム注釈が参照の実際の生存期間を変えるのではなく関係を表すことを確認します。また lifetime inference/elision も文書化しています。この脚注は言語・コンパイラの動作だけを裏付け、開発生産性への効果を立証するものではありません。 ↩ ↩²
Shuofei Zhu et al., Learning and Programming Challenges of Rust: A Mixed-Methods Study, ICSE 2022; Will Crichton, Gavin Gray, and Shriram Krishnamurthi, A Grounded Conceptual Model for Ownership Types in Rust, OOPSLA 2023; Will Crichton and Shriram Krishnamurthi, Profiling Programming Language Learning, OOPSLA 2024; Rust Survey Team, 2024 State of Rust Survey Results。ICSE 研究は Rust 関連 Stack Overflow 質問100件の手作業分析と Rust programmer 101人の survey を組み合わせています。OOPSLA 研究は特定の読者母集団における ownership 理解と学習行動を測定し、2023年の initial deployment は original version に対して Ownership Inventory が平均9%高いこと（N = 342, d = 0.56）を報告し、2024年の研究は62,526人の読者と1,140,202件の quiz 応答を分析して、12の介入後に対象設問の成績が平均20%向上したことを報告しています。2024 State of Rust survey の完了回答は7,310件で、回答者の約92%が Rust user と自己認識し、非利用者の約31%が perceived difficulty を主な非利用理由に挙げ、53%の回答者が Rust を productive に使える水準と自己評価しました。これらは self-selected な Rust 関連 survey の結果であり、組織生産性や一般の開発者母集団を直接推定するものではありません。 ↩ ↩² ↩³
Rust Project, Rust Survey 2021 Results, 2025 State of Rust Survey Results, Lessons learned from the Rust Vision Doc process, The many journeys of learning Rust。2021年の職場導入値、すなわち83%が導入を challenging とし、13%が導入中に Rust がチームを遅くしたと報告し、82%がチームの目標達成に役立ったと答えた値は、制御された言語比較ではなく回答者の self-report です。2025 survey は7,156件の回答を収集し、約7千件の回答とさらに小さい optional-question の分母から過度に外挿しないよう明示的に警告し、slow compile time/storage usage と debugging を無視できない productivity problem として報告しています。Vision Doc process は4,200件を超える survey 回答と70件を超える interview を集め、企業全体の測定より individual developer experience を主に扱い、Rust を拒否・中止した人へ到達しにくいことを含む selection bias を記録しています。学習経路の事例が示すのは質的な多様性と可能な支援 pattern であり、頻度、標準的 ramp-up 期間、組織生産性への因果係数ではありません。 ↩ ↩²
Abraham Kaplan, The Conduct of Inquiry: Methodology for Behavioral Science, Chandler Publishing Company, 1964; Abraham H. Maslow, The Psychology of Science: A Reconnaissance, Harper & Row, 1966。Kaplan の議論と Maslow の hammer の比喩は、familiarity が問題設定を狭め得るという方法論的注意として利用できます。これは software developer の母集団研究ではなく、Rust の学習が Rust の適用範囲を広げることを因果的に示す根拠でもありません。 ↩
Len Bass, Paul Clements, and Rick Kazman, Software Architecture in Practice, 3rd Edition と publisher の sample chapter, “Choice of Technology,” p. 76。この technology-choice の議論は、利用可能な技術と tool、組織内部の familiarity、外部 support、side effect、既存 stack との compatibility を明示的に含み、architecture framework も quality attribute と constraint を設計入力として扱います。この資料は多次元の選択基準を支持するもので、programming language の順位表を支持するものではありません。 ↩
Rust Survey Team, 2024 State of Rust Survey Results。survey は7,310件の完了回答を受け取り、回答者の約92%が Rust user と self-identify し、Rust project はこの survey が主に既存 Rust developer を対象としていると説明しています。職場で Rust を使う回答者の21%は、すでに Rust を知っているので default choice として使うと回答しました。また report は server backend、web/networking service、cloud technology を survey 内で特に多い technology domain としています。これらは Rust-oriented な survey 標本を記述するものであり、非合理的な tool bias、backend market share、比較生産性、普遍的適合性を立証しません。 ↩ ↩²
Rust Project, The Rust Reference — Functions: Async functions, std::future::Future, Asynchronous Programming in Rust — Why Async?。これらは async call が future を返すこと、Future::poll が実行 interface であること、Rust が built-in async runtime を提供しないこと、Rust async では heap allocation と dynamic dispatch が必須ではないことを示します。application 全体の runtime cost がゼロであることを示すものではありません。 ↩
Rust Project, Asynchronous Programming in Rust — Pinning, std::pin。文書は compiler-generated future の address sensitivity、Pin contract、pinning が現れる low-level case を説明し、通常の async/await 利用者は pinning を直接扱う必要がないことが多いとも明記しています。 ↩
Rust Survey Team, 2024 State of Rust Survey Results; Rust Project, 2025 March Project Goals Update, 2026 Project Goals。survey の open answer は async programming と debuggability の困難を挙げ、project-goal 記録には async ergonomics と Pin に関する継続作業が含まれます。これは認識された作業領域を示すもので、頻度や比較 developer productivity の controlled estimate ではありません。 ↩
Rust Project, Asynchronous Programming in Rust — Why Async?; Tokio, tokio::runtime, tokio::sync。資料は境界の両面を示します。Rust は built-in runtime を提供せず、Tokio は scheduler、I/O driver、timer service をまとめて提供しますが、多くの Tokio synchronization primitive は runtime-agnostic で、一部の timer-dependent operation はそうではありません。したがって runtime coupling は ecosystem 全体から推論せず、API ごとに評価する必要があります。 ↩
Rust Project, The Rust Reference — External blocks: Functions, Functions: Async functions, std::future::Future。external block の foreign declaration は async qualifier を受け入れず、Rust async function は poll interface が Rust 固有の Pin と Context を使う future を生成します。これは明示的な cross-language async protocol が必要であることを示しますが、blocking または callback bridge だけが可能だという意味ではありません。 ↩
Rust Project, 2026 Project Goals, Async Future Memory Optimisation。採択された2026年の作業には async future memory と state-machine optimization が含まれます。memory-optimization goal は大きな nested-future layout を文書化し、stack overflow と、cloud・embedded・kernel の memory-constrained environment に関する懸念を報告しています。これは進行中の implementation limit に関する project の problem statement と engineering evidence であり、すべての async Rust program を対象とする population-wide benchmark ではありません。 ↩
The Go Project, The Go Programming Language Specification — Go statements, Rust Project, The Rust Reference — Async functions。specification は異なる実行 model、すなわち Go の go statement は goroutine を開始し、Rust async function は poll によって進行する future を返すことを確認します。それ自体で相対的 latency、memory use、debugging difficulty、developer productivity を立証するものではありません。 ↩
Rust Project, core::result、#[must_use]、rustc unused_must_use lint。Result は must_use で、無視すると既定で warning になります。lint policy で error に昇格できますが、すべての program で本質的な hard error ではありません。 ↩
Rust Project, The Rust Reference — try propagation expression、core::result。Result の ? は Err で早期 return し、residual の変換に From::from を使います。 ↩ ↩²
Oracle, Java Language Specification, Java SE 26 — Chapter 11 §11.2。checked exception は catch または declare が必要で、RuntimeException と Error 系統は unchecked です。 ↩
Haskell 2010 Language Report、Microsoft F# — Results、Discriminated Unions。Rust 以前の ADT 表現を確認しますが、Rust への直接の影響系譜までは示しません。 ↩
Rust Project, Panic、catch_unwind、Cargo Profiles: panic。unwind/abort、cleanup、回復境界、target 制約、profile policy を区別します。 ↩
Matthew Prince, “Cloudflare outage on November 18, 2025”, 2025-11-18。duplicated feature metadata、200-feature limit、Result::unwrap() による Rust panic の incident chain を記録しますが、Rust production code 全体の unwrap 行動を示しません。 ↩
Rust Project, Cargo — Specifying Dependencies、SemVer Compatibility。left-most non-zero component を基準にし、initial-development rule は convention で hard guarantee ではありません。 ↩
Rust Project, Cargo — Publishing on crates.io。複数 owner と cargo yank を説明し、yank は削除や既存 lockfile の破壊なしに新規 resolution から除外します。 ↩
Rust Secure Code Working Group, RustSec Advisory Database。advisory と cargo-audit などは vulnerability management を支援しますが crate 全体の品質認証ではありません。 ↩
Rust Survey Team, 2025 State of Rust Survey Results。7,156件の回答、外挿上の注意、maintainer support の関心を示しますが registry-wide bus factor は測りません。 ↩
Rust Project Vision Doc group, “What we heard about Rust’s challenges”、“Lessons learned from the Rust Vision Doc process”。後者は約4,200件の survey と70件超の interview、Rust に否定的な参加者を十分集めにくかった selection bias、さらに一部 domain の具体的な優先順位を決めるには evidence が不足するという限界を記録しています。前者の original version は撤回され、現在のページは約70件の interview からチームが特定した high-level challenge に brief personal commentary を加えた改訂版であり、通常の Vision Doc 成果物より statements が biased になると明示しています。crate discovery/trust と一部 domain の未成熟な coverage は残されていますが、本書では qualitative prompt としてのみ用い、registry-wide prevalence、平均品質、ecosystem ranking の根拠にはしません。 ↩ ↩²
Rust Compiler Performance Working Group, “Rust compiler performance survey 2025 results”。3,700件超の self-selected 回答により build experience、平均6/10、selected-workload rebuild、IDE/CI を報告し、質問設計が inference boundary を定めます。 ↩ ↩² ↩³
Rust Compiler Development Guide, “Monomorphization”、“Overview of the compiler”。concrete generic instance の compile/binary cost と、より広い compiler pipeline を区別します。 ↩ ↩²
Rust Compiler Team, “Rust debugging survey 2026”。tool/OS による品質差と visualizer、async、expression evaluation 等の改善対象を示す project status であり比較生産性研究ではありません。 ↩
Rust Project, Cargo — Build Scripts。C build、native library、generated module、platform configuration と change detection を説明します。 ↩
Rust Project, Cargo — Features、Workspaces、Optimizing Build Performance。feature/resolver、shared workspace state、build trade-off を説明します。 ↩
Rust Compiler Performance Working Group, “Rust compiler performance survey 2025 results”; Rust Compiler Team, “Rust debugging survey 2026”。current build/editor observation と debugging goal をそれぞれの inference limit 内で示し、Java/C# や特定 IDE との一般 maturity ranking は示しません。 ↩ ↩²
Rust Project, The Rust Programming Language — Performance in Loops vs. Iterators and The Embedded Rust Book — Zero Cost Abstractions. iterator の例は追加 runtime overhead の不在として zero-cost を説明し、自身の benchmark の限界も明記します。embedded の例は zero-sized typestate が runtime で消去される別の mechanism を示します。どちらも lifecycle 全体の cost-free を立証しません。 ↩
Alpine Linux, Alpine 3.24.1 released, 2026-06-13, and the official v3.24 stable x86_64 package repositories. Measurement date: 2026-08-28. The measured APKs were busybox-1.37.0-r31.apk (SHA-256 0e626fa97cf937fda7bba4ed4dde8e2f2dbb5083ac34e02180cec0c4eba9351b), coreutils-9.11-r0.apk (18710a17a606d2454491d7e5b6114776c2ea861633234efdaee5b85fad5f2434), and uutils-0.9.0-r0.apk (4dfdc5be7b31965765b21573ea53fce49a0765db83b822ae8d6911ee9437e1b8). After extraction, file identified /bin/busybox, /bin/coreutils, and /bin/uutils as stripped dynamically linked x86-64 PIE executables; file sizes were measured directly from those ELF files. uutils-coreutils is a metapackage depending on uutils, so it was not used as the measured implementation. The snapshot does not normalize command coverage or shared-library dependency closure. ↩
Rust Project, The rustc book — prefer-dynamic and The Rust Reference — Linkage. rustc は既定で static dependency linkage を優先しますが dynamic linkage も利用でき、Reference は rlib、Rust dylib、system staticlib、cdylib を定義します。 ↩
Rust Project, The Rust Reference — External blocks: ABI and Type layout. extern "Rust" に stability guarantee はなく default Rust representation の layout guarantee も限定的です。extern "C" と repr(C) は明示的 interoperability boundary です。 ↩ ↩² ↩³ ↩⁴
Rust Project, The Cargo Book — Profiles. s/z、debuginfo/strip、LTO、codegen-units、panic control と compile/link/runtime trade-off を記録し、size-oriented level が必ず小さくなるとは限らないと注意します。 ↩
Rust Project, The Rust Reference — no_std, alloc, and The Embedded Rust Book — A no_std Rust Environment. no_std は core を使い、allocator があれば alloc が Vec、Box、String を提供します。startup、panic handling、allocator、platform integration は environment 側の責任として残ります。 ↩
Linux Kernel documentation, Rust Quick Start, documents CONFIG_RUST, the rust/ support code, samples/rust/, the complete LLVM setup as the best-supported build configuration, and GCC support for some configurations as very experimental. Direct inspection of the official Linux 7.2.1 stable source snapshot used for the cloc measurement also found Rust Binder under drivers/android/binder/ and Rust GPU drivers under drivers/gpu/drm/nova/ and drivers/gpu/drm/tyr/; the Nova and Tyr Kconfig help text marks them work in progress and potentially non-functional. ↩ ↩²
Linux Kernel Archives, kernel.org, stable Linux 7.2.1, 2026-08-27. Measurement date: 2026-08-30. Artifact: linux-7.2.1.tar.xz, SHA-256 4158098c8a28ea8fbe068c855d3aa6341e03d06282add3cb9049f3a24e4557b3. Tool: Debian APT package cloc 2.04-1 (cloc v2.04). Procedure: extract the official tarball and run cloc . without additional options at the source root. The command reported 82,371 unique files, 30,518,591 total code lines, and 114,481 Rust code lines. This is a source-tree composition measurement, not a runtime-use, binary-size, defect-rate, or production-adoption metric. ↩ ↩²
Linux kernel CVE record as reproduced by NVD, CVE-2025-68260, and the upstream fix 3e0ae02ba831da2b707905f4e602e43f8507b8cc. The record describes an unsafe removal from Rust Binder’s death_list, a concurrent list-access race and pointer corruption, and records Linux 6.18 as affected with 6.18.1 and 6.19-series fixes. It supports the specific unsafe-boundary failure analysis, not a defect-rate comparison between Rust and C kernel code. ↩ ↩² ↩³
Ferrous Systems, Ferrocene Part 3: The Road to Rust in mission- and safety-critical, 2021; AdaCore, AdaCore and Ferrous Systems Joining Forces to Support Rust, 2022 および Announcements around Rust, 2023; Ferrous Systems, Officially Qualified - Ferrocene, 2023; Ferrocene, Qualification Plan および Safety Manual - Qualification scope; Ferrous Systems, Ferrocene 26.02.0 now available!, 2026. Ferrous Systems は2021年、子会社 Critical Section GmbH とともに Ferrocene を安全上重要な領域における Rust 言語・コンパイラの qualification プロジェクトとして公開しました。AdaCore と Ferrous Systems は2022年に共同開発を発表し、2023年にはその共同開発パートナーシップの終了を発表しました。現在公開されている qualification 資料は、コンパイラの ISO 26262 ASIL D/TCL 3、IEC 61508 class T3、IEC 62304 の範囲と Safety Manual の使用制約を文書化しています。2026年の Ferrocene 資料は TÜV SÜD qualification を ISO 26262 ASIL D、IEC 61508 SIL 3、IEC 62304 Class C と説明し、core の認証済み部分集合を ISO 26262 ASIL B、IEC 61508 SIL 2 と区別し、DO-178C DAL C は顧客の認証活動を支援する範囲としています。これは、Ferrocene でビルドした個別のアプリケーションやシステムが自動的に該当する安全等級の認証を取得するという意味ではありません。 Ferrous Systems, Ferrocene 26.05.0 now available!, 2026-07-28 は、最新 release が TÜV SÜD-qualified compiler、ISO 26262 ASIL B / IEC 61508 SIL 2 の certified core subset、DO-178C DAL C と IEC 61508 SIL 4 に向けた customer certification support、upstream Rust 1.93.0〜1.95.0 の変更を含むと説明します。公開 main の Evaluation Plan - Qualification Scope は qualified tool を rustc に限定し companion development tool を unqualified と区別しますが、ページ自体が incomplete/inaccurate の可能性がある development-branch preview と警告しています。同じ main の Safety Manual/Core Certification にある rustc/core 1.99.0 は、次期 rolling development snapshot の scope 情報としてのみ用い、release 済み 26.05.0 の qualification version として扱いません。 ↩ ↩² ↩³
Rust Survey Team, 2025 State of Rust Survey Results. 7,156 件の回答を集め、Rust developer を追加採用する予定の組織が増えていると報告する一方、Rust-oriented な回答者母集団と optional question の小さい denominator からの過度な外挿を戒めます。これは Rust 関連 hiring activity を示すもので、言語別 labor-pool や wage ranking を確立しません。 2025 survey は2025-11-17から12-17まで実施され、9,389人が開始し7,156人が完了しました（completion 76.2%）。report 自身が約7,000件からの過度な外挿を戒め、optional question の denominator はさらに小さいと明記します。したがって hiring graph は survey された Rust-oriented population とその組織の trend を示すもので、job posting の census、労働市場全体の規模、言語間 wage estimate ではありません。 ↩
CMU Software Engineering Institute, “The Growing Importance of Sustaining Software for the DoD: Part 1”. software sustainment を物理的摩耗と区別し、hardware/environment、requirement、defect、performance の変化が継続的 maintenance 要因になることを説明します。 ↩ ↩²
Robert C. Seacord et al., CMU Software Engineering Institute, “Legacy System Modernization Strategies”, CMU/SEI-2001-TR-025. 大規模で複雑な legacy system に対する modernization の代替案を比較し、言語置換を default として処方しません。 ↩ ↩²
Google Android Security Team, “Rust in the Android platform”, “Eliminating Memory Safety Vulnerabilities at the Source”, and “Deploying Rust in Existing Firmware Codebases”. Google は mature な C/C++ code 全体の rewrite を要求するのではなく、new-code-first、interoperability への投資、既存低層 codebase への incremental/drop-in Rust を文書化しています。 ↩ ↩² ↩³
Google, “Rust in Android: move fast and fix things”, 2025, and Google Android Security Team, “Eliminating Memory Safety Vulnerabilities at the Source”, 2024. 2025 Android report は Android 自身の development/security data 内で Rust と C/C++ または C++ を比較します。これは当該組織・codebase には強い証拠ですが、randomized language experiment や industry-wide estimate ではありません。 ↩
Microsoft, “What’s new in Windows 11 Enterprise LTSC 2024”, documents a Rust implementation of GDI regions in win32kbase_rs.sys in Windows 11 24H2. shipped Windows kernel use case を確立しますが、組織全体の language share や比較 defect-rate を示しません。 ↩
Amazon Web Services, Open Source Security, states that Firecracker is written in Rust and powers AWS Lambda and other serverless offerings, and that the EC2 team uses Rust for new AWS Nitro System components. production adoption の実例ですが universal workload recommendation ではありません。 ↩
Emily M. Bender et al., On the Dangers of Stochastic Parrots: Can Language Models Be Too Big?, FAccT 2021; Youssef Mansour and Reinhard Heckel, Measuring Bias of Web-filtered Text Datasets and Bias Propagation Through Training, 2024/2025. これらの資料は、Web規模の学習データの構成・選別とその分布がモデルの挙動に影響しうるという一般的な危険と実験的可能性を扱います。しかし、いずれもRust対Ada/SPARKの言説分布や特定モデルのRust関連回答バイアスを測定していないため、本書はこれらからRust固有のLLM増幅効果を推論しません。 ↩ ↩²
本書の「銀の弾丸の物語（silver-bullet narrative）」は、Frederick P. Brooks Jr.の No Silver Bullet — Essence and Accidents of Software Engineering, Computer 20(4), 1987, pp. 10-19 における「silver bullet」という比喩を拡張した、本書独自の分析上のラベルです。Brooksの論文はRustや特定の技術コミュニティを研究したものではなく、この用語自体もRust言説の頻度や原因を立証しません。本書では、複雑な問題への条件付き改善策を単一・普遍的な解決策へ拡張する論証を識別する目的だけに使用します。 ↩
Rust Project, Governance; Rust RFC Book, Project Goals 2025H1 および Project Goals 2026; Rust Project Goals, 2026 Overview. これらの資料は、RFCに基づく熟議、bottom-upなproject-goal提案とチーム支援、資源・合意の制約、async ergonomicsやlow-level toolingなど明示された改善課題を示します。公式プロジェクトが未解決課題とtrade-offを公開して扱うことの根拠ではありますが、非公式なRust言説すべての態度を代表する根拠ではありません。 ↩ ↩² ↩³ ↩⁴ ↩⁵
Leon Festinger, A Theory of Cognitive Dissonance, Stanford University Press, 1957; Henri Tajfel and John C. Turner, An Integrative Theory of Intergroup Conflict, 原論文1979年、後の収録版2000年; Matteo Cinelli et al., The echo chamber effect on social media, PNAS 118(9), 2021. これらは一般理論や他の話題・プラットフォームについての経験研究を提供しますが、Rustコミュニティを研究した資料ではありません。したがって本書では、この資料だけからRust利用者の内的動機やRust空間のエコーチェンバーの存在を判定しません。 ↩ ↩² ↩³
Open Source Initiative, History of the Open Source Initiative; GNU Project, Free Software Movement および What is Free Software?. OSIは1998年にopen-sourceという標識を作る際、共同開発の実用的・business-case framingをfree softwareに結びつく哲学的・政治的framingから区別しようとしたと記録しています。GNU資料はfreedomとcommunityをfree softwareの中心価値として明示します。これらの一次資料は、当時の関連技術コミュニティが一つの価値フレームに還元されなかったことを示すために使用します。 ↩
Eric S. Raymond, The Cathedral and the Bazaar, 1997年初出、その後改訂。RaymondはLinux開発世界を、異なるagendaとapproachが共存するbazaarの比喩で説明します。これは一人の参加者による影響力ある同時代解釈であり、1990年代のLinux利用者全体を代表する確率標本ではありません。 ↩
The Jargon File, Version 4.2.2, 20 Aug 2000. この歴史的lexiconはhacker cultureを緩やかにつながったsubcultureの集合として説明し、slangを共有経験とinclusion/exclusionの表現として論じ、M$とRTFMの当時の用例を記録しています。これはhacker slangの存在を示す資料であり、Linux利用者全体の態度や各表現の頻度を測定した代表標本ではありません。 ↩
ISRG Prossimo, A Safer High Performance AV1 Decoder, 2023; Stephen Crane and Khyber Sen, Porting C to Rust for a Fast and Safe AV1 Media Decoder および Optimizing rav1d, an AV1 Decoder in Rust, 2024; memorysafety/rav1d。公式資料は dav1d の C code の移植、native assembly 再利用、drop-in C API、upstream synchronization の目標、および safe Rust への移行過程における性能境界を説明します。 ↩ ↩² ↩³
ISRG Prossimo, $20,000 rav1d AV1 Decoder Performance Bounty, 2025; rav1d v1.1.0 release, 2025。前者は当時 benchmark・input・platform により約 5% の差があると報告して bounty を提示し、後者は dav1d 1.5.1 の性能改善を backport して同期したと記録します。これは特定時点の性能・maintenance 事実であり、現在の全 platform における性能差を意味しません。 ↩
Hacker News, Improving performance of original dav1d video decoder, 2025。討論では assembly 再利用の safety scope、反復 backport cost、codec expertise、長期 support の持続性が問題として提起されました。公開批判の存在と論証構造を示す定性的事例としてのみ使用し、参加者の数値主張や価値判断を独立検証なしに事実として採用しません。 ↩
Antony Flew, Thinking about Thinking: Or, Do I Sincerely Want to Be Right?, Fontana/Collins, 1975. Flew のいう “No-true-Scotsman Move” は、一般化に対する反例を受け入れず、「真の」構成員の定義を事後的に変更して反例を除外する論証を指します。 ↩
Ronny Scherer, Fazilat Siddiq, Bárbara Sánchez Viveros, “The Cognitive Benefits of Learning Computer Programming: A Meta-Analysis of Transfer Effects,” Journal of Educational Psychology, 111(5), 2019, pp. 764–792, DOI: 10.1037/edu0000314. 全体転移効果 g = 0.49、近転移効果 g = 0.75、遠転移効果 g = 0.47 が報告されています。ただし、Rust 固有効果や一般知能の上昇を検証した研究ではなく、研究設計と対照群の種類による差も考慮する必要があります。この meta-analysis は105研究・539 effect sizes を統合しています。moderator analysis では untreated control を使う研究の transfer estimate が treated/active control より大きく、published study の effect も gray literature より大きいと報告されており、こうした design・publication 差は causal/population-wide interpretation をさらに制限します。 ↩
Uniform Guidelines on Employee Selection Procedures, 29 C.F.R. Part 1607, とくに §1607.9 および §1607.14。この指針は米国雇用法の文脈に限定されますが、選考基準を職務分析と経験的妥当性へ結び付ける方法論的な参考例を示します。 §1607.9 “No assumption of validity” は general reputation、label、promotional material、usage frequency、testimonial、anecdotal account を validity evidence の代替として明示的に排除します。§1607.14 は validity study に job information の review と、validation strategy に適した job analysis を原則要求します。これは米国雇用法の framework であり、普遍的心理法則や Rust 固有の主張ではありません。 ↩
Rust Project, A note on the Trademark Policy Draft, 2023-04-12; Rust Foundation, Rust Trademark Policy Draft Revision – Next Steps, 2023-04-17; Rust Foundation, Trademark Policy: Review and Survey, 2022-08-10。これらは2022 survey、2023-04-06 の draft 公開、10日間の consultation、Project Directors・Trademark Working Group・legal counsel との協働、wider Project の参加と communication が不十分だったという認識、そして draft が直ちに施行されず feedback review と revision に移った境界を記録します。 ↩ ↩² ↩³ ↩⁴
Rust Project Leadership Council, Next Steps on the Rust Trademark Policy, 2024-11-06; Rust Foundation, Rust Trademark Policy Updates, 2024-11-06。これらは revised 2024 draft、2023 feedback で繰り返された懸念の分類、package-name restriction の削除や logo・merchandise・publication rules の修正、そして final-feedback draft という状態を記録します。提出 feedback の傾向を示す資料であり、Rust 利用者全体の意見分布を測定したものではありません。 ↩ ↩² ↩³ ↩⁴
Rust Project, Governance および Rust Forge, Leadership Council — Relationship to the Rust Foundation; Rust Project Directors, January & February 2026 Project Director Update; Rust Foundation Board minutes, June 11, 2024。これらは Leadership Council・Project teams・Moderation team の現在の役割、Project Directors が Foundation Board で Project を代表し Foundation relationship を担当する構造、trademark revision が別個の Foundation/Project interface work として進んだ境界を示します。Rust Forge は Project Directors の Foundation-related purview の正確な境界がまだ完全には明文化されていないとも述べるため、本書は文書以上に精密な権限を断定しません。 ↩ ↩²
Rust Foundation, Rust Language Trademark Policy Updates, Explained, 2025-01-23; Rust Foundation, Rust Language Trademark Policy, current page accessed 2026-08-30。前者は Project Directors を含む Foundation Board の最終 approval と主要な許可範囲を記録し、現在の policy は Leadership Council による Project governance と Foundation の trademark ownership/stewardship を区別し、approval-free と approval-required use を具体的に分けます。 ↩ ↩²
National Security Agency, Software Memory Safety, originally November 2022, April 2023 Version 1.1。v1.1 は C/C++・assembly から可能な場合に MSL へ戦略的に移行することを検討するよう勧告し、Python・Java・C#・Go・Delphi/Object Pascal・Swift・Ruby・Rust・Ada を例示するとともに、MSL 間の保証差と non-language hardening の継続的な必要性を明記します。この一覧は “some examples” であり、特定 workload の最終選択や排他的承認リストではありません。 ↩ ↩²
National Security Agency and Cybersecurity and Infrastructure Security Agency, Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development, June 2025, Ver. 1.0, および release notice。報告は Ada・C#・Delphi/Object Pascal・Go・Java・Python・Ruby・Rust・Swift を例示し、MSL は panacea ではなく adoption がすべての状況で現実的とは限らないと明記します。また complete rewrite の代わりに interoperability を利用する統合と、MSL adoption が難しい場合の non-MSL hardening も扱います。 ↩ ↩² ↩³ ↩⁴ ↩⁵
Office of the National Cyber Director, Back to the Building Blocks: A Path Toward Secure and Measurable Software, February 2024。報告は MSL を strong security building block として勧告し、existing codebase の hybrid migration、no-one-size-fits-all 境界、hardware と formal methods の補完的役割を説明します。Space-system 部分では Rust を GC 制約等を満たす一例として挙げつつ、fielded evidence、toolchain maturity、workforce development がさらに必要と明記します。 ↩ ↩²
Jeff Vander Stoep, Alex Rebert, “Eliminating Memory Safety Vulnerabilities at the Source”, Google Online Security Blog, September 25, 2024. Android の比率が6年間で76%から24%へ低下し、新規コードを安全に書く戦略を説明します。 ↩
Jeff Vander Stoep, “Rust in Android: move fast and fix things”, Google Online Security Blog, November 13, 2025. 2025年比率、約500万行、リリース前潜在脆弱性一件に基づく密度推定、レビューとロールバック資料。 ↩
Jesse Howarth, “Why Discord is switching from Go to Rust”, Discord Blog, February 4, 2020. 特定サービスのキャッシュ・GC 条件と再実装結果を説明し、全システム再実装を勧告しません。 ↩
Yizhou Zhang, “How we built Pingora, the proxy that connects Cloudflare to the Internet”, Cloudflare Blog, September 19, 2022. 接続再利用、マルチスレッド、言語境界除去など複数原因を説明します。 ↩
Arun Gupta, “Announcing the Firecracker Open Source Technology: Secure and Fast microVM for Serverless Computing”, AWS Open Source Blog, November 26, 2018. i3.metal のデフォルト microVM と最小デバイスモデルで125ms未満。 ↩
Miguel Ojeda, “[PATCH] rust: conclude the Rust experiment”, Linux Kernel Mailing List, December 13, 2025. 実験終了と継続支援、未完成組合せと残作業。 ↩
Ilia Afanasiev, “Is Rust the Future of Programming?”, JetBrains Blog, May 13, 2025. 2024データから過去12か月利用者226.7万人、主要言語利用者70.9万人を推定。 JetBrains, Developer Ecosystem 2024 — Methodology および Developer Ecosystem Data Playground — Methodology は、2024年5–6月 survey を171の国・地域の23,262 developer に cleaning し、geography、employment status、language use、JetBrains-product use で weighting したことと、response bias がなお残り得ることを文書化しています。population model は survey の category share と model 化した各国 developer population を組み合わせ、得られる population figure を exact count ではなく estimate とします。したがって226.7万人 / 70.9万人は population estimate であり、識別可能な developer の census や Rust job opening 数ではありません。 ↩
Rust Survey Team, “2025 State of Rust Survey Results”, Rust Blog, March 2, 2026. 7,156回答と外挿限界。 ↩
National Vulnerability Database, “CVE-2025-30388”. Windows Win32K-GRFX のヒープバッファオーバーフローとローカル攻撃ベクトルを記録し、Rust 帰属はありません。 ↩
Ubuntu Security, “CVE-2025-68260”. Rust Binder の unsafe リスト削除と並行アクセスがデータ競合・ポインタ破損を起こした過程。 ↩
Rust Project Goals, “Just add async”, 2026. 同期／非同期機能差、同期デストラクタの限界、2026～2027探索課題。 ↩
Defense Advanced Research Projects Agency, “TRACTOR: Translating All C to Rust”. レガシー C の自動 Rust 翻訳研究の目標と評価構造。 ↩
Rust Project Goals, 2026 Goals および C++/Rust Interop Problem Space Mapping。2026 goal list は C++/Rust interoperability の問題空間整理を継続作業として含み、詳細資料は大規模な既存 C++ 資産と段階的な相互運用の必要性を明記しています。これは全面 rewrite が常に不適切だという普遍命題ではなく、相互運用を独立した工学問題として扱うべきだという公式根拠です。 ↩
Rust Project Goals, 2026 Goals および Normative Documentation for Sound unsafe Rust。公式 goal には unsafe safety contract の規範文書化、FLS、sanitizer、MC/DC coverage など高保証用途に関係する作業が含まれます。これらは現在の文書上の空白と計画を示しますが、完了済み certification やすべての domain への適合性を保証しません。 ↩
Rust Foundation, Rust Security Initiative; Rust Project Goals, Implement Verifiable Mirroring Prototype および 2026 contributor tasks。これらは ecosystem audit・threat modeling、cryptographically verified mirroring、Cargo SBOM precursor の現在の作業を説明します。個々の goal の存在は、まだ deploy されていない feature の効果を立証しません。 ↩

Rust言説を解体する

はじめに

目次

第1部：Rustの登場と技術的特性

1. Rust言語の紹介と主要な特性

1.1 誕生の背景：性能と安全性のトレードオフ

1.2 所有権、借用、ライフタイムによるメモリ管理

1.3 ゼロコスト抽象化の系譜

1.4 型システムとパターンマッチによる安全性の確保

1.5 エコシステム：Cargo と Crates.io

1.6 結論：保証の境界と設計コスト

2. Rust採用の要因：技術、エコシステム、物語の相互作用

2.1 技術的背景：メモリ安全性と性能の目標

2.2 開発者体験（DX）：Cargo とツールチェーン

2.3 物語の構築と「アジェンダ設定」の分析

2.4 組織的支援とコミュニティ文化

2.5 採用要因の総合と第2章の結論

第2部：主要設計原則の技術的分析

3. 「安全性」物語の多角的分析

3.1 「革新」の意味と歴史的先例の分析

3.2 Rustの「安全性」の定義、境界、限界

3.2.1 「安全性」の定義：未定義動作の防止

3.2.2 unsafeキーワードとFFI・外部契約の境界 {#322-unsafeキーワードとc-abiへの依存}

3.2.3 「安全な失敗」と panic の意味

3.2.4 「安全な」メモリリークの問題

3.2.5 保証範囲外の問題（論理エラー、デッドロックなど）

3.3 比較分析1：C/C++の多層的な安全性確保と変更戦略

3.3.1 リファクタリング、近代化、書き直しの区別

3.3.2 C/C++内部のリファクタリングと近代化の実質的価値

3.3.3 Rustによる書き直しが追加する保証と新たに生むリスク

3.3.4 変更戦略の連続線と選択的導入

3.3.5 主張分析：「唯一意味のあるリファクタリングはRustによる書き直しである」

3.4 比較分析2：Ada/SPARKの数学的証明と保証水準

3.5 比較分析3：代替的なメモリ管理方式（GC）の再評価

3.6 言説分析：「実用性」と「責任」の再定義

3.6.1 「実用的革新」の言説的機能

3.6.2 「責任」の帰属：メモリリークと unsafe の議論方法

3.6.3 条件付きの工学的利点と普遍的な地位判断の分離

3.7 結論：性能、安全性、生産性のトレードオフ

4. 所有権モデルの再評価と設計思想

4.1 Rust の所有権と C++ RAII・スマートポインタの歴史的関係

4.2 Rust 所有権規則の強制位置と保証境界

4.3 Rust・Ada・SPARK：所有権、アクセス、契約、証明の境界

第3部：エコシステムの現実と構造的コスト

5. 開発者体験の成果とコスト

5.1 借用検査器、学習曲線、生産性：証拠の境界

5.2 技術選択の一般化傾向と工学的トレードオフ

5.3 非同期プログラミングモデルの複雑性と工学的トレードオフ

5.4 明示的エラー処理モデル Result<T, E> の実用性再考

5.5 Rustエコシステムの質的成熟課題とコミュニティ言説分析

5.6 開発ツールチェーンの技術的課題と生産性

5.6.1 コンパイラの資源使用量とその影響

5.6.2 IDE統合とデバッグ環境：抽象化の背後にあるコスト

5.6.3 ビルドシステムCargoの柔軟性

5.7 開発環境の比較：成熟度と設計思想の交差点

6. 「ゼロコスト抽象化」の実際のコスト分析

6.1 コスト転嫁の仕組み：単相化の役割

6.2 バイナリサイズ分析：設計原則が適用領域へ与える影響

7. 産業適用の制約条件

7.1 組込み・カーネル環境：適用の現実と工学的課題

7.2 ミッションクリティカルシステムと国際標準の不在

7.3 一般産業導入の障壁と変更戦略

7.4 「巨大企業の採用」物語の多角的分析：文脈、限界、戦略的含意

第4部：技術コミュニティの言説分析

8. 「銀の弾丸の物語」と集団的防御機制の形成

8.1 「銀の弾丸の物語」の形成過程と効果

8.2 「完全置換」と「書き直しだけが改善」という物語の限界

8.3 技術言説の歴史的先例：1990～2000年代の OS 競争

8.4 批判的言説への論証パターン分析

8.4.1 Linux 7.2.1 における Rust 比率：測定値と重要性判断の分離

8.4.2 memory leak：保証境界と運用上の重大性の分離

8.4.3 rav1d/dav1d：安全性範囲、性能帰属、保守の三つの問い

8.4.4 std::process::Command CVE：memory safety と security の分離

8.4.5 Linux Rust Binder CVE：unsafe 境界と責任帰属

8.4.6 「Rust 以外に代替はない」：候補集合と要件の省略

8.4.7 応答を判定する共通手順

8.5 技術選択の地位化：資格、正常性、知能序列と言説的排除

8.6 2023年商標政策論争とガバナンス

8.6.1 2023年の文書は施行済み政策ではなく consultation draft だった

8.6.2 「撤回」ではなく長期の revision と最終 approval

3.2.2 `unsafe`キーワードとFFI・外部契約の境界 {#322-unsafeキーワードとc-abiへの依存}

3.2.3 「安全な失敗」と `panic` の意味

3.6.2 「責任」の帰属：メモリリークと `unsafe` の議論方法

5.4 明示的エラー処理モデル `Result<T, E>` の実用性再考

8.4.4 `std::process::Command` CVE：memory safety と security の分離

8.4.5 Linux Rust Binder CVE：`unsafe` 境界と責任帰属