読み方ガイド
Kaigi on Rails に参加したかったけど行けなかった人向け。
私自身が Rails 初心者のため、初学者にもわかりやすい構成で、専門用語は最小限。必要箇所だけコード／コマンドを添えています。
はじめに
株式会社 Inner Resource でエンジニアをしている翠川です。
9月26日〜27日に Kaigi on Rails 2025 に参加したので、参加レポートを書きました。学会ではないテック系カンファレンスは初参加で、とてもワクワクしました。
先に弊社エンジニアの記事も公開されています。ぜひ併せてどうぞ 👉 Rails歴半年のエンジニアが行くKaigi on Rails 2025
全体を通して
サイトの英語化や海外登壇など、日本→世界を強く意識した運営が印象的でした。
また、身近で実務に効くセッションが多く、「Rails で開発するみんなが、似たような辛み・悩みを抱えながら進めているんだな」と実感しました。
お気に入りのセッション
Railsアプリケーション開発者のためのブックガイド
資料：https://x.com/takahashim/status/1971801585752985690
「紹介したい本がありすぎる」ということが最初から最後まで伝わってきました。メモしていたのですが、情報の波に飲み込まれたため途中で諦めました（笑）。また、積読してもいい話なども面白かった。
この本持ってないなというものも沢山あり、触発されて閉会後に秋葉原のブックタワーに直行しました。
そのpreloadは必要？──見過ごされたpreloadが技術的負債として爆発した日
資料：https://x.com/mugi_1359/status/1971815228934668791
まさに数日前にコードへ preload を追加したばかりだったので、タイムリーでした。今は必要でも将来不要になったら棚卸しする（dynamic 的にも）という自戒ポイントを持ち帰りました。
-
preload/includes/eager_loadの違い-
preload：関連ごと別クエリ（N+1回避が可能だが常に複数クエリ作成される） -
includes：必要に応じてJOIN or 別クエリを自動選択（参照があればJOINとなる） -
eager_load：LEFT OUTER JOIN固定
-
下記のように preload を使うと、関連ごとに個別クエリが実行されます。実務では N+1 問題の解決に使うことが多いです。
User.preload(:address, friends: [:address, :followers])
# SELECT "users".* FROM "users"
# SELECT "addresses".* FROM "addresses" WHERE "addresses"."id" IN (1,2,3,4,5)
# SELECT "friends".* FROM "friends" WHERE "friends"."user_id" IN (1,2,3,4,5)
# SELECT ...
Rails Guide より引用
なぜ preload が負債化するのか？
→ 将来その関連を使わなくなっても毎回フェッチが走り、クエリ数やメモリが増えるため。
小規模から中規模開発へ、構造化ログからはじめる信頼性の担保
資料：https://x.com/kaku_dooo/status/1971757889040929052
ログはちょうど取り組んでいるテーマで、タイムリーでした。Rails 8.1 では構造化イベントを扱う標準 API が入る見込みで、アップデートの際は 8.1 まで上げたいところです。
非構造化ログ
人間が読みやすい自由記述のテキスト中心のログ。行単位で時刻やレベル、任意メッセージが並びます。
Rails.logger.info "User #{user.id} purchased #{item.sku} at #{Time.current}"
# => I, [2025-10-02T08:12:34.567] INFO -- : User 42 purchased SKU-123 at 2025-10-02 08:12:34 +0900
構造化ログ
キーと値（JSON など）で機械が扱いやすい形にしたログ。各行が同じ“型”を持ち、後段の検索・集計に強いです。
Rails.logger.info({
event: "purchase",
user_id: user.id,
sku: item.sku,
price_jpy: item.price,
ts: Time.current.iso8601,
request_id: RequestStore[:request_id],
trace_id: RequestStore[:trace_id]
}.to_json)
# => {"event":"purchase","user_id":42,"sku":"SKU-123","price_jpy":9800,...}
8.1以降はイベントAPIで構造化ログが標準に
Rails 8.1 には Structured Event Reporting（Rails.event）が入り、構造化されたイベントを統一フォーマットで出せます。まずは手元の JSON ロギングから始めつつ、将来的にはイベント中心に寄せていく方針にしました。参考：Rails 8.1 Beta 1
Rails.event.notify("purchase",
user_id: user.id,
sku: item.sku,
price_jpy: item.price,
request_id: request.request_id
)
Keynote
dynamic!
資料：https://x.com/moro/status/1971415676394013008
- Rubyで動的に開発する
- Railsアプリケーションを動的に開発する
- チームでプロダクトを動的に開発する
の3章構成でした。
最初から正解を選ぶのは難しく、本当に集中すべき箇所以外は保留してよいという点に強く共感しました。現状に適したソフトウェアでよく、内外の状況が変われば動的に変化させていけばよいというメッセージでした。
最終的な結論として 20 年前の書籍に回帰した点も面白く、本質を突いているのだろうと感じました。
Building and Deploying Interactive Rails Applications with Falcon
Falcon という Web サーバの紹介でした。スレッドではなく fiber 単位で処理を並列化できる効率の良いサーバ、という理解をしました。
スライドは英語中心でしたが要所で日本語もあり、コード行のハイライトやアニメーションなどリスナーへの配慮がありがたかったです。
「地球環境のためにも Falcon がいい」との話もあり、まずは個人開発で試してみたいと思いました。
おわりに
テックカンファレンス初参加 & Rails 歴が浅い身として、明日から役立つ考え方や実装の具体例を多く学べました。来年は渋谷開催で会場も広くなるそうです。ぜひ参加したいです。
株式会社Inner Resource のエンジニアブログです。 忙しい研究者・研究施設の業務効率化のためのクラウド購買管理ソフト「リプルア」を開発しています。
Discussion