Step Functions SDK Direct Integration完全ガイド — Lambdaレスでフルサーバーレスを実現するハンズオン

公開日: 2026-04-13
難易度: 中級〜上級
所要時間: 約90分
シリーズ: [Step Functions シリーズ 第8回（最終回）]

この記事で学ぶこと
– SDK Direct Integration の仕組み（arn:aws:states:::aws-sdk:service:action ARN形式）
– Lambda不要でDynamoDB・SQS・SNS・S3を直接操作するLambda-lessアーキテクチャ
– PascalCase変換ルール（AWS SDK APIとの違い）
– Optimized Integration vs SDK Integration の使い分け
– 最小権限IAM設計とエラーハンドリングのベストプラクティス
– Terraform での完全構築（コンソール版とASL完全一致）

シリーズ前回記事:
– 第1回: AWS Step Functions 入門
– 第2回: ECS × Step Functions 入門
– 第3回: Step Functions エラーハンドリング完全ガイド
– 第4回: Step Functions 入出力データフロー制御完全ガイド
– 第5回: Step Functions Callbackパターン完全ガイド
– 第6回: Step Functions Distributed Map完全ガイド
– 第7回: Step Functions Express vs Standard完全ガイド

目次

1. SDK Direct Integration 概念編
2. アーキテクチャ解説
3. AWSコンソールでのハンズオン
4. TerraformでのSDK Direct Integration構築
5. 実践Tips（SDK Direct Integration設計ガイド）
6. ハンズオン後の削除手順
7. まとめとStep Functionsシリーズ総括

Section 1: SDK Direct Integration 概念編

1-1. SDK Direct Integration とは

AWS SDK Direct Integration（SDKインテグレーション）は、Lambda関数を介さずに、ステートマシン定義（ASL）から直接AWSサービスのAPIを呼び出せる機能です。

2021年9月にGA（一般公開） され、現在は 220以上のAWSサービス・10,000以上のAPIアクション をサポートしています（2026年3月時点）。

ARN形式（呼び出しパターン）:

arn:aws:states:::aws-sdk:serviceName:apiAction

• serviceName: AWSサービス名（小文字）例: dynamodb, sqs, s3
• apiAction: APIアクション名（camelCase）例: putItem, sendMessage, publish

最近の主な追加サービス（2025〜2026年）:
– Amazon Bedrock AgentCore（エージェント実行、リトライ・並列実行対応）
– Amazon S3 Vectors（ドキュメント取り込みパイプライン自動化）
– AWS End User Messaging、Amazon Q Apps 等 36サービス（2025年1月）
– AWS Backup Search + 137の追加APIアクション（2025年4月）

1-2. Lambda経由 vs SDK Direct Integration の比較

1-3. 呼び出しパターン: ARN形式

arn:aws:states:::aws-sdk:serviceName:apiAction

主要サービスのARN例:

1-4. Parameters の書き方（PascalCase変換ルール）

SDK Direct IntegrationのParametersは PascalCase（アッパーキャメルケース） で記述します。

重要: AWS CLI/SDK では tableName（camelCase）ですが、SF Parameters では TableName（PascalCase）になります。

DynamoDB PutItem の例:

{  "Type": "Task",  "Resource": "arn:aws:states:::aws-sdk:dynamodb:putItem",  "Parameters": { "TableName": "Users", "Item": {"user_id": {"S.$": "$.user_id"},"email": {"S.$": "$.email"},"created_at": {"S.$": "$$.Execution.StartTime"} }, "ConditionExpression": "attribute_not_exists(user_id)"  }}

SQS SendMessage の例:

{  "Type": "Task",  "Resource": "arn:aws:states:::aws-sdk:sqs:sendMessage",  "Parameters": { "QueueUrl.$": "$.queue_url", "MessageBody.$": "States.Format('Welcome {}! Your registration is complete.', $.email)"  }}

主なPascalCase変換ルール:

1-5. Optimized Integration vs SDK Integration の違い

推奨: 対応サービスは Optimized Integrationを優先（ネイティブ統合のため）。未対応サービスやSDK全機能へのアクセスは SDK Integrationを使用。

1-6. ユースケース一覧

SDK Direct Integrationが特に有効なケース:

向いていないケース:
– 複雑なビジネスロジック・データ変換（Lambdaの方が適切）
– 外部HTTP API呼び出し（EventBridge API Destinations / Lambda経由）
– 100KB以上のペイロード処理（S3経由で回避可能）

1-7. 本シリーズとの関連

概念を理解したところで、次のセクションではこのSDK統合を使った実際のアーキテクチャと、本ハンズオンで構築するシナリオの全体像を解説します。

Section 2: アーキテクチャ解説

2-1. ハンズオンシナリオ概要

本ハンズオンでは「Lambda不要のユーザー登録ワークフロー」を構築します。ユーザーが登録フォームを送信すると、Step Functionsが以下の処理を Lambdaを一切使わず に自動実行します。

入力: { "user_id": "user001", "email": "user@example.com", "name": "田中太郎" }  │  ├─① RegisterUser → DynamoDB（ユーザー情報を永続化）  ├─② SendWelcomeEmail → SQS（ウェルカムメールをキューに送信）  ├─③ NotifyAdmin → SNS（管理者トピックに通知）  └─④ SaveRegistrationLog → S3（登録ログをJSONで保存）

使用リソース一覧:

2-2. アーキテクチャ全体図

上図はLambda-lessアーキテクチャの全体像を示しています。Step Functions State Machineが各AWSサービスへ直接SDK統合で接続しており、Lambda関数が介在しません。

従来のLambda経由との違い（左列 vs 右列）:
– 左列（Lambda経由）: SF Task → Lambda呼び出し → Lambda内でboto3 API → AWSサービス
– 右列（SDK Direct）: SF Task → aws-sdk:xxx:apiAction → AWSサービス（直接）

Lambda経由では 関数の管理・コード記述・追加コスト が発生しますが、SDK統合ではすべて不要です。

2-3. Lambda-lessの効果

コスト比較（100万回実行した場合）:

注意: Lambda費用はワークロードにより異なります。Lambdaが必要なケース（複雑なロジック）では従来通りLambdaを使用してください。

複雑さの比較:

2-4. データフロー（Parameters設計）

上図はDynamoDB PutItemを例にした入力→Parameters→API→ResultSelectorの流れです。

PascalCase変換ルールの要点:

入力JSON (camelCase) →SF Parameters (PascalCase)──────────────────────────────────────────────────────$.user_id→"user_id": {"S.$": "$.user_id"}$.email  →"email": {"S.$": "$.email"}※ Parameters のキー自体は PascalCase:  tableName  →  TableName  item →  Item  queueUrl→  QueueUrl

ResultSelector（レスポンスの絞り込み）:

"ResultSelector": {  "status_code.$": "$.SdkHttpMetadata.HttpStatusCode",  "request_id.$": "$.SdkResponseMetadata.RequestId"}

DynamoDB PutItemの成功レスポンスは大量のメタデータを含むため、ResultSelectorで必要な情報のみ抽出することを推奨します。

2-5. ASL全体構造（プレビュー）

本ハンズオンで構築するステートマシンのASL概要:

{  "Comment": "Lambda-less User Registration Workflow",  "StartAt": "RegisterUser",  "States": { "RegisterUser": {"Type": "Task","Resource": "arn:aws:states:::aws-sdk:dynamodb:putItem","Parameters": {  "TableName": "Users",  "Item": { "user_id": {"S.$": "$.user_id"}, "email": {"S.$": "$.email"}, "name": {"S.$": "$.name"}  }},"Next": "SendWelcomeEmail" }, "SendWelcomeEmail": {"Type": "Task","Resource": "arn:aws:states:::aws-sdk:sqs:sendMessage","Parameters": {  "QueueUrl": "https://sqs.ap-northeast-1.amazonaws.com/123456789/welcome-email-queue",  "MessageBody.$": "States.Format('Welcome {}! Email: {}', $.name, $.email)"},"Next": "NotifyAdmin" }, "NotifyAdmin": {"Type": "Task","Resource": "arn:aws:states:::aws-sdk:sns:publish","Parameters": {  "TopicArn": "arn:aws:sns:ap-northeast-1:123456789:admin-notification",  "Message.$": "States.Format('New user registered: {} ({})', $.name, $.email)",  "Subject": "New User Registration"},"Next": "SaveRegistrationLog" }, "SaveRegistrationLog": {"Type": "Task","Resource": "arn:aws:states:::aws-sdk:s3:putObject","Parameters": {  "Bucket": "registration-logs-bucket",  "Key.$": "States.Format('logs/{}/{}.json', $$.Execution.StartTime, $.user_id)",  "Body.$": "States.JsonToString($)"},"End": true }  }}

ASL全文・Terraform定義・コンソール操作手順は Section 3〜5 で詳細解説します。

アーキテクチャと全体像が把握できました。次のセクションでは、AWSコンソールを使って実際にこのワークフローを段階的に構築していきます。

Section 3: AWSコンソールでのハンズオン

このセクションでは、AWSコンソールを使って Lambda不要のユーザー登録ワークフロー を段階的に構築します。DynamoDB PutItem → SQS SendMessage → SNS Publish → S3 PutObject の4サービスをLambda関数を一切使わず、AWS SDK統合（arn:aws:states:::aws-sdk:*）だけで直接呼び出します。

Step A（DynamoDB単体）→ Step B（SQS追加）→ Step C（SNS追加）→ Step D（S3＋エラーハンドリング完成形）→ Step E（Lambda版との比較）の順に段階的に構築し、SDK統合の仕組みを体感します。

3-1. 前提条件

• AWSアカウントおよび以下のサービスを操作できるIAM権限
• AWS Step Functions（ステートマシンの作成・実行）
• Amazon DynamoDB（テーブルの作成・アイテムの確認）
• Amazon SQS（FIFOキューの作成・メッセージ確認）
• Amazon SNS（トピックの作成・サブスクリプション管理）
• Amazon S3（バケットの作成・オブジェクト確認）
• AWS IAM（ロール・ポリシーの作成）
• Amazon CloudWatch Logs（ログの参照）
• リージョン: ap-northeast-1（東京） で統一
• Lambdaは一切不要（このハンズオンの最大の特徴）

3-2. リソースの準備

3-2-1. DynamoDBテーブル作成

手順:

1. AWSコンソール → DynamoDB → 「テーブルの作成」
2. 以下を入力:
3. テーブル名: user-registrations
4. パーティションキー: user_id（タイプ: 文字列）
5. ソートキー: なし（空欄のまま）
6. 「テーブル設定」→「設定のカスタマイズ」を選択:
7. キャパシティーモード: オンデマンド（ハンズオンでは従量課金が便利）
8. 「テーブルの作成」をクリック
9. テーブルのステータスが「アクティブ」になるまで待機（通常30秒以内）

💡 ポイント: created_at カラムはASL内で $$.Execution.StartTime（Step Functionsの実行開始時刻）を自動セットします。DynamoDBテーブルにこのカラムを事前定義する必要はありません。

3-2-2. SQS FIFOキュー作成

手順:

1. AWSコンソール → Amazon SQS → 「キューの作成」
2. 以下を入力:
3. タイプ: FIFO（先入れ先出し）
4. キュー名: welcome-email-queue.fifo（.fifo サフィックス必須）
5. 「設定」セクション:
6. コンテンツベースの重複排除: 有効化（チェックを入れる）
7. 他はデフォルトのまま「キューの作成」をクリック
8. 作成後、キューのURLをメモしておく（ASLで使用）
9. 例: https://sqs.ap-northeast-1.amazonaws.com/123456789012/welcome-email-queue.fifo

💡 FIFOキューの必須パラメータ: FIFO キューへのメッセージ送信では MessageGroupId と MessageDeduplicationId が必須です。本ハンズオンではASL内でこれらを指定します。コンテンツベースの重複排除を有効にしているため、MessageDeduplicationId が重複チェックのキーとして機能します。

3-2-3. SNSトピック作成

手順:

1. AWSコンソール → Amazon SNS → 「トピックの作成」
2. 以下を入力:
3. タイプ: スタンダード
4. 名前: user-registration-admin
5. 「トピックの作成」をクリック
6. 作成後、トピックARNをメモ（ASLで使用）
7. 例: arn:aws:sns:ap-northeast-1:123456789012:user-registration-admin

テスト用メールサブスクリプションの追加:

1. 作成したトピック user-registration-admin を開く
2. 「サブスクリプション」タブ → 「サブスクリプションの作成」
3. 以下を入力:
4. プロトコル: Eメール
5. エンドポイント: （受信確認できる自分のメールアドレス）
6. 「サブスクリプションの作成」をクリック
7. 受信したメールの「Confirm subscription」リンクをクリックして確認

💡 メール確認を忘れずに: サブスクリプションが「保留中の確認」のままだとSNS通知が届きません。Step Cを実行する前に「確認済み」になっていることを確認してください。

3-2-4. S3バケット作成

手順:

1. AWSコンソール → Amazon S3 → 「バケットを作成」
2. 以下を入力:
3. バケット名: user-registration-logs-{ランダム文字列}（例: user-registration-logs-a1b2c3）
4. AWS リージョン: アジアパシフィック（東京） ap-northeast-1
5. 「オブジェクト所有者」: ACL 無効（推奨、デフォルト）
6. 「このバケットのパブリックアクセスをブロックする設定」: すべてのパブリックアクセスをブロック（デフォルト、そのまま）
7. 他はデフォルトのまま「バケットを作成」をクリック
8. バケット名をメモ（ASLで使用）

⚠️ S3バケット名はグローバルで一意: 同名のバケットが世界に1つも存在しないよう、ランダム文字列を末尾に付けてください。

3-2-5. IAMロール作成

Step Functionsが各AWSサービスを直接呼び出すための実行ロールを作成します。

ロールの作成:

1. AWSコンソール → IAM → 「ロール」→「ロールを作成」
2. 信頼されたエンティティタイプ: 「AWSのサービス」
3. サービス: Step Functions を選択 → 「次へ」
4. 許可ポリシー: この画面では何も選択せず「次へ」（後でインラインポリシーを追加）
5. ロール名: sf-sdk-integration-role
6. 「ロールを作成」をクリック

インラインポリシーの追加:

1. 作成した sf-sdk-integration-role を開く
2. 「許可」タブ → 「許可を追加」→「インラインポリシーを作成」
3. 「JSON」タブに切り替え、以下をすべて貼り付け（<ACCOUNT_ID>・<BUCKET_NAME> を実際の値に置換）:

{  "Version": "2012-10-17",  "Statement": [ {"Sid": "DynamoDBPutItem","Effect": "Allow","Action": "dynamodb:PutItem","Resource": "arn:aws:dynamodb:ap-northeast-1:<ACCOUNT_ID>:table/user-registrations" }, {"Sid": "SQSSendMessage","Effect": "Allow","Action": "sqs:SendMessage","Resource": "arn:aws:sqs:ap-northeast-1:<ACCOUNT_ID>:welcome-email-queue.fifo" }, {"Sid": "SNSPublish","Effect": "Allow","Action": "sns:Publish","Resource": "arn:aws:sns:ap-northeast-1:<ACCOUNT_ID>:user-registration-admin" }, {"Sid": "S3PutObject","Effect": "Allow","Action": "s3:PutObject","Resource": "arn:aws:s3:::<BUCKET_NAME>/logslogs/*" }  ]}

Lambda経由と比較した権限管理の簡素化:

ポイント: リソースARNは可能な限り絞り込みましょう。"Resource": "*" は便利ですが、意図しないリソースへのアクセスを許可してしまいます。DynamoDBテーブル名やS3バケット名を明示的に指定することを強く推奨します。

5-3. SDK統合が向かないケース

SDK Direct Integrationは非常に強力ですが、すべてのユースケースに最適ではありません。以下のケースはLambdaを使った方が適切です。

2026年3月時点の最新情報: AWS Step FunctionsはSDK統合で220以上のサービス・10,000以上のAPIアクションをサポートするまで拡張されました（Amazon Bedrock AgentCoreも追加）。ただし、ストリーミング系APIはSDK統合の対象外であり、Lambdaを介した実装が必要です。

5-4. エラーハンドリングのベストプラクティス

SDK Direct Integrationでは、各AWSサービス固有のエラーコードをCatchで捕捉できます。

DynamoDB固有のエラー対応:

"Catch": [  { "ErrorEquals": ["DynamoDB.ConditionalCheckFailedException"], "Next": "HandleDuplicateUser", "ResultPath": "$.error"  },  { "ErrorEquals": ["DynamoDB.ProvisionedThroughputExceededException","DynamoDB.RequestLimitExceeded" ], "Next": "HandleThrottling", "ResultPath": "$.error"  },  { "ErrorEquals": ["States.ALL"], "Next": "HandleGenericError", "ResultPath": "$.error"  }]

エラーの優先順位ルール: 具体的なエラー（ConditionalCheckFailedException）を先に定義し、汎用エラー（States.ALL）は必ず最後に配置すること。Step Functionsはリストの上から順に評価するため、States.ALL を先に書くと具体的なハンドラーに到達しなくなります。

サービスエラーの命名規則:

5-5. Optimized vs SDK Integration の選択指針

呼び出したいAWSサービスは何か?↓Optimized Integration対応サービス（Lambda/SQS/SNS/DynamoDB/ECS/Glue/SageMaker等）?  YES → Optimized Integration優先（ネイティブ最適化・.sync対応あり）  NO  → SDK Integration（220+サービス全般）↓.waitForTaskTokenや.syncが必要か?  YES → Optimized Integration（SDK統合では非サポート）  NO  → SDK統合で問題なし↓ストリーミングAPIが必要か（ConverseStream等）?  YES → Lambda経由（SDK統合では非サポート）  NO  → SDK統合で完結

まとめ: 「AWSサービスを直接呼びたい・Lambdaを減らしたい」→ SDK Direct Integration。「コールバックや同期待機が必要」→ Optimized Integration。「複雑なロジックやストリーミングが必要」→ Lambda Task、という判断軸を持っておくと設計が迷いません。

Section 6: ハンズオン後の削除手順

⚠️ 放置するとDynamoDB・S3ストレージ・CloudWatch Logs料金が発生します。ハンズオン終了後は必ずリソースを削除してください。

6-1. コスト注意事項

6-2. Terraformで構築した場合

terraform destroy -var="random_suffix=abc123" -var="admin_email=your@email.com"

terraform destroy 実行後、確認プロンプトが表示されます。yes と入力して削除を開始してください。

手動削除が必要なもの（Terraformで管理されない場合がある）:

# CloudWatch Logsロググループaws logs delete-log-group --log-group-name /aws/states/sf-sdk

6-3. コンソールで構築した場合の削除チェックリスト

以下の順番で削除すると依存関係エラーが起きにくいです。

• [ ] Step Functions — ステートマシン（user-reg-step-a / user-reg-step-b / user-reg-step-c / user-reg-final）を削除
• [ ] DynamoDB — テーブル（user-registrations）を削除
• [ ] SQS — FIFOキュー（welcome-email-queue.fifo）を削除
• [ ] SNS — トピック（user-registration-admin）とすべてのサブスクリプションを削除
• [ ] S3 — バケット（user-registration-logs-XXXXX）: オブジェクトをすべて削除 → バケットを削除
• [ ] IAM — ロール（sf-sdk-integration-role）と付随するインラインポリシーを削除
• [ ] CloudWatch Logs — ロググループ（/aws/states/sf-sdk 等）を削除

Tips: AWSマネジメントコンソールの「請求とコスト管理」→「コストエクスプローラー」で削除後のコストが0になっていることを数日後に確認することをおすすめします。

Section 7: まとめとStep Functionsシリーズ総括

7-1. この記事で学んだこと

本記事（第8回 SDK Direct Integration完全ガイド）では、以下を習得しました:

• SDK Direct Integrationの仕組み — arn:aws:states:::aws-sdk:service:action というARN形式でAWS SDKを直接呼び出す構造
• Lambda-lessアーキテクチャの実現 — DynamoDB・SQS・SNS・S3を中間Lambdaなしで直接操作する4ステップユーザー登録ワークフロー
• PascalCase変換ルール — AWS SDK APIのcamelCaseとASL上のPascalCaseの対応表とデバッグ方法
• Optimized Integration vs SDK Integration の使い分け — .sync や .waitForTaskToken の有無で選択する判断軸
• 最小権限IAM設計 — Lambda経由（2ロール）からSDK直接統合（1ロール）への簡素化
• SDK統合が向かないケース — ストリーミングAPI・複雑なデータ変換・外部HTTP APIはLambdaを活用

7-2. Step Functionsシリーズ全8弾の総まとめ

本シリーズを通じて、AWS Step Functionsの全機能を体系的に習得しました:

7-3. Step Functions実践アーキテクチャ選択指針（総まとめ）

8回にわたるシリーズで学んだ知識を集約した「Step Functionsをどう使うか」の選択フローです:

ワークフローの種類は?├── 長時間処理（5分超）・監査ログが必要・人間承認あり│→ Standard Workflow（第7回）│└── 人間の承認ステップが必要│ → Callbackパターン（.waitForTaskToken）（第5回）│├── 大量データの並列処理（S3/DynamoDBの大規模バッチ）│→ Distributed Map（第6回）│└── 処理結果をS3にまとめて書き出したい│ → ResultWriter活用│├── 高スループット・短時間処理（APIのオーケストレーション）│→ Express Workflow（第7回）│└── API呼び出し元に同期で結果を返したい│ → StartSyncExecution│└── AWSサービスを直接呼びたい（Lambdaを減らしたい） ├── .sync / .waitForTaskTokenが必要（Lambda/ECS/SageMaker等） │→ Optimized Integration（第2回・第5回） ├── 220+サービスのAWS API（Lambda不要） │→ SDK Direct Integration（本記事）← 本シリーズの集大成 └── 複雑なデータ変換・外部HTTP API・ストリーミング  → Lambda Task（第3回・第4回）

Step Functionsは「ステートマシンで制御フローを書き、各ステートでAWSサービスを呼び出す」というシンプルな原則のもと、ここまで紹介した多様なパターンを組み合わせることで、エンタープライズレベルのワークフロー自動化が実現できます。

本シリーズ全8回を完走された方は、Lambda中心のアーキテクチャからStep Functionsを軸としたサーバーレスオーケストレーションへの移行を検討する十分な知識を身につけたと言えます。ぜひ実際のプロジェクトでStep Functionsを活用してみてください。

7-4. 今後のTechBlog予告

本シリーズに続く次のテーマとして、以下のコンテンツを公開予定です:

• AWS EventBridge完全ガイド — イベント駆動アーキテクチャの中核サービスをStep Functionsと組み合わせて解説（予定）
• AWS CDK入門 — インフラをTypeScriptで記述するCDKのハンズオン（予定）
• Step Functions × Bedrock — 生成AI/MLワークフロー統合の実践例（予定）

公開をお楽しみに。

7-5. シリーズリンク

本記事は「AWS ハンズオン TechBlog」Step Functions シリーズの最終回（第8回）です。

シリーズ一覧:
– 第1回: AWS Step Functions 入門 — コンソールとTerraformで学ぶハンズオン
– 第2回: ECS × Step Functions 入門 — CSVバッチをFargateタスクでジョブ化するハンズオン
– 第3回: Step Functions エラーハンドリング完全ガイド — 注文処理パイプラインで学ぶRetry/Catch/Timeout
– 第4回: Step Functions 入出力データフロー制御完全ガイド — 5つのフィルタでペイロードを最適化するハンズオン
– 第5回: Step Functions Callbackパターン完全ガイド — .waitForTaskTokenで実現する経費承認ワークフロー
– 第6回: Step Functions Distributed Map完全ガイド — S3大規模並列処理をハンズオンで習得
– 第7回: Step Functions Express vs Standard完全ガイド — 同一処理で比較するワークフロータイプ選択術
– 第8回: 本記事（SDK Direct Integration完全ガイド）← 最終回