車載の“閉域”を理由にする時の注意点
（説明責任の作り方：CVE/トリアージ/VEX）
CVE対応で「車載は閉域ネットワークだから影響なし（not_affected）」と言いたくなる場面は多いです。実際、外部から到達できない構成なら“対応不要”に寄せられるケースもあります。
ただし「閉域」を“魔法の免罪符”として使うと、OEM照会・監査でほぼ確実に追加質問が来ます。相手が知りたいのは「閉域という言葉」ではなく、次の3点だからです。
- 境界： どこまでが閉域なのか（ECU単位？車内ネットワーク全体？）
- 到達性： 侵入口（通信/診断/工程）が本当に無いのか、前提は何か
- 再評価： 前提が変わったら（OTA導入/オプション追加/設定変更）どう見直すのか
閉域は“結論”ではなく“前提条件”
車載で言う「閉域」は多くの場合、「インターネットから直接到達しない」「車内ネットワークが物理的に分離されている」などを指します。
しかし、次の入口が1つでもあると 「閉域＝完全に到達不可」 とは言い切れません（＝説明が必要になります）。
つまりOEMに通る説明は「閉域です」で終わらず、
閉域“なので”成立しない条件を、境界・証跡つきで示す必要があります。
まず押さえる：OEMが“閉域主張”に突っ込む典型質問
「閉域だから影響なし」と返すと、だいたい次を聞かれます（先回りして書けば工数が減ります）。
- どのECU/どの機能が対象？（対象版数・搭載箇所）
- 入口は本当に無い？（診断/整備/OTA/近距離IFの扱い）
- 前提条件は？（機能OFF、認証ツールのみ、工場限定…）
- 前提が崩れたら？（再評価トリガーと責任者）
- 根拠はどこ？（参照できる証跡：図、仕様、設定、SBOM行など）
兼務でも破綻しない：閉域を理由にする時の手順（6ステップ）
ここから“やり方”です。閉域主張を説明責任に耐える形に落とします。
まず“対象版数”を切る（閉域以前の前提）
- SBOM/構成表で「当該コンポーネントが入っている製品・版数」を確定（暫定でも可）
- 対象版数が曖昧だと、閉域の議論以前に差し戻されます
閉域の“境界”を1行で定義する（ECU単位が基本）
→ “閉域”の意味を、対象ECU・接続・例外（診断など）まで含めて固定します。
到達経路チェック（4箱）で“入口”を潰す
最低限この4箱だけ埋めれば、説明の骨格になります。
“全部No”なら閉域主張は強い。Yesが混ざるなら、成立条件（権限、認証、手順、通常運用か例外運用か）を書き足します。
前提条件（“影響なし”が成立する条件）を明記する
閉域を理由に not_affected にするなら、前提条件を1〜2行で固定します。
- 「診断機能は出荷設定で無効。整備時のみ認証済みツールで有効化」
- 「当該機能は本製品構成ではビルドOFF（設定変更時は再評価）」
ここを書かずに「影響なし」を断言すると、後で前提が崩れて再炎上します。
VEX（結論）を“条件付き”で決める
- not_affected： 非搭載／到達性なし（閉域）を根拠に。ただし前提条件と証跡が必須
- under_investigation： 入口（診断/OTA等）の実態が未確認なら、結論を急がず更新日を付ける
- affected： 到達性があるなら、暫定対策と恒久対策へ（閉域は免罪符になりません）
成果物（説明責任セット）を残す
閉域主張で必要な成果物は、難しい報告書ではなく“3点セット”で十分です。
- 境界の根拠： 簡易ネットワーク図/IF一覧（機密は粒度を落として可）
- 前提の根拠： 設定値、仕様書該当箇所、整備手順の参照先
- 判断の根拠： 判定者、確認日、参照したSBOM行/構成表ID
再評価トリガー（ルール）を決める
「閉域だから影響なし」は“永久”ではありません。次が起きたら再評価、をルール化します。
- OTA導入・通信モジュール追加・スマホ連携追加
- 診断手順/サービスモードの変更
- 既定設定の変更（機能ON/OFF、認証方式変更）
- 顧客別派生やオプション構成の追加
判断を資産化する（追加質問と再調査を減らす）
閉域主張は「同じ説明を何度もする」になりがちです。決定理由をテンプレで固定すると、次回から早くなります。
OEMにそのまま貼れる：閉域を理由にする回答テンプレ（例）
使い方： メール/回答書に貼って【 】を埋めます。断定より“条件付きで説明できる形”が目的です。
自社製品の構成に合わせて「閉域」の回答方針や対応範囲を整理したい方はご相談ください。
【無料】オンライン相談を予約するFAQ：到達性・閉域の評価について
“閉域”だけの断定は避け、境界・到達経路・前提条件・証跡をセットで書けば通りやすくなります。
使えます。ただし「整備時のみ」「認証済みツールのみ」など成立条件を明記し、条件付きの not_affected にします。
次回更新日（SLA）と、未確定点（入口の実態、対象版数、前提条件）を明記することです。
機密を出しすぎる必要はありません。最低限「IF一覧（粒度を落として可）」「設定/手順の参照先」「SBOM行ID/構成表ID」の3点があれば監査で再現しやすくなります。
OTA/通信の追加、診断手順変更、既定設定変更、派生構成追加が代表的トリガーです。再評価ルールを決めておくと説明が強くなります。
「影響なし」の根拠説明、毎回手作業で書いていませんか？
Auto PSIRT Cloudなら、自社の製品構成（外部IFの有無など）をシステムに登録しておくだけで、AIがCVE情報から到達性を推測し、OEM提出用の「影響なし（条件・根拠付き）」レポートを自動生成します。