インシデント報告書を読み解く ― KDDI の不正アクセス報道発表から学ぶ開示の型

参考: ISP 事業者向けメールシステムに対する不正アクセスの発生について（KDDI 報道発表資料 2026-06-23）

まとめ

• インシデント開示文書は「謝る」「経緯を語る」ためではなく、 読み手の不安を事実で畳み、次の行動を提示する ために書く
• 確定事実と未確定事項を 語尾で厳密に区別 する。「判明しました」と「可能性があります」を混ぜない
• 数字には必ず前提を貼り、 最大値で出して下方修正の余地を確保 する
• 時間軸は非対称に扱う。 検知日は精密に出し、侵入日は伏せる 。誇れる時刻だけ選別して出している
• 対外文書は「何を書かないか」の設計が効く。社内ポストモーテムとは出す情報が真逆になる

ある大手通信事業者が出した不正アクセスの報道発表資料を読んだ。インシデント開示文書として、よくできた型だった。1ページの短い文書だが、一文一文に「なぜこう書いたか」が詰まっている。技術ドキュメントを書く人間として、開示文書の設計判断を分解しておきたい。

文書全体の骨格

短い文書だが、要素の順番に意図がある。

要素	中身	原則
ヘッダー	発表日 / 文書種別 / 発信主体	本文前に「いつ・誰が・何の文書か」を確定
タイトル	何が起きたかを名詞で言い切る	煽らず・隠さず
リード	何が・いつ判明したか + お詫び	結論先出し。事実とお詫びを混ぜない
発生経緯	検知 → 即時対応 → 原因 → 調査継続 → 当局報告	時系列に対処済み事項を織り込む
対象範囲	影響対象を具体名で列挙	範囲を確定。曖昧にしない
影響内容	影響項目 + 件数（最大値）+ 前提注記	数字に前提を貼る
案内・依頼	連絡状況 + 読み手が次にやるべきこと	締めは相手のアクション

リード文でまず「何がいつ判明したか」を1文で述べ、お詫びは独立した1文に切り出している。事実文に謝罪を混ぜると事実がぼやける。ここを分離しているのが最初の判断だ。

確定と未確定を語尾で分ける

経緯セクションを読むと、語尾の使い分けが徹底されている。

• 確定 → 「確認しました」「改修しました」「判明しました」
• 推定 → 「被疑箇所」（原因箇所と断定しない）
• 未確定 → 「可能性があります」「調査を継続しています」

特に巧妙なのが入れ子の一文だ。「漏えいした 可能性があること が 判明しました 」と書く。漏えいの可能性が存在する ことは確定事実、漏えいそのもの は未確定。二重の語尾で線引きしている。読み手に「どこまでが確定でどこからが推測か」を一文の中で正確に伝えている。

技術調査の報告でも同じだ。観察した事実と、そこから立てた仮説を、語尾で物理的に分ける。混ぜると後で「断定したのに違った」となり信頼を失う。

数字には前提を貼る

影響件数の記載に、三つの注記が付いていた。

• 解約済み・休眠ユーザーも含む（母集団の前提）
• ハッシュ化・暗号化済みのものも含む（深刻度の前提）
• 調査継続中のため最大値で記載（確度の前提）

この三つは「防御」と「実利」が同居している。

防御側の読み方をすると、最後の注記は完全に 下方修正の保険 だ。インシデント開示の定石として、件数は「最大値で出す→確定したら減る」方向にしか動かさない。増える方向の訂正（上方修正）は信頼を致命的に毀損するので、最初に天井を高めに置いておく。

一方で実利側も本物だ。解約者は自分が対象だと気づけないので注意喚起の射程を広げる意味があるし、ハッシュ強度によってリスクが変わるのも事実で、利用者が対応の緊急度を判断する材料になる。

ただし注意したいのは、報道に乗る時点で注記は死ぬということだ。見出しは件数だけが残り、注記は本文の隅か消える。起草者はそれを分かっていて、注記は記者向けではなく 後から一次資料を当たる人・当局・取引先向け に書いている。読み手を分け、見出しで燃えるのは織り込み済み、一次資料には誠実さの証跡を残す、という二層構えだ。

時間軸は非対称に扱う

経緯を読んでいて一番感心したのが、時刻の扱いの非対称さだ。

• 検知日 → 精密に出す （「6月17日に確認」）
• 即時対応 → 精密に出す （「同日改修」）
• 侵入日 → 伏せる

なぜ侵入時期だけ伏せるのか。理由は複数ある。

第一に、侵入から発覚までの潜伏期間が最も不利な数字だからだ。世間と当局が一番厳しく見るのは「何日気づかなかったか」で、ここに具体的な日付を書くと「数ヶ月放置していた」という過失のナラティブを自分で提供することになる。だから発覚から対処までの速さは出し、侵入から発覚までの遅さは出さない。出す数字を選別している。

第二に、侵入時期はログ精査に時間がかかり開示時点では確定していないことが多い。暫定で出すと後で悪い方向に訂正する羽目になる。件数と同じく時間軸にも「確定するまで言わない」が適用されている。

第三に、侵入時期は影響範囲や通知義務の起点を法的に確定させてしまう。確定前に書くと後の調査結果と齟齬が出たとき不利になる。

第四に、いつ侵入されたか正確に把握していると示すことは、どのログが残っているかを攻撃者に教えることでもある。

「伏せる」は隠蔽というより、 確定した誇れる時刻だけを出し、未確定で不利な時刻は調査結果を待つ という選別だった。

何を書かないかの設計

時間軸の話を一般化すると、この文書は「書かないことの設計」が効いている。攻撃手法の詳細、侵入時期の特定、脆弱性の識別番号、製品ベンダー名。このあたりは全て伏せられている。攻撃者へのヒントになることと、確定前の断定になることを、両方避けているわけだ。

原因についても「第三者製のソフトウェアの脆弱性」とだけ書き、自社開発の瑕疵ではないことをにおわせつつ「だから当社は悪くない」とは書かない。あくまでほのめかすだけで、断定の責任は負わない。受動態（「悪用された」）を使い、やられた側のフレームを保つ。

ここが対外文書と社内文書で真逆になるポイントだ。社内のポストモーテムでは、侵入時期の推定も潜伏期間も全部出す。むしろ潜伏期間こそ改善対象として明示するのが正しい。同じ事実の「どれを出すか」が、読み手が社外か社内かで反転する。対外文書を書くときは、この切り替えを意識する価値がある。

おわりに

短い1ページの文書を分解すると、一文ごとに「確定／未確定の区別」「数字の前提」「時刻の選別」「省略の設計」という判断が積まれていた。インシデント報告に限らず、障害報告や調査レポートの導入部にそのまま流用できる型だ。

特に「確定と未確定を語尾で分ける」「数字に前提を貼る」「締めは相手のアクションで終える」あたりは、日常の技術コミュニケーションでもすぐ効くと思う。自分も次に障害報告を書くときは、まず語尾を一個ずつ見直すところから始めるつもりだ。事故の文書って、結局のところ平時の文章作法が一番むき出しになる場所なのかもしれない。