# インシデントトリアージ ## 定義 インシデントトリアージ(Incident Triage)は、発生したインシデントを解決の責任を持つ適切なチームへ割り当てるプロセスである。[[インシデント管理]]のライフサイクル(検知→トリアージ→緩和)において、検知直後・緩和着手前に位置する工程であり、トリアージ完了までの時間は Time to Triage(TTT)、検知から緩和完了までは Time to Mitigation(TTM)と定義される([[@2024__ISSRE__Large Language Models Can Provide Accurate and Interpretable Incident Triage]] Fig. 1)。伝統的にはルールベースの決定木(例: [[@2024__ISSRE__Large Language Models Can Provide Accurate and Interpretable Incident Triage]] の AutoAnalysis)で実装されるが、新規シナリオへの継続的なルール更新が必要という限界があり、分類器ベース([[DeepCT]]・[[DeepTriage]] 等)や LLM ベース([[COMET]])の手法が提案されてきた。 ## 横断的知見 - (このページは本ソースの取り込みで新規作成した。現時点では単一ソース([[@2024__ISSRE__Large Language Models Can Provide Accurate and Interpretable Incident Triage]])のみに基づくため横断的知見は蓄積されていない。今後、他のトリアージ関連ソース([[DeepCT]]・[[DeepTriage]] 等の原論文が ingest された際、または関連する [[インシデント優先順位付け]]・[[インシデントTTM予測]] との突き合わせで得られた観察をここに追記する。) - **「トリアージ」という同一語が、AIOps文献では「どのチームに割り当てるか」という分類タスクを、セキュリティ危機対応の実務では「危機と呼ぶべきか否か・侵害かバグか」という質的判断を指しており、両者は対象が根本的に異なる**: 本概念が集約するCOMET等のAIOps文献は、既に検知され重大度も概ね確定したインシデントを適切なチームへルーティングする分類問題としてトリアージを扱う。一方 [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 17 Crisis Management]] のトリアージは、エスカレーションを受けた対応者が「誤検知か・定型処理可能な単純な侵害か・組織的対応を要する複雑な侵害か」を人間の判断で見極める、対応の入り口の質的分類である。同章はさらに、同一の脅威(ランサムウェア)でも組織の防御層と対応プロセスの成熟度次第で結果が全く異なるという3組織の思考実験を通じて、トリアージの結論がインシデントそのものの性質だけでなく受け手の組織の準備状態に依存することを示す——これはCOMET等のML分類器が学習する「インシデントの特徴からチームを予測する」という設計には現れない観点であり、人間による危機判定が組織文脈依存的な判断を要する点でAIOps的な自動化トリアージより複雑な問題であることを示唆する。(Source: [[@2024__ISSRE__Large Language Models Can Provide Accurate and Interpretable Incident Triage]], [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 17 Crisis Management]] §Triaging the Incident) - **侵害(compromise)とバグ(脆弱性)の区別という、AIOps文献のトリアージ分類には存在しない第三の軸**: BSRS 17章は、多層防御が適切に機能していればソフトウェアバグ(脆弱性)の是正は通常インシデント対応プロセスを流用する必要はないが、影響が極めて大きい脆弱性(Spectre/Meltdown・Heartbleed・Shellshock等)は侵害の有無にかかわらずインシデントとして扱うべきだと述べる。本概念が扱うAIOpsトリアージ手法(COMET・DeepCT等)はいずれも「既に発生したインシデント」を前提にチーム割り当てを最適化するのに対し、BSRS の区別は「そもそもこれをインシデント対応プロセスに乗せるべきか」という、より上流の意思決定を扱っており、AIOpsトリアージの入力データ自体がどう生成されるべきかという設計上の前提を問い直す視点を提供する。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 17 Crisis Management]] §Compromises Versus Bugs) - **同じベースライン群(DeepCT・DeepTriage・COMET)が、Microsoft 系(本概念)と ByteDance/Nankai 系([[オンコール自動化]]・[[知識蒸留]])という異なる研究系譜のトリアージ論文で共通の比較対象として使われている**: CoTriage([[@2026__nkcs.iops.ai__Collaborative Knowledge Distillation and Reinforcement Learning for Automated Ticket Triage in Large-Scale Production Systems]])は ByteDance STE チームのチケットトリアージで DeepCT・DeepTriage・COMET を非 LLM/LLM ベースラインとして採用し、ACC@1 で +28.2〜40.4pt(非 LLM 比)の改善を報告する。InsightTriage([[@2026__ASE__LLM-Assisted Joint Ticket and Log Analysis for Incident Triage in Intelligent and Connected Vehicles]])も Huawei ICV データで DeepTriage・COMET を含む 4 手法をベースラインとして採用しており(Weighted F1: DeepTriage 0.500・COMET 0.211 vs. InsightTriage 0.801)、DeepCT・DeepTriage・COMET が組織・ドメイン(ByteDance のオンコール、Huawei の車載)を越えて事実上の標準ベースライン群として定着していることを示唆する。ただし各論文のデータセット規模・分割方法は異なるため、性能数値そのものは直接比較できない。(Source: [[@2026__nkcs.iops.ai__Collaborative Knowledge Distillation and Reinforcement Learning for Automated Ticket Triage in Large-Scale Production Systems]] §5.4、[[@2026__ASE__LLM-Assisted Joint Ticket and Log Analysis for Incident Triage in Intelligent and Connected Vehicles]] Table 2) - **COMET が複数の異なるドメインで一貫して低性能を示す一方、その原因の説明は各論文で異なる**: 本概念の定義元 COMET 論文([[@2024__ISSRE__Large Language Models Can Provide Accurate and Interpretable Incident Triage]])自身はキーワード抽出+埋め込み類似度によるオンライン展開で ACC@1 を 30% 改善したと報告するが、InsightTriage([[@2026__ASE__LLM-Assisted Joint Ticket and Log Analysis for Incident Triage in Intelligent and Connected Vehicles]])が Huawei ICV データで再実装した COMET は Weighted F1 = 0.211 と全ベースライン中最低の性能に留まった。InsightTriage の著者は、COMET のルールベースキーワードフィルタリング(例: "crash")が症状駆動で多様な ICV シナリオに不適合であることを原因として挙げる。**同一手法の移植性の低さが、トリアージ手法の一般化可能性という共通課題を浮き彫りにする**。(Source: [[@2026__ASE__LLM-Assisted Joint Ticket and Log Analysis for Incident Triage in Intelligent and Connected Vehicles]] §5.2) - **「ログをどう使うか」がチケットトリアージ手法を差別化する軸として浮上している**: COMET はキーワードベースの単純なログ選択、InsightTriage はコントラスティブ学習によるクエリ駆動ログ検索+LLM 構築の構造化知識ベースという、ログ活用の深さが大きく異なる 2 つの設計を代表する。InsightTriage のアブレーション(ログ検索器除去で Weighted F1 が 0.801→0.609、19.2% 低下)は、ログを「単なる補助情報」から「クエリと同格の一次証拠」として扱うことの効果を定量的に裏付ける。(Source: [[@2026__ASE__LLM-Assisted Joint Ticket and Log Analysis for Incident Triage in Intelligent and Connected Vehicles]] §5.3.2) - **「チームへの割り当て」を明示的な単一責任に固定するか、複数チームエージェントの分散協調に委ねるかで、トリアージの信頼性の作り方が根本的に異なる**: COMET([[@2024__ISSRE__Large Language Models Can Provide Accurate and Interpretable Incident Triage]])・DeepCT・DeepTriage・CoTriage・InsightTriage はいずれも「1 回の分類判断」でチームを決定するアーキテクチャだが、Comfey([[@2026__FSE Companion__An Agentic Framework for Triaging Incidents in Production Cloud Infrastructure]])はチームごとの team-scoped エージェントに local な accept/reject 判断をさせ、拒否時は Global Routing Table を介して次候補へ転送する多段階・分散型設計を採る。Comfey のアブレーションでは Global Routing Table の除去（ナイーブなランダム隣接ネゴシエーションへの置換）が精度を 40% 低下させ、単一分類器型のアーキテクチャでは表現できない「履歴駆動のチーム間ルーティング」自体が精度の主要な駆動要因であることを定量的に示した。(Source: [[@2026__FSE Companion__An Agentic Framework for Triaging Incidents in Production Cloud Infrastructure]] §4.6) - **Comfey と COMET は同一組織（Microsoft Azure）・同一著者グループの継続関係にあり、中央集権型 LLM トリアージから分散型エージェントトリアージへの直接的な進化を示す一次資料である**: COMET はキーワード抽出+埋め込み類似度に基づく中央集権的な LLM トリアージシステムとして 2 クラウドサービスに 6 か月超展開され ACC@1 30% 改善を報告したが、後継の Comfey は COMET を「先行の Azure 本番システム」として直接比較し、トリアージ精度を +7.55%、トリアージ時間を 4.38 倍、緩和時間を 2.91 倍改善したと報告する。両者の精度が近い理由を著者らは「情報抽出に LLM を用いる点が共通するため」と説明し、時間面の優位は分散アーキテクチャとエンリッチされたデータ収集に帰する。**同一組織内での中央集権→分散化という設計転換が、精度向上ではなく主に運用効率（時間短縮）で正当化されている**点は、他組織のトリアージ研究の設計判断を評価する上での参照点になる。(Source: [[@2026__FSE Companion__An Agentic Framework for Triaging Incidents in Production Cloud Infrastructure]] §4.8) - **実運用の実証研究が「複数チームにまたがるインシデントの多さ」と「トリアージ判断の可逆性」を裏付ける一次データを提供している**: Comfey の実証研究（Azure 15 チーム、2024 年 3 月〜2026 年 1 月）は、クラウドインシデントの多くが典型的に 5〜30 チームにまたがること（一部は 20 チーム超）、85% のインシデントが異なるチームに割り当てられた重複/準重複レポートを持つこと、月間インシデントの 12.1% でチームが一度受理した後にエスカレーション・移管することを定量化した。これは本概念の「トリアージ完了までの反復的性質」を裏付けるとともに、単一チームへの 1 回限りの分類（COMET・DeepCT 等）では実態を十分にモデル化できない可能性を示唆する。(Source: [[@2026__FSE Companion__An Agentic Framework for Triaging Incidents in Production Cloud Infrastructure]] §2.2) ## 未解決の問い - BSRS 17章が示す「危機か否か・侵害かバグか」という質的判断を、AIOpsのトリアージ分類器(COMET・DeepCT等)の特徴量やラベル設計に組み込むことは可能か。組織の防御層の成熟度という文脈情報を学習器に与える設計は存在するか。 - インシデントトリアージ(チーム割り当て)と[[インシデント優先順位付け]](緩和の優先順位付け)は、Microsoft の異なる研究系譜(本ソースの著者群 vs [[インシデントTTM予測]]の Chen+チーム)がそれぞれ攻めているが、両者を統合したパイプライン設計(トリアージ→優先順位付け→緩和の一気通貫最適化)はどう設計すべきか。 - LLM ベースのトリアージ([[COMET]])における「キーワード抽出が要約より優れる」という知見は、根本原因分析(RCA)や TTM 予測など他のインシデント管理タスクにも一般化できるか。 - COMET の語彙制限(訓練時抽出キーワードのみを推論時に許容)は新規キーワードの取りこぼしリスクを伴う。オープン語彙かつオンライン処理可能なキーワード抽出手法は実現できるか。 - 2023年以降のLLMベース RCA 手法(RCACopilot・RCAgent・[[@2024__ICSE__Xpert - Empowering Incident Management with Query Recommendations via Large Language Models|Xpert]] 等)とのトリアージ精度の直接比較は行われていない。同一データセット・同一評価指標での横断比較はどう設計すべきか。 - COMET が Microsoft クラウドサービス(元論文)と Huawei ICV(InsightTriage の再実装)で性能が大きく乖離した(30% 改善 vs. 最低性能)原因は、ドメインの違いか、再実装の忠実度か、それとも「ルールベースキーワードフィルタリング」という設計自体の一般化限界か。追試による切り分けが必要。 - ログをクエリ駆動で検索する設計(InsightTriage のコントラスティブ学習ログ検索器)は、車載ログ以外のドメイン(クラウドサービス・マイクロサービス)のチケットトリアージにも同程度の効果(19.2% の性能寄与)をもたらすか。 - Comfey の分散型・多段階トリアージ(team-scoped agent + Global Routing Table)と、COMET・DeepCT・DeepTriage 等の単一分類器型トリアージを、同一データセット・同一評価指標で直接比較したらどちらが優れるか。Comfey の評価は COMET との比較に限られ、DeepCT・DeepTriage・CoTriage・InsightTriage 等の他ベースラインとは比較されていない。 - Comfey のホップ上限の記述には §3.6.3(デフォルト 10)と §4.7(5 チーム連続拒否)で数値の不一致がある。この設定可能パラメータの実運用での最適値・トレードオフ(誤ルーティングの許容 vs 人間へのエスカレーション頻度)はどう決定すべきか。 - Comfey の Global Routing Table(スティグマジックなチーム間ルーティング)は、COMET・OncallX のような単一エージェント/中央プランナー型のアーキテクチャに後付けで統合可能か。統合した場合、精度・レイテンシはどう変化するか。 ## 関連 - ソース: [[@2024__ISSRE__Large Language Models Can Provide Accurate and Interpretable Incident Triage]] / [[@2026__nkcs.iops.ai__Collaborative Knowledge Distillation and Reinforcement Learning for Automated Ticket Triage in Large-Scale Production Systems]](同一ベースライン群を用いる別系譜) / [[@2026__ASE__LLM-Assisted Joint Ticket and Log Analysis for Incident Triage in Intelligent and Connected Vehicles]](COMET を再実装しログ活用を深化させた ICV ドメイン版) / [[@2026__FSE Companion__An Agentic Framework for Triaging Incidents in Production Cloud Infrastructure]](COMET の直接後継、分散型エージェントトリアージへの転換) / [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 17 Crisis Management]](「トリアージ」を質的な危機判定として扱う人間主導の対概念) - 概念: [[インシデント管理]](上位概念・ライフサイクル全体) / [[インシデントTTM予測]](トリアージ後の緩和時間予測) / [[インシデント優先順位付け]](並列研究系譜) / [[オンコール自動化]](チケットトリアージをサブタスクとする ByteDance/Nankai 系譜) / [[知識蒸留]](CoTriage の中核技術) / [[マルチエージェント協調]](Comfey のスティグマジックルーティング設計) / [[危機時の指揮系統]](危機判定後の指揮の持続) - エンティティ: [[Zexin Wang]] / [[Minghua Ma]] / [[Chetan Bansal]] / [[Microsoft]] / [[Ruowei Fu]] / [[Shenglin Zhang]] / [[Nankai University]] / [[Huawei Technologies]] / [[Comfey]] / [[COMET]] / [[Microsoft Azure]] ## 出典 - [[@2024__ISSRE__Large Language Models Can Provide Accurate and Interpretable Incident Triage]](§II 実証研究・§III COMET アーキテクチャ・§V オフライン評価・§IV オンライン展開) - [[@2026__nkcs.iops.ai__Collaborative Knowledge Distillation and Reinforcement Learning for Automated Ticket Triage in Large-Scale Production Systems]](§5.4 ベースライン比較で DeepCT・DeepTriage・COMET を共通比較対象として使用) - [[@2026__ASE__LLM-Assisted Joint Ticket and Log Analysis for Incident Triage in Intelligent and Connected Vehicles]](§3・§5.1.4・§5.2 でベースライン比較・COMET 再実装結果を報告) - [[@2026__FSE Companion__An Agentic Framework for Triaging Incidents in Production Cloud Infrastructure]](§2.2 実証研究・§3 Comfey 設計・§4.6 アブレーション・§4.8 COMET 比較) - Matt Linton (with Nick Soda and Gary O'Connor), "Crisis Management", in Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 17, §Triaging the Incident, §Compromises Versus Bugs.