昨日はAuth0ログイン画面出すまで実装すると書いてありましたがそこ間で行きませんでした...
今日から2日かけて初めてkiroに触った感想。ClaudeCodeやRooCodeと違う強みなどを紹介していきます。
まず、きょうはタスクリストまでの作成を通して感想を書いていこうと思います。
👻Hello kiro
spec駆動開発ということで、お試しでKiroを使ってみようと考えました。特にAuthの分野で使いたかった理由があります
- 早い段階でClaudeCodeのバイブコーディングとの比較をしたい
- ClaudeCode使うにしてもSpec駆動開発のノウハウを持ち帰りたい
- Kiroのお化けが可愛い
とりあえず手始めに、手元にあったChatGPT製仕様書をKiroにも解釈してもらいました。
🧵要件作成
画像はタスクリストを作成した後の画面ですが 左バーのお化けのタブ > SPECS から＋ボタンでSpecを作ることができ、要件・詳細設計・タスクリストにスムーズに移動することができます。
今回は、あらかじめ手元にあったChatGPT製仕様書を使いたかったため、以下のようなプロンプトで作りました。
「Create Spec: auth-serviceにauth/docksの下に設計が書かれているような設計の詳細を記述してください」
と質問。Create Spec:の部分が固定の命令（スラッシュコマンド）みたいになっていそうですね。
英語でかいてあったので日本語の仕様書に直してもらうようなアイスブレイクもありつつ（１段落ごとに書き換えてくれるの仕事が丁寧で可愛い）
結果を見ると、２つの項目を繰り返すような構造になっていて「これがしごできAIかぁ」とため息。
- 要件
- ユーザーストーリー
- 受け入れ要件
- リスト
そのあと
「Auth0を使うことを前提にした要件へ変更してください」
「Prometheus/lokiをつかって可観測性を高めたいのでそれを前提に作ってください」
みたいな追加要件を加えてDesignまで作りました。
要件150行/設計2000行/タスクリスト300行 ほどの成果物が最終的に出来上がりました。
⚙️いざタスクリストへ
設計は、細かいDB設計も含めた詳細なドキュメントを作っていただき、タスクリストを作る際に「タスクリストを作成してください。ただし、AIがテストを生成し、人間が実装するように役割分担したいのでそれを考慮したタスクリストを書いてください。」と指示しました。
これを行った結果このような感じでタスクを分解してくれました。これによって人間とAIの責任範囲がドキュメントになっているいいものが作れたように思えます。
- [ ]* 2.1 データモデルのテスト生成（AI）
- ユーザー、ロール、権限モデルのバリデーションテスト
- _Requirements: 3.2, 3.4_
- [ ] 2.2 データモデルの実装（人間）
- `internal/model/user.go`, `role.go`, `permission.go` を実装
- _Requirements: 3.2, 3.4_
📚Rooとkiroの決定的な違い
これを読んで決定的だなと思った違いがあります。それは「読み込むコンテキストの総量を自分でコントロールできるところ」です。Rooはせいぜい300行ほどのテキストを読み込むとリミットがかかっており、コンテキストに載せていくとAI特有のかどに一般的なことを言って使い物にならないなということがありました。一方でKiroはちょっと触ってみたところそのような感触は一切なく、英訳の時は１段落ごとという自分で適切な量に分割して読み込んでいるところが印象的でした。
また、task部分の上部に Start task をクリックするとデバックのようにタスクを作ることができます。この定義と実行の動線が密結合になっているのもKiroの魅力かなと思います。 Rooはサブタスクのプロンプトがはっきりわかるというメリットがありましたが、その進化の一つがKiroのタスクリストなのかなとワクワクさせてくれる体験でした。
🎀まとめ
Kiroをタスクリストまで使ってみました。この時点でRooと比べてもユーザビリティの細かいところ性能どちらもKiroのほうが使い勝手も良さそうだなと感じました。実際の実装や人間がやると書いてある部分をうっかり実装しないかなどいくつか不安がありますがそれは明日のお楽しみに！
🎅 明日は「AuthをKiroで実装するぞ」
AuthをKiroで実装してみてRooとの違いや実際のペアオペってどうなの？というところをお届けします！
Authの仕組みとかは明後日明明後日に自分のわかる範囲でまとめてみようと思います。お楽しみに！