Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
AI駆動開発で崩れていくコードベースを立て直す
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
Kyoko NR
May 25, 2026
Programming
110
0
Share
AI駆動開発で崩れていくコードベースを立て直す
2026/5/24 AI駆動開発 Women's Party! 【Women's Base 1周年記念】
Kyoko NR
May 25, 2026
Other Decks in Programming
See All in Programming
My daily life on Ruby
a_matsuda
3
420
AI時代になぜ書くのか
mutsumix
0
440
関係性から理解する"同一性"の型用語たち
pvcresin
2
280
[BalkanRuby 2026] Drop your app/services!
palkan
3
610
自動レビューエンジンの実装と運用 ~レビューのない世界へ~
kurukuru1999
1
130
RailsTokyo 2026#4: AI様があれば、 Hotwireの弱点は消えるか?
naofumi
3
470
AlarmKitで明後日起きれるアラームアプリを作る
trickart
0
140
【ディップ|26年新卒研修資料】TDD実装演習
dip_tech
PRO
0
280
When benchmarks go bad - what I learned from measuring performance wrong
hollycummins
0
400
エラー処理の温故知新 / history of error handling technic
ryotanakaya
7
1.9k
~ 秘伝のタレ化した『神スプシ』と戦う ~ 関数型パラダイムで壊れない仕組みへ
h0r15h0
1
120
リセットCSSを1行消したらアクセシビリティが向上した話
pvcresin
4
520
Featured
See All Featured
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
34
2.7k
How to build a perfect <img>
jonoalderson
1
5.5k
Making Projects Easy
brettharned
120
6.6k
Ethics towards AI in product and experience design
skipperchong
2
280
Conquering PDFs: document understanding beyond plain text
inesmontani
PRO
4
2.7k
エンジニアに許された特別な時間の終わり
watany
106
240k
Reflections from 52 weeks, 52 projects
jeffersonlam
356
21k
Building a Scalable Design System with Sketch
lauravandoore
463
34k
Leo the Paperboy
mayatellez
7
1.8k
Why Your Marketing Sucks and What You Can Do About It - Sophie Logan
marketingsoph
0
150
Evolving SEO for Evolving Search Engines
ryanjones
0
200
The AI Revolution Will Not Be Monopolized: How open-source beats economies of scale, even for LLMs
inesmontani
PRO
3
3.5k
Transcript
AI 駆動開発で崩れていくコードベースを立て直す 1
自己紹介 X: @kyoko_NR_nr 北川杏子 フロントエンドエンジニア 特技: 韓国語 コロナ禍に暇だったので1日8時間K-POPの Youtubeを見続けたらいつの間にか話せるように なっていた
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
1. 非エンジニアの夫、Webアプリを作る ある日、非エンジニアの夫がAIでWebアプリを作っていた ちゃんと動いている。すごい…! せっかくなのでちゃんと作るため、本格的に手伝うことに やってみると問題が続出した。それらに四苦八苦して対応した記録 17
2. 動くけど 18
問題 動いているように見えるけど、実際に中を見てみるとなかなかのカオス 不要なライブラリが大量に依存関係に含まれていた 同じような機能のライブラリが重複していた 逆に必要な機能は仮実装のまま バックエンドが必要なアプリだったが、データベースなどは作られてない 19
対応 不要なライブラリを削除 READMEの整備 使われていないコードを削除 リンター・フォーマッターを導入 AI用のドキュメント整備(Rules) ディレクトリ構成の整備(フィーチャーベース構成) 技術選定 ベースがごちゃついてるとAIもごちゃついたコードを出力しがちなので、整理して最 低限の構成に
まずは最低限の環境構築 20
3. PRが見切れない 最低限の整備ができたので 1. 夫がバイブコーディングする 2. 自分がPRレビューをする。修正は自分でやってマージ というサイクルにしようと思ったが… 21
問題 PRの差分が大きすぎて読みきれない 1日に5件以上のPRが作成される せっかくPRレビューで修正した機能が、やっぱいらなくなった / 全然別の機能に したくなった、が多発 → 夫婦ケンカ勃発 22
対応 リポジトリを分けた PoC用リポジトリ: レビューはしない。とにかく作って壊してを繰り返す 開発用リポジトリ: PoCをAIに読ませて、ページ単位/機能単位で移植していく とりあえず作るものと ちゃんと作るものを分ける 23
4. 要件確認とリファクタ PoC用リポジトリを分けたので、これでコードの治安は守られる…と思ったが 24
問題 PoCは一見それっぽく見えるけど、よくよく考えると機能が足りてなかったりする 例)画像の登録機能はあるけど削除機能がない。ログイン機能はあるけどロ グアウトはない PoCをただ移植するだけでは保守性/可読性/セキュリティの面でよくない 例)1ファイル1000行のコード、フロントエンドから直でDB操作 25
対応 要件は都度確認 ドキュメントを起こす時間はないので、OpenSpecで仕様を同時にmdファイ ルにしていく ※OpenSpec = 仕様駆動開発用のライブラリ リファクタリング 大きすぎるコンポーネントは、まずAIにテストを書かせる 分割してテストを実行
= OKなら壊れてない、と判断 AIに任せず、理解するためにも手で実装する時間を設けた 26
5. プロジェクト用のルール・スキルは都度ブラッシュアップ 何とか開発サイクルは回るようになった。ただ、 27
問題 AIに何度も同じ指示をする どうしても既存のコードのスタイルに引きずられてしまう 28
対応 ルールの追加 何度も行う指示はAI用のルールにどんどん追加していく リントルールで強制 機械的にチェックできそうなことは、AIにオリジナルのリントルールを書か せて強制する プロジェクト用のスキルを作る 例)リファクタリング専用スキル AIのプランと手で実装したところの差分を読ませ、リファクタの時に何 を大切にしているか・どんな思想かを言語化しスキル化
フローを固定化 実装の前にまずリファクタリングプランを必ず出すフローにする あとが楽になる 29
まとめ AI駆動開発でも、整備しなければコードベースはどんどん崩れていく 問題が起きたら「仕組み」で解決することを心がける 非エンジニアがAIを使って動くものを作れるのは素直にすごい だからこそ、最後は自分自身の知識・判断が必要 30