ankuro.dev
← ブログ一覧に戻る
【開発記録 #2】CDK × Claude CodeでLambda + API Gatewayを最速で作る
2026-03-21#AWS#CDK#Lambda#API Gateway#Claude Code#個人開発

【開発記録 #2】CDK × Claude CodeでLambda + API Gatewayを最速で作る

Claude Codeを使ってCDKのスタックを作るとき、どんなプロンプトを投げればいいのか。何が自動で生成されて、何を自分で直す必要があるのか。この記事ではその判断プロセスを記録する。

最初のプロンプトは「シンプルに」が鉄則

CDKプロジェクトを初期化したあと、Claude Codeに最初の依頼を投げた。

mkdir cdk && cd cdk
cdk init app --language typescript

CDKでLambda + API Gatewayのスタックを作ってください。
Lambda（Python）がBedrockを呼び出してレスポンスを返すだけのシンプルな構成で。

ポイントは末尾の「シンプルな構成で」という一言。

Claude Codeは優秀なので、指示を与えすぎると「こういうのも必要だろう」と判断して余計な機能を追加してくることがある。最初のプロンプトで複雑な要件を全部伝えると、生成されたコードの全体像が把握しにくくなる。

「シンプルな構成で」と明示することで、Lambda関数の定義・API Gatewayとの接続・IAMロールという最小限の骨格だけが出てきた。

追加の指示はシンプルに一言ずつ重ねていく。

東京リージョンにして

これだけで ap-northeast-1 への変更が反映された。最初から全部まとめて指示するより、段階的に積み重ねる方がコードの意図が把握しやすい。

生成されたコードで確認すべきポイント

Claude Codeが出したスタックの骨格：

// cdk/lib/api-stack.ts（抜粋）
const reviewFunction = new lambda.Function(this, 'ReviewFunction', {
  runtime: lambda.Runtime.PYTHON_3_12,
  handler: 'review.handler',
  code: lambda.Code.fromAsset('../lambda'),
  environment: {
    BEDROCK_MODEL_ID: 'jp.anthropic.claude-haiku-4-5-20251001-v1:0',
    BEDROCK_REGION: 'ap-northeast-1',
  },
  timeout: Duration.seconds(30),
});

const api = new apigateway.RestApi(this, 'ReviewApi', {
  restApiName: 'Architecture Review API',
  defaultCorsPreflightOptions: {
    allowOrigins: apigateway.Cors.ALL_ORIGINS,
  },
});

生成されたコードを受け取ったとき、まず確認するのは「自分が意図した設計になっているか」。コードの細部より構造を先に見る。

今回確認したのは：

  • LambdaとAPI Gatewayが正しく接続されているか ✅
  • モデルIDとリージョンが環境変数で渡されているか ✅（ハードコードされていないか）
  • タイムアウトが設定されているか ✅（Bedrockの呼び出しは数秒かかる）

CORSの設定（ALL_ORIGINS）はローカル開発では問題ないが、本番では絞る必要がある。今はスピード優先で許容した。こういう「今は許容、後で直す」という判断を意識的にしておくと、開発が止まらない。

生成コードに足りなかったもの——IAMポリシー

生成されたコードにはBedrockを呼び出すためのIAMポリシーが含まれていなかった。

これはよくあるパターン。Claude Codeはコードの構造は正確に作るが、AWSのセキュリティ周りは「どこまで許可するか」が要件によって変わるため、省略されることが多い。

東京リージョンでClaude Haikuを使う場合、クロスリージョン推論プロファイルのARNを許可する必要がある。JPプロファイル（jp.anthropic.claude-haiku-4-5-20251001-v1:0）は東京（ap-northeast-1）と大阪（ap-northeast-3）にリクエストを振り分ける構成になっているため、両リージョンのARNが必要になる。

reviewFunction.addToRolePolicy(new iam.PolicyStatement({
  actions: ['bedrock:InvokeModel', 'bedrock:InvokeModelWithResponseStream'],
  resources: [
    'arn:aws:bedrock:ap-northeast-1::foundation-model/anthropic.claude-haiku-4-5-20251001-v1:0',
    'arn:aws:bedrock:ap-northeast-1:*:inference-profile/jp.anthropic.claude-haiku-4-5-20251001-v1:0',
    'arn:aws:bedrock:ap-northeast-3:*:inference-profile/jp.anthropic.claude-haiku-4-5-20251001-v1:0',
  ],
}));

Claude Codeで生成したコードを使うとき、IAMポリシーは必ず自分でレビューする。生成コードをそのまま使うと権限が広すぎるか、逆に足りなくて動かないかのどちらかになりやすい。

環境のトラブルは先に潰す

CDKを動かす前に環境確認をしていて、いきなり詰まった。

aws sts get-caller-identity

Unknown output type: jsom

~/.aws/config の output が jsom（タイポ）になっていた。json に修正して解決。

またLambdaのローカルテスト用に boto3 をインストールしようとしたら：

error: externally-managed-environment

macOSのHomebrewで管理されたPythonでよく起きる問題。仮想環境を作って対応した。

cd lambda
python3 -m venv .venv
source .venv/bin/activate
pip install boto3

こういった環境起因のエラーはClaude Codeに貼り付けると解決策を出してくれるが、根本的にはローカル環境の状態を把握しておく必要がある。Claude Codeは「何が起きているか」を理解した上で使うツールであって、エラーを全部丸投げするものではない。

CDKデプロイ

cd cdk
cdk bootstrap   # 初回のみ（CDK用のS3バケット等をAWSに作成）
cdk deploy

デプロイ完了でAPIエンドポイントが発行された：

https://z5k87mbntf.execute-api.ap-northeast-1.amazonaws.com/prod/review

インフラはできた。次回はこのLambdaの中身——Bedrockを呼び出してWell-Architectedレビューを返す review.py の実装。

Claude Codeへの依頼でつかんだ感覚

今回のCDK構築で学んだことを整理する。

最初の依頼はシンプルに絞る
全要件を一度に伝えると、生成されたコードの全体像が把握しにくくなる。「まずシンプルな骨格」→「必要なものを追加」の順が扱いやすい。

生成コードはIAM周りを必ず自分でレビューする
構造は正確に作るが、権限設計は自分の要件に合わせて調整が必要。

エラーはコピペして投げる
AWS固有のエラーメッセージはそのまま貼り付けると、ほぼ正確な解決策が出てくる。自分で調べるより速い。

← 前回：第1回——設計思想と全体像 | 次回：第3回——BedrockでWell-Architectedレビューを生成する →

← ブログ一覧に戻る