Kiro Hooks/Steeringを使って作業ログからLT草案を生成してみた

Transcript

1. Kiro Hooks / Steeringを使って 作業ログからLT草案を生成してみた 〜このもくもく会の成果をその場で評価！〜 kasumi
2. 自己紹介 kasumi 音楽やコミックなどのコンテンツ配信サービスでバックエンドエンジニア Claude 心の相棒 Claude Code 右腕 ChatGPT 初恋 Copilot 元同僚 Kiro 週末の新入り https://zenn.dev/m_chan
3. なぜ私は今、LTをしているのか？ 2025年: 色々なLTを聞いていたら、AIによる時代の変化を目一杯楽しんでいるように見えて、 私もAIとのやりとりが楽しくなった。 2026年: AIの「楽しい」を話すことをしたい！ だがしかし…話すためにはネタが必要、共有の準備も必要。 旅行も行きたい、ライブも行きたい、陶芸もしたい、LTもしたい、睡眠は大事、時間がない！！！
4. 作業したら自然とLTの材料が集まる仕組み、 作れないかな？
5. 目次 Kiro Hooks / Steering との格闘 もくもく会の成果を評価！
6. Kiro Hooks / Steering との格闘 失敗談 fileEdited の落とし穴 エージェント自身の書き込みでは発火しない仕様 agentStop の制御不能 あらゆる操作で発火しすぎて無限ループ寸前 解決策 postToolUse + write + プロンプト判断 logs/*.md への書き込み時のみ実行する構成 .kiro/hooks/ ：「いつ（when）」「何をする（then）」を定義する .kiro/steering/ ：エージェントへの常時適用ルールを置くディレクトリ .kiro/hooks/ { "version": "1.0.0", "enabled": true, "name": "LT Draft Committer", "description": "logs/*.md への書き込み後にLT草案を再生成してコミットする", "when": { "type": "postToolUse", "toolTypes": ["write"] }, "then": { "type": "askAgent", "prompt": "直前の書き込みが logs/ 以下の .md ファイルへの書き込みだった場合の み、以下を実行してください。それ以外のファイルへの書き込みの場合は何もしないでく ださい。\n\n1. logs/ フォルダの全ログファイルを読む\n2. drafts/lt-draft.md を読む\n3. ログの内容からLT草案を生成し、drafts/lt-draft.md を更新する\n - すでに同じテーマの 「# LT草案: ***」セクションがある場合はそのセクション内を上書き更新する\n - 新しい テーマの場合はファイル末尾に「# LT草案: ***」セクションを追記する\n4. git add drafts/lt-draft.md logs/ を実行する\n5. git diff --cached --quiet || git commit -m 'auto: update lt-draft' を実行する\n\n# 草案フォーマット（各セクション）\n## 一言で言うと\n## やったこと\n## 結論・問い" } }
7. Kiro Hooks / Steering との格闘 失敗談 上書きによりログが消える 同日に複数回ログの書き込みをした際、上書きされて最後 のログしか残らなかった 解決策 追記形式で上書きしない旨を明記 + ログもコミット ログ追記→LT草案更新→ログとLT草案をまとめてコミット で上書きされても追えるように .kiro/hooks/ ：「いつ（when）」「何をする（then）」を定義する .kiro/steering/ ：エージェントへの常時適用ルールを置くディレクトリ .kiro/steering/ ## 作業ログのルール 作業が一区切りついたら、必ず logs/YYYY-MM-DD.md に以下を追記すること： - **やったこと**：何を実装・変更したか - **なぜ**：その判断の理由 - **詰まったこと**：うまくいかなかったこと - **気づき**：作業の中で感じたこと ログは追記形式。上書きしないこと。
8. もくもく会の成果を評価！
9. どんな草案が出来上がったでしょうか・・・？ # LT草案: Amazon BedrockでAIレシピ提案サービスを作る ## 一言で言うと Amplify Gen 2 をフル活用して Lambda を1つまで削減。設計の意思決定を ADR に残しながら、スペック駆動でレシ ピ提案サービスを設計した。 ## やったこと - 認証済み単一ユーザー向けレシピ提案WebサービスのSpec（要件定義・設計・タスク）を作成 - 技術スタック：Amplify Gen 2（Amplify Data / Auth / Hosting）+ Nova Premier（Web Grounding） - Amplify Data（AppSync + DynamoDB 自動生成）で CRUD を置き換え → Lambda が 4つ → 1つに削減 - フロントから `generateClient<Schema>()` で型安全に直接 CRUD、レシピ提案のみカスタム Lambda - Nova Premier の Web Grounding でリアルタイム web 検索し 3〜5件の候補を取得、rating score のキーワード マッチで順位付け - 嫌いな食べ物がテーマに含まれたら「欠席しましょう」を即返却する早期リターンを実装 - ADR を2件作成：Amplify 採用理由（未経験サービスの習得）・Recipe_Ranker キーワードマッチ採用理由 - AWS Knowledge MCP で設計妥当性を評価 → Claude は Bedrock web 検索非対応と判明、Nova Premier に 変更 ## 結論・問い - Amplify Data の `a.model()` 1行で DynamoDB + GraphQL CRUD + リアルタイム購読が揃う。Lambda を書か なくていい範囲が思ったより広かった - ADR を残す習慣は「なぜその技術を選んだか」を後から追えるようにする。Kiro のスペック駆動開発と組み合わせ ると設計の文脈が丸ごと残る - 問い：Amplify Data の `owner` 認可は単一ユーザー前提では過剰か？それとも将来のマルチユーザー化への布 石として有効か こだわったところがちゃんと書いてある！ ・Amplifyを使う決断をADRに残す ・AWS Knowledge MCP による設計の妥当性評価 ・嫌いな食べ物がテーマの時は 　「欠席しましょう」 ログ記入は指示しないとやらなかった 良い点 改善点 自分っぽさを加えたい 問いが次に詰めるべき仕様を教えてくれた
10. ご清聴ありがとうございました