AI に Rails の仕様を洗い出させて品質向上を目指す Script Jam vol.5

Transcript

1. AI に Rails の仕様を洗い出させて 品質向上を目指す 下條 拓未 2026.07.24 Script Jam vol.5
2. 下條 拓未 Gaji-Labo Inc. ／ フロントエンドエンジニア 専門 フロントエンド／Next.js、React Router v7 最近 ・息子とおかあさんといっしょを見ています ・5弦ベースを練習中です @takumi_bv
3. プロダクトの課題を一緒に解決します。 最適な技術と、適切な手段で。 お仕事のご依頼・ご相談 サービス案内ページ https://www.gaji.jp/services 採用に関するお問い合わせ 採用情報ページ https://www.gaji.jp/recruit
4. 今日話すこと 1. 開発フローに AI を組み込んだ話 2. その中で得た学び
5. プロジェクト概要 モノリス構成からのリアーキテクチャ モノリシックな Rails Rails API + React Router v7 基本方針は「現行踏襲」
6. 進め方 移行画面の決定から受け入れテストまでの工程 対象画面決定 仕様洗い出し Issue 化 UI 実装 ロジック実装 API 繋ぎ込み API 設計 （OpenAPIスキーマ定義） 受け入れテスト
7. 移行時に実際に起きたバグ とある画面の退会判定（退会しているかどうかのロジック） コードだけ見ると、 // 誤：withdrewAt の有無で判定した 一見正しそうに見える。 if (user.withdrewAt) { … } // 正：status で判定する if (user.status === "withdrew") { … } 退会から復帰したユーザーが 退会扱いになってしまった レビューでも見落としてしまっていた...
8. なぜ気づけなかったか OpenAPI スキーマと旧画面を見ながら進めていたため、 Rails のコードの中にだけあるロジックを拾いきれていなかった 設計時に、 レビュー時に、 状態遷移やロジックを 現行 Rails ↔ 新実装の 網羅的に洗い出せていなかった 差分をチェックできていなかった QA時に、 エッジケース（退会→復帰）の テスト観点を洗い出しきれて いなかった
9. AI でこれらの穴を塞げないか? AI で AI で AI で 状態遷移やロジックを 現行 Rails ↔ 新実装の エッジケースの 網羅的に洗い出す 差分をチェックする テスト観点を洗い出す
10. AI によるチェックを工程に組み込んだ 仕様洗い出し Issue 化 API 設計 UI 実装 ロジック実装 API 繋ぎ込み AI が Rails コードを横断調査し、 現行 Rails コードと新実装を比較し、 仕様書を生成する ロジック差分がないかチェック MUST (実バグ) / IMO(要判断)で指摘 ・Claude Code のスキルを作成 > /review-by-rails-spec > /rails-explorer マイページの仕様を洗い出して ・単純な変換では済まない箇所、 方針を決めるべき点も含めて洗い出す ・生成した仕様書は、以降の工程で 共通言語となる 生成した仕様書から、 テスト観点を網羅的に洗い出し 受け入れテスト
11. どれだけ検知できたか 比較レビューを回した結果 突き合わせた項目数 検知したバグ 判断が必要な差分 137 3 11 ・退会判定のロジック差分 ・API エラーがユーザーに通知されなかった ・検索ヒット数 51件以上のときに「検索結果がありません」と誤表示していた （正しくは「検索結果が多数あります。検索条件を変えてください」）
12. ミスを減らす・漏れを減らす 仕組みはできた ✓ 仕様洗い出し ✓ Issue 化 API 設計 UI 実装 ロジック実装 ✓ API 繋ぎ込み …が、AI アウトプットの正しさは誰が保証する？ 受け入れテスト
13. 「これで問題ない」と判断し、 リリース判断をするのは人間。
14. 「これで問題ない」と判断するために やっていること 1. レールを敷く 2. コンテキストの外側で決める 3. 最後は責任を持つ
15. 1. レールを敷く どの工程で、何を渡して、何を出力させるかを決める いわゆる ワークフロー設計、コンテキストエンジニアリング 仕様洗い出し レビュー 受け入れテスト 渡すもの 渡すもの 仕様書 ＋ 現行コード ＋ 新実装 + スキル 渡すもの Railsコード ＋ スキル アウトプット アウトプット アウトプット 仕様書 指摘事項 観点リストとチェック結果 仕様書 アウトプットの結果から、 工程・渡すもの・出力させるものを更新するサイクルを回す
16. 2. コンテキストの外側で決める レールの外側の課題はちゃんと人間が結論を出す 基本方針は「現行踏襲」でも、実際に「変える・変えない・落とす」部分を決める場面は多かった。 ・データ取得のタイミング : React Routerの設計を活かす方が体験が良いと判断し変えた。 ・URL設計 : 画面特性・無限スクロール等の操作性を考慮し、ReactRouterの定石をあえて退けて変えなかった。 ・ほとんど使われていない機能 : 利用実態を考慮して落とした。 プロダクトやユーザーにとって何がいいかを判断基準とする そのためにはドメイン知識 を持つことは大事
17. 3. 最後は責任を持つ オーナーシップ・誠実さを持つ なぁなぁで仕事をしない ・自分の出した PR の説明責任は果たせるようにする ・自分の出した PR からバグを生ませない、という心持ちを持つ 自分の手で確かめる ドッグフーディング的に使ってみて、違和感がないかを確認する 意思決定を推進する 強い意志を持って結論を出し、前に進める
18. まとめ AI に任せる範囲を広げてみて、 「これで問題ない」と判断するために大切だと感じたこと 1. レールを敷く どの工程で、何を渡して、何を出力させるかを決め、継続的に改善をする 2. コンテキストの外側で決める レールの外側の課題はちゃんと人間が結論を出す 3. 最後は責任を持つ オーナーシップ・誠実さを持つ