# Change Object Rewrite ## 定義 Change Object Rewrite（COR、変更オブジェクト書き換え）とは、根本原因変更特定のパイプラインにおける前処理技法であり、実際の変更チケットに含まれる断片的・意味的に不整合な自然言語記述を、LLM を用いて意味的に完全で標準化された「変更オブジェクト」テキストへ書き直す処理を指す。 [[MagmaScope]]([[@2026__ICSE-SEIP__MagmaScope Identifying Root-Cause Changes for Emergency Incident in Large-Scale Cloud Infrastructure]], ICSE-SEIP '26, §3.3.1)が導入した技法。変更チケットは変更の意図・対象・操作を記述するドキュメントだが、実際の本番変更チケットはしばしば： - 複数の独立した変更が 1 チケットにまとめられている - 略語・内部専門用語・不完全な記述が混在する - 異なるチームが異なる書き方をするため意味的一貫性がない こうした不整合な変更記述は、語彙的類似スコアや意味的相関に基づく根本原因特定の精度を低下させる。COR はこれを LLM に標準化させることで有効な相関可能形式に変換するセマンティック正規化・圧縮層として機能する。 ## 設計上の位置づけ MagmaScope の 3 フェーズパイプラインにおいて、COR は Phase 3 のエージェントが上位候補を深く分析する前処理として位置づけられる。具体的には： 1. **検索段(Stage 1)**: インシデント時刻前 24 時間の変更チケットを取得 2. **ランキング(Phase 2)**: 4 スコア(時間近接性・変更依存グラフ・アラーム相関・語彙的類似)で上位 50 件を選び、LLM ベースの細粒度ランキングで上位 10 件へ絞り込む 3. **COR とエージェント推論(Phase 3)**: 上位 10 件の変更チケットを COR で標準化し、LLM エージェント(ReAct)が IM チャットと照合 COR がない場合、MagmaScope の Top@5 精度は 74.72% から 72.12% に低下する。Table 1 は COR を除いた構成のアブレーション結果を含み、その貢献を検証している。 ## 横断的知見 - **COR は「変更記録の意味的正規化」という新しい前処理カテゴリを根本原因特定パイプラインに導入し、テレメトリの前処理(ノイズ除去・次元削減)に対応する操作が「自然言語記述」レイヤーにも必要であることを示す**: 既存の [[Fault Localization]] や [[根本原因分析]] 研究が扱う前処理はログの解析・メトリクスの正規化・トレースのフィルタリングという数値/構造化データ中心のものだった。COR はそれと対称的に、**変更票という自然言語記述の品質問題**を処理対象とする。大規模クラウドインフラでは変更票の記述品質のばらつきが大きく、LLM が意味的に補完・標準化することなしに高精度な変更起因インシデント分析ができないという実証を、ByteDance 本番 55 件という実データで初めて提供した。変更票の断片性・意味的不整合は、[[変更起因インシデント]] の検知課題 4「非効率な異常変更箇所特定」と直接対応しており、COR はその上流での解法と位置づけられる。(Source: [[@2026__ICSE-SEIP__MagmaScope Identifying Root-Cause Changes for Emergency Incident in Large-Scale Cloud Infrastructure]] §3.3.1, Table 1) - **COR が前提とする「変更チケットには根本原因変更を示す意味的情報が潜在的に含まれる」という仮定は、変更チケット記述が体系的に貧弱な組織では成り立たない可能性がある**: MagmaScope の評価は ByteDance の内部 IM ワークフロー・専門用語・プライベート知識を基盤とする。変更チケットの記述品質が組織ごとに大きく異なる状況で、COR の LLM が汎化できるかは未検証である。また doubao-1.6-thinking という ByteDance 固有の LLM バックエンドを使用しており、ByteDance の内部情報が学習データに含まれる可能性(データ汚染)が外部妥当性を制限する。(Source: [[@2026__ICSE-SEIP__MagmaScope Identifying Root-Cause Changes for Emergency Incident in Large-Scale Cloud Infrastructure]] §4.4) ## 未解決の問い - **COR の「書き直し」によってどの程度の情報が追加・省略・変換されるか、その忠実性を保証する評価基準は何か**: COR は「断片的記述を標準化する」が、LLM が原チケットに存在しない情報を生成(ハルシネーション)する可能性は排除できない。MagmaScope の論文は COR の評価をアブレーション(COR あり/なし比較)の形で示すが、書き直し自体の忠実性(元の変更内容を正しく保持しているか)を個別評価する基準は提示されていない。 - **COR と同様の「不完全な自然言語記述の意味的正規化」が、変更チケット以外の AIOps 入力(アラートメッセージ・runbook・ポストモーテム)にも有効か**: 変更チケット固有の課題(複数変更の混在・略語の多用)と類似した問題がアラートメッセージ([[アラート管理]])やポストモーテムにも存在する。COR の設計をこれらの入力型に転用する場合、書き直しのプロンプト設計や事後検証の方法はどう変わるか。 - **COR の効果がどの変更チケット品質レベルに最も敏感か**: 非常に短い記述と非常に長い詳細な記述では COR の貢献度が異なるか。最低限どの程度の記述品質があれば COR が機能するかのしきい値は未知。 ## 関連 - 親/隣接 concept: [[変更起因インシデント]] / [[根本原因分析]] / [[LLMによる根本原因分析]] / [[Fault Localization]] / [[インシデント管理]] - 実装システム: [[MagmaScope]] - ソース: [[@2026__ICSE-SEIP__MagmaScope Identifying Root-Cause Changes for Emergency Incident in Large-Scale Cloud Infrastructure]] §3.3.1 ## 出典 - [[@2026__ICSE-SEIP__MagmaScope Identifying Root-Cause Changes for Emergency Incident in Large-Scale Cloud Infrastructure]](§3.3.1: Change Object Rewrite の設計と役割、Table 1: COR アブレーション研究結果)