💎

Kaigi on Rails 2025 参加体験記 - Ruby初心者でも楽しめました！

に公開
Ruby
Rails
Web
Kaigi on Rails
idea

参加経緯

pixiv 株式会社に招待していただきました。スカラーシップという制度です。

スポンサー企業の中にはスカラーシップを導入している企業さんもあります。
スカラーシップとは学生を招待する取り組みで、これによって学生は Ruby コミュニティや pixiv さんと交流できたり、Web アプリケーションの技術について学ぶことができるので、とても良い機会になります。
さらに、コミュニティを盛り上げるという観点でも、コミュニティと学生双方にとって良い機会です。

今後も pixiv さんを含めた各社からスカラーシップ導入が広がっていくことを期待しています！

https://inside.pixiv.blog/2025/08/19/160000

また、振り返り会としてアフターイベントが開催される予定なので、興味のある方はぜひ参加してみてください。

https://connpass.com/event/370180/

自己紹介

Rails はもちろん、Ruby も触り始めたばかりの初心者です。
普段は TypeScript の Next.js 周りのモダン技術を使って、フルスタックに開発しています。
Python の Django には触れたことがあり、MVC などの概念は概ね理解しています。

スケジュール

１日目

  • 11:00 - 12:00

    初日は会場内で集合し、顔合わせと自己紹介をしました。法被をもらって、最初のスポンサー LT とキーノートを見ました。

  • 12:00 - 13:30

    お昼休憩に pixiv の社員さんとランチ会（美味しいフレンチ料理をいただきました）

  • 13:00 - 15:05

    再び続きのセッションを見ました。

  • 15:05 - 16:50

    お昼を食べた後はブースを一通り見て、わいわい部屋で本を見たり、コーヒーやデザートなどを嗜んでいました。
    ブースを見過ぎて、見たかったセッションを見られなかったのは残念でした。

  • 16:50 - 18:30

    初日のセッションがすべて終わった後は、再び会場で集まりました。

  • 18:30 -

    そこからは公式の懇親会に移動し、美味しいご飯を食べたりお酒を飲んだりしながら、いろんな Rubyist の方や Ruby Committer、登壇者の方々とお話ししました。
    ありがたいことにコミッターの方ににコミッターを紹介してもらえて、改めて Ruby コミュニティについて知ることができました。

2 日目

  • 10:00 - 11:35

    最初の集合はなしで、いきなりセッションを見ました。

  • 11:35 - 13:05

    他のスカラーシップでも来ている学生の方々とランチをしました。ここでも横のつながりもできました。

  • 13:05 - 18:15

    再び続きのセッションを見て、無事二日間のイベントが終了しました。

  • 18:15 -

    その後は、pixiv の社員さんに二次会に誘ってもらい、そこでもエンジニアの方々と就活の相談をしたり、雑談をしたりしました。

    ランチ会

イベントの感想

  1. イベントではかなり自由にセッションを選んで見られて、縛りはほぼなく、ゆるく楽しめたのが良かったです！

  2. 世界中で Rails は使われていて、Ruby コミュニティの熱意は非常に高いのが伝わりました！

  3. 懇親会の時にお話しして、Ruby コミッターの方々は Ruby をより愛していて、機能改善などへの貢献意識が高いと思いました。

  4. Web 技術（非同期処理など）の基本的なセッションは分かりやすかったです。セッション中に Rails のコード例が出ると、わからなくなってしまうことはありました。

  5. Ruby 言語により興味が湧いて、コミッターの方々に憧れの気持ちが生まれました。

    会場の雰囲気

セッションの復習

これらの要点まとめは Ruby 初心者の私が解釈でまとめています。

dynamic!

Speaker: MOROHASHI Kyosuke

要点

  1. dynamic とは「継続して変化し続けること」。

  2. 周りの環境が変化するから、ソフトウェアも変化しなければいけない。なによりたのしい。

  3. 下記の３つの軸で動的に開発する

    1. Ruby の言語仕様や開発環境は動的である。
      ハッピーパスとは「普通の利用者が期待する最もシンプルな操作ができる」までを実装すること。しかし、これだけではリリースできない。

    2. 変更にもシンプルに改良を繰り返し、Rails でも動的に開発をしていく

    3. 企画者と開発者が動的で動くソフトウェアで会話する。

感想

ソフトウェアは動的である必要があり、そのために開発しやすい環境が Ruby にはあるということがわかりました。

また、この後でも島田さんの「WHOLENESS, REPAIRING, AND TO HAVE FUN」というスライドが何回か出てきて、この 基調講演 はレジェンドなんだと思いました。

開発と運用が継続的に循環することを前提に、小さく作って小さく直す姿勢が印象的でした。例えば、まずはハッピーパスを素早く用意し、実運用の学びを次の小さな改良に反映する、といったループです。

高度な UI/UX こそ Hotwire で作ろう

Speaker: Naofumi Kagami

要点

  1. React ではなくても、Hotwire で十分に実現できることは多い。

  2. それは以下の根拠から

    1. Cookpad などの有名サイトでも使われている
    2. ページ遷移や部分画面更新に関して Hotwire Turbo は体感的に高速なケースがある
    3. 複雑な UI も作ろうと思えば作れる

感想

開発速度に関してはシンプルな構造のため、速いという利点はあると思います。
一方で、実行速度が常に有利とは限らず、要件や実装方針によって変わると感じました。

また、「データ中心か、HTML 中心か」といったアプローチの違いにより、速い時もあれば遅い時もあります。
ただ、フロントエンドも Rails で書きたいという気持ちもわかるので、今後さらに普及していってほしいと思いました。

補足として、Hotwire は Turbo（ページ遷移・部分更新）と Stimulus（最小限の JavaScript コントローラ）から成るため、バックエンド主導で UI を組み立てやすいのが特徴です。例えば Turbo Frames を使えば、ページ全体を再読み込みせずに特定の領域だけを差し替えることができます。

Rails アプリケーション開発者のためのブックガイド

Speaker: Masayoshi Takahashi

要点

  1. チームの共通理解という面では書籍を読む文化は消えない
  2. 読めなければ積読せよ

感想

Rails に関する本だけでなく、インフラや情報系の本の紹介もしてくださって、非常に参考になりました。

2 分台で 1500examples 完走！爆速 CI を支える環境構築術

Speaker: Hayato OKUMOTO

要点

  1. 最終的にはテスト 15 倍の高速化、1/10 以下のコスト削減
  2. parallel_tests によって並列実行
  3. Knapsack Pro によって均等に並列実行
  4. tmpfs によって、ストレージ I/O 最適化
  5. 最強オンプレによってコスト最適化

感想

テストであれば、定期的に実行する必要がなく、リリースなどの CI のタイミングだけで済むので、オンプレにしたのはコスト削減の面でとても良い選択肢だったと思いました。

Rails による人工的「設計」入門

Speaker: Yasuko Ohba (nay3)

要点

  1. 設計できる人は設計できない人の気持ちがわからない。

  2. 教わる側は「手順 → システム = コード → 設計」

  3. ベテランは「設計 → 手順 → コード = システム」なので、ここですれ違いが生まれる

  4. 下記手順で「逆算」せよ

    1. ゴールを決める（画面構成や遷移を考える）
    2. ゴールに必要な機能を列挙する
    3. 選択肢を複数用意し、仮置きする

  5. デザインパーツも仮置き

  6. パーツは「データ構造、処理構造、個別機能・gem」

感想

個人的にはかなり良いセッションでした。

そもそも私はプロジェクトでは PM を担当することが多く、また後輩に授業のアシスタントをしています。
なので、両者の視点の違いを知ることができただけでもすごい良い機会になりました。「設計して」と雑に投げるのではなく、まずは逆算することに慣れてもらうようにしてみたいと思います。
具体的には、画面の遷移図やワイヤーフレームを先に用意し、それに必要なデータ構造や処理の流れを後から当てていく手順が、初心者にとっても理解しやすいと感じました。

今改めて Service クラスについて考える 〜ある Rails 開発者の 10 年〜

Speaker: Tomohiro Hashidate (joker1007)

要点

  1. 必要に応じて Service クラス使うこともある...
  2. チーム開発で Fat Model の認識違いがある。
  3. コンテキストを保ちつつ、改良を繰り返すことが大事。

感想

もちろん、Service クラスは Fat Model になりやすいので、導入には慎重に検討する必要があるとは思います。しかし、最初から絶対に使わないと決めつけるよりも、
どんなプロジェクトでも機能の独立性を担保して、改良を繰り返すことは大事だと思いました。

ActiveRecord 使いが知るべき世界：Java/Go/TypeScript の ORM アプローチ比較

Speaker: 河野裕隆

https://www.docswell.com/s/hk_it7/ZWMNJR-orm-kaigi-on-rails

要点

  1. ORM はやはり便利
  2. ActiveRecord パターンは「設定より規約」原則を再現する
  3. DSL クエリ発行、コネクションプール有無、スキーマ管理有無の機能面で比較した際には優秀

感想

他言語との ORM アプローチの違いについてさまざまな視点で比較していてより説得力がありました。
改めて ActiveRecord が機能面でも優秀だと感じました。
一方で、データマッパー系の ORM と比べると、ドメインと永続化の境界の置き方が異なるため、システムの規模やチームの好みに応じた選択が重要だと再認識しました。

履歴 on Rails : Bitemporal Data Model で実現する履歴管理

Speaker: hypermkt

要点

  1. 履歴管理には「バージョン型」と「有効期間型」があるが、どちらも欠点がある
  2. Bitemporal Data Model では、特定時点スナップショット、遡及データ修正、変更履歴追跡の３つの問題を解決する
  3. 「データ事実上の有効期間」と「システム上の有効期間」の時間軸を持つ
  4. SQL が複雑になり、学習コストが増加するので、適用は検討する必要あり

感想

あとからデータを追加する場合でも正しく反映したいなどの根本的な課題をすべて解決するためのアプローチとしてはすごくデータの信頼性を高めることができると思いました。

Rails アプリから何を切り出す？機能分離の判断基準

Speaker: yumu

要点

  1. カテゴリは「ビジネス関連度、インフラ依存、複雑さ、運用コスト vs 開発スピード、ビジネス上の柔軟性」の５つ
  2. それぞれのカテゴリを３段階で評価し、３つ以上分離推奨であれば、検討、２つ以上分離回避であれば慎重に

感想

機能分離に関してはあまり意識をしたことがなかったのですが、このように定性的に分類し、最終的には定量的に判断できるようにしていて、企業が導入するのにもとても良いアプローチだと思いました。
具体的には「分析機能」「広告機能」など、ビジネス関連度やインフラ依存が低い領域から順に分離を検討すると、影響範囲を抑えやすいと感じました。

マンガアプリ API と共存する Web 体験版の作り方 〜 コンテンツ保護技術を添えて

Speaker: baba

感想

API サーバーへの負荷分散や API 実装の二重管理の回避には、
API レスポンスを S3 上の静的 JSON ファイルとして保存し、CloudFront 経由で配信することで実現していました。また、コスト面でも要件を満たす必要十分でありました。

JSON 内の attributes によって、プラットフォームによって一話の定義が変わってしまう問題を解決していました。

もちろん開発者ツールを開いて、S3 の画像 URL にアクセスすれば漫画のページをみることができます。そこで、マンガコンテンツの不正利用防止には「GridShuffle」という独自の画像難読化処理をしていました。

S3 バケットには署名付き URL をそれぞれ一ページずつに設定して、正規のユーザーにのみ復元処理をすることで実現しています。

「技術負債にならない・間違えない」権限管理の設計と実装

Speaker: naro143 (Yusuke Ishimi)

要点

  1. 権限設定のミスは事業の信頼度に関わり、絶対に許されない
  2. 役割でなく、権限に依存した判定にする
  3. 「実装・利用・理解」で間違えない
  4. 「対象・役割・操作・条件」を物理的なファイルごとに分離
  5. Next.js では Rails から渡される最低限の権限一覧の JSON ファイルを管理するだけ

感想

個人的に一番印象に残ったセッションでした。

正直、内容はかなり難しく、スライドを見返してもなかなか理解できないです。
しかし、そもそも私は企業から受託したシステム開発で権限管理の設計と実装をしたことがあり、その経験からこのセッションに興味を持っていました。

そこでも RBAC（ロールベースアクセス制御）と ABAC（属性ベースアクセス制御）が複雑に絡んでいてそれらを表にまとめたものの、コード上ではそれが適用されているのかを理解するのは難しかったです。
しかし、このセッションのように物理的にファイルを分離し、リファクタすることによって間違えないようにすることはとても大事だと思いました。

Keynote: Building and Deploying Interactive Rails Applications with Falcon

Speaker: ioquatix

感想

正直難しくてほとんど理解できなかったのですが、Falcon というライブラリの凄さについてはすこし分かった気がします。

Falcon とは非同期処理を可能とする、Web サーバーでありライブラリです。
あるリクエストが I/O 処理で待ってる間に、Fiber を使って別のリクエストの処理を進めるノンブロッキング I/O という方式を採用しているらしいです。
これによって限られたメモリ内で最大の性能を発揮できるようにしています。

https://github.com/socketry/falcon

また、デプロイや監視に関しても全く問題なく実装できるという話がありました。

大規模サービスでの採用事例も紹介され、膨大なリクエストを効率よくさばける設計であることが印象に残りました。数字の桁にツッコミが入って会場が沸いたのも面白かったです（笑）

各種 Gem 用の AGENTS.md を集めてるリポジトリも公開されていました。

https://github.com/ioquatix/agent-context

gem "agent-context"

最後はライブコーディングで、Claude 君に「今 Ruby on Rails のステージ上にいるよ」って言っていて、とても面白かったです。

babaさんの登壇

今後について

前にも書きましたが、Web 技術の基本設計に関しては参考になることが多く、いま進めている個人や学校のプロジェクトでも取り入れられる要素が多いと感じました。

また、私自身は Rails の経験がほとんどなかったのですが、新規プロジェクトの API などで勉強がてら採用してみるのも良いと思いました。まずは CRUD と認証の小さな機能から始め、テストと CI を整えつつ学ぶのが良さそうです。

来年の会場は渋谷ということで、より研鑽を積んで、さらに楽しめるようにしたいと思いました。

Discussion