Claude CodeでAWSデプロイ自動化：事故らない手順とCI/CD設計

「AWSへのデプロイ、全部やっといて」とClaude Codeに頼んだ初日、僕は本番アカウントに AdministratorAccess のロールを生やしていました。

動いたんです。cdk deploy は緑になったし、APIも200を返した。でも翌週、IAMの棚卸しでそのロールを見つけたとき、背筋が冷えました。GitHub Actionsからフルアクセスで本番に入れる穴を、自分で開けていたわけです。

このとき気づいたのは、AWSデプロイの自動化でいちばん危ないのは「動かないコード」じゃない、ということ。動いてしまう雑な構成のほうがずっと怖い。今日はその反省から組み直した、「小さく出して、安全に広げる」デプロイ自動化のフローを書きます。

この記事の要点

• AWSデプロイ自動化のキモは速さではなく、どこで止めて、どこを人間が握るかの設計
• 最初はLambda + API Gateway + CDKで十分。後からECSやS3に移れる「境界」だけ作っておく
• cdk diff を儀式にする。差分を読まずに deploy する習慣が、いちばんの事故原因
• GitHub ActionsはOIDCで一時認証にし、長期AWSキーをSecretsに置かない
• 戻し方（rollback）を先に決めてから出す。Lambdaなら git revert で十分回る

デプロイ自動化を「フロー」で考える

個別の道具（CDK、Actions、IAM）の使い方を覚える前に、デプロイ全体をひとつの流れとして見ておくと、Claude Codeへの任せ方がブレません。

僕がいま回しているフローはこうです。

1. 書く：Claude CodeにCDKコードを生成させる（ただし制約付き、後述）
2. 見る：npm test → cdk synth → cdk diff をローカルで通し、差分を人間が読む
3. 出す：main へのpushでGitHub Actionsが走り、OIDCで一時ログインしてデプロイ
4. 確かめる：ヘルスチェック、ログ、費用通知で「ちゃんと動いて、想定内のコスト」かを見る
5. 戻せる：壊れたら直近の良いコミットへ revert で戻す手順を、出す前に用意しておく

ポイントは、Claude Codeに任せるのは主に1番と、2番の「書く部分」だけ、ということです。差分を読む判断、本番に出すボタン、戻す決断は人間が握る。能力を渡すのと、権限を渡すのは別、という話です。ここを分けないと、冒頭の AdministratorAccess みたいな事故が起きます。

下は全体の絵です。GitHubから本番までが一本につながっているのが分かると思います。

flowchart LR
  Dev[開発者 + Claude Code] --> PR[Pull Request]
  PR --> Diff[cdk diff を人間が確認]
  Diff --> Main[main にマージ]
  Main --> GHA[GitHub Actions OIDC]
  GHA --> CDK[AWS CDK deploy]
  CDK --> Api[API Gateway]
  Api --> Fn[Lambda Node.js API]
  Fn --> Secret[Secrets Manager]
  Fn --> Logs[CloudWatch Logs]
  Budget[AWS Budgets] -.費用通知.-> Dev

このフローの各段で「何を自動化し、どこで止めるか」を決めていきます。コンテナ常駐前提の構成はClaude Code × AWS ECS/Fargate完全ガイド、Lambda単体の関数設計やランタイムの細部はClaude Code × AWS Lambda完全ガイドに分けて書いたので、この記事は「デプロイの流れと安全な進め方」だけに集中します。

なぜ最初はLambda + API Gatewayでいいのか

「将来スケールするから」と、最初からECSやEKS、複雑なVPCを組みたくなる気持ちは分かります。でも、デプロイ自動化を学ぶ段階でそれをやると、CI/CDの本筋より周辺の設定で消耗します。

相談で僕が最初に勧めるのは、ほぼ「小さなAPIを安全に出す」形です。理由を表にしました。

構成	向いている用途	良い点	注意点
Lambda + API Gateway	小さなAPI、問い合わせフォーム、Webhook、軽い管理バックエンド	サーバー管理が少なく、低トラフィックで始めやすい	長時間処理、常時接続、大きなコンテナには不向き
ECS/Fargate + ALB	Docker化済みAPI、常時動くバックエンド、APIとバッチの混在	コンテナの自由度が高く、既存アプリを移しやすい	VPC、ALB、タスク定義、スケール設計が増える
Amplify / S3 + CloudFront	静的サイト、SPA、フロント中心のアプリ	配信が速く、CDNと相性が良い	API、認証、バックエンド処理は別設計が必要

この記事ではいちばん相談の多い「小さなAPIを安全に公開してCI/CDに乗せる」ケースに寄せ、Lambda + API Gateway + CDKで進めます。大事なのは、後からECSやS3へ移れる境界を最初から意識しておくこと。/v1/health や /v1/contact のような小さな入り口で切っておけば、移行のとき迷子になりません。

Claude Codeに「自由に作らせない」ための制約

ここがいちばん効きます。Claude CodeはAWSのコードを驚くほど速く書きますが、放っておくとワイルドカード権限や過剰な構成を平気で混ぜてきます。冒頭の AdministratorAccess も、僕が制約を書かずに「いい感じにデプロイして」と丸投げした結果でした。

なので、リポジトリの CLAUDE.md にルールを書いて、足場（ハーネス）を先に固めます。エージェントに安全に仕事を任せる考え方そのものはAIに仕事を任せる“足場”の作り方にまとめたので、合わせて読むと意図が伝わると思います。

# AWS deployment rules

- Use AWS CDK v2 and TypeScript.
- Target region: ap-northeast-1 unless explicitly changed.
- Do not create VPC resources for this small API unless required.
- Prefer API Gateway + Lambda for the first release.
- Runtime secrets must come from AWS Secrets Manager, not plaintext env vars.
- Use IAM grants such as secret.grantRead(handler) instead of wildcard policies.
- Add CloudWatch log retention and reserved concurrency.
- Before deploy, run npm test, npx cdk synth, and npx cdk diff.
- Never paste AWS access keys into files or GitHub Secrets.

依頼するときも、ゴールと禁止事項を同じ文に入れます。「作って」だけだと、最短で動くが危ない構成に寄りがちなので、ガードレールを言葉で渡すわけです。

このリポジトリにCDK v2のSmallApiStackを追加してください。
API Gateway REST API + Lambda Node.js 20で /v1/health と /v1/contact を作ります。
Secrets Managerから prod/claude-code-demo/api を読みます。
Lambda実行ロールは必要最小限にし、CloudWatch Logsの保持期間、予約同時実行、API Gatewayのスロットリングも入れてください。
デプロイ用GitHub ActionsはOIDCだけを使い、長期AWSキーは使わないでください。
編集後に npm test, npx cdk synth, npx cdk diff の結果を説明してください。

このプロジェクト指示があるだけで、生成されるコードの「危なさ」がはっきり減ります。Claude Code自体の挙動や設定はClaude Code公式ドキュメントが一次情報なので、迷ったらそちらを当たってください。

CDKでデプロイ対象を組む

ここからは実際のコードです。ローカルにNode.js、AWS CLI v2、AWS CDK CLI、認証済みのAWSプロファイルが要ります。WindowsならGit BashかWSLで以下を実行すると、そのまま試せます。

mkdir claude-code-aws-api
cd claude-code-aws-api
npx cdk init app --language typescript
npm install @aws-sdk/client-secrets-manager
npm install --save-dev esbuild @types/aws-lambda
mkdir -p lambda
aws sts get-caller-identity

初回だけ、Lambdaが読む設定をSecrets Managerに作ります。APIキーやDBパスワードのような機密は平文の環境変数に置かず、Secrets Managerに寄せる。これはLambda環境変数の公式ドキュメントでも、認証トークンやAPIキーにはSecrets Managerの利用が推奨されています。

aws secretsmanager create-secret \
  --name prod/claude-code-demo/api \
  --secret-string '{"supportQueue":"aws-consulting"}' \
  --region ap-northeast-1

次にLambdaハンドラー lambda/handler.ts。問い合わせ内容はログに残しますが、本文やシークレットを丸ごと出さないのがコツです。ログは便利な反面、個人情報の置き場ではありません。

import type {
  APIGatewayProxyEvent,
  APIGatewayProxyResult,
} from "aws-lambda";
import {
  GetSecretValueCommand,
  SecretsManagerClient,
} from "@aws-sdk/client-secrets-manager";

const secrets = new SecretsManagerClient({});
let cachedConfig: Record<string, string> | undefined;

// シークレットは初回だけ取得してキャッシュする（毎回呼ぶと遅いし高い）
async function loadConfig(): Promise<Record<string, string>> {
  if (cachedConfig) return cachedConfig;

  const secretArn = process.env.SECRET_ARN;
  if (!secretArn) throw new Error("SECRET_ARN is not configured");

  const result = await secrets.send(
    new GetSecretValueCommand({ SecretId: secretArn }),
  );
  cachedConfig = JSON.parse(result.SecretString ?? "{}");
  return cachedConfig;
}

function json(statusCode: number, body: unknown): APIGatewayProxyResult {
  return {
    statusCode,
    headers: {
      "content-type": "application/json",
      "cache-control": "no-store",
    },
    body: JSON.stringify(body),
  };
}

export async function handler(
  event: APIGatewayProxyEvent,
): Promise<APIGatewayProxyResult> {
  try {
    // ヘルスチェック：デプロイ後の生存確認とCI/CDの動作確認に使う
    if (event.httpMethod === "GET" && event.path.endsWith("/v1/health")) {
      return json(200, {
        ok: true,
        stage: process.env.STAGE ?? "dev",
      });
    }

    if (event.httpMethod === "POST" && event.path.endsWith("/v1/contact")) {
      const body = JSON.parse(event.body ?? "{}") as {
        email?: string;
        message?: string;
      };

      if (!body.email || !body.message) {
        return json(400, { ok: false, message: "email and message required" });
      }

      const config = await loadConfig();
      const emailDomain = body.email.split("@")[1] ?? "unknown";

      // 本文は出さず、ドメインと長さだけ記録する（個人情報をログに残さない）
      console.log(
        JSON.stringify({
          event: "contact_received",
          emailDomain,
          messageLength: body.message.length,
        }),
      );

      return json(202, {
        ok: true,
        routedTo: config.supportQueue ?? "manual",
      });
    }

    return json(404, { ok: false, message: "not found" });
  } catch (error) {
    console.error("handler_error", error);
    return json(500, { ok: false, message: "internal error" });
  }
}

そしてCDKスタック lib/small-api-stack.ts。ここが「デプロイ対象の設計図」です。NodejsFunction はTypeScriptのLambdaをesbuildで束ねてくれるCDKの部品、appSecret.grantRead(handler) は「そのシークレットの読み取り権限だけ」を実行ロールに付ける書き方です。ワイルドカードを使わずに済むのがミソです。

import * as cdk from "aws-cdk-lib";
import * as apigateway from "aws-cdk-lib/aws-apigateway";
import * as iam from "aws-cdk-lib/aws-iam";
import * as lambda from "aws-cdk-lib/aws-lambda";
import * as nodejs from "aws-cdk-lib/aws-lambda-nodejs";
import * as logs from "aws-cdk-lib/aws-logs";
import * as secretsmanager from "aws-cdk-lib/aws-secretsmanager";
import { Construct } from "constructs";
import * as path from "path";

export class SmallApiStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    const appSecret = secretsmanager.Secret.fromSecretNameV2(
      this,
      "AppSecret",
      "prod/claude-code-demo/api",
    );

    const handler = new nodejs.NodejsFunction(this, "ApiHandler", {
      functionName: "claude-code-small-api-prod",
      entry: path.join(__dirname, "../lambda/handler.ts"),
      handler: "handler",
      runtime: lambda.Runtime.NODEJS_20_X,
      architecture: lambda.Architecture.ARM_64,
      memorySize: 256,
      timeout: cdk.Duration.seconds(10),
      logRetention: logs.RetentionDays.ONE_MONTH,
      reservedConcurrentExecutions: 20, // 暴走時の上限。費用ガードも兼ねる
      environment: {
        STAGE: "prod",
        SECRET_ARN: appSecret.secretArn,
      },
      bundling: {
        minify: true,
        sourceMap: true,
        externalModules: ["@aws-sdk/*"],
      },
    });

    // シークレットは「読み取りだけ」を付与（フルアクセスにしない）
    appSecret.grantRead(handler);

    handler.addToRolePolicy(
      new iam.PolicyStatement({
        actions: ["cloudwatch:PutMetricData"],
        resources: ["*"],
        conditions: {
          StringEquals: {
            "cloudwatch:namespace": "ClaudeCodeLab/SmallApi",
          },
        },
      }),
    );

    const api = new apigateway.RestApi(this, "SmallApi", {
      restApiName: "claude-code-small-api",
      cloudWatchRole: true,
      deployOptions: {
        stageName: "prod",
        metricsEnabled: true,
        loggingLevel: apigateway.MethodLoggingLevel.INFO,
        dataTraceEnabled: false, // 本番でtrueにすると本文がログに出る。必ずfalse
        throttlingRateLimit: 20,
        throttlingBurstLimit: 40,
      },
    });

    const v1 = api.root.addResource("v1");
    v1.addResource("health").addMethod(
      "GET",
      new apigateway.LambdaIntegration(handler),
    );

    v1.addResource("contact").addMethod(
      "POST",
      new apigateway.LambdaIntegration(handler),
      { apiKeyRequired: true },
    );

    const apiKey = api.addApiKey("ClientApiKey", {
      apiKeyName: "claude-code-small-api-prod-client",
    });

    const usagePlan = api.addUsagePlan("BasicUsagePlan", {
      throttle: { rateLimit: 10, burstLimit: 20 },
      quota: { limit: 1000, period: apigateway.Period.MONTH },
    });
    usagePlan.addApiKey(apiKey);
    usagePlan.addApiStage({ stage: api.deploymentStage });

    new cdk.CfnOutput(this, "ApiUrl", { value: api.url });
  }
}

bin/claude-code-aws-api.ts でスタック名を合わせます。

#!/usr/bin/env node
import * as cdk from "aws-cdk-lib";
import { SmallApiStack } from "../lib/small-api-stack";

const app = new cdk.App();

new SmallApiStack(app, "SmallApiProdStack", {
  env: {
    account: process.env.CDK_DEFAULT_ACCOUNT,
    region: process.env.CDK_DEFAULT_REGION ?? "ap-northeast-1",
  },
});

CDKの部品の正確な仕様はAWS CDKのNodejsFunction公式リファレンスに載っています。Claude Codeに書かせたコードは、ここと突き合わせて確認すると安心です。

deployの前に、必ずdiffを読む

ここが僕のフローでいちばん大事な儀式です。cdk diff を読まずに deploy する習慣が、事故の温床でした。

初回だけCDKのbootstrap（デプロイ用のS3バケットやロールを準備する作業）が要ります。

export AWS_REGION=ap-northeast-1
export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)

npx cdk bootstrap "aws://${AWS_ACCOUNT_ID}/${AWS_REGION}"
npm test
npx cdk synth
npx cdk diff SmallApiProdStack
npx cdk deploy SmallApiProdStack --require-approval never

cdk diff ではIAMポリシー、API Gateway、Lambda名、ログ保持、予約同時実行を目で追います。とくにIAMの行は、ワイルドカード（*）が出ていないかを確認する。ここで「なぜこの権限が要るのか」をClaude Codeに説明させると、不要な権限に気づきやすくなります。僕は冒頭の事故以来、IAM最小権限の詰め方をClaude Code × AWS IAMガイドに分けてまとめ、diffレビューの拠り所にしています。

デプロイ後は出力されたURLにヘルスチェックを投げ、ログを確認します。

API_URL=$(aws cloudformation describe-stacks \
  --stack-name SmallApiProdStack \
  --query "Stacks[0].Outputs[?OutputKey=='ApiUrl'].OutputValue" \
  --output text)

curl "${API_URL}v1/health"

aws logs tail "/aws/lambda/claude-code-small-api-prod" \
  --since 1h \
  --follow

CloudWatchのログは表示まで数分かかることがあります。すぐ見えないだけで失敗と決めつけて、慌てて直しにいかないこと。これも一度やらかしました。

GitHub ActionsでOIDCデプロイ：長期キーを置かない

手元でフローが固まったら、CI/CDに乗せます。ここで冒頭の反省が効いてきます。GitHub ActionsにAWSアクセスキーを保存しない。代わりにAWS側にGitHub OIDCプロバイダーとデプロイ用ロールを作り、信頼ポリシーを「このリポジトリの、このブランチだけ」に絞ります。

信頼ポリシーの例です。your-org、your-repo、アカウントIDは置き換えてください。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:your-org/your-repo:ref:refs/heads/main"
        }
      }
    }
  ]
}

ワークフロー .github/workflows/deploy-aws.yml はこの形です。手元でやっていた test → synth → diff → deploy を、そのままパイプラインに写しているのが分かると思います。

name: deploy-aws-cdk

on:
  push:
    branches: ["main"]
  workflow_dispatch:

permissions:
  id-token: write   # OIDCで一時認証を取るのに必須
  contents: read

concurrency:
  group: prod-aws-cdk
  cancel-in-progress: false   # デプロイ中の取り消しで中途半端な状態にしない

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-cdk-deploy-prod
          aws-region: ap-northeast-1

      - run: npm ci
      - run: npm test
      - run: npx cdk synth
      - run: npx cdk diff SmallApiProdStack
      - run: npx cdk deploy SmallApiProdStack --require-approval never

デプロイロールの権限は、CDK bootstrapロール、CloudFormation実行ロール、権限境界のどれを使うかで変わります。会社のAWS管理方針に依存する部分なので、「とりあえず AdministratorAccess」は本番では避ける——これは僕が痛い目を見た当人として強く言います。IAMベストプラクティスに沿って、Access Analyzerや権限境界で少しずつ削るのが現実的です。

費用と戻し方を、出す前に決めておく

自動化で怖いのは、自分が寝ている間に呼び出しが膨らむことです。無限ループやスパムで請求が伸びても、Actionsは黙々と回ります。だから費用のガードレールと、戻す手順は「出す前」に用意します。

このCDKでは既にAPI Gatewayのスロットリング、使用量プラン、Lambdaの予約同時実行を入れています。これに加えてAWS Budgetsで月額の通知を作ります。

{
  "BudgetName": "small-api-monthly-guardrail",
  "BudgetLimit": {
    "Amount": "20",
    "Unit": "USD"
  },
  "TimeUnit": "MONTHLY",
  "BudgetType": "COST"
}

[
  {
    "Notification": {
      "NotificationType": "ACTUAL",
      "ComparisonOperator": "GREATER_THAN",
      "Threshold": 80,
      "ThresholdType": "PERCENTAGE"
    },
    "Subscribers": [
      {
        "SubscriptionType": "EMAIL",
        "Address": "[email protected]"
      }
    ]
  }
]

aws budgets create-budget \
  --account-id "$AWS_ACCOUNT_ID" \
  --budget file://budget.json \
  --notifications-with-subscribers file://notifications-with-subscribers.json

Budgetsはグラフや通知の反映に時間がかかることがあるので、本番投入の前に余裕をもって設定しておきます。

戻し方は、最初の運用なら凝ったBlue/Greenより「最後に動いたコミットへ戻す」を明文化するほうが効きます。Lambda + API Gatewayはこれで十分回ります。

git revert <bad-commit-sha>
git push origin main

pushでActionsが再デプロイしたら、ヘルスチェックとスタックイベント、ログで復旧を確認します。

curl "${API_URL}v1/health"
aws cloudformation describe-stack-events \
  --stack-name SmallApiProdStack \
  --max-items 20
aws logs tail "/aws/lambda/claude-code-small-api-prod" --since 30m

僕がやらかしたデプロイ事故3つ

正直に書きます。安全なフローに落ち着くまで、けっこう転びました。

ひとつ目は冒頭の AdministratorAccess ロール。Claude Codeに制約を渡さず「デプロイして」と丸投げした結果です。今は CLAUDE.md のルールと、diffでのIAM目視がセットになっています。

ふたつ目は、AWSコンソールでの手修正。デプロイが微妙にコケたとき、つい画面でポチポチ直してしまった。次の cdk diff がコンソール変更とぶつかって意味不明になり、何が正しい状態か分からなくなりました。直すなら必ずコードで直す、を徹底しています。

みっつ目は、dataTraceEnabled を本番でtrueにしたこと。デバッグのつもりで有効化したら、リクエスト本文がそのままCloudWatchに流れていました。問い合わせフォームの本文がログに残るのは、普通に事故です。このCDKでは false に固定しています。

デプロイ前にClaude Codeへ投げるレビュー依頼

最後の門番として、デプロイ前にClaude Code自身へレビューを頼みます。ただし「問題なさそう」では受け取らない。ファイル名と根拠を必ず出させます。

AWSデプロイ前レビューをしてください。
確認対象:
- CDK diffで追加されるIAM権限に過剰なワイルドカードがないか
- LambdaがSecrets Manager以外から秘密情報を読んでいないか
- API Gatewayのスロットリング、使用量プラン、ログ設定があるか
- CloudWatch Logsに個人情報や本文を出していないか
- rollback手順がREADMEか運用メモにあるか
- npm test, cdk synth, cdk diff が通っているか

問題があれば severity, file, line, fix を表で出してください。

このレビューは最終判断ではありません。AWSアカウントの境界、会社のセキュリティルール、料金の影響は人間が決めます。それでも、レビューの入口を自動化しておくと、同じミスを繰り返す確率はちゃんと下がります。

よくある質問

Q. SAMやServerless Frameworkではなく、なぜCDKなんですか？ A. TypeScriptで普通のコードとしてインフラを書けて、Claude Codeとの相性がいいからです。型があるぶん生成コードのミスに気づきやすく、cdk diff で差分が読める。SAMでも同じフロー（test → diff相当 → deploy）は組めるので、チームが慣れたツールがあるならそれで構いません。

Q. --require-approval never を付けて大丈夫？ A. ローカルやCIで使う前提です。代わりに、その手前で cdk diff を必ず実行し、人間（CIならPRレビュー）が差分を読むのが条件。承認を省くなら、別の場所で目視を残すのがセットです。

Q. OIDCの設定が面倒です。長期キーをSecretsに入れるのは本当にダメ？ A. 漏れたときの被害がまるで違います。長期キーは漏れたら無効化するまで使われ続けますが、OIDCの一時認証は短時間で失効し、しかも「このリポジトリのこのブランチ」に縛れる。最初の設定だけ我慢する価値はあります。

Q. 小さく始めたあと、ECSやS3にはどう移るんですか？ A. /v1/... という入り口を保ったまま、裏側の実装をLambdaからコンテナに差し替えます。常時稼働やDockerが必要になったらECS/Fargateガイド、フロント配信中心ならS3 + CloudFrontへ。境界を小さく切ってあれば、呼び出し側を壊さず移れます。

Q. デプロイが失敗したとき、まずどこを見れば？ A. cdk diff の出力、describe-stack-events、CloudWatch Logsの順です。Claude Codeはログの最後の行だけ見て見当違いを直しがちなので、「どのコマンドのどこを見るか」を先に決めておくと、修正が速くなります。

実際に試した結果

冒頭の AdministratorAccess 事故から組み直して分かったのは、AWSデプロイ自動化の価値はCDKを速く書くことじゃない、ということです。サービス選定、IaC、CI/CD、IAM、ログ、費用、ロールバックを「ひとつの流れ」にまとめ、各段でどこを人間が握るかを決める——そこに価値がありました。

実感として、MVPの問い合わせAPIくらいなら、CDKスタックからGitHub Actions、ログ確認、費用通知までを半日から1日で形にできます。一方で、IAMロールとシークレット設計を雑にすると、あとで必ず手戻りします。Claude Codeには実装を速くやらせ、人間は権限・費用・障害時の判断を握る。この分担に落ち着いてから、夜中に請求やIAMでヒヤッとすることが、ほぼなくなりました。

自分のリポジトリ、AWSアカウント構成、デプロイの失敗履歴を見ながら、このフローをチームに合わせて組みたい人は、Claude Code導入・開発自動化の相談からどうぞ。既存の構成と失敗ログを一緒に見て、実装できる改善案まで落とし込みます。