こちらは ミライトデザイン Advent Calendar 2025 の24日目の記事となっています。
23日目は ucan-lab さんの 「Laravelのバージョンアップした話」の予定です。
※現時点でまだ未公開のため、公開後にリンクを変更予定です。
はじめに
ここ最近1年ほどでAIの進歩がめざましく、仕事で利用することが多くなってきました。
2025年にAIを仕事で使ってみた所感等をまとめます。
前提となる自分の状況
- 使用言語：Ruby（今回のプロジェクトで初めて本格的に触ったレベル）
- フレームワーク：Rails（Rails 4 / レガシー）
- 役割：バックエンドの保守・開発（既存改修・バグ修正・軽い機能追加など）
- AIの使い方：
- バイブコーディング的な丸投げはしない
- 既存コード解析・コードアシストがメイン
- RubyMineのプラグインで GitHub Copilot 経由のモデルを Agent Mode で利用
- 開発以外の一般質問：Claude と ChatGPT を用途で使い分け
- センシティブ（コード等）は会社管理のアカウント（Copilot / ChatGPT Enterprise）
- 一般論は個人のアカウント（Claude / ChatGPT）
簡単な所感まとめ
詳細な内容を語る前に簡単に所感をまとめると下記のようになります。
- Rails4の保守には「書く」より 既存コード理解 / 影響範囲整理 / 安全な修正でのAI使用が便利
- concerns（ActiveSupport::Concern） 等の提案で、Railsらしい整理の型を拾えた（Ruby初心者には助かる）
- GitHub上のAIレビューは便利だが、ローカルで直したらPRで逆方向の指摘が来るなど、ブレもある
- ブレを抑えるには、“正”をAIではなくテスト・リンタ・チーム規約に置く運用が重要
Rails4（レガシー）ならではの話：AIが効く/効きにくい
AIは現行の一般論で答えることがあり、 実際のプロジェクトの状態にそぐわない内容となることもありますが、実際に使ってみると下記のような印象を受けました。
効きやすい
- 既存コードの要約（責務、依存、処理の流れ）
- 変更影響範囲の候補出し（どこが壊れそうか、どのテストを見に行くか）
- バグ調査の“当たり”付け（ログ/例外 → 原因候補 → 確認手順）
- PR説明文の補助（背景・意図・変更点・確認方法）
- テストデータの作成（Railsコンソール用のスクリプト / DBへのINSERT文等）
効きにくい／注意が必要
- Rails4固有の癖や、古いGem/当時の慣習（AIが現行Rails前提の回答をする等）
- “プロジェクト内の暗黙ルール”（命名、例外方針、nil許容、DB制約、トランザクション境界など）
実際に発生した具体例紹介
具体例1： concerns提案がAIから出た
状況
- あるロジックが Model/Controller に散らばり、同じような処理が複数箇所に存在
- Ruby経験が浅く、Rails流の整理手段がすぐ思いつかなかった
AIの提案
-
ActiveSupport::Concern を使った concerns化
- 責務を切り出して、複数箇所で再利用しやすくする
採用前にチェックしたこと
- 依存の向き：Concernが他の層を握っていないか
- 影響範囲：include箇所、既存メソッドの衝突、Callbackの影響
- テスト：最低限の回帰テストを追加/修正できるか
- 命名：業務用語に寄りすぎないか／責務が広すぎないか
効果
- 「どこに何があるか」が分かりやすくなった
- レビューで説明しやすくなった（PRの意図が伝わる）
具体例2： ローカルとPR（GitHub Copilot）で指摘が逆転
起きたこと
- ローカルではRubyMine上のCopilot（Agent Mode）に従って修正してPRを出した
- GitHub上のAIレビューで 逆方向の修正 を指摘された
起きがちな原因
- AIが見ているコンテキストが違う（ワークスペース全体 vs PR差分中心）
- 判断基準（規約・優先順位）が曖昧だと「別解」を正しいと判断することがある
- プロジェクト固有の流儀がAIに伝わっていない
再発防止の運用
- “正”はAIではなく「テスト / リンタ（RuboCop等）/ チーム規約」に置く
- AIには「前提（規約/方針）を列挙してから」提案させる
- 逆方向の指摘が来たら「前提が何か」を特定する（例外方針？パフォーマンス？可読性？）
- PR上のAI指摘は“理由と根拠”を追加で質問し、納得できないなら採用しない
- 最後に人間レビューで「プロジェクトの流儀」に照らして判断する
さいごに
Rails4のようなレガシー保守では、AIは「速く書く」よりも「速く理解する」「安全に直す」「抜け漏れを減らす」という方向で使うのが良いように感じました。
一方でAIレビューはブレることもあるので、“正”をテスト/リンタ/規約に置いた運用設計が重要です。
実用的なAIの登場と進歩により、ソフトウェア開発を含む仕事の進め方にも変革の波が来ているように感じます。
この記事もAIを使って概要作成や推敲等を行っています。
実例や自分の感想を色々と書いてみましたが、何かの参考になればと思います。
明日は hirodragon さんの『2025 AI道中膝栗毛』です。