インシデント指揮系統（ICS）と役割分担

ICS とは何を解く仕組みか

インシデント指揮系統（Incident Command System, ICS） は、もともと米国の大規模災害対応で生まれた指揮フレームワークを、システム障害対応へ転用したものです。解こうとしている問題は単純です。重大障害では、対応の失敗のほとんどが技術ではなく「調整（coordination）」の失敗だ という事実です。

行き当たりばったりの対応で起きるのは、次のような 構造的破綻 です。

• 全員が個別に調査し、誰が何を見たか共有されない（重複調査・観測の取りこぼし）。
• 同じ事象に対し複数人が別々の復旧操作を打ち、互いの操作が干渉する。
• 経営・顧客への連絡を調査担当が片手間でやり、調査も連絡も中途半端になる。
• 「これでいこう」という決定が共有されず、判断が二転三転 する。

これらは個人の能力ではなく、情報と権限の流れが設計されていない ことから生じます。ICS はこの流れを 役割という形で固定 し、混乱を構造で封じます。検知から復旧までの全体像は /devops/incident-postmortem/ で扱う対応フローと対応し、ICS はその「指揮の層」を担います。

中核となる役割の分離

ICS の本質は 3 つの役割を別の人間に割り当てること にあります。

最も重要な原則は、IC が手を動かさない ことです。直感に反しますが、これは認知科学的な必然です。人間は 状況把握（situational awareness）と詳細作業（深いデバッグ）を同時に高い水準で維持できません。デバッグに没入した瞬間、その人の視野は手元のスタックトレースに狭まり、全体で何が起きているかを見失います。IC が一行でもクエリを叩き始めたら、その時点で「全体を見る人」は不在になります。

認知負荷と統制範囲（span of control）

役割分離が効くのは、一人の人間が同時に追える対象の数には上限がある からです。ICS が災害対応から受け継いだ経験則が 統制範囲（span of control）= 5〜7 です。一人の指揮者が直接マネジメントできる部下・ワークストリームは概ね 5 から 7 が限界で、これを超えると報告が処理しきれず、把握が破綻します。

これは認知科学の ワーキングメモリ容量（同時に保持できるチャンク数がおよそ 7 前後）と整合します。重大障害では、IC のワーキングメモリは次の競合する要求にさらされます。

IC が同時に追うもの:
  - 現在の影響範囲と深刻度（顧客への実害）
  - 進行中の復旧アクションとその副作用
  - 各ワークストリームからの報告の統合
  - 次の意思決定の候補とリスク評価
  - 対外連絡のタイミングと内容の承認

もし IC がここに「自分のデバッグ作業」まで載せれば容量は即座に飽和し、報告の取りこぼし・判断の遅延が起きます。役割分離は、この 認知負荷を複数の脳に分散 させ、各人を統制範囲の内側に保つための設計です。コミュニケーションリードを置くのは、対外連絡が 割り込み（interrupt）の最大の発生源 だからで、これを IC から剥がすだけで IC の連続的な思考時間が劇的に増えます。

情報の集約と単一の決定者

役割を分けただけでは不十分で、情報と権限の流れ を定義して初めて機能します。ICS の流れは二つの原理に集約されます。

• 集約（funnel-in）：観測・報告は すべて IC に集約 する。各オペレーターが互いに直接調整し始めると、情報が分散して全体像を持つ人がいなくなる。IC が唯一の統合点になることで、矛盾する報告（「DB は正常」「DB が遅い」）を一箇所で裁定できる。
• 単一の決定者（single decision-maker）：復旧アクションの 最終 Go/No-Go は IC が一人で下す。合議は平時には良くても、障害中は決定を遅らせ二転三転を招く。誰が決めるかが明確だからこそ、速く確定し、操作の干渉も防げる。

この構造は分散システムの リーダー選出 と同型です。複数のノードが勝手に書き込めば不整合が起きるのと同様、複数の人間が勝手に本番を操作すれば状態が壊れます。IC は人間系における 唯一のライター（書き込み権限者） であり、「この操作を本番に打つ」という決定の直列化点（serialization point）です。これが破れると、復旧操作自体が新たな障害——たとえば不用意な再起動の連鎖が引き起こす /devops/cascading-metastable-failures/ ——を生みます。

規模に応じて伸縮する指揮構造

ICS の優れた点は スケーラブルな伸縮性（modular expansion） です。小さな障害に重い指揮構造は過剰で、大きな障害に IC 一人では破綻します。だから規模に応じて構造を伸び縮みさせます。

規模	指揮構造
小規模（単一サービスの軽微な劣化）	IC が連絡・作業を兼任。役割は名目上 1 人
中規模（複数サービスに影響）	IC・コミュニケーションリード・オペレーションリードを分離
大規模（広域・長時間）	作業役をワークストリーム単位に分割し、各リードへ権限委譲。IC は直接の部下を統制範囲内に保つ

大規模化の鍵は ワークストリームへの分割と権限委譲 です。たとえば「DB 班」「ネットワーク班」「顧客影響の緩和班」に分け、各班に サブリード を立てます。IC は個々のエンジニアではなく サブリードだけを見る ことで、直接の報告元を統制範囲（5〜7）の内側に保ちます。これは指揮木（command tree）を 深くせず、各ノードの分岐を抑えて浅く保つ という設計判断で、報告が IC に届くまでの遅延（hop 数）を最小化します。複数リージョンにまたがる障害では各リージョンを独立した指揮単位とする構成もあり、/devops/multi-region-failover/ の切り替え判断もこの指揮系統の中で IC が裁定します。

SRE 実践との接続

ICS は SRE 文化（/devops/sre-slo/）の運用面の中核です。誰がいつ IC を起動するか——たとえばアラート（/devops/alerting-theory/）が一定の深刻度を超えた時に自動で IC をアサインする——を事前に決めておくことで、「誰も指揮していない空白の数分」を消せます。役割は 役職ではなく、その障害における一時的な帽子（hat） であり、若手でも訓練を受けていれば IC を務められます。重要なのは肩書きではなく、統制範囲・単一決定者・役割分離という構造 が守られていることです。

まとめ

• ICS は重大障害における 調整の失敗 を構造で防ぐ。IC・コミュニケーションリード・オペレーションリードを 別人に分離 するのが中核。
• IC は 手を動かさず、情報を集約し意思決定に専念する。これは状況把握と詳細作業を両立できないという認知的制約からの必然。
• 統制範囲 5〜7 とワーキングメモリの上限が役割分離の根拠。負荷を複数の脳に分散し、各人を限界の内側に保つ。
• 情報は IC に 集約し、Go/No-Go は 単一の決定者が下す。これは人間系のリーダー選出であり、操作の直列化点。
• 構造は規模に応じて 伸縮 する。大規模ではワークストリーム分割と権限委譲で指揮木を浅く保ち、報告遅延を抑える。