AWS Lambda、API Gateway、Step Functions、EventBridge、SAM/CDK を用いて、サーバーレス（サーバー管理が不要なクラウド実行環境）アプリケーションの構築、デプロイ、管理、デバッグ、設定、最適化を行います。 コールドスタート（初回実行時の遅延）、CORS（異なるドメイン間でのデータ通信）デバッグ、イベントソースマッピング、トラブルシューティング、同時実行数管理、SnapStart、Powertools、関数 URL、EventBridge Scheduler、Lambda レイヤー、本番運用対応などに対応しています。 **次のような場合に使用:** Lambda、API Gateway、Step Functions、SAM テンプレート、CDK サーバーレススタック、DynamoDB ストリームトリガー、SQS イベントソース、コールドスタート、タイムアウト、502/504 エラー、スロットリング（実行数制限）、同時実行数、CORS、Powertools、または AWS 上のイベント駆動アーキテクチャ（処理を事象に基づいて連鎖させるシステム設計）に関する質問や相談。「サーバーレス」という言葉がなくても対応します。 **対応外:** EC2、ECS/Fargate コンテナ、Amplify ホスティング
Builds, deploys, manages, debugs, configures, and optimizes serverless applications on AWS using Lambda, API Gateway, Step Functions, EventBridge, and SAM/CDK. Covers cold starts, CORS debugging, event source mappings, troubleshooting, concurrency, SnapStart, Powertools, function URLs, EventBridge Scheduler, Lambda layers, and production readiness. Triggers on mentions of Lambda, API Gateway, Step Functions, SAM templates, CDK serverless stacks, DynamoDB stream triggers, SQS event sources, cold starts, timeouts, 502/504 errors, throttling, concurrency, CORS, Powertools, or any event-driven architecture on AWS, even without the word "serverless." Does not apply to EC2, ECS/Fargate containers, or Amplify hosting.
AWSでサーバーレスアプリケーション（サーバの管理が不要なクラウドアプリ）を構築するための専門知識。Lambda、API Gateway、Step Functions、EventBridge、イベントソースマッピング、並行処理、コールドスタート（初回実行時の遅延）、デプロイ、トラブルシューティングに対応しています。
最適な利用環境： AWS MCP サーバと組み合わせて使用すると、CLIコマンドの実行、CloudWatch（監視サービス）のクエリ、設定検証を直接行えます。標準のAWS CLIアクセスでも全ガイダンスが利用できます。
下記の一般参照資料には含まれない機能や手順をカバーしています。見落としやすい専門的な機能や、検証済みのステップバイステップ手順が記載されているため、対応するスキルに該当する場合はまずこちらをご参照ください。
| このスキルを使用 | 次のような場合 |
|---|---|
| aws-lambda-microvms | テナント間の強い分離が必要、サンドボックス環境で信頼できないコードを実行（AI エージェントのコードサンドボックス、REPL、ノートブック、CI ランナー）、長時間実行するセッション、状態を保ったまま一時停止・再開、ポートをリッスンするサーバ（gRPC、WebSocket、カスタム TCP）、Firecracker マイクロVM、スナップショットから再開可能な計算、最大8時間の実行時間が必要な場合 |
| aws-lambda-durable-functions | 耐久的な実行（チェックポイント機能付き）、長時間実行する複数ステップのワークフローをプレーンなコード（TypeScript/Python/Java）で記述、自動的な状態の永続化、コード内でのサガパターン（分散トランザクション）、人が介入する承認フロー、最大1年間の実行、context.step/context.wait/context.invoke、withDurableExecution、durable-execution-sdkを使用する場合 |
| aws-lambda-managed-instances | Lambda マネージドインスタンス、キャパシティプロバイダー、EC2バックアップのLambda、高い定常トラフィック（月5000万リクエスト以上）で Savings Plans / Reserved Instance 価格を希望、PerExecutionEnvironmentMaxConcurrency、CapacityProviderConfig、複数の並行実行環境が必要な場合 |
複数のステップ、サービス、機能を連携させたい場合はこちらをご参照ください。「調整」「ワークフロー」「ステートマシン」「複数ステップの連携」「Lambda 機能の連携」「耐久的な実行」「リトライ機能付きパイプライン」、またはサガ・補償機能、人が介入する承認、ファンアウト（1つの入力を複数の出力に分散）、長時間実行する非同期調整を構築したいという意図が示されている場合が対象です。
新しい調整またはマルチステップワークフローを開始する場合は、実装前に必ず AWS Step Functions と AWS Lambda Durable Functions の選択肢を提示してください。どちらかを黙って選んではいけません。下記のシグナルに基づいてルーティングしてください。リクエストがサガ・補償、人が介入する承認、ファンアウト、または単に「ワークフロー調整」という汎用パターンのみで、特定の技術を指名していない場合は、両方のオプションと簡潔なトレードオフを提示してから、ユーザーに決断させてください。シグナルが既に一つのサービスを指していれば、トレードオフの注意点で始めないでください。
| このスキルを使用 | 次のような場合 |
|---|---|
| aws-step-functions | 主な処理が AWS サービスの直接呼び出し、非 Lambda 計算（ECS/Fargate、Glue、SageMaker、Batch）の調整が管理統合機能を通じて必要、コンプライアンス監査、クロスチーム運用の可視性、またはコードベースを共有しないチーム間の契約仕様として、ビジュアルで監査可能なワークフロー定義が必須、ステートマシンと Amazon States Language（ASL、ワークフロー定義言語）の作成・編集（ステートタイプ、JSONata データ変換、Retry/Catch エラーハンドリング、.sync/waitForTaskToken サービス統合、Distributed Map、TestState ユニットテスト、JSONPath から JSONata への移行）を行う場合 |
| aws-lambda-durable-functions | Lambda 上で既に構築している際の、プロセス内でのコード優先な調整（context.step/context.wait/context.invoke、withDurableExecution）、実行あたりのきめ細かいステップが多く、Step Functions Standard の累積的なステート遷移コストが大きくなる可能性がある場合は、期待される利用量での Step Functions 価格（Standard vs Express）と Lambda 呼び出しコストを比較した上で選択、調整ステップが一般的なプログラミング言語で記述でき、アプリケーションコードと同じコードベース内に存在（モジュール、データ型、テストスイートを共有）、チームが標準的なソフトウェアエンジニアリング慣行（ユニットテスト、コードレビュー、型チェック）を宣言型のワークフロー言語を学ばずに調整ロジックに適用している場合 |
トレードオフ（どちらも適合する場合）： Durable Functions は調整を Lambda コードベース内に保ちます。Step Functions は調整を管理サービスとして外部化し、ビジュアルなステートマシンと組み込みのサービス統合を提供します。
セキュリティ： どちらのサービスもワークフロー状態とペイロードを永続化します。Step Functions は完全な入力/出力を実行履歴に記録し、コンソールで表示可能で、ログが有効な場合は CloudWatch Logs に記録されます。基本的には、実行ログ（CloudTrail）を有効化し、実行失敗時に CloudWatch アラームを設定し、ワークフロー実行ごとに最小権限の IAM ロールを使用してください。シークレット、トークン、個人情報（PII）をワークフロー状態経由で渡さず、Secrets Manager/ARN ポインタで参照し、データが機密の場合は顧客管理の KMS キーで状態を暗号化してください。
既知のステップシーケンスを調整するのではなく、イベント駆動型システムを設計・運用する場合はこちらをご参照ください。「イベントバス」「イベント駆動型アーキテクチャ」「パブ/サブ」「発行・購読」「ファンアウト」「イベント順序」「順序付き配信」「FIFO イベント」「イベントリプレイ」「イベント再生」「イベント保持」「イベントストア」「CloudEvents」「Avro」「Protobuf」「スキーマレジストリ」「重複排除」「コレオグラフィ（参加者による分散調整）」「疎結合化」「非同期統合」「イベントブローカー」、または複数のチームとアカウントで共有される中央バスを運用する意図が示されている場合が対象です。
| このスキルを使用 | 次のような場合 |
|---|---|
| amazon-eventbridge-event-bus | 新しいイベント駆動型ワークロード、多くのチームとアカウントが発行・購読する中央バスをプラットフォームチームが所有、そのバスのガバナンス（購読者制御、取り消し、アカウント単位のスロットリング、コスト配分、エンドツーエンドの可視性）、スキーマレジストリを通じてデコードされるオープンイベント形式（Avro、Protobuf、CloudEvents）、イベントグループごとの順序付き配信または FIFO 配信、アカウント単位の転送コストが重要な高ファンアウト、過去のイベントの耐久的な保持と新規購読者への再生、購読者ごとの JSONata 変換、重複排除、サービス間のコレオグラフィと疎結合化、複数アカウントにまたがるイベント駆動型アーキテクチャの場合。このスキルは EventBridge クラシックカスタムイベントバス、EventBridge Scheduler、EventBridge Pipes、EventBridge Global Endpoints、EventBridge スキーマレジストリ、EventBridge API Destinations、EventBridge Connections に関する質問には使用してはいけません。 |
| このスキルを使用 | 次のタスク |
|---|---|
| connecting-lambda-to-api-gateway | 既存の Lambda を新しい REST/HTTP API に接続：プロキシ統合、権限、CORS、スロットリング、アクセスログ、デプロイ |
| connecting-lambda-to-dynamodb | Lambda を DynamoDB に接続：IAM 実行ロール、読み取り・書き込み権限、ストリームイベントソースマッピング |
| creating-api-gateway-stage | API Gateway ステージの作成：CloudWatch ログ、X-Ray トレーシング、スロットリング、WAF（ファイアウォール）関連付け、認可 |
| deploying-custom-domain-rest-api | カスタムドメイン付き Regional REST API のデプロイ：ACM 証明書、Lambda バックエンド、リクエストオーサライザー、ベースパスマッピング、Route 53 DNS |
| debugging-lambda-timeouts | タイムアウトしている Lambda のシステマティックな診断：設定、CloudWatch ログ/メトリクス、VPC、コールドスタート、メモリ、ダウンストリーム呼び出し |
| processing-s3-uploads-with-step-functions | イベント駆動型ワークフローのデプロイ：S3 アップロード → EventBridge → Step Functions → Lambda（小ファイル）または Fargate（大ファイル）、VPC/ECR/ECS/IAM 付き |
| ユーザーニーズ | 参照資料 |
|---|---|
| 新しいサーバーレスアプリの構築 — パターン選択 | architecture.md |
| Lambda 設定、コールドスタート、SnapStart、メモリ、VPC、レイヤー、Function URLs | lambda.md |
| 並行処理（予約済み、プロビジョン済み、ESM コントロール） | concurrency.md |
| イベントソース（SQS、DynamoDB ストリーム、SNS、Kinesis）、フィルタリング、バッチ失敗 | event-sources.md |
| Step Functions、EventBridge ルール/パイプ/スケジューラ | orchestration.md |
| API Gateway クォータ、オーサライザー、WebSocket | api-gateway.md |
| SAM/CDK リソースタイプと高速反復 | deployment.md |
| 本番運用対応、可視性、アンチパターン | production.md |
| エラーのデバッグ（エラー文字列 → 原因 → 修正） | troubleshooting.md |
| Powertools ハンドラテンプレート | powertools-handler.py |
注記： 参照資料には、変更される可能性のある特定のランタイムバージョン、クォータ、機能マトリックスが含まれています。精度が重要な場合（本番運用、ランタイム選択、クォータ）は、現在の AWS 公式ドキュメントで確認してください。参照資料は、間違えやすい値と落とし穴に焦点を当てています。基本情報ではありません。
Domain expertise for building serverless applications on AWS: Lambda, API Gateway, Step Functions, EventBridge, event source mappings, concurrency, cold starts, deployment, and troubleshooting.
Works best with the AWS MCP server — run CLI commands, query CloudWatch, validate configs directly. All guidance also works with standard AWS CLI access.
These cover capabilities and procedures the general references below do not. Several are specialized features or step-by-step tested procedures you would otherwise miss. Route to the matching skill before falling back to the references.
| Use this skill | When the workload involves |
|---|---|
| aws-lambda-microvms | Strong tenant isolation, sandboxed/untrusted code execution (AI agent code sandboxes, REPLs, notebooks, CI runners), long-lived sessions, suspend/resume with preserved state, port-listening servers (gRPC, WebSocket, custom TCP), Firecracker microVMs, snapshot-resumable compute, up to 8-hour lifetimes |
| aws-lambda-durable-functions | Durable execution, checkpoint-and-replay, long-running multi-step workflows written as plain code (TS/Python/Java), automatic state persistence, saga pattern in code, human-in-the-loop callbacks, executions up to 1 year, context.step/context.wait/context.invoke, withDurableExecution, durable-execution-sdk |
| aws-lambda-managed-instances | Lambda Managed Instances (LMI), capacity providers, EC2-backed Lambda, steady high-volume traffic (50M+ req/mo) wanting Savings Plans / Reserved Instance pricing, PerExecutionEnvironmentMaxConcurrency, CapacityProviderConfig, multi-concurrent execution environments |
Route here when the user wants to coordinate multiple steps, services, or functions. Triggers include "orchestration", "workflow", "state machine", "multi-step coordination", "coordinate Lambda functions", "durable execution", "pipeline with retries", or intent to build saga/compensation, human-in-the-loop approval, fan-out, or long-running async coordination.
When starting a new orchestration or multi-step workflow, you MUST surface the choice between AWS Step Functions and AWS Lambda Durable Functions before implementing — do not silently pick one. Route on the signals below. When the request names only a generic pattern (saga/compensation, human-in-the-loop, fan-out, or "workflow orchestration") with no technology, present both options and the one-line tradeoff, then let the user decide. Do not lead with the tradeoff caveats when the signals already point to one service.
| Use this skill | When the workload involves |
|---|---|
| aws-step-functions | Orchestration whose primary work is calling AWS services directly; coordinating non-Lambda compute (ECS/Fargate, Glue, SageMaker, Batch) through native managed integrations; a visual, auditable workflow definition required for compliance, cross-team operational observability, or as a shared contract between teams that do not share a codebase (ASL is the specification, not application code); authoring or editing state machines and Amazon States Language (ASL) — state types, JSONata data transformation, Retry/Catch error handling, .sync/waitForTaskToken service integrations, Distributed Map, TestState unit testing, JSONPath-to-JSONata migration |
| aws-lambda-durable-functions | Code-first orchestration in-process when already building on Lambda (context.step/context.wait/context.invoke, withDurableExecution); many fine-grained steps per execution where cumulative Step Functions Standard state-transition cost may be significant — compare Step Functions pricing (Standard vs Express) against Lambda invocation cost at the expected volume before choosing; orchestration steps written in a general-purpose language within the same application codebase (share modules, data types, and test suites with application code); teams applying standard software-engineering practices (unit tests, code review, type checking) to orchestration logic without learning a declarative workflow language |
Tradeoff (use when either fits): Durable Functions keeps orchestration in your Lambda codebase; Step Functions externalizes it into a managed, visual state machine with built-in service integrations.
Security: Both services persist workflow state and payloads — Step Functions records full input/output in execution history (viewable in the console and, if logging is enabled, CloudWatch Logs). As a baseline, enable execution logging (CloudTrail) and CloudWatch alarms on execution failures, and use least-privilege per-workflow execution roles. Do not pass secrets, tokens, or PII through workflow state; reference them by Secrets Manager/ARN pointer, and apply a customer-managed KMS key to encrypt state when the data is sensitive.
Route here when the user is designing or operating an event-driven system rather than orchestrating a known sequence of steps. Triggers include "event bus", "event-driven architecture", "pub/sub", "publish/subscribe", "fan-out", "event ordering", "ordered delivery", "FIFO events", "event replay", "replay events", "event retention", "event store", "CloudEvents", "Avro", "Protobuf", "schema registry", "deduplication", "choreography", "decoupling", "asynchronous integration", "event broker", or a central bus shared across teams and accounts.
| Use this skill | When the workload involves |
|---|---|
| amazon-eventbridge-event-bus | A new event-driven workload; a platform team owning a central bus that many teams and accounts publish to and subscribe from; governance of that bus (subscriber control, revocation, per-account throttling, cost allocation, end-to-end observability); open event formats (Avro, Protobuf, CloudEvents) decoded through a schema registry; ordered or FIFO delivery per event group; high fan-out where per-account forwarding cost matters; durable retention and replay of past events into a newly created subscriber; per-subscriber JSONata transformation; deduplication; choreography and decoupling across services; event-driven architecture spanning multiple accounts. This skill MUST NOT be used for questions regarding the EventBridge classic custom event bus, EventBridge Scheduler, EventBridge Pipes, EventBridge Global Endpoints, the EventBridge Schema Registry, EventBridge API Destinations, or EventBridge Connections. |
| Use this skill | For the task |
|---|---|
| connecting-lambda-to-api-gateway | Wire an existing Lambda to a new REST/HTTP API: proxy integration, permissions, CORS, throttling, access logging, deployment |
| connecting-lambda-to-dynamodb | Connect Lambda to DynamoDB: IAM execution role, read/write permissions, stream event source mapping |
| creating-api-gateway-stage | Create an API Gateway stage with CloudWatch logging, X-Ray tracing, throttling, WAF association, and authorization |
| deploying-custom-domain-rest-api | Deploy a Regional REST API with custom domain: ACM cert, Lambda backend, request authorizer, base path mapping, Route 53 DNS |
| debugging-lambda-timeouts | Systematically diagnose a timing-out Lambda: config, CloudWatch logs/metrics, VPC, cold starts, memory, downstream calls |
| processing-s3-uploads-with-step-functions | Deploy an event-driven workflow: S3 upload → EventBridge → Step Functions → Lambda (small files) or Fargate (large files), with VPC/ECR/ECS/IAM |
| User need | Read |
|---|---|
| Building a new serverless app — pattern selection | architecture.md |
| Lambda config, cold starts, SnapStart, memory, VPC, layers, Function URLs | lambda.md |
| Concurrency (reserved, provisioned, ESM controls) | concurrency.md |
| Event sources (SQS, DynamoDB Streams, SNS, Kinesis), filtering, batch failures | event-sources.md |
| Step Functions, EventBridge rules/pipes/scheduler | orchestration.md |
| API Gateway quotas, authorizers, WebSocket | api-gateway.md |
| SAM/CDK resource types and fast iteration | deployment.md |
| Production readiness, observability, anti-patterns | production.md |
| Debugging an error (exact string → cause → fix) | troubleshooting.md |
| Powertools handler template | powertools-handler.py |
Note: Reference files contain specific runtime versions, quotas, and feature matrices that change. When precision matters (production, runtime choice, quotas), confirm against current AWS documentation. The references focus on values and gotchas that are easy to get wrong — not on basics.
原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。