Claude Code × AWS API Gateway 完全ガイド|REST API設計からデプロイ自動化まで

API Gateway 設計工数が 1/3 になった話

claudecode-lab.com を運営している Masa です。副業でバックエンド開発をしていた頃、AWS API Gateway の設計と実装は「地味に時間がかかる作業」の筆頭でした。エンドポイントの設計書を書き、CloudFormation テンプレートに落とし、Lambda の統合設定を手作業で入れ、CORS を設定して……毎回同じ失敗を繰り返していました。

転機は半年前、Claude Code に「このユースケースをもとに REST API を設計して CDK で実装して」と投げてみたことです。驚くほど実用的な構成が出てきて、API Gateway 関連の実装工数がそれ以降 1/3 になりました。

CORS 設定忘れ、Lambda 権限エラー、タイムアウトのハマりどころも「Claude Code に最初から注意してもらえる」ようになってから、レビューで指摘される数も激減しています。

この記事では、私が実際に業務で使っている Claude Code × API Gateway のパターンを Step ごとに公開します。

なぜ API Gateway 設計に Claude Code が向いているのか

API Gateway の設計には「知識は要らないが、定型作業が多い」という特徴があります。

エンドポイント命名規則 (名詞の複数形、階層構造)
HTTP メソッドの使い分け (GET/POST/PUT/PATCH/DELETE)
リクエスト/レスポンスのスキーマ定義
Lambda 統合のパス変数マッピング
CORS ヘッダーの設定 (毎回忘れる)
ステージ変数の管理 (dev/staging/prod)

これらはルールが決まっており、ドキュメントを参照しながら手で書けば誰でもできますが、Claude Code に「このユースケースの REST API を設計して CDK で書いて」と頼むと数分で完成します。

Claude Code が特に得意なのは「設計の整合性チェック」です。「このエンドポイント設計でRESTの原則に違反している箇所を指摘して」と聞けば、idempotency の問題や URL 設計の一貫性の問題を即座に指摘してくれます。

Step 1: REST API エンドポイント設計を Claude Code に依頼

まず、実装前に Claude Code にエンドポイント設計を任せます。

プロンプト例

以下のユースケースに基づいて REST API のエンドポイント設計書を作って。

ユースケース:
- タスク管理アプリ (ユーザーがプロジェクトとタスクを管理)
- ユーザー認証あり (Cognito)
- プロジェクトにはメンバーを追加できる
- タスクにはコメントとファイル添付がある

出力形式:
- エンドポイント一覧 (メソッド・パス・説明)
- リクエスト/レスポンスの JSON スキーマ
- 認証が必要なエンドポイントの明示
- RESTの原則に違反する点があれば指摘して

Claude Code が生成するエンドポイント設計

# タスク管理 API エンドポイント設計

## 認証
POST   /auth/login          - ログイン (公開)
POST   /auth/refresh        - トークンリフレッシュ (公開)
DELETE /auth/logout         - ログアウト (認証必須)

## プロジェクト
GET    /projects            - プロジェクト一覧 (認証必須)
POST   /projects            - プロジェクト作成 (認証必須)
GET    /projects/{id}       - プロジェクト詳細 (認証必須)
PUT    /projects/{id}       - プロジェクト更新 (認証必須)
DELETE /projects/{id}       - プロジェクト削除 (認証必須)

## プロジェクトメンバー
GET    /projects/{id}/members       - メンバー一覧
POST   /projects/{id}/members       - メンバー追加
DELETE /projects/{id}/members/{uid} - メンバー削除

## タスク
GET    /projects/{id}/tasks         - タスク一覧
POST   /projects/{id}/tasks         - タスク作成
GET    /tasks/{taskId}              - タスク詳細
PUT    /tasks/{taskId}              - タスク更新
DELETE /tasks/{taskId}             - タスク削除

## コメント
GET    /tasks/{taskId}/comments     - コメント一覧
POST   /tasks/{taskId}/comments     - コメント作成
DELETE /tasks/{taskId}/comments/{commentId} - コメント削除

## ファイル添付
POST   /tasks/{taskId}/attachments  - 署名付きURL取得 (S3直接アップロード用)
GET    /tasks/{taskId}/attachments  - 添付ファイル一覧
DELETE /tasks/{taskId}/attachments/{attachmentId} - 添付削除

この設計を叩き台にして「/tasks/{taskId} へのアクセスはそのプロジェクトのメンバーのみに制限すべきでは?」などの議論ができます。

Step 2: Lambda 統合設定の自動生成

エンドポイント設計ができたら、Lambda との統合設定を生成します。

プロンプト

上のエンドポイント設計をもとに、AWS CDK (TypeScript) で API Gateway REST API を構築して。
- Lambda 統合 (プロキシ統合を使う)
- 各エンドポイントに対応する Lambda 関数のスタブも作成
- プロキシリソース ({proxy+}) は使わず、各エンドポイントを明示的に定義
- リクエストバリデーターをAPI Gatewayレベルで設定

生成される CDK スタック (抜粋)

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

export class TaskApiStack extends cdk.Stack {
  public readonly api: apigateway.RestApi;

  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // ===== Lambda 関数の定義 =====
    const createLambda = (name: string, handler: string) =>
      new nodejs.NodejsFunction(this, name, {
        entry: `src/handlers/${handler}.ts`,
        handler: "handler",
        runtime: lambda.Runtime.NODEJS_20_X,
        environment: {
          STAGE: props?.env?.region ?? "dev",
          // 共通環境変数はここに追加
        },
        timeout: cdk.Duration.seconds(29), // API Gateway の最大タイムアウト
        memorySize: 256,
        bundling: {
          minify: true,
          sourceMap: true,
          // Lambda Layers を使う場合は externalModules に追加
          externalModules: ["@aws-sdk/*"],
        },
      });

    // Lambda 関数群
    const listProjectsFn = createLambda("ListProjects", "projects/list");
    const createProjectFn = createLambda("CreateProject", "projects/create");
    const getProjectFn = createLambda("GetProject", "projects/get");
    const updateProjectFn = createLambda("UpdateProject", "projects/update");
    const deleteProjectFn = createLambda("DeleteProject", "projects/delete");
    const listTasksFn = createLambda("ListTasks", "tasks/list");
    const createTaskFn = createLambda("CreateTask", "tasks/create");
    const getTaskFn = createLambda("GetTask", "tasks/get");
    const updateTaskFn = createLambda("UpdateTask", "tasks/update");
    const deleteTaskFn = createLambda("DeleteTask", "tasks/delete");

    // ===== REST API の定義 =====
    this.api = new apigateway.RestApi(this, "TaskApi", {
      restApiName: "task-management-api",
      description: "Task Management REST API",
      // デフォルトのCORS設定 (全リソースに適用)
      defaultCorsPreflightOptions: {
        allowOrigins: apigateway.Cors.ALL_ORIGINS, // 本番では制限すること
        allowMethods: apigateway.Cors.ALL_METHODS,
        allowHeaders: [
          "Content-Type",
          "Authorization",
          "X-Api-Key",
        ],
      },
      // リクエストバリデーター
      defaultMethodOptions: {
        requestValidatorOptions: {
          validateRequestBody: true,
          validateRequestParameters: true,
        },
      },
      deployOptions: {
        stageName: "v1",
        // アクセスログの有効化
        accessLogDestination: new apigateway.LogGroupLogDestination(
          new cdk.aws_logs.LogGroup(this, "ApiAccessLog", {
            retention: cdk.aws_logs.RetentionDays.ONE_MONTH,
          })
        ),
        loggingLevel: apigateway.MethodLoggingLevel.INFO,
        dataTraceEnabled: false, // 本番では false (ログにリクエスト本文が出ないように)
      },
    });

    // ===== リソース & メソッドの定義 =====
    const projects = this.api.root.addResource("projects");
    projects.addMethod("GET", new apigateway.LambdaIntegration(listProjectsFn));
    projects.addMethod("POST", new apigateway.LambdaIntegration(createProjectFn));

    const project = projects.addResource("{id}");
    project.addMethod("GET", new apigateway.LambdaIntegration(getProjectFn));
    project.addMethod("PUT", new apigateway.LambdaIntegration(updateProjectFn));
    project.addMethod("DELETE", new apigateway.LambdaIntegration(deleteProjectFn));

    // タスク (プロジェクト配下)
    const projectTasks = project.addResource("tasks");
    projectTasks.addMethod("GET", new apigateway.LambdaIntegration(listTasksFn));
    projectTasks.addMethod("POST", new apigateway.LambdaIntegration(createTaskFn));

    // タスク (トップレベル, タスク詳細取得・更新・削除用)
    const tasks = this.api.root.addResource("tasks");
    const task = tasks.addResource("{taskId}");
    task.addMethod("GET", new apigateway.LambdaIntegration(getTaskFn));
    task.addMethod("PUT", new apigateway.LambdaIntegration(updateTaskFn));
    task.addMethod("DELETE", new apigateway.LambdaIntegration(deleteTaskFn));

    // API エンドポイントを出力
    new cdk.CfnOutput(this, "ApiUrl", {
      value: this.api.url,
      description: "API Gateway URL",
    });
  }
}

Lambda ハンドラーのスタブ

// src/handlers/projects/list.ts
import { APIGatewayProxyHandler } from "aws-lambda";

export const handler: APIGatewayProxyHandler = async (event) => {
  // event.requestContext.authorizer から認証情報を取得
  const userId = event.requestContext.authorizer?.claims?.sub;

  try {
    // TODO: DynamoDB からプロジェクト一覧を取得
    const projects: unknown[] = [];

    return {
      statusCode: 200,
      headers: {
        "Content-Type": "application/json",
        // CORS ヘッダー (プロキシ統合の場合はここでも設定)
        "Access-Control-Allow-Origin": "*",
      },
      body: JSON.stringify({ projects }),
    };
  } catch (err) {
    console.error("Error listing projects:", err);
    return {
      statusCode: 500,
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ message: "Internal server error" }),
    };
  }
};

Step 3: 認証設定 (Cognito / Lambda Authorizer / API Key)

API Gateway の認証は3つのパターンがあります。Claude Code にユースケースを説明すれば最適な選択肢を提案してくれます。

認証方式の選択プロンプト

以下のケースに最適なAPI Gateway認証方式を推薦して、理由とCDK実装を教えて:
- BtoCのモバイルアプリ向けAPI (ユーザー認証必須)
- サードパーティへのAPI公開 (API Key管理)
- 社内ツール (既存のActive Directory認証を流用したい)

パターン1: Cognito User Pool Authorizer (BtoC 向け)

// Cognito User Pool を使った認証 (CDK)
import * as cognito from "aws-cdk-lib/aws-cognito";

const userPool = new cognito.UserPool(this, "UserPool", {
  userPoolName: "task-app-users",
  selfSignUpEnabled: true,
  signInAliases: { email: true },
  passwordPolicy: {
    minLength: 8,
    requireLowercase: true,
    requireUppercase: true,
    requireDigits: true,
    requireSymbols: false,
  },
  accountRecovery: cognito.AccountRecovery.EMAIL_ONLY,
});

const userPoolClient = userPool.addClient("AppClient", {
  authFlows: {
    userPassword: true,
    userSrp: true,
  },
  // アクセストークンの有効期限
  accessTokenValidity: cdk.Duration.hours(1),
  refreshTokenValidity: cdk.Duration.days(30),
});

// API Gateway に Cognito Authorizer を設定
const cognitoAuthorizer = new apigateway.CognitoUserPoolsAuthorizer(
  this,
  "CognitoAuthorizer",
  {
    cognitoUserPools: [userPool],
    identitySource: "method.request.header.Authorization",
    // 認証結果のキャッシュ時間 (コスト削減)
    resultsCacheTtl: cdk.Duration.minutes(5),
  }
);

// 認証が必要なメソッドに適用
projects.addMethod("GET", new apigateway.LambdaIntegration(listProjectsFn), {
  authorizer: cognitoAuthorizer,
  authorizationType: apigateway.AuthorizationType.COGNITO,
});

パターン2: Lambda Authorizer (カスタム認証)

// Lambda Authorizer の実装 (既存 JWT や独自トークンを検証)
// src/handlers/auth/authorizer.ts
import {
  APIGatewayAuthorizerResult,
  APIGatewayTokenAuthorizerHandler,
} from "aws-lambda";
import * as jwt from "jsonwebtoken";

export const handler: APIGatewayTokenAuthorizerHandler = async (event) => {
  const token = event.authorizationToken.replace("Bearer ", "");

  try {
    // JWT を検証 (公開鍵はパラメータストアから取得するのがベスト)
    const decoded = jwt.verify(token, process.env.JWT_SECRET!) as {
      sub: string;
      email: string;
      role: string;
    };

    return generatePolicy(decoded.sub, "Allow", event.methodArn, {
      userId: decoded.sub,
      email: decoded.email,
      role: decoded.role,
    });
  } catch {
    // 認証失敗時は "Unauthorized" を投げる (401 が返る)
    throw new Error("Unauthorized");
  }
};

function generatePolicy(
  principalId: string,
  effect: "Allow" | "Deny",
  resource: string,
  context?: Record<string, string>
): APIGatewayAuthorizerResult {
  return {
    principalId,
    policyDocument: {
      Version: "2012-10-17",
      Statement: [
        {
          Action: "execute-api:Invoke",
          Effect: effect,
          // ワイルドカードを使うとキャッシュの恩恵を最大化できる
          Resource: resource.replace(/\/[^/]+\/[^/]+$/, "/*/*"),
        },
      ],
    },
    context, // ハンドラー側で event.requestContext.authorizer から参照できる
  };
}

// CDK で Lambda Authorizer を設定
const authorizerFn = createLambda("LambdaAuthorizer", "auth/authorizer");

const lambdaAuthorizer = new apigateway.TokenAuthorizer(
  this,
  "LambdaAuthorizer",
  {
    handler: authorizerFn,
    identitySource: "method.request.header.Authorization",
    resultsCacheTtl: cdk.Duration.minutes(5),
  }
);

パターン3: API Key (サードパーティ向け)

// API Key の作成と使用量プランの設定
const apiKey = this.api.addApiKey("PartnerApiKey", {
  apiKeyName: "partner-v1-key",
  description: "API Key for partner integration",
});

const usagePlan = this.api.addUsagePlan("PartnerUsagePlan", {
  name: "PartnerPlan",
  throttle: {
    rateLimit: 100,   // 1秒あたりのリクエスト数
    burstLimit: 200,  // バーストリクエスト数
  },
  quota: {
    limit: 10000,     // 1日あたりのリクエスト数
    period: apigateway.Period.DAY,
  },
});

usagePlan.addApiKey(apiKey);
usagePlan.addApiStage({ stage: this.api.deploymentStage });

Step 4: CDK でのインフラ実装

ここまでの設計を整理して、本番で使える CDK スタック構成にします。

プロジェクト構造

my-api/
├── bin/
│   └── my-api.ts          # CDK エントリーポイント
├── lib/
│   ├── api-stack.ts       # API Gateway + Lambda スタック
│   ├── auth-stack.ts      # Cognito スタック
│   └── database-stack.ts  # DynamoDB スタック
├── src/
│   └── handlers/
│       ├── projects/
│       │   ├── list.ts
│       │   ├── create.ts
│       │   ├── get.ts
│       │   ├── update.ts
│       │   └── delete.ts
│       └── tasks/
│           └── ...
├── package.json
├── tsconfig.json
└── cdk.json

bin/my-api.ts (エントリーポイント)

#!/usr/bin/env node
import "source-map-support/register";
import * as cdk from "aws-cdk-lib";
import { ApiStack } from "../lib/api-stack";
import { AuthStack } from "../lib/auth-stack";

const app = new cdk.App();

// 環境 (dev/staging/prod) は CDK_ENV 環境変数で切り替え
const env = process.env.CDK_ENV ?? "dev";

const authStack = new AuthStack(app, `Auth-${env}`, {
  env: { region: "ap-northeast-1" },
});

new ApiStack(app, `Api-${env}`, {
  env: { region: "ap-northeast-1" },
  userPool: authStack.userPool, // スタック間の参照
  stageName: env,
});

Lambda の IAM ロール設定

// DynamoDB へのアクセス権限を Lambda に付与
import * as dynamodb from "aws-cdk-lib/aws-dynamodb";
import * as iam from "aws-cdk-lib/aws-iam";

const projectsTable = new dynamodb.Table(this, "ProjectsTable", {
  tableName: `projects-${stageName}`,
  partitionKey: { name: "pk", type: dynamodb.AttributeType.STRING },
  sortKey: { name: "sk", type: dynamodb.AttributeType.STRING },
  billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,
  // 本番環境では RETAIN を推奨
  removalPolicy:
    stageName === "prod"
      ? cdk.RemovalPolicy.RETAIN
      : cdk.RemovalPolicy.DESTROY,
});

// Lambda 関数に DynamoDB 権限を付与
projectsTable.grantReadWriteData(listProjectsFn);
projectsTable.grantReadWriteData(createProjectFn);
projectsTable.grantReadData(getProjectFn); // 読み取り専用
projectsTable.grantReadWriteData(updateProjectFn);
projectsTable.grantReadWriteData(deleteProjectFn);

Step 5: ステージ管理 (dev/staging/prod)

環境ごとの設定分離

// lib/config.ts — 環境設定の一元管理
export type Stage = "dev" | "staging" | "prod";

interface StageConfig {
  logLevel: "ERROR" | "INFO" | "DEBUG";
  throttleRateLimit: number;
  throttleBurstLimit: number;
  corsOrigins: string[];
  enableDataTrace: boolean;
}

export const stageConfig: Record<Stage, StageConfig> = {
  dev: {
    logLevel: "DEBUG",
    throttleRateLimit: 10,
    throttleBurstLimit: 20,
    corsOrigins: ["http://localhost:3000", "http://localhost:5173"],
    enableDataTrace: true, // 開発中はリクエスト本文をログに出す
  },
  staging: {
    logLevel: "INFO",
    throttleRateLimit: 50,
    throttleBurstLimit: 100,
    corsOrigins: ["https://staging.example.com"],
    enableDataTrace: false,
  },
  prod: {
    logLevel: "ERROR",
    throttleRateLimit: 1000,
    throttleBurstLimit: 2000,
    corsOrigins: ["https://example.com", "https://app.example.com"],
    enableDataTrace: false,
  },
};

// CDK スタックでの使用例
import { stageConfig, Stage } from "./config";

const stage = (process.env.CDK_ENV ?? "dev") as Stage;
const config = stageConfig[stage];

this.api = new apigateway.RestApi(this, "TaskApi", {
  defaultCorsPreflightOptions: {
    allowOrigins: config.corsOrigins,
    allowMethods: apigateway.Cors.ALL_METHODS,
    allowHeaders: ["Content-Type", "Authorization"],
  },
  deployOptions: {
    stageName: stage === "prod" ? "v1" : stage,
    loggingLevel: apigateway.MethodLoggingLevel.INFO,
    dataTraceEnabled: config.enableDataTrace,
    throttlingRateLimit: config.throttleRateLimit,
    throttlingBurstLimit: config.throttleBurstLimit,
  },
});

デプロイコマンド

# 開発環境へのデプロイ
CDK_ENV=dev npx cdk deploy Api-dev --require-approval never

# ステージング環境
CDK_ENV=staging npx cdk deploy Api-staging

# 本番環境 (変更の確認あり)
CDK_ENV=prod npx cdk deploy Api-prod

# 差分確認 (デプロイ前に必ず実行)
CDK_ENV=prod npx cdk diff Api-prod

落とし穴4選

API Gateway を使っていて実際に遭遇した、地味に厄介な落とし穴です。Claude Code に最初から「これらを避けるように実装して」と伝えておくと、事前に対処してくれます。

落とし穴1: CORS の設定漏れ (最頻出)

症状: ブラウザから fetch() でAPIを叩くと CORS error が発生。Postman では問題ない。

原因: API Gateway で CORS を有効にしていても、Lambda (プロキシ統合) がレスポンスに CORS ヘッダーを返す責任を持つため、Lambda 側でもヘッダーを設定する必要があります。

// ❌ これだけでは不十分 (API Gateway 側の設定のみ)
defaultCorsPreflightOptions: {
  allowOrigins: apigateway.Cors.ALL_ORIGINS,
}

// ✅ Lambda のレスポンスにも必ず CORS ヘッダーを追加
return {
  statusCode: 200,
  headers: {
    "Content-Type": "application/json",
    "Access-Control-Allow-Origin": "https://example.com", // 本番では明示的に指定
    "Access-Control-Allow-Credentials": "true", // Cookie を使う場合
  },
  body: JSON.stringify(data),
};

Claude Code へのプロンプト: 「Lambda プロキシ統合の場合の CORS ヘッダーをすべてのレスポンスに追加する共通関数を作って」

落とし穴2: Lambda 実行権限の設定忘れ

症状: {"message": "Internal server error"} が返る。CloudWatch ログに AccessDeniedException が出ている。

原因: API Gateway が Lambda を呼び出す権限が付与されていない。CDK の LambdaIntegration を使えば自動で付与されますが、手動でリソースを追加した場合に忘れがちです。

// CDK では LambdaIntegration が自動で権限を付与するが
// 手動で権限を確認・追加したい場合
listProjectsFn.addPermission("ApiGatewayInvoke", {
  principal: new iam.ServicePrincipal("apigateway.amazonaws.com"),
  sourceArn: this.api.arnForExecuteApi("GET", "/projects", "v1"),
});

落とし穴3: 29秒タイムアウト制限

症状: 30秒以上かかる処理が突然 {"message": "Endpoint request timed out"} で失敗する。

原因: API Gateway の統合タイムアウトは最大 29 秒です。これは緩和できません。

解決策: 時間のかかる処理は非同期化します。

// ✅ 非同期処理パターン: ジョブIDを返してポーリングさせる
// POST /export → jobId を即座に返す
export const startExport: APIGatewayProxyHandler = async (event) => {
  const jobId = crypto.randomUUID();

  // SQS にジョブをキューイング
  await sqsClient.send(
    new SendMessageCommand({
      QueueUrl: process.env.JOB_QUEUE_URL!,
      MessageBody: JSON.stringify({ jobId, params: JSON.parse(event.body!) }),
    })
  );

  return {
    statusCode: 202, // Accepted
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ jobId, status: "processing" }),
  };
};

// GET /export/{jobId}/status → ジョブの状態を返す
export const getExportStatus: APIGatewayProxyHandler = async (event) => {
  const { jobId } = event.pathParameters!;
  // DynamoDB からジョブの状態を取得して返す
  // ...
};

落とし穴4: リクエスト本文の変換 (マッピングテンプレート)

症状: Lambda が event.body を受け取れない。null が来る。

原因: プロキシ統合でない API Gateway 統合では、マッピングテンプレートが必要です。現代では基本的にプロキシ統合を使うべきですが、既存システムの改修時に混在することがあります。

// ✅ 必ずプロキシ統合を明示する
project.addMethod(
  "POST",
  new apigateway.LambdaIntegration(createProjectFn, {
    proxy: true, // デフォルトは true だが明示するとわかりやすい
  })
);

まとめ

Claude Code × AWS API Gateway で実現できることをまとめます。

タスク	Claude Code の活用ポイント	難易度
REST API 設計	ユースケースから設計書を自動生成、REST原則チェック	低
Lambda 統合 CDK	プロキシ統合・リソース定義を一括生成	低
Cognito 認証	User Pool・Authorizer・クライアント設定を生成	中
Lambda Authorizer	JWT検証・ポリシー生成を実装	中
ステージ管理	環境別設定の分離・デプロイコマンドを生成	中
非同期処理	SQS連携・ポーリングパターンを設計	高
CORS 設定	Lambda側のヘッダー設定を漏れなく生成	低

私が最も効果を感じたのは、「最初の設計書フェーズで Claude Code と壁打ちすること」です。「このエンドポイント設計で問題があれば指摘して」と聞くと、URL 命名の一貫性・べき等性・HTTP メソッドの使い分けなど、レビューで指摘されるような点を事前に洗い出してくれます。

実装工数が 1/3 になった最大の理由は「手戻りが減ったこと」でした。設計段階での品質が上がることで、実装後の修正が激減しています。

この記事で紹介した内容を業務プロジェクトで実践した結果: API Gateway の設計〜CDKデプロイまでの工数が従来の3日→1日に短縮。特に Cognito Authorizer まわりの実装は、以前は毎回 AWS ドキュメントを1時間以上読んでいた部分が、Claude Code への 1つのプロンプトで解決するようになりました。