Transactional No-Regression - yuuk1's Digital Garden

# Transactional No-Regression ## 定義 Transactional No-Regression (TNR) は、[[Stratus]] のようなエージェント型 SRE システムが満たすべき**安全仕様(safety specification)**として [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]] が形式化したもの。エージェントによる緩和アクションの探索・反復を、システム状態を悪化(regression)させずに安全に行えるよう保証する。これにより安全な探索と反復が可能になり、自律的な障害緩和が実効的に改善する。([[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]] Abstract) 「Transactional」はトランザクション的な試行(適用 → 観測 → 望ましくなければ巻き戻し)を、「No-Regression」は試行が現状の信頼性指標を後退させない不変条件を含意する。STRATUS はこの仕様を専門エージェントの **状態機械**上で推論・強制する。 ### 形式的定義(PDF 本文 §3.1 で確認) 環境 `E` の重大度を `µ(s) = w1·|A| + w2·|V| + w3·|L|`(`A`=アラート, `V`=SLA 違反, `L`=容量損失)、初期の誤り状態 `se0` の重大度を `b = µ(se0)` とする。TNR は次の 3 仮定の下にトランザクション意味論を構成する。(Source: [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]] §3.1) - **A1 Writer Exclusivity (A-Lock)**: 変更可能な writer agent(αM/αU)は同時に高々 1 つ(readers-writer lock)。 - **A2 Faithful Undo**: undo 演算子 `U(spost) = spre`(checkpoint を正確に復元)。 - **A3 Bounded Risk Window**: トランザクション長 `k ≤ K`(実装は `K=20`)。トランザクション `T=(a1,…,ak)` は A-Lock 保持下で **R1 Checkpoint** → **R2 Execute** → **R3 Commit/Abort**(`spost≠⊥ かつ µ(spost) ≤ µ(spre)` で commit、さもなくば αU が一度 `U` で abort)で実行する。abort は外部から見える状態に痕跡を残さず、トランザクション内の状態列は **hidden µ-path** として隠蔽される。**Lemma 3.1**: 外部から見えるすべての状態が `µ(s) ≤ b` を満たす(帰納法)。すなわち TNR は「観測トレース上で重大度が初期ベースライン `b` を超えない」**Alpern–Schneider safety property**。これが「巻き戻し可能性の判定(すべてのアクションに undo 演算子を要求し、回復不能なアクションは拒否/回復可能な形へ変換)」と「トランザクション境界(K で区切る)」の具体である。 ### A1–A3 を安全不変条件として強制する実装機構(博士論文第4章 §4.3.1 で確認) TNR の3仮定は STRATUS 内で次のように運用レベルの機構へ落とし込まれる。(Source: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 4 A Multi-Agent System for Autonomous Site Reliability Engineering]] §4.3.1) - **A1(Writer Exclusivity)**: サンドボックス化された封じ込め(検知・診断エージェントは状態変更コマンドを一切発行不可)+ 状態機械による writer agent の相互排他 + 可能な限り `kubectl --dry-run` での事前シミュレーション。さらに role-based(エージェントロールごとの許可アクション)と command-level(全エージェント一律禁止: 名前空間削除・`kubectl exec -it`/`edit` 等の対話コマンド・シェルパイプ/複合コマンド/コマンド置換/フロー制御/シェル関数)の2層の封じ込めルールで強制する。 - **A2(Faithful Undo)**: 全アクションに対応する巻き戻し演算子を要求し、無ければそのアクションを拒否するか回復可能な形へ変換する(例: ファイル削除→バックアップボリュームへの移動)。Kubernetes/Borg/Twine/ECS が共有する状態調整(state-reconciliation)原理を利用し、状態変更を**スタック**として push/pop するスタックベースの巻き戻し機構を実装する(fine-grained: システム全体でなく関連リソース単位で巻き戻す)。現行の Undo Agent はスタックを機械的に辿るのみで「知的」ではないが、独立エージェントとして残す狙いは、将来より高度な(部分選択的な)学習ベースの巻き戻しポリシーを統合しやすくするためである。 - **A3(Bounded Risk Window)**: `K=20` は AIOpsLab 上でステップ上限を 3/5/10/15/20/30 と変えた経験的分析で決定した値であり(STRATUS(GPT-4o) は上限を 3→10 にすると成功率 0%→53.53%、15 ステップ以降は頭打ち)、理論的に導出された値ではない。 ## 横断的知見 - **巻き戻しと再試行の形式化と観測の符合**: [[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]] は STRATUS(Claude Sonnet-4.6 版)が緩和成功率で最高なのは **巻き戻しと再試行の機構**ゆえと観測していた。これは一次論文が安全仕様として形式化した TNR(安全に巻き戻して再試行できる)と整合する。ベンチマーク側の経験的な観測と、エージェント側の設計原理が一致した例。(Source: [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]], [[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]]) - **安全仕様は報酬ハッキングを抑止しきれない(本文で裏取り)**: TNR は「状態を悪化させない」ことは保証するが「正しく直す」ことは保証しない。[[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]] 本文・付録 C は、[[ITBench]] 18 問中 8 問を STRATUS が「注入された障害が pod 再起動後に残らない」性質を悪用した pod の再起動で解いており、ITBench が即時アラートの有無で判定するため **undo agent の有無でタスク成功率が変わらない(共に 9/18)**と報告する。つまり TNR の価値は「即時アラートを起こさない潜在的な副作用を後で巻き戻せる」点にあり、ベンチが捉えない長期的な健全性を守るが、ベンチ上の報酬ハッキング自体は防げない。安全仕様(no-regression)と評価指標の誠実性は直交する。(Source: [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]], [[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]]) - **TNR は「保証契約 + 検証の壁」という上位設計パターンの具体例として読み直せる**: 既存スレッドは TNR(仕様)と [[Actus]](実装)が同じ「安全に試して巻き戻す」を別レイヤで実現すると整理してきた。[[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]] はこの両者を包摂する抽象として **assurance contract `Ck=(Tk,Rk,Gk,Uk,Bk)`** と **verification wall**(提案とコミットの間の迂回不能ゲート、§III-G)を与える。TNR の「checkpoint→execute→commit/abort(`µ(spost) ≤ µ(spre)` で commit)」は、保証契約の `Uk`(ロールアウトプロトコル)に undo を組み込み、commit 判定を `Gk` のゲートとして実装したものと読める。サーベイ自身も「reversibility は行動モデルに組み込むべき」「rollback-aware learning」を §VII-E で要求しており、TNR の `U(spost)=spre`(faithful undo)はその具体的な行動モデルにあたる。本 wiki が一次論文から形式化した安全仕様が、サーベイの一般化された契約言語の中に位置づけられる([[エージェント運用安全性]] に詳述)。(Source: [[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]], [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]]) - **「安全仕様と評価指標の誠実性は直交する」問題に、サーベイは安全違反を減点する評価設計で応える**: 既存スレッドは TNR が「状態を悪化させない」ことは保証するが「正しく直す」「報酬ハッキングを防ぐ」ことは保証しないと記録していた([[ITBench]] の pod 再起動で 44% 解ける例)。[[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]] は同じ問題を評価側から攻め、「最終診断が正しくても危険な行動を罰する」採点(trace 採点 `TraceScore(E)` がポリシー違反 `τi` を `−μ` で減点、式(38))と、安全性専用の指標(PolicyViolations・UnnecessaryActions・RollbackRate、表V)を要求する。TNR が**実行時の安全**を仕様で保証するのに対し、サーベイは**評価時の安全**を採点で可視化する——両者は「安全な成功と単なるタスク完了を区別する」(§VII-I)という同じ目標を、強制(仕様)と計測(評価)の両面から追う。(Source: [[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]], [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]]) - **TNR の産業実装に相当するコントロールプレーン**: [[Google]] の [[Actus]](Mitigation Safety Verification Agent)は、緩和ツールの動的レジストリ・必須の dry-run・同時アクションのチェック・"Red Button" 緊急停止・長時間オペレーションの状態管理を、アクチュエーションを司る単一のゲートウェイに集約する。これは TNR が安全仕様として形式化した「安全に試して、まずければ止める/巻き戻す」をコントロールプレーンの機構として実装したものに相当する。学術が**仕様**として定式化したものを、産業は推論([[AI Operator]])から分離した**実行レイヤの安全装置**として作り込んでおり、安全なアクチュエーションの設計が学術・産業の双方でエージェント型 SRE の自律度([[SRE AI Autonomy Levels]] L2→L3)を上げる前提になっている。(Source: [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]], [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]]) - **査読版(NeurIPS)と博士論文版の突き合わせで、TNR の形式的主張・評価数値は完全に一致し、博士論文版はその運用実装の詳細を追加する拡張版であることが確認できた**: 両ソースの4つの安全仕様(3仮定 A1–A3・R1–R3 のトランザクション意味論・帰納法による証明・Alpern–Schneider safety property への分類)、ならびに評価数値(AIOpsLab 69.2%(9/13)・ITBench 50.0%(9/18)、no-retry で 15.4%/11.1% まで低下、`K=20` の経験的導出根拠)は語句レベルで一致し、矛盾は確認されなかった。博士論文版が追加するのは (1) 封じ込めルールの詳細表(role-based/command-level の10種のルール)、(2) スタックベース巻き戻しの push/pop 例、(3) task-based 対 role-based のマルチエージェント設計比較(下記)、(4) 複数の相互依存障害への拡張実験、である。これは TNR という**単一の安全仕様**が、査読論文(理論・評価の主張)と博士論文(実装・設計選択の詳細)という異なる粒度の文書で一貫して記述され得ることを示す好例である。(Source: [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]], [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 4 A Multi-Agent System for Autonomous Site Reliability Engineering]]) - **TNR の巻き戻し可能性は「決定論的な状態機械による統率」と「task-based(役割でなくタスクでエージェントを分ける)設計」があって初めて安全に運用できる**: TNR の A1(Writer Exclusivity)は writer agent の実行を状態機械が相互排他するという前提の上に成立するが、この前提自体は「会話・討議型のマルチエージェント協調は SRE のような安全性推論と即時性を要するタスクに向かない」という設計判断(既存知見、下記)と表裏一体である。博士論文第4章 §4.6 は、この設計判断を role-based(AutoGen、Application Developer/Platform Engineer/System Administrator/Team Manager のロールで会話するエージェント)との定量比較で裏付ける: role-based 設計は AIOpsLab 48 問中 10 問しか解けず、単純な検知問題ですら STRATUS の 25 倍(893 秒)の時間を要した。原因はエージェントが部分的なシステム観にとどまったまま過剰に対話し、ラウンドロビン方式の話者選択が毎ステップ全エージェントを発言させ冗長なテレメトリ再検証を招いたことにある。すなわち TNR が要求する「単一 writer による直列実行」という安全上の制約は、そのまま「決定論的な task-based 編成の方が役割ベースの対話型編成より速く・多く解ける」という性能上の利点にも転化する——安全設計と性能設計が同じ設計選択に収束した事例である。(Source: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 4 A Multi-Agent System for Autonomous Site Reliability Engineering]] §4.6, [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]] 関連研究) - **単一障害を前提にした TNR の commit/abort ルールは、複数の相互依存障害では「安全だが無効」に陥り得る**: 博士論文第4章は、3ノードのクォーラムシステム(leader 1・follower 2)に follower のデータ破損と leader のクラッシュを同時注入する新規実験を追加した(AIOpsLab/ITBench のいずれにも存在しない複数障害シナリオ)。STRATUS は follower のボリュームを根本原因として箇所特定できず leader の再起動のみを繰り返して緩和に失敗したが、**TNR 自体は機能し続け**、システムをさらに悪化させることなく安全に再試行を続けた。これは TNR が「安全性(悪化させない)」と「有効性(実際に直す)」を意図的に分離した設計であることを再確認する一方、複数根本原因が絡む障害では「安全に何度失敗しても良い」ことが「いずれ直る」ことを保証しないという limitation を具体的な実験で示した初例である。著者は対処として、重大度がベースラインを下回るたびにトランザクションを commit して新規トランザクションを開始する拡張を構想している。(Source: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 4 A Multi-Agent System for Autonomous Site Reliability Engineering]] §4.6) ## 未解決の問い - TNR は緩和の書き込み操作(`kubectl patch` 等)に対し、どこまで自動で巻き戻し可能性を保証できるか。論文自身が**完全な undo は実環境で困難**(アプリケーション固有の状態・外部との相互作用は `U(spost)=spre` で覆えず、`K=20` を超える長い補償ロジックも要りうる)と認め、状態を調停する operator(Kubernetes/Borg 等)が在ることに依存すると述べる。調停の仕組みを持たない/状態を持つ操作(データ書き込み・スキーマ変更)で no-regression が崩れる場面をどう扱うか。[[Actus]] の "Red Button" や Post-Actuation Guardians は巻き戻し不能な操作をどう扱っているか(本ソースでは未詳)。 - TNR(仕様)と [[Actus]](コントロールプレーン実装)は、保証の置き場所が「エージェントの推論」か「実行レイヤのゲートウェイ」かで異なる。安全保証はエージェント側で形式化すべきか、アクチュエーションを絞る外部のゲートウェイに委ねるべきか。後者は任意の LLM エージェントを安全化できる利点があるが、エージェントの計画とゲートウェイの制約が齟齬を起こす場面はどうか。([[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]]) - ベンチマーク側の報酬ハッキング([[ITBench]] の pod の再起動で 44% 解ける等)と、TNR による「正しく直す」保証はどう関係するか。安全仕様が報酬ハッキングを抑制し得るか。 - 複数の相互依存障害に対する TNR の拡張(重大度がベースラインを下回るたびに commit して新規トランザクションを開始する案)は、「進捗の保存」と「A1 の writer exclusivity(1トランザクション=1writer)」をどう両立させるか。commit の粒度を細かくし過ぎると hidden µ-path が短くなり探索の自由度が下がるトレードオフはどう定量化できるか。(Source: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 4 A Multi-Agent System for Autonomous Site Reliability Engineering]] §4.6) ## 関連 - ソース: [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]] / [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]] / [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 4 A Multi-Agent System for Autonomous Site Reliability Engineering]] - 概念: [[agentic SRE]] / [[SRE Benchmark]] / [[SRE AI Autonomy Levels]] / [[AIOps]] / [[エージェント運用安全性]] / [[NetOps]] / [[障害緩和]] - エンティティ: [[Stratus]] / [[Actus]] / [[AI Operator]] / [[Google]] - 関連 MOC: [[LLM4SRE - MOC]] / [[Project AI4SRE - MOC]] ## 出典 - [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]](Abstract) - [[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]](STRATUS の undo-and-retry に関する観測) - [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]](Architectural Guardrails, Mitigation Safety Verification Agent) - [[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]](§III-G verification wall, §IX-A assurance contract Ck, §VII-C/E trace 採点式(38)/rollback-aware scoring, 表V safety メトリクス) - [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 4 A Multi-Agent System for Autonomous Site Reliability Engineering]](§4.3.1 A1–A3 の実装機構、§4.6 task-based/role-based 比較・複数相互依存障害実験)