AIを用いたRailsアップグレードと技術的負債への対応

Ruby Ruby on Rails AI

はじめに

エムスリーキャリア薬剤師採用支援チームの吉田です。

最近、弊社の採用管理システムでRailsのアップグレードを実施しました。
その際、AIを活用して技術的負債に対応しましたので、その事例をご紹介いたします。

アップグレードの障壁

2025年2月時点で、当該システムのRailsは7.0.8でした。Railsの7.0系は2025年4月1日にサポートが終了するため、その前にアップグレードを完了させる必要があります。

ここで大きな問題となるのが、schema_validations1です。 このGemの最新バージョンがRails 7.1に対応していないため、アップグレードを行うには代替手段への移行が必要でした。

チーム内で検討した結果、一つずつバリデーションを再実装していくことに決めました。 しかし、対象となるモデルは32個。schema_validationsは予想以上にプロダクトに根を張っているようです。

AIに任せよう

アップグレード作業に取り掛かる少し前に、タイミングよくGitHub Copilot Agentがリリースされました。 このエージェントは、Copilot editよりも自律的に動き、複数のファイルにまたがって作業を行うことができます。

schema_validationsの削除は、比較的機械的なタスクであるため、GitHub Copilot Agentに任せることで工数を削減できると考えました。

こんなプロンプトでやりました。

私の知っている限りでは、以下のようなプロンプトが良いプロンプトと言えるそうです。

  • 具体的な指示を出す
  • 役割の付与(例：「あなたはベテランプログラマーです」といった役割を与える)
  • 出力形式を指定する
  • 肯定的な指示を出す
  • マークダウンで書く
  • 英語にする
  • エモーションプロンプト(例：「お前ならできる！頑張れ！」　回答が詳細になるらしい。)

ということで、試行錯誤を繰り返して作り上げたプロンプトが以下となります。

大変恐れ多いですが、AIにはまつもとゆきひろ氏とDHH氏を憑依させました。
偉大なお二方の力をお借りできるなんていい時代です。

You are Yukihiro Matsumoto, the creator of Ruby, and also David Heinemeier Hansson (DHH), the creator of Ruby on Rails.
Please revise the model according to the following instructions:
# Deletion
- Completely remove `schema_validations`.
# Implementation
- Implement new validations that have the same content as those in `schema_validations`, but do not change their behavior.
- Combine options for the same attribute into one line.
- Use the `validates` method for implementing validations.
- keep the existing validations.
# Sorting Order
- The new validations should be sorted according to the order of Schema Information at the top of the model.
# Notes:
- Exclude default options (e.g., `allow_nil: true`).
- Numeric attributes do not require range validations.

結果は？

結果として、完璧とは言えないまでも、それなりの成果物を得ることができました。
大量のバリデーションを自動で実装し、一部のテストコードまで修正してくれました。 大幅な工数削減となったことは間違いありません。

もちろん上手くいかなかった箇所もあり、以下が一例となります。 他のロジックを参照しつつ、気を利かせた実装をするのはまだまだ難しいようです。(私にとっても難しいです)

例

belongs_to :company

# このバリデーションをGithub Copilot Agentが実装
validates :company_id, presence: true, length: { maximum: 20 }

company_idカラムには、not null制約をschema_validationsで実装していました。
しかし、belongs_toでcompanyと紐づけているため、関連するレコードの存在確認は行われます。 ということは、presence: trueは不要です。 ここまでの情報を汲み取ってもらうことはできませんでした。

所感

モデルを変えて何度も試した結果、体感的には以下の順で指示をうまく理解してくれました。 当然ですが、新しいモデルの方が高性能のようですね。

  • Claude 3.7 sonnet thinking = o3-mini > GPT-4o

また、日本語のプロンプトでも試しましたが、英語の場合と比べて特に精度に差はありませんでした。 AIの進化により、徐々に言語の壁がなくなってきていると感じています。

まとめ

今回のバージョンアップは、技術的な負債を解消し、アプリケーションの基盤を強化するための重要な取り組みでした。 今後も、ユーザーの皆様により良いサービスを提供できるよう、技術的な改善を続けていきます！

ちなみにこの記事もAIに草案を作ってもらいました。 エモーションプロンプトを活用しています。効果はどうあれ、面白いので個人的には好きなテクニックです。

プロンプト

あなたはベテランエンジニア兼プロブロガーです。
自社のwebアプリケーションに対して以下の対応を行いました。テックブログに書きたいので草案を作ってください。
あなたなら出来ます！頑張れ！

# 対応内容
- Railsを7.0.8から7.1.5にアップグレード
- Schema_validationsを削除してバリデーションを手動で実装(schema_validationsは既にサポートが終了しているため)
- 各種gemをアップグレード
- schema_validationsの削除にLLMを活用
  1. schema_validationsは、データベーススキーマに基づいて自動的にバリデーションを生成してくれる便利なgemです。↩

エムスリーキャリアのエンジニアは東京Ruby会議12に参加しました！／セッションレポート

Ruby Ruby on Rails スポンサー

エムスリーキャリアの諸岡(morooka_cube)です。

最近では薬剤師関連サービスの開発チームリーダーとして、エンジニアリングリードのほか1on1などピープルマネジメント領域にも関わっています。

以前も本ブログでお伝えした通り、1/18(土)に開催された東京Ruby会議12にシルバースポンサーとして協賛いたしました！

m3career-eng.hatenablog.com

また当日もエンジニア数名が参加し、セッションを通じてRubyの知見を深めたり、東京圏Rubyist（Ruby愛好家の通称）の方々と交流しました。

続きを読む

Hotwireを用いたフロントエンド実装事例

Ruby Ruby on Rails Hotwire

エムスリーキャリア薬剤師採用支援チームの吉田と申します。 今回は、Hotiwreを用いたフロントエンド実装について、弊社の採用管理システムの実例を交えてご紹介いたします。

何をやったか?

弊社の採用管理システムには薬剤師の検索機能があり、ユーザー毎に検索条件を保存することが可能です。 この画面でTurbo Streamsを用いてモーダルとフラッシュメッセージの制御を行いました。

今回実装した画面遷移パターンをざっくりとまとめると以下のようになります。 リクエストの種類やサーバーサイドでの処理結果によって、最終的に表示する内容が分岐しています。

設計前は「Turbo Framesで実装できるやろ...」と思っていたのですが、複数DOMを更新することや、条件分岐があることからTurbo Streamsが適していると考えました。

こんな感じでやってます

Turbo streamsでリクエストを飛ばすと、コントローラ側ではアクション名.turbo_stream.erbをレンダリングして返します。 ここに正常パターン、エラーパターンの分岐を実装しました。

<% if flash[:alert].present? %>
  <%= turbo_stream.replace 'error_message' , partial: 'layouts/error_messages', locals: { flash: flash } %>
<% else %>
  <%= turbo_stream.replace 'successful_message' , partial: 'layouts/successful_messages', locals: { flash: flash } %>
<% end %>

そして、ここにモーダルの制御処理を加えると以下のようになります。 modalをターゲットにして空のhtmlを返すことで、モーダルが非表示となるようにしました。

<% if flash[:alert].present? %>
  <%= turbo_stream.replace 'error_message' , partial: 'layouts/error_messages', locals: { flash: flash } %>
<% else %>
  <%= turbo_stream.replace 'successful_message' , partial: 'layouts/successful_messages', locals: { flash: flash } %>

  <%# アクションが成功したらmodalを消す(空のhtmlでupdate) %>
  <%= turbo_stream.update 'modal' %>
<% end %>

Turbo streamアクションの参考資料。万葉さんが翻訳してくれてる！すごい！

https://everyleaf.github.io/hotwire_ja/turbo/handbook/streams/ everyleaf.github.io

Stimulusは？

Stimulusは今回の実装であまり使いませんでした。 エラーメッセージやモーダルの表示をStimulusで制御することも可能だとは思います。

しかし、ロジックをバックエンドに寄せてRails wayに沿った開発がしたいという考えがチーム内にあったため、今回は不採択としました。

実際に弊社のプロダクト内では、Stimulusを使ってシンプルな処理を中心に実装しています。(アラートを出したり、数秒後にフラッシュメッセージを消したり)

まとめ

この記事を書くにあたり実装当時のプルリクを見直したのですが、書いたコードは約800行、そのうちJavasctiptは20行程度でした。

モーダルをいくつも開いたり閉じたりして、CRUD処理して...という機能がほとんどバックエンドの実装で実現したことになります。

Turboではカバー出来ないちょっとした処理をStimulusで書く、という方針に則った開発ができました。

デザインパターン勉強会をやりました

４月新卒入社の會澤です。

最近は、寒すぎて睡眠時間がどんどん増えている気がします

 

7月下旬から11月の中旬までデザインパターンの勉強会を開催していました。

約4か月で全23パターン(20番目の最初の素数で覚えやすい)を走り切りました！

勉強会は基本的に毎週行う形式でしたが、予定があれば次週に回したり、臨機応変に進めていました。

課題図書としては、先輩社員の勧めでHead Firstデザインパターン 第２版を選びました。結構分量あるものです(600ページ以上あって重い)

 

簡潔に学べた点・良かった点、反省点をまとめたいと思います。

学べた点・良かった点

・to teach is to learnの精神で発表しながら学べた

・オブジェクト指向の基本的な考え方を学べた

・23パターン一通り周り切ったという自信がついた

 

　1点目につきまして、発表しながら学べたのは良かったかなと思っています。私は、結構本を流しながら読んでしまいがちなので、強制的に発表しなければ進めないようにしたことで、内容が反芻され、より学びが深くなった気がします。また、先輩エンジニアの方々と色々議論できたことも深い学びになりました！内容からかなり脱線することもありましたが笑

　2点目につきまして、Javaのような昔からある言語でオブジェクト指向の本筋の実装を学べたのは勉強になりました。"継承より委譲"とかは有名なフレーズですが、具体例を見ながら学ぶことによりそのようなフレーズをちょっとだけ理解することができたのかなと思いました(23パターンもあれば嫌でも体に染み込む)。

　3点目が、個人的には一番良かったですね。デザインパターンが役に立つか立たないかは置いておいて、一通り体系的に学べたのは自信になりました！

日常会話でstrategyパターンとかfacadeパターン何それ？とならないのは一番メリットなのかなと思います。

 

反省点

・Javaすぎた

・特に銀の弾丸でもない

・私が発表しまくってしまった

 

　１点目につきましては、弊社はバックエンドは基本的にRubyで書いているので、Javaだと違和感がある設計がありました。Rubyでインターフェースとか基本使わないですし、デザインパターンの技法を直接的に真似ることはできないので、注意が必要だなと感じました。

　2点目につきましては、今ではよく使われないパターンやライブラリの内部で実装されているようなパターンが結構あって(flyweightやIteratorとか)、応用しづらいため、あまり銀の弾丸ではなかったかなと。

ただ、decorator, strategy, factoryなどは今でも知らないといけないパターンだとは思います。

　3つ目は、輪読会のつもりでしたが、ほぼ私がスライドをまとめてしまったので、あまり輪読感がなく、離脱率が多くなってしまったことですね。もう少し実践形式にした方が良かったのかもしれないです。

 

最後に

 

準備が面倒な時もあるけど、なんだかんだ勉強会やるとワイワイして楽しい！

 

 

 

実行環境毎に環境変数を切り替えてPlaywrightのテストを実行する

エムスリーキャリアでQAエンジニアを担当している川浪です。

本記事では前回に引き続き環境変数を参照するPlaywrightのE2Eテストについて、実行環境毎に環境変数を切り替えてテスト実行する方法をご紹介します。

※前回の記事は、以下のリンクを参照してください

m3career-eng.hatenablog.com

 

 

前提条件

PlaywrightのテストをVisual Studio Code（VSCode）もしくはコンソールから実行します。

  • 前回の記事と同様、VSCodeの機能拡張「Playwright Test for VS Code」とNode.jsのライブラリ「dotenv」をインストール済み
  • 「TEST_ENV」という環境変数を使って、環境ごとに異なる設定を読み込むことを想定
  • 本番環境、ステージング環境、開発環境用に以下の.envファイルを用意
    • .env.production（本番環境用）
    • .env.staging（ステージング環境用）
    • .env.development（開発環境用）

.envファイルを読み込むコードを追加する

.envファイル名から読み込む環境設定ファイルを特定するソースコードを playwright.config.ts に追加します。

import dotenv from 'dotenv';
import path from 'path';

if (process.env.TEST_ENV) {
    dotenv.config(
        { path: path.resolve(__dirname, `.env.${process.env.TEST_ENV}`) }
    );
}

コマンドラインから実行

Windowsの場合、コマンドプロンプトを起動しPlaywrightのインストール先フォルダに移動後、以下のコマンドを実行します

（例）ステージング環境で実行する場合

set TEST_ENV=staging
npx playwright test

VSCodeからデバッグ実行

ローカル環境でVSCodeからデバッグ実行する場合、settings.jsonファイルに環境変数を追加します。

手順は以下の通りです。

  1. VSCode左下の歯車アイコンをクリックし、設定（Settings）メニューを選択します
  2. 設定画面が開くので、検索ボックスに「playwright」と入力し設定項目の表示を絞り込みます
  3. 表示された項目の中から「Playwright: Env」の「Edit in settings.json」を選択します

 

settings.jsonファイルが開くので、「playwright.env」キーに環境変数名と値を追加し保存します。

"playwright.env": {
    "TEST_ENV": "development"
},

 

以上で設定は完了です。

あとは「Playwright Test for VS Code」のインストールにより追加されたVSCodeのTestingビューを開き、Test Explorerに表示されているPlaywrightのテストをデバッグ実行します。

環境変数「TEST_ENV」で指定したenvファイルが読み込まれ、ファイル内の環境変数を参照してテストが実行されます。

おわりに

今回デバッグ実行の際に設定メニューから環境変数を追加しましたが、VSCodeの公式サイトではデバッグ機能について紹介されていて、launch.json というファイルに環境変数を設定してデバッグできるようです。

今後はこのデバッグ機能に関しても理解しておきたいと思います。

 

環境変数を参照するPlaywrightのE2EテストをVSCodeで実行する

エムスリーキャリアでQAを担当している川浪です。

本記事では、環境変数を参照するPlaywrightのE2EテストをVSCodeで実行する方法をご紹介します。

Visual Studio Code（VSCode）のTestingビュー（機能拡張「Playwright Test for VS Code」のインストールにより追加されるビュー）からPlaywrightのテストを実行したとき、自前で用意した環境変数が読み込まれない現象に遭遇したため、その対処方法について記載します。

本記事の前提条件

本記事の前提条件は以下の通りです。

- Playwrightをインストール済み（使用するスクリプト言語にTypeScriptを選択）

- Visual Studio Code（VSCode）をインストール済み、かつ、VSCodeの機能拡張「Playwright Test for VS Code」をインストール済み

- dotenvをインストール済み*1

 

.envファイルの作成

まずPlaywrightのプロジェクトフォルダ直下に「.env」という名称のファイルを作成します。

作成したファイルを開き環境変数を入力、保存します。

    ※入力例：
    LOGIN_URL='https://staging.example.com/'
    LOGIN_USER='hogehoge'
    LOGIN_PASSWORD='fugafuga'

playwright.config.ts ファイルの修正

Playwrightのプロジェクトフォルダ直下にあるplaywright.config.tsファイルを開き、.envファイルを読み込む以下のコードを追加します

    import dotenv from 'dotenv';
    import path from 'path';
    
    dotenv.config({ path: path.resolve(__dirname, '.env') });

Playwrightのテスト実行

VSCodeのTestingビューを開き、Test Explorerに表示されているテストを実行もしくはデバッグ実行します。

環境変数は、コード上で

process.env.環境変数名

と記述することで値が参照できます。

 

おわりに

環境変数ですが、例えば本番、ステージング、開発環境毎に異なる値を参照させたい場合、playwright.config.ts で読み込む.envファイルを切り替えるコードを追加することで対応可能です。詳細は次回以降のブログでご紹介したいと思います。

参考URL

https://playwright.dev/docs/test-parameterize#env-files

 

*1:dotenvは環境変数を.envファイルから読み込むためのNode.jsのライブラリです。インストール方法は https://github.com/motdotla/dotenv を参照してください

BigQueryで緯度経度情報をH3情報に変換する

エムスリーキャリアでSalesforceの開発を担当している西村です。

ライドシェアリング事業を展開しているUber社が開発したH3というグリッドシステムとBigQuery上で緯度経度情報をH3で扱える情報に変換するための手法を紹介します。

H3を利用することで地理情報を国/都道府県/市区町村などの枠組みとは別の枠組みで集計・分析できるようになるため、様々な事業で今まではと異なるアプローチができるようになります。

 

H3とは

H3は、世界を六角形のセルに分割する地理空間インデックスシステムです。

https://blog.uber-cdn.com/cdn-cgi/image/width=2160,quality=80,onerror=redirect,format=auto/wp-content/uploads/2018/06/Twitter-H3.png

H3: Uber’s Hexagonal Hierarchical Spatial Index | Uber Blog より引用

 

各六角形のセルにはそれぞれ異なるセルIDがふられていて、H3には緯度経度をセルIDに変換する機能があります。

六角形のセルの大きさをどの程度にするかは0~15までの16段階で指定ができ、H3ではこの16段階を解像度という概念で扱っています。

h3geo.org

 

例として、東京駅の緯度「35.68130153」と経度「139.76708188」をH3を使って六角形のセルIDに変換してみます。変換する六角形の大きさとしては、1辺が平均26kmの解像度4と平均1.4kmの解像度7を指定します。

解像度が4の六角形に変換した時のセルIDは「842f5a3ffffffff」、解像度が7の六角形に変換した時のセルIDは「872f5a32dffffff」になります。
解像度が異なると同じ緯度経度でも異なるIDに変換されることがわかります。

この変換機能を含んだライブラリはC言語で書かれていて、PythonやJavaScritpなどの他の言語でも機能扱うことができます。

 

BigQueryで緯度経度情報をH3情報に変換

変換には以下を活用します。

GCSにh3-jsをアップロード

https://unpkg.com/h3-js からスクリプトをダウンロードします。

GCSに適当なバケットを作成して、ダウンロードしたファイルを作成したバケットにアップロードします。

JavaScript UDFを定義

h3-jsに緯度経度を六角形のセルIDに変換するlatLngToCell という関数があるのでこれをSQLから呼び出せるようにJavaScript UDFを定義します。

以下のようなUDFを定義して保存します。

CREATE OR REPLACE FUNCTION `project.dataset.h3_latLngToCell`(lat FLOAT64, lng FLOAT64, res INT64) 
RETURNS STRING LANGUAGE js
OPTIONS (library=["gs://hoge/h3-js.umd.3.6.3.js"]) AS R"""
  return h3.latLngToCell(lat, lng, res);
""";  

UDF内の各々は以下のように扱います。

  • project : Google Cloudのプロジェクト名
  • dataset : UDFの定義先となるデータセット名
  • h3_latLngToCell : このUDFの関数名。わかりやすい名前を付ける
  • library : 先程GCSにアップしたファイルのgsutil URI
  • h3.latLngToCell(lat, lng, res) : h3-jsの呼び出したい関数

SQLからの呼出

先程の東京駅の緯度「35.68130153」と経度「139.76708188」と解像度7を使ってUDFをSQLから呼び出してみます。

SELECT `project.dataset.h3_latLngToCell`(35.68130153, 139.76708188, 7)

実行結果として「872f5a32dffffff」を出力します。

 

最後に

今回はlatLngToCellを呼び出すUDFを作成しましたが、h3-jsの他の関数もUDFに定義すればSQLで利用できます。

h3-jsは他にも隣接するセルを返す関数やセルとセルがいくつ離れているかを返す関数があるので活用の可能性は大きいです。

活用例の一つとしては、飲食業界で1つのセルの中に競合を含む店舗数がどの程度あるかを集計することで市区町村といった切り口とは別の観点で今後の出店戦略を練るのに活かすことができると思います。

 

また、Kepler.glというブラウザ上で地理情報を可視化できるツールがあります。こちらのツールで算出したセルIDを含むデータをインポートすると、地図上でH3の六角形形式で可視化ができるのでぜひ試してみてください。

kepler.gl