>
>
公開日
最終更新日
API GatewayはAPIへのリクエスト受付や認証・監視を一元管理する際に配置します。複数のクラウド、社内基幹システム、外部サービスへ個別に公開口を作ると、認証方式、アクセスログ、障害時の制御が分散し、情シス部門での統制が難しくなります。
この記事では、情報システム部門のインフラ・API担当者が導入判断に使えるよう、API Gatewayとは何か、ALB・リバースプロキシ・サービスメッシュとの役割分担、Amazon API Gateway・Kong・Apigee・Azure API Managementの使いどころを解説します。AWS API GatewayのHTTP APIとREST APIのタイムアウト差、セキュリティ設計、PoCの進め方まで扱います。
この記事で確認したこと（確認日: 2026年03月28日）：各製品の公開情報、AWSの制限事項、IPAとデジタル庁の公開資料、国内企業の導入事例を確認しました。
API Gatewayとは？仕組みと役割分担
本記事のポイント
API Gatewayは、API公開に必要な認証、流量制御、監査ログを集約します。
ALBは負荷分散、リバースプロキシは通信中継、サービスメッシュはサービス間通信の統制を主な役割とします。
AWS中心ならAmazon API Gateway、複数環境を横断して統制するならKongなど、配置先と運用モデルから選定します。
長時間処理を同期APIに載せる設計はタイムアウト障害につながるため、非同期化を前提に判断します。
受付と制御の流れ
API Gatewayとは、クライアントアプリケーションからのAPIリクエストを単一の入口で受け、条件に応じてバックエンドへ配送する層です。パス、HTTPメソッド、ヘッダー、利用者の権限などを基に、Lambda、コンテナ、社内システム、外部SaaSのAPIへルーティングします。入口でJWTやOAuth 2.0のトークンを検証し、IP制限、レート制限、アクセスログの記録を行えるため、各バックエンドに同じ横断機能を重複実装する必要が減ります。
IPAは2022年に公開した資料で、API利用側と提供側の間にAPIゲートウェイを置き、API開発支援機能やAPI監視機能を組み合わせる構成を解説しています。社内外へAPIを増やすほど、個別サーバーではなく入口でポリシーを管理する効果が大きくなります。IPAのAPI連携に関する公開資料では、このようなAPI連携基盤の考え方を確認できます。
周辺コンポーネントとの役割分担
API GatewayとALBは代替関係ではありません。ALBは主にHTTP/HTTPSの負荷分散とターゲットへの振り分けを担い、同一アプリケーションを複数台で稼働させる構成に向きます。API Gatewayは利用者ごとの認可、利用量制御、APIキー、仕様公開、監査ログなど、API公開の統制に向きます。外部公開APIで利用者別の制御が必要ならAPI Gatewayを前段に置き、背後のコンテナ群をALBで分散する構成も取れます。
リバースプロキシはクライアントの代理としてバックエンドへ通信を中継する広い概念です。Nginxなどで基本的なTLS終端やパス振り分けを行うだけならリバースプロキシで足ります。一方、API利用申請、認証ポリシー、流量上限、開発者ポータルまで管理するならAPI管理機能を持つ製品が適します。サービスメッシュはKubernetesなどの内部サービス間通信でmTLS、再試行、可観測性を提供する仕組みであり、外部公開の入口を担うAPI Gatewayとは配置目的が異なります。
API管理とAI利用の動向
API GatewayはAPI管理の一部です。API管理には、Gatewayによる実行時制御に加え、APIの設計標準、OpenAPI仕様の管理、公開申請、利用分析、廃止手順などが含まれます。日本のAPI管理市場について、IMARC Groupは2025年に9億5,340万米ドルと評価し、2026年から2034年の年平均成長率を16.37％と見込んでいます。IMARC Groupの日本API管理市場レポート
AIエージェントやMCPサーバーを業務システムへ接続する場合も、APIの入口で利用者、呼出先、上限回数、監査ログを分けて管理する考え方は有効です。ただし、プロンプトインジェクションの検知はAPI Gateway単体の標準機能ではありません。AI向けの検査機能やポリシーエンジンと分担し、Gatewayでは認証、到達先制御、利用量記録を担わせます。GraviteeはGartnerの調査として、マルチモデルアプリケーションを構築するチームでのAI Gateway採用率が2025年の25％から2028年には70％へ上昇するという予測を紹介しています。この数値はGraviteeによる紹介に基づくものであり、Gartnerの一次資料を直接参照した場合と内容が異なる可能性があります。GraviteeによるGartner予測の紹介
▲ API Gatewayが単一の入口となり、認証やルーティングを一元管理する全体像
主要API Gateway製品の比較と使いどころ
自社のインフラ基盤とマルチクラウド構成に応じて製品を選定します。
製品名だけで決めるのではなく、APIをどこで稼働させるか、認証基盤を何に統一するか、誰が基盤を運用するかを同じ軸で比較します。以下は代表的な4製品の判断材料です。料金はリクエスト数、データ転送量、配置形態、追加機能で変わるため、見積り時には対象リージョンと必要機能を固定して比較します。
製品 | 主な配置環境 | 運用モデル | 認証・統制の軸 | 使いどころ | 設計上の注意点 |
|---|---|---|---|---|---|
Amazon API Gateway | AWS上 | フルマネージド | IAM、Lambda認可、JWT認可、WAF連携 | AWSのLambda、ECS、他AWSサービスを公開する場合 | API種別ごとの制限と従量課金を事前に検証します。 |
Kong Gateway | クラウド、オンプレミス、Kubernetes | セルフ運用またはマネージド提供 | プラグインによる認証、流量制御、監査 | 複数クラウドやオンプレミスを同じ方針で統制する場合 | クラスタ運用、プラグイン管理、アップグレードの担当を決めます。 |
Apigee | Google Cloud、ハイブリッド構成 | マネージドとハイブリッド | APIプロダクト、分析、利用者管理 | 外部パートナー向けAPIを事業として管理・分析する場合 | 公開APIのライフサイクルと契約・利用者管理を合わせて設計します。 |
Azure API Management | Azure、セルフホステッドGateway | マネージドとハイブリッド | Microsoft Entra ID、ポリシー、開発者ポータル | Microsoft基盤の認証・API公開を統一する場合 | ネットワーク接続方式とGateway配置場所を先に決めます。 |
基盤別の選定基準
AWS上のサーバーレスAPIを短期間で公開し、サーバー管理を持ち込みたくない場合はAmazon API Gatewayが候補になります。LambdaやECS、他AWSサービスとの責任分界を先に整理すると、Gatewayの役割を過大にせず設計できます。詳細はAWSの基礎やAWSサービスの整理も参照してください。
オンプレミスの基幹系と複数クラウドをまたぎ、同じ認証・ログ・レート制限を適用したい場合は、Kong、Apigee Hybrid、Azure API ManagementのセルフホステッドGatewayなどを比較します。デジタル庁はエリアデータ連携基盤の推奨モジュールで、API GatewayとしてKong Gatewayを定めています。これは特定用途の推奨ですが、自治体・地域データ連携のように複数組織をまたぐAPI統制で検討材料になります。デジタル庁のエリアデータ連携基盤の推奨モジュール
認証方式と公開範囲の判断
社内利用だけでネットワーク境界が明確なAPIでも、利用者やシステムごとの権限を追跡したいなら、短期トークンによる認可と監査ログを組み合わせます。外部パートナーAPIでは、OAuth 2.0やOpenID Connectを用いて利用者の本人性と権限を分け、APIキーだけを認可の根拠にしない設計が適します。Microsoft Entraのアクセストークンなど、有効期限があるトークンを使う場合は、期限切れ時の再取得とバックエンド側の検証を含めて設計します。
▲ 自社のインフラ環境と運用モデルに応じた主要API Gatewayの選定フロー
Amazon API Gatewayの特徴と国内導入事例
AWS基盤とサーバーレス構成を組み合わせることで管理コストを大幅に削減できます。
AWSサービス連携の特性
Amazon API Gatewayは、APIの作成、公開、保護、監視をAWS上で管理するフルマネージドサービスです。バックエンドとしてAWS Lambdaを含むFaaSを使う場合、リクエストの増減に応じたサーバー台数の管理を減らせます。既存サービスとの接続では、API連携の設計に沿って、同期処理と非同期処理、認証情報の受け渡し、障害時の再試行範囲を分けます。
HTTP APIは軽量なAPI公開とJWT認可を中心に構成したい場合に向き、REST APIは利用量プラン、APIキー、キャッシュ、より細かな変換・制御が必要な場合に検討します。WebSocket APIは接続を維持してサーバーから結果を通知する用途に使います。利用中の機能がHTTP APIで足りるか、REST API固有機能が必要かをPoCで確認できれば、不要な運用・コストを抑えられます。
朝日新聞社の移行事例
朝日新聞社は編集者向けシステムで、Amazon EC2を用いた構成からAmazon API GatewayとAWS Lambdaを使う構成へ移行しました。マネーフォワード Adminaが公開した事例では、同社はEC2構成と比較して開発・インフラ維持コストを約99％削減したと紹介されています。成果は、常時稼働するサーバーを持つ構成から、利用量に応じるサーバーレス構成へ変えたことによるもので、すべてのAPIで同率の削減を見込める意味ではありません。朝日新聞社のAmazon API Gateway活用事例
同事例から情シス部門が転用できる判断は、アクセス量が低い時間帯も固定費が発生する既存APIを洗い出し、状態を持たない処理から移行対象にすることです。逆に、長時間接続、特殊なネットワーク要件、常時高負荷の処理は、Gateway導入と同時にサーバーレス化する対象なのかを個別に分けます。
日テレWandsの連携事例
クラスメソッドが公開した事例では、日テレWandsはオンプレミスの会計システムとクラウド上の請求書受領システムを連携する基盤にAmazon API Gatewayを採用しています。ここでの焦点は、基幹システムを直接インターネットへ公開せず、APIの入口で接続先と認証を制御することです。日テレWandsのAPI Gateway活用事例
導入判断を進める選定フロー
既存APIのトラフィック、公開範囲、認証、処理時間を可視化してから限定PoCへ進むと、製品比較が具体化します。
API Gateway導入を「製品を入れる案件」として始めると、後から認証基盤やログ保管要件が見つかり、設計がやり直しになります。以下の順に判断材料を集めます。
棚卸し：公開中・公開予定のAPIについて、呼出元、呼出先、月間リクエスト数、平均・最大応答時間、扱うデータ区分を一覧化します。
境界の決定：外部公開、社内公開、システム間専用を分け、インターネット公開APIにはWAF、認証、レート制限、監査ログを必須要件として置きます。
PoC：代表APIを1本選び、認証失敗、流量超過、バックエンド障害、ログ検索、設定変更の承認までを検証します。
移行判断：監査ログを必要期間取得でき、障害時に呼出元とバックエンドを特定できるなら対象APIを段階移行します。取得できない場合はログ基盤や認証連携を先に補います。
PoCで使う確認チェックリスト
PoCでは成功応答だけを確認しても本番設計にはなりません。次の項目を検証結果として残すと、運用開始後の責任分界が明確になります。
誰がAPI仕様、認証設定、レート制限を変更できるか。
401、403、429、5xxの各応答を監視でき、通知先を決められるか。
アクセスログに利用者、リクエストID、送信先、応答時間を関連付けられるか。
障害時にGateway、ネットワーク、バックエンドのどこで失敗したかを切り分けられるか。
OpenAPI仕様と実装の差分を検知し、廃止APIの期限を管理できるか。
IPAの「安全なウェブサイトの作り方」は、SQLインジェクション、OSコマンド・インジェクション、クロスサイト・スクリプティングなど11種類の脆弱性を解説しています。Gatewayで認証や流量を制御しても、バックエンドの入力値検証を省略してはいけません。IPA「安全なウェブサイトの作り方」
▲ 手戻りを防ぎ安全に導入を進めるための4段階の選定・移行ステップ
導入時の注意点と失敗パターン
バックエンドのレスポンス遅延によるタイムアウトエラー対策が設計の要です。
HTTP APIとREST APIのタイムアウト差
Amazon API Gatewayのタイムアウトを「全種類で29秒固定」と扱うのは誤りです。AWSの公式ドキュメントでは、HTTP APIの統合タイムアウト上限は30秒固定であり、引き上げはできません。一方、Regional REST APIおよびPrivate REST APIでは、デフォルト29秒から引き上げる仕組みをAWSが案内しています。ただし、引き上げにはアカウントレベルのスロットリングクォータを下げるトレードオフがあり、利用可能な値や対象はAWSのクォータで判断します。AWS公式のAmazon API Gatewayクォータと制限
したがって、29秒を超える可能性がある処理でHTTP APIを使う場合は、同期応答を前提にしません。REST APIで上限緩和を検討する場合も、単に待ち時間を延ばすのではなく、同時実行数とスロットリングへの影響を測定します。対象のAPI種別、エンドポイント種別、統合方式によって使える設定が変わるため、提供状況はAWS公式のクォータ情報を基にPoC時点で確認します。
長時間処理の回避設計
重い集計、ファイル変換、AI推論をAPI Gatewayから同期的に実行し、完了まで接続を待たせる設計は失敗しやすいパターンです。処理受付時には202 AcceptedとジョブIDを返し、SQSなどのキューに処理を渡します。利用者側はジョブ状態を取得するAPIを呼ぶか、完了時にWebSocketで通知を受けます。結果取得用APIを別にすると、タイムアウト、再試行、重複実行を分けて制御できます。
セキュリティ制御の過信
API GatewayだけでSQLインジェクションや不正なHTTPヘッダーを完全に防ぐことはできません。API公開面にはWAFを連携し、Gatewayでは認証・認可、レート制限、送信先制限を担当させ、アプリケーションでは入力値検証と出力エンコードを行います。IPAはHTTPレスポンス分割に関する脆弱性をCWE-113として案内しており、ヘッダーをバックエンドで組み立てるAPIでは改行文字を含む入力を検証対象に含めます。IPAのHTTPレスポンス分割に関する解説
よくある質問
API Gatewayの使いどころで迷いやすい論点を、構成判断に使える形で整理します。
ALBとの違い
Q. API GatewayとALBの違いは何ですか？
A. ALBは主に複数のアプリケーションサーバーやコンテナへ負荷を分散するためのサービスです。外部利用者ごとの認可、APIキー、利用量制限、API公開の監査を一元化するならAPI Gatewayを使い、背後の処理を複数台へ分散するならALBを組み合わせます。
HTTP APIとREST APIの違い
Q. Amazon API GatewayのHTTP APIとREST APIはどちらを選びますか？
A. JWT認可を使う軽量なAPI公開やコストを抑えた構成ならHTTP APIから検討します。利用量プラン、APIキー、キャッシュ、細かなリクエスト変換が必要ならREST APIを比較し、HTTP APIの統合タイムアウト上限が30秒で収まるかも判断条件にします。
WAF連携の判断
Q. API Gatewayを導入すればWAFは不要ですか？
A. 不要にはなりません。認証済みの利用者からの不正入力や既知のウェブ攻撃にも備えるため、外部公開APIではWAFと連携し、バックエンドでも入力値検証を行う多層防御にします。
まとめ
API Gateway導入では、まず既存APIを公開範囲、認証方式、応答時間、ログ取得可否で棚卸しします。そのうえで外部公開APIを1本選び、認証失敗、流量超過、バックエンド障害、監査ログ検索までをPoCで検証します。AWS中心の構成ならAmazon API Gateway、複数環境を横断するならKongや各クラウドのハイブリッド構成を比較します。HTTP APIで30秒を超える処理が見つかった場合は、API種別の変更より先に、202 Acceptedとキューを使う非同期設計へ切り替えます。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
橋爪兼続
ライトハウスコンサルタント代表。2013年海上保安大学校本科第Ⅲ群（情報通信課程）卒業。巡視船主任通信士を歴任し、退職後、大手私鉄の鉄道運行の基幹システムの保守に従事。一般社団法人情報処理安全確保支援士会の前身団体である情報処理安全確保支援士会の発起人。情報処理安全確保支援士(第000049号)。
