🐷

Kiro を使ったときの備忘録

に公開
GenAI
Kiro
tech

Kiro

https://kiro.dev/
Amazon の作成した AI IDE。Copilot を使った Vibe Coding では難しかった開発の制御を、要求、設計、タスクを作成してから実装するという方法論をサポートする。

作りたいものを入力（requirements)し、設計(design)に落として技術的な内容を確定、その内容をタスク(task)に落とし込んで、タスク毎に開発を進めていく。

特徴

Spec（仕様）

要求（Requirements）、設計（Design）、タスク（Task） からなる、作りたいものを記述したMarkdownファイル群。
機能単位で作成するのがいいとのこと。
https://kiro.dev/docs/specs/best-practices/#how-many-specs-can-i-have-in-a-single-repo

Steering (ステアリング）

Kiro に指示する共通情報をまとめた Markdown ファイル。Claude Code は使ったことがないが、CLAUDE.md みたいなものっぽい。AI に常に実行してほしい内容を記載しておくファイル。
標準で作成すると以下の3つが生成される。

  • product.md
  • tech.md
  • structure.md

product.md

作成したいもの（プロダクト）全体の情報を記載する。
記載しておく内容は以下のようなもの。

  • プロジェクトの概要
  • ユースケース
  • 機能

tech.md

プロダクトの技術的な条件を記載する。

  • 開発環境
  • 規則
    • コーディング規約
    • 実行してほしいこと（PowerShellで実行させるため、rm -rf は使わないなど）
  • 使用するフレームワーク、ライブラリ
  • テスト方法
  • 各種コマンド（npm run devとか）

structure.md

プロジェクトの構造を記載する。

  • ディレクトリ構成
  • ファイルの分割ルール
  • 命名規則
  • ドキュメンテーション

条件

ステアリングファイルは適用する条件を指定できる。デフォルトは常に読み込むになっているが、特定の拡張子やファイルを処理するときだけ適用するステアリングを作れる。

Tips

ステアリングファイルの更新は直接編集でもいいが、基本チャットから指示するのがよい。例えば、React18以降で React のインポートが不要になっているが、AI が生成するコードが常に React をインポートしようとするような場合、ステアリングファイルに追記して再発しないようにしてとか伝えるとステアリングファイルを更新してくれる。チャットから更新すれば AI が理解できるように細かく書いてくれる。

ステアリングファイルはどうやらセッション（チャットの単位）で読み込むので、適宜再読込させる。

Hook

特定の条件（ファイル保存時）などに実行させる一連の処理を記述する。
まだつかってないのでドキュメントを参照。使ったら更新する
https://kiro.dev/docs/hooks/

流れ

  1. ステアリングを作成する
    • プロダクトの全体像を書く
    • チャットで product.md を更新してもらうのがよい
    • 日本語で作成してといえば日本語で進められる
  2. 要求を作成する
    • product.md から要求を作成してと伝えれば、どの機能から始めるか聞いてくる
    • 機能毎に要求をつくるのがよい
    • product.md がある程度自動作成されるので、必要に応じてチャットで修正する
    • 要求が確定したら設計に進むと伝えれば、設計フェーズに進む
  3. 設計を作成する
    • 使用する技術、アーキテクチャ、データモデルなどがある程度自動生成される
    • 要求と同じく、必要に応じてチャットで修正していく
    • 設計が確定したら、タスクに進むと伝えれば、タスク定義フェーズに進む
  4. タスクを作成する
    • 設計から作成していくステップをタスクとして定義してくれる
    • tasks.md をみてタスクの順番や粒度の修正を指示していく
    • Git のコミットの粒度などで分割するとやりやすいかもしれない
  5. タスクを実行する
    • タスクの各ステップの Start task をクリックするとそのステップを実行してくれる
  6. 実装できたら次の機能について2-5を繰り返す

Tips

  • ステアリングを修正させる
    • Claude Sonnet 4 でもかなりミスを繰り返すので、失敗している内容は都度指摘してステアリングファイルに反映させる
  • できるだけ粒度を細かく
    • おまかせで作成されるタスクの粒度はかなり大きい
    • テスト可能な単位で細分化させるとよい
    • 粒度が大きいと修正されるファイルが多くて、なにをどこまでやったのかわかりにくい
  • テストファーストができるようにする
    • AI が作成したファイルの正しさを手動で担保するのは困難
    • AI が正しさを理解する目を与えるため、自動テストが必要
    • AI はエラー発生時に自動テスト側を修正して無理矢理通そうとするので注意
  • E2E テストを早めに作る
    • 前述の通り AI が正しさを理解するためにはテストが必要
    • UI の正しさの担保が難しい
    • E2E でスクリーンショットを保存してもらいつつテストすると、AI がどこまで進めたのか、AIが期待通り作成しているか、なにか壊してないかを見つけやすい
    • UI は変わりやすいが、AI が自動的につくってくれるので、テストを作成・変更するコストは大分下がった。
      • AI が理解しないで壊していく方が怖い
  • vite のエラーログを拾えないので E2E テストがループする場合がある
    • その場合はいったんテストをキャンセルしてエラーログをコピペして修正させるとよい
    • そもそもエラーが残っている状態でテストを実行するのが問題なので
      • E2E テストの前にビルドとLintを通すようにステアリングにかく
      • VSCode の Problem に表示されるエラーと警告は全て修正させる
      • その後に UnitTest と E2E を実施するというフローにすると良い

他に思いついたら随時追記する。

Discussion