エージェント運用安全性 - yuuk1's Digital Garden

# エージェント運用安全性 ## 定義エージェント運用安全性は、運用上の制御面(control surface)の近くに座る LLM エージェントが、信頼でき・監査可能で・安全に展開可能な行動だけを取るよう、**モデルを取り巻く機構**で保証する取り組み。[[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]] の通底主張は「運用上の信頼性は主にモデル自体からは来ず、モデルを取り巻く機構に依存する」というもので、その機構を 5 つに整理する——型付きツールインターフェース(typed tool interface)・来歴と鮮度を考慮した検索(provenance/freshness-aware retrieval)・明示的な予算と停止規則(explicit budgets and stopping rules)・最小権限アクセス(least-privilege access)・エージェントが迂回できない書き込み境界の検証ゲート(verification gate at the write boundary)。中心の形式装置が**保証契約(assurance contract)**で、自律度の段 `k` ごとに `Ck = (Tk, Rk, Gk, Uk, Bk)`(許可ツール面・必須証拠・迂回不能ゲート・ロールアウトプロトコル・予算、式(42))と定義し、契約充足を trace 性質 `τ ⊨ Ck`(必須証拠を含み・予算を守り・実行行動でゲートを迂回しない、式(44)-(46))という**測定可能な主張**に落とす。「検証の壁(verification wall)」命題(§III-G、式(13))は、すべての書き込み行動が健全なゲート `g:(a,E,Π,I)↦{allow,deny}` を通過した場合のみ実行されるなら、実行された書き込み列はモデル化された領域で `Π`(ポリシー)と `I`(不変条件)を満たすと示す。 ## 横断的知見 - **「安全に巻き戻せる実行とセットでしか自律度は上げられない」に第 3 の定式化が加わった**: 本 wiki は既に学術([[Stratus]] の安全仕様 [[Transactional No-Regression]])と産業([[Google]] の [[Actus]] というアクチュエーション安全ゲートウェイ)が同じ結論に収束していると整理していた。本サーベイは同じ命題を**一般化された保証契約**として定式化する第 3 の角度を与える——`Ck` の `Gk`(迂回不能ゲート)と `Uk`(ロールアウトプロトコル、canary + rollback)が、TNR の「checkpoint→execute→commit/abort」と Actus の「dry-run + Red Button + 状態管理」を抽象した上位概念にあたる。TNR が **STRATUS エージェントの推論内**で安全仕様として強制され、Actus が**実行レイヤのゲートウェイ**として外付けされるのに対し、本サーベイの verification wall は「提案とコミットの間の迂回不能な界面」という設計パターンとして両者を包摂する。学術の仕様・産業の実装・サーベイの抽象の 3 層が、書き込み境界での検証という同一原理を指す。(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]], [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]]) - **自律度の階梯が「能力」でなく「権限契約」で刻まれる点で Google L0–L4 と一致し、かつ形式化で踏み込む**: 本サーベイの自律度 4 段(Copilot/Analyst/Planner–executor/Closed-loop、表II)と §IX の 5 段(L0 read-only copilot / L1 evidence-gathering analyst / L2 proposal agent / L3 bounded executor / L4 closed-loop self-healing)は、[[Google]] の [[SRE AI Autonomy Levels]](L0–L4、Monitor/Investigate/Mitigate/Actuate/Self-Direct の自動化度)と同じく**どこまで人間を外せるか**の権限委譲軸で自律度を刻む。両者とも「Mitigate(判断)と Actuate(実行)の分離」(本サーベイの `T^write = T^propose ∪ T^exec`、Google の L2 = 判断は人間・実行は自動)という同型の分割を持つ。違いは、Google が定性的な 5 軸表で統治するのに対し、本サーベイは段を `Ak=(T^read,T^write,G)` という権限契約として形式化し、契約充足 `τ ⊨ Ck` をベンチマークで採点可能にする点。産業の統治フレームワークと学術の形式化が、同じ「権限委譲としての自律度」を別の精度で記述する。(Source: [[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]], [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]]) - **「情報を取りすぎる病理」を予算と停止規則で形式的に制約する**: 本 wiki は [[agentic SRE]]/[[AIOps]]/[[根本原因分析]] で、テレメトリ過剰消費・貪欲な固着・過剰プロービングという「制御されない情報取得が害になる」病理を複数ソースから繰り返し観測してきた([[AIOpsLab]] §3.6・[[SREGym]]・[[MicroRemed]]・[[Bits AI SRE]])。本サーベイはこれを予算ベクトル `B=(B^tool,B^tok,B^time,B^risk)`(式(10))と停止規則 `S`(予算枯渇・必須証拠欠落・ゲート失敗・矛盾観測の反復・人間判断要、§III-B)として**第一級の安全制約**に格上げする。さらに停止判断を `StopScore = Pr(stop|証拠不十分) − Pr(stop|証拠十分)`(式(37))として採点可能にし、早すぎる結論を罰する。本 wiki が経験的病理として束ねてきたものに、設計上の予防機構(予算 + 停止規則)と評価指標(StopScore)が与えられた。(Source: [[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]], [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]], [[@2025__arXiv__MicroRemed - Benchmarking LLMs in Microservices Remediation]]) - **operational artefacts を「攻撃面」として扱う安全観が、本 wiki の「インシデント記録の一次データ化」と緊張する**: 本サーベイは runbook・チケット・チャット記録・テレメトリ文字列を untrusted 入力チャネルとみなし、prompt injection・retrieval poisoning・telemetry integrity attack の運び手として設計の中心面に置く(§VIII、図15)。一方本 wiki の [[インシデント管理]] は、[[Datadog]] エンジニアの Slack インシデントタイムライン([[ARFBench]])や OCE の事後報告([[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]])を「専門家アノテーションの一次源」として AI 評価に昇格させる流れを記録してきた。同じ運用成果物が、片や信頼できる正解ラベルの源泉、片や攻撃面として扱われる——両立させるには、本サーベイの言う authoritative / advisory / untrusted の信頼階層(表I)と、untrusted な成果物は独立チェックなしに書き込みを駆動してはならない、という規律が要る。(Source: [[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]], [[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]]) - **評価が「結果」から「過程・安全性」へ移る潮流に、契約充足という統一指標を与える**: 本 wiki の [[根本原因分析]] は、[[Cloud-OpsBench]] が RCA を結果 A@k でなく推論軌跡の整合(過程)で採点する white-box ベンチを出したこと、[[ITBench]] が軌跡の迂回/カバレッジを測ることを記録してきた。本サーベイはこの「過程評価」を保証契約の充足 `τ ⊨ Ck`(必須証拠の充足・予算遵守・ゲート非迂回・ロールアウト規律)として一般化し、各ベンチ事例を `τ ⊨ Ck` か否か(部分点付き)で採点する benchmark rule を提案する(§IX-C)。さらに「最終診断が正しくても危険な行動を罰する」採点を要求し、本 wiki の [[Transactional No-Regression]] が観測した「安全仕様(no-regression)と評価指標の誠実性は直交する」(報酬ハッキングは防げない)という問題に、安全違反を明示的に減点する評価設計で応える。(Source: [[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]], [[@2026__arXiv__Cloud-OpsBench - A Reproducible Benchmark for Agentic Root Cause Analysis in Cloud Systems]], [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]]) ## 未解決の問い - verification wall の健全性保証は「モデル化された領域内」に限られ、カバレッジの穴・古いモデル・不健全なチェッカで含意が破れる(本サーベイ §III-G が留保)。AIOps 側の不変条件(SLO・error budget・blast radius)は NetOps の到達可能性/隔離ほど明確にチェッカ化できないため、サービス層の verification wall はどこまで健全たりうるか。([[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]]) - 保証契約 `Ck` の `(Rk,Gk,Bk)` を「達成可能だが非自明」に選ぶ問題(表VII の Safe autonomy)は、refusal storm(過剰な拒否)と over-permissive execution(過剰な許可)の間のチューニング。本 wiki の [[agentic SRE]] が記録する「能力天井(6 割前後)」のもとで、契約を厳しくすると拒否が増え緩めると危険が増える——能力が低いまま安全な契約は成立するか。 - TNR(エージェント推論内の安全仕様)・Actus(実行レイヤのゲートウェイ)・本サーベイの assurance contract(設計パターンとしての抽象)は、保証の置き場所が異なる。任意の LLM エージェントを外付けゲートウェイで安全化する方式と、エージェントの計画自体に契約を埋め込む方式は、エージェントの計画とゲートウェイの制約が齟齬を起こす場面でどちらが頑健か。([[@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]]) - telemetry integrity の cross-signal consistency check(式(39)(40))は metrics/traces/logs の独立性を前提とするが、本 wiki の [[根本原因分析]] は「本番の 99% が少なくとも 1 種の観測を欠く」(観測の不完全性)と記録する。3 チャネルが揃わない本番で一致性ガードはどう機能するか。信号欠落自体を攻撃と非攻撃で弁別できるか。([[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]]) - 本サーベイが提案する最小相互運用スキーマ集合(tool call・evidence pointer・diff・approval・rollback・audit log の 6 種、§IX-G)は OpenTelemetry/gNMI を基盤候補に挙げるが、本 wiki の各一次ソース([[Stratus]]・[[Bits AI SRE]]・[[LogPilot]] 等)の trace 形式は bespoke。replay 可能性と比較可能性を担保する共通スキーマは現実に収束しうるか。 ## 関連 - ソース: [[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]] - 概念: [[Transactional No-Regression]] / [[SRE AI Autonomy Levels]] / [[NetOps]] / [[AIOps]] / [[agentic SRE]] / [[根本原因分析]] / [[インシデント管理]] - エンティティ: [[Stratus]] / [[Actus]] / [[AI Operator]] / [[Google]] / [[AIOpsLab]] / [[Cloud-OpsBench]] - 関連 MOC: [[LLM4SRE - MOC]] / [[SRE - MOC]] / [[Project AI4SRE - MOC]] / [[Network - MOC]] ## 出典 - [[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]](§I 通底主張, §III-A workflow contract, §III-B budgets/stopping rules, §III-E provenance/freshness retrieval, §III-F typed tools/least privilege, §III-G verification wall 命題, §IV autonomy rungs as capability contracts/表II, §VII trace 採点/StopScore, §VIII threat-to-control 表VI/cross-signal consistency, §IX-A assurance contract 式(42)-(46)/表VII)