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

下條 拓未 Gaji-Labo Inc. ／ フロントエンドエンジニア 専門 フロントエンド／Next.js、React Router v7 最近 ・息子とおかあさんといっしょを見ています ・5弦ベースを練習中です @takumi_bv 

プロダクトの課題を一緒に解決します。 最適な技術と、適切な手段で。 お仕事のご依頼・ご相談 サービス案内ページ https://www.gaji.jp/services 採用に関するお問い合わせ 採用情報ページ https://www.gaji.jp/recruit 

今日話すこと 1. 開発フローに AI を組み込んだ話 2. その中で得た学び 

プロジェクト概要 モノリス構成からのリアーキテクチャ モノリシックな Rails Rails API + React Router v7 基本方針は「現行踏襲」 

進め方 移行画面の決定から受け入れテストまでの工程 対象画面決定 仕様洗い出し Issue 化 UI 実装 ロジック実装 API 繋ぎ込み API 設計 （OpenAPIスキーマ定義） 受け入れテスト 

移行時に実際に起きたバグ とある画面の退会判定（退会しているかどうかのロジック） コードだけ見ると、 // 誤：withdrewAt の有無で判定した 一見正しそうに見える。 if (user.withdrewAt) { … } // 正：status で判定する if (user.status === "withdrew") { … } 退会から復帰したユーザーが 退会扱いになってしまった レビューでも見落としてしまっていた... 

なぜ気づけなかったか OpenAPI スキーマと旧画面を見ながら進めていたため、 Rails のコードの中にだけあるロジックを拾いきれていなかった 設計時に、 レビュー時に、 状態遷移やロジックを 現行 Rails ↔ 新実装の 網羅的に洗い出せていなかった 差分をチェックできていなかった QA時に、 エッジケース（退会→復帰）の テスト観点を洗い出しきれて いなかった 

AI でこれらの穴を塞げないか? AI で AI で AI で 状態遷移やロジックを 現行 Rails ↔ 新実装の エッジケースの 網羅的に洗い出す 差分をチェックする テスト観点を洗い出す 

AI によるチェックを工程に組み込んだ 仕様洗い出し Issue 化 API 設計 UI 実装 ロジック実装 API 繋ぎ込み AI が Rails コードを横断調査し、 現行 Rails コードと新実装を比較し、 仕様書を生成する ロジック差分がないかチェック MUST (実バグ) / IMO(要判断)で指摘 ・Claude Code のスキルを作成 > /review-by-rails-spec > /rails-explorer マイページの仕様を洗い出して ・単純な変換では済まない箇所、 方針を決めるべき点も含めて洗い出す ・生成した仕様書は、以降の工程で 共通言語となる 生成した仕様書から、 テスト観点を網羅的に洗い出し 受け入れテスト 

どれだけ検知できたか 比較レビューを回した結果 突き合わせた項目数 検知したバグ 判断が必要な差分 137 3 11 ・退会判定のロジック差分 ・API エラーがユーザーに通知されなかった ・検索ヒット数 51件以上のときに「検索結果がありません」と誤表示していた （正しくは「検索結果が多数あります。検索条件を変えてください」） 

ミスを減らす・漏れを減らす 仕組みはできた ✓ 仕様洗い出し ✓ Issue 化 API 設計 UI 実装 ロジック実装 ✓ API 繋ぎ込み …が、AI アウトプットの正しさは誰が保証する？ 受け入れテスト 

「これで問題ない」と判断し、 リリース判断をするのは人間。 

「これで問題ない」と判断するために やっていること 1. レールを敷く 2. コンテキストの外側で決める 3. 最後は責任を持つ 

1. レールを敷く どの工程で、何を渡して、何を出力させるかを決める いわゆる ワークフロー設計、コンテキストエンジニアリング 仕様洗い出し レビュー 受け入れテスト 渡すもの 渡すもの 仕様書 ＋ 現行コード ＋ 新実装 + スキル 渡すもの Railsコード ＋ スキル アウトプット アウトプット アウトプット 仕様書 指摘事項 観点リストとチェック結果 仕様書 アウトプットの結果から、 工程・渡すもの・出力させるものを更新するサイクルを回す 

2. コンテキストの外側で決める レールの外側の課題はちゃんと人間が結論を出す 基本方針は「現行踏襲」でも、実際に「変える・変えない・落とす」部分を決める場面は多かった。 ・データ取得のタイミング : React Routerの設計を活かす方が体験が良いと判断し変えた。 ・URL設計 : 画面特性・無限スクロール等の操作性を考慮し、ReactRouterの定石をあえて退けて変えなかった。 ・ほとんど使われていない機能 : 利用実態を考慮して落とした。 プロダクトやユーザーにとって何がいいかを判断基準とする そのためにはドメイン知識 を持つことは大事 

3. 最後は責任を持つ オーナーシップ・誠実さを持つ なぁなぁで仕事をしない ・自分の出した PR の説明責任は果たせるようにする ・自分の出した PR からバグを生ませない、という心持ちを持つ 自分の手で確かめる ドッグフーディング的に使ってみて、違和感がないかを確認する 意思決定を推進する 強い意志を持って結論を出し、前に進める 

まとめ AI に任せる範囲を広げてみて、 「これで問題ない」と判断するために大切だと感じたこと 1. レールを敷く どの工程で、何を渡して、何を出力させるかを決め、継続的に改善をする 2. コンテキストの外側で決める レールの外側の課題はちゃんと人間が結論を出す 3. 最後は責任を持つ オーナーシップ・誠実さを持つ