Graydon Hoare と Rust：メモリ安全なシステムへの転換

この話が説明すること（としないこと）

この記事は焦点を絞った起源譚を語ります：Graydon Hoare の個人的な実験がどのように Rust に育ち、Rust の設計上の選択がなぜシステムプログラミングの期待を塗り替えるほど重要だったのか。

「システムプログラミング」とは

「システムプログラミング」は機械に近く、プロダクトのリスクに近い領域です。ブラウザ、ゲームエンジン、OS コンポーネント、データベース、ネットワーク、組み込みソフトウェアなどに現れ、通常は次の要件が求められます：

• 高性能（処理は速く予測可能であること）
• 低レベルの制御（メモリ割当て、スレッド、データレイアウト）
• 信頼性（クラッシュやセキュリティバグは高コスト）

歴史的に、この組み合わせはチームを C や C++ に向かわせ、さらにメモリ関連バグを減らすための厳格なルール、レビュー、ツールが求められてきました。

本稿で解きほぐす約束事

Rust のヘッドラインは言いやすく、実現は難しい：

ガベージコレクタなしのメモリ安全性。

Rust は use-after-free、double-free、そして多くの種類のデータレースのような共通の失敗を、プログラムの実行時に周期的に停止してメモリを回収するランタイムに頼らずに防ぐことを目指します。代わりに、Rust は所有権と借用を通じてその多くをコンパイル時に移します。

範囲（含むものと含まないもの）

ここでは歴史（初期のアイデアから Mozilla の関与まで）と主要概念（所有権、借用、ライフタイム、安全と unsafe）を平易に説明します。

含まれないもの：完全な Rust チュートリアル、全構文の紹介、または逐次的なプロジェクトセットアップです。これは Rust の設計の「なぜ」に集中した記事で、概念を具体化するための簡単な例は含みますが、リファレンスマニュアルにはなりません。

ライター注： 完全版は約 3,000 語を想定しており、簡潔な例は置きつつも参照書にはならない分量を狙っています。

Graydon Hoare の初期の実験と Rust への発展

Rust は委員会で設計された「次の C++」として始まったわけではありません。2006 年に Graydon Hoare が個人的に始めた実験が出発点で、より広い注目を集める前に彼自身で進めていたことが重要です。その起源は多くの初期設計判断が理論に勝つためではなく、日常の痛みを解決するための試行に見える理由です。

初期の動機：低レベルの力とフットガンを減らすこと

Hoare はガベージコレクタに頼らずに低レベルで高性能なソフトウェアを書きつつ、C や C++ によくあるクラッシュやセキュリティバグの主原因を避ける方法を探していました。システムプログラマにとって馴染みのある緊張は：

• 高速かつレイアウトを直接制御したい。
• 間違いが静かに脆弱性に転じないよう実用的な安全性が欲しい。
• モダンな性能はしばしばマルチスレッドを意味するので、使える並行性が欲しい。

Rust の「GC なしでのメモリ安全」は初めはマーケティング文句ではなく、設計目標でした：システム作業に適した性能特性を保ちつつ、多くのカテゴリのメモリバグを表現しにくくします。

なぜ新しい言語が必要だったか

「単に C/C++ のコンパイラを改善すればよいのでは」という疑問はもっともです。静的解析やサニタイザ、安全なライブラリといったツールは多くの問題を防ぎますが、言語自体が許すパターンを外部から完全に保証するのは一般に難しいです。

Rust の賭けは、重要なルールを言語と型システムの中に移し、安全性を デフォルトの結果 にすることでした。同時に明確にマーキングされた脱出路（unsafe）で手動制御も可能にしました。

事実と逸話を区別する

Rust の初期の出来事には逸話的に伝わっている話も多く、講演やインタビューで繰り返されがちです。起源譚を語るときは、2006 年の開始や後の Mozilla による採用のような広く文書化された節目と、個人的な回想や二次的な語りを分けると良いでしょう。

一次情報を探すなら、初期の Rust 文書や設計ノート、Graydon Hoare の講演／インタビュー、そしてプロジェクトが採用された理由を説明する Mozilla/Servo 時代の投稿を見ると確かです。さらに読むための節（/blog）も参照してください。

システムプログラミングの問題：速いコードと脆いメモリ

システムプログラミングはしばしばハードウェアに近い作業を意味します。その近さがコードを速く効率的にしますが、同時にメモリのミスを致命的にします。

よくある犯人：メモリバグ

何度も現れる古典的なバグがいくつかあります：

• Use-after-free（解放後使用）：メモリを解放した後で使い続ける、まるで捨てたノートに書き続けるようなもの。
• Double free（二重解放）：同じメモリが二度解放され、アロケータを混乱させたり悪用を招いたりする。
• バッファオーバーフロー：割り当て領域の終端を越えてデータが溢れ、近傍のデータや制御フローを汚染する可能性がある。

これらのエラーは常に明白ではありません。プログラムは何週間も「動く」ことがあり、稀な入力やタイミングでのみクラッシュすることもあります。

テストだけでは救えない理由

テストは試したケースで正しく動くことを証明します。メモリバグは試さなかったケースに潜みがちで、特殊な入力、異なるハードウェア、微妙なタイミングの変化、新しいコンパイラバージョンなどで現れることがあります。特にマルチスレッドでは非決定性になり、ログを足したりデバッガを付けるとバグが消えることすらあります。

本当のコスト：セキュリティ、安定性、時間

メモリが壊れると、単に綺麗なエラーが返るわけではありません。状態が破壊され、予測不能なクラッシュや攻撃者が狙うセキュリティ脆弱性が生まれます。チームは再現が難しい故障を追いかけるのに大きな労力を割きます。

速度と安全性の核心的な緊張

低レベルなソフトウェアは常に安全性のために重いランタイムチェックや常時メモリ走査を「払う」余裕があるわけではありません。目標は共有作業場の道具を借りるようなもので、誰が握っているか、誰が共有できるか、いつ返すべきかが明確であることです。従来のシステム言語はそのルールを人間の規律に委ねてきました。Rust の起源譚はそのトレードオフを問い直すことから始まります。

「ガベージコレクタなしのメモリ安全」が大きな意味を持った理由

ガベージコレクション（GC）はメモリバグを防ぐ一般的な方法です。ランタイムが到達可能なオブジェクトを追跡して、残りを自動的に回収することで、use-after-free、double-free、多くのリークを排除できます。

システム寄りコードにおける GC のトレードオフ

GC は「悪い」と言っているわけではありませんが、プログラムの性能プロファイルを変えます。大抵のコレクタは次のような要素を導入します：

• 一時停止時間（小さくても断続的に現れ、スタッタ（引っかかり）として現れることがある）
• ランタイムオーバーヘッド（割当ての追跡や到達性の管理のコスト）
• 予測しにくいレイテンシ（回収がランタイムの判断で行われるため）

多くのアプリケーションではこれらのコストは許容できます。現代の GC は優秀で、開発者生産性を大きく向上させます。

予測可能性が重要な場面

システムプログラミングでは最悪ケースが重要になることが多いです。ブラウザエンジンは滑らかなレンダリングを必要とし、組み込みコントローラは厳格なタイミング制約を持ち、低レイテンシサーバは負荷下でテールレイテンシを抑える必要があります。こうした環境では「通常は速い」より「一貫して予測可能である」ことが重要です。

Rust の主張：制御と安全を両立

Rust の大きな約束はこうです：C/C++ に近いメモリやレイアウトの制御を保ちながら、ガベージコレクタに頼らずメモリ安全性を提供する。

これは GC が劣ると言っているわけではなく、低レベルの制御と現代的な安全保証の両方が必要な大きな中間地帯が存在すると賭けた形です。

所有権：Rust の安全性の核となるアイデア

所有権は Rust のもっとも単純で大きなアイデアです：各値には、使わなくなったときに片づける責任を持つ単一の所有者がいる。

この一つのルールは、C や C++ の開発者が頭の中で追いかける「誰がこのメモリを解放するか」という面倒な bookkeeping の多くを置き換えます。規律に頼る代わりに、Rust はクリーンアップを予測可能にします。

ムーブとコピー（平易な言葉で）

何かを コピー すると二つの独立したバージョンが残ります。何かを ムーブ すると元の所有権が渡され、元の変数はもうそれを使えなくなります。

Rust は文字列やバッファ、ベクタのような多くのヒープ上の値を既定で ムーブ として扱います。単純にコピーすると高コストであるだけでなく、二つの変数が同じ割当てを「所有している」と誤解する原因になります。

以下は簡単な疑似コードのアイデアです（コードブロックは変更しません）：

buffer = make_buffer()
ownerA = buffer      // ownerA owns it
ownerB = ownerA      // move ownership to ownerB
use(ownerA)          // not allowed: ownerA no longer owns anything
use(ownerB)          // ok
// when ownerB ends, buffer is cleaned up automatically

得られる効果：GC なしでの自動的な管理

所有者が常に一つであるため、Rust は値のクリーンアップのタイミングを正確に知っています：所有者がスコープを抜けたときです。つまり、free() を至る所で呼ぶ必要はありますが、ランタイムが周期的に走査して回収するガベージコレクタも不要です。

実務上で防げること

この所有権ルールは次のような古典的問題の多くを防ぎます：

• 二重解放（二つの「所有者」が同じメモリを解放しようとする）
• 解放後使用（メモリが既に解放されているのに使い続ける）

所有権モデルは安全な習慣を促すだけでなく、多くの「危険な状態」を表現できないようにしてしまう点が、Rust の安全機能の基盤です。

借用、ライフタイム、借用チェッカ

所有権は誰が値を「所有」するかを説明します。借用はプログラムの他の部分がその値を 一時的に 使う方法を説明します。

借用：所有権なしでのアクセス

借用すると参照を得ます。元の所有者がメモリを解放する責任を持ち続け、借用側は一時的に使う許可だけを得ます。

Rust には二種類の借用があります：

• 共有借用（&T）：読み取り専用アクセス。
• 可変借用（&mut T）：読み書きアクセス。

重要なルール：多くの読み取り者か一人の書き手か

Rust の中心的な借用ルールは簡単に言えますが強力です：

• 同時に 多くの共有参照 を持てる、または
• 一つの可変参照 を持てる、
• しかし 同時に両方は許されない。

このルールは、プログラムのある部分がデータを読み取っている間に別の部分がその下でそれを変更してしまう、というよくあるバグを防ぎます。

ライフタイム：この参照はいつまで有効か？

参照は、それが指すデータより長く生きてはいけません。Rust はその期間を ライフタイム と呼びます。

厳密な形式知識がなくても使えます：参照が所有者より長く残ってはいけない、という直感です。

借用チェッカ：プログラム実行前の安全性

Rust はこれらのルールを 借用チェッカ によりコンパイル時に強制します。危険な参照やリスクのある変更がテストで見つかることを願う代わりに、Rust はメモリを誤用する可能性のあるコードのビルドを拒否します。

分かりやすい例え

共有ドキュメントを想像してください：

• 複数人が 閲覧 しているのは共有借用のように安全です（誰も編集しない）。
• 一人が 編集 しているのは可変借用のように安全です（真の単一の情報源がある）。
• 誰かが編集している間に他の人が読んでしまうと半端な変更を見てしまうリスクがあります—Rust はその状況を設計上防ぎます。

並行性の安全性：データレースを設計で防ぐ

並行性は「自分のマシンでは動く」バグが隠れる場所です。二つのスレッドが同時に動くと驚くべき相互作用が起き得ます—特にデータを共有するときに。

データレースとは何か（危険な理由）

データレース は次のときに起きます：

• 二つ以上のスレッドが同じメモリに同時アクセスし、
• 少なくとも一方が書き込みであり、
• 調停（ロックなど）がない。

結果は単に「間違った出力」ではありません。状態の破壊、クラッシュ、セキュリティ脆弱性を生み、しかも断続的にしか現れないことがあります。

Rust の賭け：危険なことをデフォルトで難しくする

Rust は珍しい立場を取ります：毎回全員がルールを覚えていると信頼する代わりに、多くの危険な並行パターンを安全なコードでは表現しにくくすることを目指します。

所有権と借用のルールは単一スレッドに留まらず、どのようにスレッド間で共有できるかを形作ります。コンパイラが共有アクセスが適切に調停されていることを証明できないなら、コードはコンパイルできません。

これが Rust における 安全な並行性 の意味です：並行プログラムは書けますが、「あっ、二つのスレッドが同じものを書いた」というカテゴリのミスは実行前に捕まります。

例：二つのスレッドが同じデータを更新する

二つのスレッドが同じカウンタをインクリメントする場面を想像してください：

• 多くの言語では共有参照やポインタを両方のスレッドに渡してしまいます。両方が同時に書き込むと更新が失われたり状態が壊れたりします。

Rust では安全なコードで単に可変アクセスを複数のスレッドに渡すことはできません。意図を明示する必要があり、通常はロックの背後に共有状態を置くかメッセージパッシングを使うように強制されます。

低レベルの制御は残る—明確に区切られて

Rust は低レベルの並行トリックを禁じてはいません。代わりにそれらを隔離します。コンパイラが一般的に検証できないことが必要な場合は unsafe ブロックを使えます。unsafe は「ここは人間の注意が必要だ」という警告ラベルのように機能します。大部分のコードベースは安全な部分に保たれ、必要な箇所だけ手動で扱えます。

Rust が線を引く場所：safe と unsafe の境界

Rust の安全性の評判は絶対的に安全であるように聞こえますが、より正確には Rust は安全でない領域と安全な領域の境界を明示し、監査しやすくしている、ということです。

Safe Rust：デフォルト

ほとんどの Rust コードは「safe Rust」です。ここではコンパイラが use-after-free、double free、ダングリングポインタ、データレースといったメモリ安全の問題を防ぐルールを強制します。ロジックの誤りは書けますが、通常の言語機能で誤ってメモリ安全を侵すことはできません。

重要な点：safe Rust は「遅い Rust」ではありません。コンパイラがルールが守られることを信頼できれば積極的に最適化できるため、高性能なプログラムの多くは完全に safe Rust で書かれています。

Unsafe Rust：明示的な脱出口

unsafe はコンパイラが一般的に安全と証明できない操作を許します。典型的な理由は：

• FFI（外国関数インタフェース）：C/C++ ライブラリの呼び出しやそこから呼ばれること。
• 低レベル操作：ハードウェア、メモリマップド I/O、OS API との直接やり取り。
• 性能クリティカルな特殊ケース：データ構造やアロケータ、同期プリミティブを実装する際に不変条件を手動で保証する必要がある場面。

unsafe を使ってもすべてのチェックが消えるわけではなく、例えば生ポインタの参照解除など通常は禁止されている少数の操作が可能になる、という意味です。

境界は封じ込められる

Rust は unsafe ブロックや unsafe 関数を明示的にマークするため、コードレビューでリスクが可視化されます。一般的なパターンは小さな「unsafe コア」を安全な API で包み、プログラムのほとんどは safe Rust に保つことです。

実務上の指針

unsafe は電動工具のように扱うべきです：

• unsafe ブロックは 小さく局所化 する。
• 安全性仮定を明確にする コメント を残す。
• unsafe 変更は追加の レビュー を要求する。
• エッジケースのストレステストなど テスト を追加する。

適切に扱えば、unsafe Rust はシステムプログラミングでまだ必要な手動の正確さへの制御されたインターフェースになり、コードベースの他の部分の安全利点を損ないません。

Mozilla、Servo、実験からエコシステムへの移行

Rust が「現実のもの」になったのは、アイデアが紙上で優れていたからではなく、Mozilla が実際にそのアイデアを試す土壌を与えたからです。

なぜ Mozilla が関心を持ったか

Mozilla Research は、パフォーマンスが重要でかつセキュリティバグが多いブラウザの重要部分をより少ない脆弱性で作る方法を探していました。ブラウザエンジンは未検証の入力を解析し、大量のメモリを管理し、高度に並列な作業を実行するため、メモリ安全の欠陥と競合状態が特に頻繁で高コストです。

Rust を支援することは、システム性能を保ちながら特定の脆弱性クラスを減らすという目標に合致しました。Mozilla の関与は、Rust が Graydon Hoare の個人的な実験で終わらず、世界で最も難しいコードベースの一つで試され得る言語であることを示しました。

Servo：デモ以上の検証場

実験的ブラウザエンジンである Servo は、Rust を大規模に試す場になりました。狙いはブラウザ市場で「勝つ」ことではなく、言語機能、コンパイラ診断、ツールチェーンを実際の制約（ビルド時間、クロスプラットフォーム、開発者体験、並列性下での性能・正確性）に晒して評価することでした。

Servo はまた、ライブラリ、ビルドツール、慣習、デバッグ実務といった、トイプログラムを超えた言語周辺のエコシステム形成に寄与しました。

フィードバックループが Rust を成熟させた

実プロジェクトは言語設計が偽装できないフィードバックループを作ります。エンジニアが摩擦（分かりにくいエラーメッセージ、欠けているライブラリ、扱いにくいパターン）に直面すると、その痛点は早く現れます。時間と共に、こうした圧力が Rust を有望な概念から大規模な性能批判的ソフトウェアに耐えうる言語へと成熟させました。

このフェーズ以降の Rust の進化を追いたければ、/blog/rust-memory-safety-without-gc を参照してください。

Rust と C、C++、GC 言語との比較

Rust は中間地帯に位置します：C/C++ が提供する性能と制御を目指しつつ、これらの言語が人の規律や運に任せている多くのバグを取り除こうとします。

Rust と C/C++：手動メモリ管理と検証されたルール

C/C++ では開発者がメモリを直接管理し、割当て、解放、ポインタの有効性を保証します。その自由度は強力ですが、use-after-free、double-free、バッファオーバーフロー、微妙なライフタイムバグを生みやすいです。コンパイラは一般に開発者を信用します。

Rust はこの関係を逆転させます。スタックとヒープの選択、明示的な所有権移動などの低レベル制御は残しつつも、コンパイラが値の所有者や参照がどれだけ生きるかのルールを強制します。「ポインタに気をつけろ」ではなく「コンパイラに安全性を証明しろ」と言い、safe Rust ではこれらの保証を破るようなコードはコンパイルできません。

Rust と GC 言語：予測可能性と制御 vs 便利さ

Java、Go、C# などのガベージコレクトされる言語は手動管理を放棄する代わりに利便性を提供します。オブジェクトは到達不能になったときに自動で解放され、生産性が大幅に向上します。

Rust の約束は「ガベージコレクタなしのメモリ安全性」であり、ランタイム GC によるコストを払わずに安全性を実現します。これによりレイテンシ、メモリフットプリント、起動時間、制約のある環境での制御性が保たれます。代償は所有権を明示的にモデル化し、コンパイラにそれを強制させる学習が必要になることです。

学習曲線（そしてその理由）

Rust は最初は難しく感じられるかもしれません。新しい思考モデル（所有権、借用、ライフタイム）を学ぶ必要があり、単にポインタを渡すだけではない考え方に慣れるまで摩擦があります。特に共有状態や複雑なオブジェクトグラフのモデリングで初期の壁が現れます。

誰に向いているか

Rust はセキュリティや性能が重要なソフトウェア（ブラウザ、ネットワーク、暗号、組み込み、厳密な信頼性を要するバックエンド）で光ります。反対に、最速の反復を優先し低レベル制御をあまり必要としない開発には GC 言語の方が向く場合もあります。

Rust は普遍的な代替ではありませんが、C/C++ クラスの性能と頼れる安全性を求める場面で強い選択肢です。

Rust がシステムプログラミングの期待を変えた理由

Rust は「より親切な C++」として注目されたわけではありません。低レベルコードが速く、メモリ安全で、費用（コスト）を明示することが同時に可能だと主張した点で話を変えました。

安全性＋速度＋明示性を同時に

以前はチームは性能のためにメモリバグをある種の税として受け入れ、テストやレビュー、事後対応でリスクを管理していました。Rust は異なる賭けをしました：データの所有者、誰が変更できるか、参照はいつ有効かといった共通ルールを言語に組み込み、特定のバグのカテゴリをコンパイル時に拒否するのです。

この転換が意味するのは、開発者に「完璧であれ」と要求するのではなく「明確であれ」と要求し、その明確さをコンパイラに強制させる点です。

業界のシグナル（慎重に）

Rust の影響は単一の大見出しではなく複数のシグナルに表れます：性能敏感なソフトウェアを出荷する企業の関心増加、大学課程での存在感の増大、パッケージ管理や整形、Lint、ドキュメンテーションのワークフローなど、日常的に使えるツール群の充実です。

これが意味するのは、Rust が常に最良の選択というわけではないにしても、安全性をデフォルトにする考えが現実的な期待になった、ということです。

Rust が検討される典型的な用途

Rust はしばしば次の用途で評価されます：

• 高速でポータブル、信頼性の高い CLI
• 予測可能な性能とメモリ関連インシデントの削減が重要なバックエンドサービス
• ガベージコレクタが望ましくない組み込み環境
• バイナリの性能と制御が重要な WebAssembly ターゲット

「新しい標準」が意味すること

「新しい標準」はすべてのシステムが Rust に書き換えられるという意味ではありません。意味するのは基準が上がったということです：チームは「なぜメモリ安全でない既定を受け入れるのか？」と問い始めるようになりました。Rust を採用しない場合でも、そのモデルはより安全な API、明確な不変条件、正確さのためのより良いツール作りを促しました。

さらに同様のエンジニアリングの舞台裏が読みたいなら /blog を参照してください。

主要な要点と学びを進めるために

Rust の起源譚は単純な結び目を持ちます：ある人物のサイドプロジェクト（Graydon Hoare の言語実験）が頑固なシステムプログラミングの問題に直面し、その解決が厳格で実用的であることが分かった。

覚えておくべき大きなアイデア

Rust は多くの開発者が避けられないと考えていたトレードオフを再定義しました：

• ランタイムの GC に依存せずに強力なメモリ安全性 を得られる。
• システムレベルの制御と性能目標を保ちながら、コンパイラに守らせることで ヒューマンエラーを減らせる。

実務上の変化は「Rust がより安全だ」ということだけでなく、安全が言語のデフォルト特性であり得ると証明した点です。

次に何をすべきか（過度にコミットしないために）

興味があるなら大規模な書き換えは不要です。まずは Rust の感触を掴むために小さく始めましょう：

• 所有権と借用 の基礎を学んで、Rust コードが読めるようになる。
• 他の言語でミスが起きやすい小さなプロジェクト（CLI、単純なパーサ、簡単なネットワーキングクライアント）を作る。
• その後、フィット感を評価する：性能重視、セキュリティ重視、並行処理重視のコードなら Rust の制約がすぐに利点をもたらすかもしれません。

穏やかな入り口としては「ファイルを読み、変換して出力する」といった薄いスライス目標を選び、巧妙さより明快さを重視してコードを書くと良いでしょう。

プロダクトの一部を Rust でプロトタイプするなら、周辺は素早く開発して（管理 UI、ダッシュボード、コントロールプレーン、単純な API など）、コアシステムロジックだけを厳格に保つと統合が楽になります。Koder.ai のようなプラットフォームはチャット駆動のワークフローでそのような『グルー』開発を加速でき、React フロントエンド、Go バックエンド、PostgreSQL スキーマを生成して Rust サービスとクリーンな境界で統合する手助けになります。

短い読書／視聴リスト

• The Rust Programming Language（“the Rust Book”）：/book/
• Rust by Example：/rust-by-example/
• 主要な講演／インタビュー：Graydon Hoare Rust talk や Rust ownership borrow checker explanation を検索すると一次情報や分かりやすい解説が見つかります。

フォローアップのための問い

次の記事で何が最も役に立つでしょうか？

• 借用チェッカを平易に説明し、実際のエラーと修正を示す記事
• 実プロジェクトで unsafe がどのように責任を持って使われているか
• C/C++ チームが単一コンポーネントに Rust を検討する際の比較ガイド

あなたの状況（何を作っているか、今何の言語を使っているか、何を最適化したいか）を教えていただければ、次のセクションをそれに合わせて用意します。