Japan Voyage：三つのサイト、四か国語、Ruby masterで動く一つのRailsアプリ

サービスについて

Japan Voyageは、日本でゴルフ仲間、スキー仲間、旅行先を見つけるためのサービスです。ゴルフ、スノー、トラベルの三つの公開サイトと、それらをまとめるポータルで構成されていて、すべて一つのRailsアプリから配信しています。このWebサイトも同じアプリで動いています。

開発も運用も私たちが行っています。このページに書いたことは、すべて私たち自身が決めて、今も向き合っている判断です。

技術構成

• Rails 8.1、Hotwire（TurboとStimulus）、ViewComponent。JavaScriptのフロントエンドを別に持っていません。
• 一つのコードベースで三つのサイト。 サブドメインでサイトが決まり、配色、施設、文言がそれに従います。チャット、イベント、プロフィールなどの共通機能は一度だけ書いています。
• 四か国語：英語、日本語、フィンランド語、繁体字中国語。パスベースのロケールURLと、全ページのhreflang。
• iOS・Androidアプリ：Hotwire NativeでWebの画面を再利用し、Firebaseでプッシュ通知を送ります。
• リアルタイムチャット：ActionCable。
• 本番環境のSQLite、Falcon Webサーバー、CIから直接デプロイするKamal。
• データ：2,000以上のゴルフ場と500以上の旅行先。バージョン管理されたシードファイルで管理し、編集ごとに内容を検査するツールを用意しています。

Ruby masterでの運用

Japan Voyageの本番環境は、リリース版ではなく、Rubyの開発ブランチを毎晩ビルドした Ruby master で動いています。意図的にそうしています。次のRubyのリリースが実際のRailsアプリにどう影響するかを、お客様がアップグレードする数か月前に知ることができるからです。

もちろん代償もあります。2026年8月26日、Ruby masterの変更でFiberスケジューラのインターフェースが新しいバージョンに移りました。Falconが依存するio-event gemはまだ古いインターフェースを実装していたため、スケジューラ上の書き込みがすべて進まないまま空回りしました。ワーカーはCPUを100%使い続けてヘルスチェックに通らず、5回続けてデプロイが失敗しました。

原因を突き止め、Rubyのバージョンを固定するのではなく、新しいインターフェースに対応したio-eventのリリースに更新しました。さらに、指定したイメージ上でFalconの最小アプリを起動するスモークテストを作り、RubyやFalconの起動失敗とアプリ側の失敗を1分以内に切り分けられるようにしました。この種の問題を本番環境に届く前に見つけるのが、私たちのバージョンアップ支援です。

それ以前のRuby 3.4から4.0への移行はブログ記事にまとめています。

お客様の案件に活きること

• 多言語Railsの正しい作り方：ロケール別ルーティング、hreflang、サイトマップ、翻訳の運用
• Hotwire NativeでWeb、iOS、Androidを一つのコードベースに
• 少人数での運用：SQLite、Kamal、マージで自動デプロイするCI
• RubyとRailsの新バージョンを先に本番で使っているからこそ得られる、変更への早い気づき