作成開始から完成まで2日です。(細かいエラーもまだまだたくさんのこっているけど)
ゲーム「スペルトナエル」の歌ビルド補助ツールを開発した経験と、その開発プロセスで活用したAI開発ツール「kiro」の具体的な使用感について紹介します。
Kiro: The AI IDE for prototype to production
https://kiro.dev/
特に、kiroの導入による開発フローの変化、直面した課題を同じツールの導入を検討されている人の助けになればなと思います。
ゲームツール「スペルトナエル歌ビルド」について
この記事では、kiroが開発したゲームツール「スペルトナエル歌ビルド」について紹介します。
プロジェクト概要と目的
masakinihirota/spell-search-site
https://github.com/masakinihirota/spell-search-site
このWebアプリは、スペルトナエルというゲームにおいて、プレイヤーが「歌ビルド」をより効率的に行えるようにするための専用ウェブアプリです。(あまり便利なツールが出来たとは言えませんが、本当に素人が作っても同じようなクォリティのツールが作成可能になったと思います。)
「スペルトナエル」は、ボードの文字を辿って呪文を唱えてキャラクターを強化していくローグライトなゲームです。
名作で安い！
Steam：スペルトナエル
https://store.steampowered.com/app/3107590/_/
320円
👆️この補助ツールをkiroで作ってみました。
開発ツール「kiro」の活用と体験
このセクションでは、AI開発ツール「kiro」を使った開発プロセスと、その中で得られた具体的な体験や知見について解説します。
kiroは、要件定義から設計、タスク管理までをAIが支援してくれる強力なツールです。
呪文検索とkiroの使い方
開発ツール「kiro」を使って、どのようにプロジェクトを進めるかについて解説します。
kiroは、プロジェクトの初期段階から開発の各フェーズにおいて、AIの支援を受けることで、効率的な開発フローを構築できます。
機能ごとの要件定義の作成の重要性
大規模なアプリケーション開発において、一度に全体の要件定義を作成しようとすると、その複雑さから途中で止まってしまうことがありました。
そのため、1機能ごとに要件定義を作成することを強くお勧めします。
このアプローチにより、各機能に集中して深く掘り下げることができ、全体の進行状況も把握しやすくなります。
kiroを使えば、AIを立ち上げるだけで仕様駆動開発を始めることができます。
kiroのAIは、与えられた情報に基づいて要件定義書や設計書、タスクリストを自動生成し、開発の初期段階を強力にサポートしてくれます。
（バイブコーディングについては、今回のブログでは触れていませんので他の記事をご覧ください。）
開発において、最初の段階は非常に重要であり、最も時間をかけるべき部分です。
ここでの認識のズレや設計ミスは、後からの修正が指数関数的に難しくなり、プロジェクト全体の遅延やコスト増加に直結します。
kiroのAI支援は、この初期段階での精度を高めるのに役立ちます。
新しいセッションを機能の区切りごとに作成し、各機能の開発が完了し、動作確認が取れたらすぐにgit commitを行うのが良いと思います。
kiroには一応revertボタンもありますが、その動作には不安があるため、Gitのコミットまで戻る方が安心で確実だと思います。
失敗談とそこから得た学び
kiroを導入するにあたり、自作の大型要件定義書を読み込ませようとした際に、以下のような問題に直面しました。これはkiroの特性を理解する上で非常に重要な経験となりました。
既存の約5000行もある大規模な要件定義書ファイルをkiroに読み込ませて開発をしてみましたが、期待に反して途中で処理が止まってしまいました。
#kiro だめだ復活したと思ったら、5時間前の「続きを書いて」という命令の後の Working...中でずっと終わってない。 requirements.md が100行ぐらい design.md が500行ぐらい tasks.md が400行ぐらい やっぱり量の問題なのか？
この結果、kiroによって生成されたファイルは、.kiro/specs/[セッション名]/requirements.mdが約100行、design.mdが約500行、tasks.mdが約400行でした。これは、元の5000行の要件定義書が大幅に圧縮された形です。
それでも止まってしまいました。
(今回のこの例だけが特殊かもしれませんが)
この経験から、最初にkiroに渡す自作の要件定義書は、小さくするか、あるいは機能ごとに明確に区切って渡す方が良いと思います。
私の渡した要件定義書がスカスカだった可能性も否定できませんが、それ以上に、一度に処理できる情報の「量」に限界があると思います。
kiroでの開発
新しいセッションの開始と設計書開発フロー
kiroのAIチャット欄の上部にある「＋」ボタンを押すことで、簡単に新しいセッションを開始できます。
セッション開始時には、「バイブコーディング」か「仕様駆動開発」のどちらかを選択するよう求められます。
ここで「仕様駆動開発」を選択すると、kiroと対話をして、要件定義書や設計書、タスクリストを作成します。
実際、機能ごとにセッションを開始すると、kiroは自動的に.kiro/specs/[セッション名]/requirements.mdファイルを作成します。このファイルには、その機能の要件が作成されます。
セッション名はkiroの会話の単位となります。会話が長すぎると、kiroがそれまでの会話内容を要約しようとし、新しいセッションを開始するように求められることがあります。これは、AIが一度に処理できるコンテキストの量に限界があるためです。
そこで、上記の失敗談を踏まえ、短い要件定義書を渡してみたところ期待通りの成果物が得られました。
この成果物で「スペルトナエル歌ビルド」を作成してみました。
kiroとGit Worktreeの連携
git worktreeに対応させるため、.kiroフォルダをソースコードのリポジトリとは別の場所に配置してみました。
git worktreeで新しいブランチを追加する際、ブランチ用の作業ディレクトリをメインのソースコードフォルダと並列に配置できます。
この構造であれば、.kiroフォルダを一つにまとめて管理できるのではないかと思います。
以下は、そのフォルダ構造です。
.
├── .kiro
│ ├── specs
│ │ ├── header-next-project-link ＜＜＜機能ごとにセッションを新しく作っています。
│ │ │ ├── design.md
│ │ │ ├── requirements.md
│ │ │ └── tasks.md
│ │ ├── reset-button ＜＜＜機能ごとにセッションを新しく作っています。
│ │ │ ├── design.md
│ │ │ ├── requirements.md
│ │ │ └── tasks.md
│ │ └── spell-search-site ＜＜＜機能ごとにセッションを新しく作っています。
│ │ ├── design.md
│ │ ├── requirements.md
│ │ └── tasks.md
│ └── steering
│ ├── general-instructions.md
│ └── vns-development-rules.md
└── spell-search-site(mainブランチ) ＜＜＜GitHub公開フォルダ
├── data
├── src
├── _todoメモ.md
└── README.md
spell-search-site(devブランチ) ＜＜＜git worktreeのブランチ用のフォルダ(今回は未使用)
この構造により、各機能のspecsフォルダ（requirements.md, design.md, tasks.mdを含む）が.kiro/specs以下に整理されます。
実装が完了し、機能が安定した段階で、specsの下の各機能フォルダを別の場所（例えば、プロジェクトのドキュメントアーカイブなど）に移しています。これにより、開発中の作業スペースをクリーンに保ちつつ、過去の設計ドキュメントを管理できます。
kiroのAIチャット欄上部の「＋」ボタンを押すと新しいセッションが始まり、そのセッション内でrequirements.md、design.md、tasks.mdが順次作成されていきます。
ソースコードの修正を手動で行っても問題はありませんが、kiroが動作している間はAIの生成プロセスに影響を与えないよう、手動でのコードやドキュメントの変更は止めておいたほうが良いと思います。
開発時、1つのセッションごとに
requirements.md
design.md
tasks.md
の3種類のファイルが作成されます。
このファイルが作成された後は、
kiroにタスク名を指示をするか
tasks.mdを開き(./kiro/spec/[セッション名]/tasks.md)
そのファイル上に開始ボタンがあるので、自分が実装してもらいたいタスクの Start task ボタンを押します。
tasks.mdを途中で少し修正したい時は、少しの修正だろうが最初からやり直したほうがいいと思います。
きちんと前に戻って3つのファイルの整合性を取りましょう。
(後で見返す時があるかもしれません)
requirements.mdは、何を作るかのAIとの相談のまとめであり、
design.mdは、相談したものを、何を使って作るかの、どうやって作るかの相談のまとめであり、
tasks.mdは、相談したものを実際にどう実装するかの計画です。
テクニック
スクリーンショットを取ってkiroに渡す。
Win11ならshift + Win + S
エクスプローラーのピクチャフォルダに保存されます。
kiroは画像を認識するので、問題部分を撮って渡し、
問題箇所を指摘するだけで理解してくれます。
例えば、文字が読みにくいと思ったら
その部分をスクリーンショットにとって
ピクチャフォルダを指定してkiroに渡します。
「そして文字が薄いので読みやすくしてください。」
とお願いします。
複数の問題を指摘したとしても、
kiroはその複数の問題を一つ一つ分解して
それぞれ個別の問題として対応をしてくれます。
タスク実装中でも割り込みが可能
Working...中でもAIに話しかけることが可能です。
中止させたい時や、説明が足りないと思った時などに便利だと思います。
「これはなんですか？」
「現状どうなっていますか？」
などと質問すると、AIは現状を報告してくれます。
作業を続けてもよろしいでしょうか？
と聞いてくるので
さらに質問したり、
作業の再開を指示します。
「作業を続けてください。」
で続けてくれます。
ループにハマって止まっていると思ったら
working...が長い・・長すぎる
「現状どうなっていますか？」
などと質問をします。
そうすると現状を説明してくれます。
こちら(自分)で出来ることを色々試します。
ボタンの反応がない時もありましたので
長いと思ったら時々チェックします。
フリーズしていた時はエディタを再起動しました。
長いのはタスクが大きすぎるのが原因かもしれないので
要件定義 requirements.md の量を少なくします。
タスク終了後
通常、次の要件定義をAIに書いてもらいますが、
その待つ間に、gitのコミットやその他雑用、ルーチンワークを済ませておきます。
結構忘れがち。
作成された要件定義書
これはしっかり読む
- 自分の意志が反映されているか？
- 余計な機能がついていないか？
などをチェックします。
AIは結構忖度してくれます。
逆にそれは処理が重くなっちゃうだろうという機能も便利だと思って付けてくれるようです。
1つの要件定義書に複数の機能の追加を要望することも出来ますが、
小さいの機能ならば問題ないと思います。
でもできるだけ基本は1要件定義書で1機能にしておくのが後々の整理のためにも無難です。
機能追加ごとに.kiro/specs/ のフォルダ増加問題
タスク完了後は別の場所に移しています。
自分は独自に .kri/archives というフォルダを作って、そこに終わったセッションのフォルダを移動させています。
kiroの良い所
素人でも基礎を抑えておけば同じようなクオリティで出来る。
ソースコード全体を必ずチェックしてくれる。
ほぼおまかせできる
開発者はルーチンワークをやっておく。
フックがある。
フックとは、例えばマラソンで発砲したらスタートするみたいな、
なにかきっかけがあれば、その条件を満たした時に決まった作業を自動でしてくれる機能。
良くない所、悩む所
暇
ちょっと遅い。
エラーでも構わず作る
(npm run devでは動くが npm run buildは失敗した)
Working...中は反応がわからない。
開発の会話が主体で、一般的な質問がしにくい。
どのような話題も、開発に絡めてファイルを確認してくる。
並列に作業を頼めない(出来るかも)
1つのkiroウィンドウでは並列に作業を行ってもらえません。
(複数kiroウィンドウ、 git worktreeはまだ試していません。)
複数ウィンドウを開いたら出来るかも・・・
(working中に書いています)
Claude 4 Sonnetはすぐリミットになる
現在は3.7だけを使って開発しています。
現状無料だからそれはそう。
削除系のCLIコマンド
普通に使ってくるので、
信頼して任せるか、
自分で毎回コマンドを確認するかをします。
自分の場合は、最初に色々要件定義をもりすぎて余計な機能を色々とつけすぎたため、後からその機能の削除依頼をした時に使う羽目になりました。
Next.jsで開発時
npm run dev
では動くが
npm run build
ではエラーがでるパターン
vercelにデプロイ時に、vercelでbuild時に発覚。
git commit 時に、
もしくは
githubにデプロイ時に
npm run buildを走らせる
huskyなどのツールを使用して自動実行を設定しておく。
CLIコマンドの管理とセキュリティ
kiroが開発プロセス中にmkdirなどのCLIコマンドを実行しようとする際、そのコマンドの実行許可をユーザーに求めます。
これはセキュリティ上の配慮であり、AIが意図しない操作を行うことを防ぐための重要なステップです。
コマンドの内容を確認し、問題がなければ許可を与えることで、kiroは次から自動でコマンドを進めることができます。
この機能により、開発者はAIの行動をコントロールし、安全に開発を進めることが可能です。
まとめ
本記事では、「スペルトナエル」というゲームツールの開発事例を通して、AI開発ツールkiroの具体的な活用方法とその効果についてご紹介しました。特に、機能ごとの要件定義の重要性、大規模プロジェクトにおけるkiroの限界とそこから得られた教訓、効率的な開発フローについて解説しました。
kiroは、開発の初期段階におけるドキュメント作成やタスク管理を強力に支援し、開発効率を向上させる可能性を秘めています。しかし、その能力を最大限に引き出すためには、AIの特性を理解し、適切な粒度で情報を与えることが重要です。今回の経験が、皆様のAIを活用した開発の一助となれば幸いです。
本当の意味での素人でもAIコーディングが出来るようになりました。
でもまだちょっとは経験(者)の補助が必要です。
このプロジェクトは何を使えばいいのかなどの知識があれば なお良いです。
成果物＆関連URL
攻略
スペルトナエル(持ち込み無し) U-END を楽にクリアするための「考えない歌金魚ビルド」 ｜masakinihirota
実戦動画
スペルトナエル(持ち込み無し) U-END を楽にクリアするための「考えない歌金魚ビルド」 - YouTube
👆上のビルドを楽にするためのツールを作成
コード
masakinihirota/spell-search-site
公開サイト
スペルトナエル検索サイト