🧭 自律SRE前提のコンテキスト基盤設計 (SREの4体問題)

この記事は、CNCF Blog (2026-07-06, Sanjeev Sharma / Field CTO at StackGen) の「SRE の 4体問題 (4-Body Problem of SRE)」と、その解として提案される Live Context Graph / Agentic OS for Ops という方法論を、構造とデータの観点から技術調査したものです。本方法論は具体的なプロダクトでなく設計思想のため、構築方法・利用方法のコード例は「意図を反映した実装案」として示し、補完元を明示します。

概要

本方法論は、SRE が直面する「4体問題 (4-Body Problem of SRE)」を起点に、自律運用に必要な文脈 (context) 基盤の構築方法を提示します。

なぜ自律運用のボトルネックは model capability でなく context なのか

現代の運用において、どの意思決定も 4 つの真実の体の交差点に座ります。

• Code: commit、PR、branch、build artifact、version、config change。何を、いつ deploy し、昨日と何が違うか
• Infrastructure State: cloud account、network、Kubernetes cluster、queue、database、IAM policy の実際の現在形。Terraform が示す desired と、今実際にある actual
• Runtime Signals: metrics、logs、traces、events、error budgets、SLOs、customer-impacting alerts。今この瞬間システムが何をしていて、いつ挙動が変わったか
• Operational Knowledge: tribal wisdom、post-mortems、ADR (Architectural Decision Records)、on-call playbooks、runbooks。なぜそうなっているかを説明する Slack thread

各体は単独でほぼ解決済です (Git、Terraform + cloud API、Prometheus 等の observability、Confluence / Notion / Slack)。問題は、あらゆる意思決定が 4 体すべての交差点に座り、交差点にはこれまでシステムが無かったことです。

この交差点は、シニアエンジニア数名の頭の中に断片で存在する「人間の糊 (people putty)」で埋められてきました。人間パテは、高価・希少・2 年で辞める・スケールしないという性質を持ちます。runbook は書いた瞬間が最も正確で、次の infra 変更で drift します。stale runbook は無い runbook より悪いです。自信を持った誤った行動を招くからです。

エージェントの失敗は、多くの場合、断片化された文脈に起因します。断片化された文脈は、検証しづらい「もっともらしい失敗 (plausible hallucination)」を生みます。自律運用の前提は、エージェントが reason できる統合された文脈です。

4体問題とは何か

著者は物理の 3 体問題を比喩として引用します。物理の 3 体問題は、3 つの質量の長期的な軌道が閉形式解を持たず、カオス的に振る舞うことで知られます。著者の framing では、4 体問題は単に 33% 難しくなるのでなく、ダイナミクスが質的に (qualitatively) 変わります。SRE の 4 体 (Code、Infrastructure State、Runtime Signals、Operational Knowledge) も、独立でなく互いの軌道が常に影響し合います。SRE は「顧客信頼を失わずに 30 秒後のシステム位置を予測する」実践です。

従来、この 4 体を同時に追跡できるのは、数名のシニアエンジニアの頭の中だけでした。著者が経験した深夜 2 時のインシデントブリッジコールでは、8 ベンダー・200 行 RACI が並び、真因は誰の observability にも統合されていない subcontracted network telemetry stream に隠れていました。この夜が教えたことは 2 つです。

1. 誰も全体像を持っていない
2. どんなに経験豊富でも、人間は全体像を頭の中に保持できない

Live Context Graph と Agentic OS がどの問題を解くか

Live Context Graph は、4 体すべてとその間の関係の「単一・リアルタイム・クエリ可能・観測可能・durable」な表現です。Knowledge Graph から導出され、進化の順は Artifacts → Knowledge Graph → Live Context Graph です。以下の 5 つの性質を持ちます。

• Live: stale context は no context より悪い。昨日のビューは今日の世界ではない
• Context graph: 価値は個々のノード (commit、Terraform resource、span、runbook) でなく edges (エッジ) にある。「この commit がこの module を変え、この resource を provision し、この latency anomaly を出し、過去のこのインシデントに一致し、この fix で解決した」
• Queryable: 人間とエージェント双方から、一貫した semantics でクエリ可能
• Observable: グラフ自身が first-class な telemetry source。グラフが live でなくなったことを検知できる
• Durable: すべてのエージェント決定は特定バージョンのグラフに対して下される。validation と auditability のため replay できる

Agentic OS for Ops は、Live Context Graph の上で動作する runtime です。reasoning agents、policy、guardrails、human-in-the-loop approvals が住む場所です。基盤なしにクリティカルパスに置ける信頼できる agent は無い、というのが核心的な主張です。

People putty が最も厚い 3 箇所から回収が始まります。

• CI/CD pipelines: 全 commit / build / test / deploy と過去インシデントの学びが agent の working memory に入る。SLO breach 時に「何か変わったか」を聞かずに済む (13:54 に connection-pool config を触った deploy が diff・author・blast radius 付きで既知)
• Infrastructure drift: Terraform の should と cloud の is を継続 reconcile し、drift を outage 化前に flag する。金曜夜の break-glass fix のような intentional drift も observable event として扱う
• SLO violations: breach が traceable agent decision を trigger する。hypothesis 形成 → historical pattern に対しランク付け → policy guardrail 内で bounded experiment (canary rollback、throttle、scale-out、bad node isolation) → 全ステップ log。人間は最初の 12 分の調査が citation 付きで済んだ war room に入る

共通パターンは、agents read from graph → reason hypotheses → act within policy → write result back です。各ループがグラフを richer にし、次を良くします (compounding)。

The Path の 2 原則

自律運用への道は、2 つの原則に集約されます。運用の詳細は「ベストプラクティス」で扱います。

1. Treat operations as data (graph-before-agents): Code / Infra State / Runtime Signals / Operational Knowledge を相互不信のサイロにせず、query・version・reason できる Live Context Graph に統合する。基盤が agents より先に来る
2. Embed agents in the path, not after it: 事後の post-mortem 自動化は dictation にすぎない。エージェントは 4 体を継続ループで reason し、各決定が trace を足し、各 trace が次を良くする

信頼の正体は decision trace

「LLM を挟んだスクリプト」は autonomy ではありません。先週火曜と prompt が違い、木曜に model version が上がり、input context がどこにも記録されないなら、それは opaque automation です。各エージェント行動は durable な記録 (decision trace) を生む必要があります。詳細は「データ」の情報モデルで扱います。

メトリクスの位置づけ

agent が 4 体を継続 reason し、事後に post-mortem を書くのでなく path に埋め込まれると、インシデントは稀になり 2 a.m. page は例外になります。注視すべき数字は「どれだけ速く復旧したか (MTTR)」から「どれだけ悪い夜を経験せずに済んだか」へ移ります。ただし、これは基盤と trace を正しく作った consequence であり、出発点ではありません。

成熟度の段階

copilots から autopilots への ladder があります。「AI assists me」から「AI acts on its own」へ向かい、ほとんどの組織は mid-climb です。2026 年に完全自律運用に到達するかは No です。ただし trajectory は明確で、人を増やしてもスケールしません。better context と trustworthy agents でスケールします。

特徴

本方法論の特徴を以下に列挙します。

• 4 体の統合による全体文脈の構築: Code / Infrastructure State / Runtime Signals / Operational Knowledge を単一のグラフに統合し、意思決定が座る交差点を初めてシステム化する
• エッジに価値を置く設計: 価値は個々のノードでなくエッジ (関係性) にあり、commit から fix までの因果連鎖がエージェントの推論基盤になる
• Live・版管理・observable なグラフ: 最新性 (Live)、replay 可能な版管理 (Durable)、グラフ自身の観測可能性 (Observable) を同時に満たす
• decision trace による auditability: 各行動が inputs・policies・model version・hypotheses・action・outcome を durable に記録し、auditable / reproducible / trustworthy を担保する
• graph-before-agents の原則: エージェントより先に統合文脈基盤を作る。断片化された文脈の上で動かすと plausible failure を生む
• エージェントを path に埋め込む: 事後の post-mortem 自動化でなく、継続ループでインシデントをそもそも稀にする
• metrics は consequence: MTTR から「悪い夜を避けた回数」へ指標を移すが、それは基盤の結果であり出発点にしない
• stale runbook を drift として扱う: 運用知識をグラフ化し、runbook が参照する構成の drift を observable event にする

People putty からの回収ポイント

関連技術・類似アプローチとの比較

以下は、一次ソースの主張を踏まえた筆者による整理です。各アプローチの特性を、4 体のカバレッジ・文脈統合・版管理・監査可能性・エージェント前提設計の観点で対比します。

ユースケース別推奨

構造

本方法論は具体的なプロダクトでなく方法論であるため、C4 モデルの各図は参照実装でなく、提案フレームワークの論理的な役割と責務の関係を示します。

システムコンテキスト図

中核システムは Agentic OS + Live Context Graph であり、4 つの真実の体を統合したコンテキスト基盤の上でエージェントが自律運用を実現します。

アクター

中核システム

外部システム (4 つの真実の体のソース)

コンテナ図

中核システムをドリルダウンし、2 層の構造を示します。下層の Live Context Graph substrate が 4 つの体を統合し、上層の Agentic OS runtime がその上で自律運用を実現します。

Live Context Graph substrate 層

Agentic OS runtime 層

3 つのエントリポイントの位置づけ

runtime 層の Reasoning Agent は、people putty が最も厚い 3 つのトリガーから起動されます。それぞれ substrate 層の特定の入力に対応します。

コンポーネント図

エージェントの意思決定ループをドリルダウンし、具体的な技術要素を含めた構造を示します。エージェントは Live Context Graph から読み取り、仮説を形成し、policy guardrails 内で bounded experiment を実行し、結果を書き戻します。

グラフからの読み取り

意思決定ループ

Policy Guardrails の実装

Bounded Experiment の実装例

データ

本セクションでは、Live Context Graph の構造と Agentic OS for Ops の意思決定機構を構成するエンティティを、概念モデルと情報モデルとして整理します。一次ソースに明示されていない属性は、隣接する実装 (Git、Terraform、OpenTelemetry、Neo4j) から推測したものとして注記します。

概念モデル

4 つの体 (CodeArtifact、InfraResource、RuntimeSignal、OperationalKnowledge) は LiveContextGraph に統合され、各エンティティは GraphNode として表現されます。KnowledgeGraph は 4 体を統合した静的な基盤で、Live Context Graph はそれを live・queryable・durable に拡張したものです。GraphSnapshot は Live Context Graph の特定バージョンを捕捉し、エージェントはその snapshot を参照して DecisionTrace を生成します。

なお、本文では概念名を「Live Context Graph」「decision trace」のように表記し、図と情報モデルではクラス名を LiveContextGraph DecisionTrace のように CamelCase で表記します。両者は同じ対象を指します。

関連の意味

情報モデル

各エンティティの主要属性を示します。型名は言語固有の表記を避け、list / map / set 等の汎用名を用います。

GraphSnapshot

DecisionTrace (信頼の要)

一次ソースで明示された 6 項目 (inputs / policies / model version / hypotheses / action / outcome) を必ず保持します。

InfraResource

RuntimeSignal

BoundedExperiment

エンティティ間の因果例 (edges の価値)

一次ソースでは「この commit がこの module を変え、この resource を provision し、この latency anomaly を出し、過去のこのインシデントに一致し、この fix で解決した」という因果連鎖が GraphEdge の価値として示されています。

補完と制約

本セクションで一次ソースに明示されない属性は、以下の隣接技術から推測しました。checksum / parent_snapshot_id は Git の commit SHA と親コミット参照、RuntimeSignal の anomaly_started_at は OpenTelemetry span と Prometheus alert 開始時刻、InfraResource の cloud_provider / region は Terraform provider 設定、BoundedExperiment の outcome はカナリアデプロイの結果記録、OperationalKnowledge の source_url は Confluence / Notion / Slack の URL スキーマから推測しています。

構築方法

本フレームワークは方法論であり参照実装を持たないため、以下は既存技術を用いた実装案です。一次ソースの主張そのものでなく、意図を反映した構成例として示します。想定するグラフストアは Neo4j です。

前提条件

• Git リポジトリ: コードの版管理が行われていること
• Terraform または同等の IaC ツール: インフラ状態が宣言的に管理されていること
• Observability 基盤: OpenTelemetry Collector / Prometheus による収集経路が稼働していること
• Knowledge store: Confluence / Notion / Slack または ADR の保管先が存在すること
• グラフデータベース: Neo4j 等のグラフストアがプロビジョニングされていること

Live Context Graph の構築は Artifacts → Knowledge Graph → Live Context Graph の順で段階的に進めます。

ステップ 1: 4 体からのデータ収集

Code

Git log の抽出と GitHub API 経由の commit / PR / branch 取得を行います。

git log --pretty=format:"%H|%an|%ae|%ad|%s" --date=iso > commits.csv

push イベントを契機に commit をグラフへ流す実装案です。

# .github/workflows/commit-to-graph.yml
name: Commit Graph Ingestion
on:
  push:
    branches:
      - main
jobs:
  ingest-commit:
    runs-on: ubuntu-latest
    steps:
      - name: Send to graph ingest endpoint
        run: |
          curl -X POST "${{ secrets.GRAPH_INGEST_ENDPOINT }}" \
            -H "Content-Type: application/json" \
            -d '{
              "sha": "${{ github.sha }}",
              "author": "${{ github.event.head_commit.author.name }}",
              "message": "${{ github.event.head_commit.message }}",
              "timestamp": "${{ github.event.head_commit.timestamp }}"
            }'

(補完元: GitHub Actions のイベントと workflow)

Infrastructure State

Terraform state の JSON 出力と drift 検出を行います。

terraform show -json > tfstate.json
terraform plan -refresh-only
driftctl scan --output json://drift.json

driftctl の --output は <format>://<destination> 形式で、上記はファイル出力です。ただし driftctl は現在 maintenance mode で、最新リリースは 2023 年で止まっています。新規採用では、terraform plan -detailed-exitcode による差分検知や、クラウドネイティブな drift 検出手段への差し替えも検討します。

(補完元: Terraform CLI の plan コマンド、driftctl)

Runtime Signals

OpenTelemetry Collector で traces / metrics / logs を統合収集し、Prometheus で metrics を scrape します。

# otel-collector-config.yaml
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
  prometheus:
    config:
      scrape_configs:
        - job_name: "app-metrics"
          static_configs:
            - targets: ["app:8080"]
processors:
  batch: {}
  memory_limiter:
    check_interval: 1s
    limit_mib: 512
exporters:
  otlp:
    endpoint: observability-backend:4317
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]
    metrics:
      receivers: [otlp, prometheus]
      processors: [memory_limiter, batch]
      exporters: [otlp]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]

(補完元: OpenTelemetry Collector Configuration)

Operational Knowledge

Confluence / Notion の export API で runbook / post-mortem / ADR を取得し、Slack export で重要スレッドを抽出し、Markdown または JSON に統一して知識グラフへ流します。

# ingest_confluence.py (実装案)
import requests

confluence_url = "https://your-instance.atlassian.net/wiki"
auth = ("user@example.com", "api_token")
resp = requests.get(
    f"{confluence_url}/rest/api/content",
    params={"spaceKey": "OPS", "type": "page", "expand": "body.storage"},
    auth=auth,
)
for page in resp.json()["results"]:
    knowledge = {
        "knowledge_id": page["id"],
        "knowledge_type": "runbook",
        "title": page["title"],
        "content": page["body"]["storage"]["value"],
        "source_url": f"{confluence_url}{page['_links']['webui']}",
    }
    # knowledge を Neo4j の OperationalKnowledge ノードとして MERGE する

(補完元: Atlassian Confluence REST API)

ステップ 2: グラフストアへの ingest

収集したデータを Neo4j に投入します。ノードタイプの例は Commit / Module / Resource / Span / Incident / Runbook / ADR、エッジタイプの例は CHANGES (Commit から Module)、PROVISIONS (Module から Resource)、EMITS (Resource から Span)、MATCHES (Span から Incident)、RESOLVED_BY (Incident から Runbook) です。

# ingest_commits.py
from neo4j import GraphDatabase

driver = GraphDatabase.driver("neo4j://localhost:7687", auth=("neo4j", "your_password"))
commits = [
    {"sha": "abc123", "author": "Alice", "message": "Fix latency", "timestamp": "2026-07-01T10:00:00Z"},
]
cypher = """
UNWIND $commits AS commit
MERGE (c:Commit {sha: commit.sha})
SET c.author = commit.author,
    c.message = commit.message,
    c.timestamp = datetime(commit.timestamp)
"""
with driver.session() as session:
    session.run(cypher, commits=commits)
driver.close()

(補完元: Neo4j Python Driver)

ステップ 3: edges の構築

各体の間の関連を明示的に結びます。

# link_commit_to_module.py
cypher = """
MATCH (c:Commit {sha: $sha})
MATCH (m:Module {name: $module_name})
MERGE (c)-[:CHANGES]->(m)
"""
with driver.session() as session:
    session.run(cypher, sha="abc123", module_name="vpc-module")

# link_span_to_incident.py
cypher = """
MATCH (s:Span {span_id: $span_id})
MATCH (i:Incident {id: $incident_id})
MERGE (s)-[:MATCHES]->(i)
"""
with driver.session() as session:
    session.run(cypher, span_id="span456", incident_id="inc-2022-03-15")

entity resolution と OpenTelemetry semantic conventions

edges の構築で最大のコストは、4 体のデータを一貫した entity (service / resource / deployment) に紐づける entity resolution です。OpenTelemetry の semantic conventions は service.name / service.version / deployment.environment.name / k8s.pod.uid などの標準属性を定義し、traces / metrics / logs 間の entity 統一を支援します。

• service.name と service.version を commit の module 名・version にマッチング
• k8s.pod.uid を InfraResource の pod ID にマッチング
• deployment.environment.name を policy guardrail の environment 判定に利用

標準属性に寄せることで、異なる体のノードを高い精度で結びつけられます。(補完元: OpenTelemetry Semantic Conventions)

ステップ 4: 版管理とスナップショット化

各エージェント決定が、どの時点のグラフに対して下されたかを再現できるよう、グラフの状態をスナップショットとして保存します。

# snapshot_graph.py
import datetime
snapshot_id = f"snapshot-{datetime.datetime.utcnow().isoformat()}"
cypher = "CREATE (s:Snapshot {id: $snapshot_id, timestamp: datetime()})"
with driver.session() as session:
    session.run(cypher, snapshot_id=snapshot_id)

(補完元: Event Sourcing / immutable log パターン)

利用方法

Live Context Graph 構築後、エージェントや人間がグラフをクエリし、decision trace を記録し、policy guardrail を適用する方法を示します。

必須パラメータと前提

グラフのクエリ例

特定 commit に起因する latency anomaly と過去 incident を辿ります。

MATCH (c:Commit {sha: $commit_sha})
      -[:CHANGES]->(m:Module)
      -[:PROVISIONS]->(r:Resource)
      -[:EMITS]->(s:Span)
      -[:MATCHES]->(i:Incident)
WHERE s.latency > $threshold
RETURN c.sha, c.author, c.message, m.name, r.id, s.trace_id, s.latency, i.id, i.resolution

現在 drift を持つリソースとその過去の修復履歴を辿ります。

MATCH (r:Resource)
WHERE r.drift = true
OPTIONAL MATCH (r)-[:RESOLVED_BY]->(rb:Runbook)
RETURN r.id, r.type, r.drift_details, rb.title, rb.procedure

decision trace の記録形式

各エージェント決定を durable に記録する形式の実装案です。一次ソースの 6 項目を含めます。

{
  "trace_id": "decision-2026-07-07T08:30:00Z",
  "timestamp": "2026-07-07T08:30:00Z",
  "snapshot_id": "snapshot-2026-07-07T08:29:50Z",
  "agent_id": "agent-slo-responder-v3",
  "model_version": "gpt-5.5",
  "policies_in_effect": ["policy-blast-radius-limit", "policy-require-approval-for-scale"],
  "inputs": {
    "slo_breach": {"slo_name": "api-p99-latency", "current_value": 3.2, "threshold": 2.0, "breach_start": "2026-07-07T08:25:00Z"},
    "recent_changes": [{"commit_sha": "abc123", "author": "Alice", "message": "Increase connection pool size", "timestamp": "2026-07-07T08:20:00Z"}]
  },
  "hypotheses": [
    {"hypothesis": "Connection pool config change caused latency spike", "confidence": 0.85, "status": "considered"},
    {"hypothesis": "Database replica lag increased", "confidence": 0.45, "status": "rejected"}
  ],
  "action_taken": {"type": "canary_rollback", "target": "api-service-v2", "blast_radius_percent": 10, "approved_by": "auto"},
  "outcome": {"latency_post_action": 2.1, "slo_recovered": true, "recovery_time_seconds": 45}
}

policy guardrail の記述例

エージェントが本番環境で取る行動には blast-radius limit / approval requirement / allowed actions の制約が必要です。OPA Rego の現行構文 (v1) を用います。

# blast-radius-limit.rego
package guardrails

import rego.v1

default allow := false

allow if {
    input.action.blast_radius_percent <= 20
    input.action.type in ["canary_rollback", "throttle", "scale_out"]
}

破壊的操作は environment を問わず human approval を必須にします。非破壊的な action はそのまま許可します。

# require-approval.rego
package guardrails

import rego.v1

default allow := false

destructive_actions := {"terminate_instance", "delete_database", "rollback_major_version"}

# 非破壊的な action は許可する
allow if {
    not input.action.type in destructive_actions
}

# 破壊的な action は environment を問わず human approval を必須にする
allow if {
    input.action.type in destructive_actions
    input.approval.human_approved == true
}

(補完元: Open Policy Agent の Rego)

write-back loop の実装

エージェントの実験結果を graph に書き戻し、hypothesis の状態を更新します。この書き戻しが次ループの推論を改善します。

# writeback_result.py (実装案)
cypher = """
MATCH (e:BoundedExperiment {experiment_id: $experiment_id})
SET e.outcome = $outcome, e.completed_at = datetime()
WITH e
MATCH (h:Hypothesis {hypothesis_id: $hypothesis_id})
MERGE (e)-[:VALIDATED]->(h)
SET h.status = 'confirmed'
"""
with driver.session() as session:
    session.run(cypher, experiment_id="exp-2026-07-07", outcome="success", hypothesis_id="hyp-conn-pool")

運用

グラフの鮮度 (liveness) の運用

Live Context Graph の中核前提は「stale context は no context より悪い」です。運用では、グラフ自身を first-class な telemetry source として監視し、グラフが live でなくなったことを検知します。

• 鮮度 SLI の定義: 4 体それぞれの ingestion 遅延を計測します。最新 commit 反映までの遅延、terraform state 反映までの遅延、trace ingestion 遅延、runbook 更新反映遅延を個別に持ちます
• 鮮度 SLO とアラート: ingestion 遅延がしきい値を超えたら、グラフを参照するエージェントの自律実行を停止し、human-in-the-loop に降格します

グラフ自身を Prometheus metrics として export する実装案です。

# graph_exporter.py (実装案)
from prometheus_client import Gauge, start_http_server
from neo4j import GraphDatabase
from datetime import datetime, timezone
import time

graph_ingestion_lag = Gauge("graph_ingestion_lag_seconds", "Lag per body type", ["body_type"])
driver = GraphDatabase.driver("neo4j://localhost:7687", auth=("neo4j", "password"))

def collect_metrics():
    with driver.session() as session:
        record = session.run("MATCH (c:Commit) RETURN max(c.timestamp) AS latest").single()
        if record and record["latest"]:
            lag = (datetime.now(timezone.utc) - record["latest"].to_native()).total_seconds()
            graph_ingestion_lag.labels(body_type="code").set(lag)

if __name__ == "__main__":
    start_http_server(8000)
    while True:
        collect_metrics()
        time.sleep(60)

snapshot と版管理の運用

一次ソースは「すべてのエージェント決定は特定バージョンのグラフに対して下される」ため replay 可能である必要があると述べます。

• 保持ポリシー: 監査対象の decision trace が参照する snapshot は、監査要件の保持期間に合わせて保持します。参照されない中間 snapshot は圧縮または間引きます
• replay の運用: 監査や事後検証の際、当該 trace の snapshot_id を指定してグラフ状態を復元し、同じ入力に対する再評価を行います
• ストレージ設計: フルコピーでなく親 snapshot からの差分で保持し、グラフ全体の肥大を抑えます

エージェントループの運用

• blast-radius 制限: bounded experiment の影響範囲を policy で束縛し、逸脱時は即時ロールバックします
• human-in-the-loop 承認: 破壊的 action や policy 範囲外の action は人間承認を必須にします。承認の遅延そのものを計測します
• compounding の監視: hypothesis 的中率や recovery time の推移を継続計測します。改善が頭打ちなら、過去 incident の学習不足を疑います

decision trace の運用

• 完全性の担保: action を取ったのに trace が欠落している状態を検知するため、action イベントと trace イベントの件数を突き合わせます
• 監査提出: CISO / risk officer / regulator の要求に対し、対象期間の trace を snapshot 参照付きで抽出します
• プライバシー: trace の inputs に含まれる機微情報はマスキングまたは参照化し、監査可能性と両立させます

3 つのエントリポイントごとの運用

ベストプラクティス

• graph-before-agents を守る: エージェント導入より先に、4 体を統合した Live Context Graph を作ります。断片化された文脈の上で動かすと plausible hallucination を生みます
• エージェントを path に埋め込む: 事後の post-mortem 自動化は dictation です。継続ループでインシデントをそもそも稀にします
• decision trace を最初から baked-in にする: auditable / reproducible / trustworthy を後付けでなく最初の設計に含めます。監査要求が来てから trace を足すのでは、初回の interesting な action を説明できません
• stale runbook を放置しない: 運用知識をグラフ化し、runbook が参照する構成の drift を observable event として扱い、drift 発生時に該当 runbook を要更新として flag します
• metrics の見方を移す (ただし consequence として): MTTR から「悪い夜を避けた回数」へ移しますが、これは基盤の結果であり出発点にしません
• 段階的成熟 (copilot から autopilot へ): 一気に full autonomy を狙わず、trace の蓄積と hypothesis 的中率が積み上がった領域から自律度を上げます

反証・限界

一次ソースは thought leadership であり、実装コストや運用負荷の定量評価を伴いません。過信を避けるため、隣接領域の知見から限界を明示します。

トラブルシューティング

まとめ

自律運用の壁はモデル性能でなく、Code・Infra State・Runtime Signals・Operational Knowledge の4体をまたぐ文脈の欠落にあります。先に版管理された Live Context Graph を作り、各エージェント決定に decision trace を残す。この順序が、監査可能な自律運用への現実的な道筋になります。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

参考リンク

一次ソース

• The 4-Body Problem of SRE: Why Autonomous Operations Depend on Context (CNCF Blog, 2026-07-06)
• The 4-Body Problem of SRE: Building an Agentic OS for Autonomous Operations (StackGen Blog)

系譜 (SRE / observability / IaC)

• Google SRE Book: Service Level Objectives
• OpenTelemetry Collector Configuration
• OpenTelemetry Semantic Conventions
• Prometheus Configuration
• Terraform CLI: plan command

関連ツール

• driftctl: Detect and track infrastructure drift (GitHub)
• Neo4j Python Driver
• Neo4j Cypher Manual
• Open Policy Agent: Policy Language (Rego)

補完元 (実装案の参照)

• GitHub Actions: Events that trigger workflows
• Atlassian Confluence Cloud REST API
• Event Sourcing Pattern (Martin Fowler)