OEMフォーマットがバラバラ問題：マッピングの考え方｜兼務でも回る共通化手順

先に結論：まず“社内の正本”を決める

OEMフォーマットがバラバラでも、相手が求めている中身はだいたい同じです。ほぼ必ず出てくるのは次の項目です。

案件ID
対象製品
対象版数
影響あり / なし / 調査中
判断理由
証跡参照先
暫定対策 / 恒久対策
次回更新日
提出日 / 承認者

この 共通項目 を社内の「正本」として持っておけば、OEMごとの差は単なる「見せ方」の問題になります。逆に、社内の正本がなく、毎回OEM様式のExcelを開いてから書き始めると、同じ案件・同じ製品でも回答内容がブレてしまいます。

なぜOEMフォーマット対応で破綻するのか

現場でよく起きる失敗は、次の3つです。

1. 様式ごとに別々の情報を持ってしまう

A社向けはExcel、B社向けはWord、C社向けはポータル入力…と、それぞれ別ファイルで管理・修正してしまうと、どれが真の「最新の技術評価」なのか分からなくなります。

2. 同じ意味なのに別項目として扱ってしまう

例：「対象製品」「該当ECU」「対象システム」「該当モジュール」。OEMによって呼び方が違うだけで、社内ではほぼ同じ情報です。これを別物として管理しようとすると、転記漏れや矛盾が増えます。

3. フォーマット差ばかり見て、本質項目を整理していない

見た目が違うだけで、実際に聞かれているのは「何に影響するのか」「どう判断したのか」「次に何をするのか」です。ここを整理しないまま表面的な転記対応をすると、疲れるわりに回答の品質が安定しません。

マッピングの基本：3層で考える

OEMフォーマット対応は、次の「3層アーキテクチャ」で考えると整理しやすいです。

正本データ層

社内で唯一の正しい情報。
案件ごとに、対象版数、結論、理由、証跡、期限などをデータベース的に保持します。

マッピング定義層

変換ルール。
「社内項目Aは、OEM様式のどこに、どういう言葉で入れるか」を定義する表。これがあれば担当者が変わってもブレません。

提出版層

出力結果。
実際に相手へ出すExcel、PDF、ポータル入力内容。ここはあくまで出力結果であり、後から直接編集する場所ではありません。

この3層に分けると、将来OEMの様式が変わったり、新しいOEMが増えたりしても管理が壊れにくくなります。

まず作るべき：共通項目の一覧

最初に、社内で固定する“共通項目”（正本データ層）を決めます。最低限、次の項目があればどのOEM様式に対してもかなり戦えます。

社内共通項目	意味・説明
案件ID	社内で一意に追う番号
OEM名	提出先
対象製品	製品名
対象版数	暫定/確定を含む
対象箇所	ECU / 機能 / モジュール
結論	影響あり / なし / 調査中
判断理由	1〜3行程度で端的に
証跡ID	SBOM、構成表、試験結果などの参照先
暫定対策	ある場合
恒久対策	ある場合
次回更新日	調査中 / 継続案件に必須
承認者	外部送付責任者

この表が、社内正本の骨格になります。

比較表：OEMごとの差はどこに出るか

OEMごとの差分は、だいたい次の4種類に分類できます。

差分の種類	例	対応の考え方
項目名の違い	対象製品 / 対象ECU / 該当システム	社内共通項目へ寄せる
粒度の違い	製品単位 / ECU単位 / モジュール単位	社内は細かめ、提出は相手の必要粒度に落とす
結論表現の違い	影響あり・なし・調査中 vs Yes・No・Under Investigation	社内結論を相手の指定用語へ変換する
提出形式の違い	Excel / PDF / ポータル	出力方法・転記作業だけを変える

この表を見ると分かる通り、OEM差分の多くは「項目の意味」ではなく「表現と粒度」の違いです。だからこそ、正本を1つ持つ意味があります。

社内正本から各OEM向けの回答書を、自動的に出し分ける仕組みを見てみませんか？

OEM回答書作成の流れをデモで確認する

手順：兼務でも破綻しないマッピングの作り方

1OEM様式を分解する

まず、各OEMの様式を項目単位で分解します。「セルの位置」ではなく「聞いている意味」で見ます。
例：「対象製品」「影響有無」「理由」「対策」「証跡」「期限」など、本質的に何を聞かれているかを洗い出します。

2社内共通項目へ寄せる

OEMごとの項目を、先ほど作った「社内の共通項目」へ対応づけます。ここで「該当システム」も「対象ECU」も社内では「対象箇所」として扱う、といった名前の揺れを吸収します。

3粒度ルールを決める

社内では細かく持ち、提出時は必要粒度に丸めます。
例：社内では 製品名＋版数＋ECU＋モジュール まで特定していても、OEM提出時は 製品名＋版数＋対象箇所（大分類） に落として回答する、といったルールです。

4変換ルールを決める

表現の翻訳ルールを固定します。
・社内「影響なし」 → OEM様式「No」
・社内「調査中」 → OEM様式「Under Investigation」
・社内「証跡ID」 → 提出版では「別添文書名や参照先URL表現」へ

5マッピング表を残す

以下のようなマッピング定義表を1つ持つと非常に便利です。

社内項目	OEM A	OEM B	OEM C	備考
対象製品	製品名	該当システム	対象ECU	粒度変換あり
対象版数	SW version	Revision	Version	暫定/確定を含む
結論	Yes / No	影響有無	Status	調査中の表現差あり

これがあるだけで、「A社向けってここ何て書くんだっけ？」という担当者依存の迷いがかなり減ります。

実務でのコツ

1. 社内正本は“文章”ではなく“項目”で持つ
最初から文章（ベタ書きテキスト）で持ってしまうと、OEMごとの言い回しの差に引きずられます。要素を「項目」で持ち、最後に文面化する方が再利用しやすいです。
2. 提出版は上書きしない
提出用に変換した後のExcelなどを「正本」として更新してしまうと、後から社内データとの整合が取れなくなります。
3. 1回で完璧を目指さない
最初は、対応頻度の高い主要OEM 2〜3社だけでも十分です。よく使う様式からマッピングを始める方が現実的です。
4. 更新経路（OTA等）がある場合は別軸で持つ
対策の「配布方法」はOEMが特に気にするポイントです。回答様式ごとに表現が違うため、社内正本で「配布手段」という項目を独立させると後の処理が楽になります。

よくあるNG例

NG1：OEMごとに別管理
同じ脆弱性案件なのにOEMごとに回答のニュアンスが違う、どれが最新の技術評価か分からない、という重大な事故が起きます。
NG2：項目名に引きずられる
「対象ECU」と「対象システム」を別物扱いして別々のセルで管理してしまうと、無駄な二重管理になります。
NG3：証跡をセルにベタ書き
長い根拠テキストをExcelのセルに直書きするのではなく、証跡はIDやリンクで持ち、再利用・監査対応できるようにした方が安全です。
NG4：調査中の表現がOEMごとにバラバラ
社内では“調査中”の1ステータスに統一し、外向けに出力する時だけOEM指定の表現へ変換する方が圧倒的に安定します。

FAQ：マッピングの進め方

Q OEMフォーマットごとに別ファイルで管理しても大丈夫ですか？

A. 最終的な「提出版」として別ファイルになるのは構いませんが、「正本」まで別々にすると情報が崩壊します。社内正本は1つ（または1つのデータベース）にし、提出版だけをそこから派生させるのが安全です。

Q 項目の意味が微妙に違う場合はどうしますか？

A. まず社内共通項目に寄せ、そのうえでOEMごとの細かな差分や指定事項を「備考」に残します。表面的な項目名の違いよりも、意味の共通部分（コア）を優先して整理してください。

Q マッピング表は誰が持つ（管理する）べきですか？

A. 窓口機能（QA部門やPSIRTのフロント役）が持つのが現実的です。開発側（技術評価）は技術的な根拠作りに集中し、対外的な様式変換は窓口側が吸収する役割分担にすると安定します。

次に読む

OTAとは（アップデート経路と脆弱性）

OEMフォーマットがバラバラ問題：
マッピングの考え方
（兼務でも回る共通化手順）