kiroを参考にローカルLLMで仕様駆動開発してみる ～仕様が決まればローカル丸投げも夢じゃない～
こんにちはRcatです。
最近業務でkiroが解放されました☆やったね☆
説明を受けたのですが、仕様駆動開発のやり方は業務では上流過ぎて使えないんですが、個人開発ならそのまま使えると思いました。
というわけで、流れだけパクって個人のローカルLLMを使った開発にも取り入れてみようと思います。
はじめに
利用規約
情報や作品の活用時は事前に利用規約をご確認ください。
コメントについて
利用規約のガイドラインを確認の上コメントしてください。
則っていないコメントは削除します。
概要
仕様駆動開発とは
kiroの開発元がたどり着いた方法で、AIに思い通りのものを作らせようとプロンプトを工夫してたら、いつの間にかプロンプトが仕様書になってたというところから生まれたものらしいです。
要するに、完璧にできた仕様書から作った設計書があれば、あとはどんなAIに何度丸投げしなおしても大体同じものができてくるという考え方。
たしかに、いままで「OO作って」、「OOするコード書いて」「OOに変更して」ばっかりで、仕様書など作っていませんでした…。
そりゃあとからの改造で不整合が起きるわな…。
仕様駆動開発モドキを開始する
ここでは、kiroは使わないのでモドキと表現することにします。
ただし、やってることはちゃんとした仕様を定めてからAIに投げるというkiroと同じ考え方です。
Geminiと壁打ち
本来であればここからローカルLLMで進めるべきなんですが、さすがに知識量では敵わないため、Geminiとチャットでやり取りします。
高性能なモデルならローカルでもいいでしょうが、やり取りを重ねるこの段階だけは待ち時間的に商用AIに任せた方がいい。
何より、この最上流の仕様書に漏れがあると後段でごたごたします。
※もし世間的に新規アイディアの場合は絶対にGeminiに話さないでください。話したことで新規性が失われ特許が取れなくなるリスクがあります。
そういう場合はローカルLLMにしましょう。NDAで大丈夫ならNDA付きの有料チャットを使いましょう。
とりあえずこんな感じで話しかけました。
最後のは話し中にコード書かれたら困るのでダメ押しです。
作りたいものがある。
それの仕様書を一緒に作ってほしい
こっちから情報を少しずつ出すので、仕様書として足りないものを教えてほしい。
そして最終的に完璧な仕様書を作ろう
※今回はあくまでも"仕様書"であり設計書ではない 
Geminiの案内に従い仕様を決めていきます。
言われるがままでもいいですが、譲れない仕様があれば先に言ってしまいましょう。
ドラフトを書いてくれるようになったらじっくり確認して、思ったのと違うところは修正を加えていきます。
ダメ押ししながら完成させる
kiroから学んだポイントです。
少しでもあいまいなところが残っていると、AIが勝手に決めてしまい、同じ仕様書からちょっとずつ違うものができてしまいます。
そうならないように、細かいところで決まってないところがないか何度かダメ押しします。
私から見ても問題ないかな。
あとはこれから設計書を作成するとなったときに、よく考えたら細かいところ決まってないから勝手に決めちゃえってなっちゃいそうなところあるかな?
例えばUIの色はモダンにするとか書いておけばカラーコードまで指定しなくても超変なことにはならないかと。
こんな感じ?
出来ましたとか言っておいて、「設計書作ろうと思ったらどう?」と聞くとまだ出てくるようです。
Geminiがコーディングに入りたそうになったら終了。
チャットをコピーしてmarkdownで貼り付けましょう。
Geminiの返事とまとめの言葉を削除すれば、そのままMarkdownとして保存可能です。
仕様書生成のポイント
Geminiのチャットだと、仕様書の一部変更でも毎回全体を書き直してしまいます。
チャットの仕様なので仕方ないですが、差分表示ではないので本当に指摘したところだけが変わっていて、他は同じである保証がないです。
そのため、毎回全体を確認しましょう。
それは面倒な方（私とか）は最初のドラフトを少し訂正した時点でコピーして、ローカルLLM(ZooCode)に持っていきます。
そして、Geminiに指摘した個所や推奨変更点などをローカルLLMに渡してピンポイントで書き換えてもらうのが楽。これなら差分で見られるので。
あとはアスキーアートのmermaid化などをしてもらってプレビューできるのもローカルLLMのいいところ。
仕様書から実装を行う（OpenHands）
仕様書ができたらあとはローカルLLMで実装を行います。
プラットフォームはOpenHandsです。
実装するもの
Geminiとの会話などで若干気づいてるかもしれませんが、個人用パスワード管理WEBアプリを作ります。
特徴は暗号化関連を全部フロントで行うこと。こうすることでhttps化できない環境でも安全にデータを扱うことができます。
Googleのパスワードマネージャーとかで事足りるんですが、たまに反応しないサイトとかありますし、そういう用途です。
AGENTS.mdでkiroっぽく縛る
kiroは仕様書ができたら次に設計書を作成し、最後にWBSに分解してから開始します。
この動きをトレースするためには単純にそう指示すればよいですが、毎回面倒なので固定化します。
丁度いいのがいますね、そうAGENTS.mdです。
やり方を記述するので、大きく間違った使い方ではないはず。
とりあえず重要なのはここ。
4番以降はプロジェクトに沿ってテストとか環境構築とかそういった内容を入れるのがいいと思われます。
その下には注意事項を入れておきます。
まずは再度ダメ押しの仕様の確認と質問タイム。あとからやっぱりわからないと言われても困るので…。
次に整合性を取ること。これはkiroがやっていることで、常に3点セットは同期しています。同じことを指示しておきます。
ユーザーレビューのタイミングもそうです。実装より前の時点は毎回みます。
逆にそれ以降は勝手に進めてほしいので、聞くなと厳命。
この辺はローカルLLMのお約束。
特にsed使われたときなんかたまったものじゃないので禁止禁止!
まぁこういうのはHook使えなんでしょうけど忙しくてまだできてない
OpenHandsで実装開始
リポジトリをOpenHandsのプロジェクトフォルダに格納します
UIからリポジトリを選択して実装開始!
プロンプトはこんな感じにしました。
OpenHandsはAGENTS.mdがシステムプロンプトにマージされないっぽいので、念のため最初に読むように指示。
それさえ読めば仕様書を読んでやれということが書いてあるので進むはずという寸法。
このプロジェクトを実装してください。
実装のルールや規約はAGENTS.mdに記載してあるので、最初に読んでください。
仕様書はspecsの中にあります。というわけで開始。
モデルはLaguna S2.1（118B-A8 IQ4 NL）（Vulkanビルド）でやってみます。
さて、あとは放置です。さすがにMoEでも100Bモデルは重い。
設計書レビュー
ちゃんと止まりましたね。kiroでもここをちゃんと人間が介在するのが推奨されています。
ここで内容をチェックします。OpenHandsには差分表示機能があるため、そこから出力されたファイルを見ます。
markdownのプレビューにも対応
表とかもばっちり見られます
大丈夫そうなので、一部の指摘だけ直させて実装させます。
今回はOpneHandos自体がDockerなのでその辺はできない趣旨を伝えておしまい。てかsbxじゃないならコンテナ権限はまずいw
実装
ここは特にいうことはありません。終わるまで待つだけです。
結果報告
次の日起きたら終わってました。
Agents.mdが抜けたのか報告は英語だったw
でもREADMEなどの文書が日本語だったので、それ見ればいいのでOKとする。
実際に動かしてみる
さて、問題は動くのかです。
とりあえずDockerは後回しにして、venvで環境作って動かします。
vue.jsはブラウザで動かした=ビルド済みでデータが入っているのでそのまま使えます。
ログイン画面
まず最初に表示される画面。あってますし、構成もOK
新規登録画面
ログイン画面のリンクから飛べる。これもOK!
パスワード参照画面
ログイン後に飛べる画面。
これもOK
パスワード登録画面
一覧画面から新規や変更で飛べる画面。これもOKですね
データベース
いくつかデータを登録して確認。こちらも問題なさそうですね。ちゃんと意味不明な文字列が登録されています。
まとめ
今回はkiroをヒントに個人開発にも仕様駆動開発を導入してみました。
もしこれが、今まで通りの適当なバイブコーディングなら一発で目的通りのものはまず出なかったでしょう。
ローカルLLMの方も高性能なものを使ったというのはありますが、それでも目的のアプリを一発で作ることができたのは大きいです。
今後は個人でも組みながら考えるのはやめて先にちゃんと仕様を決めてから作るようにしたいですね。
それではまたお会いしましょう。
リンク集
感想投稿フォーム
コメントは公開で恥ずかしい!! Rcatだけに送りたい人向け
