ひとことで言うと
Lambda や HTTP バックエンドを、外部から呼べる URL として公開する窓口です。生成AI固有のサービスではなく、エージェントのツールやチャットUIの背後にある既存の仕組みをそのまま使っているだけです。
要するに、人間用の受付窓口です。AgentCore Gateway が「エージェント専用の通用口（MCP変換・ツール発見・認可を一括で持つ）」だとすると、API Gateway は昔からある正面の受付。REST/HTTP でリクエストを受け、Lambda に渡し、レスポンスを返す。エージェントの文脈で出てくるのは、この受付に「生成が長い」「トークンを少しずつ返したい」という新しい要求が来たときです。
なぜ生まれたか
もともとはサーバーレスの前段（認証・スロットリング・バージョニング）を肩代わりする汎用サービスとして生まれました。GenAI 文脈での摩擦点は別で、モデル呼び出しの応答時間がAPI Gatewayの前提より長いことです。
| 摩擦 | API Gateway 側の受け皿 |
|---|---|
| FM呼び出しは数秒〜十数秒かかることがある | 統合タイムアウト（既定・上限とも 29,000ミリ秒。Regional/privateに限り引き上げ申請可） |
| 生成し終わるまで待たせると体感が悪い | Lambda プロキシ統合のレスポンスストリーミング（InvokeWithResponseStream を使う専用の統合） |
| 対話をプッシュ配信したい | WebSocket API（$connect/$default/$disconnect ルート） |
何に使うか
| 用途 | 使い方 | 関連ドメイン |
|---|---|---|
| エージェントのツールをHTTPで公開 | Lambda 統合＋usage plan・APIキーでレート制御 | D2 |
| Bedrock の生成をトークン単位で中継 | Lambda プロキシ統合のストリーミング（後述） | D2, D4 |
| 動的モデル切替の窓口 | API Gateway → Lambda → AppConfig でモデルIDを注入（コード変更なし） | D1 |
| モデル呼び出しのレート制限・バックオフ観測 | 使用量プラン、X-Ray | D4 |
試験でどう問われるか
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| チャットの応答を少しずつ表示したい | Lambda プロキシ統合をストリーミング用に設定し、Lambda 側は InvokeWithResponseStream 形式で出力する | 通常のLambdaプロキシ統合のままタイムアウトだけ延ばす（バッファ方式は仕様上ストリームできない） |
| モデル呼び出しが29秒を超えて打ち切られる | 非同期化（SQS＋ワーカー、Step Functions）に設計を変える | 統合タイムアウトの引き上げだけで解決しようとする（Regional/private限定・上限あり） |
| エージェントに MCP 経由でツールを渡したい | AgentCore Gateway を使う（API/Lambdaを MCP互換ツールへ変換する専用サービス） | API Gateway でツールを公開しようとする（プロトコル変換や意味検索の機能を持たない） |
| 特定クライアントの乱発呼び出しを抑えたい | 使用量プラン＋APIキーでスロットリング | WAF だけで対応しようとする（レート制御の主役ではない） |
「ストリーミングにすればタイムアウトが伸びる」わけではありません。統合タイムアウトの上限はストリーミング統合でも変わりません。ストリーミングが解決するのは「体感（TTFB）」であって「打ち切りまでの時間」ではないため、モデルの生成が長時間に及ぶワークロードは、ストリーミングと非同期化を別問題として設計する必要があります。
実務でどう使うか
- 統合タイムアウトの上限は 29,000ミリ秒。 引き上げは Regional/private API に限られ、エッジ最適化APIでは不可です。Bedrock の生成が長引くシナリオでは、API Gateway 側だけをいじっても解決しません
- WebSocket は接続時間そのものに上限があります。 アイドルタイムアウト600秒に加えて、接続時間の上限は7,200秒（2時間）。長時間の音声・チャットセッションでは、無操作でなくても強制切断されるため、再接続ロジックが要ります
- API のペイロード上限は10MB（WebSocket以外）。 画像・音声などマルチモーダル入力を直接ボディに載せず、S3の署名付きURLを渡す設計が定石です
WebSocketの制約も見落としがちです。1メッセージのペイロードは128KB、フレームサイズは32KBが上限。大きめのツール実行結果をWebSocket経由でそのまま流すと、分割送信の実装が必要になります。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| AgentCore Gateway | API Gateway は人間/クライアント向けのHTTP窓口。AgentCore Gateway はエージェント向けにAPIをMCPツールへ変換し、認可・意味検索まで持つ専用サービス |
| AWS AppSync | API Gateway はREST/WebSocketの汎用中継。AppSync はGraphQLとPub/Sub（Events）に特化し、サブスクリプションでの配信管理までマネージド |
| Lambda 関数URL | どちらもストリーミング可能。関数URLは Lambda 単体を素早く公開する最小構成、API Gateway は使用量プラン・カスタムドメイン・複数バックエンドの集約が要るときに選ぶ |
想起チェック
Q1. Bedrock の生成トークンを少しずつクライアントに返したい。API Gateway側で何を変える？
Lambda プロキシ統合をレスポンスストリーミング用に設定します（InvokeWithResponseStream を使う専用の統合方式）。Lambda 関数側もメタデータ＋8バイトのnullデリミタ＋ペイロードという専用フォーマットで出力する必要があります。
Q2. エージェントに社内APIをツールとして使わせたい。API GatewayとAgentCore Gatewayのどちらを選ぶ？
AgentCore Gatewayです。API/Lambda/既存サービスをMCP互換ツールに変換し、意味検索によるツール発見・OAuthの入出両方向認可までを1つのマネージドサービスで持ちます。API Gateway はここまでの機能を持ちません。
Q3. 統合タイムアウトの上限は何ミリ秒？誰でも引き上げられる？
29,000ミリ秒が既定かつ上限です。引き上げはService Quotasから申請できますが、Regional APIまたはprivate APIに限られ、エッジ最適化APIでは引き上げられません。