>
>
公開日
最終更新日
API GatewayはAPIへのリクエスト受付や認証・ルーティングを一元管理するミドルウェアです。
社内システム、クラウド、外部パートナー向けAPIの公開口を個別に設けると、認証方式、アクセス制限、ログ保管、障害対応の基準が分散します。情報システム部門（情シス）・インフラ開発の導入検討担当者は、API Gatewayを単なる通信中継ではなく、API公開の統制点として設計する判断軸が必要です。
本記事では、APIゲートウェイの仕組み、ALB・リバースプロキシ・サービスメッシュとの役割分担、Amazon API GatewayのHTTP APIとREST APIの違い、WAFによる多層防御、主要製品の比較を解説します。長時間処理のタイムアウトや、APIキーを認可の根拠にしてしまう失敗も扱います。
この記事で確認したこと（確認日: 2026年03月28日）：AWSの公開クォータ、IPA・デジタル庁の公開資料、API管理市場の調査、国内企業の公開導入事例を確認しました。
API Gatewayとは？仕組みと役割分担
API GatewayとはAPIリクエストの一括受領・認証・ルーティングを一元管理する基盤です。
本記事のポイント
API Gatewayは、API公開時の認証・認可、流量制御、監査ログを入口に集約します。
ALBは負荷分散、リバースプロキシは通信中継、サービスメッシュは内部通信の統制を主目的とします。
AWS中心ならAmazon API Gateway、複数クラウドやオンプレミスを横断するならKongなどを比較します。
30秒を超える可能性がある処理は、同期APIではなく非同期処理として設計します。
APIリクエストの受付と制御
API Gatewayは、Webアプリ、モバイルアプリ、外部サービス、社内システムから届くAPIリクエストを単一の入口で受け、パス、HTTPメソッド、利用者の権限、ヘッダーなどに応じてバックエンドへ配送します。接続先はLambda、コンテナ、オンプレミスの基幹システム、外部SaaSなどです。
入口でアクセストークンを検証し、利用者やシステムごとに呼出先を制限します。OAuth 2.0は認可の枠組みであり、実際のアクセストークン検証はJWT署名検証、トークンイントロスペクション、認可サーバー連携など構成により異なります。APIキーは利用者識別や利用量管理には使えますが、単独で認可の根拠にはしません。
API数が増えるほど、個々のバックエンドで認証やログを重複実装するより、入口のポリシーを統一する方が変更履歴と監査対象を追跡しやすくなります。
ALBとの役割分担
ALBとの違いは、ALBが主にターゲットへの負荷分散とヘルスチェックを担い、API GatewayがAPI利用者単位の統制を担う点です。
ALBは、複数のEC2やコンテナへHTTP/HTTPS通信を振り分け、障害中のターゲットを除外する用途に向きます。ALBはOIDCやAmazon Cognitoを使ったリスナールール単位の認証機能も備えていますが、外部利用者ごとのAPI利用量管理、APIキーによる識別、利用者別の細かな認可制御、API公開の監査ログ集約といった管理機能はAPI Gatewayの守備範囲です。
外部公開APIでは、API Gatewayを入口に置き、その背後にあるコンテナ群への負荷分散をALBに担わせる構成を取れます。単一アプリケーションの負荷分散だけならALBで足りますが、外部パートナーごとに権限、上限回数、利用ログを分ける場合はAPI Gatewayを追加します。
リバースプロキシとサービスメッシュの役割
リバースプロキシは通信中継、サービスメッシュは内部サービス間通信の統制に適します。
NginxなどのリバースプロキシはTLS終端、パスベースの振り分け、基本的なキャッシュに利用できます。ただし、API仕様の公開、利用者登録、利用量分析、APIライフサイクル管理までを標準機能として持つとは限りません。APIを少数の社内システムに中継するだけならリバースプロキシでも構成できます。
サービスメッシュは、Kubernetesなどで稼働するサービス間通信にmTLS、再試行、分散トレーシングを適用する仕組みです。外部クライアントからの入口を統制するAPI Gatewayと、内部のサービス間通信を統制するサービスメッシュは、競合ではなく併用対象です。
API管理の市場動向
API Gatewayは実行時の制御を担い、API管理は設計標準、公開申請、利用分析、廃止管理まで含む広い領域です。
OpenAPI SpecificationはRESTful APIの事実上の標準として広く参照されており、API Gateway導入時にOpenAPI仕様を管理対象に含めると、仕様と実装の差分、廃止予定API、利用者への変更通知を運用手順に組み込めます。
Straits Researchは、世界のAPI管理市場を2025年に90億7,000万米ドルと評価し、2026年から2034年に年平均16.58％で成長すると予測しています。AI利用の有無にかかわらず、呼出元、到達先、利用量、監査ログをAPI単位で管理する実務上の意義は変わりません。
▲ API Gatewayを中心としたリクエスト受付・制御とバックエンド連携の全体構成
主要API Gateway製品の比較と使いどころ
自社のインフラ基盤と運用モデルに合わせて製品を選定します。
製品比較では、機能数だけでなく、APIをどこで動かすか、誰がポリシーとGatewayを運用するか、閉域接続が必要か、開発者ポータルを使うかを同じ軸で確認します。料金はリクエスト数、データ転送、リージョン、追加機能で変動するため、利用条件をそろえずに月額だけを比較しても判断できません。
製品 | 主な配置環境 | 運用モデル | 統制・公開機能 | 開発者ポータル | 適する条件 |
|---|---|---|---|---|---|
Amazon API Gateway | AWS | フルマネージド | IAM、JWT認可、Lambda認可、スロットリング、監視 | 別途設計が必要 | AWSのLambda、ECS、AWSサービスを中心に公開する場合 |
Kong Gateway | クラウド、オンプレミス、Kubernetes | セルフ運用またはマネージド | プラグインによる認証、流量制御、分析 | 製品構成により利用可能 | 複数クラウドとオンプレミスを同じ方針で統制する場合 |
Apigee | Google Cloud、ハイブリッド | マネージド、ハイブリッド | APIプロダクト、分析、利用者管理 | 利用可能 | 外部パートナー向けAPIを事業基盤として管理する場合 |
Azure API Management | Azure、セルフホステッドGateway | マネージド、ハイブリッド | Microsoft Entra ID、ポリシー、分析 | 利用可能 | Microsoft基盤の認証とAPI公開を統一する場合 |
クラウド基盤別の選定軸
AWS上のサーバーレスAPIを短期間で公開し、Gatewayサーバーの保守を持ち込みたくない場合はAmazon API Gatewayが候補になります。AWSサービスとの認証、ネットワーク、監視の責任分界を既存のAWS運用に寄せられるためです。
オンプレミスの基幹システムと複数クラウドをまたぐ場合は、Kong、Apigee Hybrid、Azure API ManagementのセルフホステッドGatewayを比較対象に含めます。複数組織・複数システムを横断するAPI統制においてKong Gatewayが採用される事例があり、複数クラウドとオンプレミスを横断する構成を検討する際の参考になります。
Kong Konnectの構成では、SaaS側にControl Plane、顧客環境側にData Planeを分離して置けます。実行トラフィックを自社環境に残しつつ、管理機能をSaaSで利用したい場合は、この管理面と実行面の分離が要件に合うかを検証します。
可用性と運用責任の比較
フルマネージド型は基盤の可用性管理をサービス提供者に委ねやすく、セルフ運用型は配置場所と拡張方式を自社で設計できます。
ただし、セルフ運用型ではクラスタの冗長化、バージョン更新、プラグインの脆弱性対応、証明書更新まで運用範囲に含まれます。Kong Gatewayは公式仕様としてノード当たり50,000トランザクション/秒の処理能力を示していますが（数値はKong社公式ドキュメントを採用時点で直接確認し、測定条件が自社構成と一致するかを確かめてください。条件が異なる場合は実測値を採用します）、実効性能はプラグイン数、認証処理、ログ転送、ネットワーク構成に左右されます。性能値だけで採否を決めず、実際の認証・ログ設定を含めた代表トラフィックで測定します。
選定時に固定する比較条件
見積もりとPoCでは、公開範囲、認証、ログ、障害対応の4条件を先に固定します。
外部公開か社内限定かを区分し、閉域接続やWAF連携の有無を決めます。
JWT検証、認可サーバー連携、APIキーによる利用量管理のどれが必要かを整理します。
監査ログの保管先、保管期間、個人情報や機密情報のマスキング方針を決めます。
障害時に誰がGateway設定、ネットワーク、バックエンドを切り分けるかを運用表に残します。
開発者ポータルで外部利用者に仕様、申請、鍵発行、変更通知を提供する場合は、ポータルの多言語対応や承認フローも評価対象です。ポータルが不要で、社内の限られたシステム連携だけなら、API仕様を社内リポジトリで管理する構成の方が運用を小さくできます。
Amazon API Gatewayの機能比較と国内導入事例
AWS環境ではHTTP APIとREST APIの機能差とコストを理解して選択します。
Amazon API Gatewayは、APIの作成、公開、保護、監視をAWS上で管理するフルマネージドサービスです。Lambda、コンテナ、AWSサービス、HTTPバックエンドをAPIとして公開できます。最初にHTTP APIで必要機能を満たせるかを確認し、REST API固有の機能が必要な場合にREST APIを選ぶと、構成と料金の理由を説明しやすくなります。
HTTP APIとREST APIの比較
HTTP APIは軽量・低価格のAPI公開向けであり、REST APIは利用量プランやキャッシュなどの追加機能が必要なAPI向けです。
比較項目 | HTTP API | REST API |
|---|---|---|
主な用途 | JWT認可を使う軽量なHTTP API、Lambda・HTTPバックエンド連携 | 高度なAPI公開、利用者別の利用量管理、細かな変換が必要なAPI |
認可 | JWTオーソライザー、Lambdaオーソライザーなど | IAM、Lambdaオーソライザー、Cognito、APIキーなど |
利用量プランとAPIキー | 利用量プランおよびAPIキー機能はHTTP APIでは利用できません | 利用量プランとAPIキーを利用できます |
キャッシュ | 標準機能としては対象外です | ステージキャッシュを利用できます |
統合タイムアウト | 上限30秒で固定です | デフォルト29秒で、Regional・Privateでは緩和の仕組みがあります |
東京リージョンのリクエスト料金例 | 最初の3億リクエストで100万件当たり1.29米ドル | 最初の3億3,300万リクエストで100万件当たり4.25米ドル |
料金例はリクエスト課金のみであり、データ転送、キャッシュ、ログ、WAF、Lambdaなどの周辺費用は別に発生します。月間リクエスト数が少なくても、ログ量やセキュリティサービスの費用が総額を左右するため、見積もりではGatewayだけを切り出しません。HTTP APIとREST APIの料金・提供機能は変更され得るため、採用時点ではAWS公式の「Amazon API Gateway料金」ページで対象リージョンとAPI種別の単価・クォータを直接確認し、必要機能を満たせる場合はそのAPI種別でPoCに進み、満たせない場合は要件に合う代替構成を比較します。
HTTP APIの適用条件
HTTP APIは、30秒以内に応答でき、JWT認可と基本的なルーティングで要件を満たすAPIに適します。
モバイルアプリ向けの参照API、Webhook受信、Lambdaを呼び出すBFF、社内サービスの軽量な公開口では、HTTP APIの低いリクエスト単価が有効です。Amazon API Gateway HTTP APIのバックエンドペイロードのクォータは10MBです。大容量ファイルを同期APIで受け渡す用途は、API Gatewayを経由せずオブジェクトストレージへの直接アップロードと短期URL発行に分ける構成を検討します。
REST APIの適用条件
REST APIは、利用者別の利用量プラン、APIキー、キャッシュ、より細かなリクエスト変換が必要なAPIに適します。
外部パートナーへAPIを提供し、契約ごとに呼出上限を設ける場合は、REST APIの利用量プランが判断材料になります。ただし、APIキーは利用者を識別し利用量を制御するための情報であり、機密性の高いAPIへのアクセス権をAPIキーだけで判定する構成にはしません。OAuth 2.0やOpenID Connectによるアクセストークンと組み合わせ、認可判断を分離します。
朝日新聞社の移行事例
朝日新聞社の事例は、常時稼働サーバーを持つ構成からサーバーレス構成へ移行した際の効果を示しています。
マネーフォワード Adminaは、朝日新聞社が編集者向けシステムをAmazon EC2構成からAmazon API GatewayとAWS Lambdaの構成へ移行し、開発・インフラ維持コストを約99％削減したと紹介しています（一次資料はマネーフォワード Adminaのブログ記事に基づくものであり、朝日新聞社による直接公開情報は別途確認が必要です）。この削減は、常時稼働するEC2を用いた構成から利用量に応じるサーバーレス構成へ変更したことを前提とする結果です。
したがって、同じ削減率を全APIに当てはめることはできません。アクセス量が低い時間帯にも固定費が発生しているAPIで、状態を持たず短時間で完結する処理なら、同様にサーバーレス化の効果を検討できます。長時間接続や常時高負荷の処理は、Gateway導入とサーバーレス移行を分けて評価します。
日テレWandsの連携事例
日テレWandsの事例は、基幹システムを直接公開せずAPIの入口で連携を制御する設計例です。
クラスメソッドが公開した事例では、日テレWandsはオンプレミスの会計システムとクラウド上の請求書受領システムを連携する基盤にAmazon API Gatewayを採用しています（本情報はクラスメソッドによる二次紹介であり、日テレWandsによる一次公開情報は別途確認が必要です）。公開情報では定量的な費用削減額は示されていませんが、オンプレミスとクラウドの間にAPIの制御点を置き、接続先と認証を分離する用途として参照できます。
▲ 要件に応じたAmazon API Gateway（HTTP API / REST API）の選定フロー
導入判断を進める選定フロー
既存APIの公開範囲、認証、応答時間、ログ取得可否を可視化してから限定PoCへ進みます。
API Gateway導入を製品調達から始めると、後から認証基盤、ログ保管、障害通知、閉域接続の要件が見つかり、設定を作り直すことになります。APIごとの要件を棚卸しし、最初のPoCでは成功応答だけでなく、失敗時の挙動と運用負荷を評価対象に含めます。
導入前の棚卸し
棚卸しでは、APIごとに呼出元、呼出先、認証、最大応答時間、データ区分を一覧化します。
公開範囲の分類：インターネット公開、パートナー限定、社内限定、システム間専用に分けます。
通信要件の記録：月間リクエスト数、ピーク時の毎秒リクエスト数、平均・最大応答時間、ペイロードサイズを記録します。
認証・認可の整理：認可サーバー、トークン形式、利用者単位の権限、APIキーの利用目的を明記します。
ログ要件の確定：利用者、リクエストID、送信先、応答時間、結果コードを関連付けて保存できるかを決めます。
日本では基盤導入そのものより、標準化・運用体制を含めた導入判断が課題になりやすい傾向が指摘されています。既存の認証方式とログ基盤を棚卸しに含めると、製品選定後の手戻りを減らせます。
PoCの評価項目
PoCでは、代表APIを1本選び、通常処理と異常処理の両方を記録して評価します。
検証項目 | 確認する内容 | 判断への反映 |
|---|---|---|
認証・認可 | 期限切れトークン、権限不足、無効なAPIキーの応答 | 利用者識別と認可が分離できなければ認証設計を見直します |
流量制御 | 上限超過時の429応答、バックエンド保護、再試行の挙動 | バックエンドを保護できなければスロットリング値を再設計します |
監査ログ | リクエストID、利用者、送信先、応答時間、5xxの追跡 | 障害を追跡できなければログ連携を先に補います |
障害切り分け | Gateway、ネットワーク、バックエンドのどこで失敗したか | 責任分界が不明なら監視項目と当番手順を追加します |
設定変更 | ポリシー変更の承認、履歴、ロールバック | 変更履歴を残せなければ本番移行の対象にしません |
公開APIが増える場合は、OpenAPI仕様の登録、レビュー、公開、非推奨化、廃止を同じ手順にします。仕様変更時に後方互換性を確認しないままパスやレスポンス形式を変えると、外部利用者の障害をGatewayでは防げません。
運用開始の判定基準
監査ログと障害切り分けの経路を確認できれば、対象APIを段階的に移行します。
運用開始前に、401、403、429、5xxの通知先と一次対応者を明文化します。Gatewayが返すエラーとバックエンドが返すエラーを同じ通知として扱うと、障害時に担当部署の切り分けが遅れます。利用者、API、送信先、リクエストIDで検索できるログが取得できるなら限定公開を開始し、取得できないならログ連携を整えてから公開範囲を広げます。
▲ 導入失敗を防ぐためのAPI Gateway棚卸しからPoC実施までの4ステップ
導入時の注意点と失敗パターン
タイムアウト対策とWAF連携による多層防御が設計の要となります。
API Gatewayは認証、ルーティング、流量制御を集約できますが、バックエンド処理の遅延、脆弱な入力値処理、過剰な権限設定まで自動で解決するものではありません。特に同期処理の時間上限と外部公開面の防御を初期設計で誤ると、公開後に利用者影響を伴う変更になります。
HTTP APIとREST APIのタイムアウト
HTTP APIの統合タイムアウト上限は30秒固定であり、30秒を超える処理を同期で返す用途には使えません。
Amazon API GatewayのHTTP APIは、統合タイムアウトを30秒より長く設定できません。一方で、REST APIのRegionalエンドポイントとPrivateエンドポイントはデフォルト29秒で、AWSは29秒を超える設定を可能にする仕組みを案内しています。上限緩和にはアカウントレベルのスロットリングクォータを下げるトレードオフがあるため、応答待ち時間だけを延ばす判断は適しません。
Lambdaのタイムアウトは最大15分まで設定できますが、API Gateway経由の同期呼出しではGateway側の上限が先に制約になります。処理完了まで数分かかる集計、ファイル変換、外部サービス応答待ちは、Lambdaの実行可能時間ではなくクライアントへの応答時間を基準に設計します。
長時間処理の非同期化
30秒以内に完了しない可能性がある処理は、202 AcceptedとジョブIDを返す非同期APIに分けます。
受付APIは処理要求を検証してキューへ登録し、クライアントにはジョブIDを返します。ワーカーはSQSなどからジョブを取得して実行し、利用者は状態取得APIで完了状況を参照します。即時通知が必要な場合は、WebSocketやコールバックの利用を別要件として設計します。
やってはいけないのは、タイムアウトが発生したクライアントが同じ重い処理を何度も再送できる構成です。ジョブIDと冪等性キーを持たせ、同じ要求の重複登録を防ぐことで、タイムアウト後の二重課金、二重更新、キュー滞留を抑えます。
WAFによる多層防御
外部公開APIでは、API Gatewayの認証・認可に加え、WAFとバックエンドの入力値検証を組み合わせます。
API Gatewayは、認証済み利用者から送られる不正なパラメータや既知のウェブ攻撃を完全に防ぐ層ではありません。WAFではIP制限、レートベースルール、既知の攻撃パターンへの対策を適用し、Gatewayではトークン検証、到達先制御、スロットリングを実施します。バックエンドでは型、桁数、許可文字、業務ルールを検証し、出力時には必要なエンコードを行います。
IPAは「安全なウェブサイトの作り方」で、SQLインジェクション、OSコマンド・インジェクション、クロスサイト・スクリプティングなどの脆弱性を解説しています。WAFを導入しても入力値検証を省略すると、許可済み経路や新しい攻撃手法からバックエンドに到達する余地が残ります。
対象・提供状況の確認範囲
認可方式、WAF連携、タイムアウト、利用量プランは、API種別、エンドポイント種別、リージョン、接続方式で差が出ます。
Amazon API GatewayのHTTP APIでは、バックエンドペイロードのクォータは10MBです。また、Lambda統合では統合リクエストにPOSTメソッドを使用する必要があります。設計したAPIがHTTP APIの機能・クォータで成立することを確認できればHTTP APIのPoCに進み、成立しなければREST API、非同期構成、ストレージ直接連携を比較します。この確認を要件定義に一度集約すると、公開直前のAPI種別変更を避けられます。
よくある質問
API Gatewayの選定で頻出する疑問に、構成判断に使える形で回答します。
ALBとの違い
Q. API GatewayとALBの違いは何ですか？
A. ALBは複数のサーバーやコンテナへの負荷分散とヘルスチェックを担い、API Gatewayは利用者別の認可・スロットリング・監査を入口に集約します。詳細は「ALBとの役割分担」セクションを参照してください。
HTTP APIとREST APIの選び方
Q. Amazon API GatewayのHTTP APIとREST APIはどちらを選びますか？
A. 機能要件と単価の比較軸は「HTTP APIとREST APIの比較」セクションの表で確認できます。JWT認可・30秒以内応答で十分な場合はHTTP API、利用量プランやキャッシュが必要な場合はREST APIが選択肢になります。
WAF連携の必要性
Q. API Gatewayを導入すればWAFは不要ですか？
A. 不要にはなりません。API Gatewayは認証・認可と呼出量制御を担い、WAFは既知のウェブ攻撃・IP制限・レートベースの防御を担います。「WAFによる多層防御」セクションで各層の役割を整理しています。
APIキーの扱い
Q. APIキーだけで外部APIを保護できますか？
A. APIキーは利用者識別や利用量管理に使えますが、単独で認可の根拠にはなりません。OAuth 2.0やOpenID Connectによるアクセストークンとの組み合わせ方は「REST APIの適用条件」セクションで説明しています。
まとめ
API Gatewayは、外部・社内を問わずAPI公開の入口に認証、認可、流量制御、監査ログを集約する基盤です。ALBは負荷分散、リバースプロキシは通信中継、サービスメッシュは内部通信の統制を担うため、目的に応じて併用します。AWS環境では、30秒以内の軽量APIならHTTP API、利用量プランやキャッシュが必要ならREST APIを比較します。
明日から始めるなら、公開中のAPIを呼出元、認証方式、最大応答時間、扱うデータ、ログ取得可否の5項目で一覧化します。そのうえで代表APIを1本選び、認証失敗、429、5xx、WAF遮断、タイムアウト時の挙動までPoCで確認します。30秒を超える処理が見つかった場合は、タイムアウト値を延ばす前に202 Acceptedとキューを使う非同期化へ切り替えます。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
橋爪兼続
ライトハウスコンサルタント代表。2013年海上保安大学校本科第Ⅲ群（情報通信課程）卒業。巡視船主任通信士を歴任し、退職後、大手私鉄の鉄道運行の基幹システムの保守に従事。一般社団法人情報処理安全確保支援士会の前身団体である情報処理安全確保支援士会の発起人。情報処理安全確保支援士(第000049号)。
