>
>
公開日
最終更新日
インシデントとは、業務やITサービスの正常な運用を妨げる予期せぬ事象です。事故の前兆に限らず、すでに発生したサービス停止や品質低下、情報漏えいも含みます。アクシデントは実害が生じた事故、ヒヤリハットは事故に至らなかった危険な出来事を指しますが、ITでは実害があってもインシデントと呼びます。
本記事は、言葉の意味や使い方を知りたい方と、受付・復旧・報告を担当する情報システム部門（情シス）の方に向けた解説です。意味だけを知りたい方は「インシデントとアクシデント・ヒヤリハットの違い」と例文の節まで、異常が起きた直後の方は「異常を見つけたときの相談先と個人データ漏えい等の報告期限」から、体制を整える方は原因別の予防策以降へ進むと、必要な情報に早く届きます。
この記事で確認したこと（確認日: 2026年10月22日）
ITIL 4の定義、IPAの相談案内と初動対応、個人情報保護委員会の漏えい等報告、ベンダー公表の導入事例を扱います。本文では「現行の義務」「公的機関などの推奨・手法の例示」「本記事の運用提案」を区別します。導入事例の数値は各社の対象業務における実績であり、他社での再現を保証する値ではありません。情報は2026年10月22日時点です。
インシデントとは
インシデントとは、業務やITサービスの正常な運用を妨げる予期せぬ事象全般を指します。
本記事のポイント
インシデントは事故の前兆だけでなく、発生済みのサービス停止や品質低下も含みます。
アクシデントとの違いは実害の有無だけでは決まらず、ITでは実害のある事故もインシデントとして管理します。
通常障害では早期復旧を進め、不正アクセスが疑われる場合は封じ込めと証跡保全を先に判断します。
技術的な相談と個人データ漏えい等の法定報告は別の手続きです。
MTTA・MTTRは組織や製品によって計測の開始点と終了点が異なります。自社の運用規程で、どの時点からどの時点までを測るかを定めます。
一般語とITIL 4における意味
一般語のインシデントは広く出来事や事案を表し、ITIL 4ではサービスの中断・品質低下を表します。
英語のincidentには「出来事」「事案」「騒動」などの意味があります。日本語のビジネス会話では、事故につながる出来事や業務上のトラブルを指して使います。事故未遂を指す場面もありますが、「まだ被害が出ていない状態」という意味だけに限定すると、IT現場での使い方と食い違います。
ITILでは、インシデントを計画外のサービスの中断や、サービス品質の低下として扱います。社内ネットワークが停止した場合も、受注システムが遅くなって登録処理が滞った場合も該当します。完全停止していなくても、通常の品質でサービスを利用できなければ管理対象です。
セキュリティインシデントの範囲
セキュリティインシデントは、情報の漏えい・改ざん・消失や、それらにつながる可能性のある事象を含みます。
IPAは『中小企業の情報セキュリティ対策ガイドライン』の付録8「中小企業のためのセキュリティインシデント対応の手引き」で、情報の漏えい、改ざん、破壊・消失、情報システムの機能停止、またはこれらにつながる可能性のある事象を対象に挙げています。不正ログインを検知した時点では持ち出しの有無が分からなくても、調査を始める理由になります。
ITサービスのインシデントとセキュリティインシデントは重なりますが、範囲は同一ではありません。SaaSが正常稼働していても、公開設定の誤りで顧客資料を誰でも閲覧できるならセキュリティ対応へ進みます。逆に、機器故障による停止では、不正行為の形跡がなければ通常の障害復旧手順で対応します。
情シスが受け付ける具体的な事象
情シスの受付では、障害、情報保護、端末、SaaS、生成AIに関する異常を横断して記録します。
対象 | 具体例 | 最初に残す情報 |
|---|---|---|
システム・ネットワーク | サーバー停止、通信遅延、ログイン不能、バックアップ失敗 | 対象サービス、発生時刻、エラー、影響する業務 |
情報・アカウント | 不正ログイン、権限の誤設定、メール誤送信、退職者IDの残存 | 対象データ、操作履歴、アクセス元、権限変更履歴 |
端末 | PC紛失、マルウェア検知、認証情報の流出 | 端末識別情報、最終利用場所、暗号化・管理状態 |
SaaS・委託先 | 外部サービス停止、委託先からの漏えい連絡、未承認SaaSの発覚 | サービス名、契約管理者、利用者、保存データ |
生成AI | 機密情報の入力、不正な外部操作、誤情報の対外提供 | 入力内容、利用アカウント、参照先、出力と実行履歴 |
「未承認サービスを使った」という規程違反と、「情報が漏えいした」という結果は分けて記録します。両者を混同すると、被害のない利用まで漏えいと断定したり、逆に規程違反だけとして外部送信の調査を省いたりします。
読み方・日本語訳・複数形
incidentの読み方は「インシデント」で、incidentsはその複数形です。
英語資料では単数のincidentと複数のincidentsが使い分けられますが、日本語では通常どちらもインシデントと表記します。
日本語へ置き換えるなら、文脈に合わせて「事案」「障害」「事故」「異常事象」を選びます。社内報告では「インシデント発生」だけで済ませず、「受注登録ができない」「社外から管理者アカウントへのログインを検知した」のように、起きた事実を続けます。
目的別の読み進め方
用語の理解が目的なら違いと例文まで、対応担当者なら管理手順と相談・報告までで判断に必要な情報がそろい、市場動向や導入事例は管理ツールを選ぶ段階で読めば足ります。
読者の目的 | 読む内容 | 持ち帰る実用部品 |
|---|---|---|
言葉の意味を知る | 定義、アクシデントとの違い、使い方 | 比較表と会話例 |
発生した異常へ対応する | 優先度、初動の分岐、相談先、法定報告 | 報告テンプレートと初動表 |
管理体制を整える | 原因別の予防策、導入事例、測定指標 | 原因別対策表と着手チェックリスト |
インシデントとアクシデント・ヒヤリハットの違い
アクシデントは実害が生じた事故、ヒヤリハットは事故に至らなかった出来事を指しますが、インシデントはITではその両方と重なる範囲を持ちます。
比較軸 | インシデント | アクシデント | ヒヤリハット |
|---|---|---|---|
基本的な意味 | 正常な業務・サービスを乱す事象、情報の安全を脅かす事象 | 損害が現実化した事故 | 事故には至らなかった危険な出来事 |
実害の有無 | ITでは実害のある停止・品質低下も含む | 人身・物理・金銭などの実害がある | 想定した事故による実害はない |
影響範囲 | 単一利用者から全社・顧客まで | 事故の対象や周辺へ実際の損害が及ぶ | 直接の被害はないが、同じ操作をする人へ再発リスクがある |
発生・発見時点 | 異常の検知時、障害発生時、被害発覚時 | 損害を伴う事故が発生した時点 | 事故へ至る前に回避・中断した時点 |
情シスの例 | SaaS停止、不正アクセス、外部公開設定の誤り | 情報流出による損害、設備事故 | 誤送信直前に宛先を修正 |
実害だけでは決まらない用語の境界
「実害なしがインシデント、実害ありがアクシデント」という二分法は、ITサービス管理には適用できません。
顧客向けサービスが停止して売上に影響した場合でも、IT運用の記録ではインシデントとして扱います。情報漏えいが確定した事案もセキュリティインシデントです。アクシデントへ名称を変えないと重大対応を始められない、という運用にはしません。
医療では患者への影響、製造では作業者の安全や製品品質、物流では配送品質や交通安全が判定軸に加わります。現場の報告規程を作るときは、名称の対応表より先に、誰の安全・どの情報・どの業務を守るかを定めます。そのうえで、既存の業界用語と社内の重大度を対応させます。
イベント・インシデント・重大インシデントの判定
情シスでは、観測した事実、対応を要する異常、全社対応が必要な重大事象を段階的に切り分けます。
区分 | 判定の例 | 担当者の行動 |
|---|---|---|
イベント | 監視値の変化やログ記録があるが、サービス影響や侵害の兆候がない | 記録・相関確認を行い、必要に応じて監視を継続 |
インシデント | 利用不能、遅延、不正閲覧のおそれ、マルウェア実行の兆候がある | チケットを起票し、影響評価と初期対応を開始 |
重大インシデント | 基幹業務の広範な停止、重大な漏えいのおそれ、安全への影響がある | 対応責任者を置き、経営・法務・広報などを招集 |
この表は本記事の運用提案です。たとえば、フィッシングメールの受信だけなら記録と遮断で処理できる場合がありますが、複数部署への標的型攻撃なら調査を開始します。リンクを開いた場合も、入力の有無だけで決めず、ファイルの実行、認証トークンの流出、端末の挙動を評価します。
一方、CPU使用率が高くても、利用者への影響がなく計画内の処理なら直ちに重大対応へ進めません。閾値超過が継続し、注文登録の遅延が発生したなら起票します。通知の件数ではなく、業務影響と侵害のおそれを判定に使います。
ハインリッヒの法則との関係
ハインリッヒの法則は小さな異常を集める考え方の参考になりますが、ITの用語定義や被害予測には使いません。
「小さな出来事が一定数たまると必ず重大事故が起きる」「ヒヤリハットからインシデント、アクシデントへ順に進む」と解釈すると、重大事象の扱いを誤ります。前兆が社内で把握されないまま攻撃や障害が発生する場合もあります。ITのアラート件数から重大事故の件数を機械的に計算する運用も避けます。
現場では、未遂の件数に加えて「防げた仕組み」と「防げなかった場合の影響」を残します。誤送信を送信保留機能で止めたなら、その機能が他部署にも適用されているかを点検します。件数の多い軽微事象だけでなく、頻度が低くても取り返しのつかないリスクへ対策を割り当てます。
▲ インシデント・アクシデント・ヒヤリハットにおける意味と実害の有無の違い
インシデントの具体的な使い方・例文
報告でインシデントという言葉を使うときは、発生事象・影響範囲・実施済み対応・次回連絡時刻を続けると相手が行動を判断できます。
日常のビジネス会話の例文
日常会話では、専門用語だけで済ませず、何が起きたかを具体的な動詞で伝えます。
「請求書を別の取引先へ送付するインシデントが発生しました。送信先へ削除を依頼し、添付ファイルに含まれる情報を調べています」
「端末紛失のインシデントとして情シスへ連絡します。最終利用は本日15時で、端末管理システム上の状態を調べています」
「倉庫の温度が管理基準を超えたため、対象ロットを出荷停止にしました。品質管理担当が出荷再開を判定します」
「今回のレビューでは、担当者の注意不足で終わらせず、入力画面と承認手順のどこで防げるかを検討します」
言葉を知らない相手には、「インシデント、つまり業務上のトラブルが発生しました」と初回だけ補足します。その後は「請求書の誤送信」「端末紛失」のように事象名で伝えると、会話が具体的になります。
IT障害の初報・復旧報の例文
IT障害の初報では判明した影響を先に伝え、復旧報では業務再開と残作業を分けて示します。
初報の例文
本日10時15分から、受注管理システムで注文登録が完了しないインシデントが発生しています。対象は国内拠点の利用者で、閲覧機能は利用可能です。原因は調査中です。現在は手動受付へ切り替えており、次回報告は11時00分です。利用者側での再登録は重複注文につながるため、復旧連絡まで控えます。
復旧報の例文
10時15分に発生した注文登録の障害は、11時08分に業務部門の操作確認を完了しました。アプリケーション更新時の設定不整合を修正し、登録機能は利用可能です。未処理データは運用担当が再登録し、12時までに整合性を確認します。恒久対策は問題管理へ引き継ぎます。
これらは記入例です。原因が分からない段階で「データベースが原因です」と断定せず、「データベース接続エラーを検知した」と観測事実を書きます。復旧時刻も、監視が正常に戻った時刻と利用者が業務を再開できた時刻を分けると、停止時間を後から計算できます。
トリアージと担当引継ぎの例文
優先度を伝えるときは、番号だけでなく、その判定に使った業務影響を添えます。
「全社員が会計SaaSへログインできず、締め処理を実行できません。代替手段がないためP1として起票し、責任者を招集します」
「対象は営業部の3名で、別端末から処理できます。P3として運用担当へ割り当て、2時間後に影響を再評価します」
「管理者アカウントの不審な操作を検知しました。対象セッションを停止し、セキュリティ担当へ証跡保全と詳細調査を引き継ぎます」
「個人データへのアクセスが疑われるため、漏えいの確定を待たずに法務へ連絡し、報告対象の判定を並行して始めます」
引継ぎでは「対応をお願いします」だけで終わらせません。依頼する作業、判断してほしい事項、期限、作業済みの範囲を分けます。端末を隔離済みなら、その方法と時刻も残し、引継ぎ先が同じ操作を重ねないようにします。
重大インシデント宣言の例文
重大インシデントの宣言では、招集する担当者と、誰が全体の意思決定を担うかを明示します。
顧客向け決済が全体で停止しているため、本件をP1の重大インシデントとして宣言します。対応責任者は当番マネージャーです。運用は復旧、開発は直前変更の評価、業務部門は代替受付、広報は顧客告知案の作成を担当します。次回の全体共有は15分後です。
管理者アカウントからの不審なデータ取得を検知しました。重大インシデントとしてセキュリティ・法務・経営へ連絡し、対象アカウントの封じ込めとログ保全を開始します。持ち出しの範囲は調査中です。対外発信は責任者が情報を集約して判断します。
重大度は強い言葉を使うためのラベルではありません。通常の担当割当てから、専門家の招集、意思決定の一本化、定期報告へ切り替える合図として運用します。漏えいが確定するまで宣言を待つと、調査や報告の準備が遅れます。
コピーして使える報告テンプレート
チケットやチャットへ貼り付けるテンプレートには、未判明の項目も残して担当者が追記します。
初報のために全項目が埋まるまで待ちません。発生事象、対象、連絡先を先に送り、分からない欄には「調査中」と記入します。ログの保存場所や個人データの内容は、閲覧権限を絞ったチケットへ記載し、全社チャットへ機密情報を貼り付けない運用にします。
報告の更新と訂正の記録
後から事実が変わった場合は初報を消さず、更新日時と変更理由を追記します。
たとえば「影響は営業部のみ」から「全社」へ広がった場合、判明した時刻、追加した対象、優先度の変更を残します。発生時刻の推定が変わった場合も、当初の認識を上書きせず、ログから判明した時刻を追記します。対応中のチャットをそのまま最終報告にせず、責任者が時系列を整えた記録を保存します。
インシデント管理の目的と問題管理との違い・対応手順5ステップ
インシデント管理の主目的は原因究明ではなく、一刻も早いサービスの復旧です。
問題管理・変更管理との役割分担
インシデント管理で業務を再開し、問題管理で根本原因を調べ、変更管理で恒久対策を安全に反映します。
比較軸 | インシデント管理 | 問題管理 | 変更管理 |
|---|---|---|---|
目的 | サービス復旧と影響の最小化 | 根本原因の特定と再発防止 | 変更によるリスクを抑えて改善を反映 |
主な作業 | 切り戻し、代替経路、回避策、復旧確認 | 原因分析、既知エラーの整理、恒久対策の検証 | 変更評価、承認、実施計画、切り戻し準備 |
開始の例 | 障害・異常の検知 | 重大事象、同種障害の反復、予兆の分析 | 修正や設定変更の計画 |
終了の例 | 業務再開と復旧判定の完了 | 対策の有効性と残余リスクの評価 | 反映後の正常性確認 |
記録の関連付け | 影響、復旧操作、対応時系列 | 関連する複数の障害、原因、対策 | 承認者、変更内容、実施結果 |
問題管理は、必ず復旧後にしか始められないわけではありません。復旧担当とは別の担当者が原因を調べられるなら並行して進めます。ただし、原因が完全に判明するまで代替手段を案内しない運用は避けます。再起動で直った場合も原因が解消したとは限らないため、反復する障害は問題管理へ関連付けます。
P1〜P4のトリアージ基準
優先度は、影響する業務の範囲と、対応を待てる時間の組み合わせで決めます。
優先度 | 判断例 | 初動目標の例 | 連絡先 |
|---|---|---|---|
P1 | 基幹業務の全体停止、重大な漏えいのおそれ、安全への影響 | 5分以内に受領、15分以内に責任者を招集 | 情シス責任者、セキュリティ、法務、経営 |
P2 | 重要部門の停止、複数顧客への影響、代替手段なし | 15分以内に受領、30分以内に対応方針を決定 | システム責任者、業務部門、ベンダー |
P3 | 一部利用者への影響があり、代替手段を利用可能 | 営業時間内に担当者を割当て | 運用担当、サービスデスク |
P4 | 業務を継続できる軽微な表示不良など | 通常の保守計画で処理 | 保守担当、製品担当 |
この時間設定は本記事の運用提案であり、法定期限や一律の業界基準ではありません。契約上のサービス水準、顧客対応時間、業務締切から自社の目標を決めます。給与支払日の会計障害のように、同じシステムでも時期によって緊急度が変わる場合は、判定条件へ締切を加えます。
パスワードリセットやソフトウェア導入の通常依頼は、障害と分けて受付を設計します。ZendeskのITILに基づく解説も、これらをサービスリクエストとして区別しています。ただし、突然多数の利用者が認証できない場合は、個別のリセット依頼ではなく共通障害として調査します。
可用性優先と証跡保全優先の分岐
通常の機能障害なら復旧操作を進め、不正アクセスやマルウェアが疑われるなら封じ込めと証跡保全を先に判断します。
判断材料 | 可用性優先の対応例 | 証跡保全優先の対応例 |
|---|---|---|
発生状況 | 直前の更新後に機能不良が発生し、不正操作の兆候がない | 未知の管理者、異常な通信、不審なデータ取得を検知 |
初期操作 | 承認済み手順で切り戻し、冗長系や代替経路へ切替え | 対象端末・アカウントを封じ込め、ログを保全 |
再起動・初期化 | 作業記録を残し、既定の手順で実施 | 不用意に実施せず、調査担当が証拠への影響を評価 |
復旧条件 | 機能とデータ整合性、業務操作の正常性 | 侵入経路や認証情報への対応、再侵害防止、業務の正常性 |
IPAは初動対応で、ネットワーク遮断や機器の隔離で被害拡大を防ぎつつ、記録を消す不用意な電源断などを避ける手順を示しています。感染が疑われる端末を通常障害と同じ感覚で再起動・初期化すると、調査に必要な情報を失うおそれがあります。
人命や設備の安全が関係する場合は、安全確保を先に実施します。証跡を残すために危険な設備を稼働し続ける運用にはしません。対応責任者は、何を止め、どの証跡を残せなかったかまで記録し、専門家へ引き継ぎます。
受付からクローズまでの5ステップ
対応は、受付、分類、初期対応、専門担当への引継ぎと復旧、クローズの順に進めます。
インシデント管理の主な活動は、記録、通知とエスカレーション、分類、優先順位付け、調査と診断、解決とクローズです。以下は、これらの活動を情シスの実務に合わせて5段階へまとめた運用例です。通知やエスカレーションは最後まで待たず、重大度が上がった時点でも実施します。
段階 | 担当者の作業 | 残す記録 | 次へ進む条件 |
|---|---|---|---|
1. 受付・検知 | 監視、利用者、委託先の連絡を一つの窓口で受ける | 発生・検知日時、対象、症状、連絡者 | 管理番号と受領担当が決まる |
2. 分類・優先度付け | 業務影響、緊急度、情報への影響を評価 | 優先度、判定理由、担当、次回報告時刻 | 対応責任者と初期方針が決まる |
3. 初期対応・封じ込め | 切り戻し、代替運用、端末隔離、アカウント停止 | 操作内容、実施者、時刻、保全した証跡 | 影響の拡大を抑え、復旧・調査へ進める |
4. 引継ぎ・復旧 | 専門チームやベンダーと原因候補を絞り、復旧を実施 | 依頼内容、回答、変更内容、利用者の操作確認 | 業務再開とデータ整合性を確認する |
5. クローズ・振り返り | 復旧判定、関係者連絡、問題管理への移管 | 影響時間、対応履歴、残課題、対策の担当期限 | 責任者が終了と残課題の引継ぎを承認する |
端末隔離は被害を止める「封じ込め」であり、優先順位を付ける「トリアージ」とは別の作業です。また、チケットを受け取った人と、実際に復旧を判断する人も分けて記録します。重大事象では、全体指揮、技術対応、業務連絡、記録を複数人で分担すると、技術担当が説明に追われる状態を避けられます。
MTTA・MTTRと対応品質の測定
検知から応答まで、応答から業務再開までを分けて測ると、通知と復旧のどちらを直すべきか判断できます。
MTTA・MTTR：開始点と終了点は組織や製品で異なるため、自社の運用規程で定めた区間の平均時間として計測します。
未応答率：設定した時間内に担当者が受領しなかった通知の割合です。
再発率：同じ原因に関連付けた事案が、定めた期間内に再発した割合です。
MTTRは組織によって修復・復旧・解決のどこを指すかが異なるため、計測の開始点と終了点を運用規程へ書きます。全件平均だけでなく、P1・P2、営業時間内外、対象サービス別に分けます。平均値が短くても重大事象だけ長時間化していれば、当番体制や復旧権限を見直します。
たとえば、担当者の受領は早いのに復旧が遅いなら、通知をさらに増やしても改善しません。切り戻しの承認待ち、構成情報の不足、委託先への連絡経路を調べます。逆に復旧作業は短いのに受領が遅ければ、当番表、電話通知、無応答時の代替連絡先を修正します。
▲ 障害検知から恒久対策の反映に至るインシデント管理・問題管理・変更管理の流れ
▲ 異常発生時における可用性優先の復旧と証跡保全優先の対応分岐フロー
異常を見つけたときの相談先と個人データ漏えい等の報告期限
不正アクセスの疑いがあれば技術相談と専門調査を進め、個人データの漏えい等が関係する場合は法定報告の判定を同時に始めます。
IPAの不正アクセス特別相談窓口
IPAは2026年10月16日13時に「不正アクセス特別相談窓口」を開設しています。情報は2026年10月22日時点のものです。
IPAが2026年10月16日に公表した「不正アクセス特別相談窓口」の開設案内は、不正アクセスへの対応を相談する窓口を示しています。
対象は、実際に被害を受けている、またはその可能性がある事象が発生している全国の企業・組織です。電話番号は03-6759-5760、電話の受付時間は平日9時30分〜17時30分（12時〜13時を除く）で、メールでも相談できます。窓口では、起きている事象を聞き取り、被害発生の可能性について助言します（IPAの発表）。IPAの相談窓口の一覧は情報セキュリティに関する相談窓口のページにあります。連絡先は社内の対応手順書と当番表へ転記します。相談前に、発生・検知時刻、対象システム、異常なログ、実施済みの操作を一枚に整理します。窓口の受付外でも、社内連絡、被害拡大防止、契約ベンダーへの調査依頼を止めずに進めます。
相談した時点で原因究明や現地調査まで完了するわけではありません。異常なアカウントが見つかったなら、単に削除して終わらせず、作成日時、権限、操作履歴、関連する認証ログを専門家へ渡せる状態にします。
社内外の連絡先と役割
最初の連絡では、技術調査、法的判断、業務継続、対外説明を別の担当へ割り当てます。
連絡先 | 依頼する内容 | 渡す情報 |
|---|---|---|
情シス・セキュリティ責任者 | 対応指揮、封じ込め、証跡保全の判断 | 対象、時系列、異常ログ、実施済み操作 |
専門のセキュリティベンダー | 侵入経路、被害範囲、データ取得の有無などの詳細調査 | ログ、構成、認証履歴、端末、作業記録 |
法務・個人情報保護担当 | 報告対象、期限、本人通知、契約上の連絡の判定 | データの種類、対象者数、発覚日、外部提供の状況 |
業務責任者 | 代替運用、取引先対応、業務再開の判定 | 停止機能、影響範囲、代替手段、復旧見込み |
広報・顧客窓口 | 公表文、問い合わせ対応、説明内容の統一 | 確定事実、調査中の事項、顧客が取る行動 |
不正アクセス対応の優先順位は、不正アクセス発生時の対応優先順位も参照し、社内の初動手順へ落とし込みます。窓口の担当者だけが電話番号を知っている状態を避け、当番表と対応手順書の両方へ連絡先を保存します。
現行の義務としての漏えい等報告
個人データの漏えい等が報告対象の類型に当たる場合は、個人情報保護委員会の案内に沿って、報告と本人通知の要否を判定します。
個人情報保護委員会の「漏えい等の対応とお役立ち資料」は、報告対象となる類型と手続きを案内しています。対象は、漏えいが確定した場合だけでなく、該当する事態が発生したおそれがある場合を含みます。実害の確定を待ってから期限を数え始める運用にはしません。
報告対象となる類型 | 判断材料 |
|---|---|
要配慮個人情報を含む個人データ | 病歴など、取り扱う情報の種類 |
財産的被害が生じるおそれのある個人データ | 不正利用によって本人の財産へ被害が及ぶ可能性 |
不正の目的をもって行われたおそれがある漏えい等 | 不正アクセス、持ち出しなど、行為の状況 |
本人の数が1,000人を超える漏えい等 | データの行数ではなく、対象となる本人の数 |
対象類型は、いずれかに該当するかを判定します。「対象者が少ないから報告不要」とは限りません。不正の目的のおそれや要配慮個人情報が関係するなら、人数と切り離して評価します。暗号化などの状況を含む具体的な適用判断は、法務・個人情報保護担当が同委員会の案内に沿って記録します。
速報・確報・本人通知の時間軸
速報は事態を知ってから速やかに、目安として3〜5日以内に行い、確報は原則30日以内、不正の目的のおそれがある場合は60日以内に行います。
手続き | 期限・時期 | 担当者が準備する内容 |
|---|---|---|
速報 | 事態を知ってから速やかに（3〜5日は目安であり、待機できる期間ではない） | その時点で把握した概要、対象データ、原因候補、対応状況 |
確報 | 発覚日から原則30日以内（個人情報保護委員会の案内による） | 調査結果、対象範囲、原因、二次被害、再発防止策 |
不正の目的のおそれがある事態の確報 | 発覚日から60日以内（個人情報保護委員会の案内による） | 専門調査の結果を含む確報事項 |
本人通知 | 事態の状況に応じて速やかに実施 | 概要、対象項目、原因、二次被害のおそれ、本人が取る対応 |
3〜5日は、対応を始めずに待ってよい期間ではありません。初報を受けた日に、法務担当が発覚日を記録し、速報・確報の期限を管理表へ入れます。調査が続いていても速報を進め、判明した情報を追記します。本人通知は速報・確報とは別に、対象者へ伝える内容と方法を準備します。
委託先で発生した場合は、委託元へ通知するための連絡経路も動かします。委託先が委託元へ通知した場合は、委託先は委員会への報告義務を負わないとされています（個人情報保護法第26条第1項ただし書）が、「委託先の事故だから自社の対応はない」とは扱いません。双方の法務担当が報告主体と通知内容を合意し、契約上の初報期限も別途管理します。
技術相談と法定報告の切り分け
IPAや専門ベンダーへの相談を済ませても、個人情報保護委員会への報告を済ませたことにはなりません。
技術相談は、何が起きたか、何を止めるか、どの証拠を残すかを判断するための手続きです。法定報告は、対象となる漏えい等について所管機関へ所定の事項を報告する手続きです。チケットには「技術相談の受付番号」と「法定報告の提出状況」を別欄で持ち、片方の完了で全体を終了しません。
社外へ情報を送る際も、相談に必要な範囲へ絞ります。顧客データそのものを一般のメールや公開チャットへ添付せず、調査委託先と受渡し方法、アクセス権、保管期限を決めます。対応中に新しい漏えい経路を作らないよう、共有先とダウンロード履歴も記録します。
インシデントの主な発生原因と予防・再発防止策
発生原因を人的過失、システム不具合、外部攻撃、管理外IT利用に分け、各原因へ技術的な制御と担当者の運用を割り当てます。
4つの原因と対策の対応表
原因別に防ぐ場所を決めると、「従業員へ注意した」だけで再発防止を終わらせずに済みます。
原因 | 具体例 | 技術的な予防策 | 組織的な予防策 |
|---|---|---|---|
ヒューマンエラー | 誤送信、公開設定ミス、削除操作、権限付与の誤り | 権限最小化、送信保留、設定自動検査、削除時の保護 | 変更の相互確認、作業手順の標準化、早期報告 |
システム・ソフトウェアの不具合 | 更新失敗、容量不足、バグ、証明書切れ、機器故障 | 段階リリース、冗長化、容量監視、期限監視 | 保守責任者の明確化、切り戻し訓練、復元テスト |
外部からのサイバー攻撃 | 不正アクセス、フィッシング、脆弱性悪用、マルウェア | 多要素認証、脆弱性修正、EDR、通信制限、ログ保全 | 資産棚卸し、緊急連絡、専門調査の契約、演習 |
シャドーIT・未承認AI利用 | 個人契約SaaSへの保存、機密情報のAI入力、過大な外部連携権限 | 承認済み環境、連携権限の制限、監査ログ、外部送信制御 | 利用申請、データ分類、許可用途、契約と退職時処理 |
この分類と対策は本記事の運用提案です。実際の事案では、設定ミスに攻撃者が乗じるように複数の原因が重なります。最終報告では一つへ無理に押し込まず、発生原因、検知が遅れた理由、被害が広がった理由を分けて対策を決めます。
人的過失への操作・承認の制御
設定ミスや誤送信を減らすには、誤った操作を実行できる範囲と、実行後の被害を小さくします。
外部共有を必要なフォルダだけに許可し、一般利用者へ管理者権限を付けない状態を標準にします。大量削除や全社公開には追加承認を設け、設定変更を自動検査できるなら変更前に検査します。誤送信では、宛先確認の教育に加えて、外部ドメイン警告、送信保留、機密ラベルを組み合わせます。
作業者が急いでいた場合は、なぜ緊急作業になったかまで調べます。依頼期限、夜間の人員、承認者の不在が原因なら、教育だけでは再発を防げません。レビューでは実行者への叱責から始めず、時系列、作業画面、承認記録を集め、どの段階で止められたかを検証します。
システム不具合への変更・復旧の制御
システム由来の障害には、変更前の検証と、失敗した場合に戻せる手順を対にして用意します。
更新を一度に全体へ適用せず、限定環境で業務操作を試してから広げます。変更計画には、正常性を判定する監視値、利用者の確認項目、切り戻す条件と担当者を記入します。証明書や契約の期限は、通知を出すだけでなく更新担当者へ割り当て、完了まで追跡します。
バックアップの取得成功は復旧成功と同じではありません。復元先の環境、必要な認証情報、データの整合性まで試します。システムが戻っても、注文や請求が重複していれば業務は正常化していません。復旧テストでは、技術担当と業務担当が別々の観点で判定します。
外部攻撃への認証・検知・封じ込め
外部攻撃には、侵入を防ぐ制御と、侵入後に発見して広がりを止める制御を併設します。
管理者、メール、リモートアクセス、主要SaaSへ多要素認証を適用し、共有アカウントを減らします。インターネットへ公開する機器を棚卸しし、脆弱性修正の担当と期限を決めます。EDRで検知できても、夜間に受領する人がいなければ隔離が遅れるため、通知先と隔離権限まで設定します。
退職者アカウントの停止だけでなく、外部連携のトークンや自動処理用の認証情報も管理対象にします。侵害時はパスワード変更だけで終了せず、セッション、追加された認証手段、権限変更、外部アプリの承認を調査担当が評価します。侵入経路を残したまま業務再開すると再侵害につながります。
シャドーIT・未承認AI利用への管理
管理外のSaaSや生成AIには、禁止の周知と同時に、業務で使える承認済みの選択肢を示します。
利用申請ではサービス名、管理者、保存するデータ、共有範囲、外部連携、解約時のデータ処理を記録します。学習への利用、保存期間、人による閲覧などは契約と設定によって異なるため、許可する法人環境と入力できる情報をサービス単位で決めます。学習に使われない契約でも、外部事業者へデータを送る処理は残ります。
AIがメール送信、ファイル削除、支払いなどを実行する場合は、参照する権限と実行する権限を分離します。外部文書に埋め込まれた指示をそのまま実行させず、高影響の操作には人の承認を挟みます。対外資料は、出典が実在するかだけでなく、引用した内容が原文と一致するかまで担当者が照合します。
原因分析から対策完了までの管理
再発防止策は、担当者、期限、検証方法を付けて問題管理のチケットへ登録します。
分析する問い | 記録する内容 | 対策完了の判定例 |
|---|---|---|
何が発生を引き起こしたか | 変更内容、誤操作、侵入経路、故障箇所 | 同じ条件で異常が再現しない |
なぜ早く気付けなかったか | 監視漏れ、通知の抑制、報告の遅延 | テスト用の異常を担当者が受領できる |
なぜ被害が広がったか | 過大権限、ネットワーク接続、バックアップの不備 | 想定した範囲で操作・通信を止められる |
なぜ復旧に時間がかかったか | 承認待ち、手順不足、連絡不能、構成情報不足 | 演習で復旧手順を最後まで実行できる |
「再教育を実施した」「注意喚起を送った」は活動の記録です。対策の効果は、設定ミスを検査で止められたか、必要な人が通知を受け取れたか、復元できたかで評価します。対策を実施した後も同じ原因が再発するなら、運用担当は完了済みの問題チケットを再評価します。
報告しやすい受付と振り返り
端末紛失や誤送信の初報では、原因や責任より先に、対象と実施済み操作を聞き取ります。
報告者へ詳細な反省文を求めてから対応を始めると、封じ込めの機会を逃します。受付票を使って発生時刻、データの種類、送信先、端末の状態を集め、責任者が次の操作を指示します。善意のミスと意図的な規程違反の扱いは、復旧や被害抑制とは切り分けて判断します。
振り返りでは、うまく機能した制御も残します。誤送信が送信保留で止まったなら、保留時間と解除権限が適切だったかを検証します。未遂の報告にも対応結果を返すと、現場は何を知らせるべきか理解しやすくなります。
▶ 関連記事: シャドーAI事例と生成AI事故原因｜情シスが取るべき漏洩対策
インシデント管理の効果を測る指標
導入効果は、通知件数、受領時間、業務復旧時間、記録工数を別々に測定します。
指標 | 計測する内容 | 比較時にそろえる条件 |
|---|---|---|
MTTA | 運用規程で定めた開始点から担当者の受領までの時間 | 重大度、営業時間内外、通知対象 |
アラート重複率 | 同一事象の重複通知が占める割合 | 同一事象の定義、監視ルール |
MTTR | 運用規程で定めた開始点から終了点（業務再開など）までの時間 | 開始・終了点、対象サービス、影響規模 |
記録工数 | 転記、集計、報告書作成にかかった時間 | 対象帳票、チケット数、担当範囲 |
自動化の安全性 | 誤抑制、誤割当て、再オープンの件数 | 抽出方法とレビュー期間 |
試験導入前後で同じ長さの期間を確保し、大規模障害やリリース件数も併記します。通知を減らせても重大な見落としが増えたなら設定を戻します。改善が確認できた対象から段階的に広げ、契約数の増加をそのまま導入成功とは扱いません。
2026年の動向と管理ツール・SaaS台帳の整備
2026年の運用整備では、検知製品への投資と並行して、対応担当者・資産台帳・自動化の評価方法をそろえます。
EDR市場の拡大と検知後の運用
EDRの導入を進める場合は、検知件数より先に、受領・隔離・調査の担当を決めます。
ITRは2026年6月18日の市場発表で、2024年度のEDR市場の売上金額を352億4,000万円、前年度比13.3％増としています。これは2026年に公表された2024年度の市場実績であり、2026年度の売上ではありません。市場規模は、自社の被害発生率や製品の防御率を示す数値ではありません。
検知製品が増えると、同じ端末についてメール、ネットワーク、EDRから別々の通知が来る場合があります。運用担当は端末IDや利用者IDで関連付け、同一事案として調べます。自動隔離を使うなら、対象となる端末、業務停止の影響、解除権限を先に決めます。
AIOps・運用自動化の成長予測
AIOpsを採用するなら、通知集約から試し、影響の大きい復旧操作は検証を経て段階的に自動化します。
ITRのIT運用管理市場に関する調査では、AIOps／運用自動化分野の2024〜2029年度の年平均成長率を20.4％と予測しています。対象となる運用管理市場14分野の中で最も高い成長率という予測です。市場の成長予測と、個々の組織で得られる工数削減率は分けて扱います。
実務では、要約やチケット分類など、人が修正しやすい作業から始めます。アカウント停止や設定変更を自動実行するなら、対象の限定、承認、操作ログ、停止スイッチ、切り戻し手順をそろえます。AIが出した分類をそのまま法定報告の対象判定に使わず、法務担当が判断します。
表計算から専用ツールへの移行条件
専用ツールへの移行は、従業員数ではなく、引継ぎ・監査証跡・夜間対応を現在の方法で扱えるかで決めます。
管理方法 | 扱いやすい条件 | 注意点 | 次の行動 |
|---|---|---|---|
権限管理した表計算 | 低頻度で担当が明確、更新履歴を保存できる | 通知、同時対応、機密ごとの閲覧制限を別に設計する | 受付漏れと期限超過を定期的に点検 |
チケット管理 | 複数チームの引継ぎ、担当割当て、期限管理がある | 項目を増やしすぎると登録負荷が上がる | 必須項目を絞り、メール・フォームと連携 |
オンコール・通知管理 | 営業時間外の受領や無応答時の引継ぎが必要 | 当番不在や過剰通知はツール導入後も残る | 当番表、代替連絡先、通知抑制を設定 |
構成・資産情報との連携 | 複数サービスへの影響を判断する必要がある | 台帳が古いと誤った影響判断につながる | 所有者と更新ルールを決める |
選定時は、監視連携、権限分離、監査ログ、外部委託先の利用、データ保管、エクスポートを同じ軸で比べます。価格はライセンス単価だけでなく、連携設定、移行、当番運用、ログ保管の費用を見積もります。料金が公開されていない条件は要問合せとし、推測した月額で比較しません。
構成情報とインシデントの関連付け
資産台帳に所有者と依存関係があれば、障害時に影響を受ける業務と連絡先を追跡できます。
自社では、すべての情報を一度に移すより、重要サービスの所有者、稼働基盤、認証基盤、委託先から関連付けます。台帳の項目を増やしても更新する担当がいなければ古くなるため、変更完了時に誰が更新するかまで手順へ入れます。
SaaS管理台帳と障害対応の役割分担
SaaS管理台帳は契約・アカウント・管理者の把握に使い、障害の発生状況は各サービスの公式情報と照合します。
SaaSで問題が起きたら、公式ステータス情報とサポート告知を参照し、全体障害か自社環境の問題かを切り分けます。台帳では利用部署、管理者、認証方式、主要な連携先を確認します。SaaS管理ツールが、すべてのサービス障害をリアルタイムで検知するという前提にはしません。
シャドーITの調査では、サービスの存在を見つけた後に、利用者、保存データ、共有先を担当者が聞き取ります。契約やアカウントの可視化だけで漏えいの有無は決まりません。未承認利用の是正と、必要なセキュリティ調査を別々に進めます。
ログ取得と保管の実装条件
監査ログをAPIで取得できるなら自動収集し、取得できない場合は定期エクスポートと改変防止の保管を組み合わせます。
保存する項目には、時刻、利用者、対象データ、操作、アクセス元を含めます。時刻の基準やタイムゾーンが異なると調査の並べ替えを誤るため、収集時に記録します。エクスポート作業を人が行う場合は、担当不在時の代替者と実施記録を用意します。
保管期間は「長ければよい」とせず、調査、契約、法令、個人情報の保護を踏まえて決めます。機密性の高いログは閲覧者を絞り、調査用のコピーにもアクセス記録を残します。保存できているかは、過去の特定操作を検索して再現できるかで点検します。
インシデント対応体制を構築する次のステップ
まずは、連絡網と初報テンプレートを確認し、担当者を招集できる状態を整えます。
初日に着手する最小構成
最初の作業では、連絡先、起票条件、操作手順を一つの場所から参照できるようにします。
[ ] 情シス、セキュリティ、法務、業務責任者、契約ベンダーの連絡先と代替担当を登録します。
[ ] IPAの相談案内と、個人情報保護委員会への報告担当を対応手順書へ登録します。
[ ] 初報テンプレートをチケットやチャットへ保存し、入口となる受付窓口を社内へ知らせます。
[ ] P1〜P4の判定例と、自社の営業時間・SLAに合う初動目標を決めます。
[ ] 通常障害と不正アクセスの2例で、可用性優先・証跡保全優先の分岐を記入します。
初回訓練と改善項目の決定
机上訓練では、実際の連絡先と記入欄を使い、誰が何分で受領・判断できるかを試します。
「夜間に管理者の不審なログインを検知した」「主要SaaSへ全社でログインできない」の2例を使います。担当者へ連絡し、必要な情報をテンプレートへ記入し、隔離・復旧・法務判断を誰へ依頼するかまで進めます。電話番号だけでなく、代理担当が権限を持つか、ログへアクセスできるかも試します。
訓練後は、連絡不能、判断待ち、台帳不足を修正チケットへ登録し、それぞれに担当と期限を付けます。すべてを同時に解消しようとせず、重大事象で対応が止まる項目から直します。次回の訓練では修正箇所を再度試し、手順書を書いた時点ではなく実行できた時点で完了にします。
まとめ
インシデントは事故の前兆に限らず、発生済みのサービス停止や情報漏えいも含みます。情シスは、事象と影響を記録して優先度を決め、通常障害では復旧を、不正アクセスの疑いがあれば封じ込めと証跡保全を進めます。
技術相談と法定報告は別々に管理します。明日は、連絡網と初報テンプレートを用意し、担当者へ連絡が届くかを試します。その結果を基に、復旧手順、SaaS台帳、原因別の予防策を順に整えます。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
橋爪兼続
ライトハウスコンサルタント代表。2013年海上保安大学校本科第Ⅲ群（情報通信課程）卒業。巡視船主任通信士を歴任し、退職後、大手私鉄の鉄道運行の基幹システムの保守に従事。一般社団法人情報処理安全確保支援士会の前身団体である情報処理安全確保支援士会の発起人。情報処理安全確保支援士(第000049号)。
