OEMから突然来た調査依頼・監査対応 完全ガイド
（回答書・証跡・可用性/SLA管理）
「OEMから突然、調査依頼（アンケート／照会／質問票）が来た」
「監査の通知が来て、提出物が山ほどある」
「回答期限が短く、社内の誰に振ればいいか分からない」
Tier2〜Tier4のサプライヤーにとって、OEM調査依頼・監査対応は“ある日いきなり炎上する仕事”になりがちです。しかも、回答の良し悪しは技術力だけでは決まりません。
初動の速さ／回答書の型／証跡（エビデンス）の揃え方／期限（SLA）管理──この4点が揃って初めて「OEMが納得する回答」になります。
この記事では、兼務担当でも回るように、「初動→調査→回答書→証跡→是正・フォロー」の全体像を、実務の型としてまとめます。
この記事でわかること（忙しい人向け）
- OEM調査依頼と監査の違い、依頼が来る典型パターン
- 受領直後の初動（期限・範囲・提出物の確定）
- 社内タスクの振り分け（兼務でも破綻しないRACI）
- 回答書（提出物）の「OEMが読みやすい型」
- 証跡（エビデンス）を“後から集めない”ための設計
- 可用性／期限／SLAの捉え方と運用のコツ
- よくある失敗と、回避策
まず整理：OEMの「調査依頼」と「監査」は何が違う？
同じ“依頼”でも、対処の仕方が変わるので最初に整理します。
調査依頼（照会・質問票）
- 目的： 特定の懸念（脆弱性、SBOM、体制）について、短期で事実確認したい
- 特徴： 期限が短い／回答形式がバラバラ／追加質問が来る
- 成果物： 回答書（Excel/Word/フォーム）＋補足資料
監査（定期/臨時）
- 目的： サプライヤーの仕組みが「要求を満たす」かを、体系的に評価したい
- 特徴： 要求事項が多い／証跡の粒度が細かい／是正がセット
- 成果物： 監査チェックリスト回答＋証跡一式＋是正計画（CAPA）
調査依頼は“短距離走”、監査は“マラソン”です。
どちらも「回答書と証跡」が要ですが、設計の重点が違います。
全体像：OEM対応を「1本のフロー」にすると強くなる
現場が混乱する最大の理由は、「依頼ごとに毎回ゼロから対応」してしまうことです。そこで、どのOEMでも通用しやすい“標準フロー”に寄せます。
OEM調査依頼・監査対応の標準フロー（7ステップ）
- 受領・一次受付（チケット化／期限確認）
- 範囲確定（対象製品・対象版数・要求事項・提出形式）
- 社内振り分け（担当割り当て／RACI）
- 調査・事実確認（SBOM/構成/設計/運用/ログ）
- 回答書作成（結論→根拠→対応方針）
- 証跡（エビデンス）整理（添付・参照・保管）
- 提出・フォロー（追加質問／是正計画／再提出）
このフローを“毎回同じ型”で回すと、時間も品質も安定します。
Step1：受領した瞬間にやること（最重要は「期限」と「範囲」）
受領直後に確認すべきは、以下の5点です。ここが曖昧だと後で必ず手戻りします。
- 回答期限（いつまで）：暫定回答OKか／延長交渉の余地はあるか
- 対象範囲：製品名・型番・ソフト版数・出荷期間・顧客範囲
- 要求事項：何を答えれば“完了”か（Yes/Noで良いのか、証跡必須か）
- 提出形式：OEM指定Excel／PDF／ポータル入力／メール
- 連絡経路：質問先・窓口・CCルール（品質/調達/セキュリティ等）
ミニ豆知識：「いつまで」の意味は“回答期限”だけじゃない
OEMの期限には、実務上いくつかの種類が混在します。
- 受付期限：受領したことを返す（Acknowledgement）
- 一次回答期限：暫定でもよいので影響有無を返す
- 最終回答期限：証跡込みで確定回答を返す
- 是正期限：対策計画の提出や実施の期限
この区別を最初に押さえておくと、期限が短くても「何をどこまで出すか」を切り分けられます。
Step2：チケット化（“見える化”しないと必ず漏れる）
兼務体制で最初に導入すべきは、ツールではなくチケット化（タスク管理）です。メールで回すと「誰が何をどこまでやったか」が消えます。
チケットに必ず入れる項目（最小）
- OEM名／案件名／依頼種別（調査依頼or監査）
- 期限（受付／一次／最終／是正）
- 対象製品・対象バージョン
- 要求事項（質問票の添付リンク）
- 提出形式（Excel/ポータル等）
- 主管（最終責任者）／作業担当／レビュー（品質/上長）
- 証跡の保管場所（フォルダURLなど）
ポイント： チケットには「結論」より先に「期限と範囲」を固定します。調査が進んでも、期限と範囲が揺れると全てが崩れます。
Step3：社内振り分け（RACIで“兼務でも回る形”にする）
調査依頼・監査対応は、品質保証だけでも情シスだけでも完結しません。だからこそ、役割を先に固定します。
| 役割（RACI） | 担当部門の例（小規模サプライヤー） |
|---|---|
| R（実行） | 依頼内容に応じて設計 / ソフト / 品質 / 製造 |
| A（最終責任） | 品質保証（またはプロジェクト責任者） |
| C（相談） | 情シス / セキュリティ（兼務でOK） |
| I（共有） | 営業 / 調達（OEM窓口の場合が多い） |
“誰が最終的に署名して提出するか（A）”を必ず決めます。Aが曖昧なまま作業を始めると、最後の承認で止まります。
Step4：調査（事実確認）で集めるべき情報（最小セット）
依頼内容はOEMごとに違いますが、頻出情報は決まっています。
- 対象製品の構成情報
- ソフト構成（バージョン、ビルド、オプション）
- 主要コンポーネント一覧（OSS/商用/自社）
- 必要に応じてSBOMや簡易部品表
- 接続・到達性（攻撃成立性に直結）
- 外部IF（Bluetooth/Wi-Fi/USB/CAN/Ethernet等）
- 外部からの入力経路（診断、アップデート、通信）
- ネットワーク境界（閉域/ゲートウェイ有無）
- 運用・更新の情報
- 更新方法（現地/OTA/工場）
- 既知不具合の扱い（リリース手順、例外手順）
- ログ保全や解析の体制（可能な範囲で）
Step5：回答書（提出物）は「結論→根拠→対応方針」で作る
OEMが読みたいのは、長い説明ではなく “結論と次のアクション” です。回答書は、どのテーマでも基本構造を固定すると強くなります。
回答書の基本構造（コピペで使える）
- 結論（Yes / No / 調査中）
- 根拠（何を確認してそう判断したか）
- 対象範囲（製品名・版数・出荷範囲）
- 対応方針（対策有無・計画・次回更新日）
- 添付証跡（エビデンス）一覧
例：短い結論文のテンプレ
- 影響あり：「当該事象は対象製品に影響します。対策方針と暫定措置は以下の通りです。」
- 影響なし：「当該事象は対象製品に影響しません。判断根拠は以下の通りです。」
- 調査中：「現時点では影響有無を調査中です。一次回答として状況と次回更新日を提示します。」
Step6：証跡（エビデンス）を“後から集めない”設計
監査・調査依頼で一番時間を食うのが「証跡集め」です。後から集めるほど、「どの版数か分からない」「口頭確認で終わって再現できない」「担当者異動で消える」といった問題が起きます。
証跡（エビデンス）の種類（実務で多い順）
- 設計資料（IF仕様、構成図、設定値の根拠）
- 構成情報（SBOM/部品表/依存関係）
- 変更履歴（Git、チケット、リリースノート）
- テスト結果（該当機能の無効化確認など）
- 手順書（更新手順、例外手順）
- 体制資料（窓口、役割分担、教育記録）
ポイント：証跡は「全部添付」より “参照可能な形で整える” が現実的です。添付しない場合でも、証跡ID／保存場所／版数を回答書に残しておくと強いです。
Step7：提出・フォロー（追加質問と是正計画はセットで来る）
提出して終わりではありません。現実には「追加質問」「是正要求」「フォーマット差し替え」などが来ます。
ここで大事なのは、更新日（次回回答日）を最初から宣言することです。「いつまでに」「何を更新するか」を明示すると、追加質問のペースが落ちます。
付随論点：可用性/SLA管理が“監査の勝敗”を左右する
OEMが見ているのは、技術だけでなく “運用の可用性” です。
- 連絡が取れる窓口があるか
- 期限までに回答が返るか
- 調査中の案件が放置されないか
- 是正が期限どおりに進むか
この可用性は、結局 SLA（社内の目標時間） として運用に落ちます。最初から厳密な数値でなくても、まずは社内で“基準”を置くと安定します。
兼務体制でも置けるSLAの例（最小）
- 受領確認： 1営業日以内
- 一次回答（影響有無/調査中宣言）： 3〜5営業日
- 最終回答（証跡込み）： 10営業日（案件により調整）
- 是正計画： 2週間以内（監査の指摘内容で調整）
よくある失敗（ここだけ読めば事故が減る）
→ 受付／一次／最終／是正で分ける
→ 最初に対象版数を固定し、ブレる場合は“範囲拡張”として管理する
→ 何を確認したか（証跡）を短く添える
→ 証跡IDと保管場所を回答書に残す
→ 次回更新日を宣言し、更新サイクルでコントロールする
FAQ（OEM調査依頼・監査対応のやり方）
最初に「期限（受付/一次/最終/是正）」「対象範囲（製品名・版数）」「提出形式」を確定し、チケット化して担当を割り当てます。
違います。調査依頼は短期の事実確認、監査は仕組みの評価と是正まで含むため、証跡の量と粒度が増えます。ただし、どちらも「結論→根拠→対応方針」の回答書の型は共通です。
「調査中（一次回答）」を期限内に出し、次回更新日（いつ最終回答できるか）を宣言するのが現実的です。黙るより、状態と次回更新日を出す方が信頼が落ちにくいです。
設計資料、構成情報、変更履歴、テスト結果、手順書、体制資料など、判断の根拠を再現できる形で示す材料です。添付できない場合も、証跡IDと保管場所、版数を明記すると強いです。
最初に結論（Yes/No/調査中）を置き、根拠（何を確認したか）、対象範囲（版数）、対応方針（次回更新日含む）、証跡一覧の順でまとめると読みやすくなります。
必要です。OEMが見ているのは「運用が止まらないこと」です。受領確認、一次回答、最終回答、是正計画の目標時間を社内で置くだけでも安定します。
記事マップ：まとめ（このテーマを“面”で攻略する）
調査依頼・監査対応は、この記事1本だけだと現場で回しにくいので、テンプレ／チェックリスト／深掘り論点をセットで持つと強くなります。
OEMへの回答、毎回ゼロから作って消耗していませんか？
OEMから突然来た調査依頼・監査対応の進め方を自社向けに整理したい方は、無料相談をご利用ください。
Auto PSIRT Cloudなら、JASICガイドライン等に準拠したウィザードに答えるだけで、主要OEMの指定フォーマットに合わせた回答書を自動生成できます。