要点
impactは1 minimal〜4 severeをaffected people、workflow、data、scope、reversibility、business consequenceで評価。urgencyは1 planned〜4 act nowをworsening time、deadline、workaround endurance、containment、recovery windowで評価。4×4でinitial P1–P4を作りsafety、security、privacy、fraud、data loss、legal/regulatory、accessibility、contract overrideを適用。owner/reassessment timeを置きevidence変更時に再計算します。
labelは例でuniversal SLA promiseではありません。組織がrisk、service、contract、capacityに合うobjective、incident criteria、authority、escalationを定義します。
priority、severity、impact、urgencyは別物
severityはcondition/consequence、impactはscope/harm、urgencyはresponseのtime-to-change、priorityはcapacity/dependency/override後のqueue decision、SLAは存在する場合の別service commitment。
impactはuser countだけでない
workflow criticality、data integrity/confidentiality/availability、safety、accessibility、financial/contract consequence、市場/account、reversibility、workaround cost、spreadを評価。一人でもhigh urgency、多数でもcurrent defectなしならlow urgencyがあり得ます。
urgencyはtoneでなくtime-to-harm
verified deadline、deterioration、containment window、workaround endurance、recovery lead time、delayがevidence/restorationへ与える影響を使用。ALL CAPS、executive、tier、ticket age、repeat contactは調査signalで自動urgencyではない。
override/incident declarationはmatrixより上
active safety/security/fraud、privacy breach疑い、destructive data loss、regulatory reporting、accessibility exclusion、credible threat、contract triggerはcellに関係なくspecialist pathへ。ownerがscopeを検証しelevate/contain/reclassify。
4×4 priority matrix
| Impact ↓ / Urgency → | 4 Act now | 3 Soon | 2 Planned | 1 When possible |
|---|---|---|---|---|
| 4 Severe | P1 | P1 | P2 | P3 |
| 3 Major | P1 | P2 | P3 | P4 |
| 2 Moderate | P2 | P3 | P4 | P4 |
| 1 Minimal | P3 | P4 | P4 | P4 |
cellはprovisional。confidence/missing fact、override、owner、reassessmentを記録。criteria成立時P1はincident command、P4もowner/closureが必要。
16のticket priority実例
各cardは一cell。local verified evidenceで置換しpriorityをそのままcopyしない。
複数組織でcore service停止
複数組織/地域でprimary service停止を検証。安全なworkaroundなし、現在impact拡大。
組織全体login失敗・脆弱な回避策
tenantがauthentication不能。一時admin-assisted pathはあるがcapacity/security上数時間持続不能。
重要integration変更が来週期限前にblock
広範利用integrationの必須変更が不能。productionは稼働、来週の固定deadlineとtested rollbackあり。
来月のlarge migration validation
将来migrationは多数userに影響し得るがcurrent defectなし。decision evidenceは来月、reversible test環境あり。
多数userが本日financial cutoffでblock
複数verified userがsame-day cutoff前に必須billing workflow不能。approved alternativeなし。
regional core workflowが悪化
地域のcore workflow error上昇。一部成功、高負担workaroundあり、telemetryで数時間の悪化。
複数teamの明日利用reportが不正確
複数teamのnon-financial reportが誤り。source dataは無傷、manual verification可能、decisionは明日。
integration低下・stable workaroundあり
複数teamでsync遅延。record recoverable、documented safe workaroundで現需要を満たし近いdeadlineなし。
accessibility barrierが期限付きkey taskをblock
少数userが必要assistive technologyでverified deadline前にkey task不能。equivalent accessible routeなし。
role access失敗・near-term deadline
一teamのapproved roleがrequired workspaceへaccess不能。identity/permission確認済、deadline近くmanual processingは可能だが高負担。
small teamのintermittent error・安全回避あり
small teamでnon-destructive intermittent error再現。safe workaround、stable evidence、次の業務需要は数日後。
feature gapがsecondary workflowに影響
複数userがsecondary workflowのcapabilityを要望。current processあり、committed deadlineなし、product discovery向け。
一userの期限付きsubmissionがblock
single userがexpiring submission不能。identity/deadline確認済、equivalent routeなし、failureに具体的consequence。
single-user configuration issue・予定task前
一userの再現可能configuration問題。scheduled taskが近くdocumentation不明、adminが安全に支援可能。
task影響なしのcosmetic label error
一localeのUI labelが不正確だがcontrol/outcome明瞭、data/accessibility failureなし、planned workで修正可能。
how-to questionまたはfuture enhancement
documented stepの質問/改善提案。defect、deadline、blocked task、data risk、current service impactの証拠なし。
実例：最も強い口調でも自動P1でない
executiveがexport失敗を“URGENT—broken”と書きautomationはtitle/capsでP1。evidenceは一user、malformed filter、source data intact、安全export workaround、meetingは2日後：I1/U2→P4。reviewでworkaroundがscreen reader非対応、statutory submissionが本日expiryと判明しI2/U4→P2＋accessibility override。
なぜ時点ごとに両decisionが正しいか
priorityはcurrent evidenceに従いprestige/permanent labelではない。original fact、missing accessibility/deadline question、changed evidence、old/new score、reviewer、owner、strategy、next reassessmentを保存。new material factで変更はmodel failureでなく再評価しないことがfailure。
matrixの運用
minimum factでtriage
exact task、scope、time、evidence、deadline、workaround、risk flag、contact route、uncertaintyを記録。
matrix/overrideを分離
raw impact/urgency rationaleを保存後にspecialist/contract elevation。
response roleを割当て
ticket owner、resolver、必要時IC/communications lead、customer owner、decision authorityを指定。
verified stateをcommunicate
known impact、action、workaround limit、next update、correctionを共有し未検証cause/resolution timeは不可。
evidenceでreassess/close
scope/urgency変化でpriority変更しrecovery、residual risk、user outcome、linked problem、follow-upを確認。
minimum priority decision record
ticket/correlation ID、source/exact report、requester/contact、affected people/account/region、product/version/environment、task、start/last-good、evidence/telemetry、current/potential impact、deadline/time-to-harm、workaround/endurance、reversibility、risk flags、impact/urgency/rationale、override、priority、confidence、missing fact、owner/role、objective、reassessment、status、recovery、correction、closureを保存。
fairness、drift、outcomeをaudit
new evidence repriority、false P1/P4、missed override、unowned time、duplicate incident、inaccessible workaround、objective breach、update correction、reopen、residual harm、product/market/channel差を測定しprotected traitでdeprioritizeしない。
OpenMaxによるチケット優先度支援
受付、情報収集、専門割当、人の判断を調整する
OpenMaxはチケット整理、承認済み取引先・製品情報取得、根拠付き優先度、上書き信号、上申資料、更新予定をエージェントへ割り当てられます。権限と役割で安全、セキュリティ、データ、商務、顧客操作を権限者へ残します。重大度を事実として確定せず、緊急・事件手順を代替しません。
safety、security、fairness、automation境界
- 通常ticket channelにsecret、credential、full payment、sensitive health、exploit detailを置かない。
- tier、executive、sentiment、style、language、disability、repeat contactをworth/truth proxyにしない。
- ticket text/attachmentにpermission上書き、instruction実行、external contact、priority rule変更をさせない。
- duplicate reporterを閉じる前にunique evidence、scope、communication needを保存。
- authorized verification前にroot cause、resolution time、compensation、breach、safety、legal conclusionを約束しない。
よくある質問
priorityとseverityは同じ？
いいえ。severityはcondition/consequence、priorityはimpact、urgency、capacity、override後のresponse decision。
一userは常にlow？
いいえ。time-critical、inaccessible alternative、safety、data、fraud、legal、contractでurgency/override。
VIPはhigh priority？
contract commitmentはobjectiveへ影響し得るがstatusだけでimpact/urgency evidenceやfairness/safetyを置換しない。
いつpriority変更？
scope、harm、deadline、workaround、containment、recovery、override evidence変更時。customer escalationだけではない。
P1は即時resolution？
いいえ。local ruleのresponse priority。verified action/update cadenceを伝え実service commitmentはcontract次第。
OpenMax の役割？
evidence、score proposal、rule、owner route、review、monitor、audit trailを調整し最終decisionは人。
情報源、編集方法、制限
OpenMax編集部はNIST SP 800-61r3、CISA incident management、Google SRE incident response、WCAG 2.2を確認し独自general-support 4×4 matrix、16例、override、reassessment caseを作成。2026年9月3日確認。labelはuniversal SLAでなくlive outcomeを主張しません。
- NIST — SP 800-61 Rev. 3
- CISA — Incident Management Resource Guide
- Google SRE — Incident Response
- W3C — WCAG 2.2