なぜAWSは選ばれたのか ― 標準化の力学で読み解くAI時代のプロトコル戦争

TL;DR

• AWSが勝った理由は性能ではなく「世界中の開発者が参加できる標準基盤」を作ったこと
• AI時代も同じ力学が働いており、現在MCP・A2A・Function Callingの3つのプロトコルが標準を争っている
• 2026年時点でMCPが有力な標準候補として急速に普及しているが、この勝因もAWSと同じ「余白の設計」にある

---

はじめに

クラウドサービスを選ぶとき、多くの企業や開発者はAWSを選択肢に入れます。

しかし、なぜAWSなのでしょうか。単純に性能が高いから、価格が安いからでしょうか。

実際には、それだけでは説明できません。AWSが世界中で利用されている最大の理由は、世界中の開発者が参加できる「標準基盤」を作ったことにあります。

そしてこの「標準化の力学」は、いまAIの世界でまったく同じ形で繰り返されています。本記事では、AWSの成功要因を分析した上で、AI時代に進行中のプロトコル標準化競争（MCP vs A2A vs Function Calling）を同じフレームワークで読み解きます。

---

1. 技術力だけでは市場を制覇できない ― ITの歴史が示す法則

ITの歴史を見ると、最高性能の技術が勝ったわけではありません。

競争	技術的に優れていた側	勝った側	勝因
VHS vs ベータ	ベータ（画質）	VHS	ライセンス開放、録画時間
Windows vs Mac	Mac（UI設計）	Windows	OEM開放、ソフトウェア資産
Android vs 独自モバイルOS	各社独自OS（最適化）	Android	オープンソース、端末メーカー参入自由
Linux vs 商用UNIX	商用UNIX（安定性）	Linux	誰でも参加できるエコシステム

勝敗を分けたのは、どれだけ多くの参加者がエコシステムに加わったかです。標準になると、利用者が増える→対応サービスが増える→さらに利用者が増える、というネットワーク効果が発生します。

---

2. AWSの本当の強さは「標準化」にある

AWSは単なるサーバー貸しサービスではありません。クラウドシステムを構築するときの「共通部品」を提供しました。

しかし、重要なのはサービスの数ではありません。世界中の開発者が「AWSで作る方法」を共有するようになったことです。Stack Overflowの回答、Terraformのモジュール、CDKのコンストラクトライブラリ、Qiitaの技術記事。これらすべてが「AWSの上に構築するための共有知識」として蓄積されました。

つまりAWSは、クラウド開発の共通言語になったのです。

標準を作る企業は「余白」を残す

標準化で重要なのは、すべてを完成させることではありません。むしろ「他者が参加できる余地」を残すことです。

Linuxが広がった理由も、誰でも利用でき、誰でも改善できる環境だったからです。AWSも同じで、AWSだけで閉じた世界を作るのではなく、開発者・企業・OSSコミュニティ・パートナー企業が参加できる場所を作りました。

この「余白の設計」は、後述するMCPの成功要因とまったく同じ構造を持っています。

---

3. AI時代の標準化競争 ― いま何が起きているか

生成AI時代に入り、多くの人は「どのAIモデルが一番賢いか」に注目しています。しかし歴史の法則に従えば、性能だけでは最終的な勝者は決まりません。

重要なのは、誰がAIを社会に組み込むための標準基盤を作るかです。

2026年現在、AI連携の標準をめぐって3つのプロトコルが競争しています。

3.1 Function Calling（OpenAI, 2023年〜）

OpenAIが2023年6月にGPT-3.5-turboで導入した、LLMに外部ツールを呼び出させる仕組みです。

# Function Callingの基本構造
tools = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "指定都市の天気を取得",
            "parameters": {
                "type": "object",
                "properties": {
                    "city": {
                        "type": "string",
                        "description": "都市名"
                    }
                },
                "required": ["city"]
            }
        }
    }
]

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "東京の天気は？"}],
    tools=tools
)

特徴: シンプルで低レイテンシ。OpenAIのAPI内に閉じた仕組み。

限界: ベンダーロックイン。OpenAI以外のモデルで同じツール定義を再利用できない。M個のモデル × N個のツールで M×N の個別実装が必要になる（M×N問題）。

3.2 MCP（Anthropic → Linux Foundation, 2024年11月〜）

Anthropicが2024年11月に公開し、2025年12月にLinux Foundation傘下のAgentic AI Foundation（AAIF）に寄贈されたオープンプロトコルです。

┌─────────────┐     JSON-RPC 2.0      ┌─────────────┐
│  MCP Host    │◄────────────────────►│  MCP Server  │
│ (Claude,     │  stdio / HTTP        │ (GitHub,     │
│  ChatGPT,    │                      │  Postgres,   │
│  Cursor)     │                      │  Slack...)   │
└─────────────┘                       └─────────────┘

特徴: ベンダー中立。一度書いたMCPサーバーは、Claude、ChatGPT、Cursor、VS Codeなど、すべてのMCP対応クライアントから利用できる。M×N問題をM+Nに削減する。

規模（2026年7月時点）: Anthropicの公式発表（2025年12月）によると、月間9700万以上のSDKダウンロード（Python + TypeScript）。GitHub Search APIの公開データでは、15,900以上のリポジトリが mcp-server トピックを持つ（2026年5月時点）。AAIF参加組織は146社（JPMorgan Chase, American Express, Autodesk, Red Hat, Huawei等）。

3.3 A2A（Google, 2025年4月〜）

Googleが2025年4月のCloud Nextで発表した、エージェント間通信プロトコルです。

特徴: MCPが「モデル↔ツール」の垂直接続を担うのに対し、A2Aは「エージェント↔エージェント」の水平連携を担う。Agent Cardによる能力公開、タスク委譲、非同期処理をサポートする。

MCPとの関係: 競合ではなく補完。Google自身が「MCPは整備士が診断機器を使う方法、A2Aは顧客が整備工場と話す方法」と説明している。

3つのプロトコルの比較

項目	Function Calling	MCP	A2A
提唱者	OpenAI	Anthropic → AAIF	Google → AAIF
対象	モデル → ツール	モデル → ツール	エージェント → エージェント
標準化	プロプライエタリ	オープン標準（Linux Foundation）	オープン標準（Linux Foundation）
ポータビリティ	OpenAIモデルに限定	全モデル対応	全エージェント対応
トランスポート	REST API内のJSONフィールド	JSON-RPC 2.0（stdio/HTTP）	HTTP/JSON
動的ツール検出	なし（静的定義）	あり	あり（Agent Card）
ガバナンス	OpenAI単独	AAIF（146組織）	AAIF

---

4. なぜMCPが勝ちつつあるのか ― AWSと同じ標準化メカニズム

MCPの急速な普及は、AWSの成功と同じ標準化メカニズムで説明できます。AWSは商用クラウドサービス（インフラ標準）、MCPはAIツール接続プロトコル（通信標準）であり、対象は異なります。しかし「参加者を増やす仕組みの設計」という点で、同じ力学が働いています。

4.1 「余白の設計」

AWSがパートナーやOSSコミュニティに参加の余地を残したように、MCPは仕様をオープンにし、誰でもMCPサーバーを作れるようにしました。その結果、GitHub上に15,900以上のMCPサーバーリポジトリが生まれ、各サーバーが即座にすべてのMCP対応クライアントで利用可能になりました。

4.2 ネットワーク効果

AWSでサービスが増えるほど利用者が増えたように、MCPでもサーバーが増えるほどクライアント側の対応価値が上がり、クライアントが増えるほどサーバーを作るインセンティブが強まります。

MCPサーバーが増える
    ↓
MCP対応クライアントの価値が上がる
    ↓
クライアントが増える
    ↓
サーバーを作るインセンティブが強まる
    ↓
さらにサーバーが増える

4.3 競合の参加

AWSの標準化にサードパーティが乗ったように、MCPにはOpenAI（最大の競合）が2025年3月に対応を表明しました。これについて、あるアナリストは「1998年にAppleがiMacでUSBだけを採用した瞬間に似ている。エコシステムの中心にいるプレイヤーが採用したことで、標準候補としての地位が大きく強化された」と分析しています。

4.4 中立的ガバナンスへの移行

AWSはAmazon単独のサービスですが、MCPはさらに一歩進んで2025年12月にLinux Foundation傘下のAAIFに寄贈されました。Anthropic、OpenAI、Block、AWS、Google、Microsoftが共同で運営する中立的なガバナンス体制を取っています。

---

5. 実装で理解する ― MCPサーバーの基本構造

MCPが標準になりつつある理由を、実装レベルで確認します。以下は、TypeScriptで書いた最小限のMCPサーバーの構造です。

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({
    name: "weather-server",
    version: "1.0.0",
});

// ツールの定義
server.tool(
    "get_weather",
    "指定都市の現在の天気を取得する",
    {
        city: z.string().describe("都市名（例: Tokyo, Osaka）"),
    },
    async ({ city }) => {
        // 実際にはAPIを呼び出す
        const weather = await fetchWeather(city);
        return {
            content: [
                {
                    type: "text",
                    text: `${city}の天気: ${weather.condition}, ${weather.temp}°C`,
                },
            ],
        };
    }
);

// トランスポートの接続
const transport = new StdioServerTransport();
await server.connect(transport);

このサーバーを一度書けば、Claude、ChatGPT、Cursor、VS Code Copilot、その他すべてのMCP対応クライアントから呼び出せます。Function Callingのように、クライアントごとにツール定義を書き直す必要がありません。

これがM×N問題をM+Nに削減するという意味です。

【Function Calling】             【MCP】
Client A ─┬─ Tool 1             Client A ─┐
           ├─ Tool 2             Client B ─┤─ MCP Server (Tool)
           └─ Tool 3             Client C ─┘
Client B ─┬─ Tool 1
           ├─ Tool 2             実装数: M + N
           └─ Tool 3
                                 ※同じサーバーをすべての
実装数: M × N                     クライアントが利用可能

---

6. レイヤードアーキテクチャ ― 3つのプロトコルの使い分け

実際のプロダクションシステムでは、3つのプロトコルは競合ではなく、異なるレイヤーを担います。

┌───────────────────────────────────────┐
│         A2A（エージェント間連携）        │
│   研究Agent ←→ 執筆Agent ←→ 検証Agent  │
├───────────────────────────────────────┤
│         MCP（ツール・データ接続）         │
│   DB接続 / API呼出 / ファイル操作        │
├───────────────────────────────────────┤
│     Function Calling（実行契約）         │
│   厳密な引数スキーマ / 決定的実行        │
└───────────────────────────────────────┘

レイヤー	プロトコル	使うべき場面
エージェント間連携	A2A	複数の専門エージェントがタスクを委譲・協調する
ツール・データ接続	MCP	1つのエージェントが複数の外部ツール・データソースにアクセスする
実行契約	Function Calling	スキーマの厳密性が最優先（strict modeによる引数検証）

推奨されるアプローチは、まずMCPでツール接続を標準化し、マルチエージェントの必要性が生じたらA2Aを追加し、厳密な実行契約が必要な部分にFunction Callingを使う、というレイヤード設計です。

---

7. 日本が取るべき標準化戦略

ここまでの分析から、標準化の力学について以下の法則が見えてきます。

1. 最高性能の技術が勝つとは限らない（VHS vs ベータ、Windows vs Mac）
2. 参加の余白を残した側が勝つ（Linux、AWS、MCP）
3. ネットワーク効果が始まると逆転は極めて困難（MCP 9700万DL/月）
4. 中立的ガバナンスが信頼を生む（Linux Foundation, AAIF）

日本のAI戦略を考えるとき、「世界最大のAIモデルを作る」ことだけが選択肢ではありません。

日本には製造業の現場データ、医療知識、農業技術、防災ノウハウなど、世界的に価値のあるドメイン知識があります。これらをMCPサーバーとして標準プロトコル上に公開すれば、世界中のAIクライアントから即座にアクセス可能になります。

たとえば以下のような特化型MCPサーバーが考えられます。

• 製造品質AI: 日本の製造業が蓄積した品質管理ノウハウをMCPサーバー化し、世界の製造業AIエージェントから利用可能にする
• 防災AI: 地震・津波・台風に関する世界最高水準の知見をMCPサーバー化し、各国の防災システムと連携する
• 農業AI: 気象・土壌・栽培データの解析をMCPサーバーとして提供する

モデルの規模で競うのではなく、ドメイン知識を世界標準プロトコル上で提供するという戦略です。「余白」を使う側にまわるのではなく、「余白の中で不可欠な部品になる」という発想です。

---

おわりに

AWSが世界で選ばれた理由は、最高性能の技術だったからではありません。世界中の開発者が参加できる標準基盤を作ったからです。

2026年現在、AI連携の世界でもまったく同じ標準化メカニズムが働いています。MCPがAnthropicの公式発表で月間9700万ダウンロードに達し、OpenAI・Google・Microsoft・AWSが同じプロトコルを採用した構図は、かつてAWSがクラウドの標準言語になった過程と重なります。

標準を制する者が次の時代を作る。この法則は、VHS、Windows、Linux、AWSを経て、いまAIプロトコルの世界で再び検証されています。

日本が目指すべきは、AIモデルの巨大化競争だけではありません。重要なのは、世界中のAIが利用する「知識・データ・専門能力の接続規格」を作る側に回れるかです。インターネット時代にTCP/IPを握った者が通信基盤を作り、クラウド時代にAWSが開発基盤を作りました。AI時代では、知識と能力を接続する標準を誰が作るかが、新しい競争軸になります。

---

参考リンク

• Model Context Protocol 仕様
• Anthropic MCP公式発表
• Agentic AI Foundation（Linux Foundation）
• MCP vs A2A vs Function Calling 比較（Zilliz）
• MCP Adoption Statistics 2026

---