MISRA Cガイド — 自動車ソフトウェアコーディング規格の全て

MISRA C、なぜ自動車開発者にとって避けられないのか

自動車ソフトウェア開発をしていると、MISRA Cという名前を聞かないわけにはいきません。コードレビューで、静的解析ツールの設定で、OEM納品要件で — どこでも登場します。正直に言えば、初めて接すると「なぜこんなにルールが多いのか？」という思いが先に立ちます。225個のガイドラインとは、負担に感じるのは当然です。

MISRA CはMotor Industry Software Reliability Associationが策定したC言語コーディングガイドラインです。1998年に初版が発表され、本来の目的は明確です。C言語が持つ曖昧な動作（undefined behavior）、実装依存の動作（implementation-defined behavior）を避けて、安全で移植性の高いコードを書こうというものです。

C言語はプログラマーに非常に大きな自由度を与えます。しかし、その自由度がそのままリスクとなります。評価順序が定義されていない式、境界チェックのないポインタ演算、データを静かに切り捨てる暗黙の型変換 — 一般アプリケーションでは見過ごせる問題が、自動車では致命的です。

自動車ECUに搭載されるソフトウェアは人命に直結します。ブレーキ制御、エアバッグ展開、操舵補助 — これらの機能のソフトウェアでundefined behaviorが発生したらどうなるでしょうか？ブレーキングアルゴリズムの微妙な整数オーバーフロー、エアバッグコントローラの初期化されていない変数 — これらが実際の事故につながり得ます。そのためMISRA Cは自動車業界で事実上必須のコーディング標準となり、航空、医療機器、鉄道分野にまで拡大しました。

MISRA Cの歴史：1998から2025まで

MISRA Cの発展過程を知ると、現在のバージョンの理解に役立ちます。

MISRA-C:1998 — 始まり

最初のバージョンです。C90（ANSI C）をベースに127個のルールを定義しました。自動車業界でC言語コーディング標準の必要性を公式化した最初の試みでした。

MISRA-C:2004 — 体系化

142個のルールに拡張され、ルール分類体系が整理されました。Required（必須）とAdvisory（推奨）に分けられ、自動車業界を超えて航空、医療、鉄道など安全関連産業に拡大し始めました。

MISRA C:2012 — 現代化

143個のルールと16個のディレクティブ（Directive）で構成されました。C99サポートが追加され、ルール分類がMandatory（絶対必須）、Required（必須）、Advisory（推奨）の3段階に細分化されました。ルールとディレクティブを分離したことが大きな変化です。ディレクティブは静的解析ツールだけでは自動検証が困難な、開発プロセスレベルのガイドラインです。

MISRA C:2023 — C11/C18統合

MISRA C:2012の第3エディション（second revision）として、これまでに発行されたすべてのAmendmentとTechnical Corrigendumを一つに統合したロールアップバージョンです。約200個のルールと21個のディレクティブ、計221個のガイドラインを含みます。C90、C99に加えてC11/C18までサポート範囲を拡大しました。

特にAmendment 4（AMD4）で追加されたマルチスレッド関連ルール（Rules 22.11〜22.20）とatomic演算ルールが重要です。マルチコアプロセッサが普及した自動車ECU環境で、並行性に関するコーディング標準がようやく公式化されたのです。

MISRA C:2025 — 最新バージョン

2025年にリリースされた最新バージョンです。4つの新しいルールが追加され2つが削除され、合計約225個のアクティブなガイドラインを含みます。

実務的に最も注目すべき変更が2つあります。第一に、長年議論のあった「single point of exit」ルールがdisapplied（非適用）処理されました。関数でreturnを一つだけ使うべきというルールですが、現実的にコードの可読性を低下させるケースが多く、実務者から反発がありました。第二に、AIが生成したコードも人が書いたコードと同一の基準で扱うという方針が明記されました。AIコーディングツールの使用増加を反映したものです。

ルール分類：Mandatory、Required、Advisory

MISRA Cのルールは3つの等級に分かれます。この分類を理解することが実務適用の第一歩です。

Mandatory（絶対必須）

いかなる状況でも必ず遵守しなければなりません。偏差（deviation）も許容されません。undefined behaviorを直接的に引き起こすコードパターンを禁止するルールがここに該当します。数は少ないですが、絶対に違反してはなりません。

Required（必須）

原則として遵守すべきですが、正当な理由があれば偏差を文書化して例外処理できます。大部分のルールがこの等級です。核心は「偏差を認めるが必ず記録せよ」ということです。なぜこのルールに違反したのか、違反によるリスクは何か、どのような代替措置を取ったかを文書に残す必要があります。

Advisory（推奨）

良いコーディング慣行として推奨されますが、遵守が強制されるわけではありません。ただし、プロジェクト方針によってAdvisoryをRequiredに格上げする場合もあるため、プロジェクト別のMISRA準拠ポリシーを確認する必要があります。

実務で直面する問題は別にある

MISRA Cの概念を理解することと、実際のプロジェクトに適用することはまったく別の話です。現実的に直面する問題を見ていきましょう。

レガシーコードとの衝突

新規プロジェクトでは最初からMISRA Cを適用できますが、問題は既存コードです。数万行、数十万行のレガシーコードにMISRA Cを遡及適用すると、違反事項が数千件も出てきます。すべてを修正するのはスケジュール上不可能で、どこから手をつけるべきか優先順位を決めること自体が大きな作業です。現実的にはリスクベースのアプローチが必要です。Mandatory違反から対処し、安全関連モジュールのRequired違反を次の優先順位とするといった方法です。

静的解析ツール間の差異

同じMISRA Cルールでも、静的解析ツールごとに検出結果が異なります。Aツールでは違反として検出されるパターンがBツールでは通過することもあります。ツールごとにルール解釈範囲と検出方式が異なるためです。OEMが特定ツールを指定するケースもあり、ツール選定と設定が重要です。プロジェクト初期にツールのベースラインを明確に設定しておかないと、最終納品直前のコンプライアンス監査で予期せぬ問題が発生します。

ディレクティブの曖昧さ

ルール（Rule）は比較的明確です。「このようなコードを書くな」と具体的に定義されているからです。一方、ディレクティブ（Directive）は「動的メモリ割り当てを使用するな」「アセンブリコードをカプセル化せよ」のようにプロセスレベルのガイドラインなので解釈の余地があります。チーム内でディレクティブの解釈を統一する作業が必要です。

偏差管理の負担

Requiredルールに違反するたびに偏差記録（Deviation Record）を作成する必要があります。規模の大きいプロジェクトでは数百件の偏差を管理しなければならず、それ自体がかなりの工数となります。

MISRA C++:2023 — C++開発者も知っておくべきこと

C++で自動車ソフトウェアを開発するケースも増えています。2023年10月、MISRA C++:2023がリリースされました。既存のMISRA C++ 2008とAUTOSAR C++14ガイドラインを統合し、C++17をターゲットとして179個のルールを定義しています。

以前はMISRA C++ 2008とAUTOSAR C++14が別々に存在し、どちらに従うべきか混乱がありましたが、MISRA C++:2023がこれを一つに整理しました。C++17の主要機能（structured bindings、std::optional、if constexprなど）に対するガイドラインが含まれており、最新のC++文法を活用しながらも安全なコードを書くことができます。

ISO 26262とMISRA Cの関係

ISO 26262（機能安全国際標準）は、コーディング段階で適切なコーディングガイドラインの使用を要求しています。ISO 26262 Part 6、Table 1ではASIL（Automotive Safety Integrity Level）に応じてコーディング標準の適用を推奨しており、MISRA Cがこの要求事項を事実上満たす代表的なコーディング標準です。

つまり、ISO 26262認証を受けるにはMISRA C（または同等レベルのコーディング標準）を適用したことを証明する必要があります。ASPICE CL2以上を要求するOEMは、ほぼ例外なくMISRA C遵守も併せて要求します。2つの標準は相互補完的です。ASPICEが開発プロセスの品質を保証するなら、MISRA Cはコードレベルの安全規律を保証します。両方を備えてこそOEM納品要件を満たすことができます。

AI時代のMISRA C適用

2025〜2026年現在、自動車ソフトウェア開発へのAIツール活用が急速に拡大しています。コード生成、コードリファクタリング、静的解析結果の自動修正などにAIが適用されていますが、ここで重要な問いが浮上します。AIが生成したコードもMISRA Cを遵守すべきか？

MISRA C:2025で明確に答えが出されました。AIが生成したコードであれ人が書いたコードであれ、同一のルールを適用します。コードの出所ではなくコード自体の品質が重要だということです。

この方針は実務的に2つのことを意味します。第一に、AIコーディングツールを使用してもMISRA C検証プロセスはそのまま維持しなければなりません。第二に、AIツールが最初からMISRA Cを遵守したコードを生成できれば、検証負担が大幅に軽減されます。

PARVIS-Coder：AIによるMISRA C自動適用

PopcornSARのPARVIS-Coderはまさにこの問題を解決します。AIベースのコードリファクタリングを通じて、MISRA Cルールを自動的に適用するツールです。

実際のプロジェクトでMISRA C準拠率を40%から94%に引き上げた実績があります。既存のレガシーコードにMISRA Cを遡及適用する際、手動では数週間から数ヶ月かかる作業をAIが自動で処理します。もちろん自動修正結果はエンジニアがレビューする必要がありますが、初期修正作業の工数が大幅に削減されます。

PARVIS-VerifyはMISRA C遵守を考慮したテストコードを自動生成し、PAIOは開発環境でコーディングルール検査を統合提供します。設計段階から検証までMISRA C遵守を一貫して維持できる環境です。

MISRA Cの適用や自動化ツールについて詳しく知りたい場合は、PARVIS製品ページで詳細をご確認いただくか、お問い合わせからお気軽にご相談ください。