統合タイプ（Lambdaプロキシ統合 vs カスタム統合）難易度 標準無料
REST APIのバックエンドをLambda関数にする際、「Lambdaプロキシ統合（AWS_PROXY）」を選んだ。開発者が実装で意識すべき最も重要な違いを選べ。（単一選択）
- ALambda関数はイベント全体（メソッド・パス・ヘッダー・クエリ・ボディ等）を自分でパースし、
statusCode・headers・bodyを含む決まった形式のJSONを自分で返す必要がある。マッピングテンプレートによる変換は行われない - Bプロキシ統合ではマッピングテンプレートが自動的に適用され、Lambda関数はリクエストボディの中身だけを引数として受け取れる
- Cプロキシ統合を使うとLambda関数の戻り値の形式は自由で、API Gatewayが自動的に適切なHTTPレスポンスへ変換してくれる
- Dプロキシ統合とカスタム統合はいずれもマッピングテンプレートが必須であり、書き方が異なるだけで挙動は同じである
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・AIで再検証済
解説
Lambdaプロキシ統合（AWS_PROXY）を使うと、API Gatewayはリクエストの変換を行わず、
HTTPメソッド・パス・ヘッダー・クエリ文字列・ボディなどリクエスト全体をそのままイベントオブジェクトとしてLambdaに渡す。
- Lambda側は
event.body・event.headers・event.queryStringParameters等を自分でパースする必要がある。 - レスポンスも、Lambda関数が
{"statusCode": 200, "headers": {...}, "body": "..."}という決まった形式のJSONを返さなければならない。API Gatewayはこれをそのままクライアントへ返す（変換しない）。 - 対してカスタム統合（
AWS）では、統合リクエスト/統合レスポンスのマッピングテンプレート（VTL）で API Gateway側がリクエスト/レスポンスを変換でき、Lambda側は素のペイロードだけを扱えばよい。
プロキシ統合は設定がシンプルな反面、リクエスト解析・レスポンス整形の責務がLambda関数のコード側に寄る点が最大の違いである。
- B逆。プロキシ統合ではマッピングテンプレートによる変換は行われず、リクエスト全体がそのままLambdaのイベントとして渡される。
- C自由ではない。Lambdaプロキシ統合ではLambdaが規定のレスポンス形式（statusCode/headers/body）を返さないと、クライアントへ正しくレスポンスされない（500エラー等になる）。
- Dプロキシ統合ではマッピングテンプレートは使用されない（統合リクエスト/レスポンスの変換ステップがスキップされる）。カスタム統合とは根本的に責務分担が異なる。
ひっかけ： 「プロキシ統合でもAPI Gateway側でマッピングテンプレートによる変換が効く」という誤解が罠。
プロキシ統合ではマッピングテンプレートは使われず（統合リクエスト/レスポンスの変換をスキップ）、
Lambda関数が生のイベントを受け取り、規定形式のレスポンスを自分で組み立てる必要がある。
AIが作成し、別の手順のAIで誤りを点検した解説です（有資格者による監修は経ていません）