危機管理広報、結局何をすればいい? — 8つのチェックポイントで全体像をつかむ

前回は、2026年10月に施行される法律をきっかけに、「なぜ危機管理広報の優先順位は上がりにくいのか」というところまでお話ししました。今回はいよいよ、「じゃあ具体的に何を整えればいいのか」という全体像に入っていきます。

危機管理広報と聞くと、「記者会見のやり方」を思い浮かべる人が多いかもしれません。でも実際は、記者会見はあくまで全体の中の一場面にすぎません。むしろ大事なのは、それ以前とそれ以後にある、地味だけれど欠かせない社内の意見のすり合わせと、意思決定の積み重ねです。

前職で危機管理広報のマニュアルを作った経験を振り返りながら整理すると、危機管理広報は大きく8つの意思決定ポイントに分解できます。

危機管理広報は「8つの意思決定ポイント」でできている

危機の際の広報は下記の「8つの意思決定ポイント」が重要です。

1. 目的の言語化
何のために、どういう状況を作るために備えるのかを、あらかじめ社内の共通認識にしておく

2. 想定クライシスの洗い出し
自社で起こりうる危機を、あらかじめリストアップしておく

3. 初期対応
発生直後、最初の数十分〜数時間で何をするか、どういうルート／メンバーで社内の情報共有をするか

4. 対外公表の判断
そもそも外に出すべき事案かどうかを見極める

5. 社内周知
外に出す前に、社内の誰へ、何を、どう伝えるか

6. 対外公表の実施
実際に何を、どの手段で、誰が発信するか

7. 記者会見
会見という手段を取るかどうか、取るとしたらどう進めるか

8. 公表後のフォロー
出して終わりにせず、その後どう信頼を取り戻していくか

この並びを見ると、「危機管理広報=4〜7番（公表まわり）」がメインというイメージを持つ方が多いですが、実際に備えを作ってみると大変なのは1〜3番です。危機管理広報とはどうあるべきものなのか、各々の理解度やマインドの統一も含め必要なメンバーとすり合わせておくだけでも一苦労です。想定クライシスを言語化しないまま、いきなり「公表文のテンプレート」を作ろうとしてもうまくいきません。備えるための準備がすでに、会社としての強度を上げていくプロセスであることを意識しましょう。

この並びの中でも、特に3番（初期対応）から6番（対外公表の実施）までは、現場で事態そのものに対応するチーム — 開発的な技術が絡む危機であれば技術対応チーム、そうでなければ法務や人事などのチーム — と、広報チームが、同じ事実関係を見ながらほぼ同時並行で動く必要がある部分です。現場の対応がどれだけ的確でも、それが外に伝わる言葉になっていなければ信頼は守れませんし、逆に発信だけがうまくても、中身の対応が伴っていなければすぐに見抜かれてしまいます。

それぞれの詳細（マニュアルの作り方や、判断基準の具体的な言語化の仕方）は、次回以降お伝えします。今回はまず、この8つを「地図」として頭に入れてもらえたら十分です。

危機は「開発的な技術が絡むもの」と「そうでないもの」に分かれる

2番の「想定クライシスの洗い出し」を考えるとき、最初に押さえておきたい大きな分岐があります。危機は、大きく分けると次の2種類です。

• 開発的な技術が絡む危機：システム障害、サービス停止、セキュリティインシデント、不正アクセス、情報漏洩、工場ラインの停止やハードウェアの不具合など

• 開発的な技術が絡まない危機：ハラスメントや労務トラブル、コンプライアンス違反、役員・社員の不祥事、取引先とのトラブル、自然災害による事業への影響など

この8つの意思決定ポイントという骨組み自体は、どちらの危機にも同じように当てはまります。「目的を言語化する」「想定される危機を洗い出す」「初動を決めておく」といった備えの型に、危機の種類による違いはありません。

ただ、このコンテンツを読んでくださっている方の多くは、開発的な技術が絡む危機に日常的に近い立場にいる方も多いと思います。前回取り上げた法改正も、あくまで「開発的な技術が絡む危機への備え」を後押しするきっかけのひとつに過ぎず、危機管理広報そのものが技術系の危機に限定される話ではありませんが、せっかくなので今回は、みなさんの仕事により直結しやすい「開発的な技術が絡む危機」について、もう少しだけ詳しく掘り下げてみます。

「開発的な技術が絡む」危機で、世論が高まりやすいパターン

記者会見が必要になるかどうかは、技術的な難易度ではなく「世論が説明責任を求めるかどうか」で決まります。開発的な技術が絡む危機の場合、この「世論の高まりやすさ」は、だいたい次のような軸で考えると整理しやすいです。

• 影響を受ける人の数と、その人たちの技術リテラシー：現場のエンジニアやオペレーター同士で完結する不具合と、一般の生活者に直接影響が及ぶ不具合とでは、注目のされ方が違います

• 個人に紐づく情報かどうか：個人情報の流出は、技術的な深刻度以上に、生活者の不安に直結しやすいテーマです

• 「誰かが悪意を持ってやったのか」という受け取られ方：同じ障害でも、不可抗力に近いものと、人為的なミスや不正に見えるものとでは、世論の厳しさがまったく異なります

• 組織としての振る舞い自体への疑念：事案そのものより、「隠していたのでは」「対応が遅すぎるのでは」という、対応の姿勢に対する不信感が炎上を長引かせることも少なくありません

この4つの軸に、自社で起こりうるシステム障害やセキュリティインシデント、あるいは工場ラインの停止や製品の不具合を当てはめてみると、どのリスクを優先して備えるべきかが見えてきます。

自社はどこが弱いか、セルフチェック

8つのポイントに沿って、簡単なセルフチェックをしてみてください。危機の種類を問わず使える形式になっています。

• 自社にとっての「危機管理広報の目的」を理解して、自分の言葉で語れる人が社内に何人いるか

• 自社で起こりうる危機を、技術系・非技術系の両方で具体的にリストアップしたことがあるか

• 危機発生時、最初の30分で、どんな情報を、誰が、どういうルートで、どうするか、決まっているか

• 「外に出す・出さない」の判断基準が決まっているか、誰が判断するか権限が明確になっているか

• 社外への公表より先に、社内に情報が伝わる仕組みがあるか

• プレスリリースやお知らせ文のひな形が、事前に用意されているか

• 記者会見をするかどうかの判断基準が決まっているか、誰が判断するか権限が明確になっているか

• 公表した後、フォローアップまで含めて誰が責任を持つか決まっているか

チェックがつかなかった項目があれば、そこが自社にとっての「備えの穴」です。全部を一度に埋める必要はなく、まずは自社にとって一番起こりやすい危機を例にして、1つずつ言語化していくのが現実的だと思います。

次回に向けて

この8つの意思決定ポイントは、それぞれ独立しているようで連動しています。次回は、この8つのポイントを会社を強くする「仕組み」にするための、マニュアル作成と訓練設計の実務についてお話しします。実際に手を動かして初めて見えてくるポイントを紹介していきます。