2026年のAPIゲートウェイ — Kong 4 / Tyk / Apigee / KrakenD / Zuplo / Envoy Gateway / Traefik 3 徹底比較(15選・4カテゴリ)

プロローグ — 「nginxでよくない?」

2026年のマイクロサービスチームなら、誰もが一度はする会話。

新人: 「APIゲートウェイ、なぜ必要なんですか? nginxを前に置けばよくないですか?」シニア: 「レート制限は? 認証は? キー管理は? ロギングは? スキーマ検証は? カナリアデプロイは? OpenAPI自動生成は? ポータルは?」新人: 「...あっ。」

2026年でもよくある入門の風景だ。nginxやHAProxyは優れたリバースプロキシだが、APIゲートウェイはその上にビジネスロジックを載せた別カテゴリだ。そしてその領域はこの2年で大きく揺れた。

3つの変化があった。

1つ目、Masheryが消えた。 TIBCOは2024年1月31日にMasheryを正式に終了した。かつてApigee・3scale・Masheryは「マネージドBig 3」だったが、一席が空いた。

2つ目、LLM APIゲートウェイという新カテゴリが生まれた。 Portkey・Helicone・OpenRouterは従来型ゲートウェイにはない仕事をする — モデルルーティング、トークンカウント、フォールバック、セマンティックキャッシュ、プロンプト管理。3社ともに2024〜2025年にシリーズAを調達した。

3つ目、プログラマブルなエッジが台頭した。 ZuploはTypeScriptでゲートウェイロジックを書く — Cloudflare Workers上で動く。2024年にシリーズAを獲得し、OpenAPIファーストのワークフローで差別化している。

この記事は2026年現在の15選を4カテゴリにまとめる — オープンソースのセルフホスト、マネージドクラウド、プログラマブルなエッジ、LLMゲートウェイ。各ソリューションの機能・価格・実例・選びどきまで。

第1章 · 2026年のAPIゲートウェイ地図 — 4カテゴリ

まず全体像。15の選択肢を1画面に。

カテゴリ	ソリューション	モデル	強み
オープンソース(セルフホスト)	Kong 4 / KGateway	Apache 2.0 (KonnectはSaaS)	最大のエコシステム、プラグイン
	Tyk	MPL 2.0 (オープンコア)	OSS境界が明確、英国拠点
	KrakenD	Apache 2.0	Go製、最軽量、ステートレス
	Envoy Gateway	Apache 2.0 (CNCF Graduated)	Kubernetes Gateway API標準
	Traefik 3	MIT	自動ディスカバリ、k8s親和
	Gravitee	Apache 2.0 (フランス)	API + Event mesh統合
マネージドクラウド	Apigee X (Google)	エンタープライズSaaS	APIプロダクト、分析
	AWS API Gateway	AWSネイティブ	REST + HTTP + WebSocket
	Cloudflare API Gateway	Cloudflareネイティブ(旧API Shield)	エッジ + セキュリティ
	Azure API Management	Azureネイティブ	ポリシーエンジン、開発者ポータル
	MuleSoft (Salesforce)	エンタープライズ	Anypointプラットフォーム、iPaaS
	Mashery (TIBCO)	サンセット 2024-01	新規受付停止
プログラマブルエッジ	Zuplo	SaaS、edge-first	TypeScript、OpenAPIファースト
	Hasura DDN	マネージド + OSS	GraphQL data delivery network
LLMゲートウェイ	Portkey	SaaS + OSS	AI gateway、100+ LLM
	Helicone	OSS + SaaS	観測 + ゲートウェイ
	OpenRouter	SaaS	LLMルーティング、統合請求

押さえどころは3つ。

1) コントロールプレーンとデータプレーンが分離する。 KongはKonnect(コントロール)とデータプレーンを分けた。Envoy GatewayはxDSで自然に分離する。マネージドSaaSはコントロールプレーンだけSaaS、データプレーンは顧客VPCで動かすハイブリッド型に傾いている。

2) Kubernetes Gateway APIが標準になった。 Envoy Gateway・Kong・TraefikのいずれもGateway APIを一級扱い。Ingress・Gateway・VirtualServiceを別個に学ぶ時代は終わった。

3) LLMゲートウェイは別物。 従来のAPIゲートウェイはLLMのトークンカウント・ストリーミング・フォールバック・セマンティックキャッシュが苦手。だからPortkeyやHeliconeが別途生まれ、Kong・TykもLLMプラグインを追加中。

第2章 · Kong 4 + Konnect — オープンソースの標準

最も広く使われるオープンソースAPIゲートウェイ。2025年にKong 4が登場し、大きな変化があった。

アーキテクチャ. Kongはnginx + Lua (OpenResty)で出発したが、Kong Gateway 3でGoプラグインが入り、4でRustプラグインSDKがGAになった。コントロールプレーンはKonnect (SaaS)かセルフホストの双方が可能で、データプレーンは常に顧客のインフラ上で動く。

主要機能.

# Kong declarative config (Konnect or kong.conf)
_format_version: '3.0'
services:
  - name: user-service
    url: http://user-service.internal:8080
    routes:
      - name: user-route
        paths: ['/api/users']
        methods: ['GET', 'POST']
    plugins:
      - name: rate-limiting
        config:
          minute: 100
          policy: redis
      - name: jwt
        config:
          key_claim_name: kid
      - name: prometheus
        config:
          per_consumer: true
      - name: ai-proxy
        config:
          route_type: 'llm/v1/chat'
          model:
            provider: openai
            name: gpt-4o

KGateway (旧Gloo). Solo.ioが作ったEnvoyベースのゲートウェイをKongが2025年に買収し、KGatewayとしてリブランドした。Envoyデータプレーン + Kongコントロールプレーンの組み合わせで、Kubernetes Gateway API環境に強い。従来のKong Gateway (nginxベース)とKGateway (Envoyベース)は当面共存する。

Konnect. Kongのマネージドコントロールプレーン SaaS。データプレーンは顧客がセルフホストし、コントロール・分析・ポータルだけSaaSで受け取る。マルチリージョンのゲートウェイを単一コンソールで管理できるのが最大の魅力。

プラグインエコシステム. OSSプラグイン100+、エンタープライズプラグイン50+。AI ProxyプラグインはOpenAI/Anthropic/Mistral/Cohereにルーティングしてトークンをカウントする — 2024年追加。

価格. Kong Gateway OSSは無料。Konnect Plusはゲートウェイあたり月250ドルから、Enterpriseは応相談。

選びどき. 最も安全な選択 — エコシステム・ドキュメント・人材プールが圧倒的。ただしnginx + Lua構成なのでデバッグが難しいという声もある。

第3章 · Tyk — オープンコア、英国発

Kongとよく比べられるオープンコアのゲートウェイ。ロンドン本社の英国企業。

ライセンス. Tyk GatewayはMPL 2.0 OSS、Tyk Dashboard・Multi Data Center Bridge・Pumpの一部は商用。オープンコアの境界が明快で「どこまでOSSかが一目でわかる」と評される。

アーキテクチャ. Go製。Kongと違い外部依存(nginx、Luaランタイム)がなく、単一バイナリで動く。Redisは必要(レート制限・分析用)。

# Tyk API definition (api_definition.json 抜粋)
{
  "name": "User API",
  "api_id": "user-api",
  "use_keyless": false,
  "auth": { "auth_header_name": "Authorization" },
  "version_data": {
    "default_version": "v1",
    "versions": {
      "v1": {
        "name": "v1",
        "use_extended_paths": true,
        "extended_paths": {
          "validate_json": [
            { "method": "POST", "path": "/users", "schema_b64": "..." }
          ],
          "circuit_breaker": [
            { "path": "/users", "method": "GET", "threshold_percent": 0.5, "samples": 10 }
          ]
        }
      }
    }
  },
  "proxy": { "target_url": "http://user-service:8080" }
}

Tyk AI Studio. 2025年に追加されたLLMゲートウェイ機能 — モデルルーティング、トークンカウント、PIIマスキング。Kong AI Proxyと真正面から競合する。

価格. OSSは無料。Cloud Starterは月600ドルから、Self-Managedは応相談。

選びどき. Kongのnginx + Luaが好きになれず、Go製の単一バイナリが欲しい時。英国・EUのデータ主権を気にする組織に人気。

第4章 · Apigee X (Google) — エンタープライズの定番

Googleは2016年にApigeeを買収し、GCPに深く統合した上で2021年にApigee Xとして再リリースした。

アーキテクチャ. GCP上のマネージド。Apigee Hybridを使えばコントロールプレーンはGCP、データプレーンは顧客のGKE/EKS/オンプレに置ける。マルチクラウドのエンタープライズが主ターゲット。

ポリシーモデル. Apigee最大の強みはポリシーエンジン。XMLまたはJavaScriptで60+のポリシー(XML/JSON変換、OAuth、Spike Arrest、Quota、JavaCalloutなど)を組み合わせる。

<!-- Apigee policy: Spike Arrest + OAuth + JSON to XML -->
<SpikeArrest name="SA-100ps">
  <Rate>100ps</Rate>
</SpikeArrest>

<OAuthV2 name="OAuth-Verify">
  <Operation>VerifyAccessToken</Operation>
</OAuthV2>

<JSONToXML name="JSON-to-XML">
  <Source>request</Source>
  <OutputVariable>request</OutputVariable>
</JSONToXML>

Apigee Hub. 2024年に追加されたAPIカタログ・ディスカバリサービス。社内の全APIをメタデータで登録し、検索・分類・ライフサイクル管理。

価格. 最も高い — Apigee X Standardは年30,000ドル前後から、Enterpriseは6桁ドル。Apigee Pay-as-you-go (2023)で小規模チームも始められるようになった。

選びどき. GCPに深く入っており、大企業でポリシー・ガバナンス・分析・ポータルが全部必要な時。通信・金融・ヘルスケアで強い。

第5章 · KrakenD — Go製、最軽量

スペイン・バルセロナ拠点のオープンソースゲートウェイ。ステートレス + 宣言的 + Goの3点で差別化。

設計思想. すべての設定を単一JSONファイルに。ランタイムで外部DBやRedisが不要(レート制限はメモリ内またはオプションでRedis)。「12-factor app」と相性が良い。

{
  "version": 3,
  "name": "my-gateway",
  "port": 8080,
  "endpoints": [
    {
      "endpoint": "/api/users/{id}",
      "method": "GET",
      "output_encoding": "json",
      "backend": [
        {
          "host": ["http://user-service:8080"],
          "url_pattern": "/v1/users/{id}",
          "encoding": "json"
        },
        {
          "host": ["http://order-service:8080"],
          "url_pattern": "/v1/orders?user={id}",
          "encoding": "json",
          "group": "orders"
        }
      ],
      "extra_config": {
        "qos/ratelimit/router": {
          "max_rate": 100,
          "client_max_rate": 10
        }
      }
    }
  ]
}

この設定1つで2つのバックエンド呼び出し + レスポンスマージ + レート制限を1エンドポイントに束ねる — これがKrakenDの代名詞response aggregation。BFFパターンをゲートウェイで直接解く。

OSS vs Enterprise. OSS Community EditionはApache 2.0。Enterprise Editionはマルチテナント・高度なOAuth・高度なキャッシュ・SSOが追加。

価格. OSSは無料。Enterpriseはノードあたり年次ライセンス。

選びどき. 運用のシンプルさを最優先する時。Kong/Apigeeが重く感じ、BFFやAPIコンポジションをゲートウェイで処理したい時。スタートアップ・中小企業・SaaSで人気。

第6章 · Zuplo — プログラマブル、エッジ優先のTypeScript

2022年創業、2024年にシリーズA 9百万ドル調達。最も新しいカテゴリ — ゲートウェイロジックをTypeScriptで書く。

アーキテクチャ. Cloudflare Workers上で動く — 世界300+のエッジPoPに自動デプロイ。ユーザーはTypeScript関数とOpenAPI仕様をGitHubにpushし、Zuploが自動デプロイする。

// Zuplo policy: custom auth + transform
import { ZuploRequest, ZuploContext } from '@zuplo/runtime'

export default async function (
  request: ZuploRequest,
  context: ZuploContext
) {
  const token = request.headers.get('authorization')?.replace('Bearer ', '')

  if (!token) {
    return new Response('Unauthorized', { status: 401 })
  }

  const user = await context.invokeInboundPolicy('jwt-auth', request)
  request.headers.set('x-user-id', user.sub)
  request.headers.set('x-user-tier', user.tier ?? 'free')

  return request
}

OpenAPIファースト. Zuploの差別点 — ルート設定がOpenAPI 3.1仕様そのもの。仕様を変えればゲートウェイが変わり、開発者ポータルが変わり、モックサーバーが変わる。single source of truth.

開発者ポータル自動生成. OpenAPIからポータル・SDK・ドキュメント・インタラクティブコンソールが自動生成される。ReadMeやStoplightと競合。

価格. 無料枠は月200万リクエスト。Productionは月200ドルから、Enterpriseは応相談。

選びどき. B2B SaaSの外部APIを運用する時 — OpenAPIファースト・開発者ポータル・エッジのグローバル分散がワンパッケージで必要な時。AI企業がLLM APIを公開するときによく選ばれる。

第7章 · AWS API Gateway / Cloudflare API Gateway / Azure APIM — クラウドネイティブ

AWS API Gateway

3種類 — REST API、HTTP API、WebSocket API。

REST API: 最古、最高価格、最も機能豊富。WAF・API Keys・Usage Plans・X-Ray・キャッシュ。
HTTP API: 2019年追加。RESTより70%安く、60%速い。JWTが標準。Lambda Authorizer。
WebSocket API: 双方向接続 — チャット・リアルタイム通知。

# AWS SAM template — HTTP API
Resources:
  MyApi:
    Type: AWS::Serverless::HttpApi
    Properties:
      Auth:
        Authorizers:
          JwtAuth:
            JwtConfiguration:
              issuer: https://example.auth0.com/
              audience: ['https://api.example.com']
        DefaultAuthorizer: JwtAuth
      RouteSettings:
        '$default':
          ThrottlingBurstLimit: 100
          ThrottlingRateLimit: 50

価格. HTTP APIは100万リクエストあたり1ドル、REST APIは3.50ドル。Cloudflare API Gatewayよりは高め。

選びどき. AWSに深く入っており、Lambda・EventBridge・Cognitoと組み合わせる時。マルチクラウドだとロックインが負担。

Cloudflare API Gateway

2022年にAPI Shieldとして登場、2024年に「API Gateway」へリブランド。Cloudflare Workers + WAFの上に載ったゲートウェイ。

主な機能は3つ。

Schema validation — OpenAPI仕様をアップロードすると全リクエストを自動検証。
Sequence Analytics — 異常なAPI呼び出しシーケンスをMLで検知(BOLA・BFLA攻撃を遮断)。
mTLS / JWT validation — エッジで認証を完結。

// Cloudflare Worker as API gateway logic
export default {
  async fetch(request, env, ctx) {
    const url = new URL(request.url)

    // Rate limit per API key
    const apiKey = request.headers.get('x-api-key')
    const rateLimitKey = `ratelimit:${apiKey}`
    const count = await env.RATE_LIMIT_KV.get(rateLimitKey)

    if (count && parseInt(count) > 1000) {
      return new Response('Rate limit exceeded', { status: 429 })
    }

    await env.RATE_LIMIT_KV.put(
      rateLimitKey,
      String((parseInt(count) || 0) + 1),
      { expirationTtl: 60 }
    )

    // Proxy to origin
    return fetch(`https://api.internal.example.com${url.pathname}`, request)
  },
}

価格. Enterpriseプランに含まれる。別途価格設定なし(Cloudflareの営業と相談)。

選びどき. 既にCloudflareを使っていて、エッジで認証・レート制限・スキーマ検証を済ませたい時。グローバル分散が強み。

Azure API Management (APIM)

Azureネイティブのゲートウェイ。ポリシー式モデルが核 — XMLでinbound・backend・outbound・on-errorの各段階にポリシーを差し込む。

<policies>
  <inbound>
    <base />
    <validate-jwt header-name="Authorization" failed-validation-httpcode="401">
      <openid-config url="https://login.microsoftonline.com/.../.well-known/openid-configuration" />
      <audiences>
        <audience>api://my-api</audience>
      </audiences>
    </validate-jwt>
    <rate-limit-by-key calls="100" renewal-period="60" counter-key="@(context.Subscription.Id)" />
    <set-header name="x-correlation-id" exists-action="skip">
      <value>@(Guid.NewGuid().ToString())</value>
    </set-header>
  </inbound>
  <backend>
    <forward-request />
  </backend>
  <outbound>
    <base />
    <set-header name="x-served-by" exists-action="override">
      <value>apim</value>
    </set-header>
  </outbound>
</policies>

Tier. Consumption(サーバーレス、従量課金) / Developer / Basic / Standard / Premium / Premium v2。Premiumはマルチリージョン + VNet統合。

選びどき. Azureとの深い統合。.NET / Microsoft 365 / Office Add-inのエコシステムと組み合わさる時。官公庁・公共部門で強い。

第8章 · Gravitee / MuleSoft / Hasura DDN — その他注目株

Gravitee.io

フランス・パリとラヴァルに本社。OSS Apache 2.0。差別点はAPI + Event APIの統合 — REST・gRPC・GraphQLだけでなくKafka・MQTT・WebSocket・SSEを1ゲートウェイで扱う。AsyncAPI一級対応。

2025年にGravitee 5が出てLLMゲートウェイ機能(プロンプト検査・PIIマスキング・トークンクォータ)が追加された。

EU拠点・GDPR親和・OSS優先なので欧州政府・金融・通信で人気。

MuleSoft Anypoint (Salesforce)

厳密にはAPIゲートウェイだけでなくiPaaS — Integration Platform as a Service。Anypoint StudioというビジュアルIDEでデータ変換・統合フローを作る。Salesforceエコシステムと深く統合。

最も高価で重い。大企業SI・複雑なレガシー統合シナリオ向け。小規模チームには過剰。

Hasura DDN (Data Delivery Network)

Hasuraが2024年に発表した新製品 — 厳密な意味の「APIゲートウェイ」ではないがGraphQLファーストのデータAPIプラットフォーム。複数データソース(Postgres・MySQL・MongoDB・Snowflake・REST API)を単一GraphQLスキーマに統合し、エッジでキャッシュ・認証・レート制限を行う。

GraphQL APIを外部に公開したく、バックエンドのデータが複数ソースに散らばっている時に良い選択。

第9章 · Envoy Gateway (CNCF) / Traefik 3 — Kubernetesネイティブ

Envoy Gateway

CNCF Graduated(2024)プロジェクト。Envoy ProxyをKubernetes Gateway APIで抽象化する。Lyftが作ったEnvoyはIstio・Consul・gRPCのデータプレーンとして既に標準だが、直接運用すると複雑だった。Envoy Gatewayはその複雑さを隠す。

# Envoy Gateway — Kubernetes Gateway API
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: eg
spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: eg
spec:
  gatewayClassName: eg
  listeners:
    - name: http
      protocol: HTTP
      port: 80
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: user-api
spec:
  parentRefs:
    - name: eg
  hostnames: ['api.example.com']
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api/users
      backendRefs:
        - name: user-service
          port: 8080

選びどき. Kubernetesに深く入っており、Gateway API標準に従いたい時。Istio・Linkerdなどサービスメッシュとデータプレーンを共有したい時。

Traefik 3

2024年にv3が出て、自動ディスカバリ(Docker・Kubernetes・Consul) + Gateway API + HTTP/3 + WebAssemblyミドルウェア + OpenTelemetry標準対応。v2比で大きく前進した。

伝統的には「Kubernetes Ingressのより良い選択肢」として始まったが、v3で本格的なAPIゲートウェイへ進化 — TraefikHubでAPIカタログ・ポータルも提供。

# Traefik 3 — Kubernetes Ingress (or Gateway API)
apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
  name: user-api
spec:
  entryPoints: [websecure]
  routes:
    - match: Host(`api.example.com`) && PathPrefix(`/api/users`)
      kind: Rule
      services:
        - name: user-service
          port: 8080
      middlewares:
        - name: rate-limit
        - name: auth-jwt

選びどき. Docker ComposeからKubernetesまで同じツールで通したい時。自動ディスカバリが強みで運用負担が小さい。

第10章 · LLM APIゲートウェイ — Portkey / Helicone / OpenRouter

従来のAPIゲートウェイはLLMに合わない。トークンカウント・SSEストリーミング・セマンティックキャッシュ・モデルルーティング・フォールバック — どれも欠けている。だから2023〜2024年に専用のLLMゲートウェイが別途台頭した。

Portkey

最も機能豊富なLLMゲートウェイ。OSSコア + 有料SaaS。200+モデルを単一OpenAI互換APIで公開。

主な機能 — フォールバック(モデルAが失敗したらB)、負荷分散(50/50ルーティング)、セマンティックキャッシュ、プロンプト管理(Git風バージョン管理)、ガードレール(PII・toxic・hallucinationチェック)、トークン予算(チーム別・ユーザー別)。

from portkey_ai import Portkey

portkey = Portkey(
    api_key="YOUR_PORTKEY_API_KEY",
    config={
        "strategy": {"mode": "fallback"},
        "targets": [
            {
                "provider": "anthropic",
                "api_key": "ANTHROPIC_KEY",
                "override_params": {"model": "claude-opus-4"},
            },
            {
                "provider": "openai",
                "api_key": "OPENAI_KEY",
                "override_params": {"model": "gpt-4o"},
            },
        ],
    },
)

response = portkey.chat.completions.create(
    messages=[{"role": "user", "content": "Explain transformers."}]
)

Helicone

観測優先のLLMゲートウェイ。OSS Apache 2.0 + SaaS。base_urlを差し替えるだけで全OpenAI呼び出しがHelicone経由になり、トークン・コスト・レイテンシ・エラーが自動記録される。

from openai import OpenAI

client = OpenAI(
    base_url="https://oai.helicone.ai/v1",
    api_key="YOUR_OPENAI_KEY",
    default_headers={
        "Helicone-Auth": "Bearer YOUR_HELICONE_KEY",
        "Helicone-Cache-Enabled": "true",
        "Helicone-Property-User": "user-42",
    },
)

データプレーンをセルフホストできるのが大きな魅力 — 機微なプロンプトが外に出ない。

OpenRouter

「LLM版Stripe」を自称する。300+モデルを統合請求で束ねた — 一度決済すればOpenAI・Anthropic・Google・Mistral・DeepSeek・ホスト型Llamaなど、どのモデルでも使える。

モデルごとの価格を自動比較して最安にルーティングする機能が差別点。ただしSaaS only、OSS版なし。小規模チーム・実験・プロトタイピングに人気。

// OpenRouter — OpenAI SDK 互換
import OpenAI from 'openai'

const openai = new OpenAI({
  baseURL: 'https://openrouter.ai/api/v1',
  apiKey: process.env.OPENROUTER_API_KEY,
})

const completion = await openai.chat.completions.create({
  model: 'anthropic/claude-opus-4',
  messages: [{ role: 'user', content: 'Hello' }],
})

第11章 · レート制限 / 認証 / スキーマ検証 / キャッシュのパターン

ゲートウェイが解く4大パターン。

レート制限

3つのアルゴリズムが標準 — token bucket、leaky bucket、sliding window。多くはRedisにカウンタを置く。

# Kong rate-limiting plugin
plugins:
  - name: rate-limiting-advanced
    config:
      limit: [100, 1000]
      window_size: [60, 3600]
      identifier: consumer
      sync_rate: 10
      strategy: redis
      redis:
        host: redis.internal
        port: 6379

層別に異なる上限を — 匿名IPは10/分、無料キーは100/分、有料キーは10,000/分。

認証

ゲートウェイが扱う認証方式。

API Key — 最も単純、ローテーションが難しい。
JWT — 自己署名、検証可能、短命。最もよく使う。
OAuth 2.0 / OIDC — 標準認証、refresh token、ユーザー同意。
mTLS — クライアント証明書、B2Bで強い。

ほとんどのゲートウェイがJWT検証を一級対応。issuer・audience・exp・署名の検証をエッジで終わらせる — バックエンドは認証済みリクエストだけを受ける。

スキーマ検証

ゲートウェイがOpenAPI 3.1仕様を読み、全リクエスト・全レスポンスを検証する。不正リクエストはエッジで400として遮断 — バックエンド負荷を下げ、セキュリティも強化(スキーマ外フィールドは拒否)。

# Cloudflare API Gateway — OpenAPI schema validation
apiVersion: api-gateway.cloudflare.com/v1
kind: Schema
metadata:
  name: users-api-v1
spec:
  openapi: 3.1.0
  enforcement: enforce
  source: file:openapi.yaml

キャッシュ

GETレスポンスをエッジでキャッシュ — Cache-Controlヘッダかゲートウェイルールに従う。Apigee・Kong・Cloudflare・KrakenDが全て一級対応。キャッシュキーの設計が重要 — ユーザー固有データを誤ってキャッシュすると情報漏洩。

第12章 · BFF (Backend For Frontend)パターン

Sam Newmanが2015年の記事でまとめたパターン。フロントエンドごとに専用のバックエンドAPIを置く — Web・iOS・Androidそれぞれで必要なデータも形も違うから。

[Web] ──▶ [Web BFF] ──▶ [User, Order, Product services]
[iOS] ──▶ [iOS BFF] ──▶ [User, Order, Product services]
[Android] ──▶ [Android BFF] ──▶ [User, Order, Product services]

BFFはどこで動く? 2つのパターン。

パターンA — 別個のBFFサービス. Node.js・GoでBFFを自前で書く。最も柔軟だが運用負担が大きい — Nフロントエンド = Nバックエンドサービス。

パターンB — APIゲートウェイがBFFを担う. KrakenD・Zuplo・Apigeeのようなゲートウェイが複数バックエンド呼び出し + レスポンスマージを直接行う。別途コードを書かなくて済む。

2026年のトレンドはBへ移行する動き。単純なBFF(複数API呼び出し→マージ→返却)はゲートウェイで十分、複雑なBFF(状態・キャッシュ・セッション)だけを別サービスにする。

GraphQLをBFFにするパターンも健在 — Hasura DDNがそのポジションを狙う。

第13章 · OpenAPI 3.1 / AsyncAPI 2.6 · 3 / gRPC

API仕様フォーマットの2026年事情。

OpenAPI 3.1

REST/HTTP APIの標準。2021年に出た3.1がJSON Schema 2020-12と完全互換になり、ゲートウェイ・SDK・ドキュメント・テストが単一スキーマを共有する。

Zuplo・Apigee・Cloudflare・KongはいずれもOpenAPIファーストのワークフローを推す。仕様がそのままゲートウェイ設定だ。

AsyncAPI 2.6 / 3.0

イベント駆動API(Kafka・MQTT・WebSocket・SSE)のOpenAPI。2023年にAsyncAPI 3.0が出てOpenAPI 3.1と構造を統一した。Graviteeが最も強く推し、Confluentも採用。

# AsyncAPI 3.0 example
asyncapi: 3.0.0
info:
  title: Order events
  version: 1.0.0
channels:
  orderCreated:
    address: orders.created
    messages:
      orderCreated:
        payload:
          type: object
          properties:
            orderId: { type: string }
            userId: { type: string }
            total: { type: number }
operations:
  publishOrderCreated:
    action: send
    channel:
      $ref: '#/channels/orderCreated'

gRPC

内部マイクロサービス通信の事実上の標準。Envoy Gateway・Kong・TraefikがいずれもgRPCを一級対応。gRPC-Webでブラウザからも呼べる。

RESTとgRPCを同時に公開するのが一般的 — 外部にREST、内部にgRPC。

第14章 · 韓国 / 日本 — Toss / Kakao / メルカリ / ZOZO

Toss APIゲートウェイ

Tossは自家製ゲートウェイを使う。Toss技術ブログによればSpring Cloud Gatewayから出発し、独自のミドルウェア層を載せて認証・レート制限・異常検知を統合運用している。1日数億件のAPI呼び出しが1つのゲートウェイを通る。

得られた教訓 — 「既製ソリューションは我々の要件を全て満たさなかった。自前で作り、ビジネスに合わせた。」Tossの規模では合理的だが、一般企業が真似すべきパターンではない。

Kakao APIプラットフォーム

Kakaoは社内向けのAPI Platformを運用している。Kong + 独自コントロールプレーン + 独自ポータルの組み合わせとして知られる。KakaoTalk・KakaoPay・KakaoBankなど系列各社間のAPI呼び出しの標準ゲートウェイ。

メルカリ

マイクロサービスベース、日本最大の中古マーケット。独自Envoyベースのゲートウェイ + Istioサービスメッシュ。メルカリエンジニアリングブログには Envoyの運用について複数の記事がある。Envoyデータプレーン + 独自コントロールプレーンパターンの代表例。

ZOZO

ZOZOTOWNを運営する日本のファッションEC。マイクロサービス化の過程でKongを採用し、段階的にEnvoyへ移行中とZOZOテックブログに公開。Kubernetes Gateway APIへ自然に移っていく事例。

第15章 · 誰が何を選ぶべきか — 4シナリオ

小規模チーム(10人以下、MVP)

1番手: Cloudflare API Gateway — 既にCloudflareを使っている可能性が高く、追加インフラ0。
2番手: Zuplo — OpenAPIファーストのワークフローが速い。SaaSなので運用負担なし。
3番手: KrakenD OSS — セルフホストが楽なら。
避ける: Apigee・MuleSoft(過剰)、Mashery(既にサンセット)。

中規模チーム(50〜200人、マルチサービス)

1番手: Kong OSS + Konnect — 最も安全。コミュニティ・人材・プラグインが豊富。
2番手: Envoy Gateway + 独自コントロール — Kubernetes優先なら。
3番手: AWS API Gateway HTTP API — AWSに深く統合済みなら。

エンタープライズ(1000人+、ポリシーとガバナンスが重要)

1番手: Apigee X — ポリシー・分析・ポータル・SLAが全部必要な時。
2番手: Azure APIM — Microsoftエコシステムなら。
3番手: Kong Enterprise + Konnect — クラウド中立が重要な時。

LLMルーティング(AI企業、または外部にLLMを公開)

1番手: Portkey — 機能豊富、フォールバック・負荷分散・プロンプト管理。
2番手: Helicone — 観測優先、セルフホスト可能。
3番手: OpenRouter — 統合請求・実験・プロトタイピングに最適。
補助: Kong AI ProxyまたはTyk AI Studio — 従来のゲートウェイにLLM機能を追加。

エピローグ — 「ゲートウェイはインフラではなく製品の一部だ」

2026年の最大の変化は、APIゲートウェイが単なる「ネットワークインフラ」から「製品の一部」へ移ったことだ。OpenAPI仕様 = 製品仕様、開発者ポータル = 製品の第一印象、レート制限・認証 = 製品のビジネスモデル。

そしてLLMがその流れを加速する。モデルルーティング・トークン予算・プロンプト管理は運用ではなく経営判断だ。誰がどのモデルにいくらのリクエストを送るかが直接損益になる。

小規模チームならCloudflareかZuploで素早く始める。中規模ならKongが最も安全。エンタープライズはApigeeまたはAzure APIM。LLMならPortkeyまたはHelicone。そしてMasheryはもうない — 既存ユーザーはマイグレーション計画を立てよう。

次回候補: OpenAPI 3.1 + Zod + tRPC — 型安全フルスタックAPIを作る、Envoy運用ガイド — デバッグ・メトリクス・zone-aware load balancing、LLMゲートウェイを自作する — 100行でフォールバックとキャッシュを実装。

「ゲートウェイはインフラではない。製品の一部だ。OpenAPI仕様が製品仕様、開発者ポータルが第一印象、レート制限がビジネスモデルだ。」

— APIゲートウェイ 2026、終わり。