家電や車などの機器の中で動く組込みソフトウェアの開発で、2023年以降、Rustというプログラミング言語を使う条件が整い始めました。この分野で長く標準だったのはC言語です。
故障しても危険を防ぐための規格（機能安全規格）の認定を受けた、Rustのコンパイラ（プログラムを機器で動く形に変換する道具）が登場しました。
機器を制御する小さなコンピューターであるマイコンのメーカーにも、公式にRustに対応する例が出ています。ただし対応するマイコンや認定の範囲はまだ限られ、どの製品でも使える段階ではありません。
この記事では、組込み開発でRustが使えるのかを、C言語との違い、採用が進む分野、マイコンとフレームワークの対応状況から見ていきます。続いて、機能安全との関係、導入の課題、向く場面・向かない場面の順で整理します。
内容は2026年10月1日時点で、各プロジェクト・企業の公式情報をもとにしています。
組込み開発でRustは使えるか
先に答えを書くと、Rustは組込み開発で使える段階に入っていますが、条件つきです。Arm Cortex-MやRISC-Vのマイコンで新しく書き起こすソフトウェアであれば、量産車のECU（電子制御ユニット）に採用した例がすでにあります。
反対に、使うマイコンにRustのコンパイラがない場合や、実績のある認証済みツール一式が必要な場合は、今もC言語のほうが現実的です。答えを分けるのは「どのマイコンか」「安全規格の要求があるか」「既存のC資産がどれだけあるか」の3点です。
まず、両者の違いを表で見ておきます。
性能面は近く、差が出るのは「誰がメモリの安全を確認するか」と周辺環境の厚みです。
※2026年10月1日時点。対応状況の根拠は本文と出典を参照してください。
なぜ今Rustが話題になるのか
背景にあるのは、メモリ安全性をめぐる政府機関の動きです。
2023年12月、米CISA（サイバーセキュリティ・インフラセキュリティ庁）やNSAなど5か国の機関が文書を公表しました。タイトルは「The Case for Memory Safe Roadmaps」です。
この文書は、メモリ安全性の脆弱性は公開された脆弱性のなかで最も多い種類だと指摘しています。
同じ文書は、MicrosoftのCVE（識別番号が付いた脆弱性）の約70％がメモリ安全性の問題だったという分析を引用しています。これは2006〜2018年のCVEを対象にした数字です。
ソフトウェアメーカーには、メモリ安全な言語へ移行する計画を作り、公表するよう求めました。
2024年2月には、ホワイトハウスの国家サイバー長官室（ONCD）も技術レポートを出し、メモリ安全な言語の採用を促しています。効果を示すデータとしてよく引かれるのがAndroidです。
Googleによると、Androidの脆弱性に占めるメモリ安全性の問題の割合は、2019年の76％から2024年には24％に下がりました。2025年には初めて20％を下回ったと報告されています。
ここで押さえておきたいのは、Googleが既存のC/C++コードを書き直したわけではない点です。新しく書くコードをRustなどのメモリ安全な言語に切り替え、古いコードは残したまま割合を下げました。
組込みの現場で移行を考えるときにも、この進め方は参考になります。
C言語との違い｜コンパイラが検査する範囲
RustとCの最も大きな違いは、メモリの扱いを誰が確認するかです。Cでは、確保したメモリをいつ解放するか、ポインタがまだ有効かどうかを、開発者が自分で管理します。
Rustでは、所有権（ownership）というルールをコンパイラが検査し、違反したコードはコンパイルが通りません。
メモリをいつ解放するかを、この3つのルールでコンパイラが決めます。
値を一時的に貸し出す「借用」にもルールがあり、書き換え可能な参照は同時に1つしか作れません。
これらの検査はコンパイル時に終わるため、公式ドキュメントは、所有権の機能が実行中のプログラムを遅くすることはないと説明しています。ガベージコレクション（不要になったメモリの自動回収）も持ちません。
実行時の余分な処理が少ないという点が、C言語と同じ土俵に立てる理由です。リソースの限られたマイコンでも、メモリ管理のためのランタイムを載せずに動かせます。
Cで起きやすいバグとの対応
Cの組込み開発で厄介なのは、解放済みメモリの参照、二重解放、配列の範囲外アクセス、割り込みとメイン処理の間のデータ競合といった不具合です。再現しにくく、実機評価の終盤や出荷後に見つかることもあります。
Rustでは、解放済みメモリの参照と二重解放は所有権のルールでコンパイル時に弾かれます。配列の範囲外アクセスは実行時に検出され、範囲外のメモリを読み書きする前にパニック（異常時の処理）に入ります。
並行処理についても、公式ドキュメントは、多くの誤りが実行時ではなくコンパイル時のエラーになると説明しています。
防げるのはメモリと並行性に関わる一部です。残るものを先に知っておく必要があります。
no_stdとunsafe
組込みでRustを使うときに最初に出てくるのが no_std です。OSのないベアメタル環境では標準ライブラリ（std）が使えません。そこで #![no_std] を指定し、OSに依存しないコアライブラリ（core）だけで書きます。
no_std では、ヒープ（動的メモリ確保）は別途アロケータを用意した場合にだけ使えます。標準ライブラリがmain関数の前に行う初期化処理（スタックオーバーフロー保護の設定など）も使えません。
The Embedded Rust Book は、ファームウェアやブートローダ、カーネルを書くのが no_std の用途だと整理しています。
もう1つが unsafe です。マイコンのレジスタは決まったアドレスへの読み書きで操作するため、コンパイラには安全かどうかを判断できません。
こうした処理は unsafe ブロックの中に書きます。公式ドキュメントも、ハードウェアは本質的に安全ではなく、unsafe がなければ低レベルの処理は書けないという趣旨を述べています。
実際の開発では、unsafe を直接書く場面は限られます。
レジスタを型として定義したPAC（Peripheral Access Crate）を使うためです。さらにその上で、GPIOやUARTを安全なAPIにまとめたHAL（Hardware Abstraction Layer）も使います。
アプリケーションは safe Rust で書き、unsafe は下の層に閉じ込めるのが一般的な構成です。
unsafe な処理は下の層にまとめ、上の層からは安全なAPIだけを使います。
※HALやPACを誰が提供しているか（メーカーか、コミュニティか）は、マイコンによって異なります。
Rustでも残るバグ
Rustで書けばバグが出なくなる、というわけではありません。仕様の読み違い、計算式の誤り、割り込みのタイミングといった論理的な不具合は、言語を変えても残ります。
unsafe でだけ使える操作（生ポインタの参照外しなど）は、安全かどうかをコンパイラが確認しません。Cのライブラリを呼び出すFFI（他言語の関数を呼ぶ仕組み）の境界も同じです。
unsafe ブロックの中でも借用の検査そのものは働きますが、これらの操作が正しいことは書いた人が保証する必要があります。
Googleは2025年11月の報告で、unsafe を含むRustのコードからバッファオーバーフローが1件見つかり、公開前に修正したと明かしています。
unsafe の範囲を小さく保ち、そこを重点的にレビューする運用が欠かせません。
パニックの扱いも設計事項です。no_std では、パニックが起きたときの動作を開発者がパニックハンドラとして定義します。停止するのか、リセットするのか、安全な状態に移すのかは、製品ごとに決めることになります。
採用が進む分野と現在地
Rustの採用は、OSやスマートフォンといった大規模ソフトウェアから始まり、車載や産業機器へ広がっています。2022年以降の主な出来事を並べると、流れがつかめます。
標準化、認定ツール、メーカーのサポートが、この4年でそろい始めました。
※各社・各団体の公式発表の年月。出典は記事末尾にまとめています。
AndroidとLinuxカーネル
Androidでは、プラットフォームのRustコードが約500万行に達しています（2025年11月時点）。
Googleは、中〜大規模の変更で比べた結果を報告しました。Rustの変更はC++より取り消し（ロールバック）になる割合が約4分の1で、コードレビューにかかる時間も約25％短い結果でした。
ファームウェアの分野でも、Armと共同でRustによる実装を進めているとしています。
Linuxカーネルには、2022年12月リリースの6.1でRustの基盤が入りました。2025年12月のメンテナサミットでは、カーネルのRustは「もはや実験ではない」という合意に達しています。
組込みLinuxを使う機器では、デバイスドライバをRustで書く選択肢が現実味を帯びてきました。
車載
自動車業界は、車両に載るソフトウェアの規模が増え続けており、メモリ安全性への関心が高い分野です。
Rust開発会社のTweede golfが2024年10月に公開したインタビュー記事に、Volvo Carsの事例があります。EX90とPolestar 3の電源管理を担う低電力プロセッサのECUで、ファームウェアをRustで開発しました。
同社のソフトウェアアーキテクトが語ったもので、マイコンはArm Cortex-Mです。
ただし、同じ記事によると、このECUは安全関連には分類されていません。安全規格の認証が絡まない領域から使い始めた例と見るのが正確です。
半導体メーカーでは、Infineonが2023年3月、車載向けのAURIXやTRAVEO T2GなどでRustをサポートすると発表しました。
2024年4月には、ツール会社のHighTecがAURIX向けに、ISO 26262のASIL Dに対応した認定済みRustコンパイラをリリースしています。
標準化の面では、AUTOSARが2022年4月にRustのサブグループを設けました。2023年11月のリリースでは、Adaptive Platform向けアプリケーションをRustで書くための説明文書を公開しています。
Rust Foundationは、2024年6月にSafety-Critical Rust Consortiumを立ち上げました。
Arm、Woven by Toyota、Ferrous Systems、HighTecなどが創設メンバーとして参加しています。
産業機器・医療機器
Rust公式ブログは、2026年1月に技術者へのインタビュー調査を公開しました。IEC 61508のSIL 2に対応した移動ロボットで、Rustが製品に使われている例が紹介されています。
IEC 62304のクラスBにあたる医療機器ソフトウェアの例もあります。
利用者側の統計もあります。
Rustの利用者を対象にした「2025 State of Rust Survey」は、2025年11〜12月に実施され、回答は7,156件でした。
「どのOS・実行環境向けにRustのソフトウェアを開発しているか」という複数回答の設問があります。OSなしの組込み（ベアメタル）を挙げた回答は18.4％でした。
前年の16.8％から増えています（数値はレポートのグラフによる）。
ただし、これはRustを使っている人のなかでの割合で、組込み業界全体の採用率ではありません。業界全体でどの程度使われているかを示す公的な統計は見当たらず、この数字だけで普及したとは判断できません。
マイコンとフレームワークの対応状況
組込みでRustが使えるかどうかは、最終的には使うマイコンで決まります。確認するのは、コンパイラが対応しているかと、周辺機能を動かすライブラリを誰が提供しているかの2点です。
マイコンの選定は電気・電子設計の担当者と決めることが多く、ハードウェアの選定段階で言語の選択肢が狭まることもあります。
メーカー公式、ツール会社、コミュニティのどれが支えているかで、保守の考え方が変わります。
※2026年10月1日時点で、各社・各プロジェクトの公式情報から確認できた範囲です。表にないマイコンは、コミュニティのライブラリの有無を個別に確認してください。
「公式サポート」と「コミュニティのサポート」は分けて考えるべきです。コミュニティのクレート（Rustのライブラリ）にも完成度の高いものはあります。
それでも、不具合が出たときの問い合わせ先や長期の保守を誰が担うかは、自社で判断することになります。量産後に10年以上保守する製品では、ここが採否を分けます。
メーカー公式でも、範囲には注意が要ります。
Espressifのesp-hal 1.0.0は「メーカーが支援する最初のRust SDK」とうたわれています。ただし、安定版として固定されたのは初期化処理と4種類のドライバなど一部です。残りは今後、段階的に安定化するとされています。
コンパイラのターゲット対応（Tier）
Rustのコンパイラは、対応するターゲットをTier 1〜3に分けています。Arm Cortex-M、Cortex-R、RISC-Vのベアメタル向けはTier 2です。
Rustプロジェクトがビルドできることを保証し、コアライブラリのバイナリを公式に配布しています。
AVR、MSP430、Xtensa系のESP32はTier 3で、自動ビルドやテストの対象外です。
TriCore（AURIX）やRH850は標準のコンパイラのターゲット一覧になく、ツール会社の専用コンパイラを使います。
8ビット・16ビットの小さなマイコンや独自アーキテクチャほど、選択肢は狭くなります。
フレームワークとRTOS
Rustには、組込み向けのフレームワークがいくつかあります。Embassyは、Rustの非同期構文（async/await）を使うフレームワークです。
タスクをコンパイル時にステートマシンへ変換し、動的メモリ確保なしで協調的に動かします。
RTICは、Cortex-MのNVIC（割り込みコントローラ）などハードウェアの割り込み優先度を使ってスケジューリングする仕組みです。
既存のRTOS側にも動きがあります。Zephyrは2025年3月の4.1で、オプションのモジュールを有効にすればアプリケーションをRustで書けるようになりました。
ただし公式発表には「まだ実験的」と明記されています。2026年10月時点の公式ドキュメントでも、Rustはオプションのモジュールという位置づけで、対応するボードは一部に限られます。
TockはRustで書かれたマイコン向けのOSで、互いに信頼しない複数のアプリケーションを動かす設計です。
CのRTOSの上でRustの処理を動かすのか、Rustのフレームワークに寄せるのかは、既存資産の量で決まります。使い慣れたRTOSとドライバが大量にあるなら、まずは混在から始めるほうが無理がありません。
機能安全とRust｜認定ツールと規格の動き
車載や産業機器で避けて通れないのが機能安全です。ISO 26262やIEC 61508では、コンパイラなど開発ツールの信頼性も説明する必要があります。
Cには認定済みのコンパイラや静的解析ツールが長年そろっており、Rustはこの点が弱点でした。
状況が動いたのは2023年です。
同年11月、Ferrous SystemsはFerroceneがISO 26262とIEC 61508のツール認定を取得したと発表しました。認証機関はTÜV SÜDで、Rustコンパイラとしては初めてです。
2025年1月には、医療機器ソフトウェアの規格であるIEC 62304（クラスC）も加わっています。
公式サイトの2026年10月時点の表記では、Ferroceneは認定済みツールチェーンとされています。ISO 26262のASIL D、IEC 61508のSIL 3、IEC 62304のクラスCまでの開発に使えるとのことです。
対象はLinux、QNX、Armやx86-64のベアメタルなどで、すべてのマイコンではありません。
IEC 61508のレベルは、2023年11月の発表ではSIL 4とされていました。
現在の公式サイトと2025年12月以降のリリース文はSIL 3と表記し、SIL 4は利用企業側の認証を支援する、という書き方になっています。
認定の対象となるバージョンとターゲットもリリースごとに決まっているため、採用時は最新の認定文書で確認が必要です。
コンパイラの認定と、ライブラリの認証は別に進んでいます。
※2026年10月1日時点の各社公式サイト・発表による。認定の対象バージョンやターゲットは、採用前に各社の最新情報で確認してください。
ライブラリ側の整備も始まっています。Ferrous Systemsは2025年12月、coreライブラリのサブセットがIEC 61508のSIL 2で認証されたと発表しました。
2026年2月のリリースでは、ISO 26262のASIL Bも加わっています。
裏を返すと、サブセットに含まれない機能や外部のクレートを安全関連のソフトウェアで使う場合は、利用者側で妥当性を示す必要があります。
もう1つ、認定済みのコンパイラを使えば製品が認証されるわけではない点にも注意が要ります。安全分析、要求から試験までのトレーサビリティ、検証の証拠づくりは、言語に関係なく求められます。
Rustが肩代わりするのは、そのうちメモリ安全性に関わる一部です。
MISRAとコーディング規約
Cの安全関連開発で広く使われるMISRA Cにも、Rustに関する文書が出ています。MISRAは2025年3月、「MISRA C:2025 Addendum 6」を公開しました。
これは、MISRA Cの各ガイドラインがRustにも当てはまるかを評価した対応表です。unsafe やFFIを含むRust全体の場合と、safe Rustだけの場合に分けて評価しています。
この文書の序文には、言語を切り替えるだけで問題がすべて解決するという認識があるが、実際はそうではない、という趣旨が書かれています。Rust専用のコーディングガイドラインは、整備が始まった段階です。
SAEは、自動車と航空宇宙にまたがる文書としてJA1020（重要システムでRustを使う際の安全・サイバーセキュリティの推奨事項）をまとめています。
SAEの公式ブログ（2026年4月）は、この文書を最初の手引きと位置づけ、網羅的な規範ルールは今後の利用の蓄積から生まれるとの見通しを示しました。
Safety-Critical Rust Consortiumも、コーディングガイドラインの作成を公開の場で進めています。
導入の課題｜C資産・人材・ツール
言語としての利点がはっきりしていても、導入の判断は別の話です。設計から量産、保守まで続く組込みエンジニアの仕事の流れのどこに影響が出るかを、先に洗い出しておく必要があります。
既存のC資産との共存
多くの現場では、ドライバ、ミドルウェア、RTOS、過去製品のコードがCで書かれています。すべてを書き直すのは現実的ではなく、CとRustの混在が前提になります。
HighTecのCTOも、Infineonの発表のなかで、多くのプロジェクトは既存コードを再利用する混在型になるとの見方を示しています。
RustからCの関数を呼ぶことも、CからRustの関数を呼ぶことも可能です。ただし、境界では型の変換が必要で、Cの関数の呼び出しは unsafe になります。
Rust公式ブログのインタビュー調査でも、安全関連の領域で難しいのはC/C++とのFFIだという技術者の声が紹介されています。
人材と学習コスト
所有権や借用は、Cにはない概念です。慣れるまではコンパイルが通らず、作業が進まない期間があります。
ホワイトハウスの技術レポートも、宇宙システムのように制約の厳しい用途について触れています。メモリ安全な言語の有効性を示すには、ツールチェーンの整備、人材教育、実績の蓄積がさらに必要だという指摘です。
社内のC経験者が学ぶ形が中心になるため、学習時間を業務として確保できるかがポイントです。個人の努力に任せず、リスキリングの計画に組み込むほうが定着します。レビューできる人が1人しかいない状態で量産コードに入れるのは避けたいところです。
ツールと依存クレート
開発ツールの成熟度にも差があります。
Volvo Carsのアーキテクトは、先ほどのインタビュー記事（2024年10月公開）で開発ツールの状況にも触れています。
対象は、実機でのユニットテスト、カバレッジ計測、実行時のプロファイリング、ソフトウェア部品表（SBOM）とライセンスの管理です。
これらについて、半分は整っているが自分たちで作る部分が多いと述べています。
外部クレートの扱いも論点です。
Rust公式ブログの調査によると、安全要求のない領域では外部クレートを活用できます。一方、ASIL B以上では第三者のクレートを正当化しにくく、内製や書き直しで対応しているという声が紹介されています。
便利なライブラリがそのまま使えるとは限らないことは、見積もりに入れておくべきです。
コンパイラのバージョン管理にも手間がかかります。安全関連の開発ではツールのバージョンを固定しますが、依存するクレートが新しいコンパイラを要求し、ずれが生じるという指摘が同じ調査にあります。
バイナリサイズ
Flashの小さいマイコンでは、バイナリサイズも確認が必要です。
The Embedded Rust Book は、最適化をかけないビルドは大きく遅くなり、Flashを数十KiB占めることがあると説明しています。
サイズを優先する最適化レベル（opt-level の “s” や “z”）を指定すれば小さくできます。
最適化後のサイズがCと比べてどうなるかは、使う機能やライブラリで変わります。Flashに余裕のないマイコンでは、机上の比較ではなく、対象のマイコンで早めに実測するのが確実です。
Rustが向く場面・向かない場面と判断の観点
ここまでの内容を踏まえると、考えるべきは「Cを置き換えるかどうか」ではなく、「どこに使うと効果が出るか」です。向く場面と慎重に見るべき場面を分けると、次のようになります。
左の列が向く場面、右の列が慎重に見る場面です。
採否を決める5つの観点
自社の製品で検討するときは、次の5点を順に確認すると判断しやすくなります。
- マイコン：コンパイラのTierはいくつか。HALはメーカー公式か、コミュニティか
- 安全・規制：求められる規格とレベルは何か。認定済みツールの対象に入っているか
- 既存資産：Cコードの量はどれだけか。RustとCの境界をどこに引けるか
- 人：学ぶ時間を確保できるか。コードをレビューできる人が複数いるか
- 保守期間：コンパイラと依存クレートのバージョンを、製品寿命のあいだ維持できるか
5つのうち、マイコンと安全・規制は自社だけでは変えられない条件です。ここで引っかかるなら、無理に採用せず、次の機種の選定時に改めて検討するほうが安全です。
条件がそろう場合も、最初は小さく始めます。独立したモジュールを1つ選び、Cの既存コードと並べて、サイズ、実行時間、テストのしやすさを比べます。評価用の試作で数字を取ってから、量産コードに広げる流れが無理のない進め方です。
言語が変わっても、限られた資源で確実に動くソフトウェアを作るという組込みエンジニアの役割は変わりません。Cの知識は、unsafe の中身やハードウェアに近い部分を理解するうえで、Rustを使う場合にもそのまま生きます。
まとめ
- Rustは組込み開発で使える段階に入ったが、マイコン、安全規格の要求、既存のC資産によって答えが変わる
- Cとの最大の違いは、所有権のルールをコンパイラが検査する点。unsafe、FFI、論理的な不具合は残る
- Android、Linuxカーネル、車載の一部ECUで採用が進み、Infineon、EspressifなどがRustを公式にサポートしている
- Ferroceneなど認定済みコンパイラが登場したが、対象ターゲットと認証済みライブラリの範囲は限られる
- 既存のCコードは残し、新しく書く独立したモジュールから小さく試すのが現実的
Rustをめぐる状況は、認定ツールの範囲やメーカーのサポートを中心に、半年単位で変わっています。採用を検討するときは、この記事の時点の情報をそのまま使わず、各社の最新の発表を確認してください。
関連する職種はソフトウェア・組込みや電気・電子設計、業種では自動車・輸送機器のページに、関連記事をまとめています。
出典
出典・参考資料（41件）を開く出典・参考資料を閉じる
- 所有権：The Rust Programming Language「What Is Ownership?」
- unsafe：The Rust Programming Language「Unsafe Rust」
- 範囲外アクセスとパニック：The Rust Programming Language「Unrecoverable Errors with panic!」
- 並行処理：The Rust Programming Language「Fearless Concurrency」
- no_std：The Embedded Rust Book「A no_std Rust Environment」
- PAC・HAL：The Embedded Rust Book「Memory Mapped Registers」
- パニックハンドラ：The Embedded Rust Book「Panicking」
- Cとの相互運用：The Embedded Rust Book「Interoperability」
- バイナリサイズ：The Embedded Rust Book「Optimizations: the speed size tradeoff」
- ターゲットのTier：The rustc book「Platform Support」
- メモリ安全ロードマップ：CISAほか「The Case for Memory Safe Roadmaps」（2023年12月）
- ONCDの技術レポート：The White House「Back to the Building Blocks: A Path Toward Secure and Measurable Software」（2024年2月）
- Androidの脆弱性の割合：Google Security Blog「Eliminating Memory Safety Vulnerabilities at the Source」（2024年9月25日）
- AndroidのRust：Google Security Blog「Rust in Android: move fast and fix things」（2025年11月13日）
- Linux 6.1のRust：LWN.net「Rust in the 6.2 kernel」
- LinuxカーネルのRustの位置づけ：LWN.net「The (successful) end of the kernel Rust experiment」（2025年12月10日）
- Volvo Carsの事例：Tweede golf「Rust is rolling off the Volvo assembly line」（2024年10月7日）
- InfineonのRustサポート：Infineon Technologies ニュースリリース（2023年3月7日）
- AURIX向け認定コンパイラ：Infineon Technologies ニュースリリース（2024年4月5日）
- RH850/U2x向けツールチェーン：HighTec EDV-Systeme ニュース（2026年3月9日）
- esp-hal 1.0.0：Espressif Developer Portal「esp-hal 1.0.0 release announcement」（2025年10月30日）
- STM32のコミュニティサポート：stm32-rs（GitHub）
- STのセンサー用ドライバ：STMicroelectronics「st-mems-rust-drivers」（GitHub）
- Embassy：Embassy 公式サイト
- RTIC：Real-Time Interrupt-driven Concurrency（RTIC）公式ドキュメント
- ZephyrのRust対応：Zephyr Project「Zephyr RTOS 4.1 Now Available」
- ZephyrのRust対応（ドキュメント）：Zephyr Project Documentation「Rust Language Support」（2026年10月1日閲覧）
- Tock：Tock Embedded Operating System 公式サイト
- Ferroceneの認定（2023年）：Ferrous Systems「Officially Qualified – Ferrocene」（2023年11月8日）
- FerroceneのIEC 62304：Ferrous Systems「Ferrocene Achieves IEC 62304 Qualification」（2025年1月14日）
- coreライブラリの認証：Ferrous Systems「Ferrous Systems Achieves IEC 61508 (SIL 2) Certification for Rust Core Library Subset」（2025年12月3日）
- coreライブラリのASIL B認証：Ferrous Systems「Ferrocene 26.02.0 now available!」（2026年2月15日）
- Ferroceneの認定範囲：Ferrocene 公式サイト（2026年10月1日閲覧）
- MISRAとRust：MISRA「MISRA C:2025 Addendum 6 Applicability of MISRA C:2025 to the Rust Programming Language」（2025年3月）
- SAE JA1020：SAE International「About SAE JA1020 – Safety and Cybersecurity Recommendations for the Use of the Rust Language in Critical Systems」（2026年4月24日）
- Safety-Critical Rust Consortiumのガイドライン：Safety-Critical Rust Coding Guidelines（GitHub）
- AUTOSARのRustサブグループ：AUTOSAR ニュース（2022年4月6日）
- AUTOSARの説明文書：AUTOSAR「Explanation of ARA Applications in Rust」（R23-11）
- Safety-Critical Rust Consortium：Rust Foundation「Announcing the Safety-Critical Rust Consortium」（2024年6月12日）
- 安全関連分野のインタビュー調査：Rust Blog「What does it take to ship Rust in safety-critical?」（2026年1月14日）
- 利用者調査：Rust Blog「2025 State of Rust Survey Results」（2026年3月2日）
NEWSLETTER
選んだ職種・業種に合わせた記事を、週1回メールで
週刊MONOSCOPEは、登録時に選んだ職種・業種に合わせた記事を週1回お届けする無料のメルマガです。
職種・業種を選んで登録へ ›
無料・週1回。登録後に届く確認メールのリンクを押すと登録が完了します。配信はメール内のリンクからいつでも停止できます。
WEEKLY NEWS
今週の製造業ニュース10選
メルマガは職種・業種に合わせた記事。LINEとnoteでは、全員共通の10本を毎週土曜の朝にお届けします。
LINEでニュース10選を受け取るnote今週のニュース10選をnoteで読む ›
コメント