はじめに
「Lambda関数を書くのは簡単だが、本番品質にするのは難しい」——これはサーバーレス開発に携わるエンジニアなら一度は感じたことがある感覚ではないだろうか。関数本体は数十行で済むのに、IAMロール・API Gateway・CloudWatch Logs・DLQ設定・X-Rayトレーシング・コールドスタート対策と、本番に耐えうる構成を整えるだけで数時間かかる。
本記事はTerraformによるIaC全般でも、KubernetesのPodオーケストレーションでもない。「Lambda関数を1本書いてAWSにデプロイする」——コールドスタート対策・CDKインフラ定義・EventBridge連携を含むサーバーレス開発のフルサイクルを、AWSとAnthropicが共同で提供するAWS Serverless Pluginで加速する話だ。
2026年3月にAWSが公式リリースしたAWS Serverless Pluginは、Claude Codeがサーバーレス開発の「設定の壁」を自動的に越えられるようにした転換点だった。
CLAUDE.mdでサーバーレス規約を定義する——Lambda設計・CDK・観測性の「安全なデフォルト」
サーバーレス開発においてCLAUDE.mdが果たす役割は、単なる指示書ではない。チームの「暗黙知」を明文化し、Claude Codeが毎回ゼロから設計を選択しなくて済むようにする仕組みだ。
AWS HeroのGunnar Groschが実践しているCLAUDE.md設計パターンはこのアプローチを象徴している。彼の記事「Teaching Claude Code How You Work: CLAUDE.md in Practice」では、サーバーレス開発特有の判断基準をCLAUDE.mdに落とし込むことで、チームの新メンバーであってもClaude Codeが本番品質のLambda関数を生成できるようになったと報告されている。
具体的なCLAUDE.mdの構成はこうなる。
# CLAUDE.md（サーバーレス開発ポリシー）
## Serverless Development Policy
### インフラ定義
- IaC: AWS CDK（TypeScript）を使用。SAM/CloudFormationの直接編集は禁止
- 命名規則: {project}-{env}-{resource}（例: myapp-prod-user-api）
- 環境: dev / staging / prod の3環境を必ず分離
### Lambda関数設計
- ランタイム: Node.js 22.x または Python 3.12（古いランタイム更新厳禁）
- メモリ: デフォルト512MB（パフォーマンスチューニングで調整）
- タイムアウト: API Gateway連携は最大29秒（APIGWのハードリミット）
- 環境変数: AWS Secrets Manager参照（ハードコード禁止）
### コールドスタート対策
- Java/Python 3.12: SnapStart対応を検討
- Node.js: import最適化、依存関係の最小化、esbuildバンドル
- 重要エンドポイントはProvisioned Concurrencyを検討
### イベント駆動設計
- 非同期処理はSQS/EventBridgeを経由（Lambda直接呼び出し回避）
- DLQ（Dead Letter Queue）を全非同期Lambdaに必須設定
### 観測性
- 全関数にX-Rayトレーシングを有効化
- CloudWatch Logs: structured JSON logging（console.log禁止）
- Lambda Insightsを有効化このCLAUDE.mdがある状態でClaude Codeに「ユーザー認証APIのLambda関数を作って」と依頼すると、ランタイム選定・Secrets Manager参照・X-Ray有効化・DLQ設定まで自動的に考慮した実装が生成される。CLAUDE.mdがないと、これらの設定を毎回指示する必要があるか、あるいは省略された状態の実装が出てくる。
重要なのは「環境変数のハードコード禁止」の一行だ。Lambda関数の実装でよくあるミスの一つが、データベース接続文字列やAPIキーを環境変数に直接記述してしまうことだが、CLAUDE.mdでSecrets Manager参照を明記することで、このミスをClaude Code側で防げる。
AWS Serverless Plugin × CDK——Lambdaのフルサイクルを自然言語で操作
AWSとAnthropicが共同で提供する公式プラグイン
2026年3月、AWSはClaude Code向けの「Agent Plugin for AWS Serverless」をAnthropicの公式プラグインマーケットプレイスにリリースした。このプラグインはAWS Labsが管理するOSSリポジトリ（github.com/awslabs/agent-plugins）をバックエンドとして持ち、Lambda・API Gateway・EventBridge・Step Functionsへの深い専門知識をClaude Codeに付与する。
インストールは1コマンドだ。
/plugin install aws-serverless@claude-plugins-officialプラグインが提供するスキルは役割ごとに分かれている。AWS Lambda スキルはプロジェクト初期化・イベントソース設定（DynamoDB/SQS/Kinesis/Kafka）・コールドスタート対策・CloudWatch/X-Rayによる観測性設定をカバーする。AWS Serverless Deployment スキルはSAM/CDKテンプレートの生成・SAM Localによるローカルテスト・CloudFormationデプロイ・マルチ環境管理を担う。AWS Lambda Durable Functions スキルはStep Functions統合・長時間実行ワークフロー・Sagaパターン実装を扱う。
空フォルダからAPIまでの実践フロー
Claude CodeにAWS Serverless Pluginを導入した状態で、「Node.js 22のLambda関数でユーザー管理APIを作って。API GatewayでREST API、DynamoDBにデータを保存、X-Rayトレーシング有効で」と依頼すると、CDKスタック・Lambda実装・IAMロール・CloudWatch設定が一括で生成される。AWSコンソールを開く必要はない。
Claude Codeが生成するCDKスタックはこのような形になる。
const userApiFunction = new lambda.Function(this, 'UserApiFunction', {
runtime: lambda.Runtime.NODEJS_22_X,
handler: 'index.handler',
code: lambda.Code.fromAsset('lambda'),
memorySize: 512, // Lambda Power Tuningで最適値を探索
timeout: cdk.Duration.seconds(29),
tracing: lambda.Tracing.ACTIVE, // X-Ray
environment: {
SECRET_ARN: secret.secretArn,
},
// Node.jsのコールドスタート対策: Provisioned Concurrency（重要エンドポイントのみ）
// SnapStartはJava 11/17/21・Python 3.12のみ対応。Node.jsには非対応
});
// 重要エンドポイントにProvisioned Concurrencyを設定（コールドスタートゼロ）
const version = userApiFunction.currentVersion;
new lambda.Alias(this, 'LiveAlias', {
aliasName: 'live',
version,
provisionedConcurrentExecutions: 2,
});
// DLQ設定（非同期呼び出しの信頼性確保）
const dlq = new sqs.Queue(this, 'DLQ', {
retentionPeriod: cdk.Duration.days(14),
});コールドスタート対策：SnapStartとProvisioned Concurrencyの使い分け
コールドスタートはLambdaの最大の課題の一つで、初回呼び出し時に典型的に数百ミリ秒から2〜3秒のレイテンシが加算される。Eコマースや決済APIでは許容できないレベルになりうる。
Claude Codeへの指示パターンはこうなる。
このLambda関数のコールドスタートを最適化して。
現在: Node.js 22、メモリ128MB、依存関係20パッケージ
要件:
1. Lambda Power Toolsでのstructured logging設定
2. 不要な依存関係の分析と除外
3. esbuildによるバンドル最小化の設定
4. 適切なコールドスタート対策の判断と適用
5. X-Rayトレーシングの追加ここで重要な前提知識がある。SnapStartはJava 11/17/21とPython 3.12のみ対応しており、Node.jsには非対応だ。Node.jsのコールドスタート対策として有効なのは、依存関係の最小化・esbuildによるバンドル最適化・Lambda Power Tuningでの最適メモリサイズ選定、そして重要エンドポイントへのProvisioned Concurrency適用になる。Provisioned Concurrencyは全ランタイムで利用可能だが、常時ウォームアップのコストが発生するため、決済フローや認証エンドポイントなど本当に重要なパスに絞って適用するのが現実的だ。
このCLAUDE.mdの「コールドスタート対策」セクションに使い分けルールを明記しておくことで、Claude Codeが勝手にNode.jsにSnapStartを適用しようとするミスを防げる。
Vercel Functions × Edge——フロントエンドAPIのサーバーレス最適化
VercelとClaude Codeの公式統合
VercelはClaude Code統合ガイドを公式ドキュメント（vercel.com/docs/agent-resources/coding-agents/claude-code）に公開している。Vercel AI GatewayとClaude Codeを組み合わせることで、Claude Codeのトークン使用量・APIコスト・レイテンシを組織レベルで一元管理できる設計が公式サポートされている。
さらに、Vercel SandboxでClaude Agent SDKを実行し、Edge FunctionsとしてAIエージェント処理をデプロイする構成も公式サポートされた。Lambdaを使わずにVercelのサーバーレスインフラ上でAIエージェントを動かすユースケースが、フロントエンドチームには増えてきている。
Edge FunctionsとServerless Functionsの判断基準
Vercelのサーバーレス環境では、Edge Functionsと従来のServerless Functionsどちらを使うかという判断が毎回必要になる。この判断をCLAUDE.mdに定義しておくことで、Claude Codeが自動的に適切なタイプを選択できるようになる。
実践的な判断基準はこうなる。認証チェック・レート制限・ABテスト・地理的なリダイレクトはEdge Functionsが適切だ。コールドスタートがなく、世界中のエッジロケーションで低レイテンシに処理できる。一方、データベース接続・重い計算処理・外部API呼び出しが多い処理・長時間実行が必要な処理は、フルNode.js環境が使えるServerless Functionsを選ぶ。Edge Functionsはランタイム制限（実行時間30秒、Node.js APIのサブセット）があるため、適用範囲の見極めが重要になる。
CLAUDE.mdにこの判断基準を一行ずつ書いておくだけで、Claude Codeは新しいAPIを実装する際に自動的に適切な関数タイプを提案するようになる。
組織レベルでのコスト管理
EMの視点から見たVercel AI Gatewayの価値は、Claude Codeのトークン消費量を可視化できる点にある。チームメンバーがClaude Codeをどのような作業に使い、どの程度のコストが発生しているかを、Vercel AI Gatewayのダッシュボードで把握できる。LambdaやVercel Functionsの実行コストと合わせて、AI支援開発のコスト全体を一元管理する基盤として機能する。
まとめ
AWS Serverless Pluginの登場は、「Lambdaの詳細を分かっている人だけがCDK + IAM + X-Rayを書けた」という制約を実質的に解消した。CLAUDE.mdでサーバーレス規約を定義し、AWS Serverless Pluginを導入すれば、チームの誰もが本番品質のLambda関数とCDKインフラを自然言語で生成できるようになる。
重要なのは、コールドスタート対策の前提知識をCLAUDE.mdに正確に書き込むことだ。SnapStartはJava/Python 3.12のみ対応、Node.jsにはProvisioned Concurrencyと依存関係最小化が有効——この使い分けをCLAUDE.mdに明記しておくことで、Claude Codeが誤った対策を提案するリスクを避けられる。
まず試すなら、既存のLambda関数プロジェクトにCLAUDE.mdでサーバーレス規約を定義し、AWS Serverless Pluginをインストールして「このLambda関数のCDKスタックをレビューして、本番品質に足りない設定を追加して」と依頼してみることだ。何が欠けていたかが、会話の中ではっきりと見えてくる。
コメント