初めてのAI駆動コーディングに挑戦して、資産シミュレーションサイトを作ってみた話
最近、生成AIを使った開発（いわゆるAI駆動開発）がかなり盛り上がっています。
自分の職場でも OpenAI の Codex を触る機会はありましたが、正直なところ「一部分だけAIに置き換えている」感覚が強くありました。
そこで今回は、
要件定義 → 設計 → UI作成 → 開発 → レビュー
まで、できる限りAI主体で進めることを目標に、個人開発にチャレンジしました。
題材として選んだのは、昔自分で使っていた住宅ローン計算用のExcel。
これをベースに、資産シミュレーションサイトとしてWeb化してみました。
実際に作成したサイトはこちらです。
https://takeucom.github.io/asset-simulation-site/
この記事について
この記事自体も、ベースとなる内容・体験談・構成は自分で作成したうえで、文章整理や読みやすい形へのリライトは ChatGPT を活用しています。
開発だけでなく、発信面でもAIを活用してみた形です。
なぜやろうと思ったのか
AIでコード生成する話はよく見かけますが、実際には
- 要件定義は人がやる
- 設計は人がやる
- コードの一部だけAIが補助する
というケースも多い印象です。
それも十分便利なのですが、今回はもっと踏み込んで、
「自分は意思決定とフィードバックに集中し、実務作業はAIに任せる」
という形がどこまで成立するか試してみたくなりました。
また、Figma のAI機能である FigmaMake も気になっていたため、UI生成も含めて試してみました。
今回やったこと
1. Codexに複数人格（ロール）を持たせる
まず面白かったのがここです。
Codex に対して、役割ごとに人格を分けました。
- PdM：プロダクト仕様を考える人
- Designer：UI/UX担当
- TechLead：技術責任者
- Engineer：実装担当
- Reviewer：レビュー担当
この形にしたことで、相談内容ごとに視点が切り替わり、かなり進めやすくなりました。
2. Excelベースで要件定義
もともと持っていた住宅ローン試算Excelを元に、
- この入力項目は必要
- この条件分岐を追加したい
- 将来資産推移を見たい
- UIはもっとわかりやすくしたい
など、自分は「やりたいこと」を伝えるだけ。
それをPdM / Designer役が整理し、仕様化してくれました。
3. FigmaMakeでUI作成
仕様が固まった段階で、Figma の FigmaMake に依頼。
実際に画面を作ってもらい、かなりスピーディーに形になりました。
その後、
- 実際に触る
- 違和感がある箇所を洗い出す
- Codex側で仕様整理
- 再度FigmaMakeに指示
を4〜5往復ほど実施。
このサイクルはかなり有効でした。
4. ロジック実装
UIがある程度できたら、TechLead役に依頼して、
- モックデータ置き換え
- 計算ロジック実装
- 状態管理整理
- コンポーネント整理
などを進めてもらいました。
5. Engineer × Reviewer 体制で品質向上
最後にかなり効果を感じたのがここです。
- Engineerが実装
- Reviewerがレビュー
を繰り返しました。
特にReviewerに対して、
100点満点に対して何が不足している？
と聞くと、かなり本質的な改善点を返してくれます。
- バリデーション不足
- 命名改善
- 責務分離
- UX上の弱さ
- エラーハンドリング不足
など、人間のレビュー観点に近いものが出てきました。
やってみた感想
UI生成 → コード化の流れはかなり強い
FigmaMakeが出したコードをそのまま活かす前提なら、
デザイン崩れが少なく、安心感がありました。
「デザインツールの成果物を実装に渡す」ではなく、
デザインツールがそのまま実装物になる
感覚です。
画面修正はCodexよりFigmaMakeが得意
途中でレイアウト変更や項目追加を試しましたが、見た目の調整はFigmaMakeの方が綺麗でした。
つまり役割分担としては、
- UI修正：FigmaMake
- ロジック修正：Codex
がしっくりきました。
困ったポイント
クレジット消費が意外と早い
FigmaMakeは試行錯誤していると、かなりクレジットを使います。
雑に何度も依頼するより、
- まとめて指示する
- 修正点を整理して渡す
- 1回の精度を上げる
が重要だと感じました。
Codexも万能ではない
複雑な仕様をそのまま投げると、やや荒れるケースもあります。
今回でいうと「手取り計算ロジック」は違和感があったため、
- ChatGPT に仕様書化させる
- 人間がレビューする
- Codexに実装依頼する
という流れにしました。
この AIを分業させる使い方 はかなり有効でした。
試してよかったポイント
複数人格方式はかなりおすすめ
役割が分かれていると、指示がしやすいです。
たとえばPdM役が自然に「受け入れ基準」を作ってくれるので、
- この条件ならOK
- このケースはNG
- この挙動が必要
が明確になり、後工程が進めやすくなりました。
EngineerとReviewerを分けると品質が上がる
これはかなり実感があります。
同じAIでも、
- 作る役
- ダメ出しする役
を分けた方が精度が高いです。
品質基準まで相談できる
単純にコードを書くだけでなく、
- 命名規約
- ディレクトリ構成
- テスト観点
- 可読性ルール
なども相談できるのは強いです。
次にチャレンジしたいこと
- 他の生成AIとも比較したい
- GitHub Issue → 実装 → PR作成フローを回したい
- このサイト自体をさらに使いやすくしたい
- iOSアプリ開発にも使えるか試したい
- より複雑な業務アプリでどこまで通用するか試したい
まとめ
今回やってみて感じたのは、
AIは「コード生成ツール」ではなく、開発チームとして扱うと強い
ということでした。
PdM、Designer、Engineer、Reviewer と役割分担させることで、
かなり自然にプロダクト開発の流れが作れます。
もちろんまだ粗さはあります。
ただ、個人開発やPoC、小規模プロダクトではかなり現実的な選択肢になってきたと感じました。
これからAI駆動開発を試したい人は、
まずは小さなアプリを1本、全部AI主体で作ってみる
のがおすすめです。かなり世界観が変わります。