マッピングテンプレート（VTL）難易度 標準無料
REST APIで、クライアントから受け取るリクエストボディの形式（{"user_name": "..."}）と、バックエンドのLambda関数が期待するペイロード形式（{"userName": "..."}）が異なる。Lambda関数のコードは変更したくない。カスタム統合（非プロキシ）で、この差異をAPI Gateway側で吸収する方法として最も適切なものを選べ。（単一選択）
- A統合リクエストのマッピングテンプレート（VTL）で、
user_nameをuserNameに変換するテンプレートを定義する。これはカスタム統合でのみ機能する - Bプロキシ統合のまま、統合リクエストのマッピングテンプレートで
user_nameをuserNameへ変換する - CAPI Gatewayのステージ変数でフィールド名のマッピングルールを定義し、実行時に自動的に変換させる
- DLambda関数の環境変数にフィールド名のマッピングルールをJSONとして設定し、Lambda側で読み込んで変換する
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
API Gatewayのカスタム統合では、統合リクエスト側にマッピングテンプレートを設定でき、 Velocity Template Language（VTL）を使ってクライアントからのリクエストボディを バックエンドが期待する形式へ変換できる。
#set($inputRoot = $input.path('$'))
{
"userName": "$inputRoot.user_name"
}
このように Content-Typeごとにマッピングテンプレートを定義し、
$input.path()・$input.json()等のVTL変数でリクエストボディを参照・変換して、
Lambda関数が期待するJSON構造を組み立てる。レスポンス側にも同様に統合レスポンスのマッピングテンプレートを設定できる。
なお、この仕組みはプロキシ統合（AWS_PROXY）では使えない（プロキシ統合はリクエスト/レスポンスをそのまま素通しするため）。
Lambda関数のコードを変更せずに済ませたい場合は、カスタム統合＋マッピングテンプレートの組み合わせが適切である。
- Bマッピングテンプレートはプロキシ統合では適用されない（リクエストがそのままLambdaへ渡される）。カスタム統合に切り替える必要がある。
- Cステージ変数は環境ごとの設定値（Lambda ARNの切替等）を保持する仕組みであり、リクエストボディのフィールド変換機能ではない。
- D結局Lambda関数側にロジックを実装することになり「Lambda関数のコードは変更したくない」という制約に反する。
ひっかけ： 「プロキシ統合のままLambda関数の前段でリクエストを変換できる」という誤解に注意。
マッピングテンプレートはカスタム統合（非プロキシ）でのみ機能する。プロキシ統合を使い続けたいなら、
変換ロジックはLambda関数コード側に実装する必要がある。
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）