🧠

Kiroみたいな開発をGemini-CLIでやってみた

に公開
GenAI
Gemini
Kiro
tech

tl;dr

Kiroが待機列（Wishlist）ができていて試せなかったので、いろいろ周辺情報を読み解いて、Gemini-CLIで似たようなことをやってみたら、わりといい感じの開発プロセスが回せそうな気がしてきたので、ここに書き記す。

事前に見たもの

セットアップ

  • Visual Studio Code （使いこなせてない）
  • Gemini-CLI （使いこなせてない）

開発の流れ（仮）

Kiroの周辺情報をいろいろ当たるとおおむね理解できると思うけれど、大まかな流れは、

  • 要求仕様（というか要件）を書く。要件は、「ユーザーストーリー」と、その試験項目としての「Acceptance Criteria（日本語？？）」で記述する。
  • Acceptance CriteriaはEARS（Easy Approach to Requirements Syntax）という記法で記述する。
  • 要求仕様が決まったら、そこから設計に落とし込む。
  • 設計ができたら、開発タスクに落とし込む。
  • 開発タスクを実行する。

という感じ。

上記で一旦最初のコードベースができると思うけれど、それが終わった後、徐々に改修していくプロセスは、やりながら会得する方向で。

要件に落とし込む

まずは、specs/requirements.md というそれっぽいファイルを作成して、要求仕様を記述する。

構成は、

  • 概要
  • 要件
    • 要件1
      • ユーザーストーリー
      • Acceptance Criteria
    • 要件2
      • …
    • 要件N
      • …

という構成。

人間様が要求仕様をEARS記法で記述するのは精神的負荷が非常に高いので、以下のプロンプトを使ってGeminiに修正してもらう。

specs/requirements.md を読み込んで、Acceptance CriteriaをEARS（Easy Approach to Requirements Syntax）形式に書き直してください。

で、書きあがった要求仕様（ユーザーストーリーとAcceptance Criteriaのセット）をレビューして大きな問題が無ければ、一旦、要件への落とし込みは完了。

要件→設計に落とし込む

要件が書き上がったら、次は設計に落とし込む。

設計と言っても、設計書を目次レベルでゼロから考えるのはしんどいので、Kiroのコンセプトのページや関連する周辺情報などから、「どういう目次や項目で設計書を作成して欲しいか」を明示して、要件から設計書に落とし込む。

使ったプロンプトは以下。

specs/requirements.md ファイルにはアプリケーションの要件が記載されています。要件を読み込んで、設計をしてください。設計においては、アーキテクチャ、コンポーネント、インターフェース、データモデル、エラーハンドリングの観点で設計を行い、設計した結果は specs/design.md ファイルに保存してください。

レビューした結果、特に問題が無ければ、次に進む。

設計→コードに落とし込む

ある程度設計が固まったら、いよいよコードに落とし込む。

以下のプロンプトで、まずは開発タスクを作成、つまり計画を立てさせる。

design.md の内容を元に、開発のタスクを計画してください。技術スタックは SQLite と Python/FastAPI を使うものとします。開発タスクを tasks.md というファイルに保存してください。

タスクが設計されるので、問題なさそうであれば、そのままプロンプトで指示して実行する。

フェーズ1とフェーズ 2を実行してください。

実装が終わると、動作確認方法などを教えてくれるので、それを実行しながら動作確認をする。

要件の追加・修正 → 設計 → コード

要件を追加・修正したい場合は、requirements.md に追記し、Acceptance CriteriaをEARS記法に変換する。

要件Nに追加したAcceptance CriteriaをEARS形式に変換してください

修正内容が問題なければ、設計の修正、コードの修正と進む。

要件の変更に合わせて設計を修正してください

設計の変更に合わせてコードを修正してください

コードの修正 → 設計

逆に、動作確認などでエラーが出た場合等、その場でコードを修正したい場合がある。コードを修正した場合には、その修正を設計に反映しておくことが望ましい。

というわけで、以下のようなプロンプトで、実装の変更を設計に反映しておく。

XXXXに関する設計情報を design.md に追記してください

魔法の言葉

  • 「要件の変更に合わせて設計を修正してください」
    • 要件を追加・変更して、設計を修正する場合
  • 「設計の変更に合わせてコードを修正してください」
    • 設計の変更が妥当なので、コードを修正する場合
  • 「XXXというエラーが発生しました。修正方法を考えてください」
    • 実行した際にエラーが発生した場合
  • 「要件Nに追加したAcceptance CriteriaをEARS形式に変換してください」
    • 適当な表現を、ちゃんとした要件の表現に直してもらいたい場合
  • 「XXXXに関する設計情報を design.md に追記してください」
    • その場で実装を修正してしまった場合、設計に残しておきたい場合
  • 「ここまでの設計書およびコードを分析し、ゼロから再度開発する場合を想定して、開発タスクを作成し、specs/tasks.md に出力してください。」
    • いろいろいじった結果、開発タスクを全体的に整理、アップデートしておきたい場合。

まとめ

まだまだ試行錯誤は必要そうだが、一応、「スペック駆動で生成AIを使った開発」っぽいものは、おおむね理解できてきた気がする。（一応、手元ではアプリのプロトタイプっぽいものが動いてはいるので）

あとは、GeminiならGeminiでもう少しきちんと使いこなして、Autopilotっぽくワークフローを回す負荷を下げていく方法を探求していきたい。（Gemini-CLI使いこなしてないし）

あと、きちんとテストを生成・実行するところまで持っていきたい。

Vibe Codingはあんまり語感的にも好きにはなれなかったのだけれど（もちろん多少試してみたうえで）、スペック駆動開発は個人的には性に合っていると感じる。

システム開発・アプリ開発に多大な工数（開発のみならずマネジメントも含め）を投下している諸氏には、ぜひ試してみていただきたい。

p.s.
Geminiにコードを書いてもらいながら、「神様が相手じゃ俺なんかパソコン少年みたいなもんだもんなぁ」という機動警察パトレイバーの篠原遊馬のセリフを思い出してしまった。

おしまい。

Discussion