ガベージコレクションは、プログラムがメモリを自動的に管理するプロセスだ。メモリ安全性を確保するための一般的な手法であり、「Java」「Python」「JavaScript」「Go」はいずれもこの仕組みを採用している。しかし、処理性能やメモリ使用量の大幅なオーバーヘッドを引き起こす可能性がある。

　このため、メモリ安全性と低レベルのシステム制御を両立するという特徴から、性能要件が厳しいシステムでもRustの人気が高まっている。

　コーネル大学（Cornell University）のコンピュータサイエンス学部で教授を務めるエイドリアン・サンプソン氏は次のように述べる。「どちらか一方を満たす言語は数あるが、両方を実現するのは実質的にRustだけだ。Rustの他の要素が気に入らなくても、これだけで採用する理由になる」

　サンプソン氏によれば、メモリ安全性のバグは「極めて厄介で危険な種類のバグ」だ。例えばMicrosoftの過去の調査では、自社ソフトウェアで報告されたセキュリティ関連バグのうち約3分の2がメモリ安全性の問題だったという。

　Microsoftは2026年9月、Rustを社内開発で最優先で予算やサポートを割り当てる公式標準言語「Tier 1言語」に指定した。

　開発者向けQ＆Aサイト「Stack Overflow」の年次の開発者調査でも、Rustは「最も称賛される言語」に選ばれている。プログラマーの間では「Rustで書き直せ」（Rewrite it in Rust：RIIR）という決まり文句が定着した。2024年2月にバイデン政権が発表した報告書では、より安全な重要ソフトウェアを構築するためにRustへ移行する正当性が示されている。2027年4月リリース予定の「Git」バージョン3.0では、ソースコードのビルドにRustが必須の依存関係として指定されることが正式に決定している。

　メールサービス「HEY」の開発元であるソフトウェアベンダー37signalsは、AIエージェントを活用してHEYのバックエンドの一部をRustで書き換えた。同社の共同所有者兼CTO（最高技術責任者）であるデービッド・ハイネマイヤー・ハンソン氏は、2026年9月に開催された開発者向けカンファレンス「Rails World」の基調講演で、Rustについて「人間に書かせるにはあまりにもひどいプログラミング言語だ」と語った。

　その一方で、ハンソン氏はRustの性能面での利点と、コーディングを担うAIエージェントの能力を称賛し、「私が指示を出して、AIエージェントにRustでプログラムを書かせればよい」と話す。同氏によると、書き換え後のHEYのバックエンドは、以前の実装と比べてCPU使用率を99％、メモリ使用量を95％削減できたという。

AIがRustへの書き換えを容易にする

　問題は、Rustの学習曲線の険しさから、アプリケーションの書き換えが困難になり得ることだ。そのため、一部の開発チームはAIツールに単調なコーディング作業を任せ、Rustの利点を享受しようとしている。

　2026年5月から9月にかけて、Google、GitHubなどの企業は自社のアプリケーションをRustに書き換えるプロジェクトに着手した。移行を果たした企業の一部は、本来なら手間のかかる手動での書き換え作業を、AIツールが楽にしてくれたと評価した。

　セキュリティベンダーAmutableで最高製品責任者を務めるデービッド・ストラウス氏は、かつてRustへの移行価値に疑問を抱いていたという。特に既存システムの書き換えにおいては、「労力に見合うほどの価値はない」と考えていた。

　「AI技術の進化に伴って、私はRustの熱心な支持者になった。かつての課題は『この言語で十分な生産性を発揮できるか』だった。しかし最先端のAIモデルを搭載したツールにソースコードを書かせれば、他の言語と比べてRustの作業負担はわずかで済む」とストラウス氏は語る。

　ストラウス氏によると、Amutableが開発するソフトウェアの大半はGoまたはRustで書かれている。同社はセキュリティ関連のソフトウェアに注力しており、どちらもメモリ安全な言語だからだ。「実用上の理由からRustが適さない場面もある。しかし、クラウドサービス向けのソフトウェアを開発するなら、現時点ではメモリ安全な言語を使うべきだ」（同氏）

AIを使ってもRust移行の課題は消えない

　エネルギー貯蔵・管理の分野でセキュリティツールを提供するTorusのファームウェアエンジニア、ロヒニ・ラメゴウダ氏は、「言語の得意分野と限界を正確に把握することが重要だ」と指摘する。

　ラメゴウダ氏は以前、家電メーカーで電子機器制御用のマイクロコントローラーの変更に伴い、本番稼働用ファームウェアをCからRustへ移行する作業に携わった。この書き換えはAIコーディングツールが普及する前に進められたが、同氏は移行作業の一部、とりわけアプリケーション層の書き換えでAIツールが役立ったはずだと振り返る。

　「AIツールは単純なコード変換が得意だ。しかし、アーキテクチャの問題は解決できない。システムを理解しているエンジニアが依然として必要だ」（ラメゴウダ氏）

　AI主導の移行は、システムの要件に合致しない「膨大なコードレビューの山」を生み出す恐れがある。「ソースコードの生成は速くなるが、検証作業は速くならない」とラメゴウダ氏はくぎを刺す。

　Rust自体が全ての問題を解決したわけでもない。メモリバグやスタックオーバーフロー（メモリ領域を使い果たしてプログラムが異常終了するエラー）は解消されたが、システムレベルの課題は残ったままだ。

　書き換え作業中、ラメゴウダ氏のチームはCベースのアーキテクチャから、システム機能と製品固有の機能を分離するRustベースのアーキテクチャへと移行した。これにはコードベースの整理と再構築が必要であり、アーキテクチャ上の課題だった。

　処理にかかる時間や結果が常に予測可能である「決定性」（Determinism）もRustが完全には解決できなかった問題の一つだ。ラメゴウダ氏によれば、「メモリ安全であっても、期限を超過したタスクは失敗と見なされる」ためだ。

　コンプライアンス監査人にとってRustはなじみが薄かったことも問題だ。「安全性の確保には認定されたツール群（ツールチェーン）が必要だが、Rustが監査を通過してきた実績や歴史はCのものと比べてはるかに浅い。そのため、実際に安全性が向上しても、監査の通過からは遠ざかる可能性がある」（ラメゴウダ氏）

　ストラウス氏によれば、Rustのツールチェーンを利用できる環境が限られていることも、さまざまなシステム構成で動作するソフトウェアへの導入を複雑にする要因だ。同氏は「Linux」のシステム起動やサービスを管理する基本プログラム「systemd」プロジェクトの共同メンテナーを務める。「systemdの一部にRustを使用することを検討した際、systemdが動作する組み込み機器では、Rustのツールチェーンを完全には利用できない場合があることを考慮しなければならなかった」と同氏は振り返る。Linuxカーネルについても同様だった。「Rustのツールチェーンが完全にそろっていない環境で動作させる必要があるか、あるいはそこで動作させるために必要なツールを自ら作成しなければならない」

　AIツールはCからRustへの書き換えを容易にする見込みはあるが、それによって書き換えたアプリケーションは企業のハードウェアやシステム構成で動作しなければならない。ラメゴウダ氏によると、互換性の問題を回避するために、複数の言語が混在するシステム内でセキュリティ問題を引き起こしかねないソースコードをあえて使用せざるを得ない場合がある。

　「他言語との相互運用の問題は避けられない」とラメゴウダ氏は考える。ベンダーが提供するCのSDK（ソフトウェア開発キット）を、Rust内で例外的に安全チェックを無効にする「unsafe」ブロックで囲むといった処理が必要になる。これによって、ソースコード内の安全性は保証されるが、その保証は外部ソースコードとの境界までにしか及ばない。「そこから先は、中身を確認できないブラックボックス化されたコードが動いている領域だ」（ラメゴウダ氏）

　AIセキュリティソフトウェアベンダーTrent AIでアドバイザーを務めるニール・カーペンター氏は、Rustを導入したからといって、メモリ関連以外の重大なセキュリティ脆弱性に対処できるわけではないと指摘する。

　「Rustは不適切な認証やデータベースへのアクセス認可を修正したり、他の種類のセキュリティ脆弱性を直したりはしない」とカーペンター氏は語る。開発者が犯すミスのうち、Rustが排除してくれるほんの一部の問題と同等か、それ以上に深刻な人的ミスは依然として数多く存在する。セキュリティ対策に長けていなければ、そうしたミスを犯し続けることになる」