お疲れさまです、みやもとです。
AIが書いてくれたコードを読んであれこれ考えたりする記事を３つくらい書いたところで少々心がくじけてきたというか、正直ちょっと飽きてきたので今回は別のことを書きたいと思います。
AIを使った開発がどんどん進化してますが、みやもとの業務はあんまりAI活用が進んでません。
さすがに全く使わないとはいかないまでもチャットであれこれ調べものする程度で、設計から頼んでコードを書いてもらって…というのはだいぶ先になりそうです。
しかし仕事で使わないとはいえ、エンジニア界隈で流行っているというならちょっとぐらい手を出してみたい。
おあつらえ向きに仕様駆動開発をやってみようというイベントに参加したこともあり、いくつかお試しでアプリを作ってみた感想とか今後やっていくときに気を付けたいこととかをメモっておこうと思います。
ちなみに参加したイベントはこちら。
仕様駆動開発とは
個人的なメモも兼ねるため、基本的なところから書いていきます。
仕様駆動開発（Specification Driven Development、以下SDD）とは、ソフトウェア開発の手法の一つで、開発プロセスの初期段階で詳細な仕様を定義しその仕様に基づいてコードを書く方法です。
ことAIコーディングにおいては、定義した仕様を元にしてAIに以降の開発工程を実行させることを指していると解釈しています。
ちょうどQiitaに記事があったのでリンクはっておきます。
AIコーディングが流行り始めたころ、イベントでVibe CodingとしてAIエディタに簡単な要求を伝えてコードを書いてもらって動くものを作る、というのをよく見かけましたが、手軽にさくっと動くものを作るVibe Codingに加えて、SDDは伝える要求をしっかり詰めてより高品質なものを作り、一度作ったプロジェクトに対して仕様追加したり修正したりする際にスムーズに対応できる印象です。
とりあえずやってみる
SDDに挑戦するにあたり、使ったのは以下のツールです。
- Gemini
AIエディタを使う前段階で、要求をまとめるために使いました。この記事の中で使ったGemのプロンプトをちょっと修正して使ってました - Google Antigravity IDE
AIエディタとして使用。たまたま少し前のイベントで紹介されていたので使ってみたくて…。あとGoogleなので、アカウントとか改めて取り直さなくていいし。 - cc-sdd
Kiroをモデルにして作られた、SDDをAIエージェント上で実現するためのツール。Claude Codeがベースのようですが、Gemini CLIやAntigravityも対応してます。
私の場合まるきり初めてで何もかもさっぱりだったので、Claude Codeのskillsでインストールしてドキュメントを見ながら使ってました。
手探りの実行手順
何度も言いますが私はAIを使った開発に関してはまるきりど素人の状態です。
開発の手順にしても手探りもいいところで、ほぼAIに言われるがままに進めていました。
まず要求定義を作ってもらう
最初にGeminiのGemを使って、要求定義をまとめます。
チャットで
- アプリの概要
- 欲しい機能
- 使いたい技術
あたりを伝えると、Geminiがあいまいなところについては質問してきて、私が返した答えをもとに要求定義を作ってくれました。
要求定義をAIに渡す
要求定義ができたところで、Antigravityを開いてチャット欄から要求定義を送信します。
その際、「/kiro-discovery」に続けて要求定義を貼り付けることで、AIが仕様駆動開発の動きに沿って各種ドキュメントファイルを作ってくれます。
後は確認・承認だけ
ここからはほぼほぼAIにお任せでした。
できあがったドキュメントファイルに目を通して、質問をすれば回答してくれますし、ちょっと違うと思えば修正してくれます。
私はそれにOKを出してどんどん進めてもらうだけ。早い。
やってみた感想
とにかく速い。
すごい勢いでドキュメントとかコードとか生成されて動くものができていく。
使いこなせたらそりゃ便利だし生産性も爆上がりだろうな、というのは実感としてわかりました。
特に個人開発に関して、とりあえず動かせるというのは成果が目に見えやすくモチベーションを保ちやすいですし、動かす中で見つかる改善点をどんどん反映させていくことができるのですごく楽しい。
それを踏まえて、個人的に良かったこと、ちょっと気を付けたいことは以下の通りです。
良かったこと
足りない技術を補ってくれる
自分ができないことでもAIがやってくれるので、「やってみたいけど難しい」で諦める部分が減ります。
私の場合は絵心とかデザインセンスが壊滅的なのでフロントエンドとかかわいいキャラクター付きのアプリとかはまぁ無理と思っていましたが、AIに頼むとそれなりいい感じにしてくれるのですごく楽でした。
特にUIに関して、「どういう理由でこのカラーリングにしています」というところまで仕様に書いてくれるので割と納得して進められました。
ただ、書いてくれるコードに偏りを感じなくもないかな、とは思いました。
私はバックエンドの人間で個人的に勉強したい言語もバックエンド寄りのため、AIにお願いする時にも「バックエンドとフロントエンドは明確に分離して、バックエンドはこの言語かこの言語でお願いします」という指示を出していました。
あわよくばAIが書いたコードを読むことで勉強にならないかな、という思惑です。
ただ、実際にAIに書いてもらうと、バックエンドとして指定した言語で書かれたコードは最小限で、他はほとんどフロントエンドと共通で使えるTypeScriptで書かれていました。
ほっとくと全部TypeScript（というかReact）で書かれてしまうので、「この機能とこの機能はバックエンドに置いて、フロントエンドにはこの機能だけ」みたいに明確に区切らないといけないのかなと。
ハマりが少ない
これ不具合かな？と思った時や、どうしてこんなことに？と思った時に、AIに指示すると原因調査と修正案を速攻出してくれて修正・テストに進めるので、不具合原因がわからなくて延々悩む時間がほぼありませんでした。
これに関しては私が多少なりコードを読めたり画面触ったりした経験から、「こういうことが起きてない？」と目途を立てた上でAIに質問できたのも良かったかもしれません。
気を付けたいこと
AIと人間の目の違い
開発時、AIはテストの実施報告で「PCでもスマートフォンでも画面のレイアウトが崩れてないことを確認しました」と報告してくれました。
実際開発中はPCで見るので確かに崩れてないな、と思って見てました。
それが実際スマートフォンで見たら、こう。
いや、めっちゃ崩れてますやん。
使ったデータの関係なのかAIと人間で「崩れた」の基準が違うのかはわかりませんが、こういうのがままありました。
防止策として、実装・テストの計画を出してきた段階で「最後に開発環境で起動してユーザー操作による確認手順入れてくれ」とやったことで多少改善できました。
スムーズすぎてチェック漏れ
実装されたアプリを触っていると、すごく初歩的なところでつまづいてるな、というのがしばしばありました。
例えば先の画面は介護関連の費用に対して誰がお金を出したのか、というのを登録していくアプリなのですが、介護者が全額出すケース、被介護者が全額出すケース、両者が折半するケースというのを想定していました。
画面には介護者・被介護者両方に金額の入力欄があり、折半した場合は両者がそれぞれいくら出したか、というのが表示される想定でした。
しかし、実際に実装してもらって使ってみると、両者の金額を入力しても片方が全額出した表示になる。
結局原因はデータ登録時のロジック実装に抜けがあったことだったのですが、テスト項目として挙げられていたなら実装までに判明して修正されていたはず。
これに関しては私がSDD、もっと言うとcc-sddのドキュメント形式に慣れず、記述をきちんと確認できていなかったのが原因だったと思います。
防止策はまだ試していませんが、箇条書きのドキュメント形式ではなく一覧表の形式にしてユーザーがチェックを入れる形にしてみるとかでしょうか。
次回何か作るときには試してみたいと思います。