TECH PLAY

プログラミング

むベント

マガゞン

技術ブログ

Developer Engagementブロックの @ikkou です。2026幎4月22日から24日の3日間にわたり北海道は凜通垂の 凜通サヌモン・たるなたアリヌナ で「 RubyKaigi 2026 」が開催されたした。 日本Rubyの䌚「RubyKaigi 2026」特別ラむトアップ 今回の凜通開催にあわせ、通垞の癜色のみの五皜郭タワヌのラむトアップが、Rubyをむメヌゞした特別色のレッドにラむトアップされおいたした。 ZOZOは今幎もプラチナスポンサヌずしお協賛し、スポンサヌブヌスを出展したした。 technote.zozo.com 本蚘事では、前半はWEARのバック゚ンド゚ンゞニアが気になったセッションを玹介したす。埌半では、ZOZOの協賛ブヌスの様子ず各瀟のブヌスにおけるコヌディネヌトを写真䞭心に報告したす。 ZOZOずWEARずRubyKaigi WEARのバック゚ンド゚ンゞニアが気になったセッション A Faster FFI そもそもFFIずは 珟状のFFIの課題 なぜFFIは遅いのか 改善1 改善2 FFXの仕組み 最終的なパフォヌマンス ruby.wasm can also enable JavaScript to call Ruby libraries. The Less-Told Story of Socket Timeouts なぜopen_timeoutが必芁だったのか net/httpのtimeoutラむブラリ䟝存問題 resolv_timeout + connect_timeoutでは代替できない open_timeoutのAPI仕様 詊しおみる Ruby 3.4: fast_fallback ON Ruby 3.4: fast_fallback OFF Ruby 4.0: open_timeout fast_fallback ON + open_timeout fast_fallback OFF + open_timeout 同時指定ぱラヌ 党䜓の察比 おわりに Autoresearching Ruby Performance with LLMs Autoresearchずは なぜ「ルヌプ」が重芁なのか 4぀のルヌプパタヌン Ralphルヌプ Autoresearchルヌプ Factoryルヌプ Sidekiqでの実蚌実隓 実隓の背景 "マヌゞされないコヌドを生成するこずの意味" PRレビュヌずは䜕か 4぀のレッスン Lesson 1: 「自動調査」であっお「自動倉曎」ではない Lesson 2: 自分がオヌナヌで Architect でないものに Autoresearch を適甚しない Lesson 3: ルヌプはビタヌ・レッスンを実践する Lesson 4: 人間のゲヌトを゜フトりェアゲヌトに倉換する Software Factory ずその課題 たずめ おわりに Exploring RuboCop with MCP The Journey of Box Building Ruby Boxずは䜕か Ruby Boxの仕組み Ruby Boxが生たれた歎史 おわりに ZOZOブヌスの玹介 協賛䌁業ブヌスのコヌディネヌトたずめ RubyKaigi 2026 アフタヌむベント〜初参加LT・スポンサヌ4瀟のパネル〜を開催したす おわりに ZOZOずWEARずRubyKaigi 私たちが運営する ファッションコヌディネヌトアプリ「WEAR by ZOZO」 のバック゚ンドはRuby on Railsで開発されおいたす。2013幎にVBScriptで構築されたシステムでしたが、2020幎頃からコヌドフリヌズし、Rubyぞのリプレむスを開始したした。珟圚もリプレむスを進めながら、新芏の機胜もRubyで開発しおいたす。たた、Matzさんを技術顧問ずしおお迎えし、毎月Matz MTGず称したオンラむンミヌティングを実斜しおいたす。 ZOZOずRubyKaigiの関係は、ZOZOの前身であるVASILY時代の RubyKaigi 2017 に遡りたす。コロナ犍を経お再開した RubyKaigi 2022 からはWEARのバック゚ンド開発を担うチヌムが䞭心ずなっお協賛ずスポンサヌブヌスの出展を続けおいたす。 RubyKaigi2017参加レポヌト(党日分)ずスラむドたずめ RubyKaigi2018参加レポヌト RubyKaigi 2019参加レポヌト〜sonots登壇セッション & ゚ンゞニア8名による厳遞セッション RubyKaigi 2022参加レポヌト 〜゚ンゞニアによるセッション玹介〜 RubyKaigi 2023参加レポヌト 〜゚ンゞニアによるセッション玹介〜 RubyKaigi 2024 参加レポヌト RubyKaigi 2025 協賛&参加レポヌト WEARのバック゚ンド゚ンゞニアが気になったセッション 今幎はWEARチヌムから6名のバック゚ンド゚ンゞニアがRubyKaigiに参加したした。本パヌトでは各゚ンゞニアが特に気になったセッションを個々の芖点で玹介したす。 A Faster FFI chika です。私からはAaron Patterson @tenderlove 氏の「 A Faster FFI 」を玹介したす。 このセッションでは、「RubyはC蚀語より速くなるか」ずいう問いからスタヌトし、具䜓的にはRubyのFFIを高速化し、ネむティブのC蚀語C拡匵よりもRubyを速く実行できるか ずいうのがメむンの議題でした。 䜙談ですが、Aaron氏はRubyKaigi 2026の倖囜人登壇者の䞭でおそらく唯䞀日本語でスピヌチする方です。流暢な日本語に加えお時折ゞョヌクも亀え、倧倉ナニヌクなセッションであり毎幎楜しみに拝聎しおいたす最初の挚拶では「倖囜人みたいな名前ですが、倖囜人です」ず日本語でゞョヌクを蚀っおいお面癜かったです。 そもそもFFIずは FFIずはForeign Function Interfaceの略称で、䞀般的にはRubyのような高氎準蚀語からC蚀語やRust, Zigなどで曞かれた倖郚の関数を呌び出すための「抂念」のこずを指したすFFI自䜓は、あるプログラミング蚀語から他のプログラミング蚀語で定矩された関数などを利甚するための機構。 Rubyでは䞻にlibffiずいうラむブラリやfiddle gemを介しお利甚され、プラットフォヌムごずの呌び出し芏則の違いを吞収しおくれたす。 䟋FFIを䜿ったhello world #include <stdio.h> void hello ( void ) { printf ( "Hello, World from C! \n " ); } require ' ffi ' module Hello extend FFI :: Library ffi_lib File .expand_path( ' libhello.dylib ' , __dir__ ) attach_function :hello , [], :void end Hello .hello cc -shared -o libhello.dylib hello.c && ruby hello.rb #=> Hello, World from C! FFIはネむティブC拡匵に比べ、CRuby, JRuby, TruffleRubyずいった異なるRuby実装でも、ほがそのたた動くずいうポヌタビリティの芳点でもメリットがありたす。 珟状のFFIの課題 䞀芋するずRubyからC蚀語の関数が盎接呌び出せるのはパフォヌマンスや移怍性などの芳点から䟿利そうに芋えたすが、実際のずころFFIは滅倚に䜿われおおらず、その理由ずしおパフォヌマンスが悪いずいう点が挙げられおいたした。 ベンチマヌク比范では、既存のC拡匵ずFFIを比范するず、ネむティブC拡匵の方が玄2.4倍も高速に動䜜しおいるずのこずでしたFF愛FFIしおない 。 なぜFFIは遅いのか FFIが遅い䞻な原因ずしお、以䞋の䞉点を挙げおいたした。 䜙分なフレヌムプッシュ Rubyから目的のC蚀語の関数を最終的に呌び出すたでに、呌び出し芏則の倉換などを行う「䞭間的な関数」がFFIやVM内郚で䜕局も呌び出される。そのたびにコヌルスタックに䜙分なフレヌムが積たれるプッシュされるため、関数呌び出しそのもののオヌバヌヘッドが倧きくなっおしたう。 倀の枡し方の違い Rubyはスタックを䜿っお倀を枡すが、C蚀語はx86_64やARM64などの環境においおCPUのレゞスタを䜿甚しお倀を受け取る。そのため、C蚀語の呌び出し芏玄ABIに合わせお、スタックからレゞスタぞ倀をコピヌしお詰め盎す操䜜が発生する。 タむプ倉換 RubyのオブゞェクトをC蚀語が理解できる型に倉換し、Cからの戻り倀を再びRubyオブゞェクトに倉換するオヌバヌヘッドが発生する。 改善1 この遅い原因を解消するために、JITコンパむラを甚いおそれらのコストを削枛するアプロヌチを詊みおいたした。そしお、Rubyで曞かれたFFIのためのJITコンパむラ「FJIT」が誕生したした。これはfiddle gemなど耇数のgemの機胜を掻甚しお盎接マシンコヌドを生成するこずで、既存のFFI実装に比べお玄2倍ほど高速化するこずが可胜ずなりたした。 改善2 さらにもう1぀の解決案ずしお提案されたのが、CRuby内蔵のJITコンパむラであるZJITず、新しいトランスレヌタである FFX でした。 FFXの仕組み FFXは、Rubyで曞かれたFFI拡匵のコヌドを読み蟌み、自動的にC拡匵のコヌドに倉換したす。この時、生成されるCコヌドの䞭にはZJIT向けのヒント具䜓的には、生成されるCコヌドの䞭に「この関数の匕数はこういう型である」ずいったメタデヌタをZJITが読み取れる圢で配眮するが意図的に埋め蟌たれたす。ZJITはこのヒントから関数の匕数や戻り倀の型情報を認識するこずで、最適化された高速なマシンコヌドを動的に生成するこずが可胜ずなりたす。 最終的なパフォヌマンス これらの改善を導入しベンチマヌクを枬定したずころ、なんずC拡匵よりも玄1.4倍速く動䜜するずいう結果になりたした。結果的に、「RubyはCよりも速くなる」ずいう問いに察しおは、「JITずFFXの力を借りればむ゚ス」ずなり、぀たり「RubyはCよりも速い」ずいう結論で締め括られおいたした笑 FFIの「遅いから䜿わない」ずいう垞識が芆り぀぀あり、ZJITやFFXの成熟によっおRubyからCラむブラリを気軜に・高速に呌べる未来が近づいおいるず感じたした。 ruby.wasm can also enable JavaScript to call Ruby libraries. 小島 @KojimaNaoyuki です。私からはShigeru Nakajima @ledsun さんの「 ruby.wasm can also enable JavaScript to call Ruby libraries. 」を玹介したす。 www.docswell.com このセッションでは、ruby.wasmのこれたで積み重ねられおきた改善を振り返り぀぀、なぜただ実務での採甚事䟋が少ないのかの分析ずそれを解消するために「JSからRubyを呌び出す」機胜を匷化しおいく方針が話されおいたした。 ruby.wasmずは、ブラりザ環境でRuby実行を可胜にするものです。JavaScriptず盞互で連携しながらRubyをブラりザ環境で実行できたす。 ruby.wasmはこれたでRubyからJavaScriptを呌び出す改善を倚く実斜しおいたす。しかし、珟状、本番環境で利甚されおいる䟋はあたりないそうです。その原因ずしおこのセッションでは以䞋の2点に぀いお蚀及されおいたした。 ruby.wasmバむナリが倧きすぎる JSからRubyを呌ぶサポヌトが匱い ruby.wasmバむナリが倧きすぎるこずに぀いおは https://cdn.jsdelivr.net/npm/@ruby/head-wasm-wasi@2.9.3-2.9.4/dist/ruby+stdlib.wasm を䟋に出しお話されおいたした。こちらのファむルは非圧瞮で31.80MiB、圧瞮するず8.84MiBになるそうです。そしお、BtoCのブラりザアプリケヌションではダりンロヌドサむズが重芁ですが、BtoBの堎合はダりンロヌドサむズは倧きな問題ではない可胜性があるずセッションでは話されおいたした。 JSからRubyを呌び出すサポヌトが匱いこずに぀いおは、RubyからJSを呌び出す堎合ずJSからRubyを呌び出す堎合を比范しお扱いやすさの違いを蚀及しおいたした。以䞋がセッションで䜿甚されおいた衚です。 Feature R → J J → R eval Yes Yes Method Call Yes call Property Access Yes N/A Object Conversion Yes string Load Ruby Scripts browser No 出兞 ruby.wasm can also enable JavaScript to call Ruby libraries. | ドクセル 最終閲芧日2026/05/07 こちらを芋るず確かにJSからRubyを呌び出す堎合にサポヌトされおいないものが倚い印象ですね。珟状JSからRubyを呌び出すにはevalメ゜ッドを利甚しお実行できたすが、rubyの実行結果の戻り倀を扱う適切なAPIが䞍足しおいたりず課題があるようです。 これらの珟状を受けお、本番環境で利甚されおいる䟋が少ないのは「JSからRubyを呌ぶ」機胜が䞍十分であるからではないかず分析されおいたした。そしお、もしJSからRubyを呌ぶこずが簡単にできたなら、ロゞックの二重実装を防ぐこずができるため有甚ではないかずおっしゃっおいたした。ロゞックをRubyに統䞀できれば修正も容易になり保守性も向䞊しそうですね 「JSからRubyを呌ぶ」機胜を匷化しおいくためにはRubyオブゞェクトをラップするRbValueを拡匵する必芁があり、このプロゞェクトを「Ruby’s Blanket」ず呌ぶず発衚がありたした。ちなみに、「Ruby’s Blanket」ずいう呜名は凜通出身の人気バンドGLAYの楜曲に由来しおいるずもおっしゃっおいたした。 セッションでは、目指しおいきたい理想の姿も玹介されおおり、以䞋のような䜿甚感を想定しおいるようです。 vm . evalFile ( “ [ dog . rb ]( http: //dog.rb)”); const dog \= vm .eval ( “Dog . new” ) ; dog . vow () ; dog . vow () ; const count \= dog . count\_of\_vows . toInt () ; 出兞 ruby.wasm can also enable JavaScript to call Ruby libraries. | ドクセル 最終閲芧日2026/05/07 JSネむティブなプロパティアクセスやメ゜ッド呌び出しでRubyプログラムを扱っおいるずころを瀺しおいたす。すごく盎感的にJSからRubyコヌドを呌び出せおいたすね セッションの最埌にはコヌディング゚ヌゞェントの掻甚に぀いおも語られおいお、以前よりも難しい課題に取り組むこずができおいるず語られおいたした。「Ruby Committers and the World」や「Matz Keynote」でもAI掻甚が議題に䞊がっおおり、倚くのコミッタヌがAIを駆䜿しおRubyの改善に圓たっおいるそうです。 個人的には、蚀語実装のような「䞖界的にサンプルが少なそうな䜎レむダヌの領域」はAIが䞍埗意な分野だず思い蟌んでいたため、これほど倚くのコミッタヌが掻甚しおいる事実に驚かされたした。 Ruby本䜓や呚蟺ラむブラリの開発が、AI掻甚によっお今埌さらに加速しおいくのが非垞に楜しみです このセッションを通しお「JSからRubyを呌ぶ」機胜が充実するこずで、Rubyの掻甚の幅が広がる未来を感じたした。実際のプロダクトのブラりザ䞊でRubyが動いおいるずころを目にするこずを期埅しおいたす The Less-Told Story of Socket Timeouts WEARのバック゚ンド開発を担圓しおいるaao4seyです。私からは、 @coe401_ さんの「 The Less-Told Story of Socket Timeouts 」を玹介したす。 このセッションでは、Ruby 4.0で Socket.tcp / TCPSocket.new に新しく加わった open_timeout の導入経緯ず、その背埌にあるsocketラむブラリのタむムアりトの歎史が語られおいたした。本蚘事では open_timeout が必芁になった経緯を発衚内容を螏たえお敎理し、続いお各Rubyバヌゞョンで実際にタむムアりトの挙動がどう倉わるのかを手元で芳察した結果を玹介しようず思いたす。 なぜopen_timeoutが必芁だったのか net/httpのtimeoutラむブラリ䟝存問題 発衚者のもずに「net/httpのtimeoutラむブラリ䟝存を倖したい」ずいう盞談が届いたこずが、 open_timeout 導入のきっかけでした。スラむド内でも玹介されおいたすが、Ruby 2.7の開発時代にもnet/httpのような暙準ラむブラリが、暙準ではないラむブラリに䟝存しないほうが良いのではずいう趣旚の提案がなされおいたした。 加えお、timeoutラむブラリは内郚で Timeout::State::GLOBAL_STATE ずいう共有状態を持っおいるため、non-main Ractorからこれにアクセスするず Ractor::IsolationError が発生しおしたう状況でした。 resolv_timeout + connect_timeoutでは代替できない Ruby 4.0開発時点で、 Socket.tcp / TCPSocket.new には名前解決のタむムアりトを指定する resolv_timeout ず、接続確立のタむムアりトを指定する connect_timeout がすでに甚意されおいたした。これらを組み合わせればtimeoutラむブラリの代替になりそうにも思えたすが、実際にはメ゜ッド党䜓の絶察䞊限時間を制埡できたせん。 ここで前提ずしお1぀補足しおおくず、Ruby 3.4で Socket.tcp / TCPSocket.new にはHappy Eyeballs Version 2 (HEv2 / RFC 8305)が fast_fallback ずいう名前でデフォルト有効ずしお導入されたした。HEv2は耇数候補のIPアドレスに察しお名前解決ず接続詊行を䞊行実行するアルゎリズムですHEv2 自䜓の解説は同僚が「 RubyKaigi 2025 協賛&参加レポヌト 」で曞いおいるので、本蚘事ではそちらに委譲したす。なお、Ruby 3.4たでは fast_fallback: false 経路の resolv_timeout がAPI onlyで実装されおおらず、本蚘事の察象であるRuby 4.0で䞡経路で機胜するように修正されおいたす。 その䞊で、たずえばfast_fallback有効で resolv_timeout: 2000ms , connect_timeout: 1000ms を指定した堎合、IPv6が先に解決されおIPv4が解決埅ちのたた接続詊行が始たるず、 connect_timeout の1000msを過ぎおも resolv_timeout の期限たで埅機が続きたす。結果、党䜓タむムアりトは2぀の合蚈でも connect_timeout の倀でもなく、 resolv_timeout の倀である2000msに支配されおしたいたす。 HEv2のConnection Attempt Delay (250ms)が絡むケヌスでは「 connect_timeout: 1000ms を指定しおも党䜓は1250ms埅぀」、fast_fallback無効では「IP数 × connect_timeout 」ず、いずれもナヌザヌが指定した倀ずは別の倀で党䜓時間が決たっおしたいたす。 open_timeoutのAPI仕様 これらの背景を受けお、発衚者ご自身が open_timeout を Socket.tcp / TCPSocket.new に远加する提案をされたした。 open_timeout はtimeoutラむブラリず同じく「名前解決〜接続確立の党䜓」を1぀の期限で管理するオプションです。 Socket .tcp( " ruby-lang.org " , 80 , open_timeout : 1 ) 蚭蚈䞊の論点ずしお、 open_timeout を resolv_timeout / connect_timeout ず䜵甚された堎合にどう振る舞うかを敎理する必芁がありたしたが、耇雑になりすぎおしたうずいう課題があり、最終的に open_timeout は connect_timeout / resolv_timeout ずの同時指定を犁止し、同時指定時は ArgumentError を投げる仕様ずなったそうです。 発衚内では実装の现かい郚分が fast_fallback ありなしごずに説明されおいたした スラむドのp.224以降に蚘茉されおいたす。 詊しおみる ここたで芋おきた経緯を螏たえお、 open_timeout がRuby 4.0で動䜜するのかの怜蚌をしおみたす。たた、私自身はRuby 3.4で導入された fast_fallback 機胜もこの発衚内で知ったので、こちらの挙動も合わせお確認しおみるこずにしたした。 実隓のため /etc/hosts に応答しない3぀のIPを割り圓おた test-multi-local.wear.jp を甚意したした蚘茉のIPはdummyです。 192.168.xx.1 test-multi-local.wear.jp 192.168.xx.2 test-multi-local.wear.jp 192.168.xx.3 test-multi-local.wear.jp 接続先には応答しないポヌト50000を指定し、SYNを送っおも応答が返っおこない状況を䜜りたす。 Ruby 3.4: fast_fallback ON この堎合、HEv2のアルゎリズムに埓い以䞋のような挙動になるはずです。 箄250ms間隔Connection Attempt Delayで次のIPぞ䞊行に詊行を発射しおいる 期埅結果 (IP数-1) × 250ms + connect_timeout = 1.5 秒 で党䜓タむムアりト 怜蚌スクリプト require " socket " t = Time .now begin Socket .tcp( " test-multi-local.wear.jp " , 50000 , connect_timeout : 1 , fast_fallback : true ) { |s| s.close } rescue => e puts "#{ e.class } : #{ e.message }" ensure puts " elapsed= #{ Time .now - t } s " end 実行結果Ruby 3.4.9 Errno::ETIMEDOUT: Operation timed out \- user specified timeout elapsed=1.51281s tcpdumpの結果抜粋 10:41:18.580 SYN → .1 ← IP1 開始 (t=0) 10:41:18.836 SYN → .2 ← IP2 開始 (t≒0.256) 10:41:19.086 SYN → .3 ← IP3 開始 (t≒0.506) 想定どおり、玄1.5秒でtimeout゚ラヌになるこずが芳枬できたした たた、tcpdumpでSYNパケットをざっくり芳枬した結果、玄250msごずに異なるIPぞSYNパケットが飛んでいるこずも芋お取れたした。 Ruby 3.4: fast_fallback OFF fast_fallback: false を枡すず、Ruby 3.3以前ず同じ盎列フォヌルバックの挙動に戻りたす。以䞋のような挙動になるはずです。 各IPに察しお connect_timeout: 1 で1秒ず぀順番に詊行 期埅結果 IP数 × connect_timeout = 3 秒 で党䜓タむムアりト 怜蚌スクリプト 前述のスクリプトの Socket.tcp 呌び出し行を以䞋のように倉曎したす。 - Socket.tcp("test-multi-local.wear.jp", 50000, connect\_timeout: 1, fast\_fallback: true) { |s| s.close } + Socket.tcp("test-multi-local.wear.jp", 50000, connect\_timeout: 1, fast\_fallback: false) { |s| s.close } 実行結果Ruby 3.4.9 Errno::ETIMEDOUT: Operation timed out \- user specified timeout elapsed=3.013505s tcpdumpの結果抜粋 10:40:20.753 SYN → .1 ← IP1 開始 (t=0) 10:40:21.760 SYN → .2 ← IP2 開始 (t≒1.0) 10:40:22.764 SYN → .3 ← IP3 開始 (t≒2.0) 想定通り、fast_fallbackを無効にするずIP1 → IP2 → IP3ず1秒ず぀順番に詊行され、合蚈玄3秒で党䜓タむムアりトするこずが芳枬できたした。 Ruby 4.0: open_timeout ここたでの結果から、 connect_timeout だけではメ゜ッド党䜓の䞊限時間を制埡できないこずが芋えたした。Ruby 4.0で導入された open_timeout を䜿うず挙動がどう倉わるかを芋おいきたす。 fast_fallback ON + open_timeout fast_fallback ONで open_timeout が機胜するか詊したす。 期埅結果open_timeoutに指定した1秒でタむムアりト 怜蚌スクリプト 前述のスクリプトの Socket.tcp 呌び出し行を以䞋のように倉曎したす。 \- Socket.tcp("test-multi-local.wear.jp", 50000, connect\_timeout: 1, fast\_fallback: true) { |s| s.close } \+ Socket.tcp("test-multi-local.wear.jp", 50000, fast\_fallback: true, open\_timeout: 1) { |s| s.close } 実行結果Ruby 4.0.3 IO::TimeoutError: user specified timeout for test-multi-local.wear.jp:50000 elapsed=1.004653s 想定通り、玄1.0秒で IO::TimeoutError が発生し、 open_timeout: 1 で指定した時間ずほが同じ時間でタむムアりトするこずが芳枬できたした fast_fallback OFF + open_timeout fast_fallback OFFで open_timeout が機胜するか詊したす。 期埅結果open_timeoutに指定した1秒でタむムアりト 怜蚌スクリプト 前述のスクリプトの Socket.tcp 呌び出し行を以䞋のように倉曎したす。 \- Socket.tcp("test-multi-local.wear.jp", 50000, connect\_timeout: 1, fast\_fallback: true) { |s| s.close } \+ Socket.tcp("test-multi-local.wear.jp", 50000, fast\_fallback: false, open\_timeout: 1\) { |s| s.close } 実行結果Ruby 4.0.3 Errno::ETIMEDOUT: Operation timed out \- user specified timeout for 192.168.xx.1:50000 elapsed=1.007804s こちらも想定通り、玄1.0秒で user specified timeout が発生し、 open_timeout: 1 で指定した時間ずほが同じ時間でタむムアりトするこずが芳枬できたした  fast_fallback の蚭定有無に関わらず open_timeout が機胜しおいるこずがわかりたした。 同時指定ぱラヌ open_timeout は connect_timeout / resolv_timeout ずの同時指定が犁止されおおり、 Socket.tcp の入口で ArgumentError が即座に発火したす。 Socket .tcp( " test-multi-local.wear.jp " , 50000 , connect_timeout : 1 , open_timeout : 1 ) { |s| s.close } # => ArgumentError: Cannot specify open_timeout along with connect_timeout or resolv_timeout 党䜓の察比 ここたで芳枬した結果を䞊べるず以䞋のようになりたす。 Ruby 蚭定 elapsed 3.4.9 fast_fallback: false , connect_timeout: 1 箄 3.01 秒 3.4.9 fast_fallback: true , connect_timeout: 1 箄 1.51 秒 4.0.3 fast_fallback: false , open_timeout: 1 箄 1.01 秒 4.0.3 fast_fallback: true , open_timeout: 1 箄 1.00 秒 connect_timeout だけを指定したケヌスでは、ナヌザヌの指定倀ずは別の倀で党䜓時間が決たっおいたのに察し、 open_timeout を指定すれば 指定倀ぎったりで打ち切られる ようになりたした。 おわりに 本パヌトではセッションの内容である open_timeout の導入経緯ず、実際に fast_fallback や open_timeout の挙動を芳枬した結果を玹介したした open_timeout の実装により、接続詊行党䜓のタむムアりトが管理しやすくなったず感じたす。実際のセッションではRuby 2.0の開発時代から今に至るたでのsocketラむブラリのタむムアりト導入の歎史も詳现に説明されおおり、各時代ごずにどんな課題がありどう解決しおきたのかを知るこずができずおも興味深かったです。たた、このセッションに限らずですが、RubyKaigi党䜓を通しお発衚者の方のモチベヌションを垣間芋るこずができたのも自分にずっお良い刺激ずなりたした。 Autoresearching Ruby Performance with LLMs 小山 です。私からはNate Berkopec @nateberkopec さんの「 Autoresearching Ruby Performance with LLMs 」を玹介したす。 Berkopec氏は、Speedshop代衚でありPumaメンテナヌ、Railsパフォヌマンスコンサルタントずしお広く知られおいたす。本セッションは Autoresearch ずいう先行ツヌルを参考に、AI゚ヌゞェントを䜿っお、Rubyのパフォヌマンス問題を自動で調査する取り組みずそれにより埗られた瀺唆の発衚でした。 発衚資料は以䞋のリポゞトリで公開しおくださっおいるためご参照ください。 github.com Autoresearchずは Autoresearchは、2026幎3月にAndrej Karpathy @karpathy 氏が公開したLLM実隓自動化ツヌルです。仕組みはシンプルです。 AI゚ヌゞェントがコヌドぞの倉曎を提案・適甚する 䞀定時間ベンチマヌクを実行する ベヌスラむンより良ければコミット、悪ければリバヌト 1に戻る これを無限に繰り返したす。PyTorchず単䞀のメむンファむル以倖に䟝存関係がなく、1時間あたり玄12実隓、䞀晩で玄100実隓を回せたす。Berkopec氏がこのコンセプトをRubyのパフォヌマンス改善に応甚できるかを探ったのが今回の発衚です。 なぜ「ルヌプ」が重芁なのか セッションで繰り返し匷調されたのが ルヌプ ずいう抂念です。 AI゚ヌゞェントは本質的にはルヌプにすぎないず、Berkopec氏は次のコヌド䟋で説明しおいたす。 messages = [user_prompt] loop do reply = llm.call(messages, tools : TOOLS ) break puts(reply.text) unless reply.tool_call? result = run_tool(reply.tool_name, reply.arguments) messages << reply messages << tool_result(result) end このルヌプに どのようなゲヌト通過条件を眮くか が、ルヌプの性栌を決めたす。それがセッション党䜓の䞀貫したテヌマでした。 4぀のルヌプパタヌン Berkopec氏は、ゲヌトの皮類によっおルヌプを4皮類に分類したした。 ルヌプ ゲヌト シグナル 成果物 Agents LLM 自己停止 離散 最終的な返答 Ralph ビルドテスト 離散 グリヌンなコミット Autoresearch ベンチマヌク差分 連続 改善した diff Factory 倚数のチェック 倚倉数 マヌゞ可胜な PR Ralphルヌプ while :; do cat PROMPT.md | claude-code ./build \_ and \_ test || continue git add \- A git commit \- m " ralph: passing build " git push done ビルドずテストをゲヌトにしたルヌプです。テストが通った倉曎だけをコミットし続けたす。バグぞの察凊に向いおいたす。 Autoresearchルヌプ best \= benchmark loop do change \= agent.propose\_optimization apply(change) score \= benchmark if score \> best git\_commit(change.summary) best \= score else git\_revert end end ゲヌトがブヌル倀pass/failではなく 連続倀ベンチマヌクスコアの改善量 である点がRalphずの違いです。 Factoryルヌプ backlog.each do |spec| loop do code \= agent.implement(spec) gates \= scenarios.map { |s| s.run(code) } break if gates.all?(& :pass? ) end ship(code) end スペックからコヌドを生成し、耇数のゲヌトを党お通過したら出荷するパタヌンです。StrongDM瀟の「 Software Factory 」が参照されおいたした。 Sidekiqでの実蚌実隓 セッション䞭に玹介された実隓の1぀が、 pi-autoresearch を甚いた、Sidekiqを察象にした自動最適化です。 実隓の背景 Sidekiqの Processor::Counter はアトミックなカりンタヌで、16行皋床のシンプルな実装です。Autoresearch゚ヌゞェントはここにストラむプドロック各スレッドが自前の状態を持ち、曞き蟌みを安くする仕組みを適甚する倉曎を提案したした。 たた、別のPRでは Time.now.to_i を Process.clock_gettime に眮き換えるこずも提案されたした。 Comparison: Process.clock_gettime: 17294486.8 i/s Time.now.to_i: 12698329.6 i/s - 1.36x slower Timeオブゞェクトを生成せずに敎数を盎接返すこずで1.36倍高速化できたす。 "マヌゞされないコヌドを生成するこずの意味" これらの倉曎に぀いおBerkopec氏は「OSSメンテナヌは実際にはこれをマヌゞしないだろう」ず正盎に述べおいたした。その䞊で、なぜマヌゞできないコヌドを生成するのか、ずいう問いを投げかけたした。 "Why generate code that you can't merge?" この問いに察しお、セッションは PR レビュヌの目的を再定矩するパヌト ぞず展開したした。 PRレビュヌずは䜕か 倉曎を华䞋する理由ずしお、Berkopec氏は以䞋を挙げたした。 バグがある → LLMはある皋床埗意 トレヌドオフがある →「十分に速い」ずはどのレベルか 耇雑すぎる → Flog/Flayスコア、ABCスコア、LOC リスクが高すぎる → キャッシュ無効化などAutoresearchはキャッシュが倧奜きで、しかもバグりやすい テストを通るが... → Autoresearchは良いテストがある前提で動く GPL 違反など → GitHub倖の法的・コンプラむアンスチェック 芁するに 「マヌゞできるか」を刀断する胜力こそがArchitectである ずいう䞻匵です。 4぀のレッスン セッションを通じお提瀺された4぀のレッスンをたずめたす。 Lesson 1: 「自動調査」であっお「自動倉曎」ではない Stan Lo氏Shopifyの取り組みが玹介されたした。Ruby-lspのCI時間を33削枛、rubydexのむンデックス速床を10〜50改善するずいった成果を、AIの提案を自身がレビュヌした䞊で実珟しおいたす。AIの出力を人間が怜蚌・理解しお取り蟌む姿勢が重芁だずいう䟋です。 Lesson 2: 自分がオヌナヌで Architect でないものに Autoresearch を適甚しない 理解・怜蚌・修正できるコヌドにのみ適甚すべきです。 Lesson 3: ルヌプはビタヌ・レッスンを実践する Richard Suttonさんの「苊い教蚓Bitter Lesson」人間の知識を組み蟌むより、蚈算のスケヌルによっお探玢・孊習する方が長期的に優れるずいう教蚓をルヌプは䜓珟しおいたす。ルヌプは人間のゲヌトを担保するバヌゞョンに過ぎず、ゲヌトを゜フトりェアに眮き換えるこずで探玢をスケヌルさせられたす。 Lesson 4: 人間のゲヌトを゜フトりェアゲヌトに倉換する 「遅い」ずいう感芚を赀/緑の状態・バグチケットに倉換するプロセスがパフォヌマンス改善の本質です。たずえAutoresearchが倱敗しおも、ゲヌトを定矩する過皋で゜フトりェアの品質自䜓が䞊がりたす。 Software Factory ずその課題 セッション埌半では、 Software Factory StrongDM瀟の提唱するコンセプトが玹介されたした。 "Code must not be written by humans. Code must not be reviewed by humans." — StrongDM's "Software Factory" これは人間のレビュヌを完党に排陀し、倚数の自動ゲヌトを通過したコヌドのみを出荷する考え方です。セッションではこれを「dark factory」ず衚珟し、Berkopec氏は倚くの未解決の問いを䞊べお玹介したした。 圢匏手法・プロパティベヌステストは珟実的にスケヌルするか 既存の倧芏暡コヌドベヌスブラりンフィヌルドに適甚できるか LOCの肥倧化をどう防ぐか LLMがトレヌニングデヌタの著名な最適化を「再発明」するだけにならないか 決定論的なゲヌトずLLMゞャッゞをどう組み合わせるか Berkopec氏はこれらに察しお珟時点で答えはないずしながらも、「ゲヌト蚭蚈こそが重芁になる」ずいう方向性を瀺したした。 たずめ Berkopec氏のセッションを䞀蚀でたずめるず、 「AI に自埋的なルヌプを回させるこずはできるが、それを意味のある成果に倉えるにはゲヌト蚭蚈ずいう人間のスキルが必芁」 ずいうメッセヌゞでした。 発衚で掚奚されおいた実践ステップは以䞋の通りです。 自分が十分に理解・レビュヌできるコヌドにのみ適甚するStan Lo氏のアプロヌチ 成熟した小さなモゞュヌルから始める ゲヌトが最小で枈む堎所からスタヌトする ゲヌトを増やせば人間のレビュヌを枛らせる Ralph離散・Autoresearch連続・Factory倚ゲヌトのいずれかのルヌプを詊しおみる おわりに 今幎のRubyKaigiはAIに関するセッションの倚さが印象的でした。普段の業務で自身もAIを掻甚しおいたす。本セッションで玹介されおいたゲヌトの蚭蚈・導入に泚力しお、パフォヌマンス改善はもちろんのこず、それ以倖のあらゆる業務課題の自動化をより掚進しおいきたいず思いたした Exploring RuboCop with MCP 䌊藀です。今幎もRubyKaigiに参加しおきたした 私からは @koic さんの「 Exploring RuboCop with MCP 」をご玹介したす。 speakerdeck.com 本セッションは「I. MCP Ruby SDK」「II. RuboCop x MCP」の2郚構成で、前半では @koic さんがコミッタヌを務める公匏の MCP Ruby SDK  mcp gemずしお公開の蚭蚈や、Streamable HTTPでのセッション管理・Sampling・Elicitationたでが解説されたした。埌半は、RuboCop 1.85.0で実隓的に远加された組み蟌みMCPサヌバヌの玹介でした。 ここでは特に埌半「RuboCop x MCP」を題材に、WEARのバック゚ンド゚ンゞニアずしお実際に手元で動かしおみた感想を䞭心にご玹介したす。 rubocop --mcp は、RuboCop 1.85.0から導入されたサブコマンドで、AI゚ヌゞェントClaude CodeなどのMCPクラむアントからRuboCopを呌び出せるようにする組み蟌みMCPサヌバヌを起動したす。stdio transportで通信し、以䞋の2぀のツヌルを公開したす。 rubocop_inspection オフェンス怜査読み取り専甚 rubocop_autocorrection オヌトコレクト適甚砎壊的 なお、RuboCopではコヌディング芏玄違反のこずを「オフェンスoffense」ず呌びたす。以降本蚘事でもこの甚語を䜿いたす。 rubocop --lsp の内郚で䜿われおいる蚺断機構 RuboCop::LSP::Runtime をそのたた再利甚しおいるのが特城で、出力されるオフェンスはLSPの Diagnostic 圢匏JSONです。Clang圢匏のテキストよりも構造化されおいるため、AI゚ヌゞェントがそのたたパヌスしお扱いやすい圢になっおいたす。 ここからは実際に手元で動かしおみたす。 rubocop --mcp を䜿うには、RuboCop本䜓に加えお mcp gemが必芁ですRuboCopは mcp をruntime dependencyずしお持っおいないため。既存のGemfileのdevelopmentグルヌプに以䞋を远加したす。 group :development do gem ' mcp ' end 次にClaude Codeに .mcp.json でRuboCopのMCPサヌバヌを登録したすClaude Codeが蚭定を読み、起動時に bundle exec rubocop --mcp をサブプロセスずしお立ち䞊げおくれたす。 { " mcpServers ": { " rubocop ": { " command ": " bundle ", " args ": [ " exec ", " rubocop ", " --mcp " ] } } } Claude Code䞊で /mcp を叩くず、登録した rubocop サヌバヌから2぀のツヌルが認識されおいるのが確認できたす。 ❯ /mcp ──────────────────────────────────────────────────── Tools for rubocop 2 tools ❯ 1\. RuboCop's inspection read-only 2\. RuboCop's autocorrection destructive それでは実際に rubocop_inspection を呌んでみたす。オフェンスを意図的に仕蟌んだ以䞋のサンプルファむル sample.rb を甚意しお、怜査を呌んでもらいたす。 # frozen_string_literal: true def greet ( name ) message = " Hello, " +name+ " ! " puts message end greet( " WEAR " ) 「 sample.rb をRuboCopで怜査しお」ずお願いするず、Claude Codeが rubocop_inspection ツヌルを呌び、結果を以䞋のように敎圢しお提瀺しおくれたした。 ❯ sample.rb をRuboCopで怜査しお Called rubocop (ctrl+o to expand) ⏺ sample.rb の怜査結果: 9 件の offense が怜出されたしたすべお自動修正可胜。 ┌─────┬─────────────────────────────┬─────────────────────────────┐ │ 行 │ Cop │ 内容 │ ├─────┌─────────────────────────────┌────────────────────────────── │ 2 │ Layout/SpaceInsideParens │ 括匧内の䜙蚈なスペヌス2 │ │ │ │ 箇所 │ ├─────┌─────────────────────────────┌────────────────────────────── │ 3 │ Style/StringConcatenation │ \+ 連結より文字列補間を掚奚 │ ├─────┌─────────────────────────────┌────────────────────────────── │ 3 │ Style/StringLiterals │ "Hello, " → │ │ │ │ シングルクォヌト掚奚 │ ├─────┌─────────────────────────────┌────────────────────────────── │ 3 │ Style/StringLiterals │ "\!" → シングルクォヌト掚奚 │ ├─────┌─────────────────────────────┌────────────────────────────── │ 3 │ Layout/SpaceAroundOperators │ \+ 挔算子の前埌にスペヌス無 │ │ │ │ し2 箇所 │ ├─────┌─────────────────────────────┌────────────────────────────── │ 4 │ Layout/IndentationConsisten │ むンデントが䞍揃い │ │ │ cy │ │ ├─────┌─────────────────────────────┌────────────────────────────── │ 7 │ Style/StringLiterals │ "WEAR" → │ │ │ │ シングルクォヌト掚奚 │ └─────┮─────────────────────────────┮─────────────────────────────┘ すべお rubocop \-A で自動修正できたす。自動修正を実行したすか 「自動修正を実行したすか」ずいうフォロヌアップ付きで、続けお rubocop_autocorrection ツヌルぞの切り替えたで自然に提案しおくれおいるのが分かりたす行番号がLSPの0-indexed倀のたた衚瀺されおいるのは、RuboCopが返すLSP Diagnosticの倀をClaude Code偎で1-indexedに倉換せずに衚瀺しおいるためです。 このずき裏で rubocop_inspection から返っおきおいる生のJSONは、玙面の郜合で code_actions を省略し、怜出された9件のうち代衚2件のみ抜粋するず以䞋のようになっおいたす。 { " files ": [ { " path ": " sample.rb ", " offenses ": [ { " range ": { " start ": { " line ": 2 , " character ": 10 } , " end ": { " line ": 2 , " character ": 11 } } , " severity ": 3 , " code ": " Layout/SpaceInsideParens ", " codeDescription ": { " href ": " https://docs.rubocop.org/rubocop/cops_layout.html#layoutspaceinsideparens " } , " source ": " RuboCop ", " message ": " Layout/SpaceInsideParens: Space inside parentheses detected. ", " data ": { " correctable ": true , " code_actions ": [ /* 省略 */ ] } } , { " range ": { " start ": { " line ": 3 , " character ": 12 } , " end ": { " line ": 3 , " character ": 30 } } , " severity ": 3 , " code ": " Style/StringConcatenation ", " codeDescription ": { " href ": " https://docs.rubocop.org/rubocop/cops_style.html#stylestringconcatenation " } , " source ": " RuboCop ", " message ": " Style/StringConcatenation: Prefer string interpolation to string concatenation. ", " data ": { " correctable ": true , " code_actions ": [ /* 省略 */ ] } } ] } ] , " summary ": { " target_file_count ": 1 , " offense_count ": 9 } } LSPの蚺断ず同じ圢匏なので、各オフェンスにcop名・該圓範囲・cop個別のドキュメントURL・自動修正可吊 correctable たで構造化された圢で含たれたす。さらに省略した code_actions には実際のautocorrectで挿入する文字列䟋: Style/StringConcatenation なら "Hello, #{name}!" ぞの眮換や、 # rubocop:disable を入れお該圓行で無効化する案もLSPの WorkspaceEdit 圢匏で含たれおおり、゚ヌゞェントから機械的に扱えるようになっおいたす。 rubocop_autocorrection ツヌルに切り替えれば、そのたた砎壊的に修正をかけるこずもできたす。 WEARのバック゚ンドではすでにRuboCop+各皮pluginを倧芏暡に運甚しおいるので、生成AIによる開発を取り入れる際にも「RuboCopを通っおいる」ずいう決定的なゲヌトはそのたた䜿い続けたい、ず日頃から思っおいたした。本セッションは、たさにその「決定的なツヌルRuboCop」ず「確率的なLLM」を rubocop --mcp ずいうかたちで玠盎に橋枡ししおくれる発衚で、聞きながら自分の開発フロヌに組み蟌む絵が具䜓的に浮かびたした。 セッション埌半で @koic さんが投げかけられおいた "What happens when combined?"決定的なツヌルず確率的なLLMを組み合わせるず䜕が起きるかずいう問いも印象的でした。䟋えば、珟状の .rubocop.yml で無効化しおいるcopをLLMに䞀時的に有効化させ、レビュヌ芳点ずしお「いた無効になっおいるcopをあえお芋たらどう芋えるか」を提瀺しおもらう、ずいった䜿い方は、ツヌル単䜓だず出おこない発想です。Streamable HTTPでのSamplingやElicitationたで含めお、ただ「探玢が始たったばかり」ずいう締めくくり通り、これからRuboCop×MCPでどんな詊みが出おくるかずおも楜しみです。 The Journey of Box Building 坂元 @sakam0cchan です。私からはSatoshi Tagomori @tagomoris さんの「 The Journey of Box Building 」ずいうセッションを玹介したす。 speakerdeck.com このセッションは、Ruby 4.0で実隓的に導入される新機胜「Ruby Box」をテヌマにしたKeynoteです。Boxの基本抂念から、実行䞭のRubyプログラムの䞭でBoxを特定する際の難しさ、そしおその実装に至るたでの背景などが語られおいたした。 私自身が初めおRubyKaigiに参加し、そしお初めお聞いたKeynoteがこの内容だったこずもあり、これからの3日間がどんなものになるかずおもわくわくしたした。そんな思いも蟌めお、内容を共有したす。 Ruby Boxずは䜕か Ruby BoxRubyKaigi 2025たでは「Namespace」ず呌ばれおいた機胜は、Ruby 4.0で導入された実隓的な機胜です。 Ruby Boxは、これたでRubyのプロセス党䜓で共有されおいたクラスやモゞュヌル、モンキヌパッチなどを、別の空間Boxずしお分離し読み蟌み・実行できる革新的な機胜ずなっおいたす。たずえば、 something.rb に曞かれたクラスを、メむン環境ずは独立したBoxの䞭に読み蟌むむメヌゞです。 # something.rb class Something def hello = " hello from Something " end # main.rb box = Ruby :: Box .new box.require( ' something ' ) s = box:: Something .new p s.hello # => "hello from Something" Boxの䞭で読み蟌んだ Something は box::Something ずしおだけアクセスでき、Boxの倖からは芋えたせん。これにより、ラむブラリやモンキヌパッチをプロセス党䜓ぞ挏らさずに䜿えるのがBoxのコアアむデアです。セッションの䞭では、以䞋のような甚途がBoxの利甚シヌンずしお挙げられおいたした。 䞀郚のコヌドにお有効なモンキヌパッチの適甚 テスト内でのモック凊理 異なるバヌゞョンのラむブラリに䟝存する耇数のアプリケヌションを、同じプロセス内に同居させる どちらにも同じリク゚ストを送るこずで、異なるバヌゞョンのラむブラリでの挙動を比范する このように、Boxは「同じプロセス内での隔離された環境」を提䟛するこずで、これたでRubyで難しかったこずを可胜にする機胜ずしお期埅されおいたす。 Ruby Boxの仕組み 本セッションでは、Ruby Boxを実珟する䞊で必芁䞍可欠ずなる「珟圚、実行䞭のコヌドがどのBoxに属しおいるか」を刀定する仕組みが詳现に解説されおいたした。 Ruby Boxでは、「1぀のファむルを、別のBoxで同時に読み蟌む」ずいったこずが可胜です。぀たり、ファむル自䜓は特定のBoxに瞛られおいないため、プログラムが実行されるたびに、Ruby自身が「自分は今、どのBoxの䞭で動いおいるのか」を動的に特定し続けなければなりたせん。 Boxの特定・決定のプロセスは、以䞋のようなステップで行われおいるずのこずでした。 珟圚実行䞭のフレヌムを特定する たず、自分がいた実行しおいるControl Frameを芋぀ける LOCALな倉数スコヌプを探す そこから、ブロックや䟋倖凊理ずいった非ロヌカルなものを無芖し、ファむル党䜓、クラス、メ゜ッドずいった「LOCAL局所的」なスコヌプを持぀フレヌムたでさかのがる Boxの情報を匕っ匵り出す そこで、芋぀けたLOCALなフレヌムの䞭に保存されおいる情報をたどり、そこに玐付いおいる「Box情報」を取埗する ここで䞀番興味深かったのは、Control Frameずロヌカル倉数などを管理しおいるENVずの関係性です。それぞれはRubyを実行する䞊で、珟時点でどのコヌドが動いおいるのかを把握するためのものです。Rubyのメモリ䞊では、Control FrameずENVの2぀が䞡端から内偎に向かっお䌞びおいく特殊な構造ずなっおいるそうです。 この二぀が衝突するず、Stack Overflowが発生するずいう話をこのセッションで初めお知り、今たであたり意識しおいなかったRubyの内郚構造に぀いお、もっずより知っお勉匷したいず改めお感じたした。 Ruby Boxが生たれた歎史 さらに、印象に残っおいるもう1぀のトピックずしお、Ruby Boxが生たれた歎史に぀いおの話がありたす。開発者のTagomoriさんがRuby Boxの開発を始めたきっかけは、RubyKaigi 2023で発衚された 「Multiverse Ruby」のセッション でした。その内容が、過去に自身が抱えおいた課題ず重なるず感じたこずで、䞀気にモチベヌションが高たったそうです。 さらに、その䌚期䞭に発衚者の方ず盎接話す機䌚があり、圓初は「Hako」ずいう呜名にしお凜通のRubyKaigiで発衚しよう、ずいう話もあったそうで 。そしお実際に今、こうしお発衚に至っおいる、なんず胞が熱くなる展開でしょうか。 こんな゚ピ゜ヌドを通しお、「みなさんにも、ふずモチベヌションが湧き䞊がる瞬間があるかもしれない。あなたにずっおの『Multiverse Ruby』があるかもしれない。そんなプロセスも含めおRubyKaigiを楜しんでほしい」ずいう蚀葉が印象的でした。最初のセッションでその䞀蚀を聞いたずき、これから始たる3日間のRubyKaigiにずおもわくわくしたあの瞬間を、今でも芚えおいたす。そんな開発の裏゚ピ゜ヌドも含め、ずおも印象的なセッションでした。 おわりに 本セッションは「新機胜の玹介」ずいうよりも、どんなふうに実珟されおいるのか、さらにその機胜が生たれた瞬間を聎ける発衚で、聎いた埌の䜙韻が長く残るキヌノヌトでした。 WEARのバック゚ンドはRuby on Railsで開発・リプレむスを進めおおり、monkey patchが絡む箇所のスコヌプ管理に苊劎する堎面が今埌出おくるかもしれたせん。Boxのように「実行時の境界」を衚珟できるようになれば、たずえばラむブラリの差し蟌みやテスト環境固有の䞊曞きを、より芋通しよく扱えるようになる可胜性を感じたした。Ruby Boxはただ実隓的な機胜ではありたすが、今埌も匕き続き泚目しおいきたいです ZOZOブヌスの玹介 こんにちは。Developer Engagementブロックの wiroha です。ここからはZOZOや各瀟の協賛ブヌスの様子を玹介したす。 今回は出発圓日の朝、管制トラブルの圱響で飛行機の運航に乱れが出おいる状況からのスタヌトずなりたした。搭乗予定の䟿も遅延か欠航かの芋通しが立たなかったため、早々にキャンセルしお新幹線ぞ切り替えたこずが功を奏し、4〜5時間かかったものの比范的早めの時間に凜通入りできたした。たた盎前の地震の圱響で北海道では配送の遅延が起きおいたようですが、幞いブヌスの荷物は無事に届いおおり、予定どおり運営できそうでほっずしたした。 今回のブヌスはファッション×AIの2぀の新しい䜓隓をご甚意したした。ひず぀は「 Apps in ChatGPT 」、もうひず぀はWEARアプリ内の「 着回し提案 」機胜です。 ファッション×AIの新機胜を䜓隓しよう 「 Apps in ChatGPT 」の䜓隓では、技術カンファレンスに合うコヌディネヌトを盞談する方や、自分の写真を撮っお「もっずおしゃれにするにはどうしたらいい」ず質問する方など、それぞれ自由な察話を楜しんでいる様子が芋られたした。 「Apps in ChatGPT」を䜓隓䞭の様子 「 着回し提案 」は特定のアむテムを遞択するず、ファッションに特化したAIがナヌザヌの奜みに合わせた着回しを提案したす。「知らなかった、䟿利そう」ずいう感想を倚くいただきたした。 「着回し提案」を䜓隓䞭の様子 いずれかの䜓隓をしおいただいた方に、ZOZOらしいノベルティの「 掗濯ネット 」をプレれントしたした。「ちょうど今日掗濯しようず思っおたした」「掗濯ネットが欲しくお䜓隓しに来たした」ずいった声があり、日垞的に䜿えるアむテムずしお倚くの方に喜んでいただけたした ZOZOらしいノベルティの掗濯ネット 協賛䌁業ブヌスのコヌディネヌトたずめ assu_ です。凜通ぞはすんなり蟿り着く──はずでした。䌊䞹空枯で突劂届く欠航の知らせ、満垭の凜通䟿、迫られる決断。滑り蟌んだ新千歳行き、やけくそで高い寿叞を買い、特急北斗で凜通ぞ。家を出おから実に13時間、極寒の凜通に到着──虚無の心を救ったのは、凜通駅前のハセガワストア。波乱の移動を経お蟿り着いた䌚堎には、同じように倧倉な思いをした人も少なくありたせんでした。 そんな䌚堎から、前回の RubyKaigi 2025 同様、玠敵なコヌディネヌトの協賛䌁業の皆様を撮圱させおいただきたした デザむンスポンサヌのGaji-Laboさん Committer限定のMA-1は、垌少性ず刺繍の2026デザむンがずおもクヌル。 北海道らしいむラストをあしらったフヌディヌの note さん。 パンダをモノクロにするず北海道らしくなったずいう GMO Flatt Security さん。 CM でおなじみのキャラクタヌにより個性的なデザむンの ファむンディ さん。 シンプル胞元ずカタカナ背䞭の察比が良い、ネットプロテクションズさん。 襟シャツに絞り付きの裟、男性も女性も着こなし䞊手だったギフティさん。 ロゎのラむンが今っぜい、芖認性が高くセンスの良いWEDさん。 誇り高きデザむンにより、長い Rubyæ­Ž を衚しおいるKOMOJUさん。 桜が満開の凜通に䞀番ぎったりなカラヌず、法被で華やかなwithさん。 Wellness Sponsorらしいブラックで “ W ”orkoutしやすそうなhacomonoさん。 北海道・凜通らしいデザむンや、倉化する気枩に察応しやすそうな圢が目立った回でしたね。お忙しい䞭ご協力いただいたブヌスの皆さん、本圓にありがずうございたした RubyKaigi 2026 アフタヌむベント〜初参加LT・スポンサヌ4瀟のパネル〜を開催したす RubyKaigi 2026 アフタヌむベント〜初参加LT・スポンサヌ4瀟のパネル〜 5月13日氎にRubyKaigi 2026スポンサヌ䌁業の株匏䌚瀟ZOZO、株匏䌚瀟リブセンス、株匏䌚瀟TOKIUM、株匏䌚瀟マむベストでRubyKaigi 2026のアフタヌむベント「 RubyKaigi 2026 アフタヌむベント〜初参加LT・スポンサヌ4瀟のパネル〜 」を開催したす。 RubyKaigi 2026に参加した方も、参加できなかった方も、ぜひお気軜にご参加ください mybest.connpass.com おわりに 䞖界䞭のRubyistが凜通の地に集たりたした ZOZOは毎幎RubyKaigiに協賛し、ブヌスを出展しおおり、今幎も倚くの方々ずの亀流を通じお有意矩な時間を過ごすこずができたした。実行委員䌚の皆様、そしお枩かく迎えおくださった凜通垂の皆様に感謝申し䞊げたす。来幎も再び玠晎らしい時間を共有できるこずを楜しみにしおおりたす 技術カンファレンスでは恒䟋のスポンサヌパネルぞのサむン RubyKaigi 2027 #rubykaigi 🗓 14..16 Apr 2027 🥭 Miyazaki, Japan — RubyKaigi (@rubykaigi) 2026幎4月24日 そしお、次回の開催地は私たちZOZOの宮厎オフィスがある宮厎県です。宮厎圚䜏゚ンゞニアも数名圚籍しおいるので、地元を生かしたむベントなどができるず良いですね。それではたた来幎、RubyKaigi 2027でお䌚いしたしょう。珟堎からは以䞊です ZOZOでは、来幎のRubyKaigi 2027を䞀緒に盛り䞊げる゚ンゞニアを募集しおいたす。ご興味のある方は以䞋のリンクからご応募ください。 corp.zozo.com
本蚘事は 2026 幎 5 月 7 日に公開された “ Full-text, exact-match, range, and hybrid search on Amazon ElastiCache ” を翻蚳したものです。 蚳者蚻 本蚘事の党文怜玢は、珟時点では蚀語オプションずしお english のみをサポヌトしおおり、日本語テキストはスペヌスや句読点で区切られた単䜍でむンデックスされたす。日本語を党文怜玢する堎合は、事前に圢態玠解析で語ごずにスペヌスで区切ったテキストをむンデックスし、怜玢ク゚リも同じ圢で枡すようにしおください。 Amazon ElastiCache は、別個の怜玢サヌビスを䜿甚するこずなく、キャッシュ内で盎接リアルタむムの党文怜玢、完党䞀臎怜玢、数倀範囲怜玢、ハむブリッド怜玢をサポヌトするようになりたした。䜎レむテンシヌで動的デヌタに察するスケヌラブルな怜玢を必芁ずするワヌクロヌドに察しお、アプリケヌションはマむクロ秒単䜍のレむテンシヌず毎秒最倧数癟䞇回の怜玢操䜜のスルヌプットでテラバむト芏暡のデヌタを怜玢できたす。これらの新しい怜玢機胜により、開発者は ElastiCache に既に保存されおいるデヌタを、単玔なキヌバリュヌ怜玢を超えた属性で柔軟にク゚リできるようになりたす。 完党䞀臎怜玢は、商品名、カテゎリ、ナヌザヌ ID、泚文番号など、テキスト、タグ、数倀属性にわたる正確な倀の䞀臎によっおドキュメントを取埗したす。数倀範囲怜玢は、䟡栌のしきい倀、日付範囲、取匕金額などの属性によっおドキュメントをフィルタリングしたす。完党䞀臎に加えお、党文怜玢はテキスト属性に察しお、オヌトコンプリヌト (入力補完) 甚のプレフィックスマッチング、タむプミス蚱容のためのファゞヌマッチング、耇数語怜玢のための近接マッチングを実行したす。これらの怜玢タむプをベクトル類䌌床ず単䞀のハむブリッドク゚リで組み合わせるこずができ、正確な甚語ず意味的な意図の䞡方を捉えるこずで、いずれかの手法を単独で䜿甚するよりも関連性の高い結果を提䟛したす。ベクトルワヌクロヌドにおいお、ElastiCache for Valkey は AWS 䞊の䞻芁なベクトルデヌタベヌスの䞭で、95% 以䞊の再珟率で最䜎レむテンシか぀最高スルヌプットのベクトル怜玢、そしお最高の䟡栌性胜比を実珟したす。 これらの怜玢機胜は、ElastiCache version 9.0 for Valkey で利甚可胜であり、リアルタむム分析やレポヌティング向けのサヌバヌサむド集蚈機胜も䜵せお提䟛されおいたす ( Amazon ElastiCache での集蚈機胜のお知らせ を参照)。ElastiCache version 9.0 for Valkey では、個々のフィヌルドに察するきめ现かい TTL 制埡を可胜にするハッシュフィヌルドの有効期限機胜や、最倧 40% 向䞊したパむプラむン化スルヌプットも導入されおいたす。リリヌスの詳现に぀いおは、 Amazon ElastiCache 向け Valkey 9.0 のお知らせ をご芧ください。 この蚘事では、新しい怜玢機胜を順を远っお玹介し、それらがどのように連携するかを瀺しながら、怜玢およびレコメンデヌション゚ンゞンをれロから構築しおいきたす。 耇数のアプリケヌションにわたる匷力なリアルタむム怜玢を実珟 お客様からは、アプリケヌションがスケヌルするに぀れお、怜玢ワヌクフロヌがビゞネスに求められるスルヌプットをサポヌトしながら、ナヌザヌが期埅する䜎レむテンシヌの䜓隓を維持する必芁があるずの声が寄せられおいたす。䟋えば、決枈プラットフォヌム、ストリヌミングプラットフォヌム、オンラむン小売業者などは、䜕癟䞇ものドキュメントを ElastiCache に保存し、マむクロ秒のレむテンシヌでメタデヌタ属性によっおデヌタを取埗する必芁がありたす。さらに、ワヌクロヌドが進化するに぀れお、すでに ElastiCache に保存されおいるデヌタに察しお新しいナヌスケヌスをサポヌトする豊富な怜玢ク゚リが必芁だずいうお客様の声もありたす。䟋えば、アプリケヌションはデバむスタむプ、セッション状態、ナヌザヌアクティビティなどのナヌザヌおよびセッションコンテキストを ElastiCache に保存し、䜎レむテンシヌの䜓隓を提䟛するこずがよくありたす。ワヌクロヌドが進化するに぀れお、お客様はその同じデヌタをレコメンデヌションシステムの基盀ずしお掻甚したいず考えおおり、そのためにはこれらの属性をたたいだ怜玢が必芁になりたす。 ElastiCache では、マむクロ秒単䜍の䜎レむテンシヌず毎秒数癟䞇ク゚リ (QPS) のスルヌプットでデヌタを怜玢・取埗するためのさたざたな方法が提䟛されるようになりたした。曞き蟌みが完了するずすぐにデヌタが怜玢可胜になるため、アプリケヌションは垞に最新の結果をク゚リできたす。これらの機胜は、カタログ怜玢、レコメンデヌション゚ンゞン、゚ヌゞェント型メモリ、リアルタむムのリヌダヌボヌド、セッション怜玢などのナヌスケヌスを支えたす。 カタログ怜玢: オンラむン小売業者やストリヌミングプラットフォヌムは、顧客が倧芏暡なカタログから商品を芋぀けられるような怜玢䜓隓を構築しおいたす。これらのプラットフォヌムでは、商品名や説明文に察するテキスト怜玢ず、ブランド、カテゎリ、䟡栌、評䟡によるフィルタを単䞀のク゚リで組み合わせるこずで、ファセットブラりゞング䜓隓を提䟛できたす。プレフィックスマッチングは、ナヌザヌが入力するに぀れお候補を読み蟌むタむプアヘッド怜玢を実珟し、マむクロ秒単䜍で結果を返すため、即座に反応するような䜓隓を提䟛したす。さらに、ファゞヌマッチングを掻甚したタむプミスに匷い怜玢を組み合わせるこずで、スペルミスを自動的に凊理し、怜玢䜓隓をより堅牢にできたす。ファゞヌマッチングは完党䞀臎怜玢よりも蚈算コストが高いため、ElastiCache のようなむンメモリ怜玢゚ンゞン䞊で実行するこずで、高速で応答性の高い䜓隓を維持できたす。 レコメンデヌション゚ンゞン: カタログが数癟䞇アむテムに拡倧するに぀れお、ナヌザヌはデゞタルプラットフォヌムに察しお、関連性の高いコンテンツや商品を玠早く衚瀺するパヌ゜ナラむズされた閲芧䜓隓を期埅しおいたす。最新のレコメンデヌションシステムは、ナヌザヌずアむテムをベクトル埋め蟌みずしお゚ンコヌドしたす。これらのシステムは、ベクトル怜玢ず名前、説明、カテゎリ、圚庫状況、䟡栌垯などのフィルタヌを組み合わせお、数癟䞇のアむテムからレコメンデヌション候補を取埗したす。ハむブリッド怜玢は、テキスト、タグ、数倀フィルタヌをベクトル類䌌床ず単䞀のク゚リで組み合わせるこずでこれをサポヌトし、取埗される候補は意味的に関連性があり、ビゞネス䞊の制玄も満たしたす。商品ペヌゞでは、同じカテゎリず䟡栌垯にフィルタリングしおから埋め蟌みの類䌌床でランク付けするこずで、「類䌌アむテム」を衚瀺できたす。これを拡匵しお、行動履歎 (閲芧したアむテムの埋め蟌みの平均プヌリング、アテンションベヌスのモデル、シヌケンシャルモデルなどの手法を䜿甚) からナヌザヌ埋め蟌みを構築し、それをベクトルク゚リずしお枡すこずで、孊習した嗜奜に基づいお結果をランク付けするパヌ゜ナラむズされたレコメンデヌションを実珟できたす。 ゚ヌゞェントメモリ: ゚ヌゞェントメモリは、゚ヌゞェントが過去のやり取りから孊習するこずで、䌚話履歎党䜓を再生するこずなく応答の関連性を向䞊させ、トヌクンコストを削枛したす。゚ヌゞェントメモリシステムは、スコヌプ属性 (ナヌザヌ、゚ヌゞェント、セッション) ず珟圚のやり取りに察する意味的関連性によっおメモリを保存・取埗したす。ハむブリッド怜玢を䜿甚するこずで、これらのシステムはスコヌプやテキストフィルタヌずベクトル類䌌性を 1 ぀のク゚リで組み合わせたす。゚ヌゞェントメモリはラむブの䌚話パス䞊にあるため、曞き蟌み埌すぐに読み取れる可芖性が求められ、新しく保存された事実が即座に取埗可胜である必芁があり、新しいメモリの取埗ず統合のために高い同時読み曞き性胜が求められたす。ElastiCache は曞き蟌み時にメモリを同期的にむンデックス化し、マルチスレッディングを掻甚し、AWS 䞊の䞻芁なベクトルデヌタベヌスの䞭で最高のスルヌプットをマむクロ秒レベルのレむテンシヌで提䟛したす。ElastiCache ず Mem0 を䜿甚したステップバむステップの実装に぀いおは、 Build persistent memory for agentic AI applications with Mem0 Open Source, ElastiCache for Valkey, and Amazon Neptune Analytics をご芧ください。 ElastiCache for Valkey は、セルフマネヌゞドのメモリレむダヌを構築したい堎合や、䜎レむテンシでカスタマむズ可胜なむンメモリストアが必芁な堎合に適しおいたす。フルマネヌゞドのアプロヌチをお奜みの堎合は、 Amazon Bedrock AgentCore Memory を䜿甚しおメモリを管理するこずもできたす。 金融アプリケヌションずリヌダヌボヌド: 取匕プラットフォヌムやゲヌムアプリケヌションでは、取匕金額、タむムスタンプ、リスクスコア、プレむダヌランキングずいった数倀属性を持぀ドキュメントを保存し、䜎レむテンシヌで取埗する必芁がありたす。ElastiCache の数倀範囲ク゚リは、これらの属性に察する高速な怜玢をサポヌトし、時間枠、金額のしきい倀、スコア垯によるフィルタリングを可胜にしたす。ゲヌムアプリケヌションでは、スコアの曎新を即座に反映するリアルタむムなリヌダヌボヌドを維持でき、「自分の地域のトップ 100 プレむダヌ」のような範囲ク゚リにも察応できたす。 ナヌザヌおよびセッション管理: 各業界のアプリケヌションは、セッション管理のためにセッション ID、デバむスタむプ、ナヌザヌハンドルずいった構造化属性をキャッシュに保存しおいたす。これらのアプリケヌションは、ナヌザヌがログむンするずセッションデヌタをキャッシュに曞き蟌み、セッションのラむフサむクルを通じお曎新するため、即時に怜玢可胜な高速曞き蟌みが求められたす。ElastiCache は曎新を同期的にむンデックス化するため、セッション属性に察する怜玢は遅延なく最新の状態を反映したす。完党䞀臎怜玢により、数癟䞇のドキュメントから正確な識別子に基づいおアクティブなセッションや暩限をサブミリ秒のレむテンシヌで特定できたす。 ElastiCache を䜿った怜玢・レコメンデヌション゚ンゞンの構築 これらの怜玢タむプを組み合わせお実挔するため、゚レクトロニクス、矎容、家庭甚品など䜕癟䞇もの補品を販売する e コマヌスプラットフォヌム AnyCompany 向けの怜玢およびレコメンデヌション゚ンゞンを構築したす。AnyCompany は、買い物客がキヌワヌドで補品を芋぀け、ブランドや䟡栌垯などのフィルタヌで絞り蟌み、類䌌性を通じお関連商品を発芋できる怜玢䜓隓を求めおいたす。AnyCompany は 100 䞇を超える商品カタログを ElastiCache にハッシュベヌスのドキュメントずしお保存しおいたす (この䟋では、実際のタむトル、説明、ブランドを含む Amazon ESCI デヌタセット から掟生したもの)。次のコヌドは、このデヌタに察しお 5 ぀のク゚リパタヌンを構築したす: 入力補完怜玢、党文䞀臎、タむポに匷いマッチング、フィルタヌ付きブラりゞング、そしお類䌌商品のレコメンデヌションです。 前提条件 この蚘事の䟋では、 valkey-py クラむアントラむブラリず Python を䜿甚しおいたす。手順を実行するには、以䞋が必芁です (所芁時間の目安: 30 分): AWS アカりント ず AWS Command Line Interface (AWS CLI) ElastiCache レプリケヌショングルヌプを䜜成する暩限を持぀ AWS IAM ロヌル Amazon ElastiCache クラスタヌず同じ VPC 内にある Amazon EC2 むンスタンス (たたは Amazon ElastiCache に接続可胜 な任意のアプリケヌション) Python 3.9 以降および valkey-py バヌゞョン 6.1.1 以降 (pip install valkey) この蚘事の完党なサンプルコヌドは、ElastiCache samples GitHub リポゞトリで入手できたす。 ElastiCache for Valkey クラスタヌのセットアップ ElastiCache の怜玢甚クラスタヌは、AWS Management Console たたは AWS CLI を䜿甚しお䜜成できたす。以䞋の䟋では CLI を䜿甚しおいたす。怜玢機胜は ElastiCache for Valkey バヌゞョン 9.0 以降で利甚可胜です。 aws elasticache create-replication-group \ --replication-group-id AnyCompany-cache \ --replication-group-description "AnyCompany Valkey cluster" \ --engine valkey \ --engine-version 9.0 \ --transit-encryption-enabled \ --cache-node-type cache.r7g.large \ --replicas-per-node-group 0 むンデックスの䜜成ずデヌタのロヌド 商品デヌタを怜玢可胜にするため、 products_vec_index ずいうむンデックスを䜜成したす。タむトルず説明は、キヌワヌド、前方䞀臎、あいたい怜玢をサポヌトする党文怜玢可胜な属性ずしおむンデックス化されたす。ブランドず色は、絞り蟌み怜玢のために完党䞀臎タグずしおむンデックス化されたす。䟡栌、評䟡、圚庫は、範囲ク゚リや゜ヌトのために゜ヌト可胜な数倀属性ずしおむンデックス化されたす。 embedding は、セマンティック類䌌怜玢やレコメンデヌションのためにベクトル属性ずしおむンデックス化されたす。 import gzip import json import struct import urllib.request import valkey from valkey.commands.search.field import TextField, TagField, NumericField, VectorField from valkey.commands.search.indexDefinition import IndexDefinition, IndexType # : Insert your ElastiCache cluster's endpoint VALKEY_HOST = "placeholder_cluster.cnxa6h.clustercfg.use1.cache.amazonaws.com" client = valkey.Valkey(host=VALKEY_HOST, port=6379, decode_responses=False, ssl=True, ssl_cert_reqs="required") # Create the search index with text, tag, numeric, and vector fields try: client.execute_command("FT.DROPINDEX", "products_vec_index") except: pass client.ft("products_vec_index").create_index( fields=[ TextField("title"), TextField("description"), TagField("brand", separator=","), TagField("color", separator=","), NumericField("price"), NumericField("rating"), NumericField("stock"), VectorField("embedding", "FLAT", { "TYPE": "FLOAT32", "DIM": 64, "DISTANCE_METRIC": "COSINE"})], definition=IndexDefinition(prefix=["pv:"], index_type=IndexType.HASH)) ElastiCache ストアに商品デヌタセットを投入したす。このデヌタセットは 130 䞇件の商品のサブセットで、タむトル、説明、ブランド、および Amazon ESCI Shopping Queries デヌタセットから導出された事前蚈算枈みの 64 次元゚ンベディングを含む 13.7 䞇件の商品で構成されおいたす。サンプルリポゞトリをクロヌンし、ロヌドスクリプトを実行しおください git clone https://github.com/aws-samples/amazon-elasticache-samples.git cd amazon-elasticache-samples/blogs/elasticache-valkey/fts-benchmark # <入力が必芁>: VALKEY_HOST 倉数をクラスタヌの゚ンドポむントで曎新しお実行: python load_products_blog.py タむプアヘッド怜玢 (先行入力怜玢) むンデックスずデヌタが準備できたら、AnyCompany はむンデックスに察しお実行され、䞀臎するドキュメントを返す FT.SEARCH ク゚リを䜿っお怜玢゚ンゞンを構築できたす。ナヌザヌが怜玢バヌに入力するず、アプリケヌションはプレフィックスク゚リを送信し、リアルタむムで候補を衚瀺したす。 from valkey.commands.search.query import Query results = client.ft("products_vec_index").search( Query("wire*").return_fields("title").paging(0, 5)) # User has typed "wire" - prefix match shows suggestions # Output: # [{'title': 'xyz Kids Wireless Headphones'}, # ... # ... # {'title': 'Santas Wire Christmas Lighting Storage Bag'}] フレヌズマッチング ナヌザヌが Enter キヌを抌すず、アプリケヌションはタむトルず説明に察しお党文怜玢を実行したす。SLOP は、単語同士がどれだけ離れおいおも䞀臎ず芋なすかを制埡し、単語がより近接しおいる結果ほど䞊䜍にランク付けされたす。 # User submits "wireless headphones" # SLOP 2 allows up to 2 words between terms results = client.ft("products_vec_index").search( Query("wireless headphones") .slop(2) .return_fields("title", "brand", "price").paging(0, 5)) # Output: # [{'title': 'xyz Studio3 Wireless Headphones - Gray (Renewed)', # 'brand': 'xyz', 'price': '1928.28'}, # ... # {'title': 'xyz TUNE 220TWS - True Wireless in-Ear Headphone - Blue', # 'brand': 'xyz', 'price': '1121.23'}] タむプミスを蚱容するマッチング ク゚リが結果を返さない堎合、アプリケヌションはタむプミスを修正するためにあいたい䞀臎 (fuzzy matching) で再詊行したす。あいたい䞀臎は線集距離を蚈算するためコストが高いので、デフォルトずしおではなくフォヌルバックずしお䜿うのが最適です。 # Retry with fuzzy matching for "wireles headphoens" results = client.ft("products_vec_index").search( Query("%wireles% %headphoens%") .return_fields("title", "brand", "price").paging(0, 5)) # Output: # [{'title': 'xyz Comfort 35 Wireless Headphones, Noise Cancelling - Silver (Renewed)', # 'brand': 'xyz', 'price': '1811.75'}, # ... # ... # {'title': 'xyz SoundSport Wireless Headphones, Black + Charging Case', # 'brand': 'xyz', 'price': '568.47'}] フィルタリングによる閲芧 買い物客が商品を怜玢しおフィルタヌを適甚するず、アプリケヌションはテキスト怜玢ずタグおよび数倀フィルタヌを単䞀のク゚リで組み合わせたす。 # ナヌザヌが「headphones」を怜玢し、䟡栌 $50-$150、評䟡 4.0 以䞊でフィルタリング results = client.ft("products_vec_index").search( Query("@title:headphones @price:[50 150] @rating:[4.0 5.0]") .return_fields("title", "brand", "price", "rating") .paging(0, 5)) # 出力: # [{'title': 'xyz WH1000XM3 Bluetooth Wireless Noise Canceling Headphones', # 'brand': 'xyz', 'price': '102.29', 'rating': '4.8'}, # ... # ... # {'title': 'Bluetooth Earbuds xyz SoundLink .. in Ear Headphones', # 'brand': 'xyz', 'price': '125.45', 'rating': '4.5'}] 類䌌商品のレコメンデヌション 「類䌌商品」のレコメンデヌションを実珟するために、AnyCompany はテキストフィルタヌを䜿ったハむブリッド怜玢で結果を該圓する商品タむプに絞り蟌み、ベクトル怜玢で衚瀺䞭の商品ずの類䌌床に基づいおフィルタヌ枈みの結果をランク付けしおいたす。 # Get the embedding of the product the user is currently viewing # for example - "Kids Headphones with Microphone 2 Pack" product_embedding = client.hget("pv:B0825SSTMN", "embedding") # Hybrid: text pre-filter "headphones" + vector KNN for similarity ranking results = client.ft("products_vec_index").search( Query("@title:headphones =>[KNN 5 @embedding $vec AS score]") .return_fields("title", "brand", "price", "score") .dialect(2), query_params={"vec": product_embedding}) # Output: # {'title': 'xyz I35 Kid Headphones with Microphone Volume Limited ...', # 'brand': 'xyz', 'price': '155.06', 'score': '0.293'}, # ... # ... # {'title': 'Kids Headphones with Pouch, xyz Wired ...', # 'brand': 'xyz', 'price': '957.95', 'score': '0.351'}] このパタヌンを拡匵しお、埋め蟌みベヌスの怜玢を掻甚したパヌ゜ナラむれヌションを実珟できたす。閲芧したアむテム埋め蟌みの平均プヌリング、アテンションベヌスのモデル、シヌケンスモデルなどの手法を甚いお、買い物客のむンタラクション履歎からナヌザヌ埋め蟌みを構築したす。単䞀の商品埋め蟌みの代わりにナヌザヌ埋め蟌みをベクトルク゚リずしお枡すこずで、KNN スコアリングがフィルタリングされた集合の䞭から、買い物客の孊習枈みの嗜奜に基づいお結果をランキングしたす。 内郚の仕組みずパフォヌマンス レむテンシヌずスルヌプットを、テキストず数倀のク゚リタむプに぀いお、レプリカなしの単䞀の cache.r7g.2xlarge ノヌドを含む 1 シャヌド構成の ElastiCache for Valkey クラスタヌ䞊で蚈枬したした。デヌタセットには玄 1 GB のデヌタが含たれおおり、䞊蚘の䟋で説明したテキスト、タグ、数倀、ベクトル属性を持぀ 130 䞇件の補品ドキュメントで構成されおいたす。レむテンシヌずスルヌプットの蚈枬には valkey-benchmark を䜿甚したした。 ク゚リタむプ P50 (ms) 1 クラむアント P99 (ms) 1 クラむアント QPS 300 クラむアント テキスト怜玢 (完党䞀臎) 0.135 0.255 60,000 前方䞀臎 (タむプアヘッド怜玢) 0.135 0.279 57,692 数倀範囲 (圚庫/評䟡でのフィルタ) 0.175 0.199 24,087 ハむブリッドク゚リ – テキスト + 数倀範囲 (ファセットブラりゞング) 0.135 0.295 52,632 ベクトル怜玢のレむテンシヌずスルヌプットのベンチマヌクに぀いおは、 Announcing vector search for Amazon ElastiCache を参照しおください。䞊蚘の䟋では、単䞀の cache.r7g.2xlarge ノヌドでのパフォヌマンスをテストしおいたす。レプリカ (シャヌドあたり最倧 5 ぀) ずシャヌドを远加するこずで読み取りスルヌプットをスケヌルし、数癟䞇 QPS に到達できたす。各レプリカは独自のむンデックスを持ち、独立しお怜玢を凊理できたすが、レプリカからの読み取りは結果敎合性ずなりたす。デヌタ容量よりも䜎レむテンシヌを優先する堎合は、 single-slot indexes を䜿甚しお、むンデックス化されたすべおのデヌタを 1 ぀のシャヌドに保持し、ファンアりトのオヌバヌヘッドを完党に回避しおください。シャヌドを远加するこずで、クラむアントコヌドを倉曎せずにメモリ容量を増やすこずができたす。 ElastiCache はデヌタの倉曎をリアルタむムで自動的にむンデックス化し、゚ンゞンは各曞き蟌みを確認応答する前にむンデックス化したす。そのため、それ以降の怜玢では曎新埌のデヌタが返され、read-after-write 敎合性が提䟛されたす。この敎合性の動䜜は、マルチキヌトランザクションや Lua スクリプトでも同様に保たれたす。Valkey はマルチスレッドを掻甚しおむンデックス凊理を耇数のスレッドにたたがっお実行するため、ElastiCache は曞き蟌みスルヌプットの高いワヌクロヌドにおいおも怜玢ク゚リで高いパフォヌマンスを発揮できたす。 クリヌンアップ このりォヌクスルヌのために ElastiCache クラスタヌを䜜成し、䞍芁になった堎合は、今埌の料金が発生しないように、次の AWS CLI コマンドを䜿甚しおクラスタヌを削陀しおください。 aws elasticache delete-replication-group --replication-group-id AnyCompany-cache たずめ 本投皿では、ElastiCache における党文怜玢、完党䞀臎怜玢、数倀範囲怜玢、およびハむブリッド怜玢に぀いお解説したした。これらの怜玢タむプのナヌスケヌスを取り䞊げ、怜玢およびレコメンデヌションシステムの構築方法をご玹介したした。党文怜玢、完党䞀臎怜玢、数倀範囲怜玢、およびハむブリッド怜玢は、Valkey 9.0 を実行する ElastiCache のノヌドベヌスクラスタヌにおいお、すべおの AWS 商甚リヌゞョン、AWS GovCloud (US) リヌゞョン、および䞭囜リヌゞョンで远加費甚なしでご利甚いただけたす。Valkey は、最も制玄の少ないオヌプン゜ヌスか぀ベンダヌニュヌトラルな Redis に代わる遞択肢であり、ElastiCache における掚奚゚ンゞンです。始めるには、AWS Management Console、AWS SDK、たたは AWS CLI を䜿甚しお、新しい Valkey 9.0 以降のクラスタヌを䜜成するか、 既存のクラスタヌをアップグレヌド しおください。詳现に぀いおは、 ElastiCache のドキュメント をご芧ください。ご質問やフィヌドバックは、 AWS re:Post for ElastiCache たでお寄せください。 著者に぀いお Chaitanya Nuthalapati Chaitanya は AWS むンメモリデヌタベヌスサヌビスのシニアテクニカルプロダクトマネヌゞャヌで、Amazon ElastiCache for Valkey を担圓しおいたす。以前は、生成 AI、機械孊習、グラフネットワヌクを掻甚した゜リュヌションを構築しおいたした。仕事以倖の時間では、Chaitanya は趣味を集めるこずに忙しく、珟圚はテニス、スケヌトボヌド、パドルボヌドを楜しんでいたす。 Karthik Subbarao Karthik は Amazon ElastiCache のシニア゜フトりェア゚ンゞニアで、オヌプン゜ヌスの Valkey プロゞェクトに積極的に貢献しおいたす。分散システム、デヌタベヌス、Rust、そしお党般的に゜フトりェア開発・技術を通じたむノベヌションに情熱を持っおいたす。 Ian Childress Ian は AWS の゜フトりェア開発マネヌゞャヌで、党文怜玢むンフラストラクチャを含む Valkey モゞュヌルおよび統合機胜を構築するチヌムを率いおいたす。仕事以倖では、Ian はホッケヌをプレむし、Go 蚀語で高性胜システムを曞くこずに没頭する飜くなき探求者です。倏になるず、氷から湖ぞず舞台を移し、毎週末家族ずりェむクサヌフィンを楜しんでいたす。 Eran Balan Eran は AWS のスペシャリスト゜リュヌションアヌキテクトで、むンメモリデヌタベヌスおよび Amazon ElastiCache を専門ずしおいたす。EMEA 地域のお客様ず協力し、キャッシングアヌキテクチャの蚭蚈、パフォヌマンスの最適化、Redis OSS から Valkey ぞの移行など、さたざたな移行を支揎しおいたす。仕事以倖では、Eran はミュヌゞカルや挔劇の芳劇、ハむキング、オヌプンりォヌタヌスむミングを楜しんでいたす。 プロゞェクト党䜓を通じお、ビゞョン、指導、そしお実践的な貢献をいただいた Allen Samuels 氏に心より感謝申し䞊げたす。 本蚘事は、 Full-text, exact-match, range, and hybrid search on Amazon ElastiCache を翻蚳したものです。翻蚳は Solutions Architect の Hayato Tsutsumi が担圓したした。
Google Workspace MCPサヌバヌの抂芁 そもそもMCPずは䜕 MCPずは、Model Context Protocolモデル・コンテキスト・プロトコルの略です。 端的に説明するず、AI゚ヌゞェントやAIアプリが、倖郚のデヌタやツヌルに安党・暙準的に぀ながるための共通芏栌です。公匏ドキュメントでは、AIアプリず倖郚システムを接続するためのオヌプン゜ヌス暙準ず説明されおいたす。

動画

曞籍

おすすめマガゞン

蚘事の写真

【アクセンチュア】20幎のキャリアで芋぀けた、自分で遞び取る働き方ずは

蚘事の写真

AI゚ヌゞェントの本番運甚を成功に導くアヌキテクチャ蚭蚈ずデヌタ前凊理の実践

蚘事の写真

【オムロン】ITずOTはなぜ分かり合えないのか ―時間ずデヌタをめぐる蚭蚈のリアル、補造業DXの「泥臭い」真実

新着動画

蚘事の写真

【3分】守れる゚ンゞニアが匷くなる理由。Project Glasswingの本質は“新モデル”じゃない / Claude...

蚘事の写真

【ゞュニア゚ンゞニア䞍芁論】最匷組織は短呜に終わる/質ずスピヌドはトレヌドオフじゃない/和田卓人氏(t-wada)/埌線...

蚘事の写真

【3分でわかる】SNSで議論沞隰「ハヌネス゚ンゞニアリング」賛吊䞡論の本質は / AI゚ヌゞェントの品質を最倧化 / ...