静的解析「初回100万件」からどう絞る？
車載Tier1の現場運用と「指摘ゼロ」文化

車載ソフトウェア開発のPM経験者が、最も消したい業務として挙げたのは「バグ対応」だった。理由はシンプルで、終わりが見えず精神的に辛いから。

市場で発生する不具合は再現が難しく、報告内容も曖昧になりがち。仮説を立てて再現条件を探り続けることになる。

特に量産後は、出荷台数が増えるほど問い合わせやクレームが増え、出荷直後の数ヶ月は集中しやすい。 さらに「ソフトのバグ」だけでなく、使い方やハード不良も混ざるため、切り分けと説明責任が重くなる。

インタビュー対象者の文脈では、Tier1としての開発は以下の流れが基本になる。

1. OEMからRFQ（開発要求）
2. 受注に向けた提案・システム構成の検討
3. 受注後に各領域（OS〜アプリ）で開発開始
4. 開発自体は半年〜2年規模になりうる
5. その後、評価・統合・量産準備フェーズが続く

この流れの中で、静的解析やルール準拠（MISRA等）は、開発フェーズだけでなく量産が近づくほど締め付けが強くなる。

静的解析（例：Coverity）をプロジェクトに後から入れる、または初回にフルで回すと、数十万〜100万件規模の指摘が出ることがある。

しかし、その大半は次の領域に由来する。

• OSや購入品（外部導入部位）
• 自動生成コード（GUI・モデルベース等）
• 下回り（プラットフォーム寄り）

大量指摘に対して現場が取る現実解は、対象外（除外）設定と逸脱（deviation）運用だ。

• OS・購入品は「供給元保証」の扱いで対象外にする
• 自動生成コードも対象外にする
• 解析ルールの適用範囲を最初に設計段階で決め、基本は途中変更しない

結果として、発言の示唆では：

• 99.99%は対象外になり得る
• 実際に修正が必要なのは0.01%〜0.1%程度
• それでも「直す件数」はプロジェクトによっては数百〜1000件規模になり得る

ここが、静的解析の「数字の罠」だ。初回の件数だけを見て意思決定すると、現実からズレる。

インタビュー対象者が最も強く語ったのは、リリース判断における価値観だ。

• 指摘ゼロでなければリリースしない
• 「何が何でもゼロにする」
• 指摘が残ると、最終盤にまとめて直す「合体」が発生しやすい
• 締め切り前は追加メンバー投入で対応することもある

運用としては、プロジェクト全体のビルドのタイミングに合わせて回す形が多い。

• 例：週1回、木曜昼にビルド
• フルビルド＋解析は3〜4時間かかることもある
• 結果は誰でも見られるようにしつつ、サマリーをExcelでメール配信
• 詳細はツール（Coverity）を見に行く運用

ただし、開発中は優先度が下がり、ほとんど減らない期間が続き、最後の最後で一気に直すという実態も語られている。

ルール違反をゼロにするためには、完全遵守だけでなく逸脱を管理してゼロにする必要が出る。

• 逸脱申請書（Excelテンプレ）を作る
• チームリーダーが技術レビュー
• 最終承認者が承認（リードタイムは短く、来たらすぐ見る）
• 管理はサーバに保存＋コミュニティにも記録（見つかりにくい工夫）

バグ対応が辛い理由は、技術だけではない。

• 市場から上がる情報は曖昧で、ログも十分でない
• 再現が難しく、数万回に1回の現象だと開発環境ではほぼ不可能
• FTA的に「起こり得る原因」を列挙して潰していく
• 顧客報告資料の作成と社内合意形成が重い

• 静的解析の定量ログを構造化して残す
  初回件数／対象外比率／修正件数／収束までの週数
• 「対象外設定・逸脱運用」の判断基準テンプレを作る
  監査・説明用
• バグ対応を減らすための市場ログ収集・再現手順を整備する
  再現できない前提で設計する

静的解析の運用を含め、サプライチェーンセキュリティ対策の現状を無料で診断できます。

本記事は以下の情報に基づいています:

• 車載ソフトウェア開発PM経験者へのインタビュー（2026年1月実施）
• ISO/SAE 21434:2021 Road vehicles — Cybersecurity engineering（ISO）
• UN R155 - Cyber security and cyber security management system（UNECE）
• Coverity Static Analysis（Synopsys）
• MISRA（Motor Industry Software Reliability Association）
• SEI CERT C Coding Standard（Carnegie Mellon University）