本番環境の真実をコンパイラ入力に：フェニックス・アーキテクチャ

Production used to be the place where software went to fail. Observability made it the place where software becomes legible.But it left one loop open.We use production telemetry to debug incidents, explain behavior, gate rollouts, and decide whether to roll back. We use it to help humans understand reality. Then a person decides what the code change should be.Instead, production truth becomes an input to what the system generates next. The key idea is simple: the primary failure mode is not always code breakage. It is evidence decay.A component can satisfy the spec today and fail it three months from now even if nobody touches the code.Traffic shape changes. Data distribution shifts. Dependencies slow down. Fallback paths activate more often. Cost envelopes move. Latency ceilings stop holding.The implementation may be unchanged. The world is what changed.That is technical drift: when production evidence no longer supports the claim that an implementation satisfies the operational or business constraints attached to its spec.Not that a service got slower but that the implementation no longer satisfies the latency and cost envelope the requirement promised.Not that a dashboard got worse but that the evidence that justified this module is no longer valid.Once you see that, the role of observability changes.Charity Majors and others have been pushing toward this for years: production as the place where we learn the truth, observability as the ability to ask new questions of live systems, and production as the place where intent has to be validated against reality instead of against our hopes. See “You Had One Job,” “Observability: A Manifesto,” “Honeycomb 10 Year Manifesto: Observability in a World of AI,” and “Your Data is Made Powerful By Context.”Production truth should not stop at helping humans reason about software. It should participate directly in creating the next version.In The Phoenix Architecture, production telemetry becomes evidence inside the software creation process itself. It is attached to requirements. It has provenance. It can age. It can drift. And when it drifts, it can invalidate specific parts of the system instead of merely informing a human that something seems off.A module is not good because it once passed tests. It is good only as long as the evidence still supports the claim that it satisfies the requirement.The interesting question is no longer just “What is wrong with the system?”. How about, “Which claims about the system are no longer true?”That is a much sharper question. It also points to a different architecture.The first important layer is the spec layer. In Phoenix, requirements are not just behavioral. They include operational and business constraints: latency ceilings, cost envelopes, reliability targets, quality thresholds, tenant-specific promises. Those constraints are part of the requirement, not implementation detail discovered later.The second important layer is the canonicalization layer. Raw production signals are not enough. They have to be turned into stable evidence statements attached to those requirements. Not screenshots. Not dashboards. Not anecdotes from last week’s incident review. Structured claims: a p95 latency measurement for enterprise traffic at peak, a cost-per-request ratio that has blown past budget, a fallback activation rate that has doubled past its threshold.This is why context matters so much. If you throw away relationships too early, aggregate too aggressively, or preserve only the questions you already thought to ask, you don’t have evidence. You have artifacts of somebody else’s curiosity.The third important layer is the implementation graph. Once requirements are connected to modules, services, queries, prompts, dependencies, and contracts, drift can be localized. You no longer have to say “the app is degrading.” You can say: this requirement is drifting, these modules are implicated, and these claims are now stale.That leads to the most important architectural move: selective invalidation.When production evidence drifts out of bounds, Phoenix should not just open a ticket or wake up an engineer to start hunting through code. It should invalidate the affected subgraph and the specific evidence claims that no longer hold.Not the whole system.Only the part whose justification has expired.That is what makes regeneration tractable. Without that step, “production should feed software creation” collapses into a vague fantasy about AI reading logs. With it, you get a bounded, governed process.Canonicalized evidence identifies which requirement is failing, and the implementation graph localizes the affected modules. The invalidation system marks only that subgraph as stale. Then regeneration has a concrete job.Now the question becomes:What should be regenerated because of what production just taught us?Maybe a query planner needs to be rewritten for the actual workload it now sees. Maybe a cache strategy needs to be redesigned because the hit-rate assumptions no longer hold. Maybe a component needs to optimize for tail latency rather than mean latency because that is what the requirement actually cares about in production.That is not observability as a dashboard. It is observability as an input to software creation.Compiler input means exactly that.Compilers do not just transform source. They operate under constraints. They take targets, assumptions, and optimization goals. Phoenix extends that idea upward. Production truth becomes one of the things the system compiles with.Not because production is magical, but because production is where the promises in the spec are forced to meet reality.The first generation of observability helped us detect failure.The second helped us understand complex behavior in running systems.The next step is to let production truth participate directly in software creation.If production is where the truth is, why isn’t production truth a first-class input to the build?

※ 著作権に配慮し、引用は冒頭3段落までです。続きは元記事をご覧ください。