こんにちは！AppBrewでエンジニアをしている 深津 と 駒場 です。
今年は函館開催となった RubyKaigi 2026 に、AppBrewから2名で、社の「技術カンファレンス参加サポート制度」を利用して参加してきました。
現地で感じたことや印象に残ったことについて、2人で共同レポートとしてまとめてみます。
AppBrewのRubyKaigi参加について
AppBrewでは、国内最大級の美容プラットフォーム「LIPS」を運営していて、バックエンドにはRuby on Railsを採用しています。Rubyコミュニティへ少しでも貢献できればという思いから、昨年（RubyKaigi 2025）からスポンサーとして協賛しています。
今年も継続してスポンサー協賛しており、社からは 2名（深津・駒場）が現地参加 しました！
「技術カンファレンス参加サポート制度」を利用してみた
AppBrewには 技術カンファレンス参加サポート制度 というものがあります。せっかくの機会なので、簡単に紹介させてください。
ざっくりまとめると以下のような制度です。
- 参加費・交通費は会社負担、参加中も業務時間扱いでOK
- 業務扱いにできるのは 原則3日まで（超える場合はチームリードに相談）
- 登壇する場合の資料作成時間も業務扱い にできる
- 原則年3回まで 利用可能(もっと参加したいときは チームリードに相談)
- 対象カンファレンスは RubyKaigi / Kaigi on Rails / Kotlin Fest / DroidKaigi / try! Swift / iOSDC, TSKaigi など(その他参加したいカンファレンスがあればチームリードと相談)
条件として、参加後に何かしらのアウトプット（ブログ、社内共有、レポートなど）を残すこと が求められています。インプットだけで終わらせず、得た学びを社内・社外に還元することを大事にしている制度設計だなと感じています。今このブログを書いているのも、その制度のアウトプットの一環です。
申請フローもチームリードに相談 → 承認後に経費精算で申請、というシンプルな流れで、利用しやすい制度になっていると思います。
初RubyKaigiで感じたこと
両名共に初参加でしたが、2人で歩いて感じたことを共有します。
世界中から人が集まるイベントだった
会場に着いてまず驚いたのが、本当にいろいろな国の人が参加している ことでした。会場では複数の言語が飛び交い、海外から来たRubyistたちが楽しそうに議論している光景があちこちで見られました。
「Rubyってこんなにグローバルなコミュニティなんだ」と、改めて実感した瞬間でした。
スポンサーブースとスタンプラリー
各社のスポンサーブースを巡るスタンプラリーがあり、せっかくなので 全ブース制覇 してきました。
ブースを回ると、それぞれの企業がノベルティ配布だけでなく、各社のRubyの使い方や開発の取り組みについて熱心に話してくれて、これがめちゃくちゃ参考になりました。
- どんな規模感でRubyを運用しているか
- 大規模アプリケーションでのアップグレード戦略
- AI時代の開発フローをどう設計しているか
- どんな技術的チャレンジに取り組んでいるか
業務時間中だとなかなかこういう情報をまとめて聞ける機会はないので、スタンプラリーは「ノベルティ目当て」で始めたものの、結果として一番濃いインプットになったかもしれません。各社の中の人と直接話せるのはRubyKaigiならではの体験だなと感じました。
iOS系カンファレンスとの差
これまで大きめの技術系のカンファレンスだとモバイルアプリエンジニアであることもありiOSDCとtry! Swiftに参加した事がありました。英語のトークが多いことからtry! Swiftと似た雰囲気なのかなと想像していましたがそこはわりと当たっていました。
そして登壇者にコミッターが多く、CRubyの実装関連の話が多いのだろうと思っていましたが、JRubyなどの他の処理系の話題も多く、このあたりはAppleが主導しているSwiftとは異なるなと感じました。またPicoRubyの話題も相当に多く、SwiftもEmbeddedがあり、小規模ハードウェアを操作したりといった組み込み系のトークがどのカンファレンスでも一定人気なんだなと感じました。
そして最後に「Ruby Committers and the World」のトークが印象的でした。これほどのコミッターが一度に集まるのはRubyKaigiならではだと思いました。30名程が壇上で言語へのプロポーザルについて議論していくというこれだけコミッターがいるからこそ、そしてMatzが参加しているからこそ出来る内容だなと思いながらとても面白かったです。
型そしてCodingAgent
Coding AgentはRubyコミッターの開発スタイルにも浸透してきている
去年から今年にかけてのこの1年で、AIコーディングの活用は本当に一気に進んだなという印象です。RubyKaigiでも、登壇者の方々が 「これはAIに書かせた」「Claude Codeを使った」 といった発言を当たり前のようにする場面が多く、コミッター層にもAI活用が浸透しつつあることを感じました。
mametter（遠藤侑介）さんの記事がいろんなセッションで引用されていた
ではそんなLLM時代にRubyは適した言語なのか?という議題で話題になっていたのが、Rubyコミッターのmametterさんが書かれたこちらの記事です。
この記事は、Claude Codeに15言語で簡易gitを実装させ、所要時間・コスト・行数などを定量的に測定したベンチマーク記事で、結果は Ruby・Python・JavaScriptの動的型付けがトップ3 という内容でした。
「静的型付け言語の方がコンパイルが通るかどうかが一定のハーネスとして機能するのでAIエージェントとの相性が良いだろう」という主張はうなずけるものの、モデルの学習量としてJavaScript, Pythonが多いのは有利に働くと思っていましたがそこにRubyが食い込んでくるのは意外でした。
では静的型付けではなくてもいいのか？
弊社でも静的型付けのメリットを求めてGoへの移植を検討した時期がありますが、Rubyで & をつけ忘れてエラーになってしまい「静的型付け言語ならこの状態のままデプロイせずにすんだのにな」と感じていた時の殆どのケースはnilに対するNoMethodErrorです。つまり変数がNullableなのかNonNullなのかが自分の中で関心が高かったわけです。もちろん一度でもコードを通過するテストを書いていれば気づけたケースも多かったためテストを書くという方向性に落ち着いていました。
そういった観点で「No Types Needed, Just Callable Method Check」のトークは包括的な型システムは目指さず、「メソッドの存在確認だけ」に特化することで NoMethodError を未然に防ぐgemによって「AIがコードを書くスピードに対して、CIがどれだけ早く正しさを返せるか」という納得感のあるトークでした。
まとめ
3日間のRubyKaigi、想像以上に学びと刺激の多い時間でした。
- 各社のスポンサーブースで開発の生の話が聞けた
- AI活用と型の議論という、現在進行形のテーマに触れられた
- セッションを通じて、AI時代における具体的なRuby/ツールの進化を見られた
来年2027年は宮崎開催とのことなので、また参加したいと思います！
AppBrewでは一緒にプロダクトを作る仲間を募集しています！Rubyや技術カンファレンスに興味がある方はぜひお気軽にご連絡ください。
Discussion