炎上対応の判断経緯を残す方法｜第一報・削除・謝罪・承認を記録

監修: 菊地 将（リブランディング株式会社）

炎上対応を後から振り返るとき、第一報を出した、投稿を削除した、謝罪を見送った、といった結果だけが残っていても、その判断が妥当だったかは検証できません。

検証に必要なのは、「その時点で何が分かっていて、何を根拠に、誰が、いつ決めたか」という経緯です。判断ログには、判断時刻、確認済みの事実、未確認情報、選択肢、採用理由、承認者、次に見直す条件まで残します。

この記事では、炎上進行中にそのまま使える判断ログの項目、第一報・削除・謝罪・承認を記録する方法、判断が変わったときの更新ルールを順に整理します。

判断ログをどの局面で使うのかを炎上対応全体から確認したい場合は、企業の炎上・風評被害対応（https://rebranding.co.jp/media/online-reputation-crisis-response/）の解説も参照してください。

炎上対応の判断ログは「対応履歴」ではなく「意思決定の証跡」

この節では、判断ログが単なる対応履歴とどう違うのかを確認します。炎上対応の判断ログは、「10時に会議をした」「11時に投稿を削除した」と並べた時系列表ではありません。

対応履歴は「何をしたか」を残す記録です。判断ログでは、その時点の事実・選択肢・根拠・承認者まで記録します。違いを図にまとめると、次のとおりです。

重要なのは、その判断をした時点で利用できた情報と、判断理由を一緒に残すことです。

たとえば問題投稿を削除した場合、次の内容まで残っていなければ、後から「なぜ削除したのか」を正確に再現できません。

• 何時に問題を認識したか
• 削除前に何を確認したか
• 残す選択肢も検討したか
• 削除による二次炎上リスクをどう評価したか
• 法務・広報・経営の誰が承認したか

この考え方は、海外の公的機関の指針にも見られます。英国National Cyber Security Centre（NCSC）は、重大なインシデント対応について、単一の正式記録に「何が判明したか」「いつ判明したか」「誰が、なぜ判断したか」「合意した行動と進捗」を残すことを案内しています。時刻表記の統一や、専任の記録担当者を置くことも推奨しています。 (ncsc.gov.uk)

炎上はサイバーインシデントとは異なりますが、情報が刻々と変化し、不完全な情報から重要判断を求められる点は共通します。そのため広報・危機管理でも、チャットや会議の断片を後から集めるのではなく、一つの判断ログを正本として更新する方法が有効だと考えます。

炎上判断ログに最低限残す9項目

判断ログを複雑にしすぎると、緊急時に誰も書かなくなります。そこで、まず最低限の項目に絞ります。次の9項目を、1判断1行または1レコードで残してください。

項目	記録する内容
判断ID	D-001、D-002などの通し番号
判断時刻	判断が確定した日時
判断事項	第一報、削除、謝罪、取材対応など
確認済み事実	判断時点で裏付けが取れていた情報
未確認情報	まだ確認できていない情報
選択肢	実行・保留・別対応など検討した案
判断・根拠	採用した案と、その理由
判断者・承認者	起案者、最終承認者、必要な専門確認
再評価条件	何が変わったら判断を見直すか

表の9項目は、4つのまとまりに分けて読めます。判断を特定する項目（判断ID・判断時刻・判断事項）、判断の材料（確認済み事実・未確認情報・選択肢）、決めた内容と責任（判断・根拠、判断者・承認者）、見直しの条件（再評価条件）です。結果だけでなく「判断した時点の情報」まで残しておくと、後から意思決定を追跡しやすくなります。

9項目を図にまとめると、次のとおりです。

9項目のうち特に重要なのが、「未確認情報」と「選ばなかった選択肢」です。

後から結果を知った状態では、「その判断しかなかった」と考えやすくなります。しかし実際の炎上対応では、判断時点では複数の可能性が残っています。

英国政府のCritical Incident Management指針でも、危機時の判断について、判断理由だけでなく、その時点の裏付け情報や検討した選択肢・代替策を記録することが示されています。 (gov.uk)

判断ログは「事実」「推測」「判断」を混ぜない

炎上初期は、確定した事実とSNS上の主張が混ざりやすい時期です。その状態で「炎上原因は○○だった」とログに書くと、後から情報が覆ったときに、何を根拠に意思決定したのか分からなくなります。

そこで、次の3つを分けて記録してください。以下は仮想の記載例です。

区分	例
確認済み事実	9:42に公式Xから対象投稿が公開された
未確認・仮説	元データの確認前であり、数値誤りかは未確定
判断	訂正要否が確定するまで削除せず、追加拡散のみ監視する

この例では、公開された事実は「確認済み事実」に、数値誤りかどうかは「未確認・仮説」に入れています。そのうえで、確認できた範囲だけを根拠に「判断」を書いています。

この3つを分ける理由は、判断する人の側にもあります。危機時は、専門家であっても認知バイアス（思い込みによる判断の偏り）の影響を完全には避けられません。

2022年に公表された危機意思決定に関する研究では、一般参加者460人、政府・非営利組織関係者50人、危機対応専門家21人を対象に実験を行い、専門家群でもアンカリング、フレーミング、バイアス・ブラインドスポットの影響が確認されました。 (research.tudelft.nl)

だからこそ、「正しかったか」だけでなく、判断時点で何が分かっていたかを固定することに意味があります。

第一報を出す判断は「出した理由」と「まだ言わないこと」を残す

第一報は、炎上対応で最初に大きな承認が必要になりやすい判断です。ログには「第一報を出す」とだけ書かず、次のように残します。以下も仮想の記載例です。

項目	記録例
判断事項	第一報を公式サイトとXで公開する
確認済み事実	対象投稿、投稿日時、当社公式アカウントからの投稿であること
未確認情報	投稿作成経緯、社内承認経路
選択肢A	事実確認完了まで発信しない
選択肢B	調査中であることのみ第一報する
採用	選択肢B
根拠	問い合わせが増えており、沈黙による情報混乱を避けるため
承認者	広報責任者、担当役員
再評価	事実認定完了時、報道問い合わせ発生時

この例では、選択肢Aと選択肢Bを並べたうえで、採用した案とその根拠を分けて書いています。承認者と再評価の条件まで入っているため、後から「なぜ調査中であることのみを伝えたのか」を追えます。

第一報で重要なのは、まだ分かっていないことまで説明しようとしないことです。判断ログにも「現時点では原因を断定しない」「謝罪対象の特定は次回判断」といった今回決めていないことを残すと、その後の声明との整合性を取りやすくなります。

投稿削除の判断は削除前の証拠保全とセットで記録する

炎上した投稿を削除する場合は、削除ボタンを押した時刻だけを残してはいけません。削除すると、後から投稿の内容や反応を確認できなくなるためです。削除前に少なくとも次の内容を保存したうえで、削除判断を記録します。

• 投稿本文
• 投稿URL
• 投稿日時
• 画像・動画
• 主要な反応
• 必要に応じて表示回数など確認可能な数値

保全ができたら、削除理由を具体的に書きます。「炎上しているため削除」では不十分です。「個人情報が掲載されており、公開継続による被害拡大を防ぐ必要があるため」「掲載数値が公式資料と異なることを確認したため」など、判断の前提となった事実まで記録してください。

削除しない場合も同様です。「批判が増えているが、現時点で内容の誤りを確認できていないため削除しない」と記録すれば、何もしなかったのではなく、検討した結果として維持したことが分かります。

謝罪するかどうかは「炎上規模」ではなく事実認定から記録する

批判が多いから謝罪する、少ないから謝罪しない、という決め方では判断根拠が残りません。判断ログでは、最初に「何について自社の責任を認定したのか」を明確にします。

たとえば、次の順番で書きます（仮想の記載例）。

• 確認済み事実：広告画像に第三者の著作物が無許可で含まれていた。
• 判断対象：会社として謝罪声明を出すか。
• 採用案：対象投稿を削除し、事実・謝罪・現在の対応を公表する。
• 判断理由：自社側の権利確認不足が確認できており、謝罪対象を具体的に特定できるため。

この例では、確認できた事実（第三者の著作物の無許可使用）を先に置き、判断対象、採用案、判断理由の順につないでいます。炎上の規模ではなく、認定した事実から謝罪の判断を説明できる形です。

反対に、事実関係が確認できていない場合は、単に「謝罪をしない」と書くのではなく、「現段階では責任範囲が未確定のため、謝罪判断を保留。事実確認完了後に再判断」と記録します。

判断を「実施／不実施」の二択にせず、情報不足による保留と、新しい事実が出たときの再評価を正式な判断として扱うことがポイントです。流れは次の図のとおりで、新しい事実が出たら再評価に戻ります。

承認履歴は「誰が見たか」ではなく「誰が何を承認したか」を残す

炎上対応では、SlackやTeams、メールに「OKです」「これでお願いします」という承認が散らばりがちです。これでは後から、次の3点が分かりません。

• どの原稿を承認したのか
• 何時点の情報で承認したのか
• 法務確認なのか経営判断なのか

そこで、承認は判断ログ側で確定させます。次の表は、第一報の承認を時系列で記録した仮想の例です。

時刻	対象	確認者	確認内容	結果
13:05	第一報案v2	法務	法的表現	修正条件付き承認
13:18	第一報案v3	広報責任者	発信内容	承認
13:26	第一報案v3	担当役員	公開判断	公開承認
13:31	公式サイト	広報担当	公開実行	完了

この例では、法務の確認、広報責任者の承認、担当役員の公開承認が、対象の版（第一報案v2、v3）と時刻つきで並び、最後の行に公開の実行が別に記録されています。承認と実行が別の行になっているため、どの版を誰が承認して公開したのかを追えます。

なお、「承認者一覧」と「判断ログ」は別物です。承認者一覧は誰に権限があるかを事前に決めるもので、その事案で実際に何を承認したかまでは残りません。

新しい情報が出たら過去ログを書き換えず、新しい判断を追加する

炎上対応では、数時間後に新しい事実が判明し、最初の判断を変更することがあります。その場合も、最初のログを正しい内容に書き換えてはいけません。次のように、新しい判断として追加します。

• D-004：投稿を維持する
• D-009：新事実判明により投稿を削除する

判断が変わっても過去ログは修正しません。新しい情報と新しい判断を別レコードとして追加することで、その時点の意思決定を後から再現できます。D-004が後から見れば誤った判断だったとしても、その時点で利用できた情報からどう判断したかを残すことに価値があります。

判断時点の情報を残す意義は、後知恵バイアスの面からも説明できます。過去の意思決定を結果に合わせて再構成してしまう現象は「後知恵バイアス」と呼ばれます。

1987年の研究では、事前に考えていた理由などの記録を後から参照できた条件で、後知恵バイアスが小さくなった実験結果が報告されています。すべての条件で同じ効果が確認されたわけではありませんが、判断時点の情報を残す意義を考えるうえで参考になります。 (sciencedirect.com)

炎上進行中に使える判断ログのテンプレート

ここまでの項目を実務で使いやすい形にまとめたのが、次のテンプレートです。スプレッドシート、社内Wiki、インシデント管理ツールなどに用意しておくと運用しやすくなります。

項目	記入内容
判断ID	D-001
判断日時	YYYY/MM/DD HH:MM
判断事項	何を決めるのか
状況	その時点の状況
確認済み事実	裏付け済み情報
未確認情報	調査中の事項
選択肢	A、B、C
採用した判断	実際に選んだ対応
判断理由	なぜその案を選んだか
不採用理由	他案を選ばなかった理由
起案者	判断案を出した人
専門確認	法務・セキュリティ等
最終承認者	決裁した人
実行担当	実際に対応する人
実行期限	いつまでか
再評価条件	新事実、報道、拡散増加など
関連資料	スクリーンショット、原稿、会議記録等

テンプレートは17項目ありますが、すべての判断で17項目を埋める必要はありません。

ただし、第一報、削除、訂正、謝罪、取材回答、法的措置、通常投稿の再開など、外部への影響が大きい判断では詳細を残してください。

判断ログと対応タスクは分けて管理する

判断ログとタスクリストを一緒にすると、重要判断が大量の作業記録に埋もれます。両者は、何を記録するかで区別できます。

たとえば「声明文をサイトへ掲載すると決定した」は判断ログです。一方、「CMSへログインする」「画像を差し替える」「XへURLを投稿する」は実行タスクです。

判断ログはなぜ決めたかを残す場所、タスク管理は決めたことを誰が実行するかを追う場所と分けます。

なお、NCSCは、中央記録に「判断」と「合意したアクション、その進捗」の双方を残す考え方を示しています。 (ncsc.gov.uk)

NCSCの案内は両者を一つの記録に置いていますが、判断の理由と実行状況を別の項目として残す点は、ここで説明した分け方と同じ方向だと考えます。

炎上収束後のポストモーテムは、判断ログを時系列に並べて行う

炎上が収束した後は、ポストモーテム（事後検証）として、記憶だけを頼りに振り返るのではなく、判断ログを時系列に並べて検証します。確認するのは「誰が悪かったか」ではありません。次の点を確認します。

• その時点の情報で判断は妥当だったか
• 必要な情報が意思決定者まで届いていたか
• 承認に時間がかかった箇所はどこか
• 不要な承認がなかったか
• 見直し条件は適切だったか
• 同じ事案なら次回は何を事前ルール化できるか

ISO 22361:2022は、危機管理能力の要素として、危機時の意思決定、危機コミュニケーション、訓練・検証・危機からの学習を扱っています。 (iso.org)

この規格の考え方からも、判断ログは事後報告書を作るためだけの記録ではないと考えます。次回の危機対応で、より早く、より根拠のある判断をするための組織の資産になります。

まとめ

炎上対応の判断ログでは、「何をしたか」だけでなく、その時点で何が分かっていて、どの選択肢を比較し、誰が何を根拠に決めたかを残してください。

最低限必要なのは、判断ID、判断時刻、判断事項、確認済み事実、未確認情報、選択肢、判断・根拠、判断者・承認者、再評価条件の9項目です。第一報、削除、謝罪、声明公開などの重要判断は、承認の記録も含めて一つの正式なログで管理します。

新しい情報によって判断を変更するときも過去ログは書き換えず、新しい判断として追加します。こうしておけば、炎上収束後に記憶から経緯を復元する必要がありません。

「誰が決めるか」を事前に決める承認者一覧と、「実際に何を根拠に決めたか」を残す判断ログを両方整えることで、危機対応を属人的な経験から再現可能な運用へ変えられます。最初の一歩として、9項目の表をスプレッドシートや社内Wikiに用意し、次に判断が必要になったときに最初の判断をD-001として記録してみてください。

参考文献・データ元

‹ 親記事: 企業の炎上・風評被害対応とは｜初動対応の原則から法的手段・社内体制までの全体像

関連記事

• › Yahoo!検索で風評被害が起きる原因とは？検索候補・関連検索ワードへの対策
• › 【SNSで自爆】バイトテロとは？有名な事例一覧と企業が受けた損害額まとめ
• › 【ジャングリア】沖縄テーマパークの口コミ炎上から学ぶ風評被害のリスク
• › 教えて!gooはサービス終了｜過去の投稿や検索結果が残る場合の対処法
• › 企業向けSNS研修とは？社員教育で扱うべき炎上・情報漏えい・投稿ルール
• › 社員・元社員のネット告発に企業はどう対応する？逆炎上を防ぐ初動と再発防止
• › ステマ規制の措置命令、対象になったらどうする？初動対応から再発防止までの実務ガイド
• › 退職者がSNSや口コミサイトに会社情報を投稿したときの初動対応
• › 医療機関の口コミ削除・風評被害対策｜クリニック経営者向け
• › 士業事務所の誹謗中傷対策｜弁護士・税理士の風評被害を防ぐ
• › 悪質なクレーマーへの対応マニュアル｜電話・メール・対面のケース別に解説
• › 非弁行為とは？弁護士法違反の罰則・具体例と弁護士紹介や斡旋が違法になるケース
• › ネット風評被害の「イレイサー」とは？削除・法的対応の注意点を2事例で解説
• › 広告炎上の原因と対策｜企業が公開前・炎上時に取るべき対応
• › SNS監視・モニタリングとは？自社運用・炎上対策・会社選び
• › オープンマリッジ大波紋！ヒカルの選択が示す企業ブランドへの影響と風評リスク
• › ネット上の投稿を削除依頼する方法｜媒体別の流れと削除できない場合の対処法
• › ネット上の悪評を削除・対策する方法3選｜削除申請・法的対応・検索対策の違い
• › Googleサジェストとは？意味からキーワード抽出ツール・汚染対策を解説
• › ブログの風評被害対策｜監視・モニタリング・削除・検索対策
• › 誹謗中傷とは？口コミサイト・SNSの書き込みは該当する？判断基準を解説
• › ECサイトの風評被害対策｜ 悪いレビュー・口コミ・SNS炎上への対処法
• › X（旧Twitter）の危険性とは？企業の炎上リスク・原因・予防・初動対応を解説
• › 2ch（2ちゃんねる）の誹謗中傷対策｜削除方法・逆炎上の注意点と上場審査への影響
• › Google口コミの返信方法｜悪い口コミへの例文・NG対応・運用ルール
• › 口コミ・SNSの炎上兆候を早期検知するアラート設計｜件数・感情・拡散速度の閾値を決める
• › 炎上・風評インシデントの事後検証方法｜原因・判断・再発防止を振り返るポストモーテム
• › 炎上時の指揮系統を設計する方法｜判断権限・広報・法務・経営の役割を整理
• › 口コミ・炎上案件の再発パターンを分析する方法｜原因カテゴリと再発率で優先対策を決める
• › 企業の炎上対応を机上訓練する方法｜シナリオ・役割・判断時間・振り返りを設計
• › 企業名検索のブランドリスクを確認｜検索・口コミ・SNS・AI回答
• › 炎上時のステークホルダー別コミュニケーション設計｜顧客・社員・取引先・メディアへの第一報と伝え分け
• › 風評リスクの社内報告基準｜重大度・初動・法務・経営報告を整理
• › 会社名検索で悪い口コミが目立ったときの初動診断｜何から対処するか優先順位を決める方法
• › Google口コミやSNSに従業員の実名・個人情報が書かれたときの対応｜保存・報告・返信・社内保護を整理

関連テーマ

AIO SEO MEO 採用改善 オウンドメディア集客