本章では、インシデントを招く事象の発生は避けられないという前提に立ち、インシデントを「失敗」ではなく「学習と改善の機会」として捉え、効果的な対応と振り返りを通じてシステム品質を継続的に改善するアプローチを説明する。

事前に計画した体制に基づき、職員と事業者が協働して迅速に対応し、リアルタイムで情報を共有する。そして建設的な振り返りを通じて根本原因を特定し、技術的な恒久対策を実施することで、同様の問題の再発を防ぎシステムの信頼性を継続的に向上させる。重要なのは、発生したインシデントから最大限の学びを得て、組織全体の対応力を向上させることである。

2.1 インシデント対応と振り返りの重要性

2.1.1 本ガイドにおけるインシデントの定義

はじめに、本ガイドにおける「事象」「インシデント」「非インシデント」および「インシデント対応チーム」の定義を説明する。

「事象」「インシデント」「非インシデント」の定義

本ガイドでは、システム運用中に発生するあらゆる出来事を「事象」と呼ぶ。事象はさらに、サービス提供への影響の有無により、「インシデント」と「非インシデント」に分類するものと定義する。

図2-1に、本ガイドにおける事象、インシデント、非インシデントの関係性を示す。

図2-1 本ガイドにおける 事象、インシデント、非インシデントの関係性

「事象」の定義

システム運用中に発生するあらゆる出来事を「事象」と呼ぶ。正常な動作によるものも、異常な状態や障害も含む。これらの事象は、サービス提供への影響の有無により、次に説明する「インシデント」または「非インシデント」に分類される。

「インシデント」の定義

事象のうち、「サービス提供に影響を及ぼしたもの」 と定義する。

具体的には、システムのパフォーマンスや可用性に影響を与え、その結果としてユーザーやサービスの利用に支障をきたした事象を指す。また障害の兆候に偶然気づき対処しサービスへの影響は防げたなど、実害発生はなかったが一歩間違えば重大な事故・障害につながる可能性があるヒヤリハット事象も、重大事象の兆候としてインシデントに含まれるものと定義する。

本章では、これらインシデントへの対応と振り返りを中心に扱う。なお、本ガイドでは「インシデント」を包括的な概念として使用している。一般的に「システム障害」と呼ばれるものも、インシデントの一種として位置づけている。

インシデントの例

• システム起因のインシデント（システム障害）:
  • ネットワークの遅延や接続の喪失により、一部または全てのユーザーがサービスにアクセスできない(*1)。
  • サーバーやハードウェアの故障により、一部または全てのサービスが停止する(*1)。
  • ソフトウェアのバグやクラッシュにより、一部または全ての機能が利用できない。
  • リソース不足などにより、システムのパフォーマンスが劣化し一部または全てのユーザーのサービス利用が支障をきたす。
  • 誤操作などの人為的ミス起因で、データ消失やサービス停止が発生する。
  • 信頼性設計観点で冗長化構成に検討漏れにより単一故障点があり、その箇所が障害となったが、たまたまサービス提供時間外であり実害を免れた(ヒヤリハット)。
  • 本番環境での危険な操作が実行されたが、影響が出る前に気づいて取り消したことで実害はなかった(ヒヤリハット)。
• セキュリティ起因のインシデント:
  • セキュリティ侵害やマルウェア感染により、サービスが停止または機能が制限される。
  • 不正アクセス試行が成功し、サービスに影響が及ぶ。
  • 内部犯行・外部犯行によるデータ漏洩が発生し、サービス停止などの対応が必要となる。
  • ソーシャルエンジニアリング攻撃により、システムへの不正な変更が行われる。

(*1) 信頼性設計で冗長化や自動復旧、クライアントからのリトライ等を織り込んだことにより、サービス提供に影響が生じなかったものは、次に説明する非インシデントに該当するものと定義する

「非インシデント」の定義

事象のうち、「サービス提供に影響を及ぼさなかったもの」を「非インシデント」 と定義する。

これは、冗長化や自動復旧などのシステム設計により、障害や異常が発生してもサービス提供への影響を回避できた事象を指す。事象を非インシデント化するための対応は、「3.6 障害対応の自動化とリモート化」で扱う。

非インシデントの例

• 冗長化により影響が吸収されるケース:
  • 冗長化されたWebサーバーの1台が停止したが、他のサーバーが処理を継続し、ユーザーには影響がなかった。
  • ネットワーク経路の一つが障害で通信できなくなったが、経路が冗長化され自動的に健全な経路で通信が再送されたため、サービス提供には影響がなかった。
• 自動縮退・自動復旧により影響が最小化されるケース:
  • ロードバランサーが故障したサーバーを自動的に切り離し、ユーザーには影響がなかった。
  • アプリケーションのヘルスチェックが異常を検知し、自動再起動により即座に復旧した（ユーザーからのリクエストに影響なし）。
  • オートスケールが負荷増加を検知し、自動的にリソースを追加した結果、レスポンス時間の悪化が回避された。
• 監視・早期発見により影響を未然に防いだケース:
  • ストレージ容量の増加傾向を監視が検知し、サービス影響が出る前に容量を拡張した。
  • セキュリティスキャンが脆弱性を検出し、攻撃を受ける前にパッチを適用した。

非インシデントは、サービス影響がないため本ガイドで定義する「インシデント」には分類されない。ただし、以下の理由から運用の記録として残し、分析対象とすることが望ましい。

• 同様の事象が頻発する場合、システムの潜在的な問題を示唆している可能性がある。
• 冗長化や自動復旧の仕組みが適切に機能していることの確認に有用である。
• 将来的にサービス影響につながるリスクがある場合、予防的な改善の根拠となる。

特に、非インシデントが短期間に繰り返し発生する場合や、複数の非インシデントが同時に発生した場合は、次に同様の事象が発生した際にインシデントへ発展するリスクが高まるため、予防的な対策を検討することが重要である。

「インシデント対応チーム」の定義

上記で定義した「インシデント」の発生時に、原因究明とサービスの早期復旧を行う担当者の集まりのことを本ガイドでは「インシデント対応チーム」と呼ぶ。

一般に「インシデント対応チーム」は、セキュリティインシデントを対応するチームであるCSIRT（Computer Security Incident Response Team）と同義で扱われることが多い。しかし、本ガイドではシステム障害対応も含め、サービス提供に支障をきたすインシデント全般を対応するチームとして「インシデント対応チーム」の呼称を使用する。

2.1.2 インシデント対応の重要性

システム品質を維持・向上させるためには、インシデント発生時の迅速な対応によるサービス復旧と利用者へのリアルタイムでの適切な情報提供により利用者の利便性低下を最小限の範囲にとどめるよう努めることや、発生したインシデントに対して振り返りを行い、事象の再発を防止または抑止することおよび事象が再発した場合の影響を最小限にとどめるための技術的な施策（恒久対策/抜本的対策）を行うことが重要である。

その理由として、システム品質を上げる取り組みとして、(a)システムの設計・実装段階で全ての障害ケースを網羅した作り込みや、(b)テスト段階での完全な問題の摘出、(c)仮にインシデントが発生した際にサービスへの影響を限りなくゼロに近づけようとする試み、などインシデント発生を未然に防ぐ、またはインシデント発生による影響をゼロにすることに傾倒した対応は、コストの指数関数的な増加をもたらす非現実的なアプローチだからである。システム品質の向上とコスト適正化を両立するためには、設計・構築段階でのシステム信頼性設計と実装の作り込み、並びにテスト段階での不具合の抽出・修正による品質向上を一定程度達成することが必要である。それに加え重要なことは、リリース後にインシデントが一定程度発生することを前提に、迅速なインシデント対応の実現と事後の振り返りによる技術的な恒久対策によるシステム品質の継続的改善活動を進めることが肝要である。

2.1.3 さらなる品質向上に向けた提案

本項目では、一般的なインシデント対応フローを示した上で、インシデント対応の品質をさらに向上させるための改善機会を例示し、それらの改善機会に対する効果的なアプローチ例について示す。

一般的なインシデント対応フロー

一般的にインシデント対応フローは、(a)検知、(b)トリアージ(初動対応)、(c)発動・動員、(d)インシデント対応（調査・復旧対応）、(e)振り返り、の５つのフェーズに分けられる（図2-2参照）。

(a)検知フェーズでは、システムからのエラー通知やユーザーからの問い合わせを起因としたエスカレーションなどによりインシデントの可能性を検知する。インシデントの可能性を検知した場合、(b)トリアージ(初動対応)にて内容を精査しインシデントかどうかを判断し、必要に応じ初期復旧対応を行う。(b)でインシデントと判断した場合、(c)発動・動員で、インシデントを発動し対応を行うメンバーを招集し対応を開始する。この時招集した対応を行うメンバーの集合を本ガイドでは「インシデント対応チーム」と呼んでいる。インシデント対応チームは、(d)インシデント対応にて、調査とサービスやシステムの早期復旧に努める。また事象分析のためのデータ収集や、サービスの利用者や関係者への適時の情報提供を行う。最後の(e)学習・予防では、インシデントの根本原因の特定を行い改善に向けた恒久的対策を実施する。

図2-2 一般的なインシデント対応フロー

インシデント対応の品質向上のためのアプローチ例

各フェーズにおける効果的なアプローチについて、以下で説明する。

• (a)検知フェーズ：通知の最適化
  • アプローチ: 継続的改善活動を通じて通知頻度を適正化することで、対応の質と効率を向上できる。具体的には、(e)振り返りフェーズでの技術的な恒久対策によるシステム品質向上や、通知条件の最適化などが有効である。また近年では、AIによる異常検知・アラート優先順位付け（AIOps）の活用なども考えらられる。これらの対応により、真に対応が必要なエラーに集中でき、「アラート疲れ」（alert fatigue）を防ぐことができる。
  • 期待される効果: 重要なエラーの見逃し防止、後続フェーズでの対応負荷の軽減
  • 詳細: 「2.4 振り返りと技術的な恒久対策」を参照
• (b)トリアージ（初動対応） フェーズ：対応の自動化
  • アプローチ: 原因と対応方針が明確な事象に対して、初動対応における対応の自動化
  • 期待される効果: 復旧時間の短縮、人為的ミスによる二次障害リスクの削減
  • 詳細: 「3.6 障害対応の自動化とリモート化」を参照
• (c)発動・動員フェーズ：対応体制の事前計画
  • アプローチ: インシデント発生時の迅速な初動対応のため、現場指揮官の優先順位リスト、体制人数ごとの役割分担、各役割の担当者を平常時に決定しておく。また初期段階では十分な人員を招集し、状況が明確になった時点で縮小する方針を定める。
  • 期待される効果: 初動対応の迅速化、適切な役割分担、効率的な人員活用
  • 詳細: 「2.2.4 インシデント対応チーム体制の事前計画」を参照
• (d) インシデント対応 フェーズ：協働体制の強化
  • アプローチ1: 職員と事業者の責任共有の明確化
    • 職員と事業者がそれぞれの役割を明確化し、インシデント解決に向けて協働することで、効果的な対応が可能となる。職員は利用者を含む各ステークホルダーとの円滑なコミュニケーションを担当し、事業者はシステム復旧と原因究明および対策の実施を担当する。双方が最新状況を随時共有することで、一体感のあるインシデント対応を実現できる。
    • 期待される効果: 役割分担の明確化、当事者意識の向上、効率的な対応
    • 詳細:「 2.2 職員と事業者の責任」 を参照
  • アプローチ2: リアルタイムの状況共有
    • 職員や事業者など異なる組織で構成するインシデント対応チーム全体で最新状況をリアルタイムに共有する仕組みを導入することで、情報の透明性と対応の迅速性が向上する。具体的には全員オンサイトで同一の場所で対応する場合はホワイトボードの活用、複数拠点からリモートで対応する場合は複数人で同時に参照・編集できるツールの利用が効果的である。
    • 期待される効果: 情報の透明性向上、対応の迅速化、認識齟齬の防止
    • 詳細:「 2.2 職員と事業者の責任」を参照
• (e)振り返り フェーズ：建設的な振り返りの実践
  • アプローチ: インシデントを「失敗」としてではなく、システムや運用における改善点を見つけるための「学習」と「改善」の貴重な機会と捉え、振り返りを行うことが重要である。振り返りは、職員と事業者の双方が対等な立場で参加し、建設的に議論を進める。具体的には、システムとプロセスの改善を目的として、「誰が悪いか」ではなく「何が悪かったか」に焦点を当てる。また恒久的対策は、人手に依存した運用回避ではなく、技術的な改善策により問題を根本的に解決することを目指す。なおこの「振り返り」の活動のことを、IT分野やビジネスにおけるプロジェクト管理の分野では一般に「ポストモーテム」と呼ばれている。
  • 期待される効果: 心理的安全性の確保、本質的な問題の発見、効果的な再発防止策の策定
  • 詳細:「 2.4 振り返りと技術的な恒久対策」を参照

2.2 職員と事業者の責任

2.2.1 インシデント対応チームの役割分担と規模に応じた構成の考え方

職員と事業者のそれぞれの責任の説明の前提として、インシデント対応チームの体制を構成するために必要になる役割と、インシデント対応チームの人数規模に応じた構成例に関する一般的な内容を説明する。

インシデント対応チームの役割分担

インシデント対応のチームの中には複数の役割があり、インシデントの解決に向けて現場で指揮を行う現場指揮官を中心に、複数の役割が各々の責任を持って対応を進めることでインシデントの解決を図る。

インシデント対応チームの中における役割と役割間の関連性を、図2-3に図示する。またそれぞれの役割の説明を表2-1に示す。

この中で最も重要な役割は、現場指揮官である。現場指揮官は、一般にはインシデントコマンダー（Incident Commander）と呼ばれている役割であり、インシデント解決責任者であり、インシデント対応チームの指揮官である。現場指揮官は、対応チームでリーダーシップを発揮し、経験と実績及び専門知識を発揮しインシデント解決に向け状況に応じ適切な意思決定を行える者が担当することが望ましい。また現場指揮官は、全体を俯瞰し適切に意思決定することに注力するため、実作業は別の担当者を立てることが望ましい。また所属組織の上司は、インシデント対応に関し、現場指揮官に全権限を委任し、現場指揮官の支援や求めに応じた助言を行うことに徹するのが望ましい。

なおインシデント対応チームは職員と事業者で構成されることが一般的である。これらの役割の職員と事業者への分担については、次節で説明する。

図2-3 インシデント対応チームの中の役割の相関関係

表2-1 インシデント対応チームの中の主な役割

規模に応じた対応チームの構成の考え方

インシデント対応チームの一般的な構成の考え方を説明する。インシデント対応チームを構成する場合、起点となるのは現場指揮官になる。まずインシデント対応チームには現場指揮官のみが存在し、すべての役割を現場指揮官が担当する状態をスタートと考える。この状態からインシデント対応チームに参加した担当者に対して、現場指揮官は役割の順次委任を行う。当初は現場指揮官がすべてのメンバーを指揮・調整するが、担当者が増え現場指揮官がすべての担当者を指揮・調整できる範囲を超えた場合は、オペレーションリードやコミュニケーションリードなどそれぞれの役割を担うリーダーを別に立てて役割を委任する。新しいリーダーを立てる目安は一般的には５名前後と言われている（「National Incident Management Systemガイド」の「Manageable Span of Control」の項目を参照）。

• National Incident Management Systemガイド
  https://www.fema.gov/sites/default/files/2020-07/fema_nims_doctrine-2017.pdfopen_in_newOpens in new tab

このチーム構成の考え方を踏まえて、インシデント対応チームの現実的な最小構成は、現場指揮官と実作業担当者の２名のチームになる（図2-4参照）。これは先に述べた通り、現場指揮官は解決に向けて全体を俯瞰し意思決定を行うことに注力するために、まず実担当者を立てるべきであるからである。

さらに担当者が増え5名でインシデント対応チームを構成する場合の例を、図2-5に示す。この例では、実作業担当者が３名、コミュニケーション担当者が1名、及び全体を統括しチームをリードする現場指揮官１名でチームを構成している。なお1名の場合必ずしもこの分担である必要性はなく、その時の状況に応じて分担は柔軟に変えるべきものである。

図2-4 インシデント対応チーム構成例（最小構成例）

図2-5 インシデント対応チーム構成例（５名体制例）

2.2.2 職員と事業者の責任共有の重要性

職員と事業者が関与するシステムにおいて、インシデント発生時のインシデント対応チームを事業者のメンバーのみで構成し、事業者のみで対応することは好ましくない。なぜならば、事業者は職員とは異なる組織であり、事業者は限定された情報しか接することができないこと、また事業者は契約に基づいた活動であり、活動の範囲は契約の内容に制限されることから、事業者がいかに職員と同じ目線で活動しようとしても、職員と全く対等な立場・目線で行動することは本質的に困難であるからである。

そのためインシデント対応では、職員もインシデント対応チームの一員として参加し、職員と事業者それぞれの責務を明確にし、お互いが尊重し協力し合いながら一致団結してインシデント対応に取り組むことが必要である。

本項目では、職員と事業者それぞれの責務に言及した上で、職員と事業者の責任範囲の例を説明する。

職員と事業者それぞれの責務

前述の通りインシデント対応においては、職員と事業者がそれぞれの責務を明確化し、かつお互いが尊重し協力し合いながら一致団結し、各々の責務を全うすることで初めてインシデントを解決できることを理解する必要がある。
その理解を踏まえた上で、職員と事業者は概ね以下の責務を負っていると考えられる。

職員: 外部ステークホルダーとのコミュニケーションの責務
職員は、該当システムやサービスの提供責任を有する立場として、利用者や関連組織など外部のステークホルダーとのコミュニケーションを通じ、インシデントの事象や対応状況を適切にステークホルダーに情報提供しステークホルダーの不安や不満を低減させることとともに、インシデント発生によるステークホルダーへの影響を正しく把握しインシデント対応チーム内で共有すること、また必要に応じて外部支援を要請し調達する責務がある。また外部ステークホルダーからの情報を適時、事業者側に連携する責務を有する。

事業者: インシデントの原因究明と解決の責務
事業者は、該当システムやサービスの技術的または業務的専門家の立場として、発生したインシデントの原因究明と解決を行い、サービスを早期復旧する責務がある。またコミュニケーション担当者が外部ステークホルダーと効果的にコミュニケーションを行うために必要となる情報を逐次コミュニケーションを担当する職員側に提供する責務がある。

職員と事業者の責任範囲の例

職員と事業者の責任範囲は上記に限定するものではなく、状況により変わる。具体的な範囲は個々のプロジェクト状況に依存し一概には言えないが、概ね行政機関の内製化状況に応じるものと考える。

図2-6に行政機関の内製化状況に応じたインシデント対応における職員と事業者の責任範囲の例を示す。この例で使用している「仕様内製型」、「ブリッジ型」、「完全内製型」の３つの内製化状況は、「2025年デジタル庁活動報告及び今後の取組」資料で定義されている内製化状況を引用したものである。基本的には先に述べた通り、職員はインシデント対応チームの外の外部ステークホルダーとのコミュニケーションを軸とし、事業者はインシデント究明と解決を軸にする。その上で現場指揮官は、該当システムや業務に精通したリーダー的な立ち位置の職員が携わることが理想ではあるが、仕様内製型などで事業者への依存が大きい場合は、事業者のリーダーが現場指揮官を担うこともやむを得ないと考えられる。

• 2025年デジタル庁活動報告及び今後の取組
  https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e40758be-dd25-46e1-96e9-24cf5719a7a9/4bd9ee19/20250905_activity_report.pdfopen_in_newOpens in new tab

図2-6 プロジェクト内製化状況に応じたインシデント対応における職員と事業者の責任範囲の例

2.2.3 チーム外からの担当者への直接コンタクトの防止

インシデント対応チームの部外者が、対応チームの担当者に直接コンタクトする状況は遮断すべきである。 具体的な例としては、インシデント対応チームに従事しない職員や事業者の幹部や上司が、インシデントの状況を知りたくて対応チームの担当者を直接捕まえて状況をヒアリングしたり、現場指揮官を介さず担当者に直接指示をするなどである。

なぜならば、インシデント対応の現場では、刻一刻と状況が変化する中で、担当者は高度な集中力を要求されるからである。そのような緊迫した状況下で、対応チーム外から直接問い合わせや指示が入ると、担当者の注意が分散され、対応の質とスピードが著しく低下してしまう。また、現場指揮官を介さない複数の指示系統が生まれることで、指示の矛盾や優先順位の混乱が発生し、組織全体の対応が場当たり的になる。さらに、同じ質問に何度も答える時間的ロスや、断片的な情報が独り歩きして誤解を招くリスクも高まる。インシデント対応を効率的に完遂するには、情報の流れと指示系統を現場指揮官に一元化し、担当者が本来の任務に専念できる環境を守ることが不可欠である。

このような状況が発生しないようにするためには、以下の２点の対応をすることが肝要である。

(a) 最新状況のリアルタイム情報共有ツール参照の徹底
部外者が対応状況を確認したい場合で、かつ次の「2.3 対応状況のリアルタイム共有」で言及する最新状況のリアルタイム共有ツールへの参照を可能にできる場合は、そのツールの参照権限を付与し対応チームに問い合わせるのではなく、その共有情報を参照するよう徹底する。

(b) 専任の連絡担当者（コミュニケーター）を設ける
上記対応だけで不十分な場合は、組織内での報告・エスカレーションが必要なステークスホルダーを担当する専任の連絡担当者を設け、必要な情報を適切にフィルタリングしステークスホルダーや対応チームに伝達する体制を整えることが重要である。

2.2.4 インシデント対応チーム体制の事前計画

インシデント対応を迅速かつ効果的に実施するためには、インシデント発生時にその都度チーム体制を検討するのではなく、事前に体制や担当を決めておくことが望ましい。緊急時の心理的プレッシャーの中では適切な役割分担の判断が困難になるため、平常時にインシデント対応体制を事前に整備しておくことが重要である。

なお本節で説明する体制の準備は、段階的に進めることを推奨する。まずは現場指揮官の担当者とその優先順位を決めることから始め、実際のインシデント対応を経験する中で、振り返りを通じて体制や役割分担を段階的に拡充していくアプローチが現実的である。完璧な体制を最初から構築しようとするのではなく、運用しながら継続的に改善していくことを重視されたい。

現場指揮官と段階的体制の準備

インシデント発生時に誰が現場指揮官を担当するかを相談することがないよう、予め現場指揮官の優先順位リストを作成しておくことが望ましい。プロジェクトマネージャー次にリーダーなどシステム全体を俯瞰し適切な意思決定ができる経験と専門知識を持つ者を優先し、また夜間・休日を含め連絡がつきやすく参集可能な者を考慮する。第一候補者が対応できない場合に備え、第二候補、第三候補も明確にしておく。

次に、担当者が順次集まることを前提として、体制人数ごとの役割分担を決めておく。たとえば初期対応では現場指揮官と実作業担当者の最小構成で開始し、体制が拡大するに従いコミュニケーション担当者や記録担当を追加、さらに人数が増えればオペレーションリードやコミュニケーションリードを配置する想定で、誰がどの担当を兼務するかを予め相談して決めておく。

役割ごとの担当者の決定

「2.2.1 インシデント対応チームの役割分担と規模に応じた構成の考え方」で説明した各役割について、主担当者と副担当者を明確にし、各担当者のスキルや適性を考慮した役割分担を行う。余裕があれば主担当者が不在の場合でも対応できるよう、複数の担当者が同じ役割を実施できるようトレーニングを実施することが望ましい。なお、事前に決定した役割分担は固定的なものではなく、実際のインシデントの状況に応じて現場指揮官の判断で柔軟に調整する。

初動体制は多めに招集

インシデント対応チームの規模は、システムに携わる組織の規模やインシデント重大度に依存する。ただし、重大度が明らかに低いと断定できる場合を除き、初期段階で十分な人員を招集し、状況が明確になった時点で縮小する方が効率的である。後から人を逐次投入すると、その都度状況説明に時間を取られ、情報の食い違いや重複作業が発生し、インシデント解決が遅れるためである。

体制の定期的な見直し

事前に構築した体制は、人事異動や組織改編、システムの大規模な変更、実際のインシデント発生後などのタイミングで定期的に見直す。また定期的な訓練を通じて体制が実際に機能するか検証し、体制図や連絡先リスト、役割分担表などのドキュメントを最新の状態に保つことが望ましい。

2.3 対応状況のリアルタイム共有

2.3.1 リアルタイム共有の重要性

インシデントの対応状況をリアルタイムで可視化し、インシデント対応チーム全員で共有することは、インシデント対応を効果的かつ迅速に進めるにあたり重要な要素である。
なぜならば、最新の対応状況をリアルタイムで可視化し共有することで以下のメリットがあるからである。

1. 情報の一元化： 関連情報を一箇所に集約することで、メンバー全員が同じ情報にアクセスでき、かつ最新の状況や進捗を常に把握しやすくなる。
2. 視覚化： 問題や状況を視覚的に表現することで、理解が容易になる。また全体像の把握が容易になり、問題の構造や関連性が明確になる。
3. リアルタイムの更新：インシデント対応チーム全体で最新の情報を直ちに共有することで、インシデント対応の効率が上がる。
4. コミュニケーションの効率化： 口頭での説明や個別の連絡を減らすことで、コミュニケーションオーバーヘッドを減らし、メンバーがインシデント解決に向けてそれぞれの役割に専念することができる。

2.3.2 利用ツールと共有すべき情報

インシデント対応チーム全員で対応状況をリアルタイム共有する場合は、複数人が同時に更新と参照ができるツールを使い、またインシデント概要・影響・対策状況がわかる情報を提供すること。

具体的どのようなツールを使い、どのような情報を共有すべきかについて、以下で述べる。

利用ツール

ツールは、リアルタイムに複数の人が書き込みかつ参照できるものが良い。

• オンサイト対応（対策室に集合し対応する場合）: ホワイトボードを利用する。
• リモート対応（複数拠点での対応）: 参照と更新が同時に行えるツールを利用する。例えば同時編集可能なwikiツールや、同時編集が可能なドキュメントツールの利用が一般的である。

共有情報

インシデントの概要とインシデントの対応に関する、最新状況を共有するために以下の情報を共有する。

1. 発生日時と事象概要（その時点で判明している範囲で記載し逐次更新）
2. ユーザー影響（その時点で判明している範囲で記載し逐次更新）
3. 時系列での対応経緯
4. インシデント対応チームの各担当者の役割分担
5. インシデントの直接原因（調査状況に応じ逐次記載する。簡易的なシステム概要図などを使いその時点の調査結果が可視化できるとなお良い）
6. 今後の対応方針

なおガバメントクラウドチームでの情報共有の例を、別紙2-2 に提示する。必要に応じて参考にしていただきたい。

2.4 振り返りと技術的な恒久対策

2.4.1 振り返りの目的と基本原則

初めに本項目では一般的内容として、振り返りの目的を説明した上で、振り返る時に重要となる「非難しない文化」の重要性と、振り返りの基本原則について説明する。

振り返りの目的

インシデント発生後の振り返りは、同様のインシデントの再発防止および発生時の影響最小化を目的とした、システム品質向上のための重要な活動である。振り返りを通じて、(a)インシデントの根本原因を特定し、(b)システムやプロセスの脆弱性を明らかにし、(c)具体的な改善策を立案・実施することで、継続的なシステム品質の向上を実現する。

振り返りは、「失敗」を責める場ではなく、「学習」と「改善」の機会として捉えることが重要である。インシデントは避けられないものという前提に立ち、発生したインシデントから最大限の学びを得て、組織全体の対応力を向上させることが振り返りの本質である。

「非難しない文化」の重要性

効果的な振り返りを実現するためには、「非難しない文化」（ブレームレス文化 Culture）、言い換えれば「人を責めない文化」の醸成が不可欠である。

ブレームレス文化とは、インシデント発生時に「誰が悪いか」ではなく「何が悪かったか」「どうすれば防げたか」に焦点を当てる考え方である。人為的ミスがあった場合でも、その個人を責めるのではなく、「なぜそのミスが起こりうる状況だったのか」「どのような仕組みがあればミスを防げたか、またはミスの影響を最小化できたか」というシステムやプロセスの観点から分析を行う。

ブレームレス文化が重要な理由:

1. 心理的安全性の確保: 責任追及を恐れずに、担当者が事実を正直に報告できる環境を作る。隠蔽や情報の歪曲を防ぐことで、正確な原因分析が可能になる。
2. 本質的な問題の発見: 個人の責任追及に終始すると、システムやプロセスに潜む本質的な問題を見逃す。ブレームレス文化により、組織全体の構造的な課題に目を向けることができる。
3. 継続的な改善の促進: 失敗から学ぶ文化が根付くことで、小さな問題でも早期に報告・共有され、大きなインシデントへの発展を防ぐことができる。
4. 担当者の成長と組織の学習: 個人の失敗を組織全体の学習機会に転換することで、担当者の成長と組織全体の対応力向上につながる。

ブレームレス文化の実践における注意点:

ブレームレス文化は「責任を問わない」という意味ではない。以下の点に留意する必要がある。

• 悪意ある行為や重大な規則違反は別: 意図的な破壊行為や明確な規則違反、繰り返される過失などは、通常の懲戒プロセスで対処する。
• 個人の学習機会でもある: 個人を責めないことと、個人が失敗から学習し成長する機会を提供することは両立する。建設的なフィードバックは必要である。
• 組織的な責任は明確にする: ミスなどを発見するプロセスの不備や体制の問題など、組織としての責任は明確にし、改善につなげる。
• 契約上の責任と振り返りの分離: 請負契約の瑕疵担保責任など、契約に基づく責任所在や損害賠償に関する協議は、技術的な振り返りとは分離し、双方の責任者や契約担当者間で別途実施する。振り返りの場では契約上の責任追及を行わないことで、参加者が率直に事実を報告し建設的な議論を行える環境を維持する。

振り返りの基本原則

効果的な振り返りを実施するために、以下の基本原則を遵守する。

1. タイムリーな実施: インシデント解決後、可能な限り早く振り返りを実施する。記憶が鮮明なうちに実施することで、より正確な分析が可能になる。実施タイミングは、インシデントの規模や複雑性により事前整理に要する時間が変わるため一様には言えないが、一般的にはインシデント解決後1週間以内を目安とする。
2. 関係者全員の参加: 職員と事業者の双方、およびインシデント対応に関わった全ての関係者が対等な立場で参加する。多様な視点を取り入れることで、より包括的な分析が可能になる。
3. 事実に基づく分析: 推測や憶測ではなく、ログやデータなどの客観的な証拠に基づいて分析を行う。
4. 建設的な議論: 批判や責任追及ではなく、改善に向けた建設的な議論を行う。「どうすればより良くできたか」という前向きな問いを中心に据える。
5. 文書化と共有: 振り返りの結果は文書化し、組織内で広く共有する。同様のインシデントの予防や、他のシステムへの横展開に活用する。
6. アクションの明確化と追跡: 特定された改善策は、実施責任者、期限、優先度を明確にし、確実に実行されるよう追跡する。

振り返りの実施プロセス例

振り返りの実施プロセス例について、「別紙2-1. 振り返りと技術的な恒久対策の具体例」の 「(1) 振り返りの実施プロセス例」 で紹介する。振り返りを行う際の参考にしていただきたい。

2.4.2 技術的な恒久対策の重要性

本項目では、技術的対策を優先する理由を説明する。さらに、技術的恒久対策の例を紹介する。

運用回避ではなく技術的対策を優先する理由

インシデントの再発防止策として、「人手による運用強化」や「チェックリストの整備」などの運用改善策が提案されることが多い。しかし、本ガイドでは技術的な恒久対策がある場合はそれを優先することを推奨する。

運用回避の問題点:

1. 人為的ミスは必ず発生する: いくら注意しても、疲労や思い込み、コミュニケーション不足などにより、人為的ミスは必ず発生する。「次は気をつける」、「確認項目を増やす」という対策は、根本的な解決にならない。
2. スケールしない: 人手による運用は、システムやサービスの規模拡大に伴い、比例して人員を増やす必要がある。持続可能性に欠ける。
3. 属人化リスク: 特定の担当者の知識や経験に依存した運用は、担当者の異動や退職により容易に破綻する。
4. 継続的な負担: チェックリストや手順書による運用は、継続的に人的リソースを消費し、本来注力すべき業務を圧迫する。
5. 品質のばらつき: 人手による作業は、担当者のスキルや状況により品質にばらつきが生じる。
6. 形骸化のリスク: インシデント発生の度にチェックリストが追加される結果、項目数が増大し、本来の目的が忘れられて形骸化しやすい。チェックリストの実施自体がコストとなり、効果的な運用を妨げる悪循環に陥る可能性がある。

技術的恒久対策の利点:

1. 確実性: 自動化やシステム的な制御により、人為的ミスを排除できる。
2. スケーラビリティー: 一度実装すれば、システム規模にかかわらず同じ品質で機能する。
3. 持続可能性: 人員の異動や増減に影響されず、長期的に効果を発揮する。
4. リソースの効率化: 人手を本来の付加価値の高い業務に集中できる。
5. 一貫した品質: 自動化により、常に同じ品質で処理が実行される。
6. 知識の形式知化: 技術的対策は、コードやシステム設計として知識が形式知化され、組織の資産となる。

技術的恒久対策の例

具体的な技術的恒久対策の例を、「別紙2-1. 振り返りと技術的な恒久対策の具体例」の 「(2) 技術的恒久対策の例」 で紹介する。技術的な恒久対策を検討する際の参考にしていただきたい。

2.5 ガバメントクラウドの取り組み紹介

デジタル庁のガバメントクラウドチームでは、ガバメントクラウド利用のための各種申請や環境払出し、利用状況の可視化、地方公共団体向けのクラウド利用料の請求などガバメントクラウド利用のライフサイクル全体の管理を容易にするためのWebサービスとして、GCAS（Government Cloud Assistant Service）の開発と運営を行っている。

GCASの開発と運営において、ガバメントクラウドチームでは、サービスの可用性・信頼性・性能向上を限りある人材の中で進めるための施策として、SRE（Site Reliability Engineering）手法の活用を進めてる。

本節では、ガバメントクラウドチームのGCASにおけるSREを活用したインシデント対応の取り組みについて紹介する。我々の取り組みが各利用組織においても最適であるとは言えないが、本章の「インシデント対応と振り返り」の取り組みにおけるヒントになれば幸いである。

2.5.1 GCAS開発概要

はじめに前提情報として、GCAS開発の手法と体制について説明する。

GCASでは、情報登録機能、地方公共団体向けの請求機能、ダッシュボード機能など、それぞれの機能ごとにプロダクト化されており、各々のプロダクトが独立したスクラムチームを構成し開発を進めている。また、GCASではインフラとアプリケーションでチームは分けず、それぞれのプロダクトごとのスクラムチームが、担当プロダクトのインフラからアプリケーションまでを一貫して担当している。

デジタル庁のガバメントクラウドチームの組織は、行政官と民間人材（以下、エンジニア）の混成組織である。その中でGCASの開発は、エンジニアが主に担っている。スクラムチームは一般に、(1)プロダクトの価値最大化に責任を持つプロダクトオーナー、(2)スクラムの実践をサポート・促進するスクラムマスター、(3)複数名の開発者で構成する開発チーム、の３つで構成されるが、GCAS開発のスクラムチームでは、プロダクトオーナーは主にガバメントクラウドチームのエンジニアが担っている。

プロダクトの一部は、完全内製型としてエンジニアのみで開発を進めているが、それ以外の多くのプロダクトは、委託先の事業者が開発チームとして参画し、プロダクトオーナーのガバメントクラウドチームのエンジニアとスクラムチームを構成する、ブリッジ型で開発を進めている(*1)。

(*1) デジタル庁のウェブサイトに掲載されている「2025年デジタル庁活動報告及び今後の取組」のp.40 「組織の強化｜政策立案＋内部開発の強化」を参照。

• 2025年デジタル庁活動報告及び今後の取組
  https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e40758be-dd25-46e1-96e9-24cf5719a7a9/4bd9ee19/20250905_activity_report.pdfopen_in_newOpens in new tab

2.5.2 GCASにおけるインシデント対応紹介（検知 - 発動フェーズ）

最初に「2.1.3 さらなる品質向上に向けた提案」で説明した一般的なインシデント対応フローのうち、(a)検知フェーズから(c)発動フェーズまでについて、GCASにおける取り組みを紹介する。

(a)検知フェーズ

デジタル庁では庁内のコミュニケーションにSlackを活用している。GCAS開発のスクラムチームでは、チームごとにSlackチャンネルを設けておりシステムから発報されるエラー通知は、各々のチームのエラー通知用のSlackチャンネルにメッセージが出力される。

エラー通知の頻度は、多くて 10件/週にとどめることを目安としている。エラーが多発しエラー通知数が目安を超過する場合は、中で不具合の改善や自動回復などのシステム改善や影響がない場合は通知抑止対応を行い、エラー通知数を目安以内に収める活動を継続的に実施している。

また、エラー通知以外にヘルプデスクや利用者からの照会を受けた行政官からの連携もSlackを利用している。

(b)トリアージ（初動対応）

開発チームでは、週単位で通知されたエラーを確認する担当者を決め、担当者が発生したエラーのトリアージを実施し、必要に応じ有識者やリーダーに相談し障害（インシデント）かを判断している。インシデントの疑いがあると判断された場合は、次の「(3) 発動」に進む。

(c) 発動

現場でインシデントの可能性があると判断されたものは、ガバメントクラウドチームの関係者が全員入るインシデント報知用のSlackチャンネルで報知しインシデント対応チームを招集する。

Slackチャンネルでの報知では、緊急時に報告内容に抜け漏れがないようにするため、Slackのワークフローを活用し定型フォームに必要情報を入力する方式を採用している。報告には以下の内容が含まれる。なお内容は内容の正確性より迅速性を重視し、報告時点で判明している範囲での記載で良いとし不明な場合は「不明」で良いとしている。

• タイトル: 障害内容が一言でわかる題名
• 発生日時: 報告時点で判明している範囲で記載
• 概要: タイトルの内容をより具体的に説明
• ユーザー影響: 報告時点で判明している範囲で記載
• 情報共有先（URL）: インシデント対応チーム内・外との情報共有のためのページのURLを記載。詳細は次の「(4)対応」を参照
• インシデント対応Slackチャンネル（URL）: インシデント対応チーム内のコミュニケーションは主にSlackを利用している。そのチャンネルのURLを記載
• コミュニケーションリード担当者: 情報共有ページを確認した上で、インシデント対応チームとコンタクトしたい際の窓口。発動時点では、現場指揮官（インシデントコマンダー）が兼務していることが多い。

2.5.3 GCASにおけるインシデント対応紹介（対応フェーズ）

次に「2.1.3 さらなる品質向上に向けた提案」で説明した一般的なインシデント対応フローのうち、(d)インシデント対応フェーズにおける、GCASの取り組みを紹介する。

インシデント対応チームの構成

ガバメントクラウドチームのインシデント対応チームは、大きくは、現場指揮官はエンジニアが担当し、コミュニケーションを行政官が担当、オペレーションはエンジニアまたは事業者が担当している。ただしガバメントクラウドチームの行政官とエンジニアの分担は画一的なものではなく、プロダクトの開発体制やインシデント規模によりその時に対応できる人が柔軟に対応する形で運営されている。

ガバメントクラウドチームの典型的なインシデント対応チームの構成として、図2-7では事業者もいるブリッジ型プロジェクトのインシデント対応チーム構成例を、図2-8では完全内製型プロジェクトのインシデント対応チーム構成例を示す。

事業者と共に開発を進めるブリッジ型プロジェクトの場合は、障害が発生したプロダクトのプロダクトオーナーを担うエンジニアが現場指揮官としてインシデント対応チームをリードすることが多い。ブリッジ型の場合は比較的規模が大きく複雑なプロダクトの場合が多いため、技術に明るいエンジニアが現場指揮官の補佐として入ることも多い。そして利用者やデジタル庁の関連組織へのエスカレーションなどのステークホルダー対応を行政官が、調査・復旧の実作業は事業者の現場責任者がオペレーションリードとなり事業者のチームが対応することが多い。

一方で、完全内製型プロジェクトの場合は小規模の開発体制であることもあり、エンジニアがオペレーションの対応を行い現場指揮官を担当できるエンジニアがいない場合が多いため、障害になったプロダクトを担当する行政官が現場指揮官を担当しコミュニケーションを兼務してインシデント対応を進めることが多い。

このように、ガバメントクラウドチームでは、プロジェクトの体制に応じて、行政官、エンジニア、事業者がそれぞれの強みを活かした役割分担により、インシデント対応体制を構築している。

図2-7 インシデント対応チーム構成例（ブリッジ型プロジェクト）

図2-8 インシデント対応チーム構成例（完全内製型プロジェクト）

情報共有/ポストモーテムテンプレート

ガバメントクラウドチームは主にリモートでの対応が主となるため、インシデント対応チーム内の情報共有には、同時編集可能なwikiツールを利用している。その情報共有用のwikiページのURLを記載している。このページは委託先の事業者にも権限を付与しており、事業者含めインシデント対応チームの参加者全員で情報共有できるようにしている。

またガバメントクラウドチームでは、抜け漏れない情報共有と事後のポストモーテムの議論用資料作成の効率化を狙い、最初からポストモーテムのフォーマットを活用し情報共有を図っている。

参考として、ガバメントクラウドチームで利用しているポストモーテムの雛形を公開用に汎化したものを「別紙2-2 ガバメントクラウドチームのポストモーテム雛形」に記載する。ガバメントクラウドチームでは、インシデント対応の初期からこのポストモーテムの雛形を活用し、インシデント対応チーム内外の関係者間の情報共有を図っている。

インシデント対応中は、即時性と関係者内の情報共有を重視し、「12. タイムライン」とインシデントの概要把握のための「1.エグゼクティブサマリー」の更新を中心に更新を行う。インシデント対応がひと段落ついた後の後日の 振り返り会議までにページ全体を更新し、振り返り会議はこのポストモーテムページを基に議論を進めている。

2.5.4 GCASにおけるインシデント対応紹介（学習・予防フェーズ）

次に「2.1.3 さらなる品質向上に向けた提案」で説明した一般的なインシデント対応フローのうち、(e)学習・予防フェーズにおける、GCASの取り組みを紹介する。

振り返り会議

振り返り会議は可能な限り、行政官・エンジニア・事業者の関係者が集まり実施するようにしている。振り返り会議の前に、ポストモーテムのページをアップデートし、当日はポストモーテムのページをベースに議論を進めている。議論の中では、(a)うまくいったこと、(b)うまくいかなかったこと、(c)ラッキーだったこと、を皆で意見を出して認識合わせを行い、根本原因の深掘りや恒久的対策の検討などを行い、最後にアクションアイテムを整理して、最終的にプロジェクトのタスクに落としている。

まとめたポストモーテムの最終版は、ガバメントクラウドチーム全体の定例または共有会で共有を行い、班全体での知識共有を図っている。

ブレームレス文化の実践における工夫

ガバメントクラウドチームで、ポストモーテムの取り組みを開始した当初は、事業者の多くがポストモーテムやブレームレス文化に馴染みがなく、また契約上の受注者として問題の原因を作ってしまったケースでは、事業者の担当者が責任を感じるあまり「すみませんでした、私のせいです。」と発言しがちで、仕組みの問題を率直に議論することが難しい状況があった。

このような状況を改善するため、特に取り組み初期においては、ブレームレス文化を浸透させるために以下の工夫を意識的に実施するようにした。

振り返り会議開始時の準備

• ポストモーテムの心構えや進め方を記載した文書を、参加者全員で冒頭に読み合わせる。
• 一人でも初めて参加する人がいれば、毎回説明を行う。
• 「責任追及ではなく、仕組みの改善が目的である」ことを明確に伝える。

ファシリテーションの工夫

• ポストモーテムの知見がある職員が第三者的な立場でファシリテーションを行う。
• 議論の方向性がずれないよう、また責任追及の場にならないよう注意を払う。
• 個人の能力や努力に頼る解決策ではなく、仕組みで改善できる方向に議論を導く。
• 事業者の方々も遠慮なく発言できる雰囲気づくりを心がける。

アクションアイテム設定時の注意

• 「なぜ」を追求する際やアクションアイテムを設定する際、個人の責任や能力のせいにする方向ではなく、仕組みで改善できないかという観点を重視する。
• 「レビューをもっとやる」「チェックを強化する」といった人的努力に依存する案が出た場合は、「自動化できないか」「仕組みで防げないか」という技術的な恒久対策の方向に議論を促す。

日常的な関係構築

• インシデント発生時に限らず、日々の仕事においても協力関係を意識したコミュニケーションを心がける。
• 日常的に対等な立場で率直に意見を言い合える関係を築いているからこそ、インシデント時の振り返りでも建設的な議論ができる。

これらの取り組みを継続した結果、現在ではポストモーテムやブレームレス文化を理解し実践できる人が職員・事業者双方で増え、振り返り会議がより自然に建設的な場として機能するようになってきている。ただし、新しい参加者がいる場合や、重要な局面では、引き続き意識的にこれらの工夫を実践している。

ポストモーテムを起点とした品質改善状況の可視化と管理

ポストモーテム活動が浸透することで、ポストモーテムにて決定した改善内容を今後の開発候補としてチケット化しバックログに積み上げるまでの活動は定着した。一方で、実際にどれほどシステム改善に反映されているか、実装までにどれくらいの期間を要しているか、の点が不透明であることが新たな課題とされた。

そこで個々のGCAS機能ごとに運営されているJiraプロジェクトを横串で確認し、ポストモーテム起因のチケットの対応状況を集計しチャート化する簡易ツールを作成し、品質改善の進捗状況を可視化した。このチャートでは、全体のチケット数と増減、各アクションアイテムのステータス、起票から完了までの期間、長期間未着手の案件等を可視化している。さらにこのチャートを活用し、チーム全体のミーティングで月次で、進捗状況の振り返りを実施している。

この取り組みにより、以下の効果が見えてきている。

• 長期間未着手のアクションアイテムを特定し、上位管理者のサポート（工数確保、優先度調整等）が必要な案件を早期に認識できる。
• ポストモーテムを通じて決定した改善策の多くが実際にシステムに実装されていることを定量的に確認でき、「ポストモーテムが形骸化していない」ことを関係者間で共有できる。