Skip to content
Published on

Ferrocene の認証された core — コンパイラは ASIL D なのに、ライブラリはなぜ ASIL B で止まるのか

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
シェア
Authors

はじめに — 「ASIL D 認証 Rust コンパイラ」という言葉の罠

組み込み Rust の話題が出るたびに繰り返される文があります。「Ferrocene が ISO 26262 ASIL D 認証を取得した」。この文自体は間違っていません。Ferrous Systems の公開文書がまさにそう書いているからです。

問題は、この文から人々が引き出す結論です。「じゃあもう Rust で ASIL D ソフトウェアを書いていいんだな」。違います。ここには本来別々の二つの主張が一つに押し潰されており、2026年上半期に実際に動いたのは、その押し潰された側ではなく、その下にあったもの — core ライブラリ — でした。

本稿はその話です。Ferrocene が2025年12月から2026年5月にかけて実際に何を認証したのか、なぜコンパイラは ASIL D なのにライブラリは ASIL B で止まるのか、その天井はどこから来るのか、そして依然としてあなたの側に残るものは何かを見ていきます。結論から言えば、この話でいちばん値打ちのある部分は、ベンダーが隠したものではなく、ベンダー自身が書き残したものにあります。

ツールの資格認定とソフトウェアの認証は別物である

まず用語の整理です。これが本稿全体の骨格になります。

Ferrocene コンパイラ(rustc) は ツール として資格認定(qualification)を受けました。Ferrocene 資格認定報告書(Qualification Report)の最初の一文はこう書いています — 本文書は、自動車 ISO 26262:2018 (ASIL D / TCL 3)、産業 IEC 61508:2010 (class T3)、医療 IEC 62304:2006 + AMD 1:2015 規格の認証のために開発された資格認定資料の報告書である。

ここで鍵になる略語が TCL、Tool Confidence Level(ツール信頼水準)です。ISO 26262 part 8 の clause 11 が扱うのは「ソフトウェアツール使用に対する確信」であって、ツールが吐き出したコードの完全性水準ではありません。TCL 3 で ASIL D の資格認定を受けたということは、「ASIL D 開発にこのコンパイラを使ってよい」という意味です。「コンパイル結果が ASIL D である」という意味ではありません。

core ライブラリのサブセット はまったく別物です。これはツールではなく ソフトウェアコンポーネント であり、ソフトウェアとして認証(certification)を受けました。同じ資格認定報告書はこう続けます — 本文書の一部は、自動車 ISO 26262:2018 (ASIL B) および産業 IEC 61508:2010 (SIL 2) ソフトウェア規格の認証のために開発された Core Library Certification から参照されうる。

この二つの数字はマーケティング文句ではなく、ドキュメントビルドシステムの設定ファイルに機械可読な形で埋め込まれています。Ferrocene リポジトリの ferrocene/doc/sphinx-substitutions.toml を開くとこうなっています。

iso_26262_ferrocene_asil = "ASIL D"
iso_26262_core_asil = "ASIL B"
iso_26262_ferrocene_tcl = "TCL 3"
iso_26262_ferrocene_tql = "class T3"

iec_61508_core_sil = "SIL 2"

コンパイラは ASIL D / TCL 3、core は ASIL B。26.02.0 ブランチと 26.05.0 ブランチでこのファイルは一字一句違いません。つまり ASIL B の天井は最新リリースでもそのままです。

そして安全マニュアル(Safety Manual)の「Qualification scope」章は、ユーザーの責任をこう釘付けにします — ISO 26262:2018 part 8 の clause 11.4.2 に従い、ユーザーは安全関連開発にこのソフトウェアツールを使う前に、あらかじめ定められた TCL の妥当性を検証しなければならない。そして clause 11.4.3 に従い、ユーザーはこのツールの使用法・環境・機能的制約が、その評価基準または資格認定に適合していることを保証しなければならない。

読めばわかるとおり、これは「我々が全部済ませておいたので使ってください」ではなく、「我々の資格認定の有効範囲をあなたが検証してください」という文です。

2025年12月から2026年5月まで — 実際に起きたこと

時系列に整理するとこうです。

2025年12月3日 — 最初の core サブセット、IEC 61508 SIL 2。 Ferrous Systems がプレスリリースで発表しました。TÜV SÜD が Rust core ライブラリの最初のサブセットを IEC 61508 (SIL 2) として認証し、このサブセットは Ferrocene 25.11.0 に含まれます。認証は Ferrocene ツールチェーンと資格認定済みターゲット(Armv7E-M、Armv8-A を含む)での使用に適用されます。作業は2023年に始まり、Cryspen と Thoughtworks がツールと時間を提供しました。Ferrous のマネージングディレクター、Florian Gilcher の言葉をそのまま引けば — 「core なしで Rust を組み込みや安全必須環境で動かすのは非現実的であり、core は Ferrocene のようなツールチェーンで厳密に検証しない限り認証されえない」。

同じ資料は実際の導入事例を二つ挙げています。Sonair は自律ロボット用の3D超音波センサー ADAR に使っており(クアッドコアの Armv8-A 上で、Armv7E-M サブシステムとともに動きます)、Kiteshield は地下鉱山の有人・自律機材の衝突防止システムに使っていて、最終的には IEC 61508 SIL 3 まで要求されるコンポーネントもあるとのことです。

2026年2月15日 — ASIL B 追加、サブセット拡大。 26.02.0 リリースです。認証済み core サブセットに ISO 26262 (ASIL B) が加わり、SIL 2 サブセット自体も大きく広がりました。ベンダー発表の数値では、認証済み関数の数が2,903個から5,169個に増え、core::slice、core::iter、core::ffi、core::result といったモジュールが拡張され、最小限の認証済みパニックフックが入りました。リポジトリの ferrocene/version ファイルが確認するとおり、このリリースの rustc は 1.92 です。eeNews Europe も独立して報道しました — embedded world 2026 で公開され、要点は認証がコンパイラツールチェーンを越えてライブラリ層まで降りてきたということです。

2026年5月 — core::fmt 認証、そして強制方式の入れ替え。 ここから面白くなります。26.05.0 には発表ブログ記事がありません。ferrous-systems.com/blog/ferrocene-26-05-0/ は404で、ブログ索引の最後の Ferrocene リリース告知はいまだに 26.02.0 のままです。しかしリリース自体は出ています — リポジトリの release/1.95 ブランチで ferrocene/version が 26.05.0 を保持しており、リリースノートから :upcoming-release: マーカーが取り除かれています(一方で release/1.97 の 26.08 はまだそのマーカーを付けています)。内容はこうです。

  • core::fmt モジュールが ISO 26262 (ASIL B) と IEC 61508 (SIL 2) に認証されました。Rust のデータ構造を人間が読める出力に整形するコードです。
  • その結果、「認証済みパニックランタイム」ターゲット群(aarch64-ferrocene-none、thumbv7em-ferrocene-none-eabi など)が廃止されました。整形コードを認証しないままパニックだけを認証するために作られたものでしたが、もう必要なくなったのです。
  • ferrocene::unvalidated リントが導入され、「サブセットターゲット」群が廃止されました。詳しくは後述します。
  • 新しい資格認定ターゲット aarch64-rhivos2-linux-gnu が追加され(aarch64-unknown-linux-gnu ホストでコンパイルする場合のみ)、proc_macro クレートタイプが許可されました。
  • thumbv7em-m4-none-eabihf と aarch64-a53-none が削除されました。26.02.0 で新しく追加されたターゲットでしたが、いまはベースターゲットで -C target-cpu=cortex-m4 / -C target-cpu=cortex-a53 を使えば同じことになります。

26.05.0 の core::fmt 認証は、ユーザーマニュアルにも痕跡が見えます。26.02.0 の core/using.rst にはこんな警告がありました — 認証済みターゲットを使うとき core ライブラリの挙動が異なる、とりわけ panic! マクロが任意の format_args! ではなく静的文字列しかサポートしないため、パニックメッセージが有用性に欠けることがある。26.05.0 の同じファイルでは、この段落がまるごと消えています。

独立検証。 リポジトリには、認証済みシンボルの権威あるリストが CSV として入っています(ferrocene/doc/symbol-report.csv、core-certification 文書の Safety Report 章がこのファイルをそのまま含んでいます)。二つのリリースブランチから取得して数えるとこうなります。

release/1.92 (26.02.0):  5,235 unique symbols   core::fmt シンボル:   0
release/1.95 (26.05.0):  8,790 unique symbols   core::fmt シンボル: 535
                         (追加 3,597 / 削除 42)

この数字が示すのは、core::fmt 認証が実際に反映されたということを、リリースノートとは無関係に確認できるという点です。ただし正直に言えば、26.02.0 の CSV にある5,235という数はベンダー発表の「5,169個の認証済み関数」と正確には一致しません。ファイル名が示すとおり、これは シンボル のレポートであり発表文は 関数 を数えているので、集計基準が異なる可能性が高いです。ですから5,169という数字はベンダー自身の集計として読み、確かなのは桁数と方向だけです — 一つのリリースでサブセットがおよそ1.7倍になりました。

削除された42個も興味深いところです。大半は core::panicking::PanicArguments::as_str のような旧・認証済みパニックランタイムの部品と、derive 内部のマーカー(assert_receiver_is_total_eq)です。サブセットは増えるだけでなく、減ることもあります。

2026年8月(予定)。 release/1.97 の 26.08 はまだ upcoming マーカーを付けており、三つの新しい資格認定ターゲットを予告しています — aarch64-unknown-qnx、armv7r-none-eabihf、x86_64-pc-qnx。flip-link が quality managed に格上げされます。

なぜ core 全体ではなくサブセットなのか

Ferrous のコンパイラエンジニア Jynn が書いた Callgraph analysis(2026年4月1日)が、その理由を率直に説明しています。認証対象は IEC 61508 (SIL 2) であり、この規格の要求事項のうちコードベースの規模に比例して増えるのが Annex A.9「Software verification」です。Ferrous は方法3と4(静的解析、動的解析)を使います。文書化されたアプローチは、認証済み core があるすべてのターゲットプラットフォームでテストを走らせ、すべての関数がテストされたことを検証するコードカバレッジを収集することです。

つまりコードが多いほどテストも増やさなければなりません。原文の表現をそのまま移せば — 製品が出るまでに何年分もの作業をするのを避けるため、core のサブセットだけを検証することにした。関数を validated と表示し、それぞれについてテストを走らせてカバレッジを集め、顧客にはその検証済み関数だけを使うよう伝える、というやり方です。

認証の形式的な経路も文書に書かれています。core-certification 文書の Certification scope 章によれば、IEC 61508 側は section 7.4.2.12 の Route 3S — 「非準拠開発の評価(Assessment of non-compliant development)」— であり、ISO 26262 側は SEooC(Safety Element out of Context)ソフトウェア開発として part 2/6/8 をテーラリングしたものです。

Route 3S が何を意味するのかピンとこなければ、こう考えるとよいでしょう。Rust の core は IEC 61508 を念頭に開発されたことは一度もありません。そもそも規格に沿って開発されなかったものを事後に評価して使えるかどうかを判定する経路が Route 3S です。そして ISO 26262 の適用条項リストを見ると興味深い項目が一つあります — 「8-12 ソフトウェアコンポーネントの資格認定」は 適用しない と書かれており、理由は「資格認定を適用せず、新規開発として扱う」です。つまり既存のソフトウェア資格認定経路を通らず、新規開発であるかのように証拠を積み上げたということです。

サブセットをどう強制するか — cfg ハックからコールグラフ・リントへ

ここが本稿でいちばんエンジニアリングらしい部分です。

問題はこうです。「認証済み関数だけ使ってください」と言うのは簡単ですが、ユーザーには自分が core のどの部分を使っているのか知る術がありません。Callgraph の記事はまさにそこを突いています — core は普通のライブラリではなく、コンパイラや言語との広範な統合を抱えています。do_io()? のように無害に見えるものを使うと、実際には core::ops::try_trait::Try::branch の呼び出しが発生します。どの関数がどの関数を呼ぶかを知るには本物のコンパイラ統合が必要です。

第一の試み(25.11、26.02): cfg フォーク + 偽サブセットターゲット。 標準ライブラリをフォークして、パニック機構全体に cfg を貼り付ける方式です。しかしこれでは認証に関心のないすべてのユーザーまで影響を受けるため、破壊的変更を避けようとして aarch64-unknown-ferrocene.subset のような新ターゲットをまるごと作りました。Ferrous 自身の評価は冷静です — ビルドスクリプトがターゲット名をパースできず、libtest が cfg で削られた core の部分を使うためそのターゲットではコンパイルできず、実務的には人々に「cargo check --target aarch64-unknown-none.subset は動かしてよいが、フルビルドには使わないでください」と案内せざるをえず、これは非常に悪いユーザー体験でした。

安全マニュアルも同じことを警告ボックスに書いています — サブセットターゲットは サブセット準拠の検証にのみ 使うことができ、ランタイムで認証済みターゲットとして使うことは できません。

第二の試み(26.05): カスタム rustc ドライバー上のリント。 26.05.0 が導入した ferrocene::unvalidated リントです。いまや準拠を証明する手順は、安全マニュアルの基準でこれだけ短くなりました。

// 1. 各クレートルートでリントを有効にする
#![warn(ferrocene::unvalidated)]

// 2. -D warnings でコンパイルする。成功すればサブセットは守られている。
//
// 失敗した場合は次の四つのうちどれか:
//   a) その関数が自分のクレートのものなら #[ferrocene::prevalidated] を付ける
//   b) core の関数なら Ferrous に連絡してサブセットへの追加を相談する
//   c) 呼び出しを消して同じ意味になるよう書き直す
//   d) そのまま使い続けるが安全性を自分で証明し #[allow(ferrocene::unvalidated)] を付ける

リントが守る不変条件は一文にまとめられます — core の validated な関数集合は、関数呼び出し演算について閉じていなければならない。validated な関数の中で呼び出しが見えれば、呼び出される側も validated でなければならないという意味です。逆方向は問題になりません。認証されていない core::async_iter::from_iter が認証済みの usize::checked_add を呼ぶことには何の問題もありません。

実装は二つのパスに分かれます。

  • pre-mono パス(THIR ベース)。 cargo check で速いフィードバックを与え、? のような組み込み構文を desugar できるくらい遅く動きます。関数型から関数ポインタへの unsizing キャストを捉えて「認証されていない関数ポインタを認証済み関数に渡す」という回避策を防ぎ、dyn Trait オブジェクトへのキャストも捉えます(supertrait と dyn-to-dyn 強制変換まで考慮して)。
  • post-mono パス(MIR ベース)。 こちらが認証が実際に依存しているパスです。ジェネリクスがインスタンス化される前は x.clone() がどの clone なのかわからないため、モノモーフィゼーションされたルートから出発し、型を代入しながらコールグラフをたどっていきます。代わりに cargo check では動かず cargo build でのみ動きます(公開ジェネリック関数を持つライブラリならさらに遅く出ることもあります)。

設計原則も明示されています — 偽陰性より偽陽性を選ぶ。有効なコードを誤って拒否するほうが、無効なコードが認証されるより良いということです。安全ツールとしては正しい方向であり、実務的には「まったく問題ないコードがリントに引っかかり、#[allow] を付けながら安全論証を書く羽目になる」ということでもあります。

この転換自体が一つのシグナルです。認証の強制メカニズムが「標準ライブラリのフォーク + 名前の奇妙な偽ターゲット」から「コンパイラパス」へと格上げされました。前者はハックで、後者はエンジニアリングです。

ASIL B の天井の正体 — ベンダー自身が書き残したもの

さて、本稿の核心的な問いです。コンパイラは ASIL D ツールとして資格認定されているのに、なぜライブラリは ASIL B で止まるのか。

答えを推測する必要はありません。Ferrous は ISO 26262 6-Method Tables という文書を、MIT/Apache-2.0 ライセンスの公開リポジトリにそのまま載せています。ISO 26262 part 6 の各方法表について、「ASIL B でどれだけ推奨されるか / ASIL D でどれだけ推奨されるか / 我々は適用したか」を一行ずつ書いたものです。

Table 9、ソフトウェアユニット水準の構造的カバレッジ指標はこうです。

No.  Method            ASIL B  ASIL D  Justification
1a   Statement coverage   ++      +     Applied, 100% line coverage with
                                        explanations for any coverage gaps
1b   Branch coverage      ++      ++    Not applied, 1a applied instead
1c   MC/DC                 +      ++    Not applied, 1a applied instead

すべてここにあります。適用されているのは構文カバレッジ(statement coverage)一つだけで、分岐カバレッジと MC/DC は「未適用、代わりに 1a を適用」です。しかし表が示すとおり、分岐カバレッジは ASIL B と D の両方で強く推奨(++)されており、MC/DC は ASIL D で強く推奨されています。逆に構文カバレッジは ASIL D では単なる推奨(+)に落ちます。

つまり ASIL B が上限なのではなく、現在積み上げられている証拠が ASIL B までしか支持していない ということです。ASIL D を主張するには Table 9 の 1b と 1c を埋める必要があり、それは core のサブセット全体について分岐カバレッジと MC/DC を改めて確保することを意味します。公開文書のどこにもその計画はありません。

同じ文書には、組み込みエンジニアが特に注目すべき欄がいくつかあります。

  • Table 7、1m リソース使用量評価(Resource usage evaluation)。 ASIL D で強く推奨。判定は「未適用、単なるライブラリなのでインテグレーターの責任」。組み込みの文脈に訳せば、スタック深さ解析と WCET です。認証済み core を使ったからといって、スタックをどれだけ食うか、最悪実行時間がどれくらいかについての答えが付いてくるわけではありません。それはあなたの仕事です。
  • Table 6、1j 再帰禁止。 ASIL D で強く推奨。判定は「未適用」。正確な文言は — 無条件再帰は禁止だが(コンパイラが本体を置き換える #[lang_item] を除く)、条件付き再帰は許可される。スタック制約の厳しい MCU では、これは読み流していい文ではありません。
  • Table 7、1g データフロー解析。 ASIL D で強く推奨。「未適用、解析すべき内部データフローがない、グローバル状態がない、すべて明確なインターフェースのみを通す」。
  • Table 1、モデリング・コーディングガイドライン。 判定はこうです — 認証済み core ライブラリにコーディング標準はない。理由は、アップストリームの Rust の lint とテストをそのまま使うほうがアップストリームとの乖離を減らすからで、乖離が大きくなるほど保守負担とバグの温床が増えるという論理です。MISRA に慣れた人には見慣れない答えですが、論理自体は擁護可能です。
  • Table 2/3/4、ソフトウェアアーキテクチャ設計。 すべて「該当なし、アーキテクチャが存在しないため」。core-certification の要求事項文書も同じことを言っています — core ライブラリは規模が小さいのでソフトウェアアーキテクチャを必要としない。
  • Table 8、1b/1c 等価クラス生成・分析と境界値分析。 ASIL B/D いずれも強く推奨。判定は「部分適用」。原文が正直です — coretests のテストケースは非常に丁寧に作られているが、Ferrous Systems は境界値と極端な値が常にテストされているかどうかの全数レビューはしていない。100% の行カバレッジ達成が、すべてのコードパスが実行され、特定の入力に対するテストがないために未テストのまま残ったコードがないことを保証する、というのがそれに続く論拠です。

そして要求事項管理の方式自体が議論を呼びます。core-certification の Requirements Management 章はこう始まります — 要求事項は doc-comment として実装される。 関数の doc-comment がその関数の要求事項であり、モジュールの doc-comment がモジュール設計であり、要求事項識別子は「Ferrocene バージョン + 関数のモジュールパス」です。要求事項をテストに追跡する方法はこうです — 関数の要求事項はその関数の上にある doc-comment なので要求事項は関数によって追跡される、認証はコードカバレッジに依存して各関数が十分にテストされていることを保証する、したがってすべての関数がテストでカバーされていればすべての要求事項もカバーされている、ゆえにテストを要求事項に手動で追跡する必要はない。

この論証に納得できるかどうかは各自の判断です。ただ、これがなぜ賢い選択なのかははっきりしています — Rust core の doc-comment は実際に例外的なほどよく書かれており doctest として強制実行されるため、コードとずれにくいのです。存在しない要求事項仕様を新たに作り出すより、すでに存在し、すでに検証されている文書を要求事項に格上げするほうがよいという判断です。

一つ強調しておきます。 上記の「未適用」の欄は、私が掘り出したベンダーの弱点ではありません。Ferrous が自らの手で書き、オープンソースのリポジトリに載せたものです。安全必須ツールベンダーの norm mapping は通常 NDA の裏にあり、評価レポートを見るには契約書にサインしなければなりません。これらの表が git clone 一回で読めるという事実自体が、このプロジェクトでいちばん良い部分かもしれません。そしてこれらの表は天井を隠すのではなく、説明しています。ASIL B がどこから来るのか知りたければ、Table 9 だけ見ればよいのです。

あなたのチップはおそらくリストにない

認証の議論をする前に確認すべきことがあります。あなたのターゲットがそもそもリストに載っているかどうかです。

26.05.0 安全マニュアルの資格認定範囲は、次の組み合わせに限定されています。

Host                       Target                        Certified  Uncertified          Qualified
aarch64-unknown-linux-gnu  aarch64-rhivos2-linux-gnu     core       alloc
x86_64-unknown-linux-gnu   aarch64-unknown-none          core       alloc
x86_64-unknown-linux-gnu   aarch64-unknown-nto-qnx710    core       alloc, std, test     proc_macro
x86_64-unknown-linux-gnu   thumbv7em-none-eabi           core       alloc
x86_64-unknown-linux-gnu   thumbv7em-none-eabihf         core       alloc
x86_64-unknown-linux-gnu   x86_64-unknown-linux-gnu      core       alloc, std, test     proc_macro
x86_64-unknown-linux-gnu   x86_64-pc-nto-qnx710          core       alloc, std, test     proc_macro

ここから読み取るべきことです。

認証されているライブラリは core だけです。 alloc、std、test はすべて未認証です。文書の表現をそのまま使えば — 提供される未認証ライブラリは、コンパイラ使用目的に限って Ferrocene の資格認定範囲内で評価・テストされている。エンドユーザーのコードがこれらのライブラリを使うことは現在 Ferrocene の資格認定の範囲外である。使用する場合、認証はエンドユーザーの責任である。ヒープ割り当てが必要な設計なら、alloc からしてあなたの宿題です。

MCU 側の資格認定ターゲットは thumbv7em の二つだけです。 Cortex-M4/M7 です。では何がないのでしょうか。Ferrocene のターゲットサポート等級文書で Supported(サポート)等級にあるリストはこうです — riscv64gc-unknown-linux-gnu、thumbv6m-none-eabi(Cortex-M0/M0+)、thumbv8m.base-none-eabi、thumbv8m.main-none-eabi、thumbv8m.main-none-eabihf(Cortex-M23/M33)、armv7r-none-eabihf、armv8r-none-eabihf、wasm32-unknown-unknown、x86_64-pc-windows-msvc(ホスト)、その他。26.05.0 はここに s390x と powerpc64le を加えました。

つまり、最近登場するセキュア MCU の半分が使う Cortex-M33 も、RISC-V も、資格認定リストには載っていません。26.08 が armv7r-none-eabihf を資格認定に格上げする予定なので方向は正しいのですが、今日時点では「Rust が認証された」ことは「自分のチップで認証済み Rust が使える」ことを意味しません。

Supported と Qualified の違いも文書が表にまとめています。Qualified はマージのたびにテストスイート全体を走らせ、既知の問題を追跡・提供し、2年のサポート期間と LTS があります。Supported はテストが「ベストエフォート」で、既知の問題は「文書化のみ」、サポートパッチは「致命的なものだけ」です。要求すれば資格認定や quality managed に格上げできると書かれていますが、これはつまり契約の話です。Ferrous は自社の開発モデルを「contract-driven」と呼び、会社にとっていちばん重要な機能に集中させるためにお金を払えると明言しています。

ホストは x86-64 Linux 一つだけです。 macOS(aarch64-apple-darwin)は quality managed、Windows(x86_64-pc-windows-msvc)は supported です。どちらも資格認定ではありません。認証対象のビルドを作る機械は x86-64 Linux でなければなりません。RHIVOS の行だけが例外的に aarch64-unknown-linux-gnu ホストを使います。

では何が依然としてあなたの側に残るのか

安全マニュアルの制約(Constraints)リストは各項目に識別子が付いています。core 側だけを抜き出すとこうです。

  • CORE_CSTR_0020_PANIC_ABORT — ユーザーは rustc に常に -C panic=abort を渡さなければならない。
  • CORE_CSTR_0030_SUBSET_ONLY_STABLE — 認証済みサブセットの実験的関数を使ってはならない。nightly 機能は論外です。
  • CORE_CSTR_0060_VERIFY_MACROS — マクロが生成したすべてのコードが正しいことをユーザーが検証しなければならない。マクロを好んで使う Rust コードベースには手強い文です。
  • CORE_CSTR_0060_VERIFY_ARCH — アーキテクチャ特化コードはアプリケーションの文脈で推論し、テストしなければならない。原文は鮮明です — 我々はコンパイラがあなたの要求した命令を正しく吐くことだけを保証し、その命令が文脈上意味をなすかどうかは保証しない。対象は core::arch モジュール全体と core::hint::spin_loop です。
  • CORE_CSTR_0070_VERIFY_FLOATS — 浮動小数点コードは、どの FPU を使うか、どの演算がハードウェアで実装されているかといった外部条件に依存する。ユーザーは自分のアプリケーションとハードウェアの文脈で浮動小数点計算を徹底的にテストしなければならず、コンパイラとライブラリの資格認定だけを唯一の論拠にしてはならない。
  • CORE_CSTR_0040_MATCHING_VERSION — core と rustc のバージョンが一致しているかを検証しなければならない。

これに rustc 側の安全マニュアルの「Handling Unsafety」章が加わります。unsafe を使うときの最低限の義務はこうです — 不安全性の使用を可能な限り局所化し、モジュール水準を絶対に超えないこと、そのモジュールが正確に一つの作業だけを行うこと、不安全コードとそのクライアントの両方に断定・事前条件・事後条件・不変条件を使うこと、両方に安全関連のコメントを付けること。検証時の最低限の義務はさらに重いです — 最低二人のシニアエンジニアがコードレビューを行うか、サードパーティレビューを活用すること、不安全コードがある モジュール全体 をレビューすること、不安全コードとそのクライアントに単体テストと統合テストを実施すること。そして緩和戦略を策定すること。

運用側の義務もあります。既知問題(Known Problems)データベースは、有効なサブスクリプションを持つ顧客だけがアクセスできます(problems.ferrocene.dev はログインの壁の向こうです)。そして安全マニュアルは釘を刺します — 新しい問題が発見されたことを認識し、新しい DB エントリに記載された手順を適用するのは顧客の責任である、通知を購読するか定期的に監視することによって。資格認定済みコンパイラを買って終わりではなく、そのコンパイラの欠陥告知を監視するプロセスを組織内に作らなければならないということです。

最後に環境です。Degraded Environment 章は RUST_TARGET_PATH と RUSTC_BOOTSTRAP を潜在的なエラー源として指名し、ユーザーはこれらの変数が設定されていないことを確認しなければならないと書いています。RUSTC_BOOTSTRAP は、安定版コンパイラで nightly 機能を強制的に開く抜け道なので当然です。

いつ使うべきでないか

正直に整理するとこうです。

使わないでください、もし

  • アプリケーションが ASIL D または SIL 3 なのに core に頼ろうとしているなら。 ライブラリは ASIL B / SIL 2 です。コンパイラが ASIL D ツールであるという事実はこの隙間を埋めてくれません。埋めるにはあなた自身が論証しなければならず、Table 9 が何が欠けているかを正確に教えてくれます。
  • ターゲットがリストにないなら。 RISC-V、Cortex-M0/M23/M33 では、問題なく動くコンパイラは手に入りますが、認証の論拠は手に入りません。契約で格上げできるとはいえ、それは予算とスケジュールの話です。
  • 設計がヒープを要求するなら。 alloc は認証範囲外であり、文書はエンドユーザーの責任だと明示しています。
  • 認証対象のビルドを Linux 以外で作らなければならないなら。 ホストの資格認定は x86-64 Linux だけです。
  • そもそも安全必須プロジェクトでないなら。 これがいちばんよくあるケースでしょう。認証から得るものがゼロなのに、サブスクリプション料(ベンダー告知基準でユーザーあたり月25ユーロまたは年240ユーロ、2026年2月時点)とサブセット規律を支払うことになります。アップストリームの Rust を使ってください。組み込み Rust に初めて触れるなら、no_std ハンズオンのほうがずっと役に立ちます。

使って価値がある場合

  • ASIL B / SIL 2 / IEC 62304 Class C の範囲の製品で、ターゲットが Cortex-M4/M7 や Armv8-A(または QNX 7.1)であり、no_std で設計できるとき。Sonair と Kiteshield はまさにこの位置にいます。
  • 認証そのものより認証資料が必要なとき。Ferrocene の安全マニュアル・資格認定報告書・norm mapping がオープンソースであるということは、審査員に見せるものがあるということであり、これは思ったより大きな意味を持ちます。
  • サブセット規律を担える組織であるとき。リントが引っかかるたびに一つ判断が生まれます — 書き直すか、Ferrous に依頼するか、自分で安全論証を書いて #[allow] を付けるか。これをレビュープロセスに吸収できる必要があります。

おわりに

一行に縮めるとこうです。コンパイラは ASIL D ツールであり、ライブラリは ASIL B ソフトウェアです。 二つの文は別物で、どちらも真実であり、一つに押し潰した瞬間に間違った計画が出てきます。

2026年の本当のニュースは「Rust が認証された」ではありません。それはすでに何年も前からの話であり、半分しか合っていない話です。本当のニュースは三つです。第一に、認証済みサブセットは実際に育っています — 一つのリリースでシンボルが5.2千から8.8千に増え、core::fmt が入ったことで「認証済みターゲットではパニックメッセージが静的文字列のみ」という制約が消えました。第二に、強制メカニズムが標準ライブラリのフォークからコンパイラパスへと格上げされました。第三に、ベンダーが自分の証拠の穴を公開リポジトリに書き残しています。

見守るべき点も明確です。Table 9 で分岐カバレッジや MC/DC が「Applied」に変わる日が来るかどうかです。それが ASIL D core への関門であり、今日公開されているどの文書もそれが来るとは言っていません。それまで、組み込みの安全必須プロジェクトで Rust を検討するなら、マーケティングの一行文句より先に sphinx-substitutions.toml の五行と method table の三行を読んでください。そこに答えがすべてあります。

参考資料

Discuss on Twitter • View on GitHub