Kiro Web の Build with Spec で Spec 作成から PR・レビュー対応まで試してみた
はじめに
2026年6月11日、Kiro WebにBuild with Specが追加されました。
IDE版（VS Code拡張）で提供されていたSpec駆動開発が、ブラウザー上で利用可能になった形です。ローカル環境のセットアップ不要で、Spec作成 → タスク実行 → PR作成 → レビュー対応まで完結します。今回はこのワークフローを、VPC Flow Logsの新フィールドを活用したCloudWatch Logs Insightsクエリチートシート作成（詳細）で検証しました。
検証環境
- Kiro Web: app.kiro.dev（Proサブスクリプション）
- リポジトリ： GitHub cm-suzuki-ryo/cloudwatch-logs-query-skill
Kiro Web Build with Spec の流れ
セッション開始・リポジトリ選択
app.kiro.devを開き、対象リポジトリ cm-suzuki-ryo/cloudwatch-logs-query-skill を選択しました。
Build with Spec 起動とプロンプト入力
Build with Spec をクリックし、以下のプロンプトを入力しました。
Quick Plan でお願いします。
VPC Flow Logs（version 11、ネクストホップ・EC2タグフィールド含む）を
CloudWatch Logs Insights で分析するためのチートシートを作成してください。
Clarifying Questions
Kiroから4つの確認質問が提示されました。
- チートシートの記述言語 →「日本語」を選択
- スコープ（対象範囲） → 新フィールド活用を中心にする旨を回答
- 構成スタイル →「ユースケース/シナリオ別に構成」を選択
- ファイル配置 →「リポジトリルートに独立ファイルとして配置」を選択
Requirements → Design → Tasks 生成
質問フェーズ完了後、Quick Planとして一気に生成されました。
- Requirements: 8つの要件
- Design: 7コンポーネントのセクション構成
- Tasks: 16タスク、Wave 0〜5の実行順序
フィードバックと承認
生成されたSpecに1点修正を指示しました。NAT Gatewayのフィルタ値がハイフン区切り（"nat-gateway"）になっていたため、正しいアンダースコア区切りに修正しました。修正反映を確認し、プランを承認しました。
タスク実行と PR 作成
全16タスクがWave 0〜5の順に実行されました。
4分14秒で完了しました。
続けてブランチへのpushとPR作成を指示しました。
- ブランチ：
feat/vpc-flow-logs-v11-cheatsheet - コミット： 5ファイル、940行追加
- PR: #6
/kiro fix によるレビュー対応
PRに以下3点のレビューコメントを投稿し、続けて /kiro fix を投稿しました。
- クロスAZ検出クエリで使用している
az-idフィールドがフィールドリファレンステーブルに含まれていない - タグフィールド（instance-tag, interface-tag）の値はパーセントエンコードされている旨の注記が必要
next-hop-*フィールドは対応する通信がない場合"-"が記録される。ispresent()に加えて!= "-"の条件も必要か検討が必要
/kiro fix を投稿すると、Kiro Web側で自動的に新しいセッションが起動しました。
3点の指摘を正しく認識し、以下のように対応していました。
| レビュー指摘 | 対応内容 |
|---|---|
az-id がフィールドリファレンスに未記載 |
v11 新規フィールドセクションに追加。カスタムフォーマットへの追加が必要な旨の注意書きも追記 |
| タグフィールドのパーセントエンコード | 補足セクションに変換テーブルとクエリ例を追加 |
next-hop-* の "-" 値 |
全 next-hop-* 使用クエリ（7本）に != "-" 条件を追加。補足セクションに推奨パターンを文書化 |
修正はチートシート本文だけでなく、Design Documentのクエリ設計パターンにも反映されました。Spec自体が更新されたため、以降Kiroはこの修正を前提として作業できる状態になりました。
所要時間3分27秒、クレジット消費1.64でした。
実環境での動作確認と /kiro fix #2
/kiro fix #1で修正されたチートシートのクエリを、実環境で実行して動作確認しました。
発見: 実環境ではフィールド名が異なっていた
チートシートではVPC Flow Logsのフィールド名をハイフン区切り（next-hop-az-id）+ バッククォートで記述していました。しかし実環境のCloudWatch Logs Insightsでは、以下のフィールド名で参照する必要がありました。
| カスタムフォーマット指定名 | Logs Insights でのフィールド名 |
|---|---|
| next-hop-az-id | nextHopAzId |
| next-hop-interface-type | nextHopInterfaceType |
| instance-tag | instanceTag |
| interface-tag | interfaceTag |
ハイフン区切り + バッククォートではフィールドが認識されず、ispresent() が常に0を返しました。キャメルケースのフィールド名に変更すると正常に認識されました。
クエリの修正前後
修正前（動作しない）:
filter ispresent(`next-hop-az-id`) and `next-hop-az-id` != "-"
| filter `az-id` != `next-hop-az-id`
| fields @timestamp, `interface-id`, `srcaddr`, `dstaddr`, `az-id`, `next-hop-az-id`, bytes
| sort bytes desc
| limit 50
修正後（動作確認済み）:
filter ispresent(nextHopAzId) and nextHopAzId != "-"
| filter azId != nextHopAzId
| fields @timestamp, interfaceId, srcaddr, dstaddr, azId, nextHopAzId, bytes
| sort bytes desc
| limit 50
バッククォート除去 + ハイフン区切り→キャメルケースが変更点です。v2フィールド（srcaddr, dstaddr, bytes等）はハイフンを含まない単一語のため変更不要でした。
ispresent() と "-" の挙動詳細
ispresent() は "-" が格納されたフィールドに対してもtrueを返します。実機での確認結果は以下のとおりです。
filter ispresent(nextHopAzId)
| stats count(*) as total, count(nextHopAzId = "-") as dashCount
結果： total = 23,533, dashCount = 23,533。ispresent = 1 の全レコードが "-" でした。
| レコード状態 | ispresent(nextHopAzId) |
値 |
|---|---|---|
| AZ値あり（apne1-az1等） | 1 (true) | apne1-az1 |
"-" が格納されている |
1 (true) | - |
| フィールド値なし | 0 (false) | — |
このため、有効な値のみを取得するには ispresent() に加えて != "-" のフィルタが必須です。
/kiro fix #2 で修正
この検証結果をPRコメントに投稿し、再度 /kiro fix を実行しました。全クエリのフィールド名がキャメルケースに一括変換されました。
所要時間3分20秒、クレジット消費1.46。
修正後のテスト結果
| クエリ | 結果 | 備考 |
|---|---|---|
| タグベース集計 | ✅ 動作 | 72MB、843フロー検出 |
| NAT Gateway 検出 | ✅ 動作 | 47KB/66パケット検出 |
| クロスAZ検出 | ⚠️ 0件 | 検証環境のフローログ設定に az-id を含めていなかったため |
コスト・時間サマリー
| フェーズ | 所要時間 | クレジット |
|---|---|---|
| Spec 生成（質問→Requirements→Design→Tasks） | 13分4秒 | 3.79 |
| 実装（全16タスク） | 4分14秒 | 1.99 |
| Push & PR 作成 | 1分46秒 | 0.72 |
/kiro fix #1（レビュー対応） |
3分27秒 | 1.64 |
/kiro fix #2（キャメルケース変換） |
3分20秒 | 1.46 |
| 合計 | 約26分 | 約9.6 |
まとめ
Build with Specにより、ブラウザー上でSpec作成から実装、PR作成、レビュー対応まで進められる開発ワークフローを確認できました。今回の検証では、約26分・9.6クレジットで940行規模のチートシートをPRとして作成し、2回の /kiro fix によるレビュー対応まで実施できました。また、処理中にブラウザーを閉じてもタスクは継続しており、セッション再開時に結果を確認できました。
一方で、生成されたクエリをそのまま実環境で動かすと、フィールド名の違いにより動作しない問題もありました。これは実際に実行してみないと気づきにくい問題でしたが、検証結果をPRコメントとしてフィードバックし、/kiro fix で修正反映まで進められることを確認できました。
Spec作成、実装、PR作成、レビュー指摘への対応、実環境で見つかった問題のフィードバックまでを、ブラウザーとPRコメントを中心に回せる点が、Build with Specの実用的な価値だと感じます。
