安全性最優先のシステムにRustが選ばれる理由 Rustプロジェクト調査：「Rustの要件定義や保守へのコミットメントが不可欠」と指摘

プログラミング言語の「Rust」はセーフティクリティカルな分野で導入が進んでいる。コンパイラによるチェックが開発効率を向上させる一方で、課題も指摘されている。

[＠IT]

　プログラミング言語「Rust」を開発するRustプロジェクトは2026年1月14日（米国時間）、セーフティクリティカル（安全性が最優先される）ソフトウェア分野におけるRustの現状を調査した結果を発表した。

　セーフティクリティカルなソフトウェアとは、誤作動が負傷、生命の損失、または環境破壊につながる可能性のあるソフトウェアを指す。各分野には、自動車向けの「ISO 26262」、産業向けの「IEC 61508」、医療機器向けの「IEC 62304」、航空宇宙向けの「DO-178C」といった開発プロセスや安全性の要件を定めた標準規格が存在する。

　これらの規格は、完全性レベル（インテグリティ・レベル）の段階が定義されている。レベルが上がるにつれて、開発プロセス、検証、証拠に対する要求が高まり、コストも増加する。このため、コストのかかる厳格な検証が必要なロジックを最小限の範囲に切り出し、残りの大部分を比較的規制の緩いレベルにとどめることで、開発の効率化を図る手法が一般的となっている。

　Rustプロジェクトは自動車、産業機器、航空宇宙、医療などの分野における主要装備品メーカー（OEM）、インテグレーター、サプライヤーのエンジニアを対象にインタビュー調査を実施し、Rustの利用状況およびRustのメリットや課題を次のように解説している。

セーフティクリティカルな環境でRustはどう活用されているのか

　Rustは単なる評価段階ではなく、既に規制の厳しい環境で本番導入されている。

　IEC 61508 SIL 2認定を受けたモバイルロボティクスシステムの主任ファームウェアエンジニアは、「過去にはC言語を使用し、サードパーティーのスタック分析やユニットテストツールを利用していたが、品質は十分ではなかった。Rustの導入により、スタック分析でチェックすべき事項の90％をコンパイラが実行できるようになった」と述べている。

　集中治療室（ICU）向けのIEC 62304クラスBソフトウェアを導入している医療機器企業のエンジニアは「製品コードの全てをRustでデプロイしている」と報告した。この企業ではPythonで書かれたコンポーネントをRustに変更したことで、処理速度が100倍向上した事例もあるという。

セーフティクリティカルな環境でのRustの利点と課題

クレート

　安全上の重要度が比較的低い領域では、Rustのクレート（ライブラリ）を活用して迅速に開発を進めるアプローチが採られている。だが、安全上の重要度が高い領域において「サードパーティーの依存関係の正当性を示すことが困難になる」という声がある。

　自動車サプライヤーのチームリーダーは、将来の置き換えを簡素化するための抽象化レイヤーを構築したり、既存のクレートを再利用する場合でもAPIを変更してテストを増やしたりするなどの対策を挙げている。航空宇宙分野では「全てのコードを自社で所有し、1行ごとに制御する必要がある」という考え方がさらに強いという。

コンパイラ

　Rustの価値は、従来手動で行っていたコードレビュー作業をコンパイラが一部代替し、開発の早期段階でコードの問題点をチェックできる点にある。C言語で用いられる「MISRA C」（MISRA：Motor Industry Software Reliability Association）や「CERT C」（CERT Secure Coding Standards）といったコーディング標準では、プロセスベースで品質を保証していた項目の多くが、Rustでは言語仕様に組み込まれ、コンパイラが自動的にチェックする。

　大規模なコードベースや多様なスキルレベルのエンジニアを抱えるチームにとって、コンパイル時のチェックや、コンパイラに統合された静的解析ツール「Clippy」は極めて有用だという。エコシステム全体で統一されたエラー処理の方法も、製品寿命が15〜20年に及ぶプロジェクトにおいて、手動レビューよりスケールしやすいと評価されている。

安定性と最新性のバランス

　セーフティクリティカルな環境では保守的なツールチェーンの選択が一般的だが、古いツールチェーンには未修正あるいは残存しているバグがあるという矛盾も指摘されている。

　自動車プログラムで一般的なインクリメンタルな移行戦略において、Rustのエディションシステムは大きな利点となっている。一方、ツールチェーンを固定しても、多くのクレートが最新バージョン向けに実装されているため、クレート側のバージョン調整（ダウングレード）に時間がかかるという運用上の課題も報告された。

ターゲットティア

　Rustにはターゲットティア（CPUやOSなどの組み合わせに対するサポートレベル）ポリシーが存在するが、業界の規制を受けるチームにとっては、そのサポートレベルが維持されるかどうかが重要となる。特定のターゲットにおいて、コンパイラのアップグレードで依存関係が機能しなくなることは許容されないという。

非同期処理

　デーモンやミドルウェア、イベント駆動型アーキテクチャを採用するシステムでは、Rustの非同期処理が注目されている。

　一方、特定の技術に縛られる「エコシステムのロックイン」や、安全重要度が高いコンポーネントで非同期処理を使うための要件には不確実性が残っている。

　ISO 26262（自動車向けの機能安全規格）に照らすと、非同期処理を利用するには、その土台となるランタイム自体が、規格適合を証明する品質記録やプロセスの成果物（アーティファクト）を備えていなければならないためだ。

「業界主導によるRustの要件定義や保守が不可欠」と提言

　Rustプロジェクトは調査を通じて、セーフティクリティカル分野のコミュニティーに対し、自らのニーズをサポートできる仕組みを業界自ら構築することを推奨している。その成功例として挙げられているのが、「Ferrocene Language Specification」（FLS）だ。これはRustの公式コンパイラ「rustc」の安全認定に必要な仕様書を作成するため、業界の取り組みとしてスタートした。

　対照的に、同コンパイラにおける改良条件／判定カバレッジ（MC/DC〈Modified Condition/Decision Coverage〉）のサポート（機能拡張）は、企業の継続的な関与が不足したために停滞したいきさつがある。

　このためRustプロジェクトは「単なる技術的な実装だけでなく、業界側が要件定義や検証に深く関与し、長期的な保守にコミットする『責任の共有』が不可欠だ」と結論付けている。