逆解析から始めるAI-DLC

逆解析から始めるAI-DLC AI-DLC v2 逆解析ドキュメントの有効性 JAWSUG AI-DLC支部 LT4 | 2026.08.28 | 鈴木亮 (suzryo)

自己紹介 鈴木亮 (suzryo) クラスメソッド株式会社 ● 2014年ジョイン / 850記事投稿 ● Japan AWS Top Engineers 2019-2026 ● AWS GameDay 優勝 (re:Invent 2023, 2025) ● Kiro並列執筆で月間123本ブログ

既存システム、把握できてますか？ ドキュメントが ない・古い 書いた人が もういない 全体構成が 見えない

AI-DLC v2 逆解析とは ● inceptionフェーズのステージ（既存コードがあれば自 inception 動で入る） ● developer が走査 → architect が合成する直列パイプライ reverse-engineering ン ● ソースコードに一切手を加えない（読み取り専用） ● 本流のワークフローを汚さず単体実行できる（--single ） construction operation

依頼プロンプトの工夫 4点明示で無駄な深堀りを防ぐ ① 目的 ② スコープ外 将来の改修の入口となる 設計ドキュメントを作る S3/DSQLのデータ変更 AWSへの実デプロイ ③ 矛盾解消 ④ 成果物指定 template.yaml埋込みと src/index.pyの不整合 データフロー図 スキーマ、認証評価 このプロンプト自体をOpus5に書かせるのが有効

対象: Kiro利用状況ダッシュボード

成果物: Mermaid構成図 Mermaidがそのまま出てくる → Geminiでレンダリングすれば構成図に

逆解析の実行 CloudFormation 7スタック Lambda 5本 + Step Functions Aurora DSQL + S3 + CloudFront → これらを逆解析 148 ファイル走査 7 文書生成 0 対象変更

生成ドキュメント一覧 architecture-and-components.md コンポーネント構成・Mermaidデータフロー図 aws-configuration.md AWSサービス・IaC・スタック別リソース・IAM api-and-data-flow.md APIエンドポイント・認証・データフロー technology-stack-and-components.md 言語・ランタイム・依存・ビルド・CI/CD pipelines-and-dependencies.md Step Functions・Scheduler・デプロイ経路 source-inventory.md / .tsv 全148ファイルの台帳（パス・MIME・SHA-256） open-questions-and-contradictions.md 矛盾・未確認事項・解析制約

設計ドリフトの可視化 VIBE時短 → Lambda直更新 → IaCと実コードに差分が生じる（想定通り） template.yaml 埋込み src/index.py 初期コード（シンプル最小限） VIBE改善後（進化版） ● S3参照のみ ● DSQL直結 ● DSQL接続なし ● 詳細ビュー (detail=1) ● 詳細ビューなし ● モデル別集計あり 逆解析がこの乖離を拾う → IaCと実装の管理性向上の入口

逆解析の先にあるもの 逆解析は入口。ここから先に繋がる ● Kiro use_aws / MCP経由でAWS実環境の値を取得・反映 ● 改善サイクルを回せば、仕様と実装が一致 ● 不明点のヒアリング → 潜在リスク・セキュリティ診断 ● 管理性の向上（IaC 実装の一致） ※ 静的資材のみの解析なので実行時挙動は出ないが、判断材料は揃う

コスト感 Luna(0.10x)で実行: 80クレジット ≒ 200円（Kiro月額20ドル換算） Opus5で依頼プロンプト設計 → Lunaで実行 高い頭で設計、安い手で実行 単価倍率20倍以上 + 深堀り傾向 → Opusでの逆解析はさらに跳ねる クレジット繰越不可 → 月末余剰でガンガン回す

おすすめフロー ① VIBEで作る ② → SAM/CDKで デプロイ ③ → ④ 逆解析で 仕様を追いつかせる → 改善サイクル を回す →ドキュメントがない まとめ 詳細はブログで！ 200円で既存システムを可視化 設計ドリフトの検出で管理性向上 改善サイクルの入口に最適 dev.classmethod.jp AI-DLC 逆解析 suzuki-ryo で検索

Appendix 関連記事紹介

逆解析の依頼プロンプト Opusと相談して作成した初回指示 home/kiro-2/kiro-dashboard の既存システムを対象に、 実装変更を行わず、AIDLC v2 の逆解析によって現行仕様を文書化する。 対象は主に次の内容: - kiro-dashboard/docs/ - kiro-dashboard/iac/ - kiro-dashboard/README.md アーキテクチャ、AWS構成、API、パイプライン、依存関係、 データフロー、技術スタック、コンポーネント構成を明らかにする。 AIDLC自身の .kiro/ と aidlc/ は解析対象から除外する。 コード変更、IaC変更、デプロイは行わない。 ↑ このプロンプトだけで、7文書が自動生成される

architecture-and-components.md コンポーネント構成・データフロー図 ■ コンポーネント責務表 KiroImportActivity S3 CSV→日付・種別抽出→DSQL UPSERT KiroSyncUserMapping Identity Store→DSQL UPSERT KiroExportDashboard DSQL集計→4ファイルS3 JSON出力 KiroDashboardApi S3 JSON + DSQL(detail=1)→HTML/JSON KiroDashboardPipeline Step Functions日次オーケストレーション ■ Mermaidデータフロー（原文拜用） flowchart LR Schedule[EventBridge] --> SFN[Step Functions] SFN --> Import --> DSQL[(Aurora DSQL)] SFN --> Sync --> DSQL DSQL --> Export --> DashboardS3[S3 JSON] Browser --> CF[CloudFront+BasicAuth] CF -->|OAC SigV4| API[Lambda URL] DashboardS3 --> API DSQL -->|detail=1のみ| API

aws-configuration.md AWSサービス構成・IaC定義 ■ スタック別リソース定義 psycopg2-layer Lambda Layer (Python3.12 ARM64) kiro-import-activity LogGroup, IAM Role, Lambda Function kiro-sync-user-mapping LogGroup, IAM Role, Lambda Function kiro-export-dashboard S3 Bucket, LogGroup, Role, Lambda kiro-dashboard-pipeline StepFunctions, Scheduler, Logs kiro-dashboard-api Lambda, FuncURL, OAC, CloudFront ■ 主要パラメータ（環境変数） DSQL_ENDPOINT / S3_SOURCE_BUCKET / S3_DASHBOARD_BUCKET IDENTITY_STORE_ID / DATA_SOURCE_ROLE_ARN / RANKING_LIMIT ■ 認証チェーン CloudFront Function (Basic認証) → OAC (SigV4署名) → Lambda Function URL (AuthType: AWS_IAM) → DSQL IAM認証 (generate_db_connect_auth_token)

api-and-data-flow.md APIエンドポイント仕様 ■ エンドポイント一覧 GET / 全体ダッシュボード GET /?format=json 全体JSON GET /?user_id=<id> 個人サマリー GET /?user_id=<id>&detail=1 個人詳細 S3+DSQL→HTML GET /?...&format=json JSON版 DecimalEncoder S3 JSON→HTML S3 JSON S3 JSON→HTML ■ データソース使い分け 通常: S3 reports/*.json (Export済み集計) detail=1: DSQL kiro.kiro_user_activity 直接参照 ■ S3 JSONファイル名 reports/current_month_daily_total.json reports/current_month_ranking.json reports/current_month_daily.json reports/user_credit_history.json HTML内: Chart.js CDN (cdn.jsdelivr.net/npm/chart.js)

technology-stack-and-components.md 技術スタック・ランタイム ■ 技術スタック 言語 Python 3.12 CPU ARM64 (Graviton) IaC CloudFormation YAML DB Aurora DSQL (IAM認証トークン) CDN CloudFront + OAC ランタイム Lambda Function URL ワークフロー Step Functions Standard スケジューラ EventBridge Scheduler ■ 依存ライブラリ boto3 / psycopg2 (Layer 2.9.11 ARM64) / python-dateutil ※ requirements.txt なし — バージョンロック未確認 ■ CI/CD 確認できず（手動deploy手順のみ docs/ に記載） GitHub Actions / CodePipeline / SAM 定義なし

pipelines-and-dependencies.md Step Functions パイプライン定義 ■ 日次パイプライン EventBridge cron(30 2 * * ? *) = 11:30 JST Import ── SyncUserMapping ── ExportDashboard ── Success └─ 失敗時: 各Catch → FailState ■ Retry設定 対象: Lambda.ServiceException, TooManyRequestsException IntervalSeconds: 2 / MaxAttempts: 3 / BackoffRate: 2 ■ 各段階の入出力 Import: CSV取得 → 処理ファイル数・取込レコード数返却 Sync: Identity Store読取 → 同期ユーザー数返却 Export: DSQL集計 → 4 JSON + metadata/last_run.json ■ 矛盾 現行テンプレート: 3段階 (Import→Sync→Export) 11:30 JST dsql-design.md: 4段階 (+AggregateDaily) 12:00 JST

source-inventory.md / .tsv 148ファイル完全台帳 ■ 台帳フォーマット例 # | 相対パス | 分類 | 検査 | Bytes | SHA-256 ────────────────────────────────────────── 129 README.md 主システム文書 1,802B 130 docs/dashboard-api-spec.md 主システム文書 5,919B 133 .../api/src/index.py Lambdaコード 15,006B 134 .../api/template.yaml IaC 138 .../export-dashboard/index.py Lambdaコード 17,428B 8,318B ■ 分類内訳 テキスト走査: 107ファイル (UTF-8読取→行数・見出し・定義計数) メタデータ走査: 41ファイル (バイナリ→パス・MIME・SHA-256) ■ 活用 TSV形式で機械可読 → diff検出・回帰チェックに利用可能 解析時点のスナップショットとして機能

open-questions-and-contradictions.md 矛盾6件・未確認事項 ■ 情報源間の矛盾（未解決） C-01: src/index.py (DSQL詳細実装あり) vs template.yaml埋込み (S3サマリーのみ) C-02: 現行Pipeline 3段階 11:30 JST vs 設計書 4段階 12:00 JST C-03: KiroDataLoader(一体型) vs 分割Lambda併存 C-04: README「API Gateway」表現 vs IaC実体 Lambda Function URL C-05: dsql-design.md集計テーブル設計 vs 実装の直接S3 JSON生成 C-06: 文書上の固定ドメイン vs 実環境未照合 ■ 解析制約 AWS未接続 / 機密値非複製 / バイナリ非解釈 「存在する」「稼働中」とは断定せず、IaC/コード上の定義として記載

KiroのAI-DLCで、あえて脆弱なEC2環境のCloudFormationテンプレートを生成・検証してみた

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

AI-DLC v2 で逆解析→設計→コード生成のワークフローを一通り試してみた