Tsumiki の Kairo コマンドを使って AWS インフラ環境を構築してみた
2025.08.20いわさです。
先月ですかね、クラスメソッドから AI 支援型テスト駆動開発フレームワークの「Tsumiki」というものが公開されました。
以下の公開リポジトリを見て頂くのが良いのですが、ざっくりいうと Claude Code で Tsumiki のスラッシュコマンドが利用できるようになります。
これによって Claude Code を使って Vibe コーディングではなく、定義されたコマンドから簡単に要件定義から開始することが出来ます。
今回こちらの中の Kairo コマンドを使って AWS インフラ環境を作成する工程を体験してみたので様子を紹介します。
Tsumiki のインストール
Tsumiki のインストールですが非常に簡単で、プロジェクトワークスペース上で以下を実行するだけです。（Claude Code や npx などは使える前提で）
% npx tsumiki install
Need to install the following packages:
tsumiki@0.0.6
Ok to proceed? (y) y
✅ インストールが完了しました!
コピーされたファイル (21個):
• direct-setup.md
• direct-verify.md
• kairo-design.md
• kairo-implement.md
• kairo-requirements.md
• kairo-task-verify.md
• kairo-tasks.md
• rev-design.md
• rev-requirements.md
• rev-specs.md
• rev-tasks.md
• start-server.md
• tdd-cycle-full.sh
• tdd-green.md
• tdd-load-context.md
• tdd-red.md
• tdd-refactor.md
• tdd-requirements.md
• tdd-testcases.md
• tdd-todo.md
• tdd-verify-complete.md
Claude Codeで以下のようにコマンドを使用できます:
/tdd-requirements
/kairo-design
...
そうすると、Tsumiki 用のスラッシュコマンドが.claude/commandsにインストールされ、使えるようになります。
大きくは、要件定義からタスク実装まで包括的な開発を行うkairoコマンド、テスト要件の定義からテストケース作成・リファクタリングまでを行うtddコマンド、既存コードからタスクや設計書・要件定義書までをリバースエンジニアリングで生成するrevコマンドが提供されています。
開発してみる
今回はこちらのkairoコマンドを使って開発をしてみましょう。
流れとしてはkairo-requirementsコマンドで要件定義を行い、次にkairo-designコマンドで設計、kairo-tasksコマンドでタスク分割し、最後にkairo-implementコマンドでタスクの順次実行を行う感じです。
要件定義（/kairo-requirements）
まずはkairo-requirementsコマンドで要件定義から開始します。
ここでは要件定義のテンプレート記法である EARS を使って要件定義書を作成してくれます。
ちょっと特殊なのですが、今回は Amazon Q Developer をプロキシ環境下で利用するためのインフラ環境を用意したかったのでそちらを題材にしてみます。
/kairo-requirementsコマンドを入力後に要件の概要を伝えます。
そうすると要件を分析してユーザーストーリーや機能要件・非機能要件まですべてまとめてくれます。すごい。
コマンドが終了すると、次のようにdocs/specというフォルダ内に要件定義書が作成されていました。
作成された要件定義書
# Amazon Q Developer プロキシ環境 要件定義書
## 概要
AWS上でAmazon Q Developerをプロキシ環境下で使用できる開発環境を構築する。企業のセキュリティポリシーに準拠し、プロキシサーバーを経由してAmazon Q Developerの機能を利用可能にする。
## ユーザストーリー
### ストーリー1: プロキシ経由でのAmazon Q Developer利用
- **である** 開発者 **として**
- **私は** プロキシ環境下でもAmazon Q Developerの機能を使用 **したい**
- **そうすることで** 企業のセキュリティポリシーを遵守しながら、AI支援による開発効率向上を実現できる
### ストーリー2: AWS環境でのセキュアな開発環境構築
- **である** システム管理者 **として**
- **私は** AWSクラウド上にセキュアな開発環境を構築 **したい**
- **そうすることで** 一元管理された開発環境を提供し、セキュリティとガバナンスを維持できる
### ストーリー3: ネットワーク設定の自動化
- **である** インフラエンジニア **として**
- **私は** プロキシ設定やネットワーク構成を自動化 **したい**
- **そうすることで** 運用負荷を削減し、設定ミスによるトラブルを防げる
## 機能要件（EARS記法）
### 通常要件
- REQ-001: システムはAWS環境上でAmazon Q Developer統合開発環境を提供しなければならない
- REQ-002: システムは指定されたプロキシサーバーを経由してインターネットアクセスを行わなければならない
- REQ-003: システムは開発者のAWSアカウントでAmazon Q Developerの認証を処理しなければならない
- REQ-004: システムはVS Code、IntelliJ IDEA等の主要IDEでAmazon Q Developerプラグインを利用可能にしなければならない
- REQ-005: システムはプロキシ設定を環境変数として設定しなければならない
### 条件付き要件
- REQ-101: プロキシ認証が必要な場合、システムは認証情報を安全に管理しなければならない
- REQ-102: プロキシサーバーが利用不可の場合、システムは適切なエラーメッセージを表示しなければならない
- REQ-103: Amazon Q Developerサービスが利用不可の場合、システムは代替手段を提示しなければならない
- REQ-104: ネットワーク接続が不安定な場合、システムは自動再接続を試行しなければならない
- REQ-105: SSL/TLS証明書エラーが発生した場合、システムは証明書検証オプションを提供しなければならない
### 状態要件
- REQ-201: 開発環境が起動状態にある場合、システムはAmazon Q Developerサービスへの接続を維持しなければならない
- REQ-202: プロキシ設定が変更された場合、システムは新しい設定を適用しなければならない
- REQ-203: セッションが有効な場合、システムはユーザーの認証状態を保持しなければならない
### オプション要件
- REQ-301: システムは複数のプロキシサーバーの冗長構成を設定してもよい
- REQ-302: システムはプロキシバイパスリストを設定してもよい
- REQ-303: システムはカスタムCA証明書をインストールしてもよい
- REQ-304: システムはログレベルの調整機能を提供してもよい
### 制約要件
- REQ-401: システムはHTTPS通信のみを使用しなければならない
- REQ-402: システムは認証情報を平文で保存してはならない
- REQ-403: システムはAWSセキュリティベストプラクティスに準拠しなければならない
- REQ-404: システムはプロキシサーバーの設定情報をログに出力してはならない
## 非機能要件
### パフォーマンス
- NFR-001: Amazon Q Developerのレスポンス時間は通常環境の1.5倍以内でなければならない
- NFR-002: プロキシ経由での接続確立は10秒以内に完了しなければならない
- NFR-003: 開発環境の起動は5分以内に完了しなければならない
### セキュリティ
- NFR-101: プロキシ認証情報はAWS Secrets Managerまたは同等のサービスで管理しなければならない
- NFR-102: 通信は全てTLS 1.2以上で暗号化しなければならない
- NFR-103: アクセスログは90日間保持しなければならない
- NFR-104: 未認可アクセスの検出と通知機能を実装しなければならない
### 可用性
- NFR-201: システムの稼働率は99.5%以上でなければならない
- NFR-202: 計画メンテナンスは事前通知の上で実施しなければならない
- NFR-203: 障害発生時の復旧時間は4時間以内でなければならない
### 運用性
- NFR-301: システムの設定変更はIaCツール（Terraform等）で管理しなければならない
- NFR-302: ログは構造化ログ形式（JSON）で出力しなければならない
- NFR-303: モニタリングダッシュボードを提供しなければならない
### スケーラビリティ
- NFR-401: システムは同時接続ユーザー100名まで対応しなければならない
- NFR-402: リソース使用率に応じた自動スケーリング機能を提供しなければならない
## Edgeケース
### エラー処理
- EDGE-001: プロキシサーバーへの接続タイムアウト時の処理
- EDGE-002: プロキシ認証失敗時の処理とリトライロジック
- EDGE-003: Amazon Q Developerサービスの一時的な障害時の処理
- EDGE-004: ネットワーク分断時の状態保持と復旧処理
- EDGE-005: SSL証明書の期限切れ時の警告と処理
### 境界値
- EDGE-101: プロキシ応答時間の上限値（30秒）での処理
- EDGE-102: 同時接続数の上限到達時の新規接続処理
- EDGE-103: ログファイルサイズの上限（1GB）到達時のローテーション
- EDGE-104: セッションタイムアウト（8時間）時の再認証処理
### 異常系シナリオ
- EDGE-201: プロキシサーバーの予期しない停止
- EDGE-202: AWS IAMロールの権限不足
- EDGE-203: 開発環境のディスク容量不足
- EDGE-204: 複数のプロキシサーバー全ての同時障害
## 技術要件
### インフラストラクチャ
- TECH-001: AWS EC2インスタンス（t3.medium以上）
- TECH-002: Amazon VPC with プライベートサブネット
- TECH-003: NAT Gateway またはプロキシサーバー経由のインターネットアクセス
- TECH-004: AWS Systems Manager Session Manager による安全なアクセス
### ソフトウェア
- TECH-101: Ubuntu 22.04 LTS またはAmazon Linux 2023
- TECH-102: Docker Engine 最新安定版
- TECH-103: VS Code Server または JetBrains Gateway
- TECH-104: Amazon Q Developer CLI/Plugin 最新版
### プロキシ設定
- TECH-201: HTTP_PROXY, HTTPS_PROXY環境変数の設定
- TECH-202: NO_PROXY環境変数によるバイパス設定
- TECH-203: SSL_CERT_FILE環境変数による証明書パス設定
## 受け入れ基準
### 機能テスト
- [ ] AWS環境で開発環境が正常に起動する
- [ ] プロキシ経由でAmazon Q Developerにアクセスできる
- [ ] VS CodeでAmazon Q Developerプラグインが動作する
- [ ] コード補完、説明生成等の主要機能が利用できる
- [ ] プロキシ認証が正常に動作する
- [ ] SSL証明書検証が適切に行われる
- [ ] エラー時の適切なメッセージ表示とログ出力
### セキュリティテスト
- [ ] 認証情報が暗号化されて保存される
- [ ] HTTPS通信の強制が機能する
- [ ] 未認可アクセスが検出・拒否される
- [ ] ログに機密情報が含まれない
### パフォーマンステスト
- [ ] 接続確立時間が要件を満たす
- [ ] Amazon Q Developerのレスポンス時間が要件範囲内
- [ ] 同時接続数の上限での安定動作
### 運用テスト
- [ ] 設定変更が正常に反映される
- [ ] ログが適切に出力・ローテーションされる
- [ ] モニタリングアラートが機能する
- [ ] バックアップ・リストアが正常に動作する
## 成果物
1. **インフラストラクチャコード**
- Terraformテンプレート
- AWS CloudFormationテンプレート
2. **設定ファイル**
- プロキシ設定スクリプト
- 環境変数設定ファイル
- IDE設定ファイル
3. **ドキュメント**
- セットアップガイド
- トラブルシューティングガイド
- 運用マニュアル
4. **テスト**
- 自動テストスクリプト
- 受け入れテストチェックリスト
## リスクと制約
### 技術的リスク
- プロキシサーバーの設定互換性
- Amazon Q Developer APIの変更
- AWS サービスの利用制限
### 運用リスク
- プロキシサーバーの可用性依存
- 認証情報の管理コスト
- セキュリティポリシーの変更影響
### 制約事項
- 企業のプロキシサーバー仕様に依存
- AWSリージョンの制限
- Amazon Q Developerの利用規約
この要件定義書をベースに要件の修正やブラッシュアップをしていきます。
設計（/kairo-design）
要件定義書がある程度出来たら、それを元に設計を行いましょう。
/kairo-designコマンドを使います。
kairo-designでは要件定義書を分析し、様々な設計資料を作成してくれます。
私が実行した際はここがまずまずかかりました。結構重いタスクみたいですね。
ひとつづつ対応してくれている様子。
完了すると、今度はdocs/designに各種設計資料が生成されていました。
アーキテクチャー設計やデータフロー図などを確認出来ました。
ここでまた設計書に対して修正などを行っていきます。
タスク分割（/kairo-tasks）
ある程度設計が完了したら、設計書からタスクリストを作成し実装の準備を行いましょう。
タスク分割コマンド/kairo-tasksを使うことで設計書を分析してタスクの洗い出しを行ってくれます。
こちらが生成されたタスクリストです。
フェーズごとに分かれていて、マークダウンのチェックリストになっていますね。
推定作業時間やクリティカルパスが表示されているのがおもしろいですね。
タスクリスト作成された時には依存関係を意識する必要があるので、そのあたりもタスク分割コマンドの中で分析してくれています。
実装（/kairo-implement）
では、最後にタスクの実装を行いましょう。
/kairo-implementsコマンドで実行が可能です。
依存関係に従って順に実行してくれます。
各タスクにはテスト要件や完了条件も定義されており、実装だけでなくテストまで行ってくれます。
今回はインフラストラクチャの実装を Terraform で行うようなものになっており、タスクリストの初期段階では Terraform プロジェクトの用意や VPC の実装などから始まる形になっていました。
エージェントがタスクを完了させると次のようにリアルタイムで完了のチェックを入力してくれます。
さいごに
本日は Tsumiki の Kairo コマンドを使って AWS インフラ環境を構築してみたのでその様子を紹介しました。
Kairo コマンドは現在プレビュー中の Kiro と似た開発が出来ますね。
Claude Code のトークン数やばそうだなと思って今回途中で終了しちゃったのですが、アプリケーションに限らず AWS インフラ開発で普通に Tsumiki 使えそうということがわかりました。
