【#も読】Rustの実践的な採用事例をながめる（@yusuktan）

「あの人も読んでる」略して「も読」。さまざまな寄稿者が最近気になった情報や話題をシェアする企画です。他のテックな人たちがどんな情報を追っているのか、ちょっと覗いてみませんか？

みなさんこんにちは。

「あの人も読んでる」、第7回目の投稿です。maguro (X @yusuktan)がお届けします。

今回のテーマ: Rustの実践的な採用事例をながめる

近年Rustの普及が進んでいますが、ここ数週間でさらに興味深い採用事例がいくつか公開されたため、紹介していきます。大企業が主導するオープンソースプロジェクトから、クラウドインフラ、そして言語選択の背景に至るまで、Rustがどのように評価され、採用されているのかを見ていきましょう。

OpenAI Codex CLIのRust移行：ゼロ依存とネイティブセキュリティ

最初に紹介するのは、OpenAI CodexのCLIツールがTypeScriptからRustへ移行しているという話です。

なぜRustへ移行するのか

例えば、競合ツールであるClaude CodeはJavaScript(TypeScript)で書かれています。TypeScriptおよびnpmのエコシステムは強力で、さらに今のAI時代においては「AIが書くのが得意な言語」の筆頭であるとよく言われています。どうしてわざわざRustに移行するという決断をしたのでしょうか？

Codex CLIチームによると、以下のポイントが挙げられています。

1. ゼロ依存インストール - Node.jsに依存しないインストール
2. ネイティブセキュリティバインディング - プラットフォーム固有のセキュリティ機能への直接アクセス
3. 最適化されたパフォーマンス - ガベージコレクションなし、メモリ利用の効率化
4. 拡張性の向上 - TS/JS, Pythonなどによるユーザー側でのエージェント機能拡張をサポートするプロトコル

サンドボックス

この中で特に面白いと思ったのは、2のネイティブセキュリティバインディングによるサンドボックス機能の実装です。過去の「も読」でも触れた通り、今の大AI時代において、自律的に動くAIに対して多すぎるパーミッションを与えてしまうことは、潜在的なセキュリティリスクをはらんでいます。このリスクへの対策として、Codex CLIチームでは、Linuxではlandlock、macOSではseatbeltというOS組み込みの機構を活用していくという方針のようです。これにより、AIが行う各操作に対して、権限のコントロールが可能になります。

執筆時点（2025/06/08）でのopenai/codexの最新コミット（b73426c）では、以下のようにRustの SandboxPermission というenumが定義されており、ファイルシステムの読み取りと書き込み、およびネットワークアクセスについていくつかの制御ができることが推測できます。

pub enum SandboxPermission {
    DiskFullReadAccess,
    DiskWritePlatformUserTempFolder,
    DiskWritePlatformGlobalTempFolder,
    DiskWriteCwd,
    DiskWriteFolder { folder: PathBuf },
    DiskFullWriteAccess,
    NetworkFullAccess,
}

個人的には、macOSのseatbeltという仕組みについては、syumaiさんのmacOSのApple Seatbelt (sandbox-exec) について調べた - 焼売飯店で知りました。しかし、Linuxでも同様の仕組みとしてlandlockというものが存在するということを知らなかったです。2021年6月リリースのLinux 5.13で追加されたということで、比較的新しめの機能のようです。

Landlock: unprivileged access control

AWS Aurora DSQLの10倍性能向上：JVMからRustへの転換

次に紹介するのは、AWSのAurora DSQLがRust採用で劇的な性能向上を達成した事例です。

スケーラブルな分散データベースを実現するにあたり、当初Kotlinで実装されていたコンポーネントが大きな性能上のボトルネックとなっていました。あるトランザクションが複数コンポーネントにまたがった読み取りをする必要があるときに、「どこかのコンポーネントでGCによる一時停止が発生してしまう」確率がほぼ100%になってしまい、レイテンシが著しく悪化してしまったようです。

そこで開発チームは、GCオーバーヘッドのない予測可能なパフォーマンス、制御を犠牲にしないメモリ安全性、ゼロコスト抽象化を実現するRustに白羽の矢を立てました。まずはシンプルなコンポーネントをRust実装に切り替えたところ、開発者はRustを初めて使用したにもかかわらず、結果として得られたコードは、注意深くチューニングされたKotlin実装と比較して10倍高速になったとのこと。そこからは全体をRust実装に切り替えるという決定がなされ、最終的にはスループットの改善とレイテンシの安定化が達成されました。

ボトルネックの特定と、それを解決するための適切な技術選定。そして、小さめのコンポーネントから徐々に置き換えることによって、段階的に効果を測定しつつ、チーム内の習熟度も高めながら進められる、という点が、「新しい技術に舵を切る際の実践的な進め方」を示唆しているように思いました。

Microsoft Editエディタ：言語選択の背景

最後は、Microsoftが最近公開したRust製の小さなテキストエディタ、editについてです。

https://github.com/microsoft/edit

開発言語にRustが使われているということで個人的に注目していましたが、Hacker Newsで開発者のlheckerさんが言語選定の背景について触れていたので、その内容を紹介したいと思います。

https://news.ycombinator.com/item?id=44031529

lheckerさんはプロトタイプをC、C++、Zig、Rustで実装し、Zig > C > Rust > C++ の順で気に入ったと話しています。ではなぜZigやCを使わなかったのか？まずZigについては、Microsoft社内でまだサポートがされていないことが要因だったようです。次点のCは、しばらく書いてみたものの、Zigを書いたあとだとCが苦痛に感じられて断念。最終的に、Microsoft社内でのサポートもあり、かつ言語としてそれほど悪いわけでもなかったということでRustに行き着いたそうです。

Rustの不満点としては以下を挙げています。

• アロケータサポートが弱い（注: Zigはアロケータに関して非常に強力な柔軟性を持っているので、それとの比較だと思われます）
• 木構造を作るのが難しい
• Linked Listにおけるカーソル操作が安定版のRustではまだ利用できない

Zigに魅力を感じながらも、さまざまな事情で採用できなかった、というのは興味深いところです。言語選択は技術的優位性だけでは決まらず、組織のサポート、チームのスキル、長期的なメンテナンス性など、様々な要因を考慮しなければなりません。

おわりに

今回はRustの実践的な採用事例を3つ紹介しました。

OpenAI Codex CLIのゼロ依存とネイティブセキュリティ、AWS Aurora DSQLの劇的な性能向上、そしてMicrosoft Editの現実的な言語選択。Rustが具体的な課題を解決するための実用的な選択肢として評価されているということが読み取れます。

Rustの採用を検討している方にとって、これらの事例が参考になれば幸いです。

また次回、おすすめコンテンツを紹介していきます。お楽しみに！

maguroさんの「も読」過去記事

• DockerなどのコンテナにおけるSIGTERMの取り扱い(5月30日公開)
• ライブコーディング視聴のすすめ(5月19日公開)
• 生成AIを使うか、使われるか - 学習を加速するための活用(5月8日公開)
• Rustの学習の難しさと取るべきルート(4月17日公開)
• MCPことはじめ / MCPサーバーのセキュリティリスク(4月4日公開)
• n月刊ラムダノート、実用Raft(3月21日公開)