# オンコール自動化 ## 定義 オンコール自動化(on-call automation)は、オンコールエンジニア(OCE)が担うシステム障害の受付・調査・対応・トリアージを LLM およびマルチエージェント技術で自動化する研究・実践領域である。対象タスクは「インシデント対応」（アラートやユーザーから報告された障害を解決する）と「チケットトリアージ」（自動解決できない障害を適切なチームへ割り当てる）の 2 軸に分類される。(Source: [[@2025__ASE__LLM-Powered Multi-Agent Collaboration for Intelligent Industrial On-Call Automation]] §I) 手動オンコールの主要な課題は 3 つである: (1) OCE の習熟度依存（一人前になるまでに数ヶ月〜数年の訓練が必要）、(2) 人間のワークロード限界による応答遅延（1 時間のダウンタイムで億ドル規模の損失）、(3) インシデントの増量・複雑化（数千サービス・分散アーキテクチャ・クロスリージョン・多様な技術スタック）。(Source: §I) ## 横断的知見 - **オンコール自動化は「インシデント対応」と「チケットトリアージ」の二タスクで完結するが、既存研究はそれぞれを別個に扱っており、エンド・ツー・エンド設計は OncallX（2025）が初例とされる**: チケットトリアージ研究（DeepCT・DeepTriage・COMET 等）と LLM ベース RCA 研究（RCAgent・Flow-of-Action 等）は別系統で発展し、ライフサイクル全体をカバーする統合システムが欠落していた。OncallX はこの空白を埋めた最初の実装として位置づけられる。(Source: [[@2025__ASE__LLM-Powered Multi-Agent Collaboration for Intelligent Industrial On-Call Automation]] §I Contribution (1), §VII-C) - **本番デプロイで実証された効果量は 789 倍（対応）・50 倍（トリアージ）という突出したオーダーの改善である**: ただし基準値（人手 0.58 人日 / 200 秒）は大規模企業の単一 STE チームの数値であり、スタックが整備された組織やより熟練した OCE チームでは差が縮小する可能性がある。同ドメインの比較実験（インシデント対応 Pass Rate 78.26% vs. ReAct 71.01% 等）はより控えめな改善量を示す。(Source: §V-B・§V-E) - **エンド・ツー・エンド自動化とは異なる「共通インターフェース化」による属人化対処のアプローチも存在する**: OncallX が対応・トリアージの自動化を目指すのに対し、Amazon の MCP ベース実装(Papapanagiotou, SREcon25 EMEA)は、人間とエージェントが同一データ・同一ツールハンドル(MCP)から推論する構成そのものによってオンコール属人化に対処する。すなわち「自動化してタスクを肩代わりする」のではなく、「人間とエージェントの情報・ツールアクセスを揃えることで、誰が対応しても同じ根拠に基づける」という別解であり、オンコール自動化の設計空間には「タスク代行型」と「インターフェース共通化型」の少なくとも二軸があることを示唆する。(Source: [[@2025__SREcon25EMEA__Modernizing Incident Response with LLMs, RAG, and the MCP]]) - **同一著者陣・同一 ByteDance STE ドメインで、チケットトリアージに対して「fine-tuning-free な知識グラフ拡張」と「知識蒸留+RL によるファインチューニング」という対照的な 2 つの技術路線が独立に本番デプロイされている**: OncallX([[@2025__ASE__LLM-Powered Multi-Agent Collaboration for Intelligent Industrial On-Call Automation]], 2025-09)は KG で候補カテゴリ空間を絞り込み LLM プロンプティングで判定する fine-tuning-free 設計を採り、8,662 チケット中 145 件のテストで ACC@1=0.652・ACC@3=0.774 を報告する。CoTriage([[@2026__nkcs.iops.ai__Collaborative Knowledge Distillation and Reinforcement Learning for Automated Ticket Triage in Large-Scale Production Systems]], 2026)は LLM から SLM への知識蒸留 + 自己強化 + DPO によるファインチューニングを採り、1,678 チケット中 220 件のテストで ACC@1=0.618・Macro-F1=0.506 を報告する。両者はデータセット規模・分割方法・評価データが異なるため ACC@1 の数値を直接比較できないが、同じ研究グループが 2 系統の技術路線を並行追求している事実そのものが、チケットトリアージには決定版アプローチが定まっていないことを示す一次証拠である。fine-tuning-free 路線はカテゴリの動的変化への対応力を、蒸留+RL 路線は少量データでの専門知識獲得を、それぞれ主要な強みとして提示している。(Source: [[@2026__nkcs.iops.ai__Collaborative Knowledge Distillation and Reinforcement Learning for Automated Ticket Triage in Large-Scale Production Systems]] §新規性・§考察) - **チケットトリアージ単体でも、テールクラス（希少チーム）の性能向上には「合成データによる補完」が有効だが、意味的に隣接するクラス間の判別は依然として困難**: CoTriage は自己強化ステップでテールクラスの合成チケットを生成し、Platform チーム(希少)で F1=0.667 を達成する一方、OS/Other と表層症状が重なる Virtualization/CentralCloud では F1=0.087 に留まる。OncallX の KG ベースアプローチはカテゴリ空間の絞り込みで精度を稼ぐが、同様の「意味的に隣接するクラス」への対処法は論文中で明示されていない。合成データ拡張と知識グラフ制約は補完的に組み合わせられる可能性がある。(Source: [[@2026__nkcs.iops.ai__Collaborative Knowledge Distillation and Reinforcement Learning for Automated Ticket Triage in Large-Scale Production Systems]] §5.2) - **同一著者陣(Ruowei Fu・Shenglin Zhang・Nankai University)が、ByteDance ドメイン(OncallX・CoTriage)に加えて Huawei/ICV ドメイン(InsightTriage)へも「チケットトリアージ」研究を横展開している**: InsightTriage([[@2026__ASE__LLM-Assisted Joint Ticket and Log Analysis for Incident Triage in Intelligent and Connected Vehicles]], ASE '26 投稿版)は Huawei との産学連携で車載(ICV)ドメインに特化し、KG ベースのカテゴリ絞り込み(OncallX)や知識蒸留+RL(CoTriage)とは異なり、コンポーネントレベル知識ベース + コントラスティブ学習ログ検索という「ログ活用の深さ」で差別化する。3 論文はいずれも「オンコール自動化はインシデント対応とチケットトリアージの 2 タスクに分解できる」という同一著者陣の問題整理を共有しつつ、InsightTriage はチケットトリアージ(ログ+チケットのジョイント分析)のみに特化し、対応タスクは扱わない点で OncallX とはスコープが異なる。(Source: [[@2026__ASE__LLM-Assisted Joint Ticket and Log Analysis for Incident Triage in Intelligent and Connected Vehicles]] §1) ## 未解決の問い - **オンコール自動化の汎化範囲はどこか**: OncallX は ByteDance STE チーム（OS カーネル・仮想化・基盤ソフトウェア）という単一ドメインのみで評価されている。Web サービス・DB・ネットワーク・ML 訓練クラスタ等の異業種・異ドメインでどの程度 plug-and-play が成立するか。CoTriage も同一ドメインでの評価に留まるが MSR 2013 Bug データセットでの汎化性を追加検証しており(ACC@1=0.335)、ドメイン外では性能が有意に低下することを示している。 - **チケットトリアージの動的カテゴリ変化への対応**: OncallX の KG は履歴チケットから構築されるため、新カテゴリ追加時の知識グラフ更新ラグがトリアージ精度に与える影響は未検討。CoTriage は新規 2 チーム(30 チケット)でのデータドリフト実験(F1=0.554)を行っているが、両手法の新カテゴリ対応力を同一条件で比較した研究はまだない。 - **コンテキスト推論限界の実際の影響**: 多ターン対話が増えるほど LLM のコンテキスト保持が低下する問題（§VI-A）に対し、会話履歴圧縮機構・RAG ベース外部メモリ・階層ツリー分割のどれが最も効果的か。 - **自動化が OCE の習熟度形成を阻害しないか**: 認知的徒弟制（[[認知的徒弟制]]）の観点から、自動化が介入することで OCE が障害対応スキルを習得する機会が失われるリスクがある。 - **fine-tuning-free 路線と蒸留+RL 路線を統合したハイブリッド設計は単独手法を上回るか**: KG によるカテゴリ空間の事前絞り込み(OncallX)と蒸留済み SLM による最終判定(CoTriage)を組み合わせた場合の性能は、いずれの論文でも検証されていない。 - **ByteDance ドメイン(OncallX・CoTriage)で有効だった知識グラフ拡張・知識蒸留のアプローチは、Huawei/ICV ドメイン(InsightTriage)のようなコンポーネント知識ベース+ログ検索アプローチと組み合わせ可能か**: InsightTriage はログ活用を深化させる一方 KG ベースのカテゴリ絞り込みを用いていない。逆に OncallX/CoTriage はログを主要な証拠として明示的に扱っていない。ハイブリッド設計は未検証。 ## 関連 - 関連 source: [[@2025__ASE__LLM-Powered Multi-Agent Collaboration for Intelligent Industrial On-Call Automation]] / [[@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]] - 実装: [[OncallX]] / CoTriage / InsightTriage - 組織: [[Nankai University]] / [[ByteDance]] / [[Huawei Technologies]] - 上位概念: [[インシデント管理]] / [[agentic SRE]] - 関連手法: [[マルチエージェント協調]] / [[LLMによる根本原因分析]] / [[知識グラフ]] / [[知識蒸留]] - 関連概念: [[インシデントトリアージ]](Microsoft 系譜のインシデントトリアージ研究との対比) - 関連研究: [[structures/AIOps.MOC]] への一方向参照 ## 出典 - [[@2025__ASE__LLM-Powered Multi-Agent Collaboration for Intelligent Industrial On-Call Automation]] - [[@2025__SREcon25EMEA__Modernizing Incident Response with LLMs, RAG, and the MCP]] — 共通インターフェース化によるオンコール属人化対処の産業実装 - [[@2026__nkcs.iops.ai__Collaborative Knowledge Distillation and Reinforcement Learning for Automated Ticket Triage in Large-Scale Production Systems]] — 知識蒸留+RL によるチケットトリアージ路線(OncallX との対比) - [[@2026__ASE__LLM-Assisted Joint Ticket and Log Analysis for Incident Triage in Intelligent and Connected Vehicles]] — Huawei/ICV ドメインへの横展開、ログ活用深化によるチケットトリアージ路線