Cloud Run × MCP のホスト先がこの 1 年で 3 回変わったので整理してみた Cloud Run × MCP のホスト先がこの 1 年で 3 回変わったので整理してみた

The Model Context Protocol (MCP) has quickly become one of the most discussed standards for connecting AI assistants to external tools and data, and running MCP servers on managed infrastructure such as Google Cloud Run is an increasingly common pattern. This article, published as the seventh entry in KDDI iret's "Google Cloud Next '26 / Google I/O hands-on blog relay" running from June 22 to July 3, looks back at how the recommended way to host an MCP server on Cloud Run has shifted roughly three times over the past year and tries to make sense of that churn.

The reason this matters is practical. MCP, originally published by Anthropic in late 2024, defines how a client such as an AI agent discovers and calls tools, reads resources, and exchanges prompts with a server. Early implementations were designed mainly for local use, communicating over standard input and output (stdio), which works well when the server runs on the same machine as the client. Hosting a server remotely, however, requires a network transport, and that is where Cloud Run enters the picture: it offers a serverless way to run a container, scale it to zero, and expose it behind an HTTPS endpoint without managing servers directly.

The first phase of remote hosting relied on the HTTP-plus-Server-Sent-Events (SSE) transport defined in the original specification. In this model the client opened a long-lived SSE connection to receive messages from the server while sending requests over separate HTTP POST calls. On Cloud Run this approach was workable but awkward, because long-lived streaming connections interact with request timeouts, instance concurrency, and the platform's autoscaling behavior in ways that are easy to misconfigure.

The second phase arrived when the MCP specification introduced the Streamable HTTP transport in 2025, intended to replace the older SSE approach. Streamable HTTP consolidates communication onto a single endpoint and allows responses to be returned either as ordinary HTTP responses or as streams when needed. This maps more naturally onto Cloud Run's request-response model and reduces the need to keep idle connections open, although stateful sessions still require care because Cloud Run may route subsequent requests to different instances unless session affinity is configured.

The third phase appears to reflect refinements rather than a wholesale reinvention, centering on authentication, session handling, and how Cloud Run itself has added capabilities aimed at agent and MCP workloads. Securing a publicly reachable MCP endpoint typically involves identity-aware access, OAuth-based authorization, or fronting the service with Google Cloud's IAM and Identity-Aware Proxy. The broader point the article seems to make is that anyone who built an MCP server on Cloud Run a year ago has likely had to revisit transport choices, connection handling, and security at least twice since.

For readers approaching this for the first time, a few prerequisite concepts help. Cloud Run distinguishes between request-based and instance-based behavior, and settings such as concurrency, minimum instances, and session affinity directly affect whether a streaming or stateful MCP server behaves correctly. It is also worth knowing the surrounding ecosystem: Anthropic, OpenAI, and Google have all moved toward agent tooling, with frameworks and SDKs that can consume MCP servers, and Google has promoted complementary efforts such as the Agent2Agent (A2A) protocol and its Agent Development Kit. These adjacent moves help explain why MCP hosting guidance has changed so often; the standard and the platforms beneath it are evolving in parallel.

The takeaway is less about a single correct configuration and more about the pace of change. Because the specification, the client implementations, and Cloud Run's own capabilities are all maturing at the same time, the "right" way to host an MCP server is a moving target. Teams adopting this pattern would be wise to isolate the transport layer in their code, document which specification version they target, and revisit their deployment when the next revision lands, which, given the past year, seems likely to happen again before long.