RAKSUL TechBlog

RAKSULグループのエンジニアが技術トピックを発信するブログです

JSAI2026 参加レポート

2026年6月8日〜12日に開催された「JSAI2026 – 2026年度 人工知能学会全国大会(第40回)」に、データ戦略部のメンバーで参加してきました。 本記事では、JSAI2026に参加して特に印象に残った発表や、会場の雰囲気、参加を通じて感じたことについてご紹介します。

JSAI2026とは

会場入口

JSAI2026-2026年度 人工知能学会全国大会は、一般社団法人 人工知能学会が主催する国内最大規模の人工知能関連の学会です。 大学・研究機関・企業など幅広い参加者が集まり、機械学習、自然言語処理、生成AI、マルチモーダルAI、AIエージェント、AI倫理、産業応用など、多様なテーマについて研究発表や議論が行われています。 2026年度大会は第40回の節目となる大会で、Gメッセ群馬およびオンラインのハイブリッド形式で開催されました。現地会場にも多くの参加者が集まり、セッションでの発表やポスター発表、企業展示を通じて活発な議論が行われていました。

参加の背景

ラクスルのデータ戦略部では、マーケティング施策の効果検証、商品推薦や検索、生成AIを活用した業務支援、架電リストの生成等、データやAIを活用したさまざまな取り組みを行っています。 一方で、近年は生成AIやLLM、AIエージェントをはじめとする技術の発展が非常に速くなっています。単にモデルや手法を知っているだけでなく、それらを実際の業務やプロダクトにどう組み込み、どのように価値につなげるかが重要です。 そのため今回は、最新のAI研究動向を把握するとともに、研究で得られた知見を自分たちの実務課題やプロダクト改善にどのように活かせるかを考えることを目的に参加しました。

また、ラクスルでは「AIを活用したマーケティング実践」セッションを共催し、データ戦略部から2件の発表を行いました。 発表内容については、別記事で詳しく紹介しています。

会場の雰囲気と発表全体の傾向

現地会場では、研究者、学生、企業のデータサイエンティストやエンジニア、AI活用に関わる方々が数多く参加しており、非常に活気のある雰囲気でした。 発表全体の傾向としては、生成AI・基盤モデル・大規模言語モデル(LLM)に関するテーマが多くなっていた印象を受けました。特にRAG、AIエージェント、安全性評価、LLMを用いた業務支援などのテーマが目立ちました。単にモデルの性能を高めるだけでなく、実際の業務やプロダクトでどう活用し評価・運用していくかという議論が多く見られました。

また、従来からの機械学習分野も引き続き大きな柱であり、生成モデル、グラフ学習、異常検知、強化学習、統計モデリング、因果推論など、基礎から応用まで幅広いテーマが扱われていました。加えて、マルチモーダルAIやLLMエージェント、AI倫理、説明可能性、人間とAIの協調といったテーマも目立っており、AI研究の対象がモデル単体から、実世界・社会・業務の中で使われるシステム全体へ広がっていることを感じました。

印象に残った発表

最近の人工知能研究は非常に幅広く、すべてを網羅的に紹介することは難しいため、ここでは私たちが実際に見聞きした中から、特に印象に残った発表をいくつかご紹介します。

大規模行動空間におけるDoubly Robust推定のエンドツーエンド学習に関する一考察(ポスターセッション)

介入を行う施策において、通常であれば施策の優劣はA/BテストやRCT実験の形式で結論を出しますが、オフ方策評価という分野では、手元に溜まった施策ログデータのみからこれから実験する施策の優劣を評価します。本研究は、施策の変数(推薦アイテムの種類等)が膨大になった際、従来手法では評価が難しくなるという課題に対し、補助情報の埋め込み表現を活用することで改善を試みた研究だと理解しています。

ラクスルでも、日常的にA/Bテストを実施しながら施策の優劣を評価しています。特に機械学習モデルを活用した施策では調整すべきパラメータが多岐にわたるため、実験コストをかけず事前に有望なモデルを探索できるオフ方策評価は、ビジネス的にも嬉しい部分が大きいです。ラクスルのビジネスの成長とともに扱う商材が増えていくこと、すなわち行動空間が大規模になっていくことが予想されるため、将来的には本研究のような技術にもチャレンジしていきたいと考えています。

大規模言語モデルは誰を覚えているか(計算社会科学セッション)

大規模言語モデルの集合的記憶について調査した分析研究です。Wikipediaの訃報記録から、どのようなデモクラを持った人物がLLMによって想起されるのかを明らかにし、言語や職業、性別の違いによる想起成功率を検証していました。

インターネットの普及によって、人々の情報インターフェースが本や新聞・雑誌から検索エンジンへと変化したように、生成AIの発展によって、将来的には検索エンジンからLLMとの対話へと情報インターフェースが変化していく可能性が高いです。その中で、LLMが持つバイアスを明らかにしていく研究は非常に意義深く感じました。

特に印象に残った分析結果としては、日本語版Wikipediaの人物よりも英語版Wikipediaの人物の方が想起されやすいという主張です。このようなバイアスのかかった回答がなされているとすると、長期的には、特定の国や組織、人種に関する情報へのアクセスに偏りが生じる可能性もあるのではないかと感じました。想起成功率に寄与する要因としては、Wikipediaで紹介される人物の国籍と、Wikipedia自体の記述言語の2つが大きいと考えられます。そのため、日本語版に掲載された英語圏人物、および英語版に掲載された日本語圏人物の想起成功率を比較すれば、要因を識別できると思われます。

LLM傾向性プロファイリング:マルチエージェント対話のための6軸評価フレームワーク(AI応用:対話エージェントと行動生成セッション)

LLMを単純なベンチマークスコアだけで比較するのではなく、マルチエージェント対話において「どのモデルを、どの役割に使うべきか」を6軸で評価する研究です。論理的推理、戦略的多様性、戦略的品質、ペルソナ可塑性、ペルソナ耐性、表現多様性といった観点からLLMの傾向をプロファイリングし、入力・思考・出力の各フェーズに適したモデルを選択する枠組みを提案していました。

近年はLLMのベンチマークも複数存在していますが、実際のプロダクト開発では、総合スコアが高いモデルを選べばよいとは限りません。(ベンチマークでは良くても、実務で使ってみたら、あんまりという経験を何回かしました…) 創作、業務支援、コーディング、対話エージェントなど、文脈によって求められる性質は大きく変わります。その意味で、LLMを「能力」だけでなく「傾向」として捉え、役割ごとに使い分けるという発想は興味をひきました。

特に面白かったのは、人狼ゲームを用いて評価していた点です。調べてみると、身近なゲームが研究での利用で割とスタンダードになっており、興味深かったです。(強化学習文脈だとAI Marioとかもありましたね) 人狼では、矛盾を見抜く力や戦略を立てる力だけでなく、ペルソナを保ったまま発話し続ける力も重要になります。普段LLMを使う中で「ペルソナをどれだけ維持できるか」はあまり意識していなかったため、新しい評価観点として印象に残りました。この観点は、LLM-as-a-Judgeにおける評価バイアスや、モデルごとの振る舞いの違いを考える上でも重要になりそうです。

一方で、この6軸やその他の評価指標を組み合わせることで、本当に最終的に実現したい成果につながるのかは検証してみたいポイントです。評価軸は文脈によって変わるはずなので、業務支援、コーディング、創作、分析エージェントなどのタスクごとに、どの軸が実際の品質やユーザー体験に効いてくるのかを見てみたいと感じました。

逆混合整数計画法: 制約条件学習からの目的関数学習(数理最適化セッション)

混合整数計画問題(MILP)において、目的関数と制約式の両方をデータから学習し、観測された解を再現できるようなパラメータを推定する研究です。逆最適化は、専門家が実際に下した意思決定を観測し、その裏側にある目的関数と制約式を逆算して復元する枠組みです。

特に面白いと感じたのは、この問題を実務で使える形に落とし込んでいる点です。提案手法は2段階で構成されています。まず①制約式を学習し、観測された解が実行可能なまま制約を可能な限りタイトに引き締めるパラメータを求めます。次に②その制約を固定したうえで、劣最適性損失を誤差関数として目的関数の重みを学習します。「制約を先に、目的を後で」と切り分けることで、本来は計算的に難しいMILPの同時学習を効率よく解けるようにしているのが巧みだと感じました。実際決定変数100個規模ではあるものの、スケジューリング問題を平均325秒程度で解けており、実用的なスケールを示されていました。

ラクスルでも、現場のオペレーションに「明文化されていないが、熟練者が経験的に守っているルール」がまだまだあります。今後の業務にも活用できる可能性があると感じました。

PLaMo Translate: PFNの開発する翻訳特化大規模言語モデル(AI応用:マーケティングと推薦セッション)

PFNが開発する、翻訳に特化した大規模言語モデルに関する発表です。私自身も普段からよく使っている翻訳モデルなのですが、わかりやすい自然な日本語に翻訳してくれることが多く、その裏側の仕組みが知れて面白かったです。

作り方としては、事前学習を終えたLLMに対して、翻訳に特化したファインチューニングを行っています。ここで使われているのがDPO(Direct Preference Optimization)という手法で、「良い翻訳」と「悪い翻訳」のペアを大量に用意し、その違いをモデルに学習させます。とはいえ、このペアを人手ですべて用意するのは難しいため、訳文の良し悪しを判定するjudgeモデルを別に作り、事前学習済みモデルに作らせた100パターンの訳文をjudgeモデルでランキングすることで、学習データを自動的に揃えているのが工夫されている点でした。結果として、日英・英日のどちらでもGoogleの翻訳モデルを上回る性能を出したと報告されていました。一方で、原文にない略語などを勝手に補ってハルシネーションを起こす課題もあり、現在準備中のPLaMo 3では、judgeモデルの改善やGRPO(強化学習の手法)の追加でこの問題に取り組んでいるそうです。

面白かったのは、その自然な翻訳がどう実現されているかという点です。単に良い訳例だけを覚えさせるのではなく、良い例と悪い例を見比べさせて、その差を縮めていくコントラスト学習的なアプローチで品質を高めているとわかり、納得感があって興味深かったです。

おわりに

JSAI2026に参加して、AI研究と実務開発の距離はますます近づいていると感じました。 一方で、研究で得られた知見を実際のプロダクトや業務に活かすためには、単に最新技術を追うだけではなく、自分たちの課題に引きつけて考えることが重要だと感じました。 今後もデータ戦略部では、学会や論文から得られる知見を継続的にキャッチアップしながら、事業やユーザー体験の改善につながる形でAI技術を活用していきたいです。 最後までお読みいただき、ありがとうございました。

JSAI2026 – 2026年度 人工知能学会全国大会(第40回)発表報告

はじめに

こんにちは。ラクスルのデータ戦略部でデータサイエンティストを務めている野中です。 2026年6月8日〜12日に開催された「JSAI2026 – 2026年度 人工知能学会全国大会(第40回)」に参加し、ラクスルのデータ戦略部として発表を行いました。 本記事では、発表内容の概要と、人工知能学会全国大会(JSAI2026)に参加して感じたことについてご紹介します。

群馬県の高崎にあるGメッセ群馬で行われました

JSAI2026とは

JSAI2026(2026年度 人工知能学会全国大会 第40回)は、一般社団法人 人工知能学会が主催する国内最大規模のAI関連学会です。 大学・研究機関・企業など幅広い参加者が集まり、機械学習、画像処理・自然言語処理、生成AI、マルチモーダルAIなど、多様なテーマについて研究発表や議論が行われます。 近年は、研究領域だけでなく実サービスへのAI活用/LLM活用・AIエージェント・業務改善など実践寄りのテーマも増えており、産学双方から大きな注目を集めています。 2026年度大会も、現地・オンラインのハイブリッド形式で開催され、多くの研究者・エンジニア・企業関係者が参加しました。

発表セッションとテーマ

本セッションでは、実企業で得られたデータを活用し、マーケティング上の課題解決に向けて統計・機械学習による予測を行う研究が数多く発表されました。 我々が取り組んだのは、各顧客のLTV(顧客生涯価値)を予測するというマーケティング上の重要な課題です。一般に、事前に顧客ごとのLTVを推定できれば、LTVの高い顧客に対して重点的にマーケティング投資を行うことができ、施策全体の収益性向上にもつながります。このテーマは、ラクスルが日々向き合っているマーケティング上の課題とも重なるものであり、産業現場における実課題と学術研究をつなぐという観点でも意義のあるテーマだと考えています。

LTVを予測するためには、まず各顧客の将来の購買回数を予測する必要があります。その代表的な手法が BTYD(Buy Till You Die)モデル と呼ばれる一群のモデルです。なかでも、 BG/NBDモデルとGamma-Gammaモデルを組み合わせた手法は広く利用されています。我々の発表は2件ともこのモデルを前提とした分析や手法改良の提案を行なっています。

B2Bプラットフォームにおける法人単位LTV予測

こちらは弊チームの磯と筒井の共著によるものです。本研究では、弊社の購買プラットフォームを対象に、BTYDモデル(BG/NBD・Gamma-Gamma)による法人単位のLTV予測に取り組みました。 まず背景として、従来のBTYD研究の多くはB2C(個人向け)を対象としており、B2B(法人向け)への適用は限定的でした。B2Bには固有の難しさがあります。BTYDモデルは本来一人の顧客に対して、1つのポアソン過程を仮定し個人の購買行動をモデル化する手法です。法人には複数のユーザーが所属するため、あるユーザー個人では離反したように見えても、別のユーザーが購買を続けていて法人としては取引が継続しているという事象が起こります。このとき法人単位のLTVを予測するうえでモデルをどの粒度で当てはめるべきかが自明ではなく、各ユーザーを独立顧客として適用し法人に足し上げる「個人粒度アプローチ(アプローチA)」と、法人内の全ユーザーの購買を1つの主体に統合して直接適用する「法人粒度アプローチ(アプローチB)」の2通りが考えられます。

そこで本研究では、この2つのアプローチによる法人LTVの予測精度を実データで比較検証し、B2B事業におけるBTYDモデルの適用可能性を明らかにすることを目的としました。具体的には、次の2つのリサーチクエスチョンを設定しています。RQ1は「個人粒度アプローチと法人粒度アプローチで、法人LTVの予測精度に差はあるか」、RQ2は「その精度差は、法人の所属ユーザー数やユーザーの購買頻度特性によってどう変化するか」です。結果及び考察に関しては、リンク先論文PDFをご参照ください。

商品カテゴリ別の購買回数予測のための階層ベイズBG/NBDモデル

こちらの研究は、私が単著で発表いたしました。本研究では、多様な商材を扱うラクスルのようなECサイトを対象に、「商品カテゴリごとの将来購買回数を予測する」という課題設定のもと、BG/NBDモデルの適用を考えました。BG/NBDモデルによる商品カテゴリごとの将来購買回数の予測には、大きく2つの課題があります。

まず第一に、チラシとのぼりを例に挙げても、カテゴリによって購買パターンは大きく異なります。チラシは、日常業務で利用されるため、毎月あるいは隔週で継続的に購入するユーザーが多く存在します。一方で、のぼりは店舗リニューアルなど特定のタイミングで購入されることが多く、需要構造が異なります。こうした違いを適切に表現するためには、カテゴリごとに異なるパラメータを持たせる必要があります。 第二の課題として、ECサイトの商品カテゴリ別の購買数は、典型的な ロングテール(裾の重い分布) を示します。一部の主力カテゴリには多くの購入者が存在する一方で、大半のカテゴリでは購入者数が限られています。このようなデータが少ないカテゴリでは、パラメータ推定が不安定りやすく、たまたま含まれた少数の特徴的な顧客の影響を強く受けてしまうため、予測精度が低下するという問題があります。

そこで本発表では、これらの課題を解決するためにBG/NBDモデルを階層ベイズモデルへと拡張し、カテゴリごとの購買行動の違いを捉えつつ、データの少ないカテゴリにおいて予測精度を安定化させることを目指しました。より技術的な詳細に関しては、リンク先論文PDFを参照いただければ幸いです。

おわりに

今回のJSAI2026への参加を通じて、AI活用に関するさまざまな知見や刺激を得ることができ、非常に有意義な機会となりました。 ラクスルとしても、今後もAIやデータ活用に関する研究・発信へ継続的に取り組んでいきたいと考えています。最後までお読みいただき、ありがとうございました。

【RubyKaigi 2026】『Faster Bundler, Happier Developers』振り返り — 実プロダクトで bundle install を計測してみた

はじめに

こんにちは、ラクスルのエンタープライズ事業部でエンジニアをしているマナティです。

RubyKaigiは2025年が初参加で、今回が2回目になります。函館は食べ物も美味しく、桜が綺麗で非常に楽しかったです!!

このブログでは、RubyKaigi 2026で発表された『Faster Bundler, Happier Developers』の内容を振り返りながら、実際のプロダクトでどれだけ速くなったかを計測してみます。

bundle installが遅い

bundle installを実行すると、思ったより時間がかかると感じたことはないでしょうか。登壇者の環境では、125個のgemで36MBのデータを持つ新規Railsアプリで、bundle installに30秒以上かかっていたとのことです。

36MBというのは、普通のインターネット接続なら2秒程度でダウンロードできる量です。なぜ30秒もかかるのでしょうか?

Pythonコミュニティではuvというパッケージマネージャーが登場し、高速なインストールが実現されています。これを受けて「BundlerやRubyGemsも、もっと速くできないか?」というモチベーションでこの改善が始まりました。

Bundlerとは

Bundlerはプロジェクトの依存関係を管理するパッケージマネージャーです。主に3つの役割を担っています。

  1. 依存関係の解決
  2. 解決したGemとそのバージョンをダウンロード
  3. インストール

RubyGemsと混同されやすいですが、RubyGemsはgemのインストールツールのことです。BundlerはRubyGemsの仕組みを内部で使っており、現在はRubyGemsリポジトリの中にBundlerが統合されています。

bundle installの処理の流れ

bundle installを実行すると、内部では以下の処理が行われます。

1. Gemfileの評価

まず、Gemfileを読み込み、直接依存(Direct Dependency)のGemとバージョン制約をメモします。

# Gemfile
gem 'rails', '7.1.4'# bundler 内部で依存関係をメモ
add_dependency("rails", ["7.1.4"], {})

2. gemspecを取得

依存関係の解決のために、「どのGemのどのバージョンが、何に依存しているのか」というメタデータが必要です。 そのメタデータはgemspecファイルに記載されており、以下のような内容となっています。例)sidekiq gem v.8.1.5(GitHub

# 例:sidekiq.gemspec
Gem::Specification.new do |gem|
  # gemの名前
  gem.name = "sidekiq"

  # バージョン
  gem.version = Sidekiq::VERSION

  # 必要なRubyバージョン
  gem.required_ruby_version = ">= 3.2.0"

  # gemが依存しているgemとバージョン制約
  gem.add_dependency "redis-client", ">= 0.29.0"
end

gemspecを取得するGemは2種類あります。

  • Direct Dependency(直接依存): Gemfileに書かれたGem
  • Transitive Dependency(推移依存): 直接依存のGemが必要としているGem。gemspecのadd_dependencyに記載されている。
rails 7.1.4           # 直接依存
  ├─ actionpack       # 推移依存
  └─ activerecord     # 推移依存
       └─ activemodel # 推移依存の推移依存

ここでは、Gemfileに記載された直接依存のGemのgemspecを取得します。 推移依存のGemは、解決を進めながら必要になったタイミングでgemspecが取得されます。

gemspecの取得方法は、以下の表のようにGemのソースによって異なります。 Git gemのみ、APIではなくリポジトリを直接cloneしてgemspecを取得します。

ソース 取得先
rubygems.org Compact Index API
プライベートのGem(GitHub Packagesなど) そのサーバのCompact Index API
Git gem(git@github.com:のもの) git cloneし、.gemspecを読む

3. 依存関係の解決

集めたGemのメタデータをPubGrubアルゴリズムのソルバーに渡して、インストールすべきGemのバージョンを決定します。 PubGrubは、パッケージの依存関係の解決に特化したRust製のライブラリです。

gemのバージョンを1つ1つ仮で決めながら、全てのバージョン要求を満たすかバージョン比較しながら検証していきます。 バージョン要求を満たさなかった場合は、戻って別のバージョンを試していくことで、全てのgemのバージョン要求を満たす組み合わせを見つけます。

そして、解決した結果をGemfile.lockに書き込みます。

詳細なアルゴリズムの説明は、PubGrubの作者であるNatalie Weizenbaumさんのブログがわかりやすいです。 https://nex3.medium.com/pubgrub-2fb6470504f

4. ダウンロード

依存関係が解決したら、ワーカースレッドを立ち上げ、.gemファイルをダウンロードします。 .gemファイルの中に、gemの実体やメタデータ情報、チェックサムなどが入っています。

次に、.gemファイルを展開し、Rubyのgemインストールディレクトリにコピーします。 この時、Cネイティブ拡張を持つGemの場合、コンパイルします。

Bundlerやbundle installの内部処理については、RubyKaigi 2023でHiroshi SHIBATAさん(@hsbt)が発表した『How resolve Gem dependencies in your code?』が参考になりました。

ボトルネックと改善

1. バージョン比較のsort keyを改善

PubGrubでは仮のバージョンを決め、そのバージョンで問題がないかを試し、だめであれば別のバージョンを試すということを行うため、バージョン比較が大量に行われます。 また、そのバージョン比較がGem::Versionの<=>演算子を使用しており、ループや条件分岐が複数ありました。

Shopifyのアプリケーションでは、バージョン比較が1400万回呼ばれていたため、時間がかかっていました。

改善:Gemのバージョンオブジェクトを生成する際に、整数の安定ソートキー(Stable Sort Key)を作成することで、整数同士でバージョン比較を行うようにした

結果:バージョン比較が5倍高速化

2. Git gemのダウンロードを並列化

Git gemはgit cloneをしてgemspecを取得する必要があります。 以前は、このcloneが直列で行われていたため、複数のGit gemがある場合に時間がかかっていました。

改善:git cloneを並列化

結果:Git gemのダウンロードが10〜12秒 → 2秒に短縮され、約5倍高速化

3. HTTPコネクションプールの拡張

Bundlerは複数スレッドを立ち上げ、複数ワーカがgemのダウンロード・インストールを行っています。

しかし、複数ワーカーがいるにもかかわらず、HTTPコネクションプールが1本しかなく、全ワーカーが奪い合っていました。 1ワーカーが接続している間、他のワーカーは待機するしかない状態でした。

改善:BUNDLE_JOBSの数に合わせてプール接続を増やす

4. Gemインストールの並列化

以前は、gemを依存関係の順にダウンロードしており、依存があるgemは前のgemのインストール完了を待つ必要がありました。 そのため、実質直列でのインストールとなっていました。

改善:Cネイティブ拡張を持たないgemは依存を気にすることなく、並列してインストールする。Cネイティブ拡張を持たない純粋なRubyで書かれたGemの場合、gemファイルをインストールするだけで良く、依存関係などの考慮はアプリケーションの実行時に行われるためbundle installで行う必要がないため。

一方で、Cネイティブ拡張を持つGemは引き続き依存があるGemは直列でインストールする必要があります。 理由は、Cネイティブ拡張を持つGemでは、CコードをRubyから呼べるようにextconf.rbというファイルをコンパイルします。その際、requireで依存したGemがある場合、依存したGemがインストールされていないとエラーになるからです。

5. global gem cache

※ 登壇者の改善ではなく、RubyGemsコミュニティによる改善

以前は、Gemをダウンロードした時に、Rubyバージョンごとにフォルダが分かれて.gemファイルが置かれてしまい、Rubyバージョンを上げると同じGemを再ダウンロードする必要がありました。

.bundle/ruby/3.3.0/actionview-7.0.8.4.gem
.bundle/ruby/4.0.0/actionview-7.0.8.4.gem  # 同じファイルなのに再DL

改善:Rubyバージョンを問わず、共有できるglobal gem cacheを導入。Rubyバージョンが異なってもGemのキャッシュが効くようになった。

現在はデフォルトが無効のopt-in機能ですが、次のRubyGemsのメジャーリリースでデフォルト有効になる予定です。

ベンチマーク結果

登壇者は bundler-perf-toolkit を用いて計測した結果、以下の結果となり大きく高速化がされました。

シナリオ 結果
直接依存249個、ネイティブ拡張なし 37%高速化
RubyのGemfile 2.6倍速
Git gem 40個 6倍速(2秒未満に)
rails newしたRailsアプリ 2倍速(20秒→10秒)

これらの改善は全て Bundler & RubyGems 4.0.10 で利用できます。

さらなる高速化のために

さらにbundle installを高速化するための最大のボトルネックはCネイティブ拡張のコンパイルです。 Cネイティブ拡張のGemはコンパイルが必要で、Rubyは本質的にコンパイルが遅いため、どうしても時間がかかってしまいます。

解決策は、precompiled gem(事前にコンパイル済みのgem)です。 nokogiriやsqlite3、ffiはこれに対応しています。

しかし、コンパイル済みにするには、全てのプラットフォーム・バージョンごとにコンパイルする必要があります。クロスコンパイルとしてrake-compiler-dockがありますが、デバッグや保守のしづらさが課題となっています。

RubyKaigi 2025でも、Sutou Kouheiさん(@ktou)による発表でCネイティブ拡張のgemのメンテナンスが辛いという話がありました。Goodbye fat gem 2025

その解決策として、登壇者は cibuildgem というGemを作成し、紹介していました。 cibuildgemを使うと、ネイティブにGemをコンパイルし、compiled gemとして公開できます。

  1. CIプロバイダー上でマシンを立ち上げる(macOS / Windows / Linux / ARM64)
  2. ターゲットのプラットフォーム上でネイティブにコンパイルする
  3. コンパイルしたバイナリでテストを実行
  4. precompiled gemとしてRubyGems.orgにリリース(trusted publishing)

登壇者が全gemをprecompile済みにしたRailsアプリを試したところ、20秒 → 3.8秒 になったとのことです。

実際のプロダクトで試してみた

ここまで、bundle installの処理の流れとどういう高速化の改善がされたのかを説明しました。 この改善が実際のプロダクトにどれほど影響を与えたのか、開発に携わっているRailsアプリケーションで実際に試してみました。

Railsアプリケーションの構成

項目
gem総数 275個
直接依存 87個
推移依存 188個
Git gem 5個
Cネイティブ拡張gem(precompiled gemを除く) 22個
precompiled gem 3個(nokogiri, ffi, google-protobuf)
Rubyバージョン 3.3.10
gemの取得元 ・rubygems.org(252個)
・GitHub Packages(3個)

比較するバージョン

セッションで紹介された改善は、4.0.3〜4.0.10にかけて導入されました。4.0.2はこれら全ての改善が入る直前のバージョンです。

そのため、改善前のバージョンとして4.0.2、改善後のバージョンとして4.0.10を比較することにしました。

改善内容 導入バージョン
HTTPコネクションプール拡張 4.0.3
Git clone並列化 4.0.9
並列インストール 4.0.9
stable sort key 4.0.10

計測手法

ベンチマークツールは hyperfine を使用しました。 複数回実行して、平均・標準偏差・最小/最大を出力してくれるCLIツールです。

hyperfine \
  --runs 5 \
  --prepare 'rm -rf vendor/bundle' \
  --export-markdown benchmark_result.md \
  'BUNDLE_IGNORE_BUNDLER_VERSION=true bundle _4.0.2_ install' \
  'BUNDLE_IGNORE_BUNDLER_VERSION=true bundle _4.0.10_ install'

結果

ベンチマーク結果

平均時間 標準偏差
Bundler 4.0.2 113.3秒 ±3.4秒
Bundler 4.0.10 88.7秒 ±1.6秒

結果、4.0.10は4.0.2より約1.28倍(25秒)速くなりました。

また、標準偏差が4.0.10の方が小さくなっています。 これは並列インストールによって、個々の処理のばらつきが平均化されたためだと考えられます。

まとめ

Bundlerの処理の流れと高速化の内容を振り返り、業務アプリで Bundler 4.0.10 にアップグレードしたところ、bundle install が113秒から89秒へ短縮され、約1.28倍速くなることを確認しました。

BundlerやRubyGemsのバージョンアップは後回しにしがちでしたが、CI/CDやDocker buildでも bundle install は頻繁に実行されるため、積み重なって効いてきそうな改善だと思いました。

さらなる高速化のためには、Cネイティブ拡張のコンパイルが依然としてボトルネックとなるようです。 これは、昨年のRubyKaigi 2025でも、Sutou Kouheiさん(@ktou)による『Goodbye fat gem 2025』で触れられた課題感とも通じる話で、2年連続でRubyKaigiを通じてエコシステムの動きが見えてきたのが非常に興味深かったです。

型破りな未来へテイクオフ 〜TSKaigi 2026に参加しています〜

こんにちは、ラクスル事業部 Web エンジニアの長澤、酒井です。

私たちは今、5/22(金)・23(土)の2日間にわたって開催される「TSKaigi 2026」に来ています!

ラクスルでは、祖業である印刷EC「ラクスル」だけでなく、日々非常に多くの多様なサービスを開発・運営しています。そして、それらのプロダクトの多くで、フロントエンドを中心にTypeScriptが標準技術として深く根付いています。

私たちラクスルのエンジニアの多くが、日々の開発においてTypeScriptがもたらす堅牢性や開発スピードの恩恵を大いに受けており、私たちもその中の1人です。だからこそ、世界最大規模となった今回のTypeScriptの祭典にリアル参加できることを、楽しみにしていました!

本記事では、速報として熱気あふれる現地の空気感と、私たちラクスルメンバーがどのような視点を持って今回のTSKaigiに臨んでいるのかをリアルタイムにご紹介します!

はじめに:TSKaigiとは

TSKaigiは、プログラミング言語・TypeScriptに関するあらゆるテーマを扱う、国内最大級のテックカンファレンスです。 3回目の開催となる今年のミッションは、『学び、繋がり、“型”を破ろう』

単に誰かの発表を聴くだけでなく、関わるすべての人たちが互いに学び合い、新たな繋がりを生み出すことで、既存の「型」にとらわれないエンジニアとして生き生きと活躍できる世界を目指しています。日本の、そして世界のTypeScriptの未来を切り拓く「型破り」なイベントです。

今回は簡単に現地の雰囲気と、ラクスルメンバーが何を期待して TSKaigi 2026 に参加しているかをお伝えできればと思います!

現地の様子

今年の会場は、羽田空港第3ターミナル直結の「羽田エアポートガーデン」内にある、ベルサール羽田空港です!

空港の到着ロビーから連絡通路を渡ってすぐ会場にアクセスできるのですが、空港ならではの旅立ちのワクワク感を感じながら会場に向かいました。会場に足を踏み入れると、そんな雰囲気とは一転してTSKaigiならではの熱気に包まれていました。

今回のTSKaigi 2026は、現地参加者が1,000人規模。オフラインとしては、世界最大のTypeScriptカンファレンスとなるそうです!(オープニングトークで代表の方が言っていました)

注目しているセッション

そんな、熱気あふれるTSKaigi 2026ですが、ラクスルメンバーが期待しているセッションを紹介します!

長澤

  • アンチパターンを避ける型駆動React最適化(Kazuya Serizawa)
    • 私が所属している開発チームではNext.jsを使用しており、現在React Compilerの導入を計画中です。アプリケーションコードをどのように記述すると最適化されやすいのか、それをTSの型システムなどの仕組みによって、どのように維持すべきなのかについて学べたらと思います。
  • ビジネスモデルから紐解く、AI+型駆動開発(omote)
    • 仕様やドメインを型で表現するということを意識し日々の開発を行っていますが、複雑なドメインを扱う場合などでは難しいことがあります。型駆動開発をどのように捉えて設計の意思決定を行っているのかについて知見を得られればと思います。

酒井

  • 業務に残された「よくない型」で考える「TypeScriptの難しさ」(Saji)
    • 私が普段携わっている印刷EC「ラクスル」はラクスルの中でも特に大規模かつ歴史あるコードベースであり、やむを得ずts-ignoreなどの妥協を迫られるケースもよくあります。そうした環境下において少しでも型安全なコードを書くためのヒントを得られればと思います。
  • Stage 3 Decorators でできること / できないこと(susisu)
    • 数年前にGoogle Apps Scriptでスプレッドシートに対するCRUDを書けるORMパッケージを個人的に開発したことがあり、その際にTypeORMのような書き方を目指して当時既に実装されていたStage 3 Decoratorsを採用しました。そうした経験から今回改めてデコレーターについて学べればと思います。

おわりに

現在1日目の真っ最中ですが、この後も気になるセッションが盛りだくさんです。最後まで楽しみ、多くの学びを持ち帰りたいと思います!

【RubyKaigi 2026】「Ruby Releases Ruby」セッションレポート ― リリースを支える自動化の設計思想

ラクスル事業部 Web エンジニアの森田です。 RubyKaigi 2026 のうち、参加前から特に楽しみにしていた「Ruby Releases Ruby」セッションについてご紹介します。

かつて Ruby のリリースは重い作業でしたが、さまざまな取り組みを経て、2022年には9回だったリリースが2025年には14回まで増えています。このセッションでは、その裏側にある自動化の設計思想と具体的な事例が紹介されました。

本記事では、セッションの内容をベースに紹介されたスクリプトやワークフローを実際に調査し、読み取った設計の意図も含めながら、特に印象に残った3つの事例を取り上げます。


リリース高速化のためのワークフロー設計

リリースを高速化するにあたって、まず「何を人間がやり、何を自動化するか」を定義することから始まったと紹介されていました。

人間がやることの例 - ビルドパターンの決定 - タグを打つタイミング・アナウンス・公開のタイミング判断

自動化することの例 - リリースノートの生成 - Docker イメージ作成など

事例1. ビルドの自動実行と可視化

Ruby のビルドやテストには、GitHub Actions(out-source)と chkbuild(in-source)の2種類のCI環境が使われています。

この2つは単なる冗長構成ではなく、それぞれ「コミットごとの組み合わせ爆発を並列処理する」、「クラウドでは再現できない実機互換性を担保する」という独立した役割を担っています。

out-source CI:GitHub Actions

OS × コンパイラ × ビルドオプションの膨大な組み合わせ(約120ジョブ)を並列で網羅しています。OS だけでなく実行環境のレイヤまで含めた組み合わせも対象で、例えば「Ubuntu on WSL」専用のワークフロー(wsl.yml)も存在します。

バリエーション例
OS / OS バージョン Ubuntu 22.04, Ubuntu 24.04, macOS 14, macOS 15, Windows 2022
コンパイラ GCC, Clang, MSVC
ビルドオプション YJIT有効, YJIT無効, デバッグフラグ有効
プロセスモデル 32bit, 64bit, 共有ライブラリ有効(--enable-shared

in-source CI:chkbuild

chkbuild は cron で定期実行されており、Amazon Linux・macOS・OpenBSD・Android・s390x・riscv64 など、多種多様な実機・OS環境でのビルドを担います。結果は rubyci.org に集約されており、前回ビルドとの差分やコミットハッシュとの紐付けまで整形されているため、コアメンテナが分散した環境の状態を1画面で追えます。


事例2. リリースノートの自動生成

リリースノートの生成には tool/gen-github-release.rb が使われています。前タグ〜今タグ間のコミットを取得し、各コミットメッセージを2パターンでスキャンします。

  • [Backport/Feature/Bug #1234]bugs.ruby-lang.org からタイトルをスクレイプ
  • (#1234) → GitHub PR ページからタイトルをスクレイプ

重複除去して箇条書きに整形し、GitHub Release を作成します。実際のリリースノートはこちらで確認できます。

AI や複雑な判定ロジックは使っておらず、実装は正規表現によるスキャンとスクレイピングのみです。

また、コミットメッセージをそのまま転記するのではなく、チケット番号をインデックスとして外部トラッカーからタイトルを取得するため、何度リトライコミットが打たれていても、リリースノートに集約されるのはチケット単位の1行のみです。


事例3. RubyGems / Bundler のバックポート自動化

RubyGems / Bundler は CRuby とは独立したリポジトリで管理されており、Ruby 本体より一歩進んだリリース自動化が実現されています。tool/release.rb が cherry-pick からリリース PR 作成まで一連の作業を自動化しています。

master でマージされたコミットを、リリース時にまとめて stable ブランチへ cherry-pick するバックポート方式をとっています。スクリプトは以下を自動で行います。

  1. 前回リリースタグを起点に master の未リリースコミットから対象 PR を特定
  2. 各 PR のマージ戦略(Merge commit / Squash / Rebase)を判定し、適切な引数で git cherry-pick を実行
  3. CHANGELOG 生成・バージョンバンプ・コミット
  4. stable ブランチへのリリース PR(#9554)と、master への CHANGELOG 書き戻し PR(#9555)を同時に作成

4番目の「書き戻し PR の同時生成」が設計上のポイントとみられます。一般的なリリースフローでは stable 側で CHANGELOG を確定した後、人間が手動で master へマージします。その間に master 側で開発が進むと、同じファイルの同じ箇所でコンフリクトが発生します。一方このスクリプトは、リリースと同時に書き戻し PR を生成することで、両ブランチの乖離時間をゼロにし、コンフリクトを構造的に防いでいます。


感想

今回の事例の中では、特に事例1のビルドシステムの設計が印象に残りました。

エッジな CPU アーキテクチャ・特殊な OS 環境を網羅した CI 環境を20年以上前から維持し続けている点はもちろん、GitHub Actions(out-source)では可視化の仕組みが標準で備わっているのに対し、chkbuild(in-source)側でもコミットハッシュへのリンクや差分を含む独自の可視化を整備している点が印象的でした。どちらの環境でも「何がどのコミットで壊れたか」を追える状態を維持していることになります。 一方で効果的なビルドマトリクスの選定や構成管理はメンテナーの判断に委ねられており、その設計方針の背景や意思決定プロセスも気になるところです。

また一連の事例を通じて、単にすべてを自動化するのではなく、何を自動化し何を人間が決定するかをあらかじめ定義してからワークフローを設計することの大切さを実感しました。このアプローチは、昨今の AI 活用や効率的な開発プロセスを考える上でも、そのまま役立つ考え方だと感じています。