OEM照会で「影響あり」での回答：
暫定対策と恒久対策の切り分け
OEMからの調査依頼で、いちばん炎上しやすいのが 「影響あり」 の回答です。
なぜなら相手が本当に知りたいのは「影響あり/なし」ではなく、
- どの版まで影響するのか（対象版数）
- いま何ができるのか（暫定対策）
- いつ何で直るのか（恒久対策）
- いつまでに、誰が、何を返すのか（SLA/次回更新）
- 根拠（証跡）はどこか
だからです。
この記事では、影響ありの回答を 「暫定対策」と「恒久対策」に切り分け、さらに 手順（ステップ）×人物（立場・ルール）に落として、兼務でも回る“型”としてまとめます。
先に結論：影響あり回答は「2トラック＋更新日」で止まる
影響ありのときに最悪なのは、完璧な最終回答を狙って 沈黙→期限超過 することです。
正解は、最初から 2トラック で返すことです。
トラックA：暫定対策（Mitigation）
→ 今日できる止血（リスク低減）を提示する
トラックB：恒久対策（Remediation）
→ いつ何で直すか（版数・リリース計画）を提示する
必須：次回更新日（SLA）
→ “次にいつ確度が上がるか”を約束する
この3点が揃うと、OEM側は「運用が回っている」と判断でき、追加質問が減ります。
暫定対策と恒久対策の違い（混同すると炎上します）
暫定対策（Mitigation）とは
“攻撃が成立しにくい状態”に寄せる、当面の止血です。
- 問題機能の無効化（設定/ビルド条件/機能封じ）
- 外部IFの制限（アクセス制御、到達経路の遮断）
- 診断・デバッグ経路の封鎖
- 運用回避（特定操作の禁止、監視強化、限定運用）
重要：暫定対策は 「直った」ではなく「成立しにくい」です。だからこそ 前提条件（設定・環境）を明記します。
恒久対策（Remediation）とは
原因を除去し、再現しない状態にする本命です。
- パッチ適用、修正版リリース（バージョンで示す）
- 仕様変更、実装修正、ライブラリアップデート
- テスト完了、リリース承認、配布計画（いつ/どこへ）
重要：恒久対策は 「いつ・どの版で」が必須です。
OEMが「影響あり」で必ず聞く5点（これを先回りで書く）
影響あり回答で、相手の質問を先に埋めると炎上が止まります。
- 対象範囲： 製品名／対象版数（暫定→確定の履歴）
- 成立条件： 攻撃経路（外部IF/権限/条件）
- 暫定対策： いま可能な止血（やる/やらない、前提条件）
- 恒久対策： 修正版の計画（版数、予定日、配布方式）
- 運用： 次回更新日（SLA）＋証跡（参照先）
手順（ステップ）：影響ありを「一次回答→最終回答」で回す
ここから“やり方”です。影響ありは、回答を2段階に切り、まず期限を守って運用を安定させます。
Step1：受付・案件ID・期限（SLA）を確定
- OEM期限（相手期限）
- 自社SLA（受領／一次回答／最終回答）
- 次回更新日（調査中でも必ず）
Step2：対象版数を“暫定”で切る（確定まで待たない）
- 影響が疑われる製品と版数をまず仮置き
- “暫定の対象範囲”と明記する（後で更新）
Step3：暫定対策（できる/できない）を判断する
- できるなら、前提条件付きで提示
- できないなら、「できない理由」と「代替（監視/制限）」を提示
Step4：恒久対策の線表（いつ何を）を作る
- 修正方針（パッチ/更新/仕様変更）
- リリース予定（未確定なら “予定確度” と次回更新日を示す）
- 配布方式（工場/現地/OTA 等）
- 検証方法（更新後に何で確認するか）
Step5：証跡（根拠）を先に固定する
影響ありは後から突っ込まれます。最低限の証跡を“先に”揃えます。
- 対象版数の根拠（構成、SBOM、部品表）
- 暫定対策の根拠（設定値、手順、変更記録）
- 恒久対策の根拠（修正チケット、差分、テスト結果、リリース承認）
人物（立場・ルール）：影響ありは「承認ルール」が命
影響あり回答は、言い切りのリスクが高いので 承認線が必要 です。最小のRACI（役割分担）はこれで十分です。
| 受付/窓口（PSIRT） | 案件ID、期限、一次回答の送付 |
| 技術評価（設計/開発） | 対象版数、成立条件、対策案 |
| 品質/承認（QA/上長） | 対外文面の承認、提出可否判断 |
| リリース/生産（必要時） | 配布方式、スケジュール確定 |
※“兼務”でも良いですが、承認だけは別に置くと事故が減ります。
すぐ使える：影響あり一次回答テンプレ（暫定＋恒久）
使い方： OEM照会の回答欄/メールにそのまま貼り、【 】だけ埋めます。
影響ありの回答（暫定対策/恒久対策/証跡/SLA）を、自社の体制で回る形に整備したい方はご相談ください。
【無料】オンライン相談を予約するよくある失敗（影響ありで炎上する典型）
- 暫定対策を「直った」と書いてしまう（前提条件がない）
- 恒久対策の予定が曖昧で、次回更新日がない
- 対象版数が切れず、毎回追加質問で止まる
- 承認なしで対外発信し、後から社内で撤回になる
- 証跡が散らばって、監査で再現できない
FAQ：影響あり回答の書き方
最小は「結論（影響あり）」「対象範囲（暫定でも可）」「暫定対策の可否」「恒久対策の方針」「次回更新日（SLA）」です。確定情報を待って沈黙するより、一次回答で運用を回す方が評価されやすいです。
できます。その場合は「確度（高/中/低）」と「次回更新日」を必ず書いてください。“未定”のまま放置すると信用を落とします。
必須ではありません。ただし出せない場合は「出せない理由」と、代替のリスク低減（アクセス制限、監視強化、運用回避など）を示すと、追加質問が減ります。
「暫定範囲」と明記し、確定に必要な追加調査（構成確認、供給元確認等）と「次回更新日」をセットで書きます。対象版数が不明のまま“影響あり”だけ返すのは最悪手です。
現時点の想定（候補）を示し、確定時期（次回更新日）を明記します。更新の届け方は監査でも見られるため、方針があるだけで安心感が上がります。
影響ありの回答書も、AIで自動生成しませんか？
Auto PSIRT Cloudなら、影響ありの判定後、ウィザードに沿って暫定・恒久対策を入力するだけで、この「2トラック＋更新日」の型に沿ったOEM提出用レポートを自動生成します。