今回は個人開発で作っているCMSアプリケーションの要件をまとめて生成した時にえた、Kiroでspecを作るときの落とし穴について書いていきます。
📌specをまとめて生成したい！
ある程度進んできた中で要件をSSOTにし、簡単な実装をKiro以外に任せる方針を取れないか試してみたくなりました。
また、マイクロサービス構成でサービスが増えるほど、仕様の整合性確認コストが跳ね上がりやすく、実装後だと手戻りも大きくなってしまうため１サービス作り切る前のこの段階でspecをまとめて変更する方針に変更しました。
⚠️できなかったこと1: specの同時生成
spec 作成タブで複数の spec を同時に生成し、例えば B を生成している間に、すでに生成済みの A を確認して A の修正タスクを追加する、というフローを使えば効率的にSpecを作れるなと考えていました。
しかし実際には、A のタスクがまだ作成されていない段階で別の spec を生成すると、既存の実装計画が上書きされてしまうことがあるようです。
この辺りは何が原因かまでははっきりとわからないのですが、この三つが連続でSpecを作成するような操作をした際に整合性が取れていない挙動をしているのが原因かなと思いました。
- 実際のタスクキューへの積まれ方
- Task in queueの表示
- specsの反映
specs画面の反映に関しては、.kiro/specs/アプリ名/requirements.mdが保存された段階で反映されるので、requirements.mdが保存されていることを確認してからspec作成のセッションを中断すればうまく同時生成できたかもしれません。
上の原因がはっきり分からない間は、使わないほうがいいと判断し、tasksを生成するまでを一つのタスクとして一つ作り切ってから次のrequirements.mdを生成してもらうように変更しました。
ただこれはコンテキストスイッチの観点から理にかなっていて、これができない仕様であることを今ではよかったなと思ってます。
🔗できたこと1: spec作成中に他のspecとの整合性を取る
spec を書いている最中に、別の spec（例：A）との整合性を取りたくなる場面があります。例えば「A で定義されているエンドポイント XX が存在するか確認し、なければ A の仕様に追加してほしい」と依頼すると、AI が A 側の spec を自動で更新してくれます。
この機能を無批判に使うと全体構造を崩すリスクがありつつも、実装中に関連機能を思いつくのはよくあることで、AI が spec 間の整合性維持を支援してくれる点は大きなメリットです。
また、Design/TaskのついかをしてくれるわけではないのでそのあとDesign・taskへの反映も忘れないよう気をつける必要があります。
🧭まとめてやってみての感想：
ChatGPTで都度まとめながら実装していた頃は、全体像が掴めず「いつ終わるのか？」という閉塞感が残りました。Auth機能を先に進めたことで、他領域の仕様が不透明なまま開発になり、不安も強かったです。
一方で、先にspecを全体的に作る方法は全体構造・相互依存・抜け漏れを俯瞰しながら検証できます。
「ここはREST？それともgRPC？」「このエンドポイントが足りない」といった論点を早期に解消でき、実装方針の迷いが大幅に減りました。
AIを併用する開発では、
- 全体specを先に生成
- spec間の整合性を調整
- 各サービスの詳細実装へ落とし込む
という順序が安定するのかなと思いました。
今回の経験を通して、先に全体感のDocをDocsに書いてからSpecをKiroに相談する流れで実装を進めていくとよいという学びを得ました。これは実際の開発の流れとも近いのでは無いかと考えているので「基本的には開発の流れに沿うようにKiroをつかっていくとよい」ということを頭に入れていこうと思います。