Railsフロントエンド移行効率化 ためAエージェント利用方法

Transcript

1. © Tsukulink Inc. Railsのフロントエンド移行の効率化
 のためのAIエージェントの利用方法

2. 自己紹介 
 なまへ：にしむらてつ
 趣味：スノーボード、クライミング、スキューバダイビング
 すんでるとこ：長野県
 おしごと：Webエンジニア（ツクリンクでは非機能面の改善を担当）
 好きな言語・技術：Rust, TypeScript, TCP/IP(Routing, Swiching, QoS)

3. プロジェクト環境 
 • Ruby on Rails（以降Rails）のフロントエンド環境(ERB, JavaScript)をReactRouter v7 へ移行するプロジェクト
 • 社内ナレッジは少なめ（React, TypeScriptは）
 • AIエージェントは会社で導入済み（Cursor, ClaudeCode）
 ◦ Cursorの設定でClaudeCodeのドキュメントを参照して共有している 
 • メンバーは社内ひとり＋協力会社２人
 • スクラム開発
 • チケット管理はJIRA

4. 目指すゴール 
 Railsのフロントエンド環境をReactRouter v7に移行する
 • 短期目標：１機能単位をフロントエンドに移行しつつ安定した開発体制を作る
 • 長期目標：フロントエンド開発のナレッジをチームに共有し協力会社の手を借りない 開発体制を作る

5. 課題
 • 社内はRailsエンジニアがメインでReactRouterに関するナレッジは少ない
 • 社内エンジニアの開発に割けるリソースは少なめ（他の機能開発でも忙しい）
 • フロントエンド開発のオンボーディングに割ける時間も少なめ
 ◦ 他の機能開発も進める必要があるため 

6. 課題解決のための方針 
 • 社内への技術共有について、ゼロイチで伝えることをやめる
 ◦ メンバーのスキルレベルは高めなのでREADME読んで環境構築して動くコードは書ける 
 ◦ コアに必要なのはデザインパターンまわりの知見共有のみ 
 • 理解しながら進められる開発環境をAIエージェントで支援
 ◦ AIの力を借りて「ある程度知らなくても書ける環境をつくる」方向へ 
 ◦ 同時にAIに振り回されない防止策も大切 

7. こんなことしました

8. チケットの品質 
 - AIがJIRA MCPを使ってチケット情報を読み込む前提で開発
 - 最低限チケットに記載する項目をきめておく
 - 背景と説明
 - やること
 - 受け入れ条件
 - 入力項目を多くしすぎても細かすぎるとチケット起票のコストが高くなってしまう
 - 詳細はリファイメント・スプリントプランニングで補足
 - AIエージェントにはJIRA MCPでチケット情報を理解させる

9. AIに設計方針を覚えてもらう 
 CLAUDE.md 
 プロジェクトの概要・全体方針を記載するファイル
 ◦ プロジェクトの全体アーキテクチャや採用したデザインパターン 
 ◦ 開発者やレビュー担当者全員に共通して参照してほしい内容 
 ◦ 開発で使用するコマンド 
 
 .claude/rules 
 詳細ルールや状況に応じた判断基準
 ◦ 実装例、禁止事項、特定のケースでの対応ガイドライン 
 ◦ コーディング規約、API設計方針 
 ◦ 参考ドキュメントなど 

10. AIに開発手法も覚えてもらう 
 .claude/commands
 「どう進めればよいか」「どのタイミングでどんな品質基準を満たすべきか」
 など開発工程を標準化・可視化・自動化する
 • コーディング：TDDで進めることをルール付け・テスト品質も確認しながらコーディン グする
 • テスト：単体・E2Eテスト実行とカバレッジの確認・テスト失敗したら原因の調査まで 実施
 • コミット：コミットメッセージ自動生成

11. AIに実装の背景を伝える 
 ADR（Architecture Decision Record）を残す
 • 新しく設計方針を追加したとき、「なぜ今のような設計になったか」の背景を記載
 • タイムスタンプ情報も含める
 ◦ 同じ設計観点に関して矛盾した記載があっても時系列上最新の情報を採用できる 
 

12. 現在観察できた成果 
 • ドキュメントである程度品質は担保できた
 • 細かい設計方針はベストから外れることがあった（レビューで確認）
 • 最初はファイル単位でやり直しとかが発生していた
 ◦ ReactRouterのライフサイクルの理解不足 
 ◦ 根本的な誤りについては都度CLAUDE.mdを更新して情報を充実させていく 
 • 実装を積んでいけば実装済みのコードを参考にコーディングしてくれるので精度は 上がっていっている

13. 所感：工夫の成果 
 • AI任せでデザインパターンに明るくなくてもコーディングは十分可能
 • レビュー指摘事項・バグ減少などで品質上がってきて効果は実感している
 • ドキュメントの重要性はとても上がった
 ◦ AI以前はNotionなどにまとめて人間が最新性を担保 
 ▪ 更新わすれなどは頻繁に発生⇒古い情報形骸化はよくあることだった 
 ◦ AI以後はドキュメントの最新性の担保もある程度可能 
 • 情報をさがすときも人間が探すよりAIに探させる前提なので、ディレクトリ設計は甘 めでOK

14. 所感：自分の動きで変わった部分・変わらない部分 
 • 開発に関する知見の習得方法は変わってきた
 ◦ AIの成果物を出発点に人間が学習できる 
 ▪ コードの意味をキーワードとともにAIに質問 
 ▪ キーワードをネットや書籍で学習 
 • ドキュメントに残してもキャッチアップを継続すべき部分
 ◦ フレームワークの知識 
 ◦ ソフトウェア開発の設計に関する知見 
 ◦ AIに質問した回答のハルシネーションを見つける力に繋がる 
 • そもそものフレームワークのライフサイクル理解は必要
 ◦ 理解できていないとレビューができない 
 • レビューができないと協力会社から卒業できない
 ◦ そもそもの目的達成不可能 
 

15. ありがとうございました