AWS Transform Agents × Claude Code でサーバーレス開発を次のステージへ

はじめに

以前書いた「Claude Code で AWS サーバーレス開発を高速化した話」では、Lambda + API Gateway + DynamoDB の実装を Claude Code に任せる 「コード生成の速度」 にフォーカスしました。あの記事の PV が急増しているため、今回はその続編として 「AI エージェントが AWS インフラを直接変換・移行支援する」 フェーズまで踏み込みます。

きっかけは AWS が発表した 「AWS Transform agents now available in Kiro, Claude, Cursor, and Codex」 です。これは単なるコード補完ではなく、既存のコードやインフラを AI エージェントが自律的に変換・最適化する という新しいパラダイムです。

この記事では、AWS Transform エージェントの概要と、Claude Code との組み合わせで実現できる実践的なサーバーレス開発フローを整理します。

想定読者

• 前回記事（Claude Code × サーバーレス）を読んで興味を持った方
• Lambda / API Gateway / DynamoDB / Terraform を業務で使っている
• 既存のモノリシックなコードをサーバーレスに移行したい、あるいは計画中

---

AWS Transform Agents とは何か

AWS Transform は元々 AWS Migration Hub Transform として提供されていた、Java アプリケーションの .NET 移行や Windows Server の Linux 移行を支援するサービスです。今回の発表で、これが IDE エージェントとして Kiro・Claude・Cursor・Codex に統合 されました。

主なユースケースは以下の通りです。

ユースケース	概要
Java → .NET 変換	Spring Boot アプリを .NET に変換
モノリス → マイクロサービス分解	依存関係を解析してサービス境界を提案
Lambda ランタイムのアップグレード	Node.js 16 → 22 などのランタイム移行
Terraform リソースの最適化提案	非推奨リソースの書き換え提案

従来は AWS コンソール上の専用 UI で使うツールでしたが、開発者が普段使っている IDE/エディタ上でエージェントとして動く ようになりました。これにより、コンテキストスイッチなしに移行作業を進められます。

---

Claude Code + AWS Transform で何が変わるか

従来フロー vs エージェント統合フロー

従来の Lambda ランタイム移行（例: Node.js 16 → 22）は、概ねこうでした。

1. ランタイム EOL の通知を確認
2. AWS コンソール or AWS CLI で対象 Lambda を列挙
3. コードを手動でレビューして非互換箇所を確認
4. ローカルで修正してテスト
5. Terraform の runtime フィールドを更新
6. デプロイして動作確認

Claude Code に AWS Transform エージェントが統合されると、こうなります。

1. Claude Code 上で「Node.js 16 を使っている Lambda を全て洗い出して移行計画を立てて」と依頼
2. Transform エージェントがリポジトリ + AWS アカウント全体をスキャン
3. 非互換箇所のリストと修正差分を自動生成
4. 人間は差分をレビューして承認
5. Terraform の runtime 一括書き換えも同時に実施

ポイントは 「リポジトリとクラウドアカウントを横断してスキャンし、差分を自動生成する」 点です。手順 2〜5 がほぼ自動化されます。

CLAUDE.md でエージェントのコンテキストを最大化する

AWS Transform エージェントを Claude Code から使う場合、CLAUDE.md に以下のコンテキストを追記しておくと精度が上がります。

# AWS 環境コンテキスト
- AWSアカウント: 本番/ステージング/開発が別アカウント (Organizations管理)
- Lambda ランタイム方針: Node.js は LTS のみ使用、Python は 3.12 以上
- Terraform: terraform-aws-modules/lambda/aws モジュールを標準使用
- デプロイ: GitHub Actions + terraform apply (手動 apply 禁止)

# Transform エージェントへの制約
- 本番アカウントへの直接変更は禁止、開発アカウントで検証してから PR
- runtime 変更は必ず Lambda テストスイートを通す
- 依存パッケージの major バージョンアップは人間がレビュー必須

エージェントはこのファイルを読んで制約内で動くため、「うっかり本番に直接変更を加える」 ようなリスクを減らせます。

---

実践: モノリシック Lambda をサービス分解するフロー

AWS Transform の「モノリス → マイクロサービス」ユースケースを、Claude Code と組み合わせて実践するフローを紹介します。

Step 1: 現状の依存関係を可視化する

まず Claude Code に既存コードを渡して依存関係マップを作らせます。

# Claude Code へのプロンプト例

以下の Lambda ハンドラ群を分析して、
1. 各関数が読み書きするデータストア（DynamoDB テーブル名、S3 バケット名）
2. 関数間の同期呼び出し（Lambda Invoke）
3. 非同期連携（SQS/SNS/EventBridge）
をマークダウン表形式で整理してください。

その上で、AWS Transform が推奨するサービス境界の候補を 2〜3 案出してください。

Claude Code の出力例（一部）：

関数名	読み取り	書き込み	同期呼び出し先
createOrder	Users テーブル	Orders テーブル	validateInventory
validateInventory	Inventory テーブル	—	—
notifyUser	Users テーブル	—	—
processPayment	Orders テーブル	Payments テーブル	notifyUser

この表を見ると、注文・在庫・通知・決済 の 4 つのドメインに分けられることが一目でわかります。

Step 2: Terraform モジュールの分割案を生成する

次に、Claude Code に Terraform の分割案を生成させます。

# 分割前: 1 モジュールに全 Lambda が同居
module "api_lambdas" {
  source  = "terraform-aws-modules/lambda/aws"
  version = "~> 7.0"

  function_name = "monolith-api"
  handler       = "index.handler"
  runtime       = "nodejs22.x"
  source_path   = "./src"

  environment_variables = {
    ORDERS_TABLE    = aws_dynamodb_table.orders.name
    INVENTORY_TABLE = aws_dynamodb_table.inventory.name
    PAYMENTS_TABLE  = aws_dynamodb_table.payments.name
    USERS_TABLE     = aws_dynamodb_table.users.name
  }
}

# 分割後: Claude Code + Transform が提案するモジュール構成

# orders サービス
module "lambda_orders" {
  source  = "terraform-aws-modules/lambda/aws"
  version = "~> 7.0"

  function_name = "orders-create"
  handler       = "orders/create.handler"
  runtime       = "nodejs22.x"
  source_path   = "./src/orders"

  environment_variables = {
    ORDERS_TABLE = aws_dynamodb_table.orders.name
    # 他テーブルへの直接アクセスを排除
  }
}

# inventory サービス
module "lambda_inventory" {
  source  = "terraform-aws-modules/lambda/aws"
  version = "~> 7.0"

  function_name = "inventory-validate"
  handler       = "inventory/validate.handler"
  runtime       = "nodejs22.x"
  source_path   = "./src/inventory"

  environment_variables = {
    INVENTORY_TABLE = aws_dynamodb_table.inventory.name
  }
}

# サービス間通信: SQS でデカップリング
resource "aws_sqs_queue" "orders_to_inventory" {
  name                      = "orders-inventory-queue"
  visibility_timeout_seconds = 30
  redrive_policy = jsonencode({
    deadLetterTargetArn = aws_sqs_queue.dlq.arn
    maxReceiveCount     = 3
  })
}

ポイントは 「各 Lambda が触れる DynamoDB テーブルを最小化」 していることです。これにより、IAM ポリシーも最小権限に絞りやすくなります。

Step 3: SQS DLQ と冪等性を忘れない

サービス分解で同期呼び出しを非同期（SQS）に置き換えると、メッセージの重複配信・順序保証・DLQ の設計が必要になります。Claude Code に依頼するプロンプト例です。

上記の SQS キューを使った orders → inventory の非同期フローで、
以下を実装してください:
1. DLQ (maxReceiveCount=3)
2. Lambda の SQS トリガー（バッチサイズ 10、部分的バッチ応答有効化）
3. 冪等性のための DynamoDB Conditional Write パターン
4. CloudWatch Alarm (DLQ メッセージ数 > 0)

Terraform + Node.js 22 で実装してください。

生成されるコードの骨格：

// inventory/validate.handler.ts
import { SQSHandler, SQSBatchResponse } from "aws-lambda";
import { DynamoDBClient, UpdateItemCommand } from "@aws-sdk/client-dynamodb";

const ddb = new DynamoDBClient({});

export const handler: SQSHandler = async (event): Promise<SQSBatchResponse> => {
  const failures: { itemIdentifier: string }[] = [];

  for (const record of event.Records) {
    try {
      const body = JSON.parse(record.body);
      await validateWithIdempotency(body);
    } catch (err) {
      // 部分的バッチ応答: 失敗したレコードのみ返す
      failures.push({ itemIdentifier: record.messageId });
    }
  }

  return { batchItemFailures: failures };
};

async function validateWithIdempotency(payload: {
  orderId: string;
  items: Array<{ sku: string; qty: number }>;
}) {
  // Conditional Write で冪等性担保
  await ddb.send(
    new UpdateItemCommand({
      TableName: process.env.INVENTORY_TABLE!,
      Key: { PK: { S: `ORDER#${payload.orderId}` } },
      ConditionExpression: "attribute_not_exists(PK)",
      UpdateExpression: "SET #st = :processing, updatedAt = :now",
      ExpressionAttributeNames: { "#st": "status" },
      ExpressionAttributeValues: {
        ":processing": { S: "PROCESSING" },
        ":now": { S: new Date().toISOString() },
      },
    })
  );
  // 実際の在庫チェックロジック...
}

---

AWS Transform エージェントを使う上での注意点

実際に使ってみて気づいた注意点をまとめます。

差分は必ず人間がレビューする

Transform エージェントが生成する差分は「機械的に正しい変換」であっても、ビジネスロジックの暗黙的な前提（特定のテーブルに特定のインデックスが存在する、など）を考慮していない場合があります。必ず実際のテストを通してから本番に適用してください。

Terraform state の扱いに注意

Lambda を分割すると、Terraform の リソース名（アドレス） が変わります。terraform state mv で移動しないと、既存リソースが削除・再作成されます。Claude Code に terraform state mv コマンドも一緒に生成させる習慣をつけると安全です。

上記の Terraform モジュール分割に伴い、
terraform state mv コマンドを全量生成してください。
旧: module.api_lambdas
新: module.lambda_orders, module.lambda_inventory, ...

ランタイムアップグレードは段階的に

Node.js 16 → 22 のような 2 メジャーバージョン跨ぎは、aws-sdk v2 → v3 の移行も伴う場合があります。Transform エージェントは require('aws-sdk') を @aws-sdk/* に書き換える差分も生成しますが、カスタムミドルウェアや Powertools を使っている場合は追加検証が必要です。

---

まとめ

AWS Transform エージェントが Claude・Cursor・Codex などの IDE エージェントに統合されたことで、インフラの移行・最適化作業をコンテキストスイッチなく開発フローに組み込めるようになりました。

• モノリス分解: 依存関係の可視化 → サービス境界の提案 → Terraform/コード分割を一気通貫で
• ランタイム移行: リポジトリ + AWS アカウント横断スキャン → 差分自動生成 → 人間がレビュー
• CLAUDE.md によるガードレール: エージェントの制約を明示することで、本番事故リスクを低減

前回記事が「コードを速く書く」という入り口だとすれば、今回は 「AI エージェントがインフラの変換・移行まで担う」 という出口の話です。Claude Code と AWS Transform の組み合わせは、まだ発展途上ですが、実務に組み込む価値は十分にあると感じています。

---

📚 参考書籍 / さらに学びたい方へ

• AWS Lambda実践ガイド 第2版 — Lambda 単体の挙動・デプロイ・運用を体系化。コールドスタートやランタイム比較の参考に
• AWSによるサーバーレスアーキテクチャ — Lambda + API Gateway + S3 を中心に据えたサーバーレス設計の解説書
• 実践Terraform AWSにおけるシステム設計とベストプラクティス — AWS リソースを Terraform で組む際の現場ノウハウ。state 分割やモジュール設計の章が有用

📖 著者の本 (PR)

※ 以下は本記事の著者自身が執筆した Kindle 書籍です。

• 仕様駆動開発 実践ガイド — Claude Code × 仕様駆動で 設計 → 実装 を段階的に検証する実践書。本記事のワークフローと相補的に読める
• AIエージェント実践ガイド — Claude CodeとGitHub Actionsで個人ワークフローを仕組み化する — Claude Code OAuth × GitHub Actions × MCP で個人ワークフローを仕組み化する技術書。前作『仕様駆動開発 実践ガイド』のシリーズ2作目

記事が役立ったら ❤️ や Zenn の Boost をお願いします。励みになります。
深掘りトピックは Zenn Books でも公開予定です。
個別相談は MENTA でも受け付けています (枠が空いている時のみ)。