個人プロジェクトをKiroベースに 乗り換えてみた / I Tried Migrating My Personal Project to Kiro-based

Transcript

1. 既存のプロジェクトをKiroベースに 乗り換える道のり 2025/08/01 髙橋 俊⼀ (a.k.a shuntaka) 1
2. ⾃⼰紹介 2 • 2016年 ⾦融情報ベンダー⼊社 バックエンド ◦ 株価配信Web API開発 • 2019年 クラスメソッド⼊社 ◦ CX/IoT事業部にてIoT案件を複数 • 2024年 製造ビジネステクノロジー部担当 ◦ R&D業務 • 部署 ◦ 製造ビジネステクノロジー部 • 名前（shuntaka） ◦ 髙橋 俊⼀ • 出⾝‧住まい ◦ 東京 2
3. 個⼈プロジェクト is 何？ 2020年にローンチし、ユーザーの皆様に⽀えられて5年間サービスを継続 3
4. 既存プロジェクト is 何？ 2020年にローンチし、ユーザーの皆様に⽀えられて5年間サービスを継続放置 4
5. 構成 4年の変遷 ‧Node 12 →Node 20 ‧Next.js 10 → Next.js 13
6. 夢を詰め込んでリプレース考えるがレガシー化 6
7. 発掘される謎の熱量で書かれた仕様書... 7
8. 8 https://kiro.dev/about/ Kiroを通じて、私たちは開発者が AIエー ジェントと連携する方法を根本から改革し ました。仕様駆動開発のパイオニアとし て、Kiroはユーザーの指示を構造化さ れた要件、設計、タスクに変換し、エー ジェントによって実装します 。Kiroのエー ジェントフックは、ドキュメントの更新、ユ ニットテストの生成、パフォーマンス向上 のためのコード最適化など、バックグラウ ンドで実行されるエージェントにタスクを 委任することで、作業のスケールアップを 支援します。私たちは Kiroを、単に作業を 行うだけでなく、共に構築していく真のコ ラボレーターだと考えています。 Kiroの目 標は、堅牢なエンジニアリング作業の実 現を支援すると同時に、より優れたエン ジニアになるお手伝いをすることです。 About Kiro > We pioneered spec-driven development,
9. 仕様駆動開発の岐路！ 🤝 9
10. リプレース⽤のnpm workspaceを切って対応 10
13. 13 Steering Spec
14. 14 Steeringとは？ マークダウン ファイルを通じて Kiro にプロジェクトに関する 永続的な知識。
15. 15 Steeringから整備
16. 16 Steeringから始める理由 Steeringに書いたこと ‧⽬的 ‧移⾏の背景 ‧移⾏後の技術スタック ‧テストスタイル ‧レガシードキュメントの場所 *.instructions.mdとかCLAUDE.mdと似たようなもの
18. 既存ドキュメントのSteering化 18
19. 既存ドキュメントのSteering化 19
20. 既存ドキュメントのSteering化 20
21. 既存ドキュメントのSteering化 21
24. Specsのディレクトリの分け⽅ 24 https://kiro.dev/docs/specs/best-practices/
26. Kiroで既存ドキュメントの移植 https://kiro.dev/docs/specs/best-practices/ kiro.dev ベスプラより 26
27. 既存ドキュメントからSpec(requirements.md)⽣成 27
28. design.md⽣成 ‧design.mdの間違っているこ とを指摘しながら実装を#で指 定していく ‧YAGNIは消す 28
29. task.md⽣成 ‧全然違うならstearingで基本⽅針調整 → Refineで調整していく ‧9割くらいいい感じになったら終了 29 やらないことの明確化
30. ステアリングである程度の⽅向性は決めておく 30 テーブル定義、OpenAI定義は デザイン段階で作るのが良さ だが。。(スキーマ駆動な部分 があるのでタスクでやらせる) 機能の関数をエントリから流 して問題なければOKとする。 (⼩さく早くローカルで動かす 粒度)
31. task.mdのレビュー = タスク洗い出しPDCAを回す 31
32. タスクのピンポイントでの調整も可 32 Update tasksをおして、⾜りない部分をプロンプト で指摘する。
33. タスク 33 1. 初期セットアップ 2. OpenAPI仕様の実装 3. DBスキーマファイル 4. Docker Compose設定 5. テーブル作成確認 6. tblsで定義書生成 7. DB接続とクエリビルダー 8. Repository層の実装 9. Service層の実装 10. Honoハンドラーの実装 11. Cloudinary統合 12. テストの修正と拡張 13. パフォーマンス最適化 14. ログ出力とモニタリング → 7番で一日の上限にあたってしまった ... 😭 (previewかつ無料期間なので仕方ない！ )
34. タスク実⾏時のきづき 34 ・タスクの実装時、合わせてテストを書くことが 多い → テストの書き方で方針ある場合はSteeringに 書くのが良い ・実装方針にズレがある場合 　・タスクのチャットの中で調整 　・SpecやSteeringを変更して明示指定
35. コンテキストエンジニアリング LLM（大規模言語モデル）エージェント におけるコンテキスト管理の重要性と 手法 Kiro使うと仕様駆動は事前のコンテキ スト設計を強制することで、曖昧さを 排除し最終的な成果物へ到達する時 間を効率化 AIエージェントが開発フローにも入っ てきて、人側も最適化が必要になって いるという見方も... https://rlancemartin.github.io/2025/06/23/co ntext_engineering/
36. 既存のプロジェクトをKiroベースに乗り換えた感想 36 ・新規よりKiroスタイルへ移行が楽！(ゼロから設計書かないで良い..) ・既存のSpecやSteeringを変更から、タスクへの追従が正確 ・初動は仕様を作る必要があるので少し大変。ただ必要なコンテキストをSpecや Steeringに落としこみ、型が出来れば爆発的に早くなりそう... ・今後も特定のスタイルを強制し、効率的なAIコーディングエージェントが流行るかも？ ・AIモデルはこれからも向上するので、同じSpecとSteeringでもシステム品質向上、負 債解消の効率化が望めそう 🌟 以上、ありがとうございました！