>
>
公開日
最終更新日
インシデントとは何かを理解するには、一般用語、ITIL、情報セキュリティ、医療・製造などの領域を分けて考える必要があります。特に情シスでは、サービス停止だけでなく、不正アクセスの兆候、端末紛失、SaaSの設定不備、未承認の生成AI利用も管理対象になります。
この記事で確認したこと（確認日: 2026年08月25日）
ITILにおける定義、国内企業のツール導入事例、警察庁・IPA・個人情報保護委員会などの公表内容、2026年10月施行の制度、生成AIに関するインシデントを確認しました。数値は調査対象や測定条件を併記し、導入効果が他社でも再現されるとは限らない点を踏まえて解説します。
インシデントとは
インシデントとは、業務やサービスの正常な状態を乱す予期しない事象です。ITILでは、計画外のサービス中断またはサービス品質の低下を指します。
本記事のポイント
インシデントは事故の前兆だけでなく、すでに発生したサービス停止や品質低下も含みます。
アクシデントやヒヤリハットとの区分は業界で異なるため、自社の起票基準を定義します。
初動では原因究明より影響の抑制とサービス復旧を優先します。
システム障害、サイバー攻撃、シャドーIT、生成AIの誤利用を同じ受付窓口で記録します。
ITILと一般語における定義
一般語とITサービス管理では、インシデントが示す範囲に違いがあります。
英語のincidentには「出来事」「事案」「騒動」という意味があり、必ずしも大事故だけを指しません。日本のビジネス現場では、事故につながるおそれのある出来事や、業務に支障を与えたトラブルをインシデントと呼ぶのが一般的です。
一方、ITIL 4におけるインシデントは「計画外のサービス中断、またはサービス品質の低下」です。たとえば、社内ネットワークが30分停止した場合や、SaaSの応答が遅く受注処理が滞った場合は、すでに実害が発生していてもインシデントに該当します。「実害が出る前の兆候だけがインシデント」という説明は、ITILの定義には当てはまりません。
監視ツールが出したすべての通知も、直ちにインシデントになるわけではありません。CPU使用率の上昇を検知してもサービスへの影響がなければ、まずイベントとして扱います。利用者への影響、機密性・完全性・可用性への危険、対応の必要性を評価し、インシデントとして起票するかを決めます。
IT・情シスにおける管理対象
情シスでは、障害、セキュリティ、利用者の操作、外部サービスの問題を横断して管理します。
システム障害：サーバー停止、通信遅延、ログイン障害、バックアップ失敗、業務アプリケーションのエラー
セキュリティ事象：不正アクセス、マルウェア感染、フィッシングメールの開封、アクセス権限の誤設定、監査ログの消失
端末・アカウント：PCやスマートフォンの紛失、認証情報の漏えい、退職者アカウントの削除漏れ
SaaS・委託先：クラウドサービスの停止、委託先からの情報漏えい、未承認SaaSであるシャドーITの発覚
生成AI：機密情報の入力、誤情報の対外利用、プロンプトインジェクション、権限を越えたデータ参照
端末のネットワーク隔離は、被害拡大を止める「封じ込め」です。影響度と緊急度を評価して優先順位を決める「トリアージ」とは別の作業です。両者を手順書で分けると、感染端末を評価しただけで隔離したつもりになる運用ミスを防げます。
業界別の具体例
インシデントの判定基準は、IT、医療、製造、物流などの業界で異なります。
領域 | インシデントの考え方 | 具体例 | 最初の対応 |
|---|---|---|---|
IT・情報セキュリティ | サービスの停止・品質低下、または情報資産への脅威 | SaaS停止、不正ログイン、端末紛失 | 記録、影響評価、封じ込め、復旧 |
医療 | 患者への影響が発生した事象や、事故につながるおそれがあった事象 | 投薬量の入力誤り、患者情報の取り違え | 患者の安全確保、医療安全部門への報告 |
製造・OT | 設備、品質、作業者の安全を損なう異常 | 制御装置の停止、異物混入、センサー異常 | ライン停止、対象ロットの隔離、証跡保全 |
物流 | 配送品質、荷物、交通安全に影響する事象 | 誤配送、温度逸脱、車両事故 | 荷物の追跡、顧客連絡、運行管理者への報告 |
同じ「インシデント」という言葉でも、実害の有無や報告先は一致しません。自社の規程では、対象、起票条件、重大度、連絡期限、クローズ条件をセットで定義します。
インシデントとアクシデント・ヒヤリハットの違い
3つの用語は実害、サービスへの影響、発見時点を基準に区別できますが、すべての業界に共通する固定的な上下関係はありません。
用語 | 基本的な意味 | IT・情シスの例 | 実害の扱い |
|---|---|---|---|
インシデント | 正常な業務やサービスを乱す事象、またはセキュリティを脅かす事象 | システム停止、認証障害、不正アクセス、設定ミスによる公開 | 実害がない場合と、すでに停止・漏えいが起きている場合の両方を含む |
アクシデント | 人身、物理、金銭、信用などの損害が現実化した事故 | 顧客情報の外部流出、工場設備の破損、従業員の負傷 | 原則として実害あり |
ヒヤリハット | 事故には至らなかったものの、危険を感じた事象 | 誤送信直前の宛先修正、機密ファイルを公開フォルダへ移す直前の発見 | 実害なし。ただし再発防止の記録対象 |
IT現場における切り分け基準
情シスでは、名称の議論よりも起票と連絡の要否を判断できる基準が役立ちます。
サービス影響の判定：利用不能、遅延、誤表示が発生していればインシデントとして起票します。
情報資産への影響判定：不正閲覧、改ざん、消失のおそれがあれば、実害を確定できなくてもセキュリティインシデントとして扱います。
事故の判定：人身被害、情報漏えい、金銭損失などが確定した場合は、社内規程に従ってアクシデントや重大インシデントへ格上げします。
未遂の判定：送信前にミスへ気付いた場合などはヒヤリハットとして記録し、同種事象の件数を集計します。
たとえばフィッシングメールを受信しただけであればイベント、リンクを開いたが認証情報を入力していなければインシデント、認証情報が窃取され不正送金まで発生すれば重大インシデントまたはアクシデントと分類できます。ただし、メール受信だけでも全社的な攻撃が疑われる場合は、インシデントとして調査を開始します。
業界ごとに異なる用語運用
医療安全、労働安全、ITILでは、インシデントとヒヤリハットの包含関係が一致しません。
ハインリッヒの法則を引用し、「ヒヤリハット、インシデント、アクシデントの順に必ず発展する」と説明するのは正確ではありません。重大事故が予兆なく発生する場合もあり、ITILではサービス停止そのものをインシデントと呼びます。法則は小さな兆候を収集する意義の説明には使えますが、用語定義の根拠には使わない運用が適切です。
社内で名称が統一されていない場合は、「何をインシデントと呼ぶか」だけでなく、「どの条件で誰へ何分以内に連絡するか」を規程へ記載します。実害が未確定でも、個人データの漏えいのおそれやマルウェア感染があれば、確定を待たずにセキュリティ担当へ連絡する基準にします。
▲ インシデント・アクシデント・ヒヤリハットの実害とサービス影響による違い
インシデントの具体的な使い方・例文
インシデントという言葉は、事象の報告、優先度の共有、担当者への引き継ぎ、復旧後の再発防止で使います。
IT・情シスにおけるトリアージの例文
トリアージでは、影響度、緊急度、対象システム、情報漏えいのおそれを具体的に伝えます。
「全社員が会計SaaSへログインできないため、影響度は高、緊急度は高として重大度P1のインシデントを起票します」
「不正アクセスの可能性がある端末をネットワークから隔離しました。隔離は封じ込め措置であり、トリアージ結果は調査中です」
「対象は営業部の3名で、代替手段を利用できます。優先度P3として担当者へ割り当て、2時間後に進捗を再評価します」
「個人データが含まれる可能性があるため、漏えいの確定を待たずにセキュリティ責任者と法務へエスカレーションします」
障害報告と復旧連絡の例文
障害報告では、判明している事実と未確認事項を分けると、推測が社内外へ拡散するのを防げます。
初報の例文
本日10時15分から、受注管理システムで注文登録が完了しないインシデントが発生しています。影響範囲は国内拠点の利用者で、閲覧機能は利用可能です。原因は調査中です。現在は手動受付へ切り替えており、次回報告は11時00分を予定しています。
復旧報告の例文
10時15分に発生した受注登録インシデントは、11時08分に復旧を確認しました。原因はアプリケーション更新時の設定不整合です。未処理データの再登録を実施し、12時までに整合性を確認します。恒久対策は問題管理へ引き継ぎます。
初報に原因を断定してはいけません。「データベース障害と思われます」と推測を書く代わりに、「データベース接続エラーを検知しており、原因との関係を調査中です」と事実と判断を分けます。
重大インシデントの使い分け
重大インシデントは、経営判断や全社的な対応を伴う事象に限定して使います。
たとえば、基幹システムの全面停止、ランサムウェア感染、顧客情報の漏えい、決済停止、法令報告が必要となる事象が該当します。重大度は件名の印象で決めず、影響する利用者数、停止時間、売上への影響、機密情報の種類、安全への影響を点数化します。
「本件は顧客向け決済を停止させているため、重大インシデントとして危機対策チームを招集します」
「漏えい対象に要配慮個人情報が含まれる可能性があり、重大インシデントとして証跡保全を開始します」
「復旧後も同じ障害が3回発生しているため、重大問題として問題管理へ移管します」
一般的なビジネスシーンの例文
IT以外でも、顧客対応、製造、物流、労務などのトラブル報告に利用できます。
「請求書を別の取引先へ送付するインシデントが発生したため、送信取消しと先方への削除依頼を行いました」
「倉庫の温度が管理基準を超過したインシデントについて、対象ロットを出荷停止にしました」
「同じ入力ミスが月4件発生しているため、個人への注意ではなく入力画面の制御を見直します」
「今回のインシデントレビューでは、担当者の責任追及ではなく、検知と承認の仕組みを検証します」
そのまま使えるインシデント報告テンプレート
報告項目を固定すると、夜間や緊急時でも必要な情報を短時間で共有できます。
発生・検知日時：
報告者と連絡先：
対象システム・業務：
発生している事象：
影響範囲と利用可能な代替手段：
個人情報・機密情報の関与：
実施済みの封じ込め措置：
現在の担当者と次回報告時刻：
保存したログ・画面・端末：
復旧判定者とクローズ条件：
口頭やチャットで初報を受けた場合も、この項目をチケットへ転記します。後から発生時刻を書き換えず、判明した時刻と訂正理由を追記すると、監査証跡を維持できます。
インシデント管理の目的と問題管理との違い・対応手順5ステップ
インシデント管理の目的はサービスを早く正常状態へ戻すことであり、問題管理の目的は根本原因を除去して再発を防ぐことです。
インシデント管理と問題管理の役割
復旧と原因究明を別のプロセスに分けると、調査のために業務停止が長引く失敗を避けられます。
比較軸 | インシデント管理 | 問題管理 |
|---|---|---|
主な目的 | サービスの迅速な復旧と影響の最小化 | 根本原因の特定と再発防止 |
開始時点 | 障害や異常を検知した時点 | 復旧後、または同種インシデントの反復を確認した時点 |
代表的な対応 | 切り戻し、代替経路、端末隔離、回避策の案内 | ログ分析、構成変更、設計改修、既知エラーの管理 |
終了条件 | 利用者が業務を再開し、復旧を確認した状態 | 原因と恒久対策を検証し、残余リスクを承認した状態 |
主なKPI | MTTA、MTTR、SLA達成率 | 再発率、未解決問題数、恒久対策の期限超過率 |
サーバー再起動で業務が再開できるなら、まずインシデントを復旧状態にします。ただし、再起動により揮発性ログが消えるおそれがあるセキュリティ事案では、証跡保全と封じ込めを先に実施します。可用性だけでなく、調査可能性を含めて初動を決めます。
優先度を決めるトリアージ基準
優先度は、影響度と緊急度の組み合わせで決め、担当者の主観に依存させません。
重大度 | 判断例 | 初動目標 | 主な連絡先 |
|---|---|---|---|
P1 | 全社停止、重大な漏えい、安全への影響、ランサムウェア | 5分以内に確認し、15分以内に責任者を招集 | 情シス責任者、セキュリティ、法務、経営 |
P2 | 重要部門の停止、複数顧客への影響、代替手段なし | 15分以内に確認し、30分以内に対応方針を決定 | システム責任者、業務部門、ベンダー |
P3 | 一部利用者への影響、代替手段あり | 営業時間内に担当者を割り当て | 運用担当、サービスデスク |
P4 | 軽微な表示不良、問い合わせ、将来の改善候補 | 通常のチケット順に処理 | 保守担当、製品担当 |
この時間は運用例であり、一律の業界基準ではありません。24時間の顧客サービスならP1を5分以内、営業時間内の社内システムなら15分以内など、契約上のSLAと業務停止コストから自社値を設定します。
インシデント対応の5ステップ
受付からクローズまでの担当者、期限、証跡を一つのチケットで管理します。
受付・検知：監視アラート、利用者の連絡、委託先の通知を受け、発生時刻、対象、症状を記録します。セキュリティ事案ではログや画面を上書きしない形で保全します。
分類・優先度付け：影響度と緊急度を評価するトリアージを行い、P1からP4などの重大度、担当チーム、次回報告時刻を決めます。
初期対応・封じ込め：Runbookに沿って切り戻し、代替経路への切替え、アカウント停止、感染端末の隔離を実施します。端末隔離はトリアージではなく封じ込めです。
エスカレーション・復旧：一次対応で解決しなければ専門チームやベンダーへ引き継ぎます。復旧後は監視値だけでなく、利用者の操作とデータ整合性を確認します。
クローズ・振り返り：復旧判定者が正常性を承認し、対応履歴、影響、原因の暫定評価を記録します。再発、重大事象、手順不備のいずれかに該当すれば問題管理へ移します。
MTTA・MTTRによる対応品質の評価
平均値だけでなく重大度別の中央値と上位10％の所要時間を測ると、長時間化した事案を把握できます。
MTTA：検知から担当者が確認し、対応責任を引き受けるまでの平均時間です。
MTTR：組織によって修復、復旧、解決の意味が異なるため、計測開始点と終了点を明文化します。本記事では検知から利用者の業務再開までとします。
再発率：同じ原因によるインシデントが一定期間内に再発した割合です。
変更起因率：リリースや設定変更に起因したインシデントの割合です。
月平均だけを追うと、P1が1件だけ長期化した問題を見落とします。「P1のMTTA中央値」「P1の最長MTTR」「営業時間外の未応答率」のように分解し、当番設計、通知経路、Runbookのどこを直すかへつなげます。
▲ インシデント発生時における初動対応（可用性優先 vs 証跡保全優先）の分岐フロー
▲ インシデント発生からサービス復旧・恒久対策（問題管理）までの5段階手順
インシデント管理で陥りやすい失敗パターンと対策
インシデント管理が機能しない主因は、ツール不足だけでなく、復旧と調査の混同、通知過多、報告者を責める文化、生成AIの無許可利用です。
原因究明を優先する復旧遅延
障害対応中に根本原因の特定へ集中すると、切り戻しや代替手段の案内が遅れます。
通常障害では復旧担当と原因調査担当を分け、サービス再開を先に進めます。ただし、再起動で証拠が失われるセキュリティ事案では、ログ、メモリ、通信状況を保全してから操作します。Runbookに「可用性優先」と「証跡保全優先」の分岐を設けると、現場で判断できます。
個人の注意に依存する再発防止
メール誤送信や設定ミスを当事者の注意不足だけで処理しても、同じ操作環境が残るため再発します。
宛先の外部ドメイン警告、機密ラベル、承認フロー、最小権限、設定変更の自動検査を組み合わせます。「再教育を実施した」を恒久対策の完了条件にせず、ミスをしても被害へ直結しない仕組みが動作するかをテストします。
表計算ソフトによる管理の過信
Excelやスプレッドシートは低頻度の管理に使えますが、同時対応、権限制御、自動通知、監査証跡が必要になると限界が表れます。
月数十件や従業員300名といった一律の導入基準には、十分な根拠がありません。件数が少なく、担当者が固定され、更新履歴を保持できるなら表計算でも運用できます。夜間対応がある、複数チームへ引き継ぐ、SLAを測る、機密情報ごとに閲覧権限を分ける、対応漏れが発生している、のいずれかに該当するならチケット管理へ移します。
アラート疲れによる見落とし
アラート疲れとは、大量の通知によって担当者の注意力が低下し、本当に対応すべき通知を見落とす状態です。
通知先を増やすだけでは改善しません。重複アラートの集約、同じ原因から派生した通知の相関分析、営業時間外に起こす条件、無応答時のエスカレーション先を設定します。AIOpsを使う場合も、自動抑制した通知を月次でサンプリングし、重大事象が誤って除外されていないかを検証します。
心理的安全性の不足による報告遅延
報告者が処罰や叱責を恐れる環境では、端末紛失や誤送信の連絡が遅れ、封じ込め可能だった事象が重大事故へ発展します。
No Blame Cultureは責任を問わない制度ではありません。善意のミスと意図的な規程違反を分け、早期報告を評価し、復旧後に仕組みを見直す文化です。初報時に原因や責任を追及せず、発生時刻、対象、実施済み操作を聞く質問票へ統一します。
生成AIの過信とシャドーAI
未承認の生成AIへ機密情報を入力するシャドーAIと、出力を検証せず利用する運用は、漏えいと誤情報の両方を生みます。
生成AIへの入力が学習へ使われるかは、サービス、契約プラン、管理者設定、オプトアウト状況で異なります。それでも外部事業者へデータを送信する事実は残るため、個人アカウントへの業務データ入力を禁止し、利用可能な法人契約、入力可能な情報、保持期間、監査ログ、出力の承認者を定義します。
プロンプトインジェクション対策では、外部文書やWebページに埋め込まれた指示を信用せず、AIが参照できるデータと実行できる操作を分離します。メール送信、データ削除、支払いなどの操作は、人の承認なしに実行できない権限設計にします。
専用ツールによるインシデント管理の導入事例
専用ツールは通知、担当割当て、エスカレーション、記録を自動化できますが、公開事例の効果は対象業務と導入前の運用条件を含めて読み取る必要があります。
株式会社NTTドコモのPagerDuty導入
NTTドコモの事例では、大量の監視通知を集約し、初動を自動化した成果が公開されています。
業種・規模：通信事業。対象システムや利用者数の詳細は公開事例の範囲では限定されています。
導入時期：公開情報で明確な導入年月を確認できないため、導入時期は非掲載です。
課題：月間約1万件のアラートが発生し、ノイズ処理と夜間の属人的な呼び出しが運用負担になっていました。
施策：PagerDutyのルールエンジンで重複・不要通知を集約し、担当者への通知とエスカレーションを自動化しました。
成果：PagerDutyが公開するNTTドコモの導入事例では、アラートを月1万件から1,000件へ90％削減し、初動を数時間から3分へ短縮したと説明しています。
この数値は同社の特定業務におけるベンダー公開事例です。自社で再現性を判断する際は、導入前のアラート件数、重複率、オンコール人数、MTTAを4週間測り、試験導入後と同じ条件で比較します。
日本電気株式会社の運用基盤統合
NECは、多数の社内システムを対象にインシデント管理基盤と運用手順の標準化を進めています。
業種・規模：ITサービス・製造。対象は社内約1,000システムと公表されています。
導入時期：段階的な運用DXとして展開されており、全体の単一導入日は公開情報で確認できません。
課題：システムごとに異なる運用手順、対応履歴の分散、調査作業の属人化がありました。
施策：ServiceNowとPagerDutyを組み合わせ、記録・チケット管理とリアルタイム通知を連携しました。
成果：インシデント対応と調査業務を共通基盤へ集約し、自動化できる作業と人が判断する作業を切り分けています。PagerDutyが2024年3月に公開したプレスリリースでは、アラート数を約70％削減し、インシデント解決時間を半減する見込みと説明しています。
定量値が公開されていない事例では、製品導入だけを成功条件にしません。チケット自動起票率、手動転記時間、未割当て件数、再オープン率を導入前後で測れる場合に効果を判定します。
株式会社ココナラのオンコール分散
ココナラは、特定チームへ集中していた障害対応を開発・プロダクトチームへ分散しました。
業種・規模：スキルマーケット運営。対象チームの人数は公開記事で固定値を確認できません。
導入時期：公開記事に記載された運用改善期間を基準とし、全社導入年月は未確認です。
課題：一部の運用担当へオンコール負担が集中し、インシデントを認知するまで時間がかかっていました。
施策：PagerDutyで通知と架電を自動化し、各開発チームが担当サービスのオンコールを担う体制へ変更しました。
成果：ココナラが公開したPagerDuty導入に関する公式技術記事では、MTTAを10分から1分へ短縮したと報告しています。
株式会社NTTデータ九州のServiceNow導入
NTTデータ九州は、多拠点から届く問い合わせとインシデントの登録作業を自動化しました。
業種・規模：ITサービス。対象業務では全国150以上の拠点と連携しています。
導入時期：公開事例に記載されたプロジェクト時期を基準とし、追加展開の時期は確認が必要です。
課題：問い合わせやエラーを手作業で登録し、拠点間の進捗共有に時間がかかっていました。
施策：ServiceNowでインシデント登録と進捗管理を共通化しました。
成果：ServiceNowのNTTデータ九州の導入事例では、登録時間を1件当たり5分、月間約40時間削減したと説明しています。運用業務全体の30％削減は目標値であり、確定した実績値とは分けて読む必要があります。
国内損害保険会社のLMIS導入
国内損害保険会社の事例では、表計算ソフトからITIL準拠の管理基盤へ移行しています。
業種・規模：金融・保険。企業名と対象人数は事例ページで非公開です。
導入時期：公開情報で特定できません。
課題：インシデント件数の増加により、Excelでの進捗管理と経営報告の作成が煩雑になっていました。
施策：LMIS on cloudへ情報を集約し、集計、グラフ作成、タスク通知を自動化しました。
成果：株式会社クエストのLMIS導入事例一覧では、報告書作成時間を約7分の1へ短縮し、対象業務の対応漏れ・遅れをゼロにした事例を掲載しています。
製品を選ぶ際は、インシデント件数よりも、監視ツールとの連携、監査ログ、権限分離、オンコール、外部委託先の利用、データ保管場所を比較します。APIで監査ログを取得できるなら自動収集へ進み、取得できなければ改変防止を設定したCSV保管と月次照合へ切り替えます。
最新のセキュリティ被害実態と2026年の法改正・脅威動向
2026年はランサムウェアとサプライチェーン攻撃に加え、生成AIの業務利用や攻撃への悪用をインシデント管理へ組み込む必要があります。
国内企業が直面する被害額と発生率
調査・復旧費用だけで1,000万円を超える事案が増えており、身代金以外の停止損失も予算化する必要があります。
警察庁の2025年調査では、ランサムウェア被害後の調査・復旧費用が1,000万円以上だった回答組織は59％と報告しています。費用にはフォレンジック調査、端末再構築、バックアップからの復元、外部専門家への委託などが含まれます。
JNSAが2024年に公開したレポートは、ランサムウェア被害の平均被害額を2,386万円、クレジットカード情報などを含む漏えいの平均被害額を3,843万円と報告しています。事故対応と事業中断を含めると5,700万～8,000万円規模となる試算もありますが、平均値は調査対象、被害の定義、身代金を含むかによって変わります。自社では「停止1時間当たりの粗利益」「外部調査費」「通知・コールセンター費」「再構築費」を分けて試算します。
JIPDECとITRが実施した「企業IT利活用動向調査」（2021年調査）では、過去1年間にインシデントを経験していない企業は22.7％でした。裏返すと約77％が何らかの事象を経験しており、最も多い類型は従業員によるデータや機器の紛失・盗難です。攻撃者だけでなく、日常業務の端末・データ管理も対策範囲に含めます。
デジタルアーツは国内セキュリティインシデントの調査資料で、2025年に公表された国内事案を1,782件と集計しています。同社の集計基準に基づく値であり、未公表事案や同一事案の数え方によって政府統計とは一致しません。
2026年10月施行の能動的サイバー防御法
能動的サイバー防御に関する制度では、基幹インフラ事業者の資産届出、インシデント報告、官民の情報共有が強化されます。
政府は2025年5月に「重要電子計算機に対する不正な行為による被害の防止に関する法律」と関連整備法を成立させ、2026年10月1日から主要規定を施行します。電力、通信、金融など基幹インフラ15分野の指定事業者には、特定重要電子計算機に関する届出や一定のインシデント報告が課されます。対象や手続は、内閣官房のサイバー安全保障分野の制度資料と施行時の政省令で判定します。自社が指定対象か、どの報告義務が生じるかは政省令・所管省庁資料の条文を確認した上で判断してください。内容によって対象外となる場合もあり、法的な適用判断は専門家へ相談することで適切な対応方針が決まります。
直接の指定対象でないSaaS事業者、システム保守会社、業務委託先にも影響があります。指定事業者との契約に報告期限、保存するログ、初報項目、再委託先からの連絡、証拠保全、監査協力を記載します。契約に24時間以内の初報条項があればその時間で連絡網を設計し、条項がなければ自社基準を先に設定して契約更新時に合意します。
258事業者や最大200万円の罰則という数値は、対象行為と条文上の義務を分けて読む必要があります。資産届出、事故報告、情報提供では適用条件が異なるため、自社が指定対象か、対象システムが特定重要電子計算機か、委託先として何を報告するかを一枚の対応表に整理します。
IPAが挙げるAI利用のサイバーリスク
生成AIは攻撃メールの作成だけでなく、機密情報の入力、誤情報、権限の悪用を通じて企業側にもインシデントを生みます。
IPAの情報セキュリティ10大脅威 2026は、組織編の1位をランサム攻撃、2位をサプライチェーンや委託先を狙った攻撃、3位を「AIの利用をめぐるサイバーリスク」としています。AIリスクは2026年版で初選出され、3位に入りました。
AI関連インシデントは、次の3つに分けると対策を設計しやすくなります。
入力による漏えい：従業員が個人契約の生成AIへ顧客情報、契約書、ソースコードを入力するシャドーAI
出力による損害：ハルシネーションで生成された架空の制度、判例、製品仕様を検証せず対外提供する事象
操作・参照権限の悪用：プロンプトインジェクションにより、AIが非公開情報を参照したり、意図しない外部操作を実行したりする事象
Air Canadaでは、Webサイトのチャットボットが誤った割引・返金条件を案内し、カナダの民事紛争解決機関が2024年に企業側の責任を認めました。AIの出力であっても、企業が顧客へ提供した情報として扱われる点が実務上の教訓です。
Deloitte Australiaは、生成AIを利用した政府向け報告書に誤った引用や参照が含まれていたとして、報告書を修正し、契約代金の一部返金に応じました。自動生成した資料では、出典URLの存在確認だけでなく、引用箇所が原文に存在するかを人が照合します。
サプライチェーンを含む予防・再発防止チェックリスト
自社の防御だけでなく、委託先、SaaS、生成AI、バックアップまでを一つのインシデント対応計画に含めます。
IPAの中小企業の情報セキュリティ対策ガイドラインも参照し、次の項目を点検します。
[ ] 多要素認証を管理者、リモートアクセス、メール、主要SaaSへ適用している
[ ] オフラインまたは論理的に隔離したバックアップを保持し、復元テストを実施している
[ ] 委託先との契約に初報期限、再委託、証跡保全、連絡先を記載している
[ ] 退職者、異動者、休眠アカウントを定期的に無効化している
[ ] 利用中のSaaSとシャドーITを棚卸しし、管理者とデータ種別を記録している
[ ] 生成AIの許可サービス、入力禁止情報、保持設定、監査ログを定義している
[ ] P1インシデントを想定した机上訓練を年1回以上行い、連絡不能者と手順の欠落を記録している
[ ] 復旧後レビューで原因、検知の遅れ、封じ込め、再発防止策の担当期限を決めている
よくある質問
法的報告、生成AI、SaaS障害、ツール導入、言葉の読み方に関する疑問へ簡潔に回答します。
情報漏えいが発生した場合の報告義務
Q：個人データの漏えいが発生したら、必ず行政機関へ報告しますか？
A：すべての誤送信が報告対象になるわけではありませんが、要配慮個人情報、不正利用による財産的被害のおそれ、不正目的の行為、1,000人を超える漏えいなど、個人情報保護法上の要件に該当する場合は個人情報保護委員会への報告と本人通知が必要です。速報は発覚からおおむね3～5日以内、確報は原則30日以内で、不正目的の行為が関係する場合は60日以内が基準です。
委託先が漏えいを把握した場合、委託元へ必要事項を通知することで委託先自身の報告義務が免除される場合があります。対象条件と届出様式は、個人情報保護委員会が公開する「個人情報の保護に関する法律についてのガイドライン（通則編）」および「リスクに応じた個人データ等の適切な取扱いに関するQ&A」（個人情報保護委員会公式サイト内で参照可）で確認します。該当すれば法定報告へ進み、該当しなくても社内記録と再発防止は継続します。
生成AIへ入力した情報の学習利用
Q：生成AIへ入力した機密情報は、必ずAIの学習に使われますか？
A：必ず学習へ使われるとは限りません。学習利用、保存期間、人による閲覧、第三者提供の条件は、サービス、法人・個人プラン、管理者設定、オプトアウト状況によって異なります。
契約で学習不使用と監査ログを確認できれば承認済み環境で限定利用し、確認できなければ個人情報、顧客データ、ソースコードを入力しない運用へ切り替えます。出力にはハルシネーションが含まれ得るため、対外資料は人が原典と照合します。
利用中SaaSに障害が起きた場合の確認方法
Q：利用中SaaSで障害が発生した場合、どこで状況を確認できますか？
A：対象サービスの公式ステータスページと公式サポート告知を最初に参照し、自社だけの問題かサービス全体の問題かを切り分けます。公式情報に障害がなければ、認証ログ、ネットワーク、端末、IDプロバイダーの順に確認します。
SaaS管理ツールで契約、アカウント、管理者、シャドーITを可視化しておくと、影響を受ける利用者と連絡先を特定しやすくなります。ただし、SaaS管理ツールが各サービスの稼働状況を必ずリアルタイム検知するわけではないため、公式ステータス情報との併用が前提です。
インシデント管理ツールの導入判断
Q：どの程度の企業規模になったら専用ツールを導入しますか？
A：従業員数ではなく、夜間対応、複数チームへの引継ぎ、SLA、権限制御、監査証跡、対応漏れの有無で判断します。単一担当で低頻度なら権限管理した表計算でも運用でき、無応答や転記漏れが発生しているなら件数が少なくてもチケット管理と自動通知へ移します。
incidentの読み方と意味
Q：「いんしでんと」やincidentとは、どのような意味ですか？
A：incidentは「出来事」「事案」「騒動」を意味し、日本語ではインシデントと表記します。ローマ字入力で見かける「innsidennto」は英単語ではなく、日本語の読みを入力した表記です。
IT分野では、計画外のサービス中断またはサービス品質の低下を意味します。事故の前兆だけに限定せず、自社の起票条件と重大度を定義して使います。
まとめ
インシデント対応体制を構築する次のステップ
インシデント対応では、発生をゼロにする目標より、早く検知し、封じ込め、復旧し、再発を減らす仕組みを整えます。
まず整えるべき最小構成（規模・業種を問わず）：起票基準の文書化、優先度と連絡先の設定、端末隔離・証跡保全のRunbook作成の3点が出発点です。規制業種・高度な運用向けの追加対応：能動的サイバー防御法の対象判定、委託先への報告期限の契約明記、SLA・MTTA・MTTRの重大度別計測、生成AI利用の監査ログ整備が次の段階となります。明日から着手する項目は次の通りです。
[ ] 自社におけるインシデント、重大インシデント、ヒヤリハットの起票基準を文書化する
[ ] P1からP4までの優先度、初動時間、連絡先を決める
[ ] 端末隔離、アカウント停止、切り戻し、証跡保全のRunbookを作成する
[ ] MTTAとMTTRを重大度別に測り、長時間化した事案を振り返る
[ ] SaaS、委託先、シャドーIT、生成AIを含めた机上訓練を実施する
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
橋爪兼続
ライトハウスコンサルタント代表。2013年海上保安大学校本科第Ⅲ群（情報通信課程）卒業。巡視船主任通信士を歴任し、退職後、大手私鉄の鉄道運行の基幹システムの保守に従事。一般社団法人情報処理安全確保支援士会の前身団体である情報処理安全確保支援士会の発起人。情報処理安全確保支援士(第000049号)。
