AI開発の実験レポート：プロダクトを繰り返し再構築して観察する設計判断の変化（第2ラウンド進行中）
AI支援ツールが普及し、開発プロセスの前提が大きく変わりつつある。 そこで、「AIと協働して開発を繰り返した場合、設計判断力はどのように変化するのか」を検証するため、 個人的な実験を始めた。
同じプロダクトを3回再構築することを目標に、現在は2回目の開発を実施中。 初回は構造が崩壊して学びが多かったが、2回目では仕様駆動・テスト駆動の手法を導入して改善を試みている。
この記事では、初回の結果と2回目の途中経過から見えた知見をまとめる。
目的は、AIとのやり取りを通じて設計判断力がどのように鍛えられるかを観察すること。 特に、初回の「泥団子」的なモノリス構成が、反復を通してどのように整理・洗練されていくかに注目した。 また、開発環境として Cursor を使用し、AI支援ツールがどのように開発体験を変えるのかも併せて検証した。
下記は作成したECサイト（権利の関係もありビジュアルは未記載）、ユーザー登録、認証、商品一覧、商品詳細、購入（決済は未実装）等の一連の機能を業務と並行しつつ、１行もコードを書かずに10時間程度で構築
実験の進め方（1回目）
最初のプロダクトは典型的なECサイトを題材に、機能設計や要件定義を行わず、VibeCoding的に進めた。 Cursor（Claude4.5、Codex-5）、MCP（GitHub、GitLab、Playwright）を使用し、自分では一行もコードを書かない。 AIに逐次指示を与えながら開発を進めた。
当初はスムーズで、短時間でUIを構築できた。ガイドラインのリンクを渡すことで Apple 風や Google 風のデザインへ柔軟に切り替えることも可能だった。 しかし、3時間ほどでアーキテクチャの方向転換が必要になり、その際にコード間の矛盾が発生。 その後、機能追加を続けるうちに既存機能が動かなくなる現象が頻発した。
5時間経過時点で機能追加で別の機能が壊れる事象が発生。単体・結合・E2Eテストを網羅的に作成させて実施したが、AIがテストの通過を優先した結果、コード全体の整合性が崩れた。 報告上「全テスト成功」とされても、実際には動作しないケースもあった。 10時間を過ぎると、矛盾の修正に要する時間が実装時間を上回ったため、この段階で開発を停止し、ポストモーテムを実施した。
内部構造は典型的な「泥団子」状態だった。 フロントエンドが直接URLを叩く実装になっており、DBには Prisma ORM を採用したものの、キャッシュ設計の不足により不具合が発生した。
得られた知見
まず、生成AIを組み込んだ開発環境によって「壊して学ぶコスト」が大幅に低下した。 短期間でプロダクトを作り、壊し、再構築することが容易になったことでそこから学ぶコストが劇的に下がった。これは頭で思っていた以上に感動する体験だった。 雑でも一度完成させてみることで、要件の抜け漏れや本質的な課題が見えてくる。思っても見なかった箇所に複雑さを発見したり、思いもよらないリスクがあったり、思ったよりも簡単に実装できてしまったり、不可逆性の意思決定を発見できたりと、大量の気づきを得られた。
設計判断についても、多くの学びが得られた。 特に、アーキテクチャやDB設計のような不可逆な部分では、方針変更時の手戻りが約30%発生した。 ADR（Architecture Decision Record）を残せばいいが、どうしたら良いのか、、、と悩んでいたが、結果的にはAIに疑問点をぶつけてその対話結果をまとめてもらうことでADRとしては十分だということもわかった。
また、AIと協働する場合、最初にテストケースを定義しておく重要性が高い。 開発の初期段階で受け入れ条件をマークダウン等で外部出力した文書で明示することで、AIの出力品質が安定しやすくなる。 逆に、口頭指示で、要件やテストが曖昧なままだと、人間・AIの双方で目的がぶれ、整合性の取れないコードが生まれる。
面白い副次的な気づきとして、AIの“挙動の人間らしさ”も挙げられる。 「できました」と返してきた結果が動作せず、修正を指示すると「あ、実はやっていませんでした」と回答するなど、人間的なやり取りが発生した。 エージェントによっても傾向に差があり、Claudeは柔和で文脈重視、Codexは忠実で安定的という特徴が見られた。
あとは、AquaVoiceという音声入力アプリを利用したので、AIと対話するように進められたのが想像以上に良い体験だった。
改善フェーズ（2回目）
2回目の開発では、初回のポストモーテムの結果をインプットにしている。そして、Spec Kit を用いた仕様駆動開発に切り替えている。 初回のコードベースから機能一覧を整理して受け入れ条件を整理した上で、3層レイヤーアーキテクチャを採用。 インフラはコンテナベースに変更し、テスト駆動開発（TDD、BDD）で進めている。
バックログには BDD による受け入れ条件を明記しGithubでIssueとして管理、AIと協働しながら実装を進めた。 Issue ごとにブランチを切り、Pull Request 単位でレビューとマージを行う運用が確立。 ポストモーテムで抽出した改善点を反映したことで、開発全体の安定性が向上していると感じている。2025/11/05の1500時点では15時間以上開発を続けているが、手戻りも発生していないし、機能追加もスムースだ。
所感
AIとの開発を通して感じたのは、設計や意思決定における「答え合わせの速度」が極端に速くなっているということだ。 自身が新人のころ、数年に一度のシステム改修に関与する機会があり、 半年かけてアーキテクチャの設計や意思決定をそばで見る体験をしたことがあるが、今では類似の体験を数時間で実施できる。 経験の密度が飛躍的に高まり、設計判断力の成長速度も上がっている。
「AIがあるからジュニアエンジニアはいらない」という議論もあるが、実際には逆だと感じる。 AIをうまく使えば、経験を圧縮して学ぶ機会を増やすことができる。 主体的に設計に取り組み、試行錯誤の過程をAIと共有することで、エンジニアとしての地力を短期間で鍛えることが可能になると感じた。
