この記事では、マイクロサービスアーキテクチャにおける API Gateway の役割を、歴史的な経緯から技術的な詳細まで体系的に解説します。
「API Gateway って何をしているの？」「なぜマイクロサービスに必要なの？」という疑問に対して、モノリスからマイクロサービスへの移行という歴史の流れの中で答えを示していきます。
対象読者
- マイクロサービスアーキテクチャを導入しようとしているエンジニア
- API Gateway の役割を体系的に理解したい方
- システム設計の基礎知識を固めたい方
アーキテクチャの進化 — モノリスからマイクロサービスへ
API Gateway がなぜ必要なのかを理解するには、アプリケーションアーキテクチャがどう変遷してきたかを辿るのが最も分かりやすいです。
2000年代：モノリスの時代
2000年代の多くのプロダクション環境では、アプリケーションは単一のモノリスとして動いていました。
図1: モノリスアーキテクチャ — クライアントは1つのURLにリクエストを送り、すべての処理が1つのサーバーで完結する
クライアントが叩くURLは1つ。認証もユーザー管理も注文処理もメッセージングも、すべてが1つのサーバーの中に収まっていました。データベースへの接続も、そのサーバーから直接行われます。
この構成の最大の利点はシンプルさです。リクエストの流れが一本道で、デバッグも容易。デプロイも1つのアーティファクトを置き換えるだけ。チームが小さく、アプリケーションの規模も限られている段階では、これで十分に機能していました。
2010〜2012年頃：マイクロサービスへの分割
しかし、サービスが成長するにつれて、モノリスには限界が見えてきます。
- デプロイの影響範囲が大きい — 1つの機能を修正しただけでも、アプリケーション全体を再デプロイする必要がある
- スケーリングの粒度が粗い — メッセージング機能だけ負荷が高くても、アプリケーション全体をスケールアウトしなければならない
- チームの独立性が低い — 複数チームが同じコードベースで作業し、変更の競合やリリース調整が発生する
こうした課題を解決するために、モノリスを機能ごとに分割するマイクロサービスアーキテクチャが台頭しました。
図2: マイクロサービスアーキテクチャ（API Gatewayなし）— クライアントが各サービスのURLを個別に知る必要がある
ところが、モノリスを分割したことで新たな問題が生まれました。クライアントが各マイクロサービスのURLを個別に知らなければならないのです。
これには2つのアプローチが考えられました。
- クライアントが全サービスのエンドポイントを管理する — サービスが増えるたびにクライアント側の修正が必要になり、密結合が生じる
- 1つのサービスがルーターの役割を兼ねる — 例えば User Service がリクエストを受けて、必要に応じて他のサービスに転送する。しかし、ルーティングロジックを変更するたびにそのサービス全体を再デプロイしなければならない
どちらのアプローチも扱いづらいものでした。
2013〜2014年頃：API Gateway の登場
この課題を解決するために登場したのが API Gateway です。マイクロサービスの前に薄いレイヤーを1つ置くことで、クライアントは再びモノリス時代のように「1つのエンドポイント」だけを知っていればよくなりました。
図3: API Gatewayを導入したマイクロサービスアーキテクチャ — クライアントはAPI Gatewayの1つのURLだけを知っていればよい
API Gateway の導入により、ルーティングの問題は解決しました。しかし、すぐに次の気づきが生まれます。各マイクロサービスに共通するボイラープレートが多いということです。
認証、レート制限、ログ収集、TLS終端——これらはどのサービスにも必要な処理ですが、各サービスが個別に実装していました。「この共通処理も API Gateway に集約できるのではないか」という発想は自然な帰結でした。
こうして、API Gateway はルーティングに加えて共通ミドルウェアの実行基盤としての役割も担うようになり、現在の姿に至っています。
API Gateway の内部構造 — リクエストはどう処理されるか
API Gateway の内部では、リクエストは4つのフェーズを経て処理されます。
図4: API Gatewayの内部処理フロー — リクエストは4つのフェーズを順番に通過する
フェーズ1: リクエスト検証（Request Validation）
受け取ったリクエストの形式を確認します。
- URLのフォーマットは正しいか
- 必須ヘッダー（
Content-Type、Authorization等）が含まれているか - リクエストボディが期待されたスキーマに合致するか
不正なリクエストはここで即座に拒否されます。バックエンドサービスに到達する前に弾くことで、不必要な負荷を防ぎます。
フェーズ2: ミドルウェア実行（Middleware）
検証を通過したリクエストに対して、共通の横断的処理を実行します。
| ミドルウェア | 処理内容 | 外部依存 |
|---|---|---|
| TLS 終端 | HTTPS → HTTP の変換。バックエンドは平文で通信可能に | 証明書ストア |
| 認証（Authentication） | JWT トークンの検証、OAuth トークンの確認 | 認証サービス |
| レート制限（Rate Limiting） | 単位時間あたりのリクエスト数を制御 | Redis 等のカウンタストア |
| ログ・メトリクス収集 | リクエスト/レスポンスのログ記録、レイテンシ計測 | ログ基盤 |
| CORS 処理 | Cross-Origin Resource Sharing ヘッダーの付与 | — |
| IP 制限 | 許可/拒否リストに基づくアクセス制御 | — |
ここで重要なのは、ミドルウェアの中には外部サービスへのリクエストを伴うものがあるという点です。たとえば、レート制限のチェックでは Redis へ問い合わせを行い、認証では外部の Auth サービスにトークンの検証を依頼します。
すべてのリクエストがこのフェーズを通過するため、各ミドルウェアのレイテンシはシステム全体のパフォーマンスに直結します。
フェーズ3: ルーティング（Routing）
API Gateway の最も本質的な責務です。リクエストのパスに基づいて、適切なバックエンドサービスに転送します。
ルーティングはシンプルな設定ファイルで定義されるのが一般的です。
routes:
- path: /users/*
service: user-service
port: 8080
- path: /orders/*
service: order-service
port: 8081
- path: /messages/*
service: message-service
port: 8082
- path: /payments/*
service: payment-service
port: 8083
/users/123 というリクエストが来たら user-service:8080 に転送する。/orders/456 なら order-service:8081 に転送する。この設定ファイルを変更するだけでルーティングを変えられるため、バックエンドサービスの再デプロイは不要です。
フェーズ4: レスポンス変換（Response Transformation）
バックエンドサービスからのレスポンスを、クライアントが期待する形式に変換して返します。
特に重要になるのがプロトコルの変換です。バックエンドサービス間の通信に gRPC を使い、外部クライアントには REST（JSON）を返すというパターンは現代のマイクロサービスでは一般的です。
クライアント ←[REST/JSON]→ API Gateway ←[gRPC/Protobuf]→ Backend Service
API Gateway がこのプロトコル変換を担うことで、クライアントはバックエンドの通信プロトコルを意識する必要がなくなります。また、レスポンスの圧縮やフィールドのフィルタリングもこのフェーズで行われることがあります。
API Gateway が解決する5つの課題
ここまでの内容を整理すると、API Gateway は以下の5つの課題を解決しています。
1. エンドポイントの一元化
クライアントは1つのURLだけを知っていればよい。サービスの追加・削除・URLの変更がクライアントに影響しない。
2. 横断的関心事の集約
認証、レート制限、ログ、TLS 終端といった共通処理をサービスごとに実装する必要がなくなる。各チームはビジネスロジックに集中できる。
3. プロトコル変換
外部向けは REST、内部は gRPC といった異なるプロトコルの橋渡しをする。
4. ルーティングの柔軟性
設定ファイルの変更だけでルーティングを変えられる。カナリアリリースや Blue-Green デプロイメントの実現にも活用できる。
5. セキュリティの境界
外部からのリクエストが最初に到達する「門番」として機能し、不正なリクエストをバックエンドに到達させない。
主要な API Gateway ソリューション
マネージドサービス
| サービス | プロバイダ | 特徴 |
|---|---|---|
| Amazon API Gateway | AWS | Lambda 統合が強力。REST / WebSocket / HTTP API の3タイプ |
| Azure API Management | Microsoft Azure | ポリシーベースの制御、開発者ポータル機能 |
| Cloud Endpoints | Google Cloud | OpenAPI 仕様ベース、ESP（Extensible Service Proxy）利用 |
マネージドサービスの利点は運用負荷の低さです。スケーリング、可用性、パッチ適用をクラウドプロバイダに任せられます。一方で、カスタマイズの自由度やベンダーロックインの観点ではトレードオフがあります。
オープンソース
| ソリューション | ベース技術 | 特徴 |
|---|---|---|
| Kong | NGINX / OpenResty | プラグインエコシステムが豊富。Lua でカスタムプラグイン開発が可能 |
| Tyk | Go | GraphQL ネイティブサポート。ダッシュボードUIが充実 |
| Express Gateway | Node.js (Express) | JavaScript エコシステムとの親和性が高い |
| APISIX | NGINX / etcd | 動的ルーティング、プラグインのホットリロード対応 |
オープンソースの利点はカスタマイズ性と透明性です。自社の要件に合わせて細かく調整できる反面、運用・監視・アップデートは自チームの責任になります。
API Gateway と Service Mesh の違い
API Gateway と混同されがちな概念に Service Mesh があります。両者の違いを整理しておきます。
| 観点 | API Gateway | Service Mesh |
|---|---|---|
| 対象の通信 | 外部クライアント → 内部サービス（North-South） | 内部サービス間（East-West） |
| 配置 | サービス群の前段に1つ（または少数） | 各サービスにサイドカーとして付随 |
| 主な責務 | ルーティング、認証、レート制限、プロトコル変換 | サービス間の暗号化、リトライ、サーキットブレーカー |
| 代表的なツール | Kong, AWS API Gateway, Tyk | Istio, Linkerd, Consul Connect |
簡潔に言えば、API Gateway は「外からの入口」を管理し、Service Mesh は「中の通信」を管理するものです。大規模なマイクロサービスアーキテクチャでは、両者を組み合わせて使うのが一般的です。
実務での設計ポイント
API Gateway はステートレスに保つ
API Gateway 自体にビジネスロジックやセッション状態を持たせてはいけません。ステートレスであることで、水平スケーリングが容易になります。ロードバランサーの背後に複数の API Gateway インスタンスを並べ、リクエストをラウンドロビンで分散させるのが基本パターンです。
単一障害点にしない
API Gateway はすべてのリクエストが通過する場所であるため、ここがダウンするとシステム全体が停止します。以下の対策が必要です。
- 複数インスタンスの冗長構成 — 最低2台以上で稼働させる
- ヘルスチェック — 異常なインスタンスを自動的にロードバランサーから切り離す
- グレースフルデグラデーション — 一部のミドルウェア（例：メトリクス収集）が失敗してもリクエスト自体は通す
ミドルウェアのレイテンシに注意する
すべてのリクエストがミドルウェアを通過するため、各ミドルウェアのレイテンシ増加がシステム全体に波及します。特に外部サービスへの問い合わせ（認証サービス、Redis 等）は、キャッシュの活用やコネクションプールの最適化でレイテンシを最小化する必要があります。
ルーティング設定の管理
ルーティング設定は、サービスの追加・削除に伴って頻繁に変更されます。設定のバージョン管理と、変更時の影響範囲の把握が重要です。設定ファイルを Git で管理し、CI/CD パイプラインで自動デプロイするアプローチが一般的です。
所見 — 「門番」の進化と今後
ミドルウェア開発者から見た API Gateway
私自身、データベースミドルウェアの開発に携わっている立場から見ると、API Gateway はアプリケーション層のミドルウェアとして非常に興味深い存在です。
ScalarDB がデータベースアクセスの複雑さを隠蔽するように、API Gateway はマイクロサービスの複雑さを隠蔽します。どちらも「裏側の複雑さをクライアントに見せない」という同じ設計思想に基づいています。そして、どちらも「薄いレイヤーであるべき」という原則を共有しています。API Gateway にビジネスロジックを詰め込み始めると、かつてのモノリスと同じ問題が再発します。
AI エージェント時代の API Gateway
昨今の AI エージェントの台頭は、API Gateway の役割にも影響を与えるかもしれません。AI エージェントが複数のマイクロサービスを横断的に呼び出すケースでは、API Gateway がエージェントのリクエストを認証し、適切にレート制限をかけ、必要なサービスにルーティングする——という従来の役割がそのまま適用されます。
さらに、MCP（Model Context Protocol）のようなプロトコルが普及すれば、API Gateway が REST/gRPC だけでなく MCP のプロトコル変換を担う可能性もあります。外部の AI エージェントからのリクエストを MCP で受け取り、内部のサービスには REST や gRPC で転送する。API Gateway のプロトコル変換機能は、こうした新しいプロトコルの登場にも対応できる柔軟な設計が求められるでしょう。
まとめ
- API Gateway は、マイクロサービスアーキテクチャにおいてクライアントとバックエンドサービスの間に位置する「門番」
- モノリス → マイクロサービスへの移行に伴い、エンドポイントの一元化と共通ミドルウェアの集約のために登場した
- 内部では リクエスト検証 → ミドルウェア実行 → ルーティング → レスポンス変換 の4フェーズでリクエストを処理する
- Service Mesh とは役割が異なる。API Gateway は外部→内部（North-South）、Service Mesh は内部間（East-West）の通信を管理する
- 実務ではステートレス設計、冗長構成、ミドルウェアのレイテンシ管理が重要な設計ポイント
- マネージドサービス（AWS API Gateway 等）とオープンソース（Kong, Tyk 等）の選択は、運用負荷とカスタマイズ性のトレードオフ
マイクロサービスアーキテクチャにおいて API Gateway は「あって当たり前」の存在ですが、その役割と設計原則を正しく理解しておくことは、システム全体の品質を左右する重要なポイントです。
参考リンク
- API Gateways in System Design Interviews w/ Ex-Meta Staff Engineer — Hello Interview（YouTube）
- API Gateway Deep Dive — Hello Interview
- Kong Gateway — 公式ドキュメント
- Amazon API Gateway — AWS ドキュメント
執筆者紹介 / 会社情報
執筆者
深津 航（ふかつ わたる）
株式会社Scalar 代表取締役CEO、Co-Founder。名古屋大学大学院 人間情報学研究科修了。日本オラクルで18年間データベース領域の技術・営業に従事した後、決済スタートアップを経由した後、2017年にScalarを共同創業。データベースミドルウェア ScalarDB、改ざん検知ソフトウェア ScalarDL の事業を推進しつつ、AI活用方法を社内外に発信しています。
会社情報
Scalar, Incは、「データマネジメントの未来を創る」を掲げ、データベースミドルウェアの研究開発・販売を行う日本発のグローバルスタートアップ企業です!
複数の異なるデータベース（RDB、NoSQLなど）を仮想的に統合し、トランザクション処理や分析クエリを実現するデータベースミドルウェアであるScalarDB、分散台帳技術（DLT）を用いたソフトウェアで、データの改ざん検知を行うScalarDLを主な製品としています。
是非下記の弊社サイトもチェックをお願いします！
Discussion