Day 90 境界シグナル（KRI）を、判断から行動へ KPIs/KRIs That Drive Action: Monitoring Signals and Operating Rhythm
[シリーズ構造] 柱F｜判断はどこで起きるのか
リスクのシグナル(KRI)が機能しない理由は、データ不足ではありません。行動につながらないことです。本稿では、境界シグナル（KRI）を リスク許容度・判断ルール・運用リズムと接続し、監視を意思決定と行動に変える方法を探ります。
▶ シリーズ全体マップ： 人間のしなやかさ ― サイバー判断力のために
▶ 柱F｜リスクとガバナンス 関連記事：
- Day 81｜リスクを語れる共通言語をつくる
- Day 82｜ネガティブリスクとポジティブリスク ― 不確実性の両面を統治する
- Day 83｜サイバーリスクの構造化 ― 「気になる話」を比べられるシナリオに変える
- Day 84｜リスク・トレランスという境界線 ― 限界が重要な理由
- Day 85 | リスク許容度とは何か ―判断を本当に変える問い
- Day 86 | 判断はどこで起きるのか ― リスクが行動に変わる瞬間
- Day 87 | 良いコントロール／悪いコントロール
- Day 88 | コントロールが多すぎる組織は、なぜ疲弊するのか
- Day 89 | 「多さ」ではなく「効く」統制
- Day 90 | 境界シグナル（KRI）を、判断から行動へ
境界シグナル（KRI）を、判断から行動へ
～境界シグナル（KRI）とオペレーティング・リズム（KPI）～
「赤」が点いた。
でも会議は、「どう読む？」から始まり、結局"様子見"で終わる。
この瞬間、リスクは減っていません。
KRIの機能だけが、静かに止まります。
KRIとは、リスクが許容度の境界（限界値）に近づいていることを知らせる兆しです。本来それは、「考える材料」ではなく、動く合図のはずでした。
今日は、KRIを「見える化」で終わらせないための話です。リスクを境界シグナル（KRI）に落とし、デリバリー／パフォーマンス（KPI）と接続する。
そうすると監視は、"報告のための報告"ではなく、意思決定・介入・エスカレーションを生み出すリズムに変わります。
シグナルが機能しない、よくあるパターン
シグナルが鳴ったときに、「誰が」「何を」「どこまで」動かすのか。
それが決まっていなければ、リズムは生まれません。
シグナルが効かない理由は、だいたい決まっています。
- 指標が多すぎて、ノイズになる
- 閾値が曖昧で、「どう読む？」が毎回会議で発生する
- 赤になっても、誰が何をするのか書かれていない
- 結局「様子見」がデフォルトになり、何も変わらない
これを潰さない限り、ダッシュボードは "壁紙" です。
目的は、当てることでも、説明することでもありません。
問題が起きる前に、今日どこで判断を変えるかを決めること。
そのために必要なのは、次の三つです。
- シグナルは少なく、意図が明確であること
- 閾値は「判断が変わる境界線」であること
- 各シグナルに、
- 取る行動
- エスカレーション先
- 判断の期限
が決まっていること
ここまで決まって、はじめて 「運用」 になります。
シナリオに紐づけて「少数精鋭」にする
まず前提です。KRI は「良い指標」ではありません。特定のリスクシナリオに対する 適切なシグナル です。
だから、KRI は単体で集めません。シナリオタイプごとに、KRI ライブラリを持ちます。
例えば、ベンダー障害、キャパシティ不足、データ品質劣化、サイバー事象、規制変更、モデルドリフト、デリバリー遅延。
各 KRI エントリに入れる項目は、固定します。
- 検知するシナリオ（何の「早期シグナル」か）
- 定義（何を、どう測るか）
- オーナー（誰が更新し、誰が動くか）
- データソース（システム＋フィールド）
- 頻度（日次／週次／月次）
- 先行／遅行の区分
- 閾値＋許容帯
- エスカレーショントリガー＋必須アクション
- コントロールへのリンク（どの対策を起動するか）
そして、量は絞ります。1シナリオあたり 3〜7 個。行動を起こすには十分で、ノイズにならない範囲です。
解釈を消して、判断を自動化する
シグナルが壊れる瞬間は、ここです。「この数字、どう読む？」が会話になる。
だから、信号機（R/A/G）を明文化します。主観を入れないためです。
- Green（緑）：許容帯の中 → 継続
- Amber（黄）：許容帯の外だが、エスカレーション境界の内 → 調査＋準備
- Red（赤）：境界突破 → 行動＋エスカレーション
さらに、すべての指標に「運用の部品」 を持たせます。
- ターゲット／ベースライン（通常レンジ）
- 許容帯（許されるブレ）
- 違反定義（何回／どれくらい続いたら違反か）
- リセットルール（どう戻れば 緑 か）
判定ルールは、どれかに統一します。例えば、
- 黄が 2期連続で 赤
- 単発 赤で即エスカレーション
- 直近 5点中 3点 黄 でアクション
ポイントは、正確さより一貫性です。同じ条件で、同じ判断が再現できること。それが、運用の強さになります。
安心の錯覚を避ける
指標には、2種類あります。先行と遅行です。片方だけだと危険です。
先行指標は、影響が出る前に動くためのもの。予防のためのシグナルです。
たとえば、
- 処理待ちが溜まり始める（待ち行列が増える）
- 変更の失敗率が上がる
- ベンダーSLA（契約上の水準）が「ギリギリ」に寄ってくる
- ヒヤリハットの報告が増える
- コントロール例外が増加傾向になる
- キャパシティ（処理余力）が縮んでいく
まだ何も起きていない。でも、「ズレ」はもう見えている。それが、先行指標です。
一方、遅行指標は、影響が出た後に現れます。学習と説明責任のためのシグナルです。
- 障害／欠陥／インシデント
- 規制当局からの指摘
- 顧客離反
- 損失イベント
- マイルストーン未達の確定
遅行指標は、「何が起きたか」を教えてくれます。
先行指標は、「起きそうか」を教えてくれます。
運用ルール
各シナリオに、先行指標を1つ以上、遅行指標を1つ以上。
先行がなければ、手遅れになります。
遅行がなければ、判断の良し悪しを検証できません。
シグナルを「テンポ」に落とす
ここで大事なのは、カレンダーではなくテンポです。シグナルは、正しい人に、正しい頻度で届いてはじめて意味を持ちます。
だから、判断が回るリズムをつくります。例えば、
- 日次／常時（Ops）自動ダッシュボード＋アラート（変化の速いリスクに即応する）
- 週次（Tactical）トレンド確認、アクション割当、障害除去
- 月次（Governance）許容帯の見直し、コントロール有効性、リスク受容の再検証
- 四半期（Strategic）シナリオ更新、閾値の再調整、リスク・ポートフォリオの転換
成果物は、「月次で見る」ではありません。カレンダー、アジェンダテンプレ、意思決定権限（decision rights）ここまで落として、はじめて運用になります。
トリガー（立ち止まる合図）とエスカレーション
エスカレーションとは、「赤になったら、何が起きるか」を先に決めておくことです。トリガー（立ち止まる合図）は「通知」ではありません。「誰が・何を・いつまでに」が書けて、はじめてトリガーになります。
最低限の設計例
- トリガー条件：指標＋閾値＋違反ルール
- 即時アクション：封じ込め、または ここで止める条件
- 担当者 → リスク責任者 → 経営スポンサー → 委員会
- 必要な意思決定：追加キャパ承認、ベンダーDR発動、リリース停止
- 必要な証跡：リンク、ログ、分析
ここがポイントです。「エスカレート」はアクションではありません。アクションとは、エスカレーションが強制する意思決定と介入です。
つまり、通知は情報の移動。アクションは、優先順位・予算・停止権限のいずれかを動かすこと。
リスク受容：KRIが突きつける、避けて通れない問い
閾値を置くと、必ずこう問われます。
「このリスク、私たちは OK なのか？」
だから、受容を"暗黙"から"統治された決定"へ引き上げます。
受容の要件（最低限）
- 受容基準：重要性の基準を下回り、許容しているリスク範囲内で、規制・契約違反がないこと
- 期限付き：失効日＋レビュー日（失効より前）
- 即時無効条件：赤の KRI、対策が機能していない場合、対象範囲の変更
- 代替コントロール：追加の確認、手作業による確認、職務の分離、切り戻し、取引先の切り替え
- 1ページ規律：リスク文、理由、監視指標、コントロール、期間、承認、残余リスク（前／後）
ここまで書けて、はじめて 「受容した」と言えます。
「受容している気がする」は、受容ではありません。
締め
シグナルは、見るためのものではありません。
動くためのものです。
動かない、動けないシグナルは、安全をつくりません。
今日つくったのは、ダッシュボードではありません。
意思決定を生むリズムです。
次は、このシグナルがリスク許容度という境界線と、どう噛み合うのか。
そして、会議で崩れないスコアリングに進みます。
今日からできること
優先シナリオを1つ決め、KRIを3〜7個に絞る
KRIは単体で集めません。「どのリスクシナリオの早期シグナルか」にひもづけ、少数精鋭にします。多すぎる指標はノイズになり、結局動けなくなります。
目安は1シナリオあたり3〜7個。
-
シナリオタイプを1つだけ選ぶ
（例：ベンダー障害／キャパ不足／データ品質劣化／サイバー事象／規制変更／モデルドリフト／デリバリー遅延 など） -
そのシナリオ用のKRIを3〜7個に絞る
- 先行指標を1つ以上＋遅行指標を1つ以上入れる （どちらかだけだと危険）
―――
[Series Structure] Pillar F | Where Judgment Happens
Risk signals don't fail because organizations lack metrics. They fail because signals stop at visibility.This article explores how to turn boundary signals (KRIs) into action, by explicitly linking them to risk tolerance, decision rules, and operating rhythm. By connecting KRIs with delivery and performance indicators (KPIs), monitoring becomes a repeatable system that produces decisions, intervention, escalation, and governed risk acceptance--before risk quietly drifts out of tolerance.
▶ Series overview: Series Overview -- Human Flexibility for Cyber Judgment
▶ Other posts in Pillar F (Risk & Governance):
- Day 81 | Building a Shared Language for Risk
- Day 82 | Negative vs. Positive Cyber Risk -- Governing Both Sides of Uncertainty
- Day 83 | Structuring Cyber Risk -- Turning Concerns into Comparable Scenarios
- Day 84 | Risk Tolerance as a Boundary -- Why Limits Matter
- Day 85 | Defining Risk Tolerance -- The Questions That Actually Change Decisions
- Day 86 | Where Judgment Happens ー When Risk Turns into Action
- Day 87 | Good Controls / Bad Controls
- Day 88 | Why Over-Controlled Organizations Burn Out
- Day 89 | "Effective" Controls, Not "More"
- Day 90 | KPIs/KRIs That Drive Action
KPIs/KRIs That Drive Action: Monitoring Signals and Operating Rhythm
We connect risk to signals (KRIs) and delivery/performance (KPIs) so monitoring isn't "reporting for reporting's sake." It becomes a repeatable operating rhythm--one that reliably produces decisions, interventions, and escalation.
KRI library tied to scenario types
We build a KRI library where each scenario type (vendor failure, capacity shortfall, data quality degradation, cyber event, regulatory change, model drift, delivery slippage) has a small, standardized set of KRIs. KRIs are meant to act as early signals--measurable indicators that risk is rising before it becomes damage.
Each KRI entry includes: • Scenario type it detects (what it's an early signal for)
• Definition (what exactly we measure)
• Owner (who updates, who acts)
• Data source (system + field)
• Frequency (daily / weekly / monthly)
• Leading vs. lagging classification
• Thresholds + tolerance bands
• Escalation trigger + required action
• Link to controls (which mitigations it activates)
Rule of thumb: 3-7 KRIs per scenario type--enough to drive action without creating noise.
Thresholds, tolerance bands, and R/A/G rules (so interpretation is never subjective)
If we want monitoring to drive action, we can't leave "what does this mean?" to debate. We define explicit traffic-light rules and standardize how breaches count.
A workable standard:
- Green: within tolerance band → monitor
- Amber: outside tolerance but inside escalation boundary → investigate + prepare
- Red: escalation boundary breached → act + escalate
To make it operational, every metric has:
- Target/baseline (expected operating range)
- Tolerance band (acceptable variation)
- Breach definition (how many times / how long before it counts)
- Reset rule (how it returns to Green)
Example rule patterns (pick one and standardize):
- 2 consecutive periods amber = red
- Single-period red triggers escalation
- 3 of last 5 datapoints amber triggers action
If you want a "math-backed" way to set bands (instead of vibes), Statistical Process Control (SPC) is a proven pattern for setting control limits and detecting when variation is meaningful enough to intervene.
Review cadence (the operating rhythm, not a calendar placeholder)
We use a tiered cadence so signals meet decision-makers at the right tempo:
- Daily/continuous (ops): automated dashboards + alerting for fast-moving risks
- Weekly (tactical): trend review, action assignment, blocker removal
- Monthly (governance): tolerance review, control effectiveness, risk acceptance revalidation
- Quarterly (strategic): scenario refresh, threshold recalibration, portfolio shifts
This isn't "we'll review monthly." The output is a calendar, agenda templates, and decision rights--so reviews reliably produce decisions, not discussions.
Leading vs. lagging indicators (how we avoid false comfort)
A healthy system needs both.
Leading indicators (predict): signals that move before impact--useful for prevention. A clear example from safety practice is that leading indicators are proactive measures, while lagging indicators measure what already happened.
Examples:
- Queue depth rising
- • Change failure rate increasing
- Vendor SLA near-breache
- Near-miss incidents
- Control exceptions trending up
- Capacity headroom shrinking
Lagging indicators (confirm): signals that move after impact--useful for learning and accountability:
- Outages, defects, incidents
- Regulatory findings
- Customer churn
- Financial loss events
- Missed milestones realized
Practice: for each scenario type, require at least one leading and one lagging indicator--otherwise we either react too late (no leading) or never verify outcomes (no lagging).
Escalation triggers (what happens when it turns Red)
A trigger must specify who does what by when.
Minimum trigger design:
- Trigger condition: metric + threshold + breach rule
- Immediate action: containment step or stop-the-line condition (if applicable)
- Escalation path: owner → risk lead → exec sponsor → committee
- Decision required: approve additional capacity, invoke vendor DR, pause release
- Evidence required: links, logs, analysis
Key point: "Escalate" is not an action. The action is the decision and intervention that escalation forces.
Risk acceptance (explicit, governed decision)
We deliberately pair this with Day 90 because thresholds always surface the same question: "Are we OK with this risk?"
ISO 31000 frames risk treatment choices as including accepting/retaining risk, as part of structured risk management decision-making.
Purpose
We define risk acceptance as an explicit, governed decision--not an implicit habit.
Core outputs for risk acceptance
A) Acceptance criteria (what qualifies) We define criteria such as: • Impact is below defined materiality
Risk is within approved appetite/tolerance
• No regulatory or contractual breach
• Compensating controls exist and are verified
• Risk owner has authority and budget accountability
B) Time-bound acceptance (never "forever") All acceptances include: • Expiry date
Review date (earlier than expiry)
• Conditions that void acceptance immediately (e.g., red KRI, control failure, scope change)
C) Required compensating controls If we accept risk, we state what must be true operationally: • Additional monitoring
Manual review steps
• Segregation of duties
• Rollback plans
• Vendor contingency arrangements
D) Documentation minimums (one-page discipline) Minimum acceptance record: • Risk statement + scenario type
Why acceptance is chosen (vs. mitigate/transfer/avoid)
• KRIs/KPIs monitored and their thresholds
• Compensating controls
• Duration (start, review, expiry)
• Owner and approvers
• Residual risk estimate (before/after)
Re-review cadence We tie cadence directly to signal volatility:
- High volatility/high impact: monthly or weekly
- Stable/low impact: quarterly
Closing
Day 90 is complete when:
• Every priority scenario type has KRIs with thresholds and R/A/G rules
• Each KRI has a named owner and data source
• We have a documented review cadence with decision rights
• "Red" states have predefined escalation and action playbooks
• Risk acceptance is time-bound, documented, and re-reviewed using the same signal framework