期限交渉の仕方
（関係を壊さない連絡文と“交渉の型”）
OEM調査依頼（脆弱性の影響有無、是正計画の提示など）は、期限（SLA）が短いほど“運用の出来”が露骨に評価されます。
一方で、兼務体制のTier2〜Tier4では「調査が想定より重い」「上流（サプライヤー）回答待ち」「検証環境が組めない」など、期限内に最終回答が出せない場面も現実に起きます。
このとき最悪なのは、
①黙る（返信が遅い） ／ ②雑に延長を頼む（理由が弱い） ／ ③期限を超える（信頼毀損）
のどれかです。
本記事では、関係を壊さずに期限合意を取りに行くための「手順（ステップ）」と「成果物（証跡・文面・ルール）」を、そのまま運用に落とせる型としてまとめます。
先に結論：期限交渉は「延長依頼」ではなく「合意形成」
期限交渉はお願いではありません。相手が欲しいのは「言い訳」ではなく、次の5点です。
- 受領： 依頼を理解し着手している
- 現状： どこまで分かったか（暫定でも良い）
- 不足情報： 何が足りなくて結論が出ないか（依存関係）
- 代替案： 期限内に出せる最小成果物 ＋ 延長後の最終成果物
- 次回更新日（SLA）： いつ何を更新するか
この5点が揃うと、「期限を伸ばしてほしい」ではなく、“この条件で進める”合意になります。
期限交渉が必要かの判断（交渉する／しないの基準）
まず、交渉の前に「交渉が必要な状況か」を切ります。
交渉すべきケース
＝延長合意を取りに行く
- 最終結論に必要な情報が外部依存（上流回答、ベンダー情報、工場工程の確認）
- 期限内に最終回答を出すと、誤回答リスクが高い（対象版数が切れない等）
- 期限内に“最低限の一次回答”はできる（受領＋暫定結論＋次回更新日）
交渉せず返すケース
＝期限内に（暫定でも）返す
- こちらの整理不足（担当未決、社内確認漏れ）
- 期限に間に合う見通しがあるのに、ただ余裕が欲しい
- 期限を超えると相手の工程（監査・出荷）が止まる可能性が高い
ポイントは、「忙しいから」ではなく、
品質（確度）と依存関係で判断することです。
兼務でも破綻しない：期限交渉の手順（6ステップ）
期限内に出せる“最小成果物”を先に決める
交渉は「全部できない」では通りません。期限内に出せる最小成果物を切ります。
- 受領（受付番号）
- 対象範囲（暫定でも可：製品名・版数レンジ）
- 現時点の暫定結論（影響あり/なし/調査中）
- 次回更新日（いつ確度が上がるか）
→ これが「交渉の土台」になります。
延長後に出す“最終成果物”を定義する
延長後のゴールが曖昧だと、相手は承諾できません。
・対象版数の確定
・到達性（成立条件）の確認結果
・対策方針（暫定/恒久）または影響なし根拠（証跡）
「遅れる理由」を“依存関係”として書く
良い理由は「調査の品質」を上げる理由です。悪い理由は「社内事情」です（言い訳化しない）。
- 良い： 上流ベンダーの影響有無確認待ち、構成差分の検証中、派生構成の棚卸し中
- 悪い： 担当不在、忙しい、調整が遅れている
提案は“二案提示”が最も通る
相手の選択肢を作ると合意が早いです。
- 案A： 期限内に一次回答（暫定結論＋次回更新日）、最終回答は○日
- 案B： 期限を○日延長し最終回答を一括提出（その代わり中間報告を○日に実施）
メール/文書は「短く、確実に」送る（テンプレ化する）
長文は読まれません。1通で通すには、構造を固定します（後述テンプレ）。
合意後に“証跡”を残し、期限管理表を更新する
合意が取れたら終わりではなく、再遅延が一番まずいです。
期限管理表に「合意した新期限」と「次回更新日」を反映し、社内のOwner/承認者も固定します。
コピペで使える：関係を壊さない期限交渉メール（日本語テンプレ）
使い方： 最短で送るなら、このまま貼って【 】だけ埋めてください。
期限交渉メール（二案提示型）
NGになりやすい言い回し（避ける）
- × 「忙しくて間に合いません」
- × 「確認中です（次回更新日なし）」
- × 「閉域なので影響ないと思います（根拠なし）」
→ 代わりに、「依存関係」「確度」「次回更新日」をセットで伝えます。
自社の体制に合わせて、OEM調査依頼・監査対応のSLA（期限管理）や進め方を整理したい方はご相談ください。
【無料】オンライン相談を予約するよくある落とし穴：期限交渉が“信用毀損”になるパターン
- 期限当日に初めて連絡する（相手の工程を止めてしまう）
- 延長後のゴールが曖昧（結局いつ終わるか相手に分からない）
- 次回更新日を守らない（再遅延＝最悪のケース）
- 合意の証跡が残っていない（後で「言った言わない」になる）
交渉は「1回で終わらせる」設計が重要です。
期限管理表と更新ルールをセットにしてください。
FAQ：SLA管理・期限交渉のやり方
遅れる可能性が見えた時点で、期限より前に送るのが原則です。少なくとも「期限当日」は避け、一次回答（暫定結論＋次回更新日）を期限内に返す設計にします。
できます。むしろ「受領＋未確定点＋次回更新日」があれば運用として成立します。沈黙が一番まずいです。
「上流回答待ち」「対象版数の確定に検証が必要」「派生構成の棚卸しが必要」など、確度（品質）を担保するための依存関係が通りやすいです。
“最終回答までの最短”ではなく、中間報告（次回更新日）を挟んだ現実的な日程にします。二案提示（一次回答＋最終回答 or 一括＋中間報告）が合意されやすいです。
タスク管理とSLAアラートを、システムに任せませんか？
Auto PSIRT Cloudなら、OEMからの期限（SLA）や次回更新日をダッシュボードで可視化。期限が近づくとアラートが出るため、「気づいたら過ぎていた」という事故をシステムで防ぎ、回答書も自動生成できます。