AUTOSAR Open Conference 2026でRustが注目されていたので調べてみた

AUTOSAR

Posted at 2026-07-05

はじめに

AUTOSARはOpen Conference というものが定期的に開催されて、情報が公開されている。
第17回は2026年6月10日〜11日に中国・上海で開催された。

AOCを参照する目的：
AUTOSAR関係者が現状どういう議論をしていて、今後の標準化の流れがどうなるのか情報をインプットするため。

ビデオの内容をすべて見るのは時間がかかるので、字幕をAIに要約させながら、大事そう・気になった内容だけ抜粋。

要約ツール

今回はVectorの講演の中でRustに注目されていたので、Rustについて調べてみた。

出典

AUTSOARニュース↓

Tech. Session 3 - Vector - Wu Changlong↓

Rust↓

発表の結論(AI要約)

自動車業界のソフトウェア開発は多種多様で厳しい要求によって複雑さを増しており、従来のC/C++では開発効率や品質確保に限界が見え始めている。Rustは安全性をコンパイル時に保証し、高性能ながら開発生産性も高い強力な言語として注目されている。導入はまだ初期段階でハードウェア対応や解析ツール面の課題は残るものの、既にボルボなどは実用化を開始しており、今後さらに広がる見込みだ。

既存Autosarプラットフォームとの融合には、段階的・実用的な統合方法を選択し、即時の全面置換ではなく、クリティカルなアプリ層からRustを適用していく戦略が有効。Vectorはこの流れを後押しするソリューションを提供中で、技術連携や標準化の動きにも注目が集まる。

アクションを取る技術者は、今後の技術成熟とツール普及をウォッチしつつ、小規模なクリティカルモジュールや新規開発でRust適用を試験的に進めることが効果的。
Rustの特性と現状課題を理解し、自社のプロジェクトに合った柔軟な導入計画を立案・試行しながら、将来的な高品質・低コスト開発体制の構築に向けた準備を進めることが推奨される。

Rustについて調査、理解したこと

Rustの強み：
メモリの扱いミスやスレッド間の競合をコンパイル時に防げること。

項目	C/C++	Rust
ダブルフリー	プログラマが注意して管理する必要がある	所有権システムによりコンパイル時に防止
Use After Free（解放済みメモリへのアクセス）	発生する可能性がある	安全なRustコードでは借用・所有権によりコンパイル時に防止
データ競合（Data Race）	発生する可能性がある	安全なRustコードではコンパイル時に防止
実行性能	高速	C/C++に近い高速性能

ポイント1: メモリの事故を防ぐことができる
たとえば、C/C++では「もう消したはずのデータをうっかり使ってしまう」というバグが起きることがあるが、Rustでは、データの所有者は1つだけという考え方があるので、こうしたミスをかなり減らせる。

ポイント2: 並列処理の事故を防ぐことができる
たとえば、2つの処理が同じデータを同時に書き換えると、結果が壊れることがある。
Rustは、そういうデータ競合が起きにくいように、コンパイル時にルールをチェックする。

ポイント3:
RustはJavaのようなGCを持たず、所有権システムによって不要になったメモリをスコープ終了時に自動解放する。そのためリアルタイム性が求められる車載ソフトウェアとも相性が良い。

具体例1. 所有権の移動

Rustでは、String のようなデータは「持ち主」（所有権を持つひと）が1人だけです。

たとえば次のコードでは、s1 の所有権が s2 に移動するので、s1 はもう使えない。

fn main() {
    let s1 = String::from("hello");
    let s2 = s1;

    println!("{}", s2);
    // println!("{}", s1); // エラー
}

この仕様のおかげで、C/C++で起きやすい「二重解放」や「使い終わったメモリの参照」を防ぎやすくなる。

Stringなどヒープ領域を所有する型では、変数にはヒープ領域へのポインタ・長さ・容量が保持される。
Copyを実装していないため、代入すると所有権がMoveする。

メモリイメージ：

スタック（main）
────────────────────────────
s1
+-------------------------+
|      無効（Moved）      |
+-------------------------+
※ 実際のメモリがゼロクリアされるわけではなく、Rustコンパイラがs1を以後利用できないと判断する。

s2
+-------------------------+
| ptr ───────────────┐    |
| len = 5            |    |
| cap = 5            |    |
+-------------------------+
                     │
                     ▼
ヒープ
────────────────────────────
+----------------+
| h e l l o      |
+----------------+

具体例2. 借用と参照

Rustでは、データを渡すときに「所有権を渡す」のではなく、借りることもできる。
種類としては不変借用と可変借用がある。

不変借用の例：

fn len(s: &String) -> usize {
    s.len()
}

fn main() {
    let s = String::from("hello");
    let n = len(&s);

    println!("{}", s);
    println!("{}", n);
}

実行結果：

hello
5

len関数は、sが所有しているStringを不変借用（読むだけ）して、その長さを取得している。

メリット：
・コピーしなくていいので効率がいい。
・関数に渡したあとも、元の変数をそのまま使える
・参照が生きている間、Rustが「そのデータを壊してはいけない」と保証してくれるので、事故が減る。

たとえば「ファイル名を渡して、その内容を読むだけ」のような処理では、わざわざ所有権を移さずに済むので、設計が楽になる。

メモリイメージ：

mainのスタック
─────────────────────
s
 ├ ptr ───────────────┐
 ├ len = 5            │
 └ cap = 5            │
                      │
n = 5                 │
                      │
                      ▼
ヒープ
─────────────────────
+----------------+
| h e l l o      |
+----------------+

C/C++での懸念

C/C++では、同じことをポインタや参照で表せますが、誰がいつ解放するかを人間が管理し続ける必要がある。

解放後に使ってしまう。
同じ領域を2回解放してしまう。
複数箇所から書き換えて、意図しない状態になる。

Rustの借用は、こうした問題をコンパイル時にBorrow Checkerによってチェックしている。
これにより、不要なコピーを避けながら、安全にデータを共有できる。

コンパイルエラーとなる実装例

fn main() {
    let mut x = 5;
    let rx = &mut x;
    let rx1 = &x;
    println!("{}", rx1); /*まだrxの借用が終わっていない*/
    println!("{}", rx);
}

→
ポイント：xの借用が重なっていないかどうか
xをrxが可変借用している間は、xに対して他の借用（不変借用・可変借用）は作れない。
rxによる借用が最後の使用で終了したあとなら、rx1はxを不変借用できる。

エラー内容：

error[E0502]: cannot borrow `x` as immutable because it is also borrowed as mutable
--> src/main.rs:6:15
5 | let rx = &mut x;
  | ------ mutable borrow occurs here
6 | let rx1 = &x;
  |               ^^ immutable borrow occurs here
7 | println!("{}", rx1);
8 | println!("{}", rx);
  | -- mutable borrow later used here
error: could not compile ...

ポイント：可変参照は同時に1つだけ
Rustでは、「読む人」（不変参照 (&)）と「書く人」（可変参照 (&mut)）が同時に存在しない
というルールをコンパイル時に保証します。
次のコードは、1つの変数を安全に変更する例です。

fn main() {
    let mut s = String::from("hello");
    let r = &mut s;
    r.push_str(" world");/* ここでrの借用は最後の使用になるので、以降はsを再び借用できる */

    println!("{}", s);
}

もし複数の場所から同時に書き換えできると、並列処理で壊れやすくなりますが、Rustはこのルールで事故を減らす。

Rustが向く場面

OS、組み込み、通信基盤など、止まると困るソフトウェア。
高速処理が必要で、かつバグを減らしたい場所。
C/C++資産をすべて捨てずに、新規部分だけ安全に作りたい場面。
→つまり、車載組み込みECUの世界と相性が良い！

さいごに

今回の講演を見てRustを調べてみて、
ClassicPlatformでよく使っているC/C++よりも安全性が高いため、
今後車載ソフトウェア開発者にとってRustは学ぶ価値のある言語になっていくと感じた。

ただ、すぐにすべてをRustへ置き換えるという話ではなく、
現状の資産も活用する必要があるため、
安全性が重要なアプリケーション層から段階的に導入される可能性が高いと感じた。
今後もAUTOSARの標準化動向を追いながら、Rustも継続して学んでいきたい。

参考(Vector発表のAI要約)

要約

本動画は、自動車産業におけるソフトウェア開発の複雑性と課題に対し、新たなプログラミング言語「Rust」を導入することの可能性と課題について解説している。自動車ソフトウェアは安全性、高ボリューム生産、分散システム、リアルタイム制御、規制対応といった多様な厳しい要件が重なり、高品質かつ効率的な開発は極めて困難である。Rustは高性能かつ高信頼性を特長とし、安全性やエラー処理の新機構により、従来のC/C++より開発効率やソフトウェア品質の向上が期待されている。

動画は、Rustによる技術的な利点（メモリとスレッド安全、エラーハンドリング、ゼロコスト抽象化、非同期処理、豊富なツール群）や現在の自動車業界での適用例、実用化に向けたハードウェアサポートやコードカバレッジツールの課題、既存プラットフォーム(Autosar)へのRust統合手法などを詳細に解説する。また、Rust導入によるコスト削減効果や、今後の展望についても示し、Rustは自動車ソフトウェアの将来を支える技術として期待されることを伝える。

この講演は、自動車ソフトウェア開発者や制御系エンジニア、ソフトウェア品質管理者、産業向けプログラミング言語に関心のある技術者に特に役立つ。視聴者はRustの特長、現状の課題、およびAutosar体系への融合可能性を理解でき、今後の自動車制御ソフトウェア開発に向けた技術選択・投資判断の参考情報を得られる。

タイムライン要約

00:00-00:54｜自動車ソフトウェア開発の課題と複雑性
自動車産業のソフト開発が航空機や鉄道並みの高安全性要求に加え、多数の車両への適用に伴う欠陥許容の低さ、コストプレッシャー、分散開発、厳しいリアルタイム制御、各国の規制対応を必要とすることが説明された。これら複数の矛盾する要件が開発難易度を高めている。

01:00-04:32｜Rustの選択理由と性能特徴
Rustはメモリ最適化とGC不要の高性能言語で、性能はC/C++に近い。型システムや所有権モデルにより高いメモリ・スレッド安全性をコンパイル時に保証し、バグを事前排除可能。ドキュメントやコンパイラの詳細なエラーメッセージによる生産性向上も強調した。

04:40-08:30｜Rustの普及状況と適用例
近年Rustの人気が上昇し、AWSやMicrosoft、Cloudflareなどインターネット大手やOSレベル（Windowsカーネル、Linuxカーネル）、モバイルOSでも採用が拡大中。自動車ではボルボと中国EVメーカーMiaが実用化初期段階にある。

08:30-13:55｜Rustの技術的利点（メモリ安全、エラー処理、抽象化、非同期処理、パッケージ管理）
C/C++のランタイムエラー例や例外処理問題がRustの型チェックや所有権モデル、例外なしの一貫したエラーハンドリングにより解決可能。ゼロコスト抽象化で効率を維持しつつ高度なシステムモデル化が可能。標準のビルド・パッケージ管理ツールCargoで開発効率向上。

14:00-18:30｜Rustによるコスト削減効果と品質向上
実務経験を基に実装で35％のコスト削減、静的・動的解析・コードレビューやテスト工数の大幅削減が見込まれ、ソフトウェア全体のライフサイクルで約20%のコスト削減を期待。高品質開発はデバッグ・保守工数も抑制。

18:30-23:10｜自動車分野向けのハードウェア・ツールの課題
多様なMCUアーキテクチャに対するRustコンパイラがまだ完全に対応していない。コードカバレッジはMC/DC対応ツール不足が大きな課題。ライブラリの安全認証も必要だが解決可能な問題。ソフトウェア複雑度指標（メトリクス）の整備もこれから。

23:10-30:20｜RustのAutosarプラットフォーム統合戦略
既存のC/C++製Autosar classic/adaptiveプラットフォームへは、アプリケーションレイヤにRust組込みを推奨。ClassicではRust-C間のAPI相互運用が容易だが、AdaptiveはC++の複雑性に対応するため中間Cレイヤを挟む。VectorのApplication FrameworkもMiddleware抽象化に利用可能。

30:20-33:15｜まとめと将来展望
Rustは自動車ソフトに最適な高効率・高信頼性言語として期待大。Autosar標準に準拠しつつRustを段階的に導入することで、信頼性と開発効率の大幅向上を狙う。課題はあるが技術成熟により将来性が高い。

33:15-41:45｜質疑応答（Rust適用範囲、Autosarの仕様変化、新規モジュール開発、シミュリンク連携など）
既存ベースソフトの完全Rust化は現時点で非現実的。クリティカルなアプリ層をRustで開発し統合する方針。RH850など特定MCUへのRustコンパイラ対応状況や、シミュリンクによるコード生成の安全性、AutosarのAPI仕様にRust対応予定は現時点でなし等の技術的質問が交わされた。

主要ポイント

🚗 自動車ソフトは多様な高要求で開発が極めて困難、安全性・高ボリューム生産・分散開発・リアルタイム制御が複雑化要因
🦀 RustはC/C++に近い性能かつメモリ安全を保証し、高信頼性を実現する新世代プログラミング言語
🔧 安全性チェックをコンパイル時に行い多くのバグを排除。エラー処理も一貫した仕組みで予測可能性向上
📈 RustはインターネットサービスやOSカーネルなど幅広く採用が進み、自動車でも初期導入が始まっている
💰 実装・解析・レビュー・テストで工数削減が見込まれ、車載全ライフサイクルで20%のコスト削減効果を期待
⚠️ 課題としてはMCUアーキテクチャへのコンパイラ対応、MC/DCカバレッジツール不足、ライブラリ認証などが挙げられる
🔄 Autosarとの共存戦略としてはRustアプリのアプリ層への組込み。Classicは直結可能、Adaptiveは中間Cレイヤで橋渡し
📚 Vectorは関連ツールやアプリケーションフレームワークを提供し、Rust導入を促進中
❓ 質疑応答で現実的な導入計画や仕様間の整合性、既存コードとの共存など具体的な検討事項が示された

よくある質問（FAQs）

Q: Rustはすぐに自動車ソフト全体に使えますか？
A: 現在はアプリケーション層の導入が中心で、ベースソフト全体のRust化は技術的・認証面で課題が大きく、将来的な展望として検討されています。

Q: 開発コストはどれくらい削減できますか？
A: 実装段階で約35%、ソフトのライフサイクル全体では約20%の工数・コスト削減が見込まれています。

Q: RustはどのようにAutosarプラットフォームに統合されますか？
A: ClassicプラットフォームはRust-Cアダプター経由で直接統合可能。AdaptiveはC++との複雑な関係から中間のCレイヤを挟む形で統合するのが現実的です。

Q: 現状Rustに対応したMCUコンパイラの状況は？
A: 一部のARMやChoリナーモデルではAOD資格付きコンパイラが提供されているが、Renesas RH850などのMCUではまだ未対応です。

Q: シミュリンクのコード生成と比較したときRustはどう活用されますか？
A: シミュリンク生成コードの安全性が十分であればRustの必要性は低いが、アプリケーションレベルでのコード開発や特定モジュールの信頼性向上にはRustの利用が有効です。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up