A2A + MCP — 2026 年 Google Cloud NEXT で本当のストーリーを告げた 2 つのプロトコル

Google Cloud NEXT 書き込みチャレンジへの投稿です。 こんにちは、Saquib です。過去数年、主に Node と Go のマイクロサービス構築に深く取り組み続けてきました。2026 年の開発者と同じく、私は過去数ヶ月間 AI を試行錯誤しました。LLM を API に接続し、バグを作り、直す。最初のアプロードが機能した直後に何か著しく間違っていると思い込む。 Google Cloud NEXT '26 が開幕すると、私はカレンダーに時間を確保して観戦しました。私のフィードには Gemini エンタープライズエージェントプラットフォームと新しい 8 世代 TPUs に関する熱い意見が溢れかかっていました。また、「Google のコードの 75％は AI によって生成された」という統計についても誰も大きな意見を持っていたようです。 しかし正直に言うと、私は 2 つの退屈な略語に引き込まれていました。 A2A と MCP。 彼らは舞台時間をほとんど得られませんでした。ハイプリールもないのに。しかし私は本当におそらくこのイベントで最も重要なことが発表されたのだと思います。なぜそう思うのかを説明させてください。 ステージにいるどのベンダーもエージェントを見せつけていました。Salesforce は Agentforce。ServiceNow も SAP も、Microsoft Copilot がもちろん、Google の Gemini エンタープライズ。基本的にみんな今エージェントを出荷中です。それはいいことです。 しかし私が何度も思い出されるのは、もっと派手ではない質問でした。どのエージェントも実際にはどのように互いに通信できるのでしょうか？ 通常のバックエンドのセットアップでは、2 つのマイクロサービスが会話する必要があるとき、私たちはプレイブックを持っています。REST、gRPC、Kafka クォータ、OpenAPI 仕様が。その全体の混乱は解決されています。それは退屈ですが機能します。 しかしエージェントの場合？一年前、答えは彼らはただしなかったことです。あるいは、さらに悪いことに、誰かが 2 時の Slack DM からベビシッターをしなければならないような恐ろしいカスタム Webhook アダプターを通じて行いました。各システムが独自の言語を話し、統合は機能ではありませんでした—それは誰かの全仕事でした。 A2A と MCP はそのまさにその問題を解決します。Google は最後にこれらを研究実験としてではなく、実際のインフラとして扱うことを始めました。 私は何回もドキュメントを読まなければ理解できませんでした。ここでは、初日から持っておいてほしい概要です。 MCP はエージェントのための HTTP です。A2A はエージェント同士が話せるための DNS plus HTTP です。 MCP（モデルコンテキストプロトコル）は元々 Anthropic の子供でした。それはモデルがツールやデータベースにアプローチする方法を標準化します。MCP 以前に、Gemini がデータベースを照会したければ、あなたは多数のグルーコードを書き、モデルがテーブル名を発明しないことを願わなければなりませんでした。今、モデルは MCP を話し、サーバーは MCP を話し、彼らはただ手を差し合います。 A2A（エージェント 2 エージェント）は Google から生まれ、Linux Foundation にも寄贈されました。それは 1 つのエージェントが別の自律的エージェントと話す方法を標準化します。 A2A ドキュメントはそれらを最良に述べています：どのフレームワークでも構いませんが、MCP を装備し、A2A で通信してください。それらは競争する基準ではありません。MCP はあなたのエージェントがデータベースに語りかける方法です。A2A はそれが他のエージェントに横向きに話する方法です。その気づきは私に大きな頭痛を救いました。 この多くは NEXT 以前から溢れ出ましたが、カンファレンスではそれを実際の実施にまとめるためにすべてをまとめています。 MCP の側面では、BigQuery、Cloud SQL、Pub/Sub のために完全に管理されたサーバーを得ました。何もデプロイしなくたっていいです。あなたはエージェントをエンドポイントに指しただけです。彼らはまた Apigee を MCP ブリッジに変換しました。これはあなたがすでに構築したあらゆる REST API があなたの既存の認証の層を上に持っているまま発見可能なエージェントツールになることを意味します。一年間 API を LLM ために手書きでラップした人が男性であるとして、それは大きな解放でした。認証は今すべて IAM によってバックアップされていますので、API キーを回送する必要はありません。 A2A の側面では、LangGraph と CrewAI サポートでプロダクショングレードに命中しました。Linux Foundation への寄贈は大きな動きでした。彼らはまたエージェントレジストリ（あなたのエージェントのインターネットのための基本的な DNS）とエージェントゲイウェイを発表しました。 すべてをまとめると、Google はエージェント自体を所有する必要があるとは言い切らないでしょう。彼らはエージェントが走行する高速道路を所有したいだけです。 私はアーキテクチャ図を嫌いです。実際の実施を見たいです。それで、ここには本当に最小限のセットアップがあります：プランナーエージェントが analyzi

This is a submission for the Google Cloud NEXT Writing Challenge Hey, I'm Saquib. I've been deep in the backend trenches for a couple of years now, mostly building out Node and Go microservices. Like pretty much every dev in 2026, I spent the last few months messing around with AI. Wiring LLMs into APIs. Breaking stuff. Fixing it. Getting a prototype working on the first try and immediately assuming something is horribly wrong. When Google Cloud NEXT '26 kicked off, I actually blocked out some calendar time to watch. My feed was absolutely flooded with hot takes on the Gemini Enterprise Agent Platform and the new 8th-gen TPUs. Everyone also had a very loud opinion about that "75% of Google's code is AI-generated" stat. But honestly? I kept getting distracted by two boring acronyms. A2A and MCP. They barely got any stage time. No hype reel. But I genuinely think they were the most important things announced at the whole event. Let me try to explain why. Every vendor on stage was showing off agents. Salesforce has Agentforce. ServiceNow's got one. SAP too. Microsoft Copilot, obviously. Google's Gemini Enterprise. Basically everyone is shipping agents right now. Which is fine. But the question I kept coming back to was way less glamorous: how do any of these things actually talk to each other? In a normal backend setup, when two microservices need to chat, we have a playbook. REST, gRPC, Kafka queues, OpenAPI specs. The whole mess is solved. It's boring and it works. But with agents? A year ago, the answer was they just didn't. Or worse, they did it through some horrible custom webhook adapter that someone is going to have to babysit from a Slack DM at 2am. Every system spoke its own language. Integration wasn't a feature—it was somebody's entire job. A2A and MCP fix that exact problem. Google finally stopped treating them like research experiments and started treating them like actual infrastructure. I had to read the docs a few times before I really got it. Here is the summary I wish I had on day one. MCP is HTTP for agents. A2A is DNS plus HTTP for agents talking to other agents. MCP (Model Context Protocol) was Anthropic's baby originally. It standardizes how a model reaches out to your tools and databases. Before MCP, if you wanted Gemini to query a database, you had to write a bunch of glue code and pray the model didn't invent a table name. Now, the model speaks MCP, the server speaks MCP, and they just shake hands. A2A (Agent2Agent) came from Google and got donated to the Linux Foundation. It standardizes how one agent talks to another autonomous agent. The A2A docs say it best: build with whatever framework, equip with MCP, and communicate with A2A. They aren't competing standards. MCP is how your agent talks down to the database. A2A is how it talks sideways to another agent. That realization saved me a massive headache. A lot of this trickled out before NEXT, but the conference is where they put it all together into an actual strategy. On the MCP side, we got fully managed servers for things like BigQuery, Cloud SQL, and Pub/Sub. You don't deploy anything. You just point your agent at an endpoint. They also turned Apigee into an MCP bridge. This means any REST API you already built instantly becomes a discoverable agent tool with your existing auth layered on top. As a guy who spent way too long last year hand-wrapping APIs for LLMs, that was a huge relief. Auth is all IAM-backed now too, so no more passing API keys around. On the A2A side, it hit production grade with LangGraph and CrewAI support. Donating it to the Linux Foundation was a big move. They also announced Agent Registry (basically DNS for your internet of agents) and Agent Gateway. Put it all together, and Google is basically saying they don't need to own the agent itself. They just want to own the highways the agents drive on. I hate architecture diagrams. I need to see the actual implementation. So here is a really minimal setup: a planner agent analyzing data, handing work off to a reporter agent in a completely different service. Planner first. We'll set it up to hit BigQuery via MCP: # planner_agent.py from google.adk.agents import LlmAgent from google.adk.tools.mcp_tool import MCPToolset from google.adk.tools.mcp_tool.mcp_session_manager import StreamableHTTPConnectionParams # Point at Google Cloud's managed BigQuery MCP server. # No infra to deploy. Auth handled by IAM. bigquery_tools = MCPToolset( connection_params=StreamableHTTPConnectionParams( url="https://bigquery.googleapis.com/mcp/v1", ), ) planner = LlmAgent( name="sales_planner", model="gemini-3.1-pro", instruction=( "You analyze sales data in BigQuery and prepare a brief " "for the reporter agent. Findings as bullet points only." ), tools=[bigquery_tools], ) Notice what's missing there. There are no BigQuery SDK imports or crazy prompt schemas. The managed MCP server just exposes the database as an agent tool. When I ran this the first time, I kept looking for the missing step. There isn't one. Next, we expose the reporter agent over A2A: # reporter_server.py from a2a.server import A2AServer from a2a.types import AgentCard, AgentSkill # The Agent Card is the "business card" that other agents fetch. # Served at /.well-known/agent-card.json automatically. card = AgentCard( name="QuarterlyReporter", description="Turns sales briefs into formatted exec reports.", version="1.0.0", url="https://reporter.example.com", skills=[ AgentSkill( id="write_exec_report", name="Write executive report", description="Takes bullet findings and produces a polished report.", input_modes=["text"], output_modes=["text", "application/pdf"], ) ], ) server = A2AServer(agent_card=card, handler=my_report_handler) server.run(host="0.0.0.0", port=8080) That Agent Card is the magic part. It's just a tiny JSON doc at a predictable URL. It tells any other agent from any cloud exactly what this bot can do and how to authenticate. It's basically robots.txt for AI. Finally, we make them talk: # orchestrator.py from a2a.client import A2AClient, A2ACardResolver # Discover what the reporter can do. resolver = A2ACardResolver(base_url="https://reporter.example.com") card = await resolver.get_agent_card() # Open a client against it. reporter = A2AClient(agent_card=card) # Run the planner... findings = await planner.run("Analyze Q1 2026 revenue by region.") # ...and hand off to the reporter over A2A. task = await reporter.send_task( message={"parts": [{"type": "text", "text": findings}]}, ) # A2A tasks have a real lifecycle so we stream updates back. async for update in reporter.stream_task(task.id): print(update.status, update.artifacts) Three files and we have a working cross-service handoff. The crazy part is that the reporter could be running on AWS or it could be a Salesforce agent. The planner code wouldn't need to change at all. A lot of the coverage I've seen just says "these are cool." True. But the interesting part is the underlying design. A2A is basically stealing every good idea from how the early web scaled. Agent Cards live at /.well-known/agent-card.json. That's RFC 8615, the same pattern we use for security.txt. They're using JSON-RPC 2.0 over HTTP and Server-Sent Events. If your system speaks HTTP, it speaks A2A. Tasks have a normal lifecycle too. Submitted, working, completed. It's the same shape as AWS Step Functions or GitHub Actions. It's boring—and coming from backend land, that's basically the nicest thing I can say about a tech. Clever protocols usually die because nobody wants to actually implement them. MCP and A2A are predictable. Look, I'm not totally sold yet. The security surface area here is terrifying. An agent that can auto-discover other agents and pass tasks around is an absolute nightmare for prompt injection or data exfiltration. I'd need a very solid threat model before letting this touch real production data. Debugging is also going to be awful. Google says everything lands in Cloud Audit Logs. Cool. But tracing a failed task across three different agents built by three different vendors? Prepare for a lot of late nights. Also, the spec is still moving. A2A is at the Linux Foundation, which means it will evolve. If you build heavily on it today, you will probably be rewriting parts of it next year. If you want to get ahead of this, here is my unsolicited advice. Go run the A2A Python quickstart. It takes maybe an hour and you get a working agent in 50 lines. Then hook a basic agent up to a managed MCP server. BigQuery is probably the easiest to test. Read a real Agent Card—just go look at the JSON and see how the auth and skills are structured. It grounds the whole concept. Just don't overbuild right away. Start with two agents and see what breaks. Next '26 was Google quietly admitting that no single company will own the agent ecosystem. So they're building the infrastructure instead. A2A is the DNS. MCP is the HTTP. If you learn these protocols now, future-you is going to be really happy about it. That's my bet anyway. If you are building with A2A or MCP, drop a comment. I'd love to swap notes, especially if you've hit weird OAuth snags between managed MCP servers and non-Google clients. I definitely spent a few hours stuck on that this week. — Saquib