使っていたLLMモデルが廃止され、生成機能が止まった — 2つのプロダクトの原因と再発防止A hands-on postmortem describing how Google's deprecation of Gemini 2.5…

On the morning of July 10, 2026, the design generation feature of promptflow, a multi-LLM workflow SaaS, stopped working entirely. According to the developer's own account, the failure did not originate in the product's code. Instead, Google had deprecated a Gemini 2.5 model that the service depended on, and two separate products lost their generation capabilities as a result. The postmortem is notable because it documents a class of failure that is becoming more common as software increasingly depends on third-party model endpoints that vendors can retire on their own schedule.

The author, Masakichi Uehara of EarthLink Network Co., Ltd., frames the write-up as a field report from real operations rather than a theoretical exercise. He describes using Claude Code as the primary engine of his development workflow while building and running more than twenty products single-handedly. That context matters: when one person maintains a large portfolio, an upstream change that silently disables a shared dependency can cascade across multiple services before it is noticed. In this case, the outage manifested as generation features that simply produced nothing, which is a harder symptom to catch than a loud crash.

The immediate technical cause was the removal of a specific Gemini 2.5 model identifier from Google's API. When a provider deprecates a model, requests that reference the retired identifier typically begin to fail, and any product hard-coded to that exact model can break without warning. The account emphasizes that the trigger was external, but it also treats the incident as an opportunity to examine why the systems were vulnerable in the first place. In other words, the deprecation exposed a design assumption that a particular model would remain available, and the postmortem focuses on removing that assumption rather than assigning blame to the vendor.

Model deprecation is a recognized part of the large language model lifecycle. Providers including Google, OpenAI, and Anthropic periodically retire older model versions as they ship newer ones, and they generally publish deprecation timelines and migration guidance. Even so, transitions can catch teams off guard, especially when applications pin themselves to a precise model string. A common distinction here is between pinned version identifiers, which point to a fixed snapshot that can eventually be sunset, and rolling aliases that automatically track a provider's latest recommended model. Each approach carries trade-offs: pinned versions offer output stability but require active migration, while aliases reduce maintenance but can shift behavior underneath an application without notice.

The architectural response outlined in the postmortem appears to center on making the products resilient to model changes rather than merely swapping in a replacement model. Typical mitigations for this kind of failure include routing requests through an abstraction layer so that a single model reference is not scattered across the codebase, configuring fallback models so that a failed call to one provider can retry against another, and adding health checks or monitoring that flag when generation output drops to zero. Because promptflow is described as a multi-LLM workflow platform, it is well positioned to lean on provider diversity, treating any single model as replaceable rather than foundational.

The broader industry context reinforces why this matters. Tools such as provider-abstraction libraries and model-routing gateways have grown popular precisely because they let developers switch between vendors and versions with configuration changes rather than code rewrites. LiteLLM, OpenRouter, and similar layers are frequently cited as ways to insulate applications from any one provider's roadmap. For solo developers and small teams operating many products, this kind of indirection is likely to become a prerequisite rather than an optimization, since manual, per-product migrations do not scale as the number of dependencies grows.

The lasting value of the report is its emphasis on prevention. It documents not only what failed and why, but also the concrete changes intended to keep a future deprecation from silently disabling core features again. The lesson generalizes beyond Gemini or any single vendor: applications that call external models should assume those models will eventually be retired, and should be built so that a deprecation becomes a configuration update instead of an outage. As reliance on hosted LLM APIs deepens, treating model availability as a variable rather than a constant looks increasingly like standard operational hygiene.