API Gatewayとは｜役割・主要サービス比較と設計のポイント

API Gatewayとは何か

API Gatewayは、クライアントとバックエンドサービスの間に立つ中継役です。すべてのAPIリクエストがまずGatewayに届き、そこで認証や流量制御を通過してから、本来の処理を担うサービスへ転送されます。

CNCFの用語集でも、APIゲートウェイは複数のバックエンドサービスへの単一の入口として位置づけられています。

なぜクライアントを直接つながせないのか

サービスが1つしかないうちは、Gatewayを挟む意味はあまりありません。問題が出るのは、バックエンドが複数に割れたときです。

クライアントが各サービスに直接つなぐ構成では、認証ロジックをサービスの数だけ実装することになります。エンドポイントが変わればクライアント側の修正も必要です。Microsoftのアーキテクチャガイドでも、この直接通信とGatewayパターンの比較がマイクロサービスの設計指針として整理されています。

入口を1つにまとめると、横断的な処理を一箇所で面倒を見られます。これがGatewayを置く最大の動機です。

なお、そもそもサービスを分割すべきかという判断は別の話です。分割の是非はマイクロサービスとは｜モノリスとの違い・採用判断・案件動向を解説を参照してください。

API Gatewayが担う主な機能

製品によって粒度は変わりますが、だいたい次の機能が載っています。

認可の仕組みそのものを理解しておくと設計判断が速くなります。トークンの流れはOAuth 2.0とは｜認可の仕組み・4つのグラントとPKCEを解説で補完できます。

ミニFAQ：Gatewayを入れるとレイテンシは悪化しないのか

1ホップ増えるぶん、理屈の上では増えます。オーバーヘッドの大きさは構成次第で、マネージド製品では小さく収まることが多い一方、認証方式・統合先・キャッシュの有無によっては無視できない場合もあります。ベンチマーク値を一般化できる領域ではないため、Gatewayのメトリクスでレイテンシを分解して自分の構成で測るのが先です。

ロードバランサー・リバースプロキシ・サービスメッシュとの違い

結論から言うと、4つは競合ではなく責務の層が違う部品です。実務では併用します。混同したまま「Gatewayを入れたからロードバランサーは不要」と判断すると、可用性の設計が抜けます。

責務の対応表

この表が示すとおり、分かれ目は「何を単位として制御するか」です。ロードバランサーはリクエストを振り分ける側で、どのAPIキーがどれだけ叩いたかには関心がありません。API Gatewayはそこに踏み込みます。

リバースプロキシとしてnginxを使っている現場なら、設定次第でGatewayに近い役割をある程度は持たせられます。前提となる挙動はnginxとは？仕組み・基本設定・Apacheとの違いをフリーランスエンジニア視点で解説で確認できます。

南北トラフィックと東西トラフィック

サービスメッシュとの違いは、トラフィックの向きで覚えると忘れません。

外部クライアントとシステムの間を流れるのが南北（North-South）トラフィック。ここを守るのがAPI Gatewayです。クラスタ内のサービス同士を流れるのが東西（East-West）トラフィックで、ここを担うのがサービスメッシュになります。

ただし境界は完全にきれいではありません。Istioのようにingress gatewayを持つ製品は、入口の機能も一部兼ねます。メッシュ側の詳細はIstioとは｜サービスメッシュの仕組み・Kubernetes運用での役割を解説に委ねます。

同期的なAPI呼び出しそのものを減らす設計を検討しているなら、イベント駆動アーキテクチャとは｜同期APIとの違いと採用判断も選択肢に入ります。

主要なAPI Gatewayサービスを比較する

マネージドとセルフホストで性格が分かれます。以下は執筆時点で各社の公式ドキュメントから確認できる位置づけを整理したものです。料金や機能は改定されるため、採用前に公式ページで最新の内容を確認してください。

AWS：Amazon API Gateway

AWSには、HTTP API・REST API・WebSocket APIという3つのAPIタイプがあります。両者の機能差はAWS公式のHTTP APIとREST APIの比較にまとまっています。

ざっくりした使い分けは次のとおりです。APIキー・使用量プラン・レスポンスキャッシュ・リクエスト検証のいずれかが要件に入るならREST API。入らないならHTTP APIで足ります。料金はHTTP APIのほうが抑えられる体系になっており、リージョンによって単価が異なるため公式の料金ページで対象リージョンの数字を確認してください。

バックエンドにLambdaを置く構成が定番です。この組み合わせの基礎はAWS Lambdaとは？特徴・できること・料金・フリーランス案件の単価をエンジニア視点で解説を参照してください。全体像はAmazon API Gatewayの公式ドキュメントが出発点になります。

Google Cloud：API GatewayとApigee

Google Cloudには、軽量なAPI Gatewayと、フルセットのAPI管理プラットフォームであるApigeeの2系統があります。

前者はCloud RunやCloud Functionsの前に置いて、OpenAPI仕様からルーティングと認証を構成する用途に向きます。後者は開発者ポータル、アナリティクス、APIの収益化まで含むため、APIを社外に提供して事業にするフェーズで候補になります。小さく始めるなら前者、という切り分けで実務上はだいたい足ります。

Google Cloud全体の構成要素はGCPとは｜Google Cloud主要サービス・AWSとの違い・案件単価に整理があります。

Azure：API Management

Azure API Managementは、ゲートウェイ・管理プレーン・開発者ポータルを束ねた構成です。Microsoft Learnの概要ページで各コンポーネントの役割が説明されています。

特徴はポリシーベースの制御で、認証・変換・流量制御をXMLのポリシー定義として記述します。ティアによって使える機能とSLAが変わるため、選定時はまずティア比較から入るのが実務的です。

OSS・セルフホスト：Kong、Envoy

クラウドに依存しない構成にしたい、あるいはオンプレと併用するなら、Kongのようなセルフホスト型が選択肢になります。Kongの公式ドキュメントにプラグイン方式の設計が記載されています。

Kubernetes上で動かす前提なら、Gateway APIリソースとして扱う構成も一般的です。基盤側の理解はKubernetesとは？仕組み・Dockerとの違い・フリーランス案件の単価をエンジニア視点で解説で補えます。

ミニFAQ：CDNがあればAPI Gatewayは不要ですか

役割が違うため、置き換えにはなりません。CDNはキャッシュと配信の最適化が主目的で、APIキーごとのクォータ管理は守備範囲外です。実際には、CDNを最前段に置いてGatewayをその後ろに配置する構成がよく採られます。CDN側の挙動はCloudFrontとは｜AWSのCDNの仕組み・料金・案件単価をエンジニア向けに解説を参照してください。

ケース別の選定フロー

要件から逆算すると、候補は意外と早く絞れます。

ケース1：サーバーレスAPIを数本公開したい

Lambda、Cloud Run、Azure Functionsのいずれかが土台なら、同じクラウドのマネージドGatewayを素直に選ぶのが近道です。AWSならHTTP API。認証やカスタムドメインを含まない最小構成なら、検証環境での初期構築が数時間から1日程度で済むこともあります。ここで多機能な製品を持ち込むと、運用対象が無駄に増えます。

ケース2：社外のパートナーにAPIを提供する

APIキーの発行、利用量の可視化、ドキュメント配布が要件に入ります。開発者ポータルを持つApigeeやAzure API Managementが候補です。AWSで揃えるならREST APIの使用量プランで対応できます。

公開APIの仕様管理には定義ファイルが要ります。OpenAPIとは｜Swaggerとの違い・仕様書の書き方と運用が実務の下敷きになります。

ケース3：Kubernetes上のマイクロサービス

入口はIngressコントローラやGateway API実装、内部通信はサービスメッシュ、という二段構えが定番です。入口に何を置くかはクラスタの運用方針次第で、Envoyベースの製品を使う構成がよく見られます。

ケース4：すでにnginxで捌いている

APIキー管理も流量制御も不要なら、無理に入れ替える理由はありません。判断材料は「利用者ごとの制御が必要になったか」です。必要になった時点で検討すれば十分間に合います。

API Gateway設計のポイント

タイムアウト上限を最初に確認する

これが設計で最も刺さりやすい制約です。

Amazon API Gatewayの統合タイムアウトは既定で29秒です。この上限を超えるとHTTP 504が返ります。2024年6月のアップデートで引き上げが可能になりましたが、AWSの告知のとおり条件があります。

LLM推論やバッチ生成のように応答が長引く処理をAPIの裏に置く設計では、ここを先に潰しておかないと後半で作り直しになります。手順はAWS公式のナレッジ記事に記載があります。

29秒で収まらない処理は、そもそも同期APIにしないという判断もあります。ジョブを受け付けてIDを返し、結果はポーリングか通知で渡す形です。

レート制限はデフォルト値から設計する

Amazon API Gatewayのアカウントレベルのスロットリングは、公式のクォータ表によると既定で10,000リクエスト/秒、バースト5,000リクエストです。一部リージョンでは2,500リクエスト/秒、バースト1,250と低く設定されています。

このアカウント単位の上限と、APIごと・利用者ごとの上限は別物です。多くの事故は後者を設定し忘れて、特定の利用者がアカウント全体の枠を食い潰すところで起きます。

認証をどこに置くか決める

入口で検証を済ませるのが基本ですが、全部をGatewayに寄せると今度は権限判定がGatewayの設定に埋まります。実務では、トークンの正当性検証はGateway、リソース単位の細かい認可はサービス側という分け方に落ち着くことが多くなります。ただし、OPAのような集中認可基盤を持つ構成では配置が変わるため、例外もあります。

設定をIaCで管理する

コンソールで手編集したGatewayは、環境差分の再現ができません。ステージングと本番で挙動が違うという相談の多くはここが原因です。Terraformなどで定義を管理し、変更をレビュー対象に含めてください。

ミニFAQ：GraphQLを使う場合もAPI Gatewayは要りますか

必要になるケースが多いです。エンドポイントは1本でも、認証・流量制御・ログの要件は変わらないためです。ただしパス単位のルーティングは効かないので、制御の粒度が落ちる点は意識してください。GraphQLとは？REST APIとの違い・メリット・案件動向・将来性をフリーランス視点で解説に前提の整理があります。

よくある失敗と対策

Gatewayにビジネスロジックを入れて肥大化させる

変換機能が便利なので、少しずつロジックが入り込みます。気づくとGatewayの設定を読まないと仕様がわからない状態になり、テストもしづらくなります。

対策はシンプルで、Gatewayに置いてよいのは横断的関心事だけと最初に線を引くことです。認証、流量制御、ロギング、プロトコル変換まで。ドメイン判断が混じったら、それはサービス側の仕事です。

コストの見積もりを外す

リクエスト課金のため、トラフィックが読みにくいサービスでは見積もりがぶれます。特に、ヘルスチェックやポーリングのような定期リクエストは件数が積み上がります。

課金対象になるリクエストを洗い出し、ピーク時ではなく月間総数で試算してください。HTTP APIとREST APIで単価が違う点も効いてきます。

ステージとバージョニングを設計しないまま進む

後からAPIの破壊的変更が必要になったとき、逃げ道がなくなります。パスにバージョンを含めるか、ヘッダーで切り替えるかを先に決めておくと、移行期間に新旧を併存させられます。

可観測性を後回しにする

Gatewayは全リクエストが通る場所なので、ここのログ設計が運用の質を決めます。リクエストIDを発行してバックエンドへ伝播させる設定を、初期構築の段階で入れてください。後付けは面倒です。

導入前チェックリスト

着手前にこの9項目を潰しておくと、手戻りがかなり減ります。

1. バックエンドの最長応答時間は何秒か。Gatewayのタイムアウト上限に収まるか

2. 収まらない場合、非同期化する余地はあるか

3. APIキーや使用量プランは必要か（必要ならHTTP APIでは足りない）

4. 利用者ごとのレート制限値を決めたか

5. 認証方式は何か。トークン検証をGatewayに寄せるか

6. 月間リクエスト総数の試算を出したか

7. ステージ（開発・検証・本番）の分け方を決めたか

8. 設定をIaCで管理する前提になっているか

9. アクセスログの出力先と保持期間を決めたか

フリーランス案件でのAPI Gatewayの扱われ方

公開案件ベースでは、API Gateway単独が主役の募集は多くなく、クラウドインフラ案件やバックエンド案件の要件の一部として書かれることが多くなります。アーキテクト層の非公開案件では扱いが変わる可能性もあるため、以下はあくまで公開案件に限った観測として読んでください。

本記事で触れる案件の傾向は、2026年10月時点で首都圏中心の主要フリーランスエージェント数社の公開案件ページを確認し、API GatewayやAPIマネジメントへの言及がある募集を観測ベースで整理したものです。公開案件に限った観測であり、非公開案件の条件は個別性が強いため別に考える必要があります。

公開案件を見る限りでは、次のような書かれ方が目立ちます。

• 「AWS（Lambda、API Gateway、DynamoDB）を用いたサーバーレス開発」という形で、構成要素の1つとして列挙される

• マイクロサービス移行案件で、入口の設計・移行担当として求められる

• 既存システムのAPI公開プロジェクトで、認証・流量制御の設計要員として求められる

単価レンジはAPI Gatewayの経験そのものではなく、クラウド設計の経験年数と担当範囲で決まる傾向があります。認証設計・IaC・監視設計・移行計画まで引き受けられる人ほど、実装のみを担当する場合より高めのレンジで提示されやすい傾向です。AWS案件の相場感はAWSエンジニア フリーランスの単価相場｜経験・案件レイヤー別に解説に整理があります。どのクラウドから手を広げるか迷っている場合はクラウド案件の参入順序｜AWS・Azure・GCPどれから取るかの判断軸が参考になります。

自分がいまどのくらいの単価を狙えるか確かめたい方は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。単価の上げ方を体系的に押さえるなら【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？も合わせてどうぞ。

まとめ

API Gatewayは、外部からのAPIリクエストを一箇所で受け止め、認証・流量制御・ルーティング・ログを横断的に処理する入口です。ロードバランサーの置き換えではなく、APIという単位での制御を足す部品だと捉えてください。

要点を整理します。

• 導入の判断軸は「バックエンドが複数か」「外部に公開するか」。単一サービスの社内利用なら急がなくてよい

• ロードバランサーは分散、Gatewayは外部との契約管理、サービスメッシュは内部通信。責務の層が違う

• サーバーレス中心ならHTTP API、APIキーや使用量プランが要るならREST API、外部提供や収益化まで見るならApigeeやAzure API Management

• Amazon API Gatewayの統合タイムアウトは既定29秒。引き上げは最大300秒だが、リージョン別・プライベートのREST APIに限られる

• Gatewayに置くのは横断的関心事だけ。ビジネスロジックが入り始めたら設計を見直す

次の一歩としては、手元のクラウドで検証用のGatewayを1つ立て、既存のAPIを1本だけ裏に置いてみてください。タイムアウトとレート制限の挙動を実際に見ておくと、設計レビューでの判断がかなり速くなります。

参照した一次情報は以下のとおりです。

• Amazon API Gateway とは何ですか？（AWS公式ドキュメント）

• HTTP API と REST API の選択（AWS公式ドキュメント）

• Amazon API Gateway の料金（AWS公式）

• 統合タイムアウトの上限引き上げに関する告知（AWS公式）

• REST API のクォータ一覧（AWS公式ドキュメント）

• API ゲートウェイ パターンとクライアントからマイクロサービスへの直接通信（Microsoft Learn）

• Azure API Management の概要（Microsoft Learn）

• Google Cloud API Gateway ドキュメント

• Apigee ドキュメント（Google Cloud）

• Kong Gateway ドキュメント

• APIゲートウェイ（CNCF Glossary）