インフラには冗長性だけでなく監査可能性が必要

Infrastructure auditability is not a property your pipeline inherits from idempotency — it's a separate architectural requirement that most IaC implementations have never addressed. The field spent a decade optimizing for deterministic execution. That work is largely done. The gap now is not whether your infrastructure runs consistently. It's whether you can prove, after the fact, that what executed was authorized, reviewed under the correct policy, and consistent with what was actually approved. Those are different problems. Most teams treat them as the same one. What Idempotency Actually Guarantees Idempotency is an execution property. It guarantees that running the same operation multiple times produces the same outcome. In modern infrastructure & IaC architecture, idempotency is foundational — Terraform, Ansible, Kubernetes manifests, and GitOps pipelines all depend on it. Apply the same configuration twice: same result. That guarantee is real and valuable. What idempotency does not guarantee: that the change was authorized. That the person or system that triggered the run had current approval. That the policy state active at execution time matched the policy state in effect when the change was reviewed. That the plan artifact applied was the same one that was signed off. That anyone could reconstruct the authorization chain a month later without access to the live system. Idempotency describes the relationship between input and output. It says nothing about the legitimacy of the input itself. Why Teams Mistake Idempotency for Auditability The confusion is understandable because IaC pipelines produce visible feedback that feels like proof. The plan succeeded. The apply succeeded. The state file matches the desired configuration. The CI/CD run is green. Drift detection shows no variance. Everything looks clean. None of those facts answer the questions an auditor, a post-incident review, or a security team will actually ask: Who authorized this change? What policy was active when it was approved? Was the executed plan the same artifact that was reviewed? Did anything change in the environment between approval and execution that would have altered the decision? Infrastructure teams that have built intent-driven systems know this distinction well — a system can faithfully execute what it was told while the original intent has long since drifted from the current operational context. The state machine is correct. The authorization trail is gone. The pipeline being green is not evidence of legitimate execution. It's evidence of successful execution. Those are not the same thing. The Auditability Gap in Modern IaC Pipelines Infrastructure auditability requires four things that most IaC pipelines do not produce: Change provenance — who triggered the change, from what state, at what point in the approval chain Intent capture — the approved intent at review time, preserved as an artifact, not just a Git commit Policy state at execution — what constraints were active when the apply ran, not when the plan was generated Execution evidence — a record that links the applied plan to the authorization event and survives beyond the pipeline run Logs are not a substitute for any of these. Configuration drift detection catches variance after the fact. IaC drift detection tooling tells you when state diverges from desired configuration. None of those tell you whether the desired configuration was legitimately authorized at the time it was applied. The auditability gap is structural. It exists because IaC was designed to solve execution consistency, not authorization traceability. Why the Gap Widens in GitOps Environments GitOps accelerated the auditability problem by decoupling human approval from execution in a way that feels rigorous but isn't. The standard GitOps model treats a pull request merge as the authorization event. That framing is directionally correct — the PR captures intent, the merge signals approval, the pipeline executes. But a pull request captures intent at review time. The infrastructure executes later, under a potentially different policy state, against a potentially different environment, using a potentially different plan artifact. Policy drift in GitOps pipelines is a documented failure pattern. A policy exception added and then removed. An environment variable changed after the plan was generated. A module version pinned in the PR but resolved differently at apply time. The execution diverges from the reviewed intent — not because anyone made a mistake, but because the system has no mechanism to detect or record the divergence as an authorization failure. Consider the sequence: a Terraform change opens a security group. The plan is generated and reviewed Tuesday. The apply runs Thursday. Between those events, a policy exception governing that specific security group class is removed from the enforcement pipeline. The apply succeeds. Six weeks later, a security review asks: Who authorized this change? What policy was active at execution time? Was the applied configuration consistent with the reviewed plan? The pipeline logs are gone past the retention window. The state file exists. The Git history has the PR and the merge commit. Nobody can answer the second question. Nobody can prove the answer to the third. That is the Infrastructure Evidence Gap — and it is reproducible in any environment where plan generation and plan execution are temporally separated. What Infrastructure Auditability Requires Auditability is not a log retention problem. It's a chain-of-custody problem. Solving it requires treating each infrastructure change as an evidence artifact that must survive outside the systems that produced it. The evidence doctrine that applies to AI execution proof applies here with equal force — the question is not whether your system recorded what happened, but whether that record constitutes defensible proof to a party that has no access to the live system. Framework #151 — Infrastructure Evidence Gap defines the chain: 01 — APPROVED INTENT The human-readable change description as reviewed and approved — captured as a signed artifact, not just a Git commit hash. What the approver believed they were authorizing. 02 — AUTHORIZATION EVENT The explicit approval record — who authorized, at what time, under what role or policy scope. Not a PR merge timestamp. A discrete authorization artifact linked to an identity. 03 — SIGNED PLAN ARTIFACT The exact plan that will execute — signed at generation time, verified at apply time. If the plan at apply time does not match the signed artifact, execution should not proceed. 04 — POLICY STATE SNAPSHOT The active policy constraints at execution time — captured as an immutable snapshot, not derived retroactively from current policy state. This is the record that closes the Tuesday-to-Thursday gap. 05 — EXECUTION RECORD A tamper-evident record linking the actual execution to the signed plan artifact, the authorization event, and the policy state snapshot. The execution record is what proves all four upstream elements were honored. 06 — EVIDENCE ARTIFACT The portable, externally-readable package of the above five elements — readable by a third party without access to the live pipeline, CI/CD system, or Git provider. The evidence artifact is the unit of auditability. Everything else is scaffolding. The Audit Trail Is a Control Plane Requirement Infrastructure audit trails are not a compliance deliverable. They are operational infrastructure. Postmortem analysis requires change provenance — not just what state the system is in now, but what changed, when, under what authorization. Blast radius analysis after an incident depends on being able to reconstruct which changes were active in the affected environment at the time of failure. Security reviews require evidence that changes were authorized under current policy, not just that they executed successfully. None of those use cases are served by pipeline logs alone. IaC governance tooling treats governance as an architectural requirement for exactly this reason — policy enforcement, drift detection, and ownership boundaries are the upstream conditions that make evidence artifacts meaningful. Without them, you are logging executions you cannot defend. Diagnostic: "If your Git provider, Terraform backend, and CI/CD platform disappeared tomorrow, could you still prove who approved your last production infrastructure change, what policy state governed it, and what actually executed?" For most teams the honest answer is: the Git history survives because it's replicated, the Terraform state file survives if it's in remote backend, and everything else — the authorization event, the plan artifact at apply time, the active policy snapshot — exists nowhere that doesn't depend on the live system. That is not an audit trail. It is a state record. The distinction matters the moment someone asks you to prove the state was reached legitimately. Architect's Verdict Idempotency solves the wrong problem for auditability. It guarantees that your infrastructure can be reproduced. It does not guarantee that anyone can reconstruct why it was changed, who authorized it, or what policy governed the execution. A system that runs correctly and reproducibly can still be impossible to audit — and in regulated environments, in post-incident reviews, and in security investigations, that gap becomes a liability. The Infrastructure Evidence Gap (#151) is not a tooling shortfall. No amount of better logging closes it. It is an architectural shortfall — the evidence layer was never designed into the pipeline because the pipeline was designed for execution, not for defensibility. The six-step chain from approved intent to portable evidence artifact requires deliberate architecture decisions that most IaC implementations have never made. Infrastructure teams spent the last decade making change deterministic. The next decade will be spent making change defens