Kiroで仕様定義から実装・IaC化まで完結させてみた(ブログ執筆者統計バッチ)

AIエディタ「Kiro」を活用し、仕様書の定義から実装、そしてインフラのIaC化（CloudFormation）までを一貫して行う開発フローを試みる機会がありました。

本記事では、S3上に毎日エクスポートされるDevelopersIOの執筆データを元に、執筆者ごとの月次投稿数推移グラフを自動生成するバッチ処理を構築した過程を紹介します。

特に今回は、以下のステップで**「プロトタイピングからIaCへの昇華」**を行いました。

1. 対話的なCLI構築: 指示を受けたKiroが、AWS CLIコマンドを実行
2. 仕様の記録: 構築手順を並行してドキュメント（Spec）に落とし込む。
3. IaC化: Specを元にCloudFormationテンプレートを生成し、本番環境として再構築。

開発の背景とアーキテクチャ

今回の目的は、過去の執筆実績を可視化し、著者のモチベーション向上に繋げることです。
入力データとなるS3上のJSONLファイルは、既存の社内BIツール（Looker、QuickSuite）向けにエクスポートされていたデータを流用しました。

アーキテクチャ:

1. Input: all-blog-posts.jsonl.gz (既存のS3データ)
2. Process: Lambda (Python/Matplotlib/Seaborn) with EventBridge Scheduler
3. Output: 執筆者ごとのPNG画像 (S3 + CloudFront with OAC)

1. 既存データ資産の調査とSpec化

まず、入力データの構造を把握するため、実機データを調査し data-spec.md を作成しました。

実データの確認

AWS CLIを用いてS3上の実データを取得し、構造を確認しました。

# S3から最新のダンプファイルをダウンロード
# <SOURCE-BUCKET-NAME> は実際のバケット名
aws s3 cp s3://<SOURCE-BUCKET-NAME>/contentful/all-blog-posts.jsonl.gz .
gzip -dc all-blog-posts.jsonl.gz | head -n 1 | jq .

Specファイルへの反映

調査結果を元に、Kiroに読み込ませるための仕様書 data-spec.md を定義しました。
ここでは、膨大なデータフィールドの中から、今回のバッチ処理（集計・結合・可視化）に不可欠な要素だけを抽出し、AIに焦点を絞らせています。

data-spec.md（抜粋）:

## データスキーマ仕様
BIツール連携用の既存データを流用する。

### all-blog-posts.jsonl.gz (トランザクション)
- **必須フィールド**:
  - `author_id`: **結合キー**。著者マスタと紐付けるために必須。
  - `first_published_at`: **集計軸**。月次でグルーピングするために必須。
  - `title`: 検証・デバッグ用。

### authorProfile.jsonl.gz (マスタ)
- **必須フィールド**:
  - `id`: **結合キー**。
  - `slug`: **出力ファイル名**（例: `suzuki-ryo.png`）に使用。
  - `display_name`: **グラフタイトル**（表示名）に使用。

このSpec定義により、Kiroは「マスタ結合」「時系列集計」「成果物生成」のロジックを迷いなく実装できました。

2. アプリケーション実装: マスタ結合

Kiroは data-spec.md を読み取り、「トランザクション（投稿）」と「マスタ（著者）」の結合処理 を実装しました。
データ量が約6万件あるため、マスタを辞書（Hash Map）化して O(1) で高速にルックアップする効率的なコード（lambda_batch.py）が生成されました。

    # 1. 著者マスタを辞書化
    authors = {}
    with gzip.open(authors_file, 'rt', encoding='utf-8') as f:
        # ... マスタ読み込み処理 ...

    # 2. 投稿集計データに対し、辞書から情報を引く
    for author_id, monthly_data in data.items():
        if author_id in authors:
             # ...

3. プロトタイピングとIaCへのリファクタリング

ここが今回の開発のハイライトです。いきなりCloudFormationを書くのではなく、まずは対話的に動く環境を作るアプローチを取りました。

3.1 KiroによるAWS操作の代行 (Prototyping)

まず、Kiroに対して「このPythonコードが動くAWS環境を作りたい」とチャット形式で指示を出しました。
ここで私は直接 AWS CLI コマンドを実行していません。代わりに Kiro に対話形式で要件を伝え、Kiro が搭載する use_aws ツールを使用して必要なコマンドを生成・実行していきました。

• ユーザー: 「S3バケットを作成、出力先として利用して」
  • Kiro: aws s3 mb ... を実行
• ユーザー: 「手元のPythonコードを、Dockerコンテナとして動かして」
  • Kiro: Dockerfileを作成し、docker build コマンドを実行してイメージを作成
• ユーザー: 「このローカルで動いたイメージを、AWS Lambdaで動かして」
  • Kiro: 「Lambdaでコンテナイメージを使用するには、Amazon ECRへのプッシュが必要です。リポジトリを作成しますか？」と提案
  • Kiro: (承諾後) aws ecr create-repository ... を実行し、Dockerイメージをプッシュ

このように、「抽象的な要件やゴール」は人間が指示し、「具体的な手順や依存関係（LambdaにはECRが必要など）の解決」と「コマンド入力」はKiroに任せる 形です。

構築後、実機での動作検証を行い、直近7日間の集計が正しく行われることを確認しました。

3.2 手順のドキュメント化とSpec化

構築作業と並行して、Kiro に手順をドキュメント化するよう指示し、spec/batch-setup.md を作成しました。
後からログを解析したのではなく、リソース作成の都度「この設定をSpecに追記して」と指示することで、常に最新の状態が反映された手順書が出来上がりました。

spec/batch-setup.md（抜粋）:

1. Dockerイメージビルド・プッシュ
2. IAMロール作成（信頼ポリシー、S3アクセスポリシー）
3. Lambda関数作成
4. CloudFront配信設定（OAC作成、ディストリビューション作成）

3.3 CloudFormationテンプレートへの変換

最後に、この spec/batch-setup.md を元に、CloudFormationテンプレートを作成させました。
「検証済みのCLI手順書」があるため、それを「IaCテンプレート」に変換するリファクタリング作業は非常にスムーズでした。

Kiroへの指示:

spec/batch-setup.md の内容を CloudFormation テンプレート (author-stats-batch.yaml) に変換して。

結果として、OAC設定やS3バケットポリシーなど、複雑な設定も含んだ正確なテンプレートが生成されました。

4. クリーンな環境への再デプロイと検証

テンプレートの完成後、プロトタイプ環境のリソースを削除し、CloudFormationを用いた「本番相当」のデプロイを実施しました。

4.1 スタックのデプロイ

aws cloudformation create-stack \
  --stack-name author-stats-batch-stack \
  --template-body file://cloudformation/author-stats-batch.yaml \
  --parameters \
    ParameterKey=SourceBucketName,ParameterValue=<SOURCE-BUCKET-NAME> \
    ParameterKey=ECRImageUri,ParameterValue=<ACCOUNT-ID>.dkr.ecr.us-east-1.amazonaws.com/author-stats-batch:latest \
    ParameterKey=ScheduleExpression,ParameterValue="cron(45 17 * * ? *)" \
  --capabilities CAPABILITY_NAMED_IAM \
  --region us-east-1

実行結果:

Waiting for stack creation...
Stack created successfully!

数分でスタックの作成が完了し、CloudFrontのドメインやS3バケットが払い出されたことを確認しました。

4.2 最終動作検証

再構築された環境で、再度テストを実行しました。

直近7日間の更新 (通常稼働)

2025-11-25T22:11:57 Found 68 active authors
2025-11-25T22:12:24 REPORT Duration: 27054.79 ms   Max Memory Used: 259 MB

正常に68名分のグラフが生成されました。

全期間（15年分）の一括生成 (高負荷テスト)

2025-11-25T22:13:54 Processing authors active in last 5475 days
2025-11-25T22:13:54 Found 1056 active authors
...
2025-11-25T22:18:28 Processed: littleossa

1,056名 全員のグラフ生成が、エラーなく約5分で完了しました。

S3出力確認:

aws s3 ls s3://<DEST-BUCKET-NAME>/author-monthly-stats/ | wc -l
> 1047

表示確認:

生成された画像ファイル数も一致しており、IaCによる再構築が完璧に行われたことを裏付けました。

5. 今後の展望とリリースについて

今回の検証で、バックエンドの生成ロジックと配信基盤は完成しました。今後は以下の調整を行い、本番環境への投入を進めていきます。

• ジョブ安定性の確認: EventBridgeによる日次実行を数日間監視します。
• デザイン調整: 生成されるグラフの色使いやフォントサイズを、DevelopersIOのサイトデザインに合わせて微調整します。

これらの確認作業を経て、近日中にDevelopersIOの各著者プロフィールページにて、この統計グラフを実際に公開する予定です。ご期待ください。

まとめ

今回の検証では、Kiroを用いて以下のモダンな開発フローを実践できました。

1. 対話的なプロトタイピング: 自然言語で指示し、KiroがCLIを代行することで、リソース作成の試行錯誤を高速化。
2. プロセスの仕様化: 構築しながら手順をMarkdownに記録し、ブラックボックス化を防ぐ。
3. IaCへのリファクタリング: 検証済みの手順書を元にCFnテンプレートを生成し、堅牢な環境へ移行。

「まず動くものを作り、並行してドキュメントを残し、最後にコード化する」。この理想的なサイクルをAIとのペアプログラミングで実現できた点は、大きな収穫でした。