Kiro CLIでAI-DLC v2の逆解析ドキュメントを活用し、CDKプロジェクトの改善サイクルを回してみた

はじめに

以前の記事で、AI-DLC v2の逆解析ワークフローを紹介しました。

https://dev.classmethod.jp/articles/ai-dlc-v2-reverse-engineering-to-code-generation-workflow/

既存コードベースを入力として、技術スタック・コンポーネント構成・品質評価等の設計ドキュメントを自動生成する仕組みです。
今回はその逆解析をCDKプロジェクトで利用した過程を紹介します。

https://dev.classmethod.jp/articles/cognito-cloudfront-vpc-origin-agentcore-websocket/

改善後の構成図を以下に示します。

実行環境

• Kiro CLI: claude-opus-4.6
• AI-DLC Workflows: v2（2026-06時点）
• CDK: v2 / TypeScript
• Node.js: v22

逆解析の実施

AI-DLC v2のスキル群（aidlc-reverse-engineering、aidlc-orchestrator 等）をプロジェクトの .kiro/skills/ にインストールしました。まず逆解析を実施しました。

Vibe改善（1回目）

逆解析で得られた code-quality-assessment.md を元に、Kiro CLIに改善案を求め、直ちに対応が望ましい事項について、バグ修正と併せて実施しました。
orchestratorのような体系的プロセスは踏まず、人間がプロンプトを即興的に構成して実行するアプローチです。

コミット1: セキュリティ強化

信頼境界の見直しを中心に実装しました。

• ウェブSocket Origin検証（CSWSH対策）: upgradeリクエスト時、許可Originが設定されている場合にOriginヘッダーを検証し、不一致の接続を拒否するようにしました。Origin検証はブラウザー経由のCSWSH対策であり、認証・認可の代替ではありません。実際の接続可否はCognito認証および署名付きCookieの検証と組み合わせています
• ユーザー識別CookieのHttpOnly化: 該当CookieにHttpOnly属性を追加し、クライアントサイドJSからの読み取りを抑止
• ログアウト時のCookie削除修正: 削除時のCookie属性（Domain等）を発行時と揃え、クリアされやすくなるよう修正
• IAMリソーススコープの縮小: KMS/ECRに対する権限のリソーススコープを縮小

// WebSocket Origin 検証の実装例（修正後）
httpServer.on("upgrade", (req, socket, head) => {
  const url = new URL(req.url, "http://localhost");
  if (url.pathname === "/ws") {
    const origin = req.headers.origin || '';
    if (ALLOWED_ORIGIN && origin !== ALLOWED_ORIGIN) {
      console.error(`[ws] Origin rejected: ${origin}`);
      socket.write('HTTP/1.1 403 Forbidden\r\n\r\n');
      socket.destroy();
      return;
    }
    // ... 以降の処理
  }
});

コミット2: セッション外部化 + Auto-scaling

ウェブSocket接続に紐づくセッション情報を、in-memoryの Map からDynamoDBに移行しました。

// DynamoDB セッション操作（修正後）
const SESSION_TABLE = process.env.SESSION_TABLE_NAME || "agentcore-webshell-sessions";
const SESSION_TTL_SEC = 48 * 60 * 60;

async function putSession(userId, shellId, sessionId) {
  const now = new Date().toISOString();
  const ttl = Math.floor(Date.now() / 1000) + SESSION_TTL_SEC;
  await ddbClient.send(new PutCommand({
    TableName: SESSION_TABLE,
    Item: { userId, shellId, sessionId, createdAt: now, lastActivity: now, ttl },
  }));
}

併せて、ECS Service Auto-scalingを追加しました。セッション情報を外部化したことで、再接続時に既存セッションを参照できる構成になりました。

コミット3: 運用性改善

graceful shutdown、構造化ログ、circuit breaker、CloudFrontアクセスログを追加しました。

• Graceful shutdown: SIGTERM/SIGINT受信時に10秒タイムアウトでウェブSocket接続をドレイン
• 構造化ログ: JSON形式ログに接続ID（connId）を付与。CloudWatch Logs Insightsの検索性向上
• ECS circuit breaker: ECSサービスのデプロイが安定化しない場合に、直前の正常なデプロイへロールバックする設定を有効化
• CloudFront Access Logs: S3バケット（Block Public Access / 暗号化 / 90日ライフサイクル）に標準ログを出力

// ECS circuit breaker の設定例（CDK）
const service = new ecs.FargateService(this, 'Service', {
  // ...
  circuitBreaker: { rollback: true },
});

2回目: orchestratorによる構造的改善

1回目の改善でセキュリティや運用面は強化できましたが、コード構造自体の問題（400行規模のモノリシックなserver.mjs、テスト不在等）は残っています。

2回目ではAI-DLCの改善フローに則り、再逆解析を実施したのち aidlc-orchestrator スキルで体系的な改善を進めました。

再逆解析

1回目の改善後のコードに対して aidlc-reverse-engineering を再実行し、設計ドキュメント10本を更新しました。

orchestratorによるワークフロー構成

更新された逆解析ドキュメントと code-quality-assessment.md の残課題を入力に、aidlc-orchestrator スキルへ本番運用を意識した改善（production-hardening）を指示しました。
orchestratorは以下のワークフローを構成しました。

orchestratorは要件分析→設計→ユニット分割→実装という設計プロセスを組み立てて実行しました。

Requirements Analysis での意思決定

orchestratorは要件分析フェーズで実装スコープの選択を求めました。人間が以下を指示しています。

• 採用： config外部化、テスト追加、モジュール分割、healthエンドポイント、.dockerignore追加等
• 見送り： Secrets Manager移行、署名鍵ローテーション
• テスト範囲： CDK snapshot + Lambda unit tests

Application Design

server.mjs（400行規模のモノリシックな構成）を5モジュールに分割する設計が策定されました。

Units Generation と Code Generation

orchestratorは改善を3つのワークユニットに分割し、依存関係順に実行しました。

テスト追加とデプロイ

1回目ではテストの用意がない状態でしたが、CDK snapshot tests 6本とLambda unit tests 7本が作成されました。

$ npm test

Test Suites: 2 passed, 2 total
Tests:       13 passed, 13 total
Snapshots:   6 passed, 6 total

テスト全通過を確認後、CDKデプロイを実施しました。全スタックのデプロイ成功、ECSタスクがhealthyであること、GET /health が200応答を返すことを確認しています。

Before → After

まとめ

AI-DLC v2の逆解析ドキュメントを起点に、CDKプロジェクトの改善サイクルを2段階で実施しました。

1回目は、逆解析結果をもとに人間が改善対象を選び、Kiro CLIへ都度プロンプトを組み立てて指示する「Vibe改善」として進めました。ウェブSocket Origin検証、Cookie属性の見直し、IAMスコープ縮小、セッション情報の外部化などを短いサイクルで実装できました。

2回目は aidlc-orchestrator を使い、再逆解析後のドキュメントを入力として、要件分析、設計、ユニット分割、実装の流れで改善を進めました。結果として、server.mjs の分割、設定値の整理、healthエンドポイント追加、自動テスト追加まで実施できました。

今回の検証では、code-quality-assessment.md のAnti-Patterns表が改善対象を見つける起点として有効でした。AI-DLC v2の逆解析は、今回検証したCDKのほか、TerraformやCloudFormationなどのIaCコードベースにも応用できる可能性があります。既存コードを起点に改善対象を洗い出し、段階的なリファクタリングやテスト追加へつなげる手段として活用できそうです。

参考リンク

• AI-DLC v2の逆解析→コード生成ワークフローを紹介してみた（前回記事）
• Cognito + CloudFront VPC Origin + AgentCore WebSocket構成の紹介
• AI-DLC Workflows（GitHub）
• Kiro CLI ドキュメント