> [!info] 出典 > Yinfang Chen, "Agentic Failure Management of Cloud Systems", Ph.D. Dissertation, **University of Illinois Urbana-Champaign**, 2026. Advisor: [[Tianyin Xu]](Chair)。Committee: Indranil Gupta, [[Minghua Ma]](Microsoft), Lingming Zhang, Minjia Zhang。原本 PDF: [[.raw/papers/CHEN-DISSERTATION-2026.pdf]](141ページ)。 > [!important] このページの scope > 本論文は 4 つの既発表システム論文([[Rainmaker]] は本論文が初出、[[RCACopilot]]・[[Stratus]]・[[AIOpsLab]] は既刊)を博士論文としてまとめたものである。**RCACOPILOT・STRATUS・AIOPSLAB の詳細(アーキテクチャ・数式・実験数値)は既存の wiki source ページに既に深掘り済みのため本ページでは重複させず、リンクのみ**とする。本ページで深掘りするのは (1) 本論文で初めて wiki 化する **Rainmaker(第2章)**、(2) 4系統を貫く thesis statement・Discussion・Future Work という**博士論文レベルの統合フレーミング**の2点。 > [!abstract] 概要(abstract の日本語訳) > クラウドシステムはますます重要になっている——世界の public cloud 支出は 2025 年に 7,230 億ドルに達すると見込まれる。しかしクラウドでは障害が常態であり、大規模システムのダウンタイムは 1 時間あたり 50 万ドルを超えることがある。自動化への巨額投資にもかかわらず、今日のクラウド運用は依然として人間のエンジニアに大きく依存している。 > 本論文は根本的な問いに取り組む: システムに知性を組み込み、障害を安全・効率的・大規模に自律的に検知・診断・回復させるにはどうすればよいか。我々は、インシデント発生前の予防から、発生後の根本原因分析、安全性保証を伴う自律緩和のためのマルチエージェントシステム、さらに agentic な解を比較できるベンチマークまで、クラウドインシデントライフサイクル全体にまたがるシステムを構築することでこの問いに答える。 > インシデント前段階(予防段階)では、クラウドを利用するアプリケーション向けの push-button な信頼性テストツール Rainmaker を提示する。Rainmaker は outbound の REST API 呼び出しを HTTP 層で傍受・操作し、現実的な一時的クラウド障害を注入する。Rainmaker はクラウドベースの障害モデルの下でエラー処理がどう壊れるかを分析して開発した 4 パターンのバグ taxonomy(エラー処理なし、無関係な例外のスロー、静かなセマンティック違反、状態の乖離)に基づいて構築される。Rainmaker は体系的なフォールトインジェクションを開発ワークフローの定常業務にする。 > しかし実世界の大規模システムはほぼ確実にバグを含み、テストがどれほど徹底していてもインシデントは発生する。インシデント後段階では、LLM の推論をクラウドインシデント管理に適応させる自動根本原因分析システム RCACOPILOT を導入する。RCACOPILOT は 3 つの再利用可能なアクション(スコープ切替・クエリ・緩和)からインシデントハンドラを構成し、診断情報を収集する。そして LLM を統合して根本原因カテゴリを予測し、予測の背後にある推論を説明する。 > 診断にとどまらず、我々は緩和までループを閉じる。LLM ベースのマルチエージェントシステム STRATUS を提示する。STRATUS は 4 つの専門エージェント(検知・診断・緩和・undo)を決定論的な状態機械に編成し、安全な探索と反復を可能にする Transactional No-Regression (TNR) と呼ぶ形式的安全仕様を伴う。TNR は古典的なトランザクション意味論を基盤に、成功しなかった緩和は必ず undo でき、外部から見えるシステムの重大度が障害検知時のベースラインを超えて増大しないことを保証する。 > 最後に、LLM と自律エージェントがクラウド運用にますます統合されるにつれ、この分野にはそれらの有効性を比較する厳密で再現可能なベンチマークが欠けていた。我々はこのギャップに AIOPSLAB で対処する。AIOPSLAB は検知・局所化・根本原因分析・緩和を含むクラウドインシデントライフサイクル全体にわたる LLM ベースエージェント向けの、最初のエンドツーエンドベンチマークスイートである。AIOPSLAB は現実的なマイクロサービス配備、フォールトライブラリ、エージェントに対してクラウドの複雑さを抽象化する Agent-Cloud Interface (ACI)、そしてアドホックなエージェントのデモンストレーションを再現可能な実験に変える Orchestrator を提供する。 > 本論文のシステム群を合わせると、現代クラウドシステムの自律的なトラブルシューティングへ向けた最初の一歩を示す。我々は完全に自律的なクラウドへ向けた議論と今後の方向性で締めくくる。 ## 論文情報 - タイトル: Agentic Failure Management of Cloud Systems - 著者: Yinfang Chen - 学位: Doctor of Philosophy in Computer Science - 所属: [[University of Illinois Urbana-Champaign]]、Graduate College、2026年、Urbana, Illinois - 指導教員: [[Tianyin Xu]](Chair) - 審査委員: Indranil Gupta / [[Minghua Ma]](Microsoft)/ Lingming Zhang / Minjia Zhang - PDF: `.raw/papers/CHEN-DISSERTATION-2026.pdf`(141ページ、著者本人の公開ページ https://tianyin.github.io/thesis/CHEN-DISSERTATION-2026.pdf より取得) ## 論文全体の構成(全6章) 本論文はクラウドインシデントライフサイクルに沿って4つの貢献を配置する(Table形式で整理)。 | 章 | システム | 段階 | wiki での既存深掘り | | --- | -------------- | ----------- | -------------------------------------------------------------------------------------------------------------------------- | | 第2章 | [[Rainmaker]] | インシデント前(予防) | **本ページで新規に深掘り**(下記) | | 第3章 | [[RCACopilot]] | インシデント後(診断) | [[@2024__EuroSys__Automatic Root Cause Analysis via Large Language Models for Cloud Incidents]](EuroSys'24) | | 第4章 | [[Stratus]] | インシデント後(緩和) | [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]](NeurIPS'25) | | 第5章 | [[AIOpsLab]] | 評価基盤 | [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]](MLSys'25) | **Thesis Statement(§1.1)**: 現代クラウドシステムの自律的トラブルシューティングは、インシデント管理ライフサイクルの両端における体系的な改善によって実用化できる。すなわち (1) 本番前では、体系的テストが潜在バグを検知することで失敗表面を縮小できる。(2) 本番中では、安全ガードレールを伴う AI によって自律的な障害管理を実現できる。 ## Rainmaker(第2章)— 本論文の新規深掘り ### 問題設定 現代アプリケーションは AWS S3・Azure Storage・CosmosDB のような RESTful クラウドサービスに依存する。この「クラウドネイティブ」実践には、不透明なクラウドバックエンドの障害モデルとアプリケーション-クラウド間接続の予測しづらさに由来する新しい信頼性課題が伴う。エラー処理にまつわる 3 要素——(1) クラウドサービスからのエラー応答(HTTP ステータスコード + サービス固有のエラーコード、例: Azure Blob Storage は 409 に対し 44 種のエラーコードを持つ)、(2) 一時的エラーへの SDK リトライ(Table 1: Azure Storage/CosmosDB/AWS S3・SQS でリトライ対象の HTTP コードが不統一)、(3) SDK からアプリケーションへのエラー伝播(.NET/Java は例外として伝播)——は、サービス間・SDK 間・同一 SDK のバージョン間で一貫性を欠く。例えば Azure Queue Storage は `QueueNotFound` を 404 で、AWS SQS は同じ論理エラーを 400 で表現する。この不統一が、開発者がコード内でどのエラーが表面化するかを予見しづらくする根本原因になる。また非冪等な API に対するリトライはリモートのデータ破損など独自のバグを生みうる。こうした一時的クラウド障害は稀にしか発生しないため、小規模・短時間の機能テストではエラー処理バグを見逃しやすい。 ### 提案手法: Rainmaker Rainmaker は RESTful クラウドサービス(Azure Storage・CosmosDB・AWS S3等)を使うアプリケーション向けの「push-button」型信頼性テストツール。既存のテストスイートにコード変更なしで**プラグアンドプレイ**適用できる。 - **フォールトインジェクション機構**: スタンドアロンの HTTP プロキシがアプリケーション→クラウドサービスの outbound REST API 呼び出しを傍受する。リクエストパスへの 5XX 注入はプロキシがリクエストをブロックしてエラーレスポンスを返し、レスポンスパスのタイムアウト注入はリクエストをサービスに到達させたうえで応答に遅延を入れてアプリケーション側でタイムアウトさせる。 - **HTTP 層介入の利点**: (1) SDK リトライで発生する呼び出しも含め REST 呼び出しを細粒度に傍受できる、(2) クラウドバックエンドアプリのエラー処理は例外型だけでなく HTTP ステータスコードにも依存するため対応できる、(3) アプリケーションの言語・アーキテクチャに関わらず透過的に機能する、(4) HTTP リクエスト/レスポンスは解釈しやすく、複雑な例外オブジェクトを理解する必要がない。 ### 4パターンのバグ taxonomy(§2.2) 1 回の REST API 呼び出しインタラクション(元リクエスト+リトライ)中に起きる一時的エラーの取り扱いがどう壊れるかを 4 分類する。 - **No Error Handling(エラー処理なし、29件)**: アプリケーションが一時的エラーを一切処理しない。SDK が全ての一時的エラーをマスクすると誤って想定した場合などに発生。全件が v12.3.0 以前の Azure Storage SDK(タイムアウトをリトライしない)または CosmosDB SDK(単一リージョン設定でリトライなし)を使うアプリで発生。 - **Throwing Unrelated Exceptions(無関係な例外のスロー、23件)**: リトライにより元の障害と無関係な新しいエラーが発生。Figure 2(Microsoft BotBuilder): レスポンスがタイムアウトした後、Blob 作成 API 呼び出しが実際には成功しているにもかかわらず、SDK が自動的にリトライして 409(BlobAlreadyExists)を受け取り、この無関係な永続エラーが while ループを破壊してログ喪失を招く(確認・修正済み)。 **Figure 1: Rainmakerの4つのフォールトインジェクションポリシー** ![[_attachments/CHEN-DISSERTATION-2026/fig01-fault-injection-policies.png]] (Figure 1. P1: 最初の応答のみタイムアウト。P2: 全応答をタイムアウト。P3: 全リクエストに5XXを返す。P4: 最初の応答をタイムアウトし以降のリクエストに5XXを返す。赤い爆発マークが注入点を示す。) **Figure 2: 無関係な例外のスローのバグ例** ![[_attachments/CHEN-DISSERTATION-2026/fig02-throwing-unrelated-exception-bug.png]] (Figure 2. Microsoft BotBuilder で Rainmaker が検出した確認・修正済みのバグ。Azure Storage SDK がタイムアウト時に自動リトライし、前提条件が最初のリクエストにより無効化されているため 409 エラーを返す。) - **Silent Semantic Violations(静かなセマンティック違反、4件)**: REST 呼び出しは正常終了しアプリケーションは happy path を進むが、非冪等 API へのリトライによりセマンティック違反が生じる。Figure 3(Microsoft Orleans): `GetQueueMessage()` がタイムアウトのたびに SDK が `ReceiveMessagesAsync` を複数回リトライし、そのたびにキューから 1 件ずつデキューしてしまう。最悪の場合キューが空になり `null` が返り Orleans が null 参照でクラッシュする。ドキュメントにこのコーナーケースが記載されているにもかかわらずアプリケーションは気づかない。 - **State Divergence(状態の乖離、17件)**: ローカル状態とリモート状態が乖離する。Figure 4(Microsoft BotBuilder): コンテナ作成前にローカルのコンテナ集合を楽観的に更新するが、実際の `CreateIfNotExistsAsync()` 呼び出しが 503 で失敗しても巻き戻さない。結果としてダングリングなコンテナ参照がローカル状態に残り、後の参照解決でクラッシュする(確認・修正済み)。 **Figure 3: 静かなセマンティック違反のバグ例** ![[_attachments/CHEN-DISSERTATION-2026/fig03-silent-semantic-violation-bug.png]] (Figure 3. Microsoft Orleans で Rainmaker が検出したバグ。Azure Storage SDK がタイムアウト時に複数回自動リトライし、誤ってキューを空にしてしまう。) **Figure 4: 状態の乖離のバグ例** ![[_attachments/CHEN-DISSERTATION-2026/fig04-state-divergence-bug.png]] (Figure 4. Microsoft BotBuilder で Rainmaker が検出した確認・修正済みのバグ。Azure Storage SDK が 503 エラーに対し複数回自動リトライするが、呼び出し前にローカル状態が更新済みのため乖離する。) ### フォールトインジェクションポリシーとカバレッジ(§2.3–2.5) - 4 ポリシー P1–P4(Figure 1)で taxonomy の全パターンをカバーできることを示す(Table 2 で対応関係を整理)。デフォルトでは request 失敗に 503(ServiceUnavailable)、response にタイムアウトを注入する(いずれも有効かつ安全な一時的障害)。 - どの REST 呼び出しに注入するかは 4 種のカバレッジ指標 C1–C4 で制御(Table 3)。C4(全テストの全ユニーク call site をカバー、デフォルト)が最も網羅的。call site 情報は .NET/Java の inheritable thread-local storage (ITLS) を使い、非同期の子スレッドへも自動伝播させることで、別プロセスの HTTP プロキシからも呼び出し元コード位置を特定できるようにする(独自の技術的工夫)。 - テスト計画はオフラインの一括処理: 障害注入なしの reference run でテストごとの所要時間と REST 呼び出しを観測し、C1/C2/C4 は直接算出、C3 は線形計画法(LP)で全テスト×全 call site をカバーしつつ総実行時間を最小化するペア集合を生成する。 ### テストオラクル(§2.6) アプリケーション非依存の2種のオラクルのみを使う。 - **Exception Oracle**: (1) テストが例外で失敗し、(2) その例外がテストコードでなくアプリケーションコードで生成され、(3) 例外が注入した障害と矛盾する、の3条件を満たす場合にバグ候補とする。条件(3)により「意図的に処理を放棄しているコード」を除外できる。 - **Assertion Violation Oracle**: 例外ではなくアサーション違反によるテスト失敗をバグ候補とする。静かなセマンティック違反や状態乖離のように即座に例外を出さないバグを捕捉する。 ### 実験評価(§2.7) - **対象**: Azure/AWS の6クラウドサービスを使う11個の成熟した .NET アプリケーション(Microsoft Orleans・BotBuilder・EF Core・FHIR Server・NuGet Insights・Petabridge Alpakka等、Table 4)。選択されるテスト数はアプリごとに2〜420件。 - **バグ検出**: 全11アプリで新規バグ73件(no error handling 29・throwing unrelated exceptions 23・silent semantic violations 4・state divergence 17、Table 5)。66件を upstream に報告し、執筆時点で55件確認・51件修正。 - **誤検知率**: 2,654件のテスト失敗中52件が偽陽性で1.96%。内訳は、意図的に4XXパスをテストする Insights の10件と、ハードコードされた短いタイムアウト設定を持つ Alpakka/IronPigeon のflakyテスト42件。 - **ポリシー・オラクルの相補性**: どの単一ポリシーも全バグを検出できない(Table 6)。DistributedLock-132 は 900件超のリクエストのうちわずか4件から来る特定の call site だけがトリガーになるバグで、ランダム注入ではまず発見できないが、call-site 指向のポリシーにより一貫して検出できる。 - **効率性**: C4 での実行に 0.57〜212.77 マシン時間(Table 8)。C4 は exhaustive baseline に比べテスト実行回数を平均64.47%削減。Orleans では394,172回(99.04%)の削減となり、削減なしでは588日かかっていた計算になる。 **Figure 8: カバレッジ指標ごとのテスト実行回数とバグ検出数** ![[_attachments/CHEN-DISSERTATION-2026/fig08-coverage-metric-comparison.png]] (Figure 8. Table 3 の C1–C4 各カバレッジ指標でのフォールトインジェクションテスト実行回数(棒グラフ)と検出バグ数(点)。Baselineは全REST API呼び出しへの網羅的注入。) ### 新規性・関連研究(§2.8) 既存のエラー処理静的解析(欠落ログ・TODO検出、エラー仕様検査、エラー伝播解析)や伝統的ソフトウェア・分散バックエンドシステム向けのフォールトインジェクション技術は、(1) ランダム化を超える自動ポリシーやクラッシュを超えるオラクルを欠く、(2) アプリケーション/ドメイン固有知識を要求する、(3) プログラムレベルの障害注入はセマンティック違反のような細粒度バグを検出できず例外オブジェクト構築も非自明、という限界を持つ。Rainmaker は REST インターフェースでの注入によりこれら3つの限界を回避する。 ### 限界と今後の方向性(§2.9) - **既存テストスイートへの依存**: 効果はクラウドサービスと相互作用するテストの充実度に依存する(例: Microsoft Orleans は 7,002 件中 155 件のみ)。モックされたテストを Rainmaker が駆動可能な形に自動書き換えする拡張が今後の方向。 - **テストコスト**: 大規模テストスイートでは多くのマシン時間を要する。テスト選択技術や変更コードへの差分テストでコスト削減が可能。 - **単一呼び出し障害モデルの限界**: 現行の taxonomy とポリシーは1回の REST API 呼び出し(元リクエスト+リトライ)内の障害のみを対象とし、複数の相関する API 呼び出しにまたがるバグ(例: あるサービスへの書き込みと別サービスからの読み込みの間)は対象外。 - **クライアント側バグを超えて**: AWS S3 の同一 REST API がリージョンによって一貫性保証が異なる、非冪等 API の 500 エラーの副作用がドキュメントからも不透明、といった発見があり、Rainmaker をクラウドサービス自体の differential testing ツールへ拡張する可能性を指摘。 - **修正が困難なバグ**: レスポンスパスのタイムアウトはアプリケーションにリクエストが実際に適用されたか判別不能にする。この種のバグをクリーンに解決するには HTTP ETag のようなリクエストバージョニングやトランザクション的な API セマンティクスがサーバー側に必要と論じる。 - **言語非依存性**: 現プロトタイプは .NET 対象だが、設計自体は言語非依存。.NET 固有部分は call-site instrumentation(.NET profiling API)と ITLS のみで、Java 等の他ランタイムへの移植は自然な拡張としている。 ## RCACOPILOT(第3章)・STRATUS(第4章)・AIOPSLAB(第5章)— 既存ページへの委譲 博士論文の第3–5章は、内容・数値・図表とも既存の一次論文 wiki source ページと同一である(第4章の TNR 定式化・実験は NeurIPS'25 版 STRATUS 論文と一致、第5章の 4-level タスク taクソノミー・評価数値は MLSys'25 版 AIOpsLab 論文と一致)。詳細は以下のページを参照: - [[@2024__EuroSys__Automatic Root Cause Analysis via Large Language Models for Cloud Incidents]] — RCACopilot のアーキテクチャ・実験・考察 - [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]] — TNR の形式化・実装・ablation - [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]] — ACI・Orchestrator・4-level タクソノミー・評価 ## 博士論文レベルの統合フレーミング(第1章・第6章) ### Thesis Statement と4つの貢献(§1.1–1.2) 現代クラウドシステムの自律的トラブルシューティングは、インシデント管理ライフサイクルの両端における体系的な改善で実用化できる: (1) 本番前は体系的テストによる潜在バグ検知で失敗表面を縮小し、(2) 本番中は安全ガードレール付きのAIによって自律的な障害管理を可能にする。4つの貢献([[Rainmaker]]・[[RCACopilot]]・[[Stratus]]・[[AIOpsLab]])は、この二極(予防 vs 本番自律化)と、それらを測定可能にするベンチマークという3つの補完的側面をカバーする。 ### Discussion(§6.1)— 本論文が新たに提示する考察 既刊の各論文には含まれない、博士論文としての統合的な考察が第6章に追加されている。 - **社会的含意**: STRATUS のように本番インフラへ人間の介入なしに状態変更アクションを取るシステムには、純粋な技術評価では捉えきれない社会的な重みが伴う。論文は4点を指摘する。(1) **説明責任と責任の所在**: 自律エージェントが重要インフラに作用し損害を与えたとき、委任した運用者・導入した組織・基盤モデルのベンダーのうち誰が責任を負うのか、既存の運用・法的規範は人間の意思決定者を前提としており不明確である。(2) **透明性と監査可能性**: 何が・なぜ・どのような効果で変更されたかの改ざん耐性のある記録が、インシデントの再構成と責任の割り当てに必要。(3) **自動化バイアスとオペレータの警戒心の低下**: エージェントが成功裏に処理するインシデントが増えるほど、監督する人間は状況認識と介入スキルを失っていく。(4) **運用統制の集中というシステミックなリスク**: 多数の独立システムが同一のモデル・プロンプト・ヒューリスティックに基づくエージェントへ緩和を委任すると、障害モードが相関し、単一の誤った推論パターンが無関係な複数サービスに同時多発的な誤対応を引き起こしうる。 - **human dimension**: 自律緩和は信頼性エンジニアリングから人間を除去するのではなく、その役割を再配置する。STRATUS のようなシステムが前線業務を担うにつれ、SRE の役割は「深夜に叩き起こされ runbook を実行する応答者」から「監督者」、より根本的には「エージェント挙動の仕様策定者」へ移行する。この再配置は第4章の形式的保証(TNR)の上に成り立つ: TNR はあくまで人間が定義する健全性条件に関して外部から見える状態が後退しないことを保証するに過ぎない。仕様がある種の害(データ破損・データ常駐地制約違反等)を見落としていれば、TNR上は non-regression と認定される遷移が運用上はあらゆる意味で悪化していることがありうる。したがって安全性は「人間による仕様の網羅性」に条件づけられ、その隙間を埋めることは削減不可能な人間の仕事である。日常インシデントをエージェントへ委任することはオンコール負荷を軽減する一方、この仕様策定に必要な暗黙の運用知識を時間とともに摩耗させるリスクも孕む。新規・曖昧・高難度のインシデントでは human-in-the-loop が引き続き必須であり、STRATUS はこのハイブリッド運用(writer agent が実行前に人間の承認を要求できる、割り込み可能な action stack)を既にサポートする。 ### Future Work(§6.2)— 5つの方向性 1. **効率的なマルチエージェント・マルチモデル協調**: エージェント間の同期をどう過剰・無秩序な通信なしに行うか、レイテンシに敏感な場面でいつ大規模モデル対小規模モデルを使い分けるか。 2. **運用における安全性保証と実行の封じ込め**: MCP (Model Context Protocol) 等を介したエージェントの外部システム操作に対し、ロールバック対応実行とpost-actionの健全性を継続評価する検証オラクル(retry/reflect/escalateの判断)を統合し、第4章のTNRをより広いエージェント駆動アクション一般へ拡張する。 3. **クラウドシステムを超えた自律運用の拡張**: IoT基盤・金融プラットフォーム・ロボットシステムのようなサイバーフィジカル/社会技術的環境。物理的・経済的な結果、ノイズの多いセンシング、計算資源の制約という点でクラウドと異なる課題を持つ。 4. **人間とAIの協調運用**: エージェントが推論を説明し不確実性を定量化して低信頼時にガイダンスを要求し、人間が継続学習を通じて訂正フィードバックを与える協調的自律性の枠組み。 5. **より holistic な評価プラットフォームへ向けて**: [[AIOpsLab]](第5章)を拡張し、より現実的なワークロードと広範な障害タイプの下でエージェント型AIシステムを検証するプラットフォームを開発する。運用上の有効性を超え、敵対的操作への耐性やDDoS等のセキュリティインシデントへの対処可能性など、セキュリティ・信頼性の評価も今後の目標とする。 ## 強み / 弱点・課題 ### 強み - インシデントライフサイクル全体(予防→診断→緩和→評価)を一貫した thesis statement の下に統合し、個々のシステム論文には無い横断的な位置づけを与えている。 - Rainmaker は HTTP 層フォールトインジェクションという単純な仕組みで、複数のクラウドプロバイダ・SDKバージョンにまたがる不統一なエラー処理という現実の問題に対し、taxonomy駆動の網羅的かつ効率的なテスト手法を提示している。 - 第6章 Discussion は技術的成果に留まらず、自律運用の説明責任・監査可能性・自動化バイアス・相関故障という社会的含意と、SREの役割変化という human dimension を、TNRという形式的保証の限界(仕様の網羅性への依存)と結びつけて論じており、単なる技術サーベイを超えた考察になっている。 ### 弱点・課題(論文記載・読み取り) - Rainmaker は .NET プロトタイプに限定され、単一 REST API 呼び出し内の障害モデルに留まる(相関する複数呼び出しにまたがるバグは対象外)。 - 4系統のうち3つ(RCACOPILOT・STRATUS・AIOPSLAB)は既刊論文の再録であり、博士論文としての新規性は主に Rainmaker と第1章/第6章の統合的フレーミングに集中する。 - Discussion で指摘される説明責任・自動化バイアス等の懸念に対する具体的な技術的対策は、本論文の実装(TNR等)には反映されておらず、今後の課題として提起されるに留まる。 ## 関連 - システム: [[Rainmaker]] / [[RCACopilot]] / [[Stratus]] / [[AIOpsLab]] - 概念: [[障害注入]] / [[プロアクティブ障害管理]] / [[agentic SRE]] / [[障害緩和]] / [[AIOps]] / [[根本原因分析]] / [[Transactional No-Regression]] - 既存一次論文: [[@2024__EuroSys__Automatic Root Cause Analysis via Large Language Models for Cloud Incidents]] / [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]] / [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]] - 著者: [[Yinfang Chen]] - 指導教員・所属: [[Tianyin Xu]] / [[University of Illinois Urbana-Champaign]] / [[Minghua Ma]] - 関連 MOC: [[LLM4SRE - MOC]] / [[Project AI4SRE - MOC]] / [[AIOps - Failure Detection - MOC]]