Amazon API Gateway 完全ガイド 2026

初心者から実務者向けの包括的解説

📚 公式ドキュメント・参考リソース

• API Gateway Developer Guide
• What is Amazon API Gateway
• API Gateway Pricing
• API Gateway Features
• API Gateway REST API Reference
• API Gateway WebSocket API Guide
• API Gateway Authorization & Authentication
• API Gateway VPC Link Configuration
• Serverless Application Model (SAM)
• AWS CDK API Gateway Construct Library

🎯 概要

Amazon API Gateway は 「フルマネージドの API 作成・公開・管理・保護・監視サービス」。バックエンド（Lambda・EC2・ALB・HTTP エンドポイント・AWS サービス）への統一的な API フロントエンドを提供し、REST API・HTTP API・WebSocket API・Private API の 4 タイプをサポート。

初心者向けメモ： API Gateway = 「玄関番」。クライアント（スマホアプリ・ブラウザ・外部システム）からのリクエストを受け取り、バックエンドへ正しくルーティングしながら、認証・スロットリング・ロギングを一括管理する。

🔧 API Gateway が解決する課題

⭐ 主な特徴

1. 複数の API タイプをサポート

• REST API：フル機能（キャッシュ・変換・プライベート API）
• HTTP API：軽量・高速・低コスト（JWT 認証中心）
• WebSocket API：リアルタイム双方向通信
• Private API：VPC 内限定アクセス

2. 柔軟な統合オプション

Lambda、HTTP、AWS サービス（SQS・SNS・Kinesis）、VPC Link、Mock 統合に対応

3. エンタープライズグレードのセキュリティ

• IAM / Cognito / Lambda Authorizer による認証・認可
• mTLS（クライアント証明書）対応
• WAF / Shield との統合
• 暗号化（転送中・保存時）

4. スロットリング・クォータ管理

API キー + 使用量プランで B2B API の商用提供が可能

5. 多角的なモニタリング

CloudWatch Logs、X-Ray、Access Log で詳細追跡

🏗️ アーキテクチャ

graph TB
    Client["クライアント<br/>(ブラウザ・モバイル・外部 API)"]
    
    Client -->|HTTP/HTTPS| APIGW["API Gateway<br/>(フロントエンド)"]
    
    APIGW -->|認証・スロットリング<br/>キャッシュ・変換| Auth["認証層<br/>- IAM<br/>- Cognito<br/>- Lambda Authorizer"]
    
    Auth --> Routes["ルーティング層"]
    
    Routes -->|Lambda Proxy| Lambda["Lambda<br/>関数"]
    Routes -->|HTTP 統合| HTTP["HTTP エンドポイント<br/>ALB・外部 API"]
    Routes -->|AWS Service| Service["AWS サービス<br/>SQS・SNS・Kinesis"]
    Routes -->|VPC Link| VPC["VPC リソース<br/>EC2・RDS Proxy"]
    Routes -->|Mock| Mock["モックレスポンス<br/>(開発用)"]
    
    Lambda --> Lambda_Logs["CloudWatch Logs"]
    APIGW --> X_Ray["X-Ray<br/>トレース"]
    APIGW --> Access_Log["Access Log"]
    
    style APIGW fill:#ff9933
    style Auth fill:#66b3ff
    style Lambda fill:#99ff99

📡 API タイプ詳細比較

REST API vs HTTP API vs WebSocket API vs Private API

初心者向けメモ： 新規構築なら HTTP API。既存マイクロサービスやキャッシュが必要なら REST API。リアルタイム通信なら WebSocket API。

⚔️ REST vs HTTP API 使い分けガイド

HTTP API を選ぶべき場合 ✅

• ✅ 新規マイクロサービス API 構築
• ✅ JWT / OAuth 2.0 認証が中心
• ✅ コスト最小化が優先
• ✅ レイテンシー最小化が必須
• ✅ Lambda バックエンド中心
• ✅ シンプルなルーティング

例：スタートアップの REST API、モバイルバックエンド、マイクロサービス間通信

REST API を選ぶべき場合 ✅

• ✅ キャッシング機能が必要
• ✅ リクエスト/レスポンス変換（VTL マッピングテンプレート）が必要
• ✅ 既存大規模システム
• ✅ API キー + 使用量プラン（B2B API 商用提供）
• ✅ Private API（VPC 内限定）
• ✅ 複雑なメディア型対応

例：Enterprise SaaS API、金融機関向け API、レガシーシステム統合

移行パターン

既存 REST API → HTTP API への移行チェックリスト
├── キャッシング不要？ ✅
├── VTL マッピング不要？ ✅
├── JWT 認証 OK？ ✅
├── 使用量プラン不要？ ✅
└── すべて ✅ なら HTTP API へ移行可能（70% コスト削減）

🎪 主要ユースケース（12+）

1. サーバーレス Web API バックエンド

モバイルアプリ / ブラウザ
    ↓ HTTPS
API Gateway REST API
    ↓ Lambda Proxy 統合
AWS Lambda
    ↓
DynamoDB / RDS

✅ メリット：サーバー管理不要、自動スケーリング、認証一元化 ❌ デメリット：Cold Start 対策必要

2. IoT デバイス連携

IoT デバイス（センサー）
    ↓ HTTP/MQTT
API Gateway HTTP API
    ↓
Lambda（データ変換）
    ↓
Amazon Kinesis → DynamoDB

✅ メリット：低レイテンシー、大量デバイス対応

3. モバイルバックエンド API

iOS/Android アプリ
    ↓ JWT トークン + API キー
API Gateway HTTP API
    ↓ Cognito User Pool オーソライザー
Lambda
    ↓
RDS Aurora / DynamoDB

✅ メリット：認証・レート制限・ログを一元管理

4. SaaS / マルチテナント API

複数テナント
    ↓ テナント ID + API キー
API Gateway REST API（使用量プラン）
    ↓
Lambda（テナント分離ロジック）
    ↓
RDS（テナント別 DB）

✅ メリット：API キー + クォータで課金管理、SLA 管理

5. 認証付き GraphQL API

GraphQL クライアント
    ↓ Authorization: Bearer {JWT}
API Gateway HTTP API
    ↓ Lambda Authorizer
Lambda（GraphQL リゾルバー）
    ↓ AWS AppSync（代替案）

✅ メリット：既存インフラで GraphQL を公開

6. API レート制限（DDoS 対策）

攻撃トラフィック
    ↓
API Gateway スロットリング
    ├── アカウントデフォルト：10,000 RPS
    ├── ステージ：1,000 RPS
    └── リソース：100 RPS
→ 429 Too Many Requests（攻撃を棄却）

✅ メリット：下流 Lambda・DB 保護

7. API Composition（マイクロサービス集約）

クライアント
    ↓ 1 つのリクエスト
API Gateway
    ├─→ 認証マイクロサービス
    ├─→ 注文マイクロサービス
    ├─→ 在庫マイクロサービス
    └─→ 支払いマイクロサービス
→ 集約レスポンス

✅ メリット：バックエンド複雑性をクライアント非表示化

8. PrivateLink による B2B API 連携

カスタマー VPC
    ↓ PrivateLink（AWS 専用ネットワーク）
API Gateway Private API
    ↓
プロバイダー側 Lambda

✅ メリット：VPN 不要、高セキュリティ B2B 連携

9. Webhook・Event Receiver

外部 SaaS（Stripe・GitHub）
    ↓ HTTP POST
API Gateway
    ↓
Lambda
    ↓
EventBridge → 他のサービス

✅ メリット：外部イベントの受信・ルーティング・処理を一元化

10. リアルタイムチャット・通知

ブラウザクライアント
    ↕ WebSocket (wss://)
API Gateway WebSocket API
    ├── $connect: 接続 ID を DynamoDB に保存
    ├── $default: メッセージをブロードキャスト
    └── $disconnect: DynamoDB からクリーンアップ

✅ メリット：双方向リアルタイム通信、Connection ID 管理

11. Multi-Region フェイルオーバー

Route 53 (Geolocation / Failover Routing)
    ├─→ API Gateway us-east-1
    └─→ API Gateway eu-west-1（フェイルオーバー）

✅ メリット：高可用性、レイテンシー最小化

12. ファイルアップロード・マルチパート対応

クライアント
    ↓ multipart/form-data
API Gateway REST API
    ↓
Lambda
    ↓
Amazon S3

✅ メリット：ファイル検証・変換・ウイルススキャン前処理

🔄 ルーティングと統合

統合タイプの詳細

1. Lambda Proxy 統合（推奨 ✅）

// API Gateway → Lambda 転送
{
  "requestContext": {
    "requestId": "id",
    "httpMethod": "POST",
    "path": "/orders"
  },
  "headers": { "Authorization": "Bearer token" },
  "body": "{\"amount\": 100}",
  "pathParameters": { "id": "123" },
  "queryStringParameters": { "filter": "active" }
}

// Lambda レスポンス
{
  "statusCode": 200,
  "headers": { "Content-Type": "application/json" },
  "body": "{\"orderId\": \"ORD-123\"}"
}

メリット：

• ✅ リクエスト全体を Lambda が受け取る
• ✅ キャッシング・ログ・トレース自動
• ✅ ステータスコード・ヘッダーを Lambda が制御

2. Lambda カスタム統合

マッピングテンプレート（VTL）でリクエスト・レスポンスを変換。複雑な統合時のみ使用。

## マッピングテンプレート例（リクエスト）
{
  "table": "orders",
  "id": "$input.params('id')",
  "amount": "$input.json('$.amount')"
}

3. HTTP 統合

外部 HTTP エンドポイント、ALB へのフォワード

• API Gateway → ALB → ECS

4. AWS Service 統合

SQS・SNS・Kinesis に直接リクエスト

• API Gateway → SQS（キューイング）
• → Lambda（非同期処理）

5. VPC Link 統合

API Gateway
    ↓ PrivateLink
VPC Link（ENI）
    ↓
ALB（VPC 内）
    ↓
ECS / EC2

6. Mock 統合

バックエンドなしでレスポンス返却（開発・テスト用）

// API Gateway マッピング
{
  "statusCode": 200,
  "body": "{\"status\": \"success\"}"
}

🔐 認証・認可

認証方式比較

実装例

Cognito User Pool オーソライザー

# クライアント側
import requests

token = cognito_idp.initiate_auth(
    ClientId='app_client_id',
    AuthFlow='USER_PASSWORD_AUTH',
    AuthParameters={'USERNAME': 'user@example.com', 'PASSWORD': 'pwd'}
)

response = requests.get(
    'https://api.example.com/orders',
    headers={'Authorization': f"Bearer {token['AuthenticationResult']['IdToken']}"}
)

# API Gateway は自動的に JWT を検証

Lambda Authorizer（カスタム認証）

def lambda_handler(event, context):
    token = event['authorizationToken']
    
    # トークン検証ロジック
    if is_valid_token(token):
        return {
            'principalId': 'user@example.com',
            'policyDocument': {
                'Version': '2012-10-17',
                'Statement': [
                    {
                        'Action': 'execute-api:Invoke',
                        'Effect': 'Allow',
                        'Resource': event['methodArn']
                    }
                ]
            },
            'context': {'userId': 'user@example.com'}
        }
    else:
        raise Exception('Unauthorized')

mTLS（クライアント証明書）

# API Gateway で mTLS を有効化
curl --cert client-cert.pem --key client-key.pem \
  https://api.example.com/secure

⏱️ スロットリングとクォータ

3 階層のスロットリング

┌─────────────────────────────────────────┐
│ アカウントレベル（デフォルト）           │
│ 10,000 RPS / バースト 5,000             │
└─────────────────────────────────────────┘
            ↓
┌─────────────────────────────────────────┐
│ ステージレベル                           │
│ 設定例：1,000 RPS / バースト 500        │
└─────────────────────────────────────────┘
            ↓
┌─────────────────────────────────────────┐
│ リソース・メソッドレベル                 │
│ 設定例：POST /orders = 100 RPS          │
└─────────────────────────────────────────┘
            ↓
┌─────────────────────────────────────────┐
│ 使用量プラン（API キーごと）             │
│ ├─ スロットリング制限                    │
│ └─ クォータ（日/週/月）                  │
└─────────────────────────────────────────┘

使用量プラン設定例

[使用量プラン：Premium]
  ├─ API キー：sk_live_xxxxx
  ├─ スロットリング：500 RPS
  ├─ バースト：250 req
  └─ クォータ：
      ├─ 日間：100,000 req
      ├─ 週間：500,000 req
      └─ 月間：10,000,000 req

初心者向けメモ： スロットリング = 「制限速度」。クォータ = 「1 か月の走行距離制限」。

💾 キャッシュ（REST API のみ）

クライアント リクエスト
    ↓
API Gateway（TTL チェック）
    ├─ キャッシュ有効 → キャッシュ返却（レイテンシー↓）
    └─ キャッシュ無効 → バックエンド呼び出し

キャッシュ設定

キャッシュメモリ：0.5 GB ～ 237 GB
キャッシュキー：
  ├─ リクエストヘッダー（デフォルト Authorization）
  ├─ クエリ文字列
  └─ ステージ

TTL：デフォルト 300 秒
無効化：Cache-Control: max-age=0 ヘッダー

使用例

# キャッシュ有効なレスポンス
def lambda_handler(event, context):
    return {
        'statusCode': 200,
        'headers': {
            'Cache-Control': 'max-age=300',  # 5 分キャッシュ
            'Content-Type': 'application/json'
        },
        'body': json.dumps({'data': 'cached'})
    }

コスト削減効果：頻繁にアクセスされるリソース（マスターデータ等）をキャッシュで 80%+ レスポンス時間短縮可能。

🚀 ステージとカナリアリリース

ステージ構成

dev ステージ
    ├─ API エンドポイント：https://xxx.execute-api.ap-northeast-1.amazonaws.com/dev
    ├─ Lambda エイリアス：dev
    └─ CloudWatch ロググループ：/aws/apigateway/dev

stg ステージ
    ├─ API エンドポイント：https://xxx.execute-api.ap-northeast-1.amazonaws.com/stg
    ├─ Lambda エイリアス：stg
    └─ CloudWatch ロググループ：/aws/apigateway/stg

prod ステージ
    ├─ API エンドポイント：https://api.example.com（カスタムドメイン）
    ├─ Lambda エイリアス：prod
    ├─ CloudWatch ロググループ：/aws/apigateway/prod
    └─ カナリアリリース設定：新バージョン 10% → 50% → 100%

カナリアデプロイ例

新バージョンを 10% のトラフィックで検証
    ├─ 異常なし → 25%
    ├─ 異常なし → 50%
    ├─ 異常なし → 100%
    └─ 本番環境で完全置き換え

メリット：本番環境でリスク最小化した段階的デプロイ

📊 ロギングとトレーシング

4 つのロギング方式

Access Log フォーマット例

$context.requestId $context.identity.sourceIp \
$context.identity.userAgent $context.requestTime \
$context.httpMethod $context.resourcePath \
$context.status $context.responseLength

X-Ray トレース

graph LR
    Client["クライアント<br/>latency: 200ms"]
    Client -->|100ms| APIGW["API Gateway<br/>latency: 50ms"]
    APIGW -->|80ms| Lambda["Lambda<br/>latency: 70ms"]
    Lambda -->|30ms| DDB["DynamoDB<br/>latency: 10ms"]

🛡️ WAF と Shield 連携

インターネット
    ↓ トラフィック
AWS Shield Standard（自動DDoS対策）
    ↓
AWS WAF（Web Application Firewall）
    ├─ IP レピュテーションリスト
    ├─ SQL インジェクション検出
    ├─ XSS 検出
    ├─ レート制限ルール
    └─ カスタムルール
    ↓
API Gateway
    ↓
Lambda / バックエンド

WAF ルール例

Block if:
  ├─ Source IP in "hostile IPs" list
  ├─ Body contains "OR 1=1" (SQL injection)
  ├─ More than 1000 req/5min from same IP
  └─ Geographic location outside allowed countries

🔗 VPC Link（Private Integration）

Private API アーキテクチャ

┌─────────────────────────────────────┐
│ VPC (10.0.0.0/16)                   │
│ ┌─────────────────────────────────┐ │
│ │ Private Subnet                  │ │
│ │ ├─ Lambda (private)             │ │
│ │ └─ ALB (private, 10.0.1.100)   │ │
│ └─────────────────────────────────┘ │
│         ↑                            │
│         │ VPC Endpoint (ENI)         │
│         │ (Interface Endpoint)       │
│ ┌─────────────────────────────────┐ │
│ │ VPC Link                        │ │
│ └─────────────────────────────────┘ │
└─────────────────────────────────────┘
         ↑
         │ PrivateLink (AWS 内部ネットワーク)
         │ (インターネット経由しない)
    ┌────────────────┐
    │ API Gateway    │
    │ (Private API)  │
    └────────────────┘
         ↑
    VPC 内のみアクセス可能
    (IAM リソースポリシー)

リソースポリシー設定

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "execute-api:Invoke",
      "Resource": "execute-api:/*",
      "Condition": {
        "StringEquals": {
          "aws:SourceVpc": "vpc-12345678"
        }
      }
    }
  ]
}

🎭 API Gateway vs 類似サービス比較

選択フロー

Lambda を HTTP で公開したい？
    ├─ YES → API Gateway
    │
複数のバックエンドをロードバランシング？
    ├─ YES → ALB
    │
グローバルキャッシング + エッジ配信？
    ├─ YES → CloudFront
    │
GraphQL が必須？
    ├─ YES → AppSync
    │
Simple Lambda エンドポイント（認証最小）？
    └─ YES → Lambda Function URL

🌍 SaaS API 公開パターン

マルチテナント API 例

Tenant A
    ↓ API Key: sk_A_xxxxx
    │
Tenant B ──→ API Gateway REST API（使用量プラン）
    │          ├─ API Key: sk_B_xxxxx
Tenant C       ├─ Throttling: 1000 RPS
    ↓          ├─ Quota: 10M req/月
    └────→  Lambda
                ├─ テナント ID 抽出（API Key から）
                ├─ テナント分離ロジック
                └─ RDS 接続（テナント別 DB）

API ティア化（Freemium モデル）

API Gateway 使用量プラン
    ├─ Free Tier
    │   ├─ Throttling：100 RPS
    │   └─ Quota：10,000 req/月
    │
    ├─ Pro Tier
    │   ├─ Throttling：1,000 RPS
    │   └─ Quota：1,000,000 req/月
    │
    └─ Enterprise Tier
        ├─ Throttling：10,000 RPS
        └─ Quota：Unlimited

🔀 他の API Gateway との比較

🛠️ クライアントとエコシステム

インフラストラクチャ as Code

AWS SAM（Serverless Application Model）

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31

Globals:
  Function:
    Timeout: 20

Resources:
  MyAPI:
    Type: AWS::Serverless::Api
    Properties:
      StageName: prod
      Auth:
        DefaultAuthorizer: MyCognitoAuth
        Authorizers:
          MyCognitoAuth:
            UserPoolArn: !GetAtt MyUserPool.Arn

  MyFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: src/
      Handler: app.lambda_handler
      Runtime: python3.11
      Events:
        ApiEvent:
          Type: Api
          Properties:
            RestApiId: !Ref MyAPI
            Path: /orders/{id}
            Method: GET

AWS CDK

from aws_cdk import (
    aws_apigateway as apigw,
    aws_lambda as lambda_,
    core,
)

class MyAPIStack(core.Stack):
    def __init__(self, scope: core.Construct, id: str, **kwargs):
        super().__init__(scope, id, **kwargs)
        
        # Lambda 関数
        handler = lambda_.Function(
            self, 'Handler',
            runtime=lambda_.Runtime.PYTHON_3_11,
            handler='index.handler',
            code=lambda_.Code.from_asset('lambda')
        )
        
        # API Gateway
        api = apigw.RestApi(
            self, 'MyAPI',
            rest_api_name='My API'
        )
        
        # リソース + メソッド
        orders = api.root.add_resource('orders')
        orders.add_method('POST', apigw.LambdaIntegration(handler))
        
        # 認証
        auth = apigw.CognitoUserPoolsAuthorizer(
            self, 'auth',
            cognito_user_pools=[user_pool]
        )
        orders.add_method('GET', apigw.LambdaIntegration(handler), authorizer=auth)

Terraform

resource "aws_apigatewayv2_api" "main" {
  name          = "my-api"
  protocol_type = "HTTP"
  
  cors_configuration {
    allow_origins = ["*"]
    allow_methods = ["GET", "POST", "PUT", "DELETE"]
    allow_headers = ["*"]
  }
}

resource "aws_apigatewayv2_stage" "prod" {
  api_id      = aws_apigatewayv2_api.main.id
  name        = "prod"
  auto_deploy = true
}

resource "aws_apigatewayv2_integration" "lambda" {
  api_id           = aws_apigatewayv2_api.main.id
  integration_type = "AWS_PROXY"
  integration_method = "POST"
  payload_format_version = "2.0"
  
  integration_response_selection_expression = "$default"
}

開発者ツール

⚡ ベストプラクティス

1. API 設計

✅ Do

• RESTful 設計（リソース中心）
• バージョニング（/v1/orders）
• 一貫した命名規則
• エラーレスポンスの標準化

// 標準エラーレスポンス
{
  "error": {
    "code": "INVALID_REQUEST",
    "message": "Missing required parameter: amount",
    "details": {
      "field": "amount",
      "issue": "must be positive integer"
    }
  }
}

❌ Don’t

• RPC スタイル（/getOrders）
• バージョニングなし
• 一貫性のないレスポンス形式
• エラーの詳細不足

2. 認証・認可

✅ Do

• Cognito User Pool（ユーザー向け）
• Lambda Authorizer（カスタム認可）
• mTLS（B2B）
• API キー + 使用量プラン（課金）

❌ Don’t

• API キーを認証として使用
• Basic Auth（平文）
• ハードコード認証情報

3. パフォーマンス

✅ Do

• HTTP API を優先（新規）
• キャッシング（頻繁アクセス）
• 圧縮（レスポンス）
• 非同期処理（長時間操作）

# 非同期処理の例
import json
import boto3

sqs = boto3.client('sqs')

def lambda_handler(event, context):
    # 即座にクライアントにレスポンス
    sqs.send_message(
        QueueUrl='https://sqs.ap-northeast-1.amazonaws.com/xxx/jobs',
        MessageBody=json.dumps(event['body'])
    )
    
    return {'statusCode': 202, 'body': 'Processing'}

❌ Don’t

• 大型レスポンス（>6MB）
• N+1 クエリ
• 同期的な長時間処理
• キャッシング設定なし

4. セキュリティ

✅ Do

• HTTPS のみ
• WAF + Shield
• リソースポリシー（Private API）
• CloudTrail ロギング
• 定期的なアクセス権監査

// WAF ルール例
{
  "Name": "BlockSQLInjection",
  "Priority": 1,
  "Action": { "Block": {} },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "SQLInjectionMetric"
  },
  "Statements": [
    {
      "ManagedRuleGroupStatement": {
        "VendorName": "AWS",
        "Name": "AWSManagedRulesSQLiRuleSet"
      }
    }
  ]
}

❌ Don’t

• HTTP（非暗号化）
• 認証なし
• ログ記録なし
• デフォルトセキュリティ設定

5. 運用

✅ Do

• CloudWatch Alarms（エラー率・レイテンシー）
• X-Ray トレーシング
• 定期的なキャパシティ計画
• 段階的デプロイ（カナリア）

# CloudWatch Alarm 例（boto3）
cloudwatch = boto3.client('cloudwatch')

cloudwatch.put_metric_alarm(
    AlarmName='API-Error-Rate-High',
    MetricName='5XXError',
    Namespace='AWS/ApiGateway',
    Statistic='Sum',
    Period=300,
    EvaluationPeriods=1,
    Threshold=100,
    ComparisonOperator='GreaterThanThreshold',
    AlarmActions=['arn:aws:sns:ap-northeast-1:123456789:alert']
)

❌ Don’t

• ロギング無視
• 本番で未テストデプロイ
• アラーム設定なし
• 容量計画なし

🐛 トラブルシューティング

一般的な問題と対応

CloudWatch Logs 分析

# API Gateway ログをフィルタ
aws logs filter-log-events \
  --log-group-name /aws/apigateway/prod \
  --filter-pattern "[statusCode >= 400]" \
  --start-time $(date -d '1 hour ago' +%s)000

X-Ray で分散トレース

from aws_xray_sdk.core import xray_recorder
from aws_xray_sdk.core import patch_all

patch_all()  # Lambda・boto3 自動計測

@xray_recorder.capture('process_order')
def process_order(order_id):
    # この関数の実行時間・エラーが X-Ray に記録される
    return order_service.get(order_id)

🚀 2025-2026 最新動向

HTTP API 機能拡充

• ✅ JWT 認可をネイティブサポート
• ✅ OIDC プロバイダー統合
• ✅ リクエスト/レスポンス変換（限定）

mTLS サポート強化

• ✅ Private API での mTLS 標準化
• ✅ 証明書 rotation の自動化

Private REST API 機能強化

• ✅ Interface Endpoint 経由でのアクセス最適化
• ✅ PrivateLink との統合深化

AI Agent との統合

• ✅ Amazon Bedrock Agent Core との連携
• ✅ API Gateway → Lambda → Bedrock のシームレス統合

クライアント
    ↓
API Gateway
    ↓
Lambda（API orchestration）
    ↓
Amazon Bedrock Agent
    ├─ Claude / Mistral / Llama2
    └─ API Gateway を使った外部ツール呼び出し

📖 学習リソース

初心者向け

• AWS API Gateway チュートリアル（公式）
• API Gateway + Lambda ハンズオン
• Udemy「AWS API Gateway マスターコース」

中級者向け

• API Gateway ベストプラクティス（AWS Black Belt）
• マイクロサービスアーキテクチャ設計
• 認証・認可パターン集

上級者向け

• API Gateway パフォーマンス最適化
• Multi-Region API アーキテクチャ
• SaaS API の設計・運用

💻 実装例・活用シーン

例 1：Lambda + DynamoDB サーバーレス API

import json
import boto3

dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('orders')

def lambda_handler(event, context):
    method = event['httpMethod']
    
    if method == 'GET':
        # GET /orders/{id}
        order_id = event['pathParameters']['id']
        response = table.get_item(Key={'id': order_id})
        return {
            'statusCode': 200,
            'body': json.dumps(response.get('Item', {}))
        }
    
    elif method == 'POST':
        # POST /orders
        body = json.loads(event['body'])
        table.put_item(Item=body)
        return {
            'statusCode': 201,
            'body': json.dumps({'id': body['id']})
        }

例 2：Cognito 認証付き API

def lambda_handler(event, context):
    # API Gateway が認証済みの context を渡す
    user_id = event['requestContext']['authorizer']['claims']['sub']
    
    # ユーザー固有のデータ返却
    return {
        'statusCode': 200,
        'body': json.dumps({
            'userId': user_id,
            'role': event['requestContext']['authorizer']['claims']['cognito:groups'][0]
        })
    }

例 3：WebSocket リアルタイムチャット

import json
import boto3

apigw_management = boto3.client('apigatewaymanagementapi', endpoint_url='...')
ddb = boto3.resource('dynamodb')
connections = ddb.Table('websocket-connections')

def connect(event, context):
    """接続時"""
    connection_id = event['requestContext']['connectionId']
    connections.put_item(Item={'connectionId': connection_id})
    return {'statusCode': 200}

def send_message(event, context):
    """メッセージ送信"""
    connection_id = event['requestContext']['connectionId']
    message = json.loads(event['body'])
    
    # 全接続者にブロードキャスト
    response = connections.scan()
    for item in response['Items']:
        apigw_management.post_to_connection(
            ConnectionId=item['connectionId'],
            Data=json.dumps(message)
        )
    
    return {'statusCode': 200}

def disconnect(event, context):
    """切断時"""
    connection_id = event['requestContext']['connectionId']
    connections.delete_item(Key={'connectionId': connection_id})
    return {'statusCode': 200}

🗺️ 導入ロードマップ

Phase 1: 基礎構築（週 1-2）
├─ REST API 作成
├─ Lambda Proxy 統合
└─ 基本認証（API キー）

Phase 2: セキュリティ強化（週 3-4）
├─ Cognito User Pool 統合
├─ WAF ルール追加
└─ CloudTrail ロギング

Phase 3: パフォーマンス最適化（週 5-6）
├─ HTTP API への移行検討
├─ キャッシング設定
└─ X-Ray トレーシング

Phase 4: スケール・信頼性（週 7-8）
├─ 使用量プラン（B2B API）
├─ カナリアデプロイ
├─ Multi-Region フェイルオーバー
└─ SLA 監視・アラーム

Phase 5: 高度な統合（週 9+）
├─ API Composition
├─ Private API / VPC Link
├─ GraphQL（AppSync）
└─ AI Agent 統合

✅ 実装チェックリスト

API 設計
  ☐ RESTful 設計に基づいているか
  ☐ リソース中心のパス設計
  ☐ 適切なステータスコード
  ☐ エラーレスポンス標準化
  ☐ API バージョニング戦略

統合
  ☐ Lambda Proxy 統合を使用
  ☐ VTL 変換を最小化
  ☐ 非同期処理は SQS 経由

認証・認可
  ☐ Cognito User Pool 統合
  ☐ Lambda Authorizer でカスタム認可
  ☐ API キー + 使用量プラン設定
  ☐ リソースポリシー（Private API）

パフォーマンス
  ☐ HTTP API を優先検討
  ☐ レスポンス圧縮を有効化
  ☐ キャッシング設定（REST API）
  ☐ CloudFront キャッシュ検討

セキュリティ
  ☐ HTTPS のみ
  ☐ WAF ルール適用
  ☐ CloudTrail ロギング
  ☐ アクセスログ記録

運用
  ☐ CloudWatch Alarms 設定
  ☐ X-Ray トレーシング有効化
  ☐ ステージ分離（dev/stg/prod）
  ☐ カナリアデプロイ計画
  ☐ 容量計画・スケーリング
  ☐ ディザスタリカバリ計画

📌 まとめ

Amazon API Gateway は AWS のフルマネージド API フロントエンド。

• 新規構築：HTTP API（安い・速い）を基本
• 既存システム：REST API で高度な機能（キャッシュ・変換）を活用
• リアルタイム：WebSocket API で双方向通信
• 内部 API：Private API で VPC 限定アクセス

セキュリティ・信頼性・スケーラビリティを AWS が全面管理。Cognito 認証 + WAF + スロットリング + カナリアデプロイで本番 API のエンタープライズ基準を実現できる。

📚 参考文献

AWS 公式ドキュメント（2026 年版）

1. AWS API Gateway Official Documentation
2. API Gateway Pricing
3. What is Amazon API Gateway
4. API Gateway REST API Reference
5. API Gateway WebSocket API Guide
6. API Gateway Authorization & Authentication
7. Serverless Application Model (SAM)
8. AWS CDK API Gateway Constructs
9. AWS Well-Architected Framework - API Gateway

API 標準仕様・設計

10. RESTful API Best Practices
11. OpenAPI / Swagger Specification
12. OAuth 2.0 Specification
13. RFC 6749 - OAuth 2.0 Authorization Framework
14. OpenID Connect Specification

Bedrock 統合・AI Agent（2026）

15. Amazon Bedrock AgentCore Gateway - OAuth2 統合強化
16. Bedrock Agent Core with API Gateway

関連ツール・エコシステム

17. AWS Black Belt - API Gateway
18. Postman API Platform
19. Kong API Gateway
20. Tyk API Gateway
21. MDN Web Docs - REST
22. MDN Web Docs - HTTP

最終更新：2026-04-26