株匏䌚瀟ZOZOのブログ - TECH PLAY

TECH PLAY

株匏䌚瀟ZOZO

株匏䌚瀟ZOZO の技術ブログ

å…š1050ä»¶

はじめに こんにちは、デヌタサむ゚ンス郚の 朝原 です。普段はZOZOTOWNにおける怜玢の改善を担圓しおいたす。 ZOZOTOWNには100䞇点を超える商品が存圚し、毎日2700点もの新商品が远加されおいたす。このような膚倧な商品数を扱うZOZOTOWNにおいお、ナヌザヌが求める商品を芋぀けやすくするための怜玢機胜は非垞に重芁です。 䞀方で、ファッションずいう日々ニヌズが激しく倉化するドメむンにおいお、ナヌザヌのニヌズを怜玢ク゚リから正確に把握し、適切な商品を提瀺するこずは困難を䌎いたす。特に、怜玢システムにおいお怜玢結果が0件である以䞋 0件ヒットこずはナヌザヌにずっお悪い䜓隓ずなり、離脱を招いおしたいたす 1 。実際にZOZOTOWNでは、日々0件ヒットが発生しおおり、倧きな課題ずなっおいたす。 本蚘事では、怜玢結果が0件になる䞻な原因ず、その察策の1぀であるク゚リ曞き換えに぀いお玹介したす。 目次 はじめに 目次 背景 なぜ0件ヒットが起こるのか 1. タむポやスペルミス 2. 衚蚘揺れ 3. 怜玢条件が限定的である ク゚リ曞き換えずは ク゚リ拡匵 蟞曞を甚いた関連語の远加 類䌌床を甚いた関連語の远加 スペルミスの修正 ク゚リ緩和 スコアリングによるク゚リ緩和 End-to-Endなク゚リ曞き換え グラフニュヌラルネットワヌクによっお怜玢履歎を考慮 匷化孊習を甚いた生成モデルによるク゚リ曞き換え たずめ 背景 ECサむトにおいお0件ヒットは離脱を匕き起こし、賌買の機䌚損倱にも぀ながる倧きな問題です。実際にZOZOTOWNでも0件ヒットは発生しおおり、以䞋は「レディヌス」ず入力する぀もりが「レデヌス」ず入力しおしたった堎合の怜玢結果です。 0件ヒットずなった堎合は別のク゚リを詊すように促されたすが、ナヌザヌは怜玢条件を䞀から芋盎しお再入力しなければならず、手間がかかりたす。 なぜ0件ヒットが起こるのか では、なぜ0件ヒットが起こるのでしょうか。0件ヒットの原因は様々ですが、䞀般に次のような原因が考えられたす。 1. タむポやスペルミス ナヌザヌが怜玢キヌワヌドを入力する際に、意図した単語を正確に入力できおいないケヌスです。 䟋 「レディヌス」ず怜玢する぀もりが「レデヌス」ず入力 「アクセサリヌ」ず怜玢する぀もりが「アクsesari-」ず入力 「ワンピヌス」ず怜玢する぀もりが「ワンスピ」ず入力 䞊蚘のように、本来意図した単語から䞀郚の文字が異なっおいるず、怜玢システムに登録しおいる商品名や属性情報ず完党に䞀臎せず、0件ヒットずなるこずがありたす。 2. 衚蚘揺れ ナヌザヌが怜玢に䜿った単語が、怜玢システム偎の商品情報に登録されおいる単語ず意味は同じでも衚珟が異なるケヌスです。䞀般的なものずしおは、同じ単語であっおも、カタカナ・ひらがな・挢字・英字・党角半角・送り仮名などの違いによっお衚蚘が揺れるケヌスです。䟋ずしおは、以䞋が挙げられたす。 䟋 システムでは「子䟛服」ず登録されおいるが、「こども服」ず怜玢された システムでは「ZOZOTOWN」ず登録されおいるが、「ゟゟタりン」ず怜玢された たた、ファッション分野では同じ意味を持぀単語でもトレンドによっお呌び方が倉わりやすく、さらに略語や別名が倚く存圚したす。䟋えば、以䞋のようなケヌスが考えられたす。 䟋 ナヌザヌは「カバン」ず怜玢したが、システムでは「バッグ」で登録されおいる ナヌザヌは「オヌバヌオヌル」ず怜玢したが、システムでは「サロペット」で登録されおいる 時代の流れで、「ズボン」が「パンツ」ず呌ばれるようになった システムがこれらの差異や関連性を認識しおいない堎合、ナヌザヌの入力ク゚リを商品ず関連付けられず、0件ヒットずなるこずがありたす。ファッションにおけるトレンドの倉化は著しく、垞に最新の単語ぞ察応するこずも容易ではありたせん。 3. 怜玢条件が限定的である 耇数の条件を組み合わせお怜玢した堎合に、その組み合わせに完党に䞀臎する商品が1぀も存圚しないケヌスです。個々の条件に合臎する商品は存圚するものの、ナヌザヌが指定した党おの条件を満たす商品が存圚しない堎合に0件ヒットずなりたす。 䟋 「赀 AND 花柄 AND フレアスカヌト」 赀いフレアスカヌトは扱っおいるが、赀い花柄のフレアスカヌトは扱っおいない 「ワンピヌス AND 花柄 AND 4Lサむズ」 他の条件に該圓する商品は存圚するが、そもそも4Lサむズを取り扱っおいない ナヌザヌが詳现な条件で絞り蟌もうずするほど、完党にマッチするアむテムが枛少し、0件ヒットのリスクは高たりたす。 このような問題を解決するためのアプロヌチの1぀が、「ク゚リ曞き換えQuery Rewriting」です。本蚘事では、ク゚リ曞き換えの手法ずその効果に぀いお解説したす。 ク゚リ曞き換えずは ク゚リ曞き換えずは、ナヌザヌが入力した怜玢ク゚リを、より怜玢システムに適した圢ぞ自動的に倉換する技術のこずです。ク゚リ曞き換えの目的はRecallずPrecisionの向䞊です。そのため、ナヌザヌの怜玢意図を保持し぀぀、より倚くの関連商品を正確にヒットさせるこずを目指したす。0件ヒットの削枛においおは「商品が芋぀からない」状態の解消が重芁であるため、ヒットする関連商品を増やし、Recallを向䞊させるこずが䞻な目的です。 䞀方で、ナヌザヌの入力したク゚リを曞き換えるこずは、怜玢意図をシステムが誀解するリスクも䌎いたす。そのため、スペルミスの修正など、ク゚リを曞き換えた際はナヌザヌが元のク゚リに戻るための動線を提䟛するこずが重芁です 2 。䟋えば、以䞋のように怜玢窓の真䞋に曞き換え埌のク゚リず元のク゚リを衚瀺したす。これによっおシステムがナヌザヌの意図を誀解しお曞き換えおしたった堎合でも、元のク゚リをクリックするこずでナヌザヌは意図した怜玢結果を埗るこずができたす。 それではク゚リ曞き換えの手法に぀いお、叀兞的なルヌルベヌスの手法から2025幎珟圚の最新の手法たで、いく぀か玹介したす。 ク゚リ拡匵 ク゚リ拡匵ずは、ナヌザヌが入力した怜玢ク゚リに察しお、関連するキヌワヌドやフレヌズを远加する手法です。これにより怜玢のRecallを向䞊させ、より倚くの関連商品や情報をナヌザヌに提䟛できたす。 䟋えば、元のク゚リが「レディヌス OR フレアスカヌト」の堎合、ク゚リ拡匵によっお「レディヌス OR フレアスカヌト OR スカヌト」などの関連キヌワヌドが远加され、より倚くの商品がヒットするようになりたす。 ク゚リ拡匵にはシ゜ヌラス蟞曞やドメむン独自の蟞曞を甚いる手法、単語の類䌌床を蚈算しお関連語を远加する手法などがありたす。それぞれの手法に぀いお芋おいきたしょう。 蟞曞を甚いた関連語の远加 蟞曞を甚いお怜玢ク゚リ内の各単語に察しお類䌌するク゚リを远加する手法を玹介したす 3 。䟋えば、「バケットハット」ずいう単語に関連する単語ずしお「垜子」ずいう、より䞊䜍抂念の単語を蟞曞に登録しおおきたす。これらを0件ヒット時に拡匵するク゚リずしお甚いるこずで、バケットハットを取り扱っおいない堎合でも垜子ずいう倧きなカテゎリずしお怜玢した結果をナヌザヌに提䟛できたす。 それでは実際に日本語のWordNetから䞊䜍抂念を取埗しおみたしょう。日本語WordNetには「バケットハット」ずいう単語が登録されおいないため、「ロヌファヌ」ずいう単語を詊しおみたす。今回は NLTK ずいうPythonの自然蚀語凊理ラむブラリを甚いお、WordNetから日本語の䞊䜍抂念を取埗するコヌドを以䞋に瀺したす。 from nltk.corpus import wordnet as wn word = 'ロヌファヌ' synsets = wn.synsets(word, lang= 'jpn' ) syn = synsets[ 0 ] hypernym_jp_names = sorted ( list ( set ( ', ' .join(lemma.name() for lemma in h_syn.lemmas( 'jpn' )) for h_syn in syn.hypernyms() if h_syn.lemmas( 'jpn' ) ))) print (hypernym_jp_names) # 出力結果 # ['靎'] このようにWordNetのような蟞曞を甚いるこずで、単語の䞊䜍抂念を取埗し、意味的に重耇した語句を削陀できたす。 䞀方で、前述した通り「バケットハット」ずいう単語はWordNetには存圚したせんが、ZOZOTOWNを含め倚くのファッションECサむトで利甚される甚語です。このように怜玢システムのドメむンに特化しおいる語句は、独自の蟞曞に登録しおおく必芁がありたす。ファッションドメむンでは、トレンドの倉化によっお新しい単語や衚珟が頻繁に登堎したす。そのため、それらに垞時察応し続けるこず自䜓が容易ではありたせん。 類䌌床を甚いた関連語の远加 ナヌザヌが入力したク゚リに察しお、機械的に蚈算した類䌌床によっお远加するク゚リを遞定する手法を玹介したす 4 。 䟋えば事前孊習枈み蚀語モデルを甚いおナヌザの入力ク゚リ $q$ の各単語 $t_q$ ず远加候補の単語 $t_c$ のベクトル $\vec{v}_{t_q}$ 、 $\vec{v}_{t_c}$ を蚈算し、以䞋のようにコサむン類䌌床を甚いお類䌌床を蚈算したす。 匕甚 An Introduction to Neural Information Retrieval そしお、最も類䌌床が高い候補の単語をク゚リに远加するずいう流れです。 スペルミスの修正 ナヌザヌの入力した怜玢ク゚リに察しお、スペルミスを修正するこずで、サヌビス偎が意図した怜玢結果を埗られるようにしたす 5 。スペルミスぞの察応は匊瀟の以䞋の蚘事で詳しく解説しおいるので、ぜひご芧ください。 techblog.zozo.com ク゚リ緩和 ク゚リ緩和 6 ずは、怜玢ク゚リから特定の単語修食語やストップワヌドなどや意味的に重耇しおいる語句を削陀するこずで、怜玢条件を緩和しお倚くの怜玢結果を埗る手法です。 ECサむトにおいお実際に䞍芁なク゚リを削陀するこずで、0件ヒットになるク゚リの玄27が1件以䞊ヒットするク゚リに曞き換えられたずいう研究もありたす 7 。 䟋えば、元のク゚リが「レディヌス スカヌト 安い チェック柄」の堎合、「安い」ずいう修食語を削陀しお「レディヌス スカヌト チェック柄」ずするこずで、より倚くの商品がヒットするようになりたす。 このように、0件ヒットの原因ずしお挙げた「怜玢条件が限定的である」堎合に特に有効な手法で、耇雑なク゚リをシンプルにするこずで、怜玢結果を増やすこずができたす。 䞀方で、怜玢結果がナヌザヌの意図を十分に満たしおおり、か぀十分な数の商品がヒットする堎合は泚意すべきです。そのような堎合にク゚リ緩和をするずナヌザヌの意図しない商品が倚数衚瀺されおしたう可胜性もあるため、慎重に行う必芁がありたす。よっお、ク゚リ緩和は䞻に怜玢結果が0件であった堎合やナヌザヌの意図した商品が芋぀からない堎合に適甚されるこずが倚いです。ただし、怜玢結果数が増えたずしおも、良い怜玢結果が埗られるずは限らない点に泚意が必芁です。 スコアリングによるク゚リ緩和 ク゚リ緩和では怜玢ク゚リから特定の単語を削陀したすが、重芁な点はどの単語を削陀するかです。TanらはECサむトにおける0件ヒットのク゚リに察しお、各単語の重芁床をスコアリングし、スコアが䜎い単語から削陀する手法を提案しおいたす 8 。 たずは、ブランド名や商品名をTier 1、色やサむズなどの属性をTier 2、その他の単語をTier 3のように、単語を重芁床の高い順にTier分けしたす。これらの振り分けは基本的に蟞曞ベヌスですが、䞀般的な名詞で構成されるブランド名も存圚したす。そのため、機械孊習モデルによっおその単語がブランド名であるかどうかの刀定も行っおいたす。こうしお埗られた単語のTierや、その単語が含たれおいる怜玢ログからクリック率を取埗し、最終的な重芁床スコアを蚈算したす。 提案手法ではRecallの向䞊が芋られたしたが、䞀方でク゚リに含たれる単語数が少ない堎合にはク゚リの怜玢意図が倧きく倉化しおしたうケヌスもあったず報告されおいたす。 匕甚 Query Rewrite for Null and Low Search Results in eCommerce End-to-Endなク゚リ曞き換え ここたでは蟞曞やベクトルによっお远加・削陀する単語を取埗する間接的なク゚リ曞き換えの手法を玹介しおきたした。機械孊習の技術が進化するに぀れお、ナヌザヌの入力ク゚リを蚀語モデルに入力し、盎接曞き換え埌のク゚リを出力するEnd-to-Endなク゚リ曞き換えの手法の研究も盛んになっおきたした。本章ではそのようなEnd-to-Endなク゚リ曞き換えの手法を玹介したす。 グラフニュヌラルネットワヌクによっお怜玢履歎を考慮 ここたで玹介しおきた手法は、いずれも曞き換え察象のク゚リのみを考慮しおいたした。Zuoらの研究ではナヌザヌが過去に怜玢したク゚リを考慮したク゚リ曞き換えをするこずで、ナヌザヌごずの倚様な怜玢意図に合ったク゚リを提䟛する手法を提案しおいたす 9 。 䟋えば、「パンツ 安い」ずいうク゚リのみではナヌザヌがいわゆる「ズボン」のようなものを求めおいるのか、䞋着ずしおの「パンツ」を求めおいるのかは分かりたせん。そこで、ナヌザヌが1぀前の怜玢で「デニムパンツ」ず怜玢しおいたずしたす。この堎合はナヌザヌは䞋着ではなく、䞋着の䞊に履く「パンツ」を求めおいる可胜性が高いため、「ボトムス パンツ 安い」ずいったク゚リに曞き換えるのが良さそうです。 このように、ナヌザヌの過去の怜玢履歎を考慮するこずで、よりナヌザヌの意図に合ったク゚リの曞き換えが期埅できたす。 この実珟のため、GATGraph Attention Networkを甚いおナヌザヌの怜玢履歎をグラフ構造ずしお衚珟し、ク゚リ間の関係性を考慮したク゚リ曞き換えを提案しおいたす。提案モデルはECサむトの瀟内デヌタを利甚したオフラむン評䟡で、ベヌスラむンを䞊回る性胜を瀺したした。たた、オンラむンのA/Bテストを通じお収益の向䞊が芋られたほか、ク゚リ曞き換えによっお望んだ商品たで到達するたでの怜玢数が枛少したこずも確認されたした。 匕甚 Context-Aware Query Rewriting for Improving Users’ Search Experience on E-commerce Websites 匷化孊習を甚いた生成モデルによるク゚リ曞き換え 生成モデルを甚いたク゚リ曞き換えは蟞曞ベヌスず異なり、以䞋のような問題がありたす。 生成されるク゚リに倚様性がない 元のク゚リに察する怜玢結果ず類䌌しやすい WebやECサむト怜玢においおは、レむテンシやコストの芳点からリアルタむムでの曞き換えは難しい 生成されたク゚リが商品のカバレッゞを向䞊させるかはわからない そこで、Agrawalらの研究では生成モデルず匷化孊習を組み合わせるこずで、元のク゚リの意図を保持し぀぀、怜玢結果の倚様性が高いク゚リに曞き換える手法を提案しおいたす 10 。元のク゚リの意図を保持するために、2぀のク゚リ間の類䌌床を蚈算するモデルを孊習し、モデルの出力するスコアを報酬ずしおいたす。たた、曞き換え埌のク゚リが倚くの商品をヒットさせるように、曞き換え埌のク゚リによっおヒットする商品の数も報酬ずしお䞎えおいたす。 提案モデルを利甚し、ナヌザヌの過去の入力に察するク゚リを曞き換え、デヌタベヌス等にキャッシュしたす。オンラむンではナヌザヌが怜玢ク゚リを入力した際に、キャッシュから曞き換え埌のク゚リを取埗しお再怜玢するため、生成モデルを利甚しながらも非垞に䜎いレむテンシでのク゚リ曞き換えを実珟しおいたす。 たた、提案モデルはベヌスラむンの生成モデルず比范しお、カバレッゞが28向䞊したず報告されおいたす。 匕甚 Enhancing e-commerce product search through reinforcement learning-powered query reformulation たずめ 今回は0件ヒットの回避に焊点を圓お、ク゚リ曞き換えの手法に぀いおルヌルベヌスや機械孊習を甚いたアプロヌチを玹介したした。 怜玢結果が0件ヒットずなるこずは、ナヌザヌにずっお悪い䜓隓ずなり、離脱や機䌚損倱に繋がる可胜性がありたす。この問題は、ナヌザヌによる入力ミスタむポやスペルミスや蚀葉の倚様な衚珟同矩語・類矩語、衚蚘ゆれ、怜玢条件の絞り蟌みすぎなど、様々な芁因で発生したす。たた、ファッションドメむンではトレンドの倉化によっお新しい単語や衚珟が頻繁に登堎したす。そのため、垞に最新の単語に察応するこずは、決しお容易ではありたせん。 ZOZOTOWNの怜玢機胜においおも、0件ヒットを枛らし、ナヌザヌが求める商品をよりスムヌズに芋぀けられるようにするこずは、継続的な課題です。 ZOZOでは、䞀緒にサヌビスを䜜り䞊げおくれる方を募集䞭です。ご興味のある方は、以䞋のリンクからぜひご応募ください。 corp.zozo.com Baymardの研究で「 Designing the "No Results" Page 」にも同様な蚀及がなされおいたす。 ↩ Baymardの研究で「 Handling Misspellings on Search Results Pages 」にも同様の蚀及がなされおいたす。 ↩ Christopher D. Manning, Prabhakar Raghavan, Hinrich SchÃŒtze. Introduction to Information Retrieval . Cambridge University Press, Chapter 9,2008. ↩ Bhaskar Mitra, Nick Craswell. An Introduction to Neural Information Retrieval . Microsoft Research, pages 49-50, 2018. ↩ Christopher D. Manning, Prabhakar Raghavan, Hinrich SchÃŒtze. Introduction to Information Retrieval . Cambridge University Press, Chapter 3,2008. ↩ Hurtado, Carlos A. and Poulovassilis, Alexandra and Wood, Peter T. A Relaxed Approach to RDF Querying . The Semantic Web - ISWC 2006, pages 314-328, 2006. ↩ Yuki Amemiya, Tomohiro Manabe, Sumio Fujita and Tetsuya Sakai. How Do Users Revise Zero-Hit Product Search Queries? . ECIR 2021. ↩ Tan, Zehong, Canran Xu, Mengjie Jiang, Hua Yang and Xiaoyuan Wu. “ Query Rewrite for Null and Low Search Results in eCommerce. ” eCOM@SIGIR (2017). ↩ Simiao Zuo, Qingyu Yin, Haoming Jiang, Shaohui Xi, Bing Yin, Chao Zhang, and Tuo Zhao. 2023. Context-Aware Query Rewriting for Improving Users’ Search Experience on E-commerce Websites. In Proceedings of the 61st Annual Meeting of the Association for Computational Linguistics (Volume 5: Industry Track), pages 616–628, Toronto, Canada. Association for Computational Linguistics. ↩ Sanjay Agrawal, Srujana Merugu, and Vivek Sembium. 2023. Enhancing E-commerce Product Search through Reinforcement Learning-Powered Query Reformulation. In Proceedings of the 32nd ACM International Conference on Information and Knowledge Management (CIKM '23). Association for Computing Machinery, New York, NY, USA, 4488–4494. ↩
はじめに こんにちは。Developer Engagementブロックの @wiroha です。6月19日に「WWDC25 報告䌚 at LINEダフヌ, ZOZO」を開催したした。Appleの幎次開発者むベント「WWDC25」で発衚された最新技術や知芋に぀いお、゚ンゞニアがそれぞれの芖点で共有するむベントです。本蚘事ではオフラむンで開催した圓日の様子をレポヌトしたす なお、本むベントはAppleがNDAを締結した開発者にのみ公衚しおいる情報を取り扱っおおり、参加はApple Developer Programに加入しおいる方に限定しお実斜したした。本レポヌトもセッションの詳现は割愛し、雰囲気をお䌝えできればず思いたす。 lycorptech-jp.connpass.com 登壇内容たずめ 各瀟の゚ンゞニアによるLTず、珟地に参加した゚ンゞニアによるパネルディスカッションを行いたした。 発衚タむトル 登壇者 2回目のお぀かい S_Shimotori What's new in Foundation Model だヌはた What's New in Apple Intelligence Tommy Finally Here! A Native WebView for SwiftUI セヌタ WWDC25 activities of LINE app MDX Team ikesyo FAANSにおけるWriting Toolsの掻甚 むッセヌ パネルディスカッション freddi, Masakaz Ozaki, ikkou 2回目のお぀かい LINEダフヌのS_Shimotoriさんによる発衚 What's new in Foundation Model ZOZOのだヌはたによる発衚 What's New in Apple Intelligence LINEダフヌのTommyさんによる発衚 Finally Here! A Native WebView for SwiftUI ZOZOのセヌタによる発衚 WWDC25 activities of LINE app MDX Team LINEダフヌのikesyoさんによる発衚 FAANSにおけるWriting Toolsの掻甚 ZOZOのむッセヌによる発衚 パネルディスカッション パネルディスカッションの様子 パネルディスカッションにはZOZOのikkou、Swift Students Community Japan OrganizerのMasakaz Ozakiさん、LINEダフヌのfreddiさんが登壇したした。WWDC25で気になった発衚や実装したいこず、参加しお良かったこずなどを語らいたした。珟地でのコミュニケヌションが倧切ずいうのはみなさん共通の意芋で、コミュニティむベントぞの参加や海倖の有名な゚ンゞニアずの䌚話などを楜しんだそうです。行くべきおすすめの堎所や倱敗談ずいった、今埌参加する方の参考になる情報も共有されたした。 最埌に 今回はWWDC25の最新情報や珟地の䜓隓を共有する貎重な堎ずなりたした。ご参加いただいた皆さた、ありがずうございたした ZOZOでは最新情報をキャッチし぀぀、䞀緒にサヌビスを䜜り䞊げおくれる仲間を募集䞭です。ご興味のある方は、以䞋のリンクからぜひご応募ください。 hrmos.co corp.zozo.com
はじめに こんにちは、デヌタシステム郚掚薊基盀ブロックの棚本 @i6tsux です。 ZOZOTOWNには1,600のショップ、9,000以䞊のブランド、100䞇点を超える商品が集たり、毎日2,700点もの新商品が远加されおいたす。この膚倧な商品の䞭から、1,000䞇人以䞊のナヌザヌそれぞれに「これだ」ず思える商品を芋぀けおもらうヌヌそのためにパヌ゜ナラむズは欠かせない技術です。 私たちのチヌムでは、単に奜みに合う商品を芋せるだけでなく、「新しい商品ずの出䌚い」も提䟛できるパヌ゜ナラむズを目指したした。ホヌム画面のモゞュヌルに衚瀺する商品をナヌザヌごずに最適な順番で䞊び替える仕組みを構築し、その結果、 モゞュヌルのクリック商品数が58.3増加、モゞュヌル経由の受泚金額が26.3増加 ずいう成果を達成したした。 本蚘事では、この取り組みの背景ずなった課題から技術的な解決アプロヌチ、システム構成、そしおA/Bテストで埗られた成果たで詳しく解説したす。 パヌ゜ナラむズ機胜や掚薊システムの開発に携わる方々の参考になれば幞いです。 目次 はじめに 目次 背景・課題 モゞュヌルずは 珟状の課題 今回の察象カテゎリ掚薊モゞュヌル パヌ゜ナラむズロゞック 蚭蚈方針 Two-Towerモデルずベクトル怜玢 ベクトル怜玢基盀の遞定 2段階凊理の蚭蚈 プロトタむピングによる事前怜蚌 パヌ゜ナラむズシステム システム抂芁 システム構成 モデルの敎合性担保 A/Bテストによる効果怜蚌 テスト抂芁 結果 たずめず今埌の展望 おわりに 背景・課題 モゞュヌルずは ZOZOTOWNのホヌム画面は、ナヌザヌが最初に蚪れる堎所であり、商品ずの出䌚いを生み出す重芁な接点ずなっおいたす。このホヌム画面は「モゞュヌル」ず呌ばれる商品衚瀺枠で構成され、それぞれが特定のテヌマで商品を玹介しおいたす。 䟋えば、「20代女性向けワンピヌス」「泚目のアりタヌ特集」ずいった様々な切り口で商品を蚎求しおいたす。 珟状の課題 埓来のシステムでは、モゞュヌル内の商品衚瀺順が党ナヌザヌ共通の人気順になっおいたした。䟋えば「20代女性向けワンピヌス」ずいうモゞュヌルでも、商品は人気順で䞊べられおおり、ナヌザヌの奜みや過去の賌買履歎に関わらず、党員が同じ商品を同じ順番で芋るこずになっおいたのです。 今回の察象カテゎリ掚薊モゞュヌル この状況を改善するため、モゞュヌル内の商品衚瀺順をナヌザヌごずに最適化したした。数あるモゞュヌルの䞭から、たずはホヌム画面䞊郚に3぀衚瀺される「カテゎリ掚薊モゞュヌル」を察象に遞びたした。このモゞュヌルは、盎近のナヌザヌ行動を元に興味がありそうなカテゎリアりタヌ、パンツ、シャツなどの商品を衚瀺したす。 カテゎリ掚薊モゞュヌルは2段階の仕組みで動䜜したす。たず、ナヌザヌごずにパヌ゜ナラむズされたカテゎリ・ブランドで絞り蟌み、次にその条件に合う商品を人気順で衚瀺したす。しかし、この2段階目の「人気順衚瀺」が課題でした。カテゎリずブランドをパヌ゜ナラむズしおも、商品の衚瀺順が人気順では、パヌ゜ナラむズの効果が十分に発揮されたせん。 図1: ZOZOTOWNホヌム画面に衚瀺されるカテゎリ掚薊モゞュヌルの䟋 パヌ゜ナラむズロゞック 蚭蚈方針 私たち掚薊基盀チヌムは、ZOZOTOWNのパヌ゜ナラむズ機胜党般を担圓しおいたす。毎幎 OKR ずいう圢匏でチヌムの方向性を決めおおり、今幎床は「新たな出䌚いを目指し、新芏性ず倚様性に重きを眮く」ずいう目暙を掲げたした。これは、関連性だけを远い求めるパヌ゜ナラむズでは、ナヌザヌの興味が固定化し、新たな商品ずの出䌚いが倱われおしたうずいう考えからです。 このプロゞェクトでも、チヌムのOKRに沿っお、新たな出䌚いを目指しお新芏性ず倚様性を重芖するこずにしたした。ただし、たったく興味のない商品を芋せおも意味がないため、関連性も含めた3぀の芁玠をバランスよく組み合わせるアプロヌチを採甚したした。 芁玠 目指すこず 関連性 ナヌザヌの興味に合った商品を掚薊する 新芏性 ただ芋たこずのない商品ず出䌚える機䌚を䜜る 倚様性 偏りのない幅広い商品を提案する Two-Towerモデルずベクトル怜玢 これらの3芁玠を実珟する最倧の課題は、1,000䞇人のナヌザヌず100䞇点の商品ずいう膚倧な組み合わせの䞭から、各ナヌザヌずの関連性が高い商品を芋぀け出すこずでした。 この課題に察し、 以前の蚘事 で玹介したTwo-Towerモデルを今回も採甚したした。Two-Towerモデルは、ナヌザヌず商品をそれぞれ独立したニュヌラルネットワヌクTowerで凊理し、同じ次元のベクトル空間に埋め蟌む手法です。関連性の高いナヌザヌず商品のベクトルが互いに近くなるように孊習されるため、あるナヌザヌのベクトルから、そのナヌザヌに適した商品をベクトル怜玢近傍探玢で取埗できるようになりたす。 Two-Towerモデルの詳しい仕組みに぀いおは前回の蚘事をご参照ください。 ベクトル怜玢基盀の遞定 ベクトル怜玢の基盀ずしお、Google Cloudの Vertex AI Vector Search を採甚したした。事前に商品ベクトルを登録しおおくこずで、ナヌザヌベクトルず関連性の高い商品を高速に取埗できたす。採甚理由は以䞋の通りです。 採甚理由 詳现 柔軟なフィルタリング機胜がある ブランドやカテゎリ、䟡栌などで商品をフィルタリングした䞊でベクトル怜玢が可胜 倚様性確保の仕組みがある クラりディング機胜 により、同じ属性倀ブランド、カテゎリなどの商品数を制限し、怜玢結果の倚様性を確保可胜 将来的な拡匵性がある 今回はバッチ凊理で䜿甚する想定だが、将来的なリアルタむム化の予定があり、これに察応可胜 2段階凊理の蚭蚈 関連性・新芏性・倚様性を兌ね備えたパヌ゜ナラむズを実珟するため、以䞋の2段階凊理を蚭蚈したした。 図2: パヌ゜ナラむズ凊理の2段階アプロヌチ 第1段階近傍の商品取埗関連性×倚様性 Vertex AI Vector Searchでナヌザヌベクトルに近い商品を怜玢するこずで、 関連性 の高い商品を取埗したす。同時に、クラりディング機胜により同䞀ブランドを最倧3件に制限するこずで、 倚様性 を確保したす。これにより、ナヌザヌの興味に合いながらも、様々なブランドの商品を候補ずしお遞出できたす。 第2段階䞊び順調敎新芏性 取埗した商品の䞭から、最近ナヌザヌが閲芧した商品にはスコアのペナルティを加え、衚瀺順を調敎したす。この調敎によっお、ナヌザヌがただ芋おいない商品が優先的に衚瀺され、関連性を保ちながら 新芏性 の高い商品ずの出䌚いが生たれるよう蚭蚈しおいたす。 この2段階凊理により、関連性・新芏性・倚様性の3芁玠すべおを満たしたパヌ゜ナラむズを実珟したす。 図3: パヌ゜ナラむズによっお期埅される商品衚瀺の倉化 プロトタむピングによる事前怜蚌 蚭蚈したアプロヌチの劥圓性を確認するため、本栌的な開発の前に Gradio で怜蚌ツヌルを䜜成したした。 このツヌルではナヌザヌIDを入力するだけで、そのナヌザヌ向けにパヌ゜ナラむズされた商品リストをブラりザ䞊で確認できたす。実際の動䜜を芋るこずで、埓来の人気順衚瀺ずの違いが明確になり、ステヌクホルダヌぞの説明も効果的に行えたした。 プロトタむピングでアプロヌチの劥圓性を確認できたこずで、自信を持っお本栌的な開発に着手できたした。 パヌ゜ナラむズシステム システム抂芁 䞊述のようなパヌ゜ナラむズを本番環境で運甚するため、各ナヌザヌに最適な商品リストを生成・配信するシステムを構築したした。Two-Towerモデルの孊習、100䞇商品のベクトル生成ずむンデックス曎新、1000䞇人を超えるナヌザヌぞの掚薊結果の生成たで、すべおを自動化しおいたす。 システムの䞭栞ずなるのは、ベクトル怜玢むンデックスず2぀のバッチ凊理パむプラむンです。 日次で実行されるパむプラむンはTwo-Towerモデルを孊習し、ベクトル怜玢むンデックスを曎新したす。䞀方、1時間毎に実行されるパむプラむンは、最新のナヌザヌ行動を反映した掚薊商品の生成を担圓したす。生成された結果はBigtableに保存され、ホヌム画面衚瀺時に䜎レむテンシで配信されたす。 システム構成 図4: パヌ゜ナラむズシステムの党䜓構成 コンポヌネント 圹割 training-and-indexing-pipeline (Vertex AI Pipelines) 日次で以䞋の凊理を行うパむプラむン 1. Two-TowerモデルUser Tower、Product Towerを蚓緎しおModel Registryに保存 2. Product Towerを䜿甚しお党商品玄100䞇件のベクトルを生成 3. 生成したベクトルでVertex AI Vector Searchのむンデックスを曎新 module-personalization-pipeline (Vertex AI Pipelines) 1時間毎に以䞋の凊理を行うパむプラむン 1. Model RegistryからUser Towerモデルを取埗 2. 最新のナヌザヌ特城量ずUser Towerを䜿甚しおナヌザヌベクトルを生成 3. ナヌザヌベクトルの近傍商品をVertex AI Vector Searchから取埗     a. クラりディング機胜を䜿甚し、同䞀ブランドは最倧3件に制限 4. 取埗した商品に察しお新芏性を考慮した䞊び替え 5. 結果をBigtableに保存 product-vector-index (Vertex AI Vector Search) 党商品ベクトルが栌玍される高速怜玢むンデックス モデルの敎合性担保 User TowerずProduct Towerは必ず同じバヌゞョンのモデルを䜿甚する必芁がありたす。異なるバヌゞョンのモデルを䜿甚するず、ナヌザヌベクトルず商品ベクトルが異なるベクトル空間に埋め蟌たれおしたい、類䌌床蚈算が意味をなさなくなりたす。 この問題を防ぐため、以䞋の仕組みを実装したした。 training-and-indexing-pipelineが新しいモデルを蚓緎し、商品ベクトルの曎新を完了 曎新完了埌、Model Registryの該圓モデルに「珟圚のむンデックスず同期枈み」を瀺す゚むリアスを蚭定 module-personalization-pipelineは垞にこの゚むリアスが指すモデルを䜿甚 この方匏により、商品ベクトルを生成したモデルず同じバヌゞョンでナヌザヌベクトルが生成されるこずを保蚌し、ベクトル空間の敎合性を維持しおいたす。 A/Bテストによる効果怜蚌 テスト抂芁 パヌ゜ナラむズの効果を定量的に評䟡するため、以䞋の蚭定でA/Bテストを実斜したした。 項目 内容 期間 28日間 察象ナヌザヌ数 箄500䞇人 察象モゞュヌル カテゎリ掚薊モゞュヌルホヌム画面の3箇所 Control矀 埓来の人気順衚瀺 Treatment矀 パヌ゜ナラむズされた䞊び順関連性×新芏性×倚様性 結果 「新たな出䌚い」を目指したパヌ゜ナラむズが、優れたナヌザヌ䜓隓ず確かなビゞネス成果に぀ながりたした。 カテゎリ掚薊モゞュヌルの盎接的な成果 指暙 改善率Treatment/Control 1人圓たりナニヌク商品閲芧数 +18.8% 1人圓たりナニヌクブランド閲芧数 +56.3% 1人圓たりナニヌク商品クリック数 +58.3% 1人圓たりナニヌクブランドクリック数 +63.3% 1人圓たりモゞュヌル経由の受泚金額 +26.3% これらの結果から、「新たな出䌚い」を目指したパヌ゜ナラむズの成功が確認できたす。単に閲芧数が増えただけでなく、クリック数も倧幅に増加商品+58.3、ブランド+63.3しおいる点が重芁です。 衚瀺された新しい商品・ブランドがナヌザヌの興味を匕き、積極的にクリックされおいる こずを瀺しおいたす。そしお受泚金額も26.3向䞊し、新たな出䌚いがビゞネス䟡倀にも結び぀きたした。 さらに、モゞュヌル党䜓のカバレッゞ指暙党ナヌザヌの行動を集蚈した結果も倧幅に改善したした。 指暙党ナヌザヌ集蚈 改善率Treatment/Control ナニヌク閲芧商品数 +387.9% ナニヌク閲芧ブランド数 +62.4% ナニヌククリック商品数 +202.2% ナニヌククリックブランド数 +92.2% これらの結果から、 パヌ゜ナラむズによっおカテゎリ掚薊モゞュヌルで衚瀺される商品・ブランドの皮類が倧幅に増加した こずがわかりたす。埓来の人気順では限られた商品・ブランドしか衚瀺されたせんでしたが、パヌ゜ナラむズによっお各ナヌザヌに合わせた倚様な商品が衚瀺されるようになりたした。その結果、閲芧される商品の皮類が387.9増、クリックされる商品の皮類も202.2増ずいう劇的な改善を実珟したした。これは、 埋もれおいた商品が適切なナヌザヌに届き、実際に興味を持たれおいる こずを意味しおいたす。 サむト党䜓ぞの圱響 指暙 改善率Treatment/Control 1人圓たり受泚金額 +0.4% 1人圓たりお気に入り商品数 +4.3% 1人圓たりお気に入りブランド数 +1.4% 1人圓たりサむト蚪問頻床 +0.2% 1人圓たりホヌム画面の蚪問頻床 +0.2% ホヌム画面の3぀のモゞュヌルずいう限定的な倉曎でありながら、サむト党䜓のKPIが向䞊したした。お気に入り登録の増加は、 パヌ゜ナラむズによっお芋぀けた商品・ブランドに、ナヌザヌが匷い興味を持ち、今埌も賌入を怜蚎したいず感じた こずを瀺しおいたす。蚪問頻床の向䞊は、新たな商品ずの出䌚いぞの期埅感を生み出せおいる蚌拠です。 特に泚目すべきは、1人圓たり受泚金額が0.4向䞊したこずです。䞀芋小さな数字に芋えたすが、 ZOZOTOWNの芏暡を考えるず非垞に倧きなビゞネスむンパクト ずなりたす。 たずめず今埌の展望 私たちは「新たな出䌚いを目指し、新芏性ず倚様性に重きを眮く」ずいうチヌムのOKRに基づき、ZOZOTOWNホヌム画面のパヌ゜ナラむズに取り組みたした。 その結果、1人圓たりクリック商品数が58.3増加、モゞュヌル経由の受泚金額が26.3増加ずいう倧きな成果を達成。さらに、衚瀺される商品の皮類が387.9増加し、埋もれおいた商品に光を圓おるこずができたした。 技術面では、Two-TowerモデルずVertex AI Vector Searchを組み合わせるこずで、新芏性・倚様性を意識したパヌ゜ナラむズを実珟できたした。たた、プロトタむピングによる事前怜蚌の重芁性も再認識したした。 今埌は、この成功を基に以䞋の展開を進めおいきたす。 バッチ掚薊からリアルタむム掚薊ぞの移行 ホヌム画面の他モゞュヌルぞの展開 ホヌム画面以倖ぞの展開 おわりに パヌ゜ナラむズは技術だけの問題ではありたせん。どのような䟡倀をナヌザヌに届けたいのか、その想いを圢にする蚭蚈が重芁です。 本蚘事で玹介した手法や考え方が、パヌ゜ナラむズシステムの構築に取り組む皆さたの参考になれば幞いです。 ZOZOでは、䞀緒にサヌビスを䜜り䞊げおくれる方を募集䞭です。ご興味のある方は、以䞋のリンクからぜひご応募ください。 corp.zozo.com
はじめに 技術戊略郚の @ikkou です。XRずキヌボヌドが奜きで、特にVision ProずHHKB Studioの組み合わせが倧奜きです。珟地時刻で2025幎6月8日〜10日に察面圢匏で開催された WWDC25のSpecial Event に珟地参加しおきたした。䜕名かの方に「䜕回も参加しおいそう」ず蚀われたしたが、初めおの珟地参加でした 本蚘事では、珟地参加ならではのむベントや圓日発衚された内容に぀いお、私の芖点から速報ずしおお䌝えしたす。 はじめに WWDCずSpecial Event Schedule 事前準備 セミナヌ・カンファレンス参加支揎制床 航空刞ず宿泊先の手配 Wallet passの登録 通信環境ず怜蚌甚デバむス Day 0 (June 8) Welcome reception Apple Design Awards Day 1 (6/9) Keynote Liquid Glass Apple Intelligence Download station Platforms State of the Union In-person labs Reception in the inner ring Day 2 (June 10) Developer activities (Morning session) 珟地でのアクティビティ Run & Walk with Ctrl+Alt+Run - WWDC Edition WWDC25 Vision Pro Community Meetup A Vision Pro Spatial Art Experience for WWDC25 Flatland: Mixed Reality Dreams SpatialComputing Meetup @ WWDC25 さいごに WWDC25関連むベントのお知らせ WWDC25 Recap for Spatial Computing WWDC25 報告䌚 at LINEダフヌ, ZOZO LODGE XR Talk Vol.28 / WWDC25 & AWE USA 2025 Report WWDCずSpecial Event WWDC(Worldwide Developers Conference)は、Appleが毎幎開催する 開発者向け のカンファレンスです。Keynote、Platforms State of the Union、そしお数倚くのセッションやラボが行われ、Appleの最新技術や開発ツヌルに぀いお孊べたす。WWDCは、Appleの最新技術を孊び、他の開発者ず亀流する重芁な機䌚です。今幎の WWDC25 は6月9日〜13日にオンラむンで開催されたした。 私が珟地参加したSpecial EventはこのWWDC25の䞀郚を構成する 招埅制 のむベントです。セッションだけであればオンラむンでも事足りたすが、䟋えばオンラむンのラボず異なりIn-person LabsではAppleの方から盎接フィヌドバックを受けられたす。たた、6月10日に開催されたSpecial Sessionも珟地参加者のみが参加できるむベントです。 Schedule Date Pacific Time Content Venue Day 0 (June 8) 3 p.m. Welcome reception Infinite Loop Day 1 (June 9) 8 a.m. Check-in Apple Park 10 a.m. Keynote Apple Park 12 p.m. Download station open Apple Park 12 p.m. Lunch Apple Park 1 p.m. Platforms State of the Union Apple Park 2 p.m. In-person labs Apple Park 4-5:30 p.m. Reception in the inner ring Apple Park Day 2 (June 10) 10 a.m. Activities at the Developer Center (Morning Session) Apple Developer Center Cupertino 事前準備 WWDC25 Special Eventの本線が気になる方は Day 0のパヌト から読み進めおください。ここでは、珟地に赎く前の事前準備に぀いおお䌝えしたす。 セミナヌ・カンファレンス参加支揎制床 4月5日の深倜に圓遞メヌルが届き、WWDC25のSpecial Eventに参加するこずが決たりたした。この時点で枡航日たで2か月皋床しかありたせんでした。 ZOZOでは犏利厚生の䞀環ずしお「 セミナヌ・カンファレンス参加支揎制床 」が甚意されおいたす。囜内の技術カンファレンスはもちろん、WWDCのような海倖カンファレンスに参加する際は、事前に申請するこずで参加費や枡航費はもちろん、宿泊費に珟地での亀通費などの諞経費を䌚瀟が負担しおくれたす。 私は䟋幎、幎始に本制床を利甚しおCESに参加しおいるので、今回は本制床を利甚した半幎ぶりの海倖出匵でした。単独での海倖出匵は䞀定の経隓があったので、たずは手早く航空刞ず宿泊先などを手配したした。 航空刞ず宿泊先の手配 䌚堎最寄りの空枯はサンノれ囜際空枯SJCですが、今回は乗継䟿の関係でサンフランシスコ囜際空枯SFOを利甚したした。フラむト䞭は Apple Musicで公開されおいるWWDC25のプレむリスト を聎きながら、WWDC25ぞの気持ちを高めおいたした。 music.apple.com SFOから最初の目的地であるInfinite Loopたでの移動は、安䟡に枈たせるならBARTずCaltrain、そしおVTAバスなどの公共亀通機関の組み合わせですが、ドア・トゥ・ドアで2時間前埌かかりたす。察しおUberを利甚すればコストは4倍前埌になりたすが、30分皋床で到着したす。今回は“コスパ”より“タむパ”を優先しおUberを利甚したした。 宿泊先はInfinite Loopから埒歩圏内のわりにコスパの良い Cupertino Hotel にしたした。このホテルには他にもWWDC25の参加者が倚く宿泊しおおり、朝食䌚堎や゚ントランスで車を埅っおいる間などに他の参加者ず自然に䌚話が生たれたした。WWDC25の参加者同士での亀流は、珟地参加の倧きな魅力のひず぀です。 Wallet passの登録 䌚期が近づくずWallet passがメヌルで届きたす。WWDC24でも発生しおいたようですが、圓初、 iPhoneの蚀語蚭定が「日本語」のたただずWallet passが正垞に衚瀺されない 事象が発生しおいたした。蚀語蚭定を「英語」に倉曎しおから改めお登録を詊みたずころ、無事にWallet passが衚瀺されたした。このWallet passは、䌚堎でのチェックむンに利甚したす。 通信環境ず怜蚌甚デバむス 私はiPhone 3G以前からの゜フトバンクナヌザヌです。゜フトバンクには通話ずデヌタ通信がアメリカで䜿い攟題の「 アメリカ攟題 」ずいうサヌビスがあり、これを利甚すれば珟地での通信環境は抂ね賄えたす。さらにバックアップずしおAiraloのeSIMを普段遣いのiPhoneにセットしお臚みたした。 䟋幎、WWDCの期間䞭に新しいOSが発衚され、すぐに開発者のみがむンストヌルできる Developer Preview が公開されたす。ここで勢いよく普段遣いのiPhoneをアップデヌトしおしたうず䞍枬の事態が起きたずきに困るので、珟地での怜蚌甚に予備のiPhoneも持参しおいたす。 同様にVision Proも持ち蟌んでいたすが、さすがにこれは怜蚌甚の予備機たで甚意できたせん。visionOS 2の登堎時にはアップデヌトに倱敗しお Developer Strap に助けられた苊い思い出がありたす。今回は䜕も起きないように祈りながら珟地に持ち蟌みたした。 Day 0 (June 8) Day 0はSFOに到着埌、埌述するWWDC25関連むベントを3件こなしおから、Infinite Loopで開催されたWelcome receptionに参加したした。 Welcome reception Welcome Receptionは前日チェックむンを兌ねたむベントで、昚幎に匕き続き今幎もAppleの旧本瀟であるInfinite Loopで開催されたした。翌日のメむンむベントに早くから䞊ぶためには、このタむミングでバッゞを受け取っおおく必芁がありたす。 Appleの方がInfinite Loopの前で蚘念写真を撮っおくれたす。 私は開始時刻の15時少し前にInfinite Loopぞたどり着きたした。䌚堎には既に倚くの参加者が集たっおいお、バッゞを受け取るための行列ができおいたした。セキュリティチェックも厳しく、䌚堎内に入れたのは16時過ぎでした。手ぶらでの参加者は、セキュリティチェックに時間がかからないため、行列をパスできたす。特にDay 0は倧きな荷物を必芁ずするこずはそう倚くないので、手ぶらでの参加を匷くおすすめしたす。 個人のADPで圓遞しおいるのでZOZO, Inc.の衚蚘がないバッゞ。 セキュリティチェックを終えるずテンションの高いAppleの皆さんが出迎えおくれたす。自然ず自分のテンションも高たりたす。恥ずかしがらずにハむタッチしおいきたしょう。ここで期間䞭に携垯するバッゞずノベルティを受け取りたす。 バッゞずノベルティを受け取る゚ントランス。 WWDC25のノベルティはトヌトバッグ・氎筒・ストラップ・WWDC25のピンバッゞセットでした。 䌚堎に入った埌の過ごし方は自由です。定番ずも蚀えるWWDC25のモニュメント前で写真を撮るのはもちろん、どこから来たかピンを挿したり、䌚堎内に甚意されおいたコヌンホヌルゲヌムで遊んだりしおいる方もいたした。 お玄束のWWDC25モニュメント前での蚘念撮圱。 どこから来たかを瀺すピンを指すボヌドただ入堎しおいない方も䞀定数いる16:45時点。 たた、䌚堎内では食べ物ず飲み物が無限に提䟛されおいお、食べたり飲んだりしながら参加者同士で楜しく䌚話するなど、思い思いに過ごしおいたした。 ハンバヌガヌ系のものの他、唐揚げや小さなたぐろ䞌などが甚意されおいたした。 䞀床ID Checkすればアルコヌルを含めお飲み物は自由に飲めたした。 なぜか寒くなった頃合いで゜フトクリヌムを食べおしたいたした。 Apple Design Awards Welcome receptionず同じ䌚堎内で2025幎の『 Apple Design Awards 』の受賞䜜品によるブヌスが蚭けられおいたした。受賞者が授䞎されるトロフィヌのサンプルも展瀺されおいお、そのずっしり重い感觊に思わず感動したした。 å…š6カテゎリヌごずに受賞䜜品のブヌスが蚭けられおいたした。 Apple Design Awardsのトロフィヌのサンプル。 クロヌズする7 p.m.も近づいた頃、今幎の『 Swift Student Challenge 』で日本人ずしお唯䞀の優秀受賞者である濱本 倪茝さんにお䌚いできたした。濱本さんのこずは受賞の蚘事を芋お出発前から気になっおいたので、盎接お話しできおずおも嬉しかったです。 Hanafuda Tactics のVision Pro察応を楜しみにしおいたす 濱本 倪茝さんず蚘念撮圱 Photo by @toyochang さん。 こうしおDay 0は無事に終了したした。翌日からのメむンむベントに備えお早めに䌑みたしょう。 Day 1 (6/9) developer.apple.com Day 1はWWDC25のメむンむベントである Keynote ず Platforms State of the Union 、そしお In-person labs などが催されたした。 䌚堎はApple Parkですが、入堎前の埅機列はApple Park Visitor Centerの裏手に圢成されたす。この埅機列ぞ䞊ぶずころからむベントは始たっおいるずいっおも過蚀ではありたせん。開堎時間は8 a.m.ですが、私はLINEダフヌの参加者らずずもに6 a.m.頃から䞊び始めたした。最前列の方は明るくなる前から䞊んでいたそうです。日が射し蟌む前の時間垯は肌寒いので、絶察に薄手の䞊着を持参するこずをおすすめしたす。 開堎を埅っおいるずApple Park Visitor Centerに䜵蚭されおいるCaffÚ Macsのドヌナツやコヌヒヌが提䟛されたした。これがずおも矎味しくお、思わずおかわりしおしたいたした。 CaffÚ Macsのドヌナツやコヌヒヌ。 定刻が近づくに連れ、Appleの方も『ダブ ダブ ディヌシヌ』コヌルを繰り返し倧いに盛り䞊げおくれたす。たたに“野良”の掛け声も混ざっおいたした。定刻盎前の様子がTim Cook氏のX旧Twitterに 投皿されおいたした 。実は開始3〜4秒に映り蟌んでいたす。 そしおいよいよ定刻の8 a.m.を過ぎたずころで列が動き始めたした。最初のゲヌトでバッゞをスキャンし、次のゲヌトでセキュリティチェックを受けたす。セキュリティチェックはDay 0同様に厳重です。䌚堎内ですぐに怜蚌したいこずを考えるずさすがに手ぶらでの参加は難しいので、荷物はできるだけ少なくしおおくこずをおすすめしたす。それでも䞊ぶレヌンによっおは時間がかかるので運次第ずいう偎面も吊めたせんでした。 結果ずしお私は前方2列目の䞊手寄りの座垭を確保できたした。昚幎、前方の座垭はEnterprise Guest向けに確保されおいたので、今幎は端の方ずはいえ前方の座垭を確保できたのは幞運だったず蚀えるかもしれたせん。ただし、この䞊手偎、屋根はあるものの斜めに射し蟌む陜射しが非垞に匷く、Keynote䞭は暑さずの戊いでした。来幎以降にこの゚リアを狙う方は、日焌け止めを塗っおおくこずを匷くおすすめしたす。 前から2列目の䞊手寄りの座垭から芋たステヌゞの様子。 座垭を確保埌、Keynoteが始たるたでの時間でLINEダフヌの方々らず䞀緒に朝食を楜しみたした。 座垭を離れる際は念のためにAirTagなどのトラッカヌを入れおおくず安心できたす 。 同時刻に日本ではZOZOのiOS゚ンゞニアも登壇した『 Extended Tokyo - WWDC 2025 』が開催されおいお、生䞭継が行われおいたした。 Keynote www.youtube.com 定刻を迎え、昚幎同様にCEOのTim Cook氏ずSenior Vice PresidentのCraig Federighi氏が壇䞊に登堎し、短い時間ですがトヌクしたした。この様子もアヌカむブには残らない珟地ならではの䜓隓です。その埌、Keynote本線のビデオが䌚堎内のスクリヌンで再生されたした。 CEOのTim Cook氏ずSenior Vice PresidentのCraig Federighi氏。 Liquid Glass 今回のWWDCではOSバヌゞョンを西暊にあわせたiOS 26などにするずいった倧胆な倉曎がありたした。しかし、䞀番の目玉であり、ナヌザヌず開発者の双方にずっお倧きな倉化ずなるのは Liquid Glass の発衚ではないでしょうか。 www.apple.com 倧胆か぀倧きな倉化ですが、XR屋の私ずしおはvisionOSの系譜が他OSに波及したず考えおいたす。そのvisionOSにも様々なアップデヌトが加えられ、空間コンピュヌティングの発展に倧きく寄䞎するこずが期埅されたす。 Apple Intelligence 昚幎のWWDC24で発衚された Apple Intelligence も進化し、いよいよXcodeにChatGPTが統合されたした。これも䌚堎を沞かせたトピックのひず぀です。KeynoteではChatGPTずの統合を掚しおいたしたが、䟋えば Claude Sonnet 4など自身でモデルを遞択できたす 。 developer.apple.com Download station KeynoteずPlatforms State of the Unionの間の玄90分間はランチタむムずなり、同時に䌚堎内のDownload stationがオヌプンしたした。Download stationには電源ず有線LANが甚意されおいたす。䌚堎内には高速なWi-Fiも飛んでいるので、手早くランチを枈たせ、iPhoneずVision Proのアップデヌトを詊みたした少なくずもこの蚘事を曞いおいる時点で倧きな問題は発生しおいたせん。 Download stationは䌚堎内に耇数甚意されおいたした。 ここでひず぀トラブルがあり、せっかく持参した怜蚌甚のiPhoneをホテルに眮いおきおこずに気づきたした。もしも特定のアプリが動䜜しなくなった堎合、特にUberやLyft、航空䌚瀟のアプリで䞍枬の事態が発生するず道䞭が厳しいものになりたす。しかし、いざずなれば怜蚌甚のiPhoneに必芁なものをむンストヌルすれば枈むので、朔く普段䜿いのiPhoneにiOS 26をむンストヌルするこずになりたした。 今床むベントで話す3人で集合 みんなでvisionOS26をダりンロヌドしおたす😎 #WWDC25 pic.twitter.com/2SSDPmv411 — ARおじさんᯅ / MESON CEO (@AR_Ojisan) 2025幎6月9日 visionOSに匷い関心を寄せる同奜の士も合流し、3人でVision Proを装着しながらアップデヌトを埅ち、そのたた次のPlatforms State of the Unionぞず向かいたした。 䜙談ですが、私のVision Proに着けおいるオレンゞ色のカバヌは dbrandのAperture です。䌚堎内でも気になった方が倚いのか、写真を撮らせおくださいず声を掛けられるこずが䜕床かありたした。 Platforms State of the Union www.youtube.com www.youtube.com Keynoteを芋おいた前方の座垭は匕き続き匷い陜射しに照らされおいたため、Platforms State of the Unionは建物内に移動したした。iOS 26、visionOS 26ずもにアップデヌトが枈んでいたので、その倉化をより具䜓的に想像しながら芖聎したした。 Platforms State of the Unionの様子。 In-person labs Keynote、Platforms State of the UnionずもにApple DeveloperたたはYouTubeでアヌカむブを芖聎できたす。芖聎するだけであれば、特に珟地参加する必芁はありたせん。いわゆる“実況”を楜しむにもオンラむン参加の方に利がありたす。しかし、Appleの方ず察面で䌚話できる In-person labs は珟地参加ならではの特暩であり醍醐味です。 このIn-person labsはDay 2に甚意されおいるOne-on-one labsやgroup labず異なり、原則ずしお事前予玄が䞍芁ですDesign & AX DesignずApp Store Distribution & Servicesの2぀のみ必芁。気になるカテゎリヌの゚リアに行き、その堎で声をかけお各分野のスペシャリストず䌚話できたす。 In-person labsのカテゎリヌごずの配眮図。 私はSpatial ComputingずSafari & Webのブヌスに立ち寄り、Appleが考える空間コンピュヌティングやWebXRの将来に぀いおの䌚話を楜しみたした。 Spatial Computingラボの様子。 Reception in the inner ring In-person labsでの䌚話を楜しんだ埌はApple Parkのリング内を巡る Reception in the inner ring を楜しみたした。 KeynoteでCraig Federighi氏が乗っおいたF1カヌ。 有名な虹のアヌチ。 本物ず芋間違えるような“人工池”にも行きたかったのですが、虹のアヌチを含めお䞀定時間が経過した埌に封鎖されおしたったのは残念でした。たた、Apple Parkの党䜓を芋枡せる2F、3Fにも行けたせんでした。それでも、飲み物ず食べ物を片手にApple Parkの矎しい景色を楜しみながら、参加者同士で䌚話を十分に楜しめたした。既にiOS 26にアップデヌトしおいたこずもあり、実際の画面を芋ながらの䌚話もできたした。 Day 2 (June 10) developer.apple.com Special Eventの最終日ずなるDay 2はApple Developer Center Cupertinoで開発者向けのDeveloper activitiesが開催されたした。 Morning・Afternoon・Eveningの3぀の時間垯から遞択しお事前に予玄するのですが、私はその予玄に出遅れお気付いたずきには既にすべおの枠が埋たっおいたした。そのため、空き状況に応じお先着順で利甚できる Overflow seating の埅機列に小䞀時間ほど䞊んでMorning Session枠に参加したした。 䟋幎は䞊べばステヌゞのある特別なホヌルに入れたしたが、今幎は䟋幎よりも人数が倚かったのか、Overflow seatingずしお案内されたのは60人皋床が入れる皋床の䌚議宀でした。たた、Overflow seatingも䞊んでいた人が党員入堎できたわけではなく、䞀定のずころで打ち切りになり、残念ながら参加できなかった人もいたした。来幎以降の傟向ず察策ずしお、事前予玄は必須ずしお、もしも逃した堎合は1時間以䞊前から䞊ぶ芚悟で臚むこずをおすすめしたす。 Developer activities (Morning session) KeynoteやState of the Unionず異なり、Developer activitiesの内容は公開されたせん。新たに発衚されたLiquid Glassを䞭心ずしお、その特長や具䜓的な掻甚方法に぀いお、ラむブデモを亀えながらAppleの方が入れ替わり立ち替わりで解説しおくれたした。 Developer activitiesのステヌゞ。 Overflow seatingのラむブビュヌむングルヌムは“ラむブ感”を味わうには物足りなさがありたしたが、コヌドを䌎うラむブデモは非垞に芋やすく、これはこれで「あり」でした。 Overflow seatingのラむブビュヌむングルヌム。 終了埌には、䌚堎内に甚意されたランチを぀たみながら、Appleの方や参加者同士で楜しく亀流したした。 Developer activities終了埌に提䟛されたランチ。 これを以お私のWWDC25 Special Eventは終了したした。Special Eventが終わっおもWWDCは続きたす。匕き続き関連セッションを眺め、手元で動かす日々が始たりたす 珟地でのアクティビティ WWDCの開催䞭・開催埌に䞖界各囜の開発者コミュニティがWWDCに関連するむベントを開催したす。 これらのむベントの倚くはWWDC25の公匏ペヌゞでも玹介されおいたす 。私は滞圚䞭の3日間で次のむベントに参加したした。 Jun 8, Run & Walk with Ctrl+Alt+Run - WWDC Edition Jun 8, WWDC25 Vision Pro Community Meetup Jun 8, A Vision Pro Spatial Art Experience for WWDC25 Flatland: Mixed Reality Dreams Jun 9, Vision Pro Meetup at CommunityKit Jun 9, Spatial Computing Meetup @ WWDC25 Jun 10, One More Thing Conference 2025 Jun 10, CommunityKit 特に印象に残ったものを玹介したす。 Run & Walk with Ctrl+Alt+Run - WWDC Edition Day 0の8 a.m.からCtrl+Alt+Run @ctrlaltrunph が䞻催する「 Run & Walk 」むベントに参加したした。Day 0は3 p.m.スタヌトなので、朝の時間を有効掻甚しようず思い事前に申し蟌んでいたした。 Run組もWalk組も同じコヌスを巡りたした。 Apple Park Visitor Centerに集合し、簡単な自己玹介の埌、Run組ずWalk組に分かれ、およそ4kmの道のりを進みたした。私は同日の7 a.m.にSFOぞ到着したばかりで、䞀定の疲れもあるこずを想定しおWalkを遞んでいたした。しかし、かなりゆっくりずしたペヌスで走っおいるチヌムもあったので、Runに参加しおもよかったかもしれたせん走れる靎を履いおきおいたした。 ゎヌル埌に提䟛されたミネラルりォヌタヌ。 気持ちよく歩いおゎヌルした埌、ミネラルりォヌタヌが配られ、参加者同士でWWDC25ぞの期埅を語り合いたした。 WWDC25 Vision Pro Community Meetup Run & Walkの埌はCtrl+Alt+Runの䞻催者による別のむベント「 WWDC25 Vision Pro Community Meetup 」にそのたた参加したした。半分くらいはRun & Walkからの参加者でしたが、このMeetupのために参加した方も䞀定数いたした。 仲良くなった4人で蚘念撮圱。 その堎で意気投合しお仲良くなった方々ずVision ProやRay-Ban Meta AI Glassesなどの話に花を咲かせたした。そしお偶然にも私の隣にいる男性は、4月に審査員ずしお参加したハッカ゜ンむベント『 VisionDevCamp Tokyo 』の参加者ずいうこずが刀明し、ずおも驚きたした。こういった出䌚いもリアルむベントの醍醐味です。最埌に4人で写真を撮っお解散したした。 A Vision Pro Spatial Art Experience for WWDC25 Flatland: Mixed Reality Dreams Day 0の入堎間際にVision Proを䜿ったアヌト䜓隓むベント「 A Vision Pro Spatial Art Experience for WWDC25 Flatland: Mixed Reality Dreams 」に参加したした。 来堎者のサむンが加えられたボヌド 䌚堎はApple Park Visitor CenterからUberで5分皋床のずころにある䞀軒家で、Airbnbで探しお借りたそうです。 写真に写っおいないものも含めお党7台のVision Proで臚んでいたした。 このむベントはApp StoreにもリリヌスされおいるILLUSION TechのVision Pro向けアプリ『 Story: Spatial Storytelling 』を利甚しお制䜜されたもので、私はずおも楜しめたした。 SpatialComputing Meetup @ WWDC25 䞻催者のZac @greenlig 氏を亀えお蚘念撮圱。 Day 1のReception埌に少し離れた堎所のPUBで催された『 SpatialComputing Meetup @ WWDC25 』に参加したした。フリヌドリンクで入退堎自由のむベントで、Vision Proに興味を持぀方々が集たり、自由に䌚話を楜しみたした。 さいごに 本蚘事はDay 2終了埌にホテルでHHKBを接続したVision ProのMac仮想ディスプレむで執筆しおいたす。私はこの埌、 AWE USA 2025 に参加するため早朝のフラむトでロサンれルスのロングビヌチに向かいたす。Android XRなどの情報が期埅されるAWE USA 2025の様子は、埌日別の蚘事でお䌝えしたす。 たた、埌日、WWDC25にオンラむン参加しおいるiOS゚ンゞニアチヌムによる、セッションや参加したラボで埗た知芋などを玹介するレポヌト蚘事を公開予定です。 珟堎からは以䞊です WWDC25関連むベントのお知らせ WWDC25の開催にあわせお、様々なRecapむベントや報告䌚が予定されおいたす。そのいく぀かに登壇したす。 WWDC25 Recap for Spatial Computing 6月16日にTOKYO NODE LABで開催される「 WWDC25 Recap for Spatial Computing 」に登壇したす。 WWDC25で発衚された 空間コンピュヌティング 関連の情報に特化しお、空間コンピュヌティングに䞀家蚀ある3名がパネルディスカッション圢匏で今埌の可胜性に぀いお深掘りしおいきたす。 WWDC25 報告䌚 at LINEダフヌ, ZOZO 6月19日に、LINEダフヌずZOZOの゚ンゞニアが、それぞれが興味のある分野に぀いお、新しく発衚された技術や埗た知芋、情報などを共有する「 WWDC25 報告䌚 at LINEダフヌ, ZOZO 」を開催したす。 ZOZOからは3名のiOS゚ンゞニアがLT Sessionに登壇したす。たた、私はパネルディスカッションのパネラヌのひずりずしお参加したす。ご興味のある方はぜひご参加ください。 LODGE XR Talk Vol.28 / WWDC25 & AWE USA 2025 Report 6月25日にLODGEで開催される「 LODGE XR Talk Vol.28 / WWDC25 & AWE USA 2025 Report 」に登壇したす。 LODGE XR TalkはLINEダフヌの方ず共同で毎月開催しおいるXR領域に特化したむベントで、今回はWWDC25ず、その埌に参加したAWE USA 2025の2぀のむベントに぀いお玹介したす。 ZOZOでは、䞀緒にサヌビスを䜜り䞊げおくれる仲間を募集䞭です。ご興味のある方は、以䞋のリンクからぜひご応募ください。 corp.zozo.com
はじめに こんにちは。Developer Engagementブロックの @wiroha です。5月29日に『若手゚ンゞニアが語るリアルな実䟋 ~「技術負債」ずの戊い方・「技術資産」掻かし方』を開催したした。SmartHR・ZOZO・TOKIUM・プレむドの4瀟から若手゚ンゞニアが集い、技術負債や技術資産の掻甚に぀いお語り合うむベントです。本蚘事ではオフラむン開催した圓日のレポヌトをお届けしたす plaidtech.connpass.com 登壇内容たずめ SmartHR・ZOZO・TOKIUM・プレむドのメンバヌによる発衚の埌、質疑応答&クロストヌクを行いたした。 発衚タむトル 登壇者 コヌドの考叀孊 〜劎務プロダクトから発掘した成長の糧〜 SmartHR 関根 健倪 挞進。 ZOZO 冚川 宗倪郎 技術懞念に立ち向かい法改正を穏䟿に乗り切った話 TOKIUM 高田 将人 積み䞊げられた技術資産ず向き合いながら、プロダクトの信頌性をどう守るか プレむド 片山 拓海 質疑応答&クロストヌク 登壇各瀟のメンバヌ コヌドの考叀孊 〜劎務プロダクトから発掘した成長の糧〜 SmartHR 関根 健倪さんによる発衚 speakerdeck.com SmartHRの関根さんからは、劎務プロダクト開発の珟堎で盎面した耇雑なデヌタモデルや技術スタックの混圚、耇雑なコヌドずいった課題ぞの向き合い方を語っおいただきたした。䞀床の完璧な䜜り盎しはせず、「今できる最善のこず」の積み重ねが持続可胜な改善ぞの道であるずのこずでした。 挞進。 ZOZO 冚川宗倪郎による発衚 speakerdeck.com ZOZOの冚川からは、関根さんず同じく負債を少しず぀リプレむスしおいく倧切さ぀いお語られたした。少しず぀改善するために、ずにかく旧環境を觊っおコヌドを読む、ビッグバンリラむトを避けコンポヌネントレベル・ペヌゞ単䜍など现かく眮き換える、開発者䜓隓に投資するずいった方法が玹介されたした。たた負債にしないために泚意する点も発衚されたした。 技術懞念に立ち向かい法改正を穏䟿に乗り切った話 TOKIUM 高田将人さんによる発衚 speakerdeck.com TOKIUMの高田さんからは、むンボむス制床の法改正に䌎い非垞に倚くのコヌドを修正する必芁があった䞭でどのように察応したか、苊劎や工倫に぀いお語っおいただきたした。䞁寧に掗い出しを行い共通化するこずで負債を枛らしおおり、倉曎に匷いコヌドぞず改善されおいたした。 積み䞊げられた技術資産ず向き合いながら、プロダクトの信頌性をどう守るか プレむド 片山拓海さんによる発衚垌望によりお顔は䌏せおいたす speakerdeck.com プレむドの片山さんからは、サむトの曞き換えやABテスト斜策を支揎する「KARTE Blocks」ずいうプロダクトで信頌性を担保するための取り組みに぀いお共有いただきたした。CUJ(Critical User Journey)を決めるこずでSLOを策定しおおり、CUJの重芁さを感じる発衚でした。 質疑応答クロストヌク 質疑応答クロストヌクの様子 質疑応答クロストヌクでは、Slidoを通しお寄せられた参加者からの質問に回答しおいきたした。数十件ず非垞に倚くの質問が寄せられ、発衚内容に察する深い掘り䞋げが行われたした。文化の浞透や技術スタックの混圚ぞの課題感など、各瀟での取り組みや考えに぀いおの意芋亀換も行われたした。 最埌に 今回は若手゚ンゞニアが䞻圹ずなり、技術負債・技術資産ずどう向き合うかを本音で語り合う貎重な堎ずなりたした。懇芪䌚にも倚くの方が参加し、亀流を楜しんでいたした。ご参加いただいたみなさた、ありがずうございたした。今埌もこのようなむベントを通じお知芋を共有し、゚ンゞニア同士の぀ながりを深めおいきたいず思いたす。 冚川の登壇で觊れたWEARのほか、ZOZOでは倚様なプロダクトの成長や技術的な挑戊に日々取り組んでいたす。珟圚、耇数のポゞションで゚ンゞニアを募集しおいたすので、ご興味をお持ちの方は以䞋のリンクからぜひご応募ください。 corp.zozo.com
ZOZO開発組織の2025幎5月分の掻動を振り返り、ZOZO TECH BLOGで公開した蚘事や登壇・掲茉情報などをたずめたMonthly Tech Reportをお届けしたす。 ZOZO TECH BLOG 2025幎5月は、前月のMonthly Tech Reportを含む蚈7本の蚘事を公開したした。振り返っおみるず特にむベントの参加レポヌトが倚い月でした。 techblog.zozo.com 登壇 Google Cloud Next 2025 Recap in ZOZO 5月12日に開催された「 Google Cloud Next 2025 Recap in ZOZO 」に、MA郚の霋藀・吉川・富氞の3名が登壇したした。 【ZOZO゚ンゞニア登壇情報】 本日 5/12(月) 19:00より『Google Cloud Next 2025 Recap in ZOZO』をYouTubeにおオンラむン配信いたしたす🎙 ZOZOからはMA郚の霋藀・吉川・富氞の3名が登壇したす。ぜひご芖聎ください https://t.co/Sx6pQmM69k #GoogleCloudNext25Recap #GoogleCloudNext — ZOZO Developers (@zozotech) 2025幎5月12日 www.youtube.com speakerdeck.com speakerdeck.com speakerdeck.com After RubyKaigi 2025〜ZOZO、ファむンディ、ピクシブ〜 5月13日に開催されたRubyKaigi 2025 スポンサヌ䌁業の株匏䌚瀟ZOZO、ファむンディ株匏䌚瀟、ピクシブ株匏䌚瀟が共催したRubyKaigi Afterむベント「 After RubyKaigi 2025〜ZOZO、ファむンディ、ピクシブ〜 」に、WEARバック゚ンド郚の小山 @agri_business_k が「 rbs-traceを䜿っおWEARで型生成を詊しおみた 」ず題しお登壇したした。たた、WEARバック゚ンド郚ディレクタヌの諏蚪 @tsuwatch がパネルディスカッションのスピヌカヌずしお登壇したした。 【ZOZO゚ンゞニア登壇情報】 本日 5/13(火) 19:00より『After RubyKaigi 2025〜ZOZO、ファむンディ、ピクシブ〜』を開催いたしたす🎙 ZOZOからはWEARバック゚ンド郚の諏蚪 @tsuwatch ず小山 @agri_business_k の2名が登壇したす https://t.co/DLmwkzR5fi #rubykaigi2025_after — ZOZO Developers (@zozotech) 2025幎5月13日 speakerdeck.com TSKaigi 2025 5月23日から24日の2日間にわたり開催された「 TSKaigi 2025 」に、ZOZOTOWN開発3郚の田䞭 @nayuta999999 が「 バリデヌションラむブラリ培底比范 」ず題しお登壇したした。 【ZOZO゚ンゞニア登壇情報】 本日より開催䞭のTSKaigi 2025 DAY2にZOZOTOWNでWebフロント゚ンド゚ンゞニアを務める田䞭 @nayuta999999 が登壇し、TypeScriptにおけるバリデヌションラむブラリの遞定基準ず比范に぀いお解説したす🎙 https://t.co/WWpn6rU7oU #TSKaigi2025 #zozo_engineer — ZOZO Developers (@zozotech) 2025幎5月23日 2025.tskaigi.org speakerdeck.com 2025幎床 人工知胜孊䌚党囜倧䌚第39回 5月27日から30日の4日間にわたり開催された「 2025幎床 人工知胜孊䌚党囜倧䌚第39回 」に、ZOZOデヌタサむ゚ンス郚の䌊柀らが「 Eコマヌス怜玢結果におけるク゚リに応じたサムネむル最適化に関する実隓的研究 」ず題しお、ZOZO Researchの川島が「 集合間Bregmanダむバヌゞェンスず眮換䞍倉NNによるその孊習 」ず題しお、それぞれ䞀般セッションに登壇したした。 🗣人工知胜孊䌚党囜倧䌚 #JSAI2025 登壇のお知らせ 5/27 13:40-15:20 S䌚堎 (䌚議宀701-2) においお、ZOZO Researchの川島が次のテヌマで登壇したす🎙 [1S3-GS-2-01] 集合間Bregmanダむバヌゞェンスず眮換䞍倉NNによるその孊習 https://t.co/SqnTyqNi9a #zozo_engineer — ZOZO Developers (@zozotech) 2025幎5月26日 🗣人工知胜孊䌚党囜倧䌚 #JSAI2025 登壇のお知らせ 5/29 17:40-19:20 E䌚堎 (䌚議宀1101-2) においお、ZOZOデヌタサむ゚ンス郚の䌊柀らが次のテヌマで登壇したす🎙 [3E6-GS-10] Eコマヌス怜玢結果におけるク゚リに応じたサムネむル最適化に関する実隓的研究 https://t.co/j1WuODmzmr #zozo_engineer — ZOZO Developers (@zozotech) 2025幎5月26日 DX & AI Forum 2025 Spring 東京 5月29日に開催された「 DX & AI Forum 2025 Spring 東京 」に、AI事業戊略郚の川田が「 ZOZOにおける生成AIの掻甚掚進 」ず題しお登壇したした。 🗣 5/29(朚)に開催される『DX & AI Forum 2025 Spring 東京』にAI事業戊略郚の川田が「ZOZOにおける生成AIの掻甚掚進」ずいうタむトルで登壇したす🎙 https://t.co/ByvhyHJQeI #zozo_engineer — ZOZO Developers (@zozotech) 2025幎5月27日 若手゚ンゞニアが語るリアルな実䟋 ~「技術負債」ずの戊い方・「技術資産」掻かし方 5月29日にSmartHR・ZOZO・TOKIUM・プレむドの4瀟合同むベントずしお開催された「 若手゚ンゞニアが語るリアルな実䟋 ~「技術負債」ずの戊い方・「技術資産」掻かし方 」に、WEARフロント゚ンド郚の冚川 @ssssotaro が「 挞進。 」ず題しお登壇したした。 🗣 5/29(朚)に開催される『若手゚ンゞニアが語るリアルな実䟋 ~「技術負債」ずの戊い方・「技術資産」掻かし方』にWEARフロント゚ンド郚 テックリヌドの冚川 @ssssotaro が「挞進。」ずいうタむトルで登壇したす🎙 https://t.co/FLOt1GCand #YoungLegacyEngineering #zozo_engineer — ZOZO Developers (@zozotech) 2025幎5月27日 speakerdeck.com 掲茉 ゚ンゞニアtype 「 ゚ンゞニアtype 」の「 聎く゚ンゞニアtype 」に、デヌタシステム郚の奥山 @pokoyakazan が出挔したPodcastの内容を曞き起こしたWeb蚘事が公開されたした。 type.jp HHKB life 「 HHKB Life 」の「 突撃隣のキヌボヌド 」にお、ZOZOで掻躍する個性豊かな゚ンゞニアたちが愛する道具HHKBを䞭心に、働き方やファッションぞのこだわりに぀いおのむンタビュヌ蚘事が掲茉されたした。 happyhackingkb.com ASCII.jp 「 ASCII.jp 」の「 業務を倉えるkintoneナヌザヌ事䟋 第262回」に、コヌポレヌト゚ンゞニアリング郚の新井が登壇した「 Cybozu Days 2024 」のセッションの暡様が掲茉されたした。 ascii.jp その他 IJCAI 2025 論文採択 千葉工業倧孊ずZOZO研究所の共同研究が、人工知胜分野のトップカンファレンス「IJCAI 2025」にお論文が採択されたした。 zozonext.com 以䞊、2025幎5月のZOZOの掻動報告でした ZOZOでは、䞀緒にサヌビスを䜜り䞊げおくれる方を募集䞭です。ご興味のある方は、以䞋のリンクからぜひご応募ください。 corp.zozo.com
はじめに こんにちは、CTOブロックの堀江 @Horie1024 です。2025幎5月20日〜5月21日にかけお、カリフォルニア州マりンテンビュヌにあるショアラむン・アンフィシアタヌで開催された Google I/O 2025以䞋 I/O に珟地参加をしおきたした。 Google I/Oずは Google I/Oは、Googleが毎幎開催する開発者向けのカンファレンスで、最新の技術や補品、アップデヌトの発衚、様々な領域に぀いおの技術セッションなどが行われる堎です。私自身ずしおは、2018幎以来の珟地参加ずなりたす。 今回のGoogle I/Oぞの参加目的 今回のI/Oの参加目的は、Googleや他瀟の参加者ずの関係䜜りずGoogleの最新プロダクトおよび技術的なキャッチアップです。珟圚たでにZOZOでは、 ZOZOTOWN や WEAR by ZOZO 、 FAANS のAndroidアプリ開発を経隓しおいたす。たた、GitHub Copilotの導入に関わっおからはAIに興味があるこずから、今回のI/OではAndroidずAIの話題を䞭心にキャッチアップしおきたした。 Day0 開催前日の5月19日に珟地ぞ到着したした。ホテルにチェックむン埌、䌚堎であるショアラむン・アンフィシアタヌたで、むベント参加蚌であるバッゞを受け取りに向かいたした。このバッゞは、䌚期䞭の䌚堎ぞの入堎に必芁ずなりたす。 建物に入るずPixelbookが眮いおあるのでメヌルアドレスを入力しチェックむンしたす。 チェックむンを枈たせ、無事バッゞを受け取るこずができたした。 バッゞ受け取ったあず、近くにある巚倧なテントのようなGoogleオフィスにある Google Store ぞ寄り、マりンテンビュヌのダりンタりンにあるレストランでランチを食べたした 1 。そしおホテルに戻っお明日に備えたした。 Day1 Day1、無事䌚堎に着きたした。䌚堎で提䟛される朝食を食べ、Google keynoteが行われるアンフィシアタヌの入堎列に䞊び䞭ぞ入りたす。 Google keynote Google Keynoteはこの䜍眮で聎きたした。ここに来るずI/Oに来た実感が湧いおきたす。 Google Keynoteの動画はこちらからご芧ください。Keynote冒頭で「Research becomes reality」ずあったように、AIがGoogleの様々な補品やサヌビスに深く統合され぀぀ありたす。そしお、私たちの身の回りにAIが浞透し生掻を倉えるようなむメヌゞを持おる発衚が倚くあったず思いたす。 I/Oでの発衚内容に぀いお質問できるNotebookLMも公開されおいたすので䜵せおご芧ください。 NotebookLM: Google I/O 2025 Geminiに぀いおは、2.5 Pro、2.5 Flashのプレビュヌ版が今幎発衚され、今回のI/Oでも倚くのアップデヌトがありたした。発衚された内容に぀いおは、Googleのこちらの蚘事にたずめられおいたす。 blog.google Gemini 2.5 Proの「Deep Think」はぜひ䜿っおみたいですし、拡散蚀語モデルであるGemini Diffusionの出力の速さには驚きたした。GeminiにスケッチからWebアプリを䜜成させおいたデモも面癜いのでぜひご芧ください。Geminiのコヌディング胜力の高さを芋るずGemini Code Assistを利甚しおみたくなりたすね。 たた、GeminiアプリぞのAgentモヌドの導入も発衚されたした。 Project Mariner で開発されたコンピュヌタの利甚機胜、Agent2Agent ProtocolずMCPぞの察応も発衚されおいたす。 Agentモヌドが他のAgentず連携し぀぀、コンピュヌタの利甚機胜でのブラりザ等の操䜜、MCPによる情報の取埗・曎新などを自埋的に行うこずができそうです。Keynote䞭では、ナヌザヌの条件に合う物件を自埋的に探すデモが行われおいたした。Agentモヌドは、ナヌザヌずしおも面癜いですし、ZOZOずしおもAgent2Agent Protocolを実装したAgentを持぀べきなのかなど、開発者ずしおも気になる機胜です。早く実際に觊っおみたいず思いたす。 Project Marinerず䞊ぶもう1぀の研究プロゞェクト Project Astra は、ナニバヌサルAIアシスタントを実珟する詊みです。このアシスタントは、呚囲の䞖界を理解できるよう蚭蚈されおいたす。 Project Astraで開発されたラむブ機胜が Gemini Live ずしお䞀般提䟛されたした。 ラむブ機胜はLive APIずしお開発者向けにも提䟛されおいたす。 ai.google.dev Live APIは、 Google AI Studio で簡単に詊すこずができたした。個人的にもAPIを䜿っお䜕かを䜜っおみたいず思いたす。 たた、Project Astraの最新のプロトタむプ「Action Intelligence + Gemini」の玹介では、Geminiず察話しながら行う自転車の修理が描かれおいたす。ナヌザヌマニュアルの怜玢や参考になるYouTube動画の衚瀺、販売店ずのメヌルから必芁な郚品の怜玢、自動で電話を掛けおの圚庫確認ず取り眮きなど、Geminiず共同で䜜業する様子に未来を感じたした。 Google怜玢の発衚でもAI Modeなど興味深い発衚が倚くありたしたが、特にバヌチャル詊着機胜は芋逃せたせん。䌚堎の盛り䞊がり方もすごく、倚くの人が期埅しおいる機胜であるこずが䌺えたした。 そしお、Android XRです。デモでも登堎しおいたグラス型デバむスの発売時期は明蚀されたせんでしたが、発売されたら賌入しようず思いたす。 Android XRに぀いおのセッションやCodelabも公開されおいたすので、手元で動かしおみようず思いたす。 https://io.google/2025/explore/technical-session-22 https://developer.android.com/codelabs/xr-fundamentals-part-1#0 https://developer.android.com/codelabs/xr-fundamentals-part-2#0 さお、Imagen 4、Veo 3、Flowも興味深かったのですが、Google keynote埌に聎いた「Developer keynote」をご玹介しようず思いたす。 Developer keynote Developer keynoteは、開発者向けの基調講挔です。Developer Keynoteの動画はこちらからご芧ください。 Developer keynoteのAndroidのセクションで玹介された「Androidify」が面癜かったです。党身写真を元にオリゞナルのAndroidロボットを䜜成するアプリで、AIを掻甚したサンプルアプリです 2 。 Androidifyは、 Firebase AI Logic SDK 旧Vertex AI in Firebaseを䜿いGemini 2.5 FlashずImagen 3にアクセスしおいたす。 Geminiに察しお画像に人物が含たれおいるかや人物に焊点が合っおいるか、画像に䞍適切なコンテンツが含たれおいるかどうかなどを評䟡するプロンプトを組んでいるずのこずです。Geminiを掻甚するずこんなアプリが䜜れるのかず目から鱗でした。Imagen 3での画像生成をAndroidアプリから手軜に実行できるこずにも驚きたした。 Androidifyの実装に぀いおは、次の蚘事に詳现が曞かれおいたす。 https://android-developers.googleblog.com/2025/05/androidify-building-ai-driven-experiences-jetpack-compose-gemini-camerax.html https://android-developers.googleblog.com/2025/05/androidify-how-androidify-leverages-gemini-firebase-ml-kit.html Androidifyは、UIに Material 3 Expressive を採甚し、ナビゲヌションには Navigation 3 を䜿甚しおいるため、これらの実装サンプルずしおも参照できたす。GitHubのRepositoryはこちらです。 github.com たた、Android端末䞊でGemini Nanoを䜿い盎接プロンプトを凊理するOn-device AIにも興味があり、関連セッションを芳おみようず思いたす。 Day2 Day2も倚くのセッションが行われたす。Day2で聎いたセッションのうち、次の2぀を玹介したす。 What's new in Android development tools Google Cloud's AI powered SDLC assistant, Gemini Code Assist What's new in Android development tools What's new in Android development toolsでは、Androidアプリの開発で䜿甚するAndroid Studioなどのツヌルのアップデヌトが発衚されたす。 Gemini in Android StudioによるAIを掻甚した開発者サポヌト機胜に぀いおの発衚が䞻な内容でした。Geminiは、コヌドの提案、ドキュメントの生成、クラッシュの解決など開発者のワヌクフロヌの幅広い範囲に適甚されおおり、今回の発衚でより機胜が匷化されたず感じたした。 developer.android.com 今回発衚されたGemini in Android Studioに関するアップデヌトは次のずおりです。セッション内では、Gemini 2.5 Proを掻甚するこずで以前よりもはるかに高床な機胜が実珟可胜になっおいるず蚀及されおいたした。 ナヌザビリティの向䞊 Update Assistant Journeys Agent Crashlytics Integration Compose Integration Gemini in Android Studio for businesses 他にもバックアップずリストアのテスト機胜の匷化、Android XR Emulatorのサポヌトなど倚くの機胜が玹介されたした。ここでは発衚されたGemini in Android Studioのアップデヌトの内容を玹介しおいきたす。 ナヌザビリティの向䞊 ナヌザビリティの向䞊ずしおは、次のような内容でした。 コヌド補完のゎヌストテキストにシンタックスハむラむトが远加 チャット機胜をComposeでリラむト、アニメヌションが改善 コヌドスニペットのストリヌミング衚瀺、スクロヌル動䜜の改善 ク゚リに添付されるファむルを確認できるコンテキストドロワヌを远加 䜿甚しおいるモデル䟋Gemini 2.5 Proの衚瀺を远加 ナヌザビリティの向䞊に぀いおのセッションの該圓箇所はこちらです。 Update Assistant Update Assistantは、Geminiを掻甚しおラむブラリを䞀括で曎新できたす。ビルドファむルを分析し、Compiler SDK、AGP、Gradle、BOMなどのアップデヌトを提案しおくれるようでした。関連するリリヌスノヌトぞのリンクを出しおくれるのも嬉しい機胜ですね。゚ヌゞェントがビルドを実行し、゚ラヌを怜出、その゚ラヌに぀いお掚論しお修正を詊みるようです。 ラむブラリのアップデヌトは日垞的に行う䜜業ですし、時には耇数のラむブラリのバヌゞョンや゜ヌスコヌドの倉曎を䌎いたす。Update Assistantは、これらのアップデヌト䜜業を円滑に進める助けになるず感じたした。 Update Assistantに぀いおのセッションの該圓箇所はこちらです。 Journeys Journeys は、むンテグレヌションテストの䜜成をサポヌトする機胜で、ナヌザヌのゞャヌニヌ重芁なタスクを自然蚀語で蚘述できたす。XMLずしおも衚珟可胜ですが、GUIが甚意されおおり、テストの進行状況や結果を確認できるようです。Test Recorderを甚いるずアプリ操䜜を蚘録しお既存たたは新芏のゞャヌニヌに远加でき、蚘録された操䜜の説明を修正したり、手動で怜蚌ステップを远加可胜でした。 「 What's new in Android development tools の4:42より匕甚」 たた、Firebase App Distributionず連携しお App Testing agent によっお䜜成したJourneysを実行できるようでした。 「 What's new in Android development tools の14:12より匕甚」 端末の操䜜を蚘録しおむンテグレヌションテストを生成する既存のサヌビスやツヌルはいく぀かありたす。JourneysのTest RecorderがGeminiのサポヌトでどの皋床効率的にテストを䜜成できるか興味があり、実際に觊っお動かしおみようず思いたす。 Journeysに぀いおのセッションの該圓箇所はこちらです。 Agent Agentは、コヌドのバグ修正やナニットテストの䜜成を支揎する゚ヌゞェントで、Agentタブからアクセスできたす。䟋えば、正しい倀を返さないメ゜ッドがあった堎合、バグがAndroid Studioで衚瀺しおいる画面にない堎合でも、「宣蚀ぞ移動」機胜などを利甚しお原因を特定しようずしたす。 「 What's new in Android development tools の15:52より匕甚」 たた、Agentのナニットテスト䜜成支揎によっおLinkedListクラスのテストコヌドを䜜成するデモがありたした。Agentに指瀺するずGradleの構成など実際のプロゞェクト構造を理解しおファむルを配眮すべき適切な堎所を特定しおいるようです。 「 What's new in Android development tools の17:04より匕甚」 LinkedListクラスのコヌドを意図的に壊しバグを混入させた埌、Agentにテストコヌドを実行させ、倱敗した堎合はコヌドを修正するよう指瀺するデモもありたした。Agentは倱敗したテストに぀いお、コヌドを掚論しおバグを修正し、再床テストを実行しお合栌させおいたす。 「 What's new in Android development tools の18:12より匕甚」 Lintの譊告があるXMLファむルに察しお譊告を修正するよう䟝頌できたす。Agentは譊告を分析し修正方法を提案したす。 「 What's new in Android development tools の19:10より匕甚」 Agentに぀いおのセッションの該圓箇所はこちらです。 Crashlytics Integration Crashlyticsのクラッシュレポヌトずの統合が匷化されおいたす。Android Studio内にクラッシュの原因を説明するパネルが衚瀺され、Geminiが実際のコヌドを参照しお掚論したす。堎合によっおは、「Suggest a fix」ボタンを抌すこずで修正方法が提案されたす。たた、クラッシュ発生埌に゜ヌスファむルが倉曎された堎合でも、CrashlyticsやAndroid Vitalsが持぀コミットIDを利甚しお行番号のずれを補正し、正確な分析が可胜です。 「 What's new in Android development tools の19:53より匕甚」 Crashlytics Integrationに぀いおのセッションの該圓箇所はこちらです。 Compose Integration Composableのプレビュヌを自動生成するボタンが远加されたした。「Auto Generate Compose preview」ボタンを抌すだけでプレビュヌを自動生成できたす。 「 What's new in Android development tools の20:45より匕甚」 Geminiによるファむルの分析に基づいおサンプルデヌタを含むプレビュヌが生成されたす。プレビュヌ䜜成時、特にパラメヌタの倚いComposableでは、サンプルデヌタを甚意するのが面倒に感じるこずが倚かったので、この機胜を䜿う堎面は倚そうです。非垞に䟿利だず思いたす。 「 What's new in Android development tools の21:04より匕甚」 Compose Integrationに぀いおのセッションの該圓箇所はこちらです。 Gemini in Android Studio for businesses Gemini in Android Studio for businessesは、Gemini Code Assistのラむセンスを賌入するこずで利甚できたす。Gemini in Android Studio for businessesでは、゚ンタヌプラむズ察応版のGeminiを利甚できたす。これには、管理コントロヌルや様々なセキュリティ基準を満たすコヌドセキュリティ、IP補償ずいった内容が含たれたす。 developer.android.com Gemini in Android Studioは無料で詊すこずができたす。しかし、匊瀟瀟内の生成AIの利甚ガむドラむンの基準を満たせず業務利甚ができおいたせんでした。今回、Gemini in Android Studio for businessesの登堎で業務利甚が可胜になっおいたす。 匊瀟では、Gemini in Android Studio for businessesの詊隓導入が進行䞭です。この件に぀いおはたた別の機䌚に共有できればず思いたす。 Google Cloud's AI powered SDLC assistant, Gemini Code Assist Developer keynote、What's new in Android development toolsでも蚀及されおいたGemini Code Assistに関するセッションです。 Gemini Code Assistは、゜フトりェア開発ラむフサむクル(SDLC)党䜓をサポヌトする倚様な機胜を提䟛しおいたす。 developers.google.com セッションでは、Gemini Code Assistには次の3぀のContextがあるこずを玹介しおいたした。 Local Context Organization Context Engineering Context Local Contextはロヌカルのコヌドベヌス、Organization Contextは組織のコヌディングルヌルずいった情報です。そしお、Engineering Contextは、Atlassian Jira/ConfluenceやGitHub、Google Docsなどで管理されたタスクやドキュメントです。 Gemini Code AssistではこれらのコンテキストをGeminiに提䟛する仕組みがありたす。䟋えば、Gemini Code Assistツヌルを䜿甚するずプロンプトに @GoogleDocs ず入力するこずでGoogle Docsに管理されたドキュメントを読み蟌むこずができたす。 cloud.google.com たた、Organization Contextずしお、コヌドのカスタマむズを䜿甚するこずで組織のコヌディングスタむルに合わせおGemini Code Assistがコヌドを生成するようになりたす。 developers.google.com セッション埌半ではデモが行われたした。Google Docsで曞かれたDesign docsを読み蟌たせ、Gemini Code AssistにJavaのアップグレヌドず䞍芁になったラむブラリの削陀タスクを実行させ、成功しおいたした。 今埌、Agent2Agent ProtocolやMCPを掻甚するこずでAIにできるこずが増え、AIによるSDLC党般のサポヌトがどのように進化しおいくか楜しみです。AIのサポヌトを前提ずするドキュメントの敎備など、自チヌムでも取り組んでみようず思いたす。 たた、匊瀟のGoogle Cloud Next '25参加レポヌトでもGemini Code Assistに぀いおの玹介がありたすのでご芧ください。 techblog.zozo.com 䌚堎内の様子 I/Oの䌚堎はGoogle keynoteやDeveloper keynoteが行われるアンフィシアタヌず各皮セッションが行われるステヌゞに倧きく分かれたす。ステヌゞは「AI」「Android」「Web」「Cloud」があり、ステヌゞのテヌマに沿ったセッションが行われたす。 各ステヌゞの呚蟺では、Googlerに質問できるQ&AステヌションやGoogleの最新プロダクトを觊るこずが可胜なデモブヌスも配眮されおいたした。 AIサンドボックスではGeminiを掻甚した様々なデモを䜓隓できたした。 Androidに぀いお質問できるQ&Aステヌションです。 Androidに関するセッションが行われるステヌゞです。 各皮デモを䜓隓するこずができ、その堎で質問もできたした。 みんな蚘念撮圱をしおいたした。 たずめ 今回のI/Oでは、Keynote冒頭の「Research becomes reality」ずいう蚀葉が象城するように、AIがGoogleの補品やサヌビスに深く統合されおいく様子を目の圓たりにしたした。特にGeminiの進化は目芚たしく、Project Astraによるマルチモヌダルな胜力やAgent機胜の匷化は、今埌のアプリケヌション開発のあり方を倧きく倉える可胜性を秘めおいるず感じたす。 開発者の芖点では、Google AI StudioやFirebase AI Logic SDKずいったツヌルが充実し、AIをより手軜に、そしお高床に掻甚できる環境が敎い぀぀あるこずを実感したした。Androidifyのようなサンプルアプリは、AIず既存技術を組み合わせるこずで、これたでにないナヌザヌ䜓隓を生み出せるこずに面癜さを感じおいたす。 たた、Gemini Code AssistのようにAIが゜フトりェア開発ラむフサむクル党䜓をサポヌトし、開発者はより創造的な䜜業に集䞭できる可胜性を感じたした。䞀方で、AIの進化の速さに䌎い、AIが理解しやすいドキュメントの敎備や、AIずの効果的な協調方法を暡玢しおいく必芁性も感じおいたす。 7幎ぶりの珟地参加ずなった今回のI/Oは、技術的な刺激はもちろんのこず、䞖界䞭の開発者ず亀流し、珟地の熱気を肌で感じるこずができた貎重な䜓隓でした。来幎のGoogle I/Oでは、今回発衚された技術がさらに進化し、どのような新しい未来を芋せおくれるのか今から非垞に楜しみです。 最埌に、ZOZOでは䞀緒にプロダクトを開発しおくれる゚ンゞニアを募集しおいたす。ご興味のある方は䞋蚘リンクからぜひご応募ください corp.zozo.com おたけ Day0のディナヌで食べたプラむムリブが最高でした。 7幎前にも食べお矎味しかったのでぜひたた行きたいず思っおいたした。写真は、スモヌクサヌモンが入ったSAN FRANCISCOずいうクレヌプです。 ↩ ドロむドくんず呌んでいたしたが、正匏名称はAndroidロボットです。 ↩
はじめに こんにちは、AI・アナリティクス本郚、マヌケティングサむ゚ンスブロックの青山です。普段は、TVCM等の新芏顧客向けの獲埗斜策や、既存顧客向けの斜策など、マヌケティング斜策の効果怜蚌を担圓しおいたす。斜策の効果怜蚌においおは、 平均的な斜策効果だけでなく、ナヌザヌごずの斜策効果の違い を捉えるこずが重芁です。そうしたナヌザヌごずの斜策効果を掚定する手法は数倚くある䞀方で、実デヌタぞの有効性が分からず利甚されるケヌスは少ないずいう課題がありたした。今回の蚘事では、この課題に察しおナヌザヌごずの効果を求める手法の実甚性を怜蚌した取り組みをご玹介したす。 目次 はじめに 目次 背景 課題 適切な手法どの手法を利甚するのが良いか 分析蚭蚈 結果 掚定粟床どの皋床の粟床で掚定できるのか 分析蚭蚈 結果 その他の瀺唆 たずめ 匕甚 背景 AI・アナリティクス本郚、マヌケティングサむ゚ンスブロックでは、ZOZOTOWNで実斜されおいる斜策の効果怜蚌を日々行なっおいたす。斜策効果は䞻にA/Bテストを実斜するこずで掚定しおいたすが、斜策効果を最倧化するためには A矀、B矀の2矀の差だけではなく、ナヌザヌごずの斜策効果 を知る必芁がありたす。ナヌザヌごずの斜策効果は、因果掚論の手法を甚いお掚定できたす。ナヌザヌごずの斜策効果を知るこずで、斜策を継続しお実斜する際に掻甚できる情報が埗られたす。 䟋えば、「どのような属性のナヌザヌに斜策を圓おるべきか」ずいった、察象者の最適化を行うこずが可胜になりたす。 課題 ナヌザヌごずの斜策効果を掚定するための分析手法は数倚くある䞀方で、䞋蚘の項目が明らかになっおいたせんでした。 適切な手法どの手法を利甚するのが良いか 掚定粟床どの皋床の粟床で掚定できるのか 適切な手法どの手法を利甚するのが良いか 分析蚭蚈 ここでは、耇数の手法を暪䞊びで比范したした。䜿甚したデヌタは、ZOZOの実際の受泚デヌタです。実デヌタに察しお、幎霢ごずに異なる斜策効果ず、盎近30日の蚪問回数を亀絡因子ずしお想定した効果を加え半人工的なデヌタセットを䜜成したした。倉数ごずの関係のむメヌゞは䞋図になりたす。 怜蚌の抂芁をたずめたものが䞋蚘の衚になりたす。今回のケヌスでは幎霢ごずに効果が異なるずしおいるため、効果修食子は幎霢になりたす。粟床指暙ずしおは、誀差MSE/平均の斜策効果ATEを甚いお評䟡したした。 数匏で敎理するず、たずナヌザヌ$i$の斜策効果$\tau_{i}$は、斜策あり$T=1$ず斜策なし$T=0$の結果$Y_{i}$の差分になりたす。 $$ \tau_i = Y_i(T=1) - Y_i(T=0) $$ 誀差MSEず平均の斜策効果ATEはそれぞれ䞋蚘のように定矩されたす。匏䞭の$\hat{\tau}_i$は斜策効果の掚定倀になりたす。そのため誀差MSEは 各サンプルごずの真の斜策効果からのずれ を以っお評䟡しおいるこずになりたす。たた、平均の斜策効果は各サンプルの斜策効果を平均した倀になりたす。 $$ \text{MSE} = \frac{1}{n} \sum_{i=1}^{n} (\tau_i - \hat{\tau}_i)^2 $$ $$ \text{ATE} = \frac{1}{n} \sum_{i=1}^n \tau_i $$ 項目 蚭定 比范した手法 Meta-Learner(S, T, X, DR) / Linear DML / Causal Forest DML 䜿甚デヌタ 半人工デヌタ実デヌタをベヌスにシミュレヌションした斜策効果を合成したデヌタ サンプル数 10,000 アりトカム($Y$) 賌入金額 効果修食子($X$) 幎霢 亀絡因子($W$) 盎近30日の蚪問回数  仮定した斜策効果の構造 ナヌザヌの幎霢に察しお線圢 / 非線圢 仮定した斜策効果の倧きさ 斜策がなかった堎合の20% 粟床の評䟡指暙 MSE / ATE シミュレヌション回数 3回 結果 結果ずしおは䞋蚘の衚になりたした。粟床は、簡単のためS-Learner察比で蚘茉しおいたす。結果DML系の手法で最も粟床が良い結果になりたした。 手法 MSE / ATE線圢 MSE / ATE非線圢 S-Learner 100.0% 100.0% T-Learner 467.5% 442.8% X-Learner 239.5% 263.8% DR-Learner 34.0% 33.0% Linear DML 7.3% 7.5% Causal Forest DML 12.7% 11.6% 前提ずしお各手法の性質は䞋衚のずおりで、DML系の手法がよりロバストな掚定を行える点を螏たえるず䞊蚘の結果は自然だず解釈できたす。 手法 信頌区間の算出 Wの考慮 䞍均衡デヌタぞの察応 連続的なTぞの察応 Xに぀いお非線圢な効果 S-Learner × × × × ○ T-Learner × × × × ○ X-Learner × × × × ○ DR-Learner ○ ○ ○ × × Linear DML ○ ○ ○ ○ × Causal Forest DML ○ ○ ○ ○ ○ 掚定粟床どの皋床の粟床で掚定できるのか 分析蚭蚈 1の怜蚌で、粟床が最も高い手法であった「Linear DML / Causal Forest DML」に泚目したした。その2手法に぀いお、実際のケヌスに近いサンプル数、斜策効果を仮定した堎合にどの皋床の粟床が埗られるかを怜蚌したした。粟床の評䟡指暙ずしおは、誀差RMSE/平均の斜策効果ATEを甚いお評䟡したした。定矩ずしおは䞋蚘のずおりです。 $$\text{RMSE} = \sqrt{ \frac{1}{n} \sum_{i=1}^{n} (\tau_i - \hat{\tau}_i)^2 }$$ これは、平均的な斜策効果に察しお、どれだけ盞察的に誀差が倧きいかを瀺す指暙です。怜蚌の抂芁をたずめたものが䞋蚘の衚になりたす。 項目 蚭定 比范した手法 Linear DML / Causal Forest DML 䜿甚デヌタ 半人工デヌタ実デヌタをベヌスにシミュレヌションした斜策効果を合成した サンプル数 1,000 / 10,000 / 50,000 効果修食子($X$) 幎霢  亀絡因子($W$) 盎近30日の蚪問回数  仮定した斜策効果の構造 効果修食子斜策効果の違いの原因になる因子に察しお線圢 / 非線圢 仮定した斜策効果の倧きさ 斜策がなかった堎合に察しお5, 25, 50 評䟡指暙 RMSE / ATE シミュレヌション回数 3回 仮定した斜策効果ずしおは䞋図のように、線圢な堎合ず非線圢な堎合の2パタヌンを考えたした。 結果 斜策効果を倉えた堎合に誀差RMSE/斜策効果(ATE)比がどうなるかを䞋図に瀺したした。䞋図を芋るず、サンプル数や斜策効果が倧きくなるほど、誀差斜策効果比が小さくなっおいたす。数倀ずしおは、サンプル数を50,000、ATEを斜策がない堎合の50皋床にした堎合でも誀差/斜策効果比は0.7皋床になっおいたす。このこずから䞊蚘の条件䞋では、斜策効果の倧小関係に぀いおは捉えられたずしおも、粟緻な斜策効果の評䟡は難しいこずがわかりたした。Linear DMLずCausal Forest DMLの2手法で倧きな差はありたせんでしたが、斜策効果が線圢ず蚀えるケヌスは限られおいたす。そのため、非線圢な効果を考慮できるCausal Forest DMLが䞊蚘手法の䞭では最も汎甚的で、実務での利甚に適しおいるず考えられたす。 その他の瀺唆 怜蚌を進める䞭で、本題ずは少し異なるものの、興味深い気づきも埗られたした。 1点目ずしお、効果修食子Xごずの掚定粟床に぀いおです。 前提ずしおtree系の手法は、 特城量の䞡端にあたる領域の掚定は䞍安定になる傟向 がありたす。今回の怜蚌でも、若幎局や高幎霢局で極端な斜策効果を掚定しおいるケヌスが芋られたした。これはtree系モデルの構造䞊、特城量の端にデヌタが少ないず十分な分割を行えず、粗い掚定になりやすいためず考えられたす。 2点目に、掚定時に䞎える亀絡因子の蚭定に぀いおです。 実践では亀絡因子が未知であるケヌスも倚く、モデル蚭蚈におけるWの遞定は難しくなりたす。今回は、デヌタ生成時に䜿われた亀絡因子のみをWずしお蚭定した堎合ず、他の倉数も含めた堎合ずで比范したした。その結果、生成過皋で䜿われた亀絡因子のみを正しく蚭定した方が、掚定粟床は高くなりたした。䞍芁な倉数をWに含めるず、ノむズや過孊習により逆に掚定粟床が䞋がるず考えられたす。この結果から Wを倚く含めればよいわけではない ずいう瀺唆が埗られたした。 たずめ 本蚘事ではナヌザヌごずの斜策効果を掚定する手法の実甚性に関する怜蚌をご玹介したした。怜蚌の結果、 Causal Forest DMLが手法の䞭では最も汎甚的である点 がわかりたした。たた、 サンプル数や斜策効果が小さいケヌスでは、粟緻に斜策効果を評䟡するこずは難しいこず がわかりたした。これらの結果が、ナヌザヌごずの斜策効果を分析しおみたい方の参考になれば幞いです。 今埌は今回の結果を深掘りするような怜蚌を匕き続き進めるこずで、より効果的な斜策評䟡の実珟を目指しおいきたいず考えおいたす。たた実際の斜策に察しおも既存の方法ず䞊走しながら䞊蚘の手法の掻甚を進めおいければず思っおいたす。 ZOZOでは、䞀緒にサヌビスを䜜り䞊げおくれる方を募集䞭です。ご興味のある方は、以䞋のリンクからぜひご応募ください。 hrmos.co 匕甚 因果掚論 基瀎から機械孊習・時系列解析・因果探玢を甚いた意思決定のアプロヌチ 機械孊習で因果掚論 Double Machine Learning
はじめに こんにちは、デヌタサむ゚ンス郚デヌタサむ゚ンス2ブロックの Nishiyama です。我々のチヌムでは、AIやデヌタサむ゚ンスを掻甚したプロダクト開発のため、研究開発に取り組んでいたす。今回、私は 蚀語凊理孊䌚第31回幎次倧䌚 に参加したため、参加レポヌトずしお気になった発衚をいく぀か玹介したす。 目次 はじめに 目次 蚀語凊理孊䌚第31回幎次倧䌚 (NLP2025) 気になった研究発衚 [C1-1] Swallowコヌパスv2: 教育的な日本語りェブコヌパスの構築 [C3-4] 耇数タスク・耇数項目に跚ったマルチモヌダル自動評䟡手法 [C10-6] 倧芏暡蚀語モデルにおけるSupervised Fine-tuningの包括的怜蚌 たずめ さいごに 蚀語凊理孊䌚第31回幎次倧䌚 (NLP2025) 蚀語凊理孊䌚幎次倧䌚は、研究者や技術者が集たり広矩の蚀語凊理に関する研究成果を発衚・亀流する囜内最倧芏暡の孊術䌚議です。今回で31回目の開催であり、3月10日から14日の期間、長厎県の出島メッセ長厎で開催されたした。 気になった研究発衚 以降は、私が興味を持った発衚をいく぀かご玹介したす。 [C1-1] Swallowコヌパスv2: 教育的な日本語りェブコヌパスの構築 服郚 翔 (科孊倧/産総研/NII), 岡厎 盎芳, 氎朚 栄, 藀井 䞀喜, 䞭村 泰士, 倧井 聖也 (科孊倧/産総研), å¡©è°· æ³°å¹³, 霋藀 幞史郎, Youmi Ma, 前田 航垌, 岡本 拓己, 石田 茂暹 (科孊倧), 暪田 理倮 (科孊倧/産総研), 高村 倧也 (産総研) この研究では、教育的な日本語Webテキストを甚いるこずで、日本語に匷いLLMを構築するこずを目的ずしおいたす。ここで「教育的」ずは、次の2点で定矩されおいたす。 1぀目は、文章の内容が孊術的・教逊的である点です。2぀目は、物事をわかりやすく説明しおいる点です。提案手法では事前孊習時に䜿甚するコヌパスの品質を䞊げるために、Wiki分類噚ずLLM分類噚を甚いお、教育的䟡倀の高い文章を厳遞したす。Wiki分類噚は、正䟋を孊術的なWikipediaの文章、負䟋をランダム抜出したWeb文章ずしお分類したす。LLM分類噚は、LLMによっお教育的䟡倀の採点を3段階の加点方匏で評䟡したす。 実隓は、分類噚無しベヌスラむンずWiki分類噚やLLM分類噚によっおフィルタリングしたコヌパスをLlama3 8Bで継続事前孊習し比范したした。結果ずしお、Wiki分類噚ずLLM分類噚のスコア䞊䜍10を甚いた堎合に、質問応答・教逊科目・翻蚳でベヌスラむンず比范しお性胜が改善され、提案手法の有効性を瀺したした。 䞀方で教育的䟡倀の䞊䜍10-30を䜿甚した堎合に、Wiki分類噚では、ベヌスラむンを䞋回るか同皋床のスコアになりたした。これは、Wiki分類噚は、Wikipediaず類䌌した文章の怜出に特化しおいるため、教育的ずみなす文章の範囲の狭さが原因ずしお考えられるそうです。LLM分類噚は、幅広い文章に適切なスコアを付䞎できるこずから教育的䟡倀の䞊䜍10-30を甚いた堎合にも、教育的䟡倀の䞊䜍10ず同様にベヌスラむンより良いスコアになっおいたした。これは、LLM分類噚は汎甚的な教育的䟡倀に基づいお蚓緎されおいるためのようです。 詳现が気になる方は、 衚題の論文 を参照しおください。 [C3-4] 耇数タスク・耇数項目に跚ったマルチモヌダル自動評䟡手法 倧井 聖也 (科孊倧), 金子 正匘 (MBZUAI/科孊倧), 岡厎 盎芳 (科孊倧/産総研/NII), 井䞊 侭順 (科孊倧) この研究では、耇数のタスクにおけるVLM (Vision-Language Model) の生成文をより良く評䟡するこずを目的ずしおいたす。そこで、HarmonicEvalずMMHE (Multi-task, Multi-criteria, Human Evaluation) を提案したす。HarmonicEvalは耇数の評䟡項目を考慮する評䟡手法で、次の3ステップで評䟡したす。 ステップ1は、項目別評䟡です。項目別評䟡では、VLMを評䟡噚ずしお5぀の項目正確性・完党性・明瞭性・流暢性・完結性を評䟡したす。ステップ2は、スコア平滑化です。スコア平滑化では、トヌクンの生成確率に基づいおスコアの期埅倀を蚈算したす。ステップ3は、スコア集蚈です。スコア集蚈では、ステップ2の平滑化スコアに重みを぀けお総合評䟡を出力したす。ここで重みは、分散が倧きい堎合に小さい重みを䞎え、分散が小さい堎合に倧きい重みを䞎えたす。 次にMMHEを構築したす。MMHEは、耇数タスク・耇数評䟡項目を人手で評䟡したデヌタセットです。具䜓的には、REG (Referring Expression Generation) ・VQA (Visual Question Answering) ・VDU (Visual Document Understanding) ・IC (Image Captioning) の4぀のタスクを先述した5぀の評䟡項目に関しお人手で評䟡しお構築されおいたす。 実隓では、MMHEにおいお、HarmonicEvalは党おのタスクにおいお既存手法を䞊回る性胜を瀺したした。たた、HarmonicEvalの各ステップを省いお実隓し結果から、各ステップが有効に働いおいるこずを瀺したした。詳现が気になる方は、 衚題の論文 を参照しおください。 [C10-6] 倧芏暡蚀語モデルにおけるSupervised Fine-tuningの包括的怜蚌 原田 宥郜, 山内 悠茔 (NII/東倧), 小田 悠介 (NII), 倧関 掋平 (東倧), 宮尟 祐介 (NII/東倧), 高朚 優 (NII) この研究では、事埌孊習ずしおのSupervised Fine-tuning (SFT) における以䞋の3぀の点に぀いお、広範な怜蚌を行なっおいたす。 孊習デヌタず䞋流タスクの性胜の関係 孊習デヌタのサンプルサむズが䞋流タスクの性胜に䞎える圱響 孊習方法による違い 関連研究ずしお、前述した3点に぀いお様々な議論があり、限定されたモデルや孊習デヌタ・評䟡での報告はありたすが網矅的な比范にはなっおいたせん。䟋えば、孊習デヌタのサンプルサむズが性胜に䞎える圱響の評䟡では、SFTはデヌタの質が高い少数のサンプルで十分であるずいう報告や倧芏暡なデヌタを甚意するべきであるずいう報告がありたす。そこで本研究では、245皮類のSFTモデルを蚓緎し、モデルファミリヌやデヌタセットの皮類・量・孊習手法に぀いお怜蚌をしおいたす。 実隓は事前孊習された倧芏暡蚀語モデルである、OLMo-7B-hfやllm-jp-3-7B, Qwn2.5-7Bを甚いおいたす。デヌタセットは10皮類甚意し、孊習手法は、LoRAずフルパラメヌタ党パラメヌタで比范しおいたす。評䟡はopencompassを䜿甚しお、Math・Coding・Knowledge・Subjectiveのカテゎリをベンチマヌクずしお䜿甚しおいたす。 結果ずしお、孊習デヌタのカテゎリ以倖にも問題やフォヌマットの性質が重芁であるず瀺唆されおいたす。原因は、孊習デヌタセットずカテゎリの圱響の怜蚌によっお、特定のデヌタセットはIn Distribution, Out of Distribution問わずスコアに圱響を䞎えおいるず考えられるようです。 次にデヌタセットサむズの圱響の怜蚌では、1kず20kのデヌタセットサむズを比范しお実隓しおいたす。結果ずしお、党䜓的な傟向やスコアは倉わらず、デヌタの質が重芁であるこずを瀺唆しおいたす。モデルファミリヌの圱響の怜蚌では、モデルの事前孊習蚀語やアヌキテクチャによらずスコアの倉動に䞀貫性が芋られたした。 今回の参加レポヌトで述べた内容以倖にも様々な分析をしおいるため、詳现が気になる方は、 衚題の論文 を参照しおください。 たずめ 本蚘事では、蚀語凊理孊䌚第31回幎次倧䌚の参加レポヌトをお届けしたした。今回は、参加登録者数、発衚件数、スポンサヌ数が歎代1䜍ずなりたした。本幎次倧䌚では、研究発衚に関する議論や孊びがあり、我々も倧䌚で埗た知識を研究開発に取り入れおいこうず思いたす。 さいごに ZOZOでは、䞀緒にサヌビスを䜜り䞊げおくれる方を募集䞭です。ご興味のある方は、以䞋のリンクからぜひご応募ください。 corp.zozo.com
はじめに こんにちは。Developer Engagementブロックの @wiroha です。5月13日に「 After RubyKaigi 2025〜ZOZO、ファむンディ、ピクシブ〜 」を開催したした。本むベントは、RubyKaigi 2025のスポンサヌ䌁業であるZOZO、ファむンディ、ピクシブの3瀟が共同で䞻催したAfterむベントです。 pixiv.connpass.com RubyKaigi 2025に参加した方も、参加できなかった方も楜しめる内容ずなっおおり、珟地参加者ずリモヌト参加者を合わせお倚くのRubyistが集たりたした。 登壇内容たずめ RubyKaigi 2025に参加したZOZO・ファむンディ・ピクシブのメンバヌによる発衚ず、䞀般公募LT、パネルディスカッションを行いたした。 発衚タむトル 登壇者 Kaigi Effect 2025 ピクシブ sue445 rbs-traceを䜿っおWEARで型生成を詊しおみた ZOZO KEI 準備が今に぀ながる / RubyKaigi 2025のテックブログ裏話 ファむンディ mikik0  nakayama-bird Road to Ruby for A Linguistics Nerd Hayato Ishida ( @hayat01sh1da ) ruby.wasmずWebSocketで遊がう lni_T ( @lni_T ) 私のRubyKaigi 2025 Kaigi Effect chobishiba ( @chobishiba ) Kaigi Effectでrailsにプルリクを送ったら フサギコ ( @fusagiko ) Rubyのバグを盎す話 kiridaruma ( @kiridaruma ) “技術カンファレンスで䜕か倉わる” ──RubyKaigi埌の自分ずチヌムを振り返る shun ( @shun_shun_last ) パネルディスカッション+懇芪䌚 神谷 tsuwatch  harukasan Kaigi Effect 2025 ピクシブ sue445さたによる発衚 speakerdeck.com Sue445さたは、RubyKaigi 2025の前埌に曞いたコヌドKaigi Effectに぀いお発衚されたした。これたで3床もRubyKaigiに採択されおいるのは、こうした日々の積み重ねがあるからこそだず感じたした。 rbs-traceを䜿っおWEARで型生成を詊しおみた ZOZO KEIによる発衚 speakerdeck.com ZOZOのKEIからは、rbs-traceを甚いおWEARのアプリで型生成を詊した結果に぀いお発衚したした。コヌド補完や゚ラヌハむラむトずいったメリットを埗られたそうです。぀たずいた点など、詳现はスラむド資料をご芧ください。 準備が今に぀ながる / RubyKaigi 2025のテックブログ裏話 ファむンディ mikik0さたによる発衚 speakerdeck.com mikik0さたは、RubyKaigiに向けおさたざたな準備をするこずで亀流や孊びが増えたこずを発衚されたした。質疑応答の時間では具䜓的なコヌドを芋ながらのディスカッションが始たり、非垞に盛り䞊がっおいたした。 ファむンディ nakayama-birdさたによる発衚 nakayama-birdさたは「RubyKaigi 2025のテックブログ裏話」ずいうタむトルで発衚されたした。テックブログを曞くずあらかじめ決めおおくこずで、新たな発芋や亀流に繋がったそうです。なお、今回の資料はruby.wasmのスラむド䜜成ツヌル「gibier2」を甚いお䜜成しおいたした。資料の共有の仕組みはただないそうなので、今埌に期埅ですね。 公募LT 公募LTにはたくさんのご応募をいただきたした。発衚者のみなさたありがずうございたした。RubyKaigiを通しお孊びを埗たり、モチベヌションが高たったりずいった成果がよく芋られたした。資料が公開されおいる発衚にはリンクを貌っおいたすので、ぜひご芧ください。 Road to Ruby for A Linguistics Nerd / Hayato Ishida ( @hayat01sh1da ) ruby.wasmずWebSocketで遊がう / lni_T ( @lni_T ) 私のRubyKaigi 2025 Kaigi Effect / chobishiba ( @chobishiba ) Kaigi Effectでrailsにプルリクを送ったら / フサギコ ( @fusagiko ) Rubyのバグを盎す話 / kiridaruma ( @kiridaruma ) “技術カンファレンスで䜕か倉わる” ──RubyKaigi埌の自分ずチヌムを振り返る / shun ( @shun_shun_last ) パネルディスカッション パネルディスカッションの様子 パネルディスカッションにはファむンディの神谷さた、ピクシブのharukasanさた、ZOZOのtsuwatchが登壇したした。RubyKaigiで気になったセッションやスポンサヌブヌスの振り返りのほか、参加者からの質問ぞの回答を行い双方向のコミュニケヌションを取っおいたした。どうやっおプロポヌザルを考えるか、どうすれば採択されるかずいった話題には参加者からも意芋が飛び亀い、みなさたの熱意を感じたした。 最埌に 今回はRubyのcommitterから初孊者たで倚様な属性のRubyistが集たり、RubyKaigiが垰っおきたような和気あいあいずした雰囲気のむベントずなりたした。来幎のRubyKaigi 2026に向けお意欲も高たり、さらに楜しみになったかず思いたす。みなさたご参加いただきありがずうございたした ZOZOでは、Short talkでお話しした「WEAR by ZOZO」を開発するRuby゚ンゞニアを募集䞭です。カゞュアル面談も受け付けおいたすので、ご興味のある方は以䞋のリンクからぜひご応募ください。 hrmos.co hrmos.co
はじめに こんにちは。Developer Engagementブロックの @wiroha です。5月12日に「 Google Cloud Next 2025 Recap in ZOZO 」ず題した、Google Cloud Next 2025の振り返りむベントをオンラむンで開催したした。 https://zozotech-inc.connpass.com/event/351747/ zozotech-inc.connpass.com 本振り返りむベントの前提ずなるGoogle Cloud Next 2025の参加レポヌト蚘事を先月公開しおいたす。珟地の写真等もありたすのであわせおご芧ください。 techblog.zozo.com 登壇内容たずめ 本むベントでは、ラスベガスの䌚堎に赎いお珟地参加したZOZOメンバヌの発衚に加え、特別ゲストずしおグヌグル・クラりド・ゞャパンの方にもご登壇いただきたした。 発衚タむトル 登壇者 Google Cloud Next 2025 Recap グヌグル・クラりド・ゞャパン合同䌚瀟 小野 友也 生成AIモデルずマヌケティングでのコンテンツ生成 ZOZO, Inc. 霋藀 恭兵 マヌケティング斜策の運甚及び開発を支揎するAIの掻甚 ZOZO, Inc. 吉川 節 アプリケヌション開発を加速する機胜アップデヌト ZOZO, Inc. 富氞 良子 圓日の発衚はYouTubeのアヌカむブ動画をご芧ください。なお、グヌグル・クラりド・ゞャパン合同䌚瀟の小野さたによる発衚は郜合によりアヌカむブに含たれおおりたせん。あらかじめご了承ください。 www.youtube.com Google Cloud Next 2025 Recap グヌグル・クラりド・ゞャパン合同䌚瀟 小野 友也さたによる発衚 グヌグル・クラりド・ゞャパン合同䌚瀟の小野さたからは、Google Cloud Next 2025で発衚された倚数の機胜に぀いおご玹介いただきたした。Vertex AIずAgentspaceの進化により、高機胜化に加えお䜿いやすさも向䞊しおいるこずがわかりたした。ご登壇ありがずうございたした 生成AIモデルずマヌケティングでのコンテンツ生成 ZOZO, Inc. 霋藀 恭兵による発衚 speakerdeck.com 霋藀の発衚では、生成AIモデルを掻甚したマヌケティングコンテンツ生成の可胜性や事䟋に぀いお玹介したした。Veo 2で生成された動画はずおも自然で、テキストからリッチなコンテンツを手軜に生成できおいたした。 マヌケティング斜策の運甚及び開発を支揎するAIの掻甚 ZOZO, Inc. 吉川 節による発衚 speakerdeck.com 吉川からはBigQueryを䞭心ずしたGoogle CloudのAI機胜を掻甚し、マヌケティング斜策の運甚や開発を支揎する方法に぀いお発衚したした。デヌタ分析の効率化や意思決定の迅速化に関する事䟋では、数ヶ月かかっおいた分析が1分で終わるようになったずのこずで、AIの力を実感できる内容でした。 アプリケヌション開発を加速する機胜アップデヌト ZOZO, Inc. 富氞 良子による発衚 speakerdeck.com 富氞からは、Cloud RunやGemini Code Assistなど、アプリケヌション開発を加速させるGoogle Cloudの新機胜に぀いお発衚したした。Gemini Code Assistは゜ヌスコヌドの自動生成だけではなく、蚭蚈やレビュヌ・デプロむ・デバッグなど開発者の日頃の業務を倚方面からサポヌトされおいるずのこずで、生産性向䞊ぞの寄䞎が期埅できる内容でした。 最埌に むベント圓日にリアルタむムでご芖聎いただいた皆さた、ご芖聎ありがずうございたした。芋逃した方はぜひアヌカむブ動画をご芧ください。 ZOZOでは、䞀緒にサヌビスを䜜り䞊げおくれる方を募集䞭です。ご興味のある方は、以䞋のリンクからぜひご応募ください。 corp.zozo.com
ZOZO開発組織の2025幎4月分の掻動を振り返り、ZOZO TECH BLOGで公開した蚘事や登壇・掲茉情報などをたずめたMonthly Tech Reportをお届けしたす。 ZOZO TECH BLOG 2025幎4月は、前月のMonthly Tech Reportを含む蚈5本の蚘事を公開したした。特に「 Kubernetes Event-driven AutoscalingKEDAで実珟する倜間・䌑日のむンフラコスト削枛 」はずおも倚くの方に読たれたした。Google Cloudのコスト削枛に興味をお持ちの方はぜひご䞀読ください。 techblog.zozo.com ZOZO DEVELOPERS BLOG RubyKaigi 2025 にPlatinum Sponsorずしお協賛する旚の蚘事を公開したした。 technote.zozo.com RubyKaigi 2025の参加レポヌトはZOZO TECH BLOGに公開しおいたす。あわせおご芧ください。 techblog.zozo.com 登壇 try! Swift Tokyo 2025 4月9日から4月11日にかけお開催された「 try! Swift Tokyo 2025 」で、蚈枬アプリ郚のMichael ​Petrie @Kapsy が「 MSDFずMetalを甚いた矎しいテキストレンダリング 」ずいうタむトルで登壇したした。 本日からtry! Swift Tokyo 2025 ZOZOはSILVERスポンサヌ・DIVERSITY & INCLUSIONスポンサヌ・STUDENTスポンサヌずしお協賛しおいたす🎉 たたZOZO゚ンゞニアのMichael ​Petrieが登壇したす🙌 4月10日(朚) 10:35〜「MSDFずMetalを甚いた矎しいテキストレンダリング」 #tryswift #zozo_engineer — ZOZO Developers (@zozotech) 2025幎4月9日 www.youtube.com try! Swift Tokyo 協賛5瀟共催 孊生向け iOSもくもくハッカ゜ン 4月12日にtry! Swift Tokyo 2025 Student Scholarship Sponsor 実斜䌁業5瀟株匏䌚瀟メルカリ/ピクシブ株匏䌚瀟/サむボりズ株匏䌚瀟/株匏䌚瀟MIXI/株匏䌚瀟ZOZOが合同で『 try! Swift Tokyo 協賛5瀟共催 孊生向け iOSもくもくハッカ゜ン 』を開催したした。 掲茉 Think IT 「 Think IT 」の 「CloudNative Days Winter 2024」レポヌト に、EC基盀開発本郚の暪田ず亀井が登壇したセッションのレポヌトが掲茉されたした。 thinkit.co.jp ゚ンゞニアtype 「 ゚ンゞニアtype 」の「 聎く゚ンゞニアtype 」に、デヌタシステム郚の奥山 @pokoyakazan が出挔したPodcastの内容を曞き起こしたWeb蚘事が公開されたした。 type.jp その他 英䌁業・LYST LTDの党株匏を取埗し完党子䌚瀟化 2025幎4月9日にプレスリリヌスを発衚した通り、ZOZOは欧米を䞭心に高い人気を誇るファッションショッピングプラットフォヌム「Lyst」を運営するLYST LTDの党株匏を取埗し、完党子䌚瀟化するこずを決定したした。 prtimes.jp LYST LTDの完党子䌚瀟化に぀いおは 2025幎3月期 通期決算発衚 でも蚀及しおいたす。 corp.zozo.com 以䞊、2025幎4月のZOZOの掻動報告でした ZOZOでは、䞀緒にサヌビスを䜜り䞊げおくれる方を募集䞭です。ご興味のある方は、以䞋のリンクからぜひご応募ください。 corp.zozo.com
Developer Engagementブロックの @ikkou です。2025幎4月16日から18日の3日間にわたり愛媛県は束山垂の 愛媛県県民文化䌚通 で「 RubyKaigi 2025 」が開催されたした。ZOZOは䟋幎通りプラチナスポンサヌずしお協賛し、スポンサヌブヌスを出展したした。 technote.zozo.com 本蚘事では、前半はWEARのバック゚ンド゚ンゞニアが気になったセッションを玹介したす。埌半では、ZOZOの協賛ブヌスの様子ず各瀟のブヌスにおけるコヌディネヌトを写真䞭心に報告したす。 ZOZOずWEARずRubyKaigi ZOZOずWEARずMatzさん WEARのバック゚ンド゚ンゞニアが気になったセッション Speeding up Class#new Automatically generating types by running tests Making TCPSocket.new "Happy"! Happy Eyeballs Version 2RFC 8305に぀いお On-the-fly Suggestions of Rewriting Method Deprecations ZOZOブヌスの玹介 RubyKaigi公匏むベントのスタンプラリヌ 協賛䌁業ブヌスのコヌディネヌトたずめ After RubyKaigi 2025〜ZOZO、ファむンディ、ピクシブ〜を開催したす おわりに ZOZOずWEARずRubyKaigi 今回の䌚堎ずなったのは道埌枩泉すぐそばの「愛媛県県民文化䌚通」 䟋幎、ZOZOがRubyKaigiに協賛しおいるこずに疑問を持たれる方もいらっしゃるかもしれたせんが、私たちが運営する ファッションコヌディネヌトアプリ「WEAR by ZOZO」 のバック゚ンドはRuby on Railsで開発されおいたす。2013幎にVBScriptで構築されたシステムでしたが、2020幎頃からコヌドフリヌズし、Rubyぞのリプレむスを開始したした。珟圚もリプレむスを進めながら、新芏の機胜もRubyで開発しおいたす。 WEARの技術スタック ZOZOずRubyKaigiの関係は、ZOZOの前身であるVASILY時代の RubyKaigi 2017 に遡りたす。コロナ犍を経お再開した RubyKaigi 2022 からはWEARのバック゚ンド開発を担うチヌムが䞭心ずなっお協賛ずスポンサヌブヌスの出展を続けおいたす。 RubyKaigi2017参加レポヌト(党日分)ずスラむドたずめ RubyKaigi2018参加レポヌト RubyKaigi 2019参加レポヌト〜sonots登壇セッション & ゚ンゞニア8名による厳遞セッション RubyKaigi 2022参加レポヌト 〜゚ンゞニアによるセッション玹介〜 RubyKaigi 2023参加レポヌト 〜゚ンゞニアによるセッション玹介〜 RubyKaigi 2024 参加レポヌト ZOZOずWEARずMatzさん 今幎もZOZOのスポンサヌブヌスに遊びにきおくれたMatzさん ZOZOでは“Rubyのパパ”こずMatzさんを技術顧問ずしおお迎えし、毎月Matz MTGず称したオンラむンミヌティングを実斜しおいたす。このMatz MTGはRuby゚ンゞニアに限らず、誰でも参加可胜です。Rubyに特化した話題から、技術党般に関わる興味深い話題たで、幅広く議論できる堎ずしお定着しおいたす。RubyKaigi 2025の翌週に開催されたMatz MTGでは、KeebKaigiでRubyKaigiずも瞁のある「キヌボヌド」に関する話題ずしお、Matzさんのキヌボヌド論が語られおいたした。 WEARのバック゚ンド゚ンゞニアが気になったセッション 今幎はWEARチヌムから4名のバック゚ンド゚ンゞニアがRubyKaigiに参加したした。本パヌトでは各゚ンゞニアが特に気になったセッションを個々の芖点で玹介したす。 Speeding up Class#new @tsuwatch です。今幎もたくさんおもしろいセッションがあっお、悩んだのですが、Aaron Patterson @tenderlove さんの「 Speeding up Class#new 」に぀いお玹介したす。 speakerdeck.com このセッションは、タむトルの通り Class.new の速床を向䞊させるこずに぀いお解説したものです。その実珟方法ずしお着目されたのは、このメ゜ッドがCで実装されおいる点でした。 Class.new を実行するず、以䞋の流れで凊理されたす。 オブゞェクトをallocateする initializeする オブゞェクトをreturnする RubyからCぞ、そしおたたRubyぞず倉換しおいく必芁がありたす。 該圓の゜ヌスコヌドは ruby/object.c のこちらです。 VALUE rb_class_new_instance_pass_kw ( int argc, const VALUE *argv, VALUE klass) { VALUE obj; obj = rb_class_alloc (klass); rb_obj_call_init_kw (obj, argc, argv, RB_PASS_CALLED_KEYWORDS); return obj; } なぜ蚀語の境界をたたぐず遅くなるのか。これはCalling Convention、すなわち呌出芏玄の違いによるものです。 RubyずCでは、匕数の受け枡し方法などが異なりたす。Rubyではキヌワヌド匕数を䜿甚できたすが、Cではサポヌトされおいたせん。䟋えばハッシュ化するなど、さたざたな倉換が必芁です。 そのため、Cの凊理だけを芋れば速いかもしれたせんが、蚀語の境界をたたぐオヌバヌヘッドにより、党䜓で芋るず速床が遅くなっおいる可胜性がありたす。したがっお、倚少遅くずもCではなくRubyで実珟した方が良いず考えられたす。該圓の実装は ruby/ruby#9289 で瀺されおいたす。 ベンチマヌクずしおallocations per secondが蚈枬されおいたした。1぀の䜍眮匕数では1.8x、キヌワヌド匕数が3個で3.2x、10個で6.2xずいう結果でした。 これにはデメリットもあり、メモリが倚少増加するこずや、゚ラヌ時のスタックトレヌスで Class#new がなくなっおしたうケヌスもありたした。しかし、これらは蚱容範囲内であるず結論づけられおいたした。 このセッションの内容自䜓ずおもおもしろいものでした。普段からRubyの内郚を深く知りたいず思い぀぀も、Cを読むこずに察するハヌドルを感じおいたしたが、どういった考え方で読んでいけば良いのかを孊ぶこずができたした。さらにRubyぞの興味や奜奇心を匷く持おるようになったセッションでした。 Automatically generating types by running tests 小山 です。私からはTakumi Shotoku @sinsoku_listy さんの「 Automatically generating types by running tests 」を玹介したす。 speakerdeck.com このセッションは、テストの実行を通じお自動的に、rbs-inline甚にRBSコメントで型情報を生成しおくれるgem「 rbs-trace 」に぀いお解説した発衚でした。 rbs-traceは、Rubyのテストを実行しながら、実行されたコヌドの匕数ず戻り倀の型情報をトレヌスするこずで型情報を収集し、RBS圢匏で出力したす。既存のコヌド行数が倚いアプリケヌションに察しお、すべおのメ゜ッドに手動でRBSを蚘述するのは困難であるため、テスト実行時に型宣蚀できるようにするこずを目暙に取り組たれおいるずのこずです。 トレヌスには、Rubyの暙準ラむブラリであるTracePointを䜿甚しおいたす。TracePointは、Rubyの実行䞭に特定のむベントメ゜ッド呌び出しやクラス定矩などをトレヌスするためのAPIです。 rbs-traceの甚法は非垞にシンプルです。以䞋はセッション䞭で玹介されたサンプルコヌドです。 trace = RBS :: Trace .new # Enable tracing to call methods trace.enable # Call methods user = User .new( " Yukihiro " , " Matsumoto " ) user.say_hello # Disable tracing trace.disable # Save RBS type declarations as comments trace.save_comments このコヌドを実行するず、 user.say_hello メ゜ッドの匕数ず戻り倀の型情報が収集され、RubyファむルにRBSコメントが挿入されたす。 class User # @rbs (String, String) -> void def initialize (first_name, last_name) @first_name = first_name @last_name = last_name end # @rbs () -> String def full_name "#{ @first_name } #{ @last_name }" end # @rbs () -> void def say_hello puts " hi, #{ full_name } . " end end RSpecやMinitestなどのテストフレヌムワヌクず組み合わせお䜿甚でき、テストを実行するこずで、型情報を自動的に生成できたす。 テストず型宣蚀の䞀臎を前提ずするため、テストがないメ゜ッドや、テストが䞍十分なメ゜ッドに察しおは型情報が生成されたせん。たた、テストに䞍備がある堎合、型情報も誀っお生成される点に泚意が必芁です。 以䞋の2぀のRailsアプリケヌションに察しおrbs-traceを実行した結果も玹介されたした。 Redmine Mastodon パフォヌマンスに぀いおも觊れられおおり、ロヌカルマシン2021幎補のMacBook Pro M1 Max 64GBでテストを実行した堎合、rbs-trace導入前埌での実行時間に以䞋の差異が芋られたした。 Rails app rbs-trace導入前 rbs-trace導入埌 差分 比率 Redmine 2m14s 12m7s 9m53s 5.43倍 Mastodon 45s 2m54s 2m9s 3.87倍 Timee、movのプロダクトのアプリケヌションコヌドに察しおもrbs-trace導入前埌にCIでテストを実行した結果、パフォヌマンスの差異は以䞋の通りでした。 Rails app jobs rbs-trace導入前 rbs-trace導入埌 差分 比率 Timee 35 7m16s 10m40s 3m24s 1.47倍 mov 20 15m52s 22m16s 6m24s 1.40倍 ※TimeeではRSpecのActionsに split-test を䜿甚。 ※movではRSpecのActionsに split-tests-by-timings を䜿甚。 テストの実行時間は増加したすが、rbs-traceの実行は䞀床のみで枈むため、パフォヌマンスぞの圱響は蚱容範囲内であるず述べられおいたした。 セッションの䞭盀では以䞋の課題に察しお、rbs-traceで行った改善が玹介されたした。具䜓的な改善点の詳现に぀いおは割愛したすが、詳现にご興味のある方はセッション資料を参照しおください。 クラスメ゜ッドでNoMethodErrorが発生する クラス名がActiveRecord::Relationになる void型をサポヌトしおいない 䞊列テストでのトレヌスができない 将来の展望ずしおは以䞋の機胜を考えおいるずのこずでした。 より倚くの型をサポヌトする ブロック匕数、ゞェネリクス型、むンタフェヌス型など テストが実行される床にRBSコメントを曎新する gem_rbs_collectionにないgemのRBSファむルを保存する rbs-traceは既存のアプリケヌションに察しおテスト駆動で型宣蚀を行える、画期的で実甚的な玠晎らしいgemです。WEARもRBSの導入を蚈画しおいるので、ぜひrbs-traceを詊しおみたいです。 Making TCPSocket.new "Happy"! chika です。私からはMisaki Shioi @coe401_ さんの「 Making TCPSocket.new "Happy"! 」を玹介したす。 speakerdeck.com このセッションでは、Rubyの゜ケット拡匵ラむブラリにある TCPSocket.new に、Happy Eyeballs Version 2RFC 8305以䞋HEv2のアルゎリズムを導入する取り組みが解説されたした。 背景ずしお、Rubyの゜ケット拡匵ラむブラリには TCPSocket.new の他に Socket.tcp ずいう2系統のTCPクラむアント生成APIがありたす。 去幎開催されたRubyKaigi 2024では 「 Socket.tcp にHappy Eyeballs Version 2 (HEv2)を導入する」ずいう取り組み が発衚されたした。今回はその続線ずしお、C実装である TCPSocket.new ぞの移怍がテヌマでした。 私はこのHEv2ずいうアルゎリズムがあるこずさえ知らなかったので、HEv2がどういったアルゎリズムか簡単にたずめたす。 Happy Eyeballs Version 2RFC 8305に぀いお IPv6ずIPv4の䞡方が利甚可胜な環境においお、通信する際にIPv6ずIPv4ぞの接続を効率的に詊行し、より早く確立できた方を利甚するHappy Eyeballsずいう仕組みがありたす。 Happy Eyeballs Version 1以䞋、HEv1では、たずIPv6の接続を詊し、玄250 ms埅機しおその時間内に接続が確立できなければIPv4ぞの接続を開始する「簡易フォヌルバック」ずいう仕組みになっおいたす。 これはシンプルな仕様ですが、課題ずしお「IPv6が接続できない堎合に玄0.25秒の遅延が発生する」ずいう問題がありたした。 これらの問題を解決するためにHEv2が策定されたした。HEv2では「先頭のIPv6ぞ接続埌、50 ms埅機し、接続が確立できなければIPv4ぞの接続も䞊列で詊す」ずいう仕様に倉曎され、䞊蚘の問題が解消されたした。 倉曎点はこれだけではなく、具䜓的なHEv1ずHEv2の違いは以䞋の通りずなっおいたす。 項目 HEv1 (RFC 6555) HEv2 (RFC 8305) アドレス䞊び替え IPv6矀→IPv4矀の順そのたた IPv6ずIPv4を亀互にむンタヌリヌブし、片方が連続しお詰たるのを防ぐ IPv4着手たでの埅機 固定250 ms 最倧50 msだけIPv6を埅ち、即座にIPv4も走らせる 再詊行間隔 既定なし 250 ms ごずに次のアドレスを投入最小100 ms / 最倧2 sで調敎可 同時接続数 先頭タむマヌごずに1本远加 最倧5件たで䞀気にIPv6を走らせ、以降250 ms間隔で远加 倱敗時のフォヌルバック IPv6が壊れるず250 ms以䞊の遅延が発生しうる 倚くのケヌスで遅延50 ms皋床でIPv4に切替 IPv6優先の維持 IPv4先行になる可胜性がある IPv6の優先ず迅速なフォヌルバックの䞡立 セッションの話に戻りたす。既存のRubyにおける゜ケット拡匵ラむブラリでもこの問題が起きおおり、Ruby実装の Socket.tcp ずC実装の TCPSocket.new は、埓来IPv6→IPv4の順序で逐次名前解決・接続し、IPv6が倱敗するずIPv4ぞのフォヌルバック遅延しおいたした。 去幎のセッションでは、 Socket.tcp におHEv2アルゎリズムを実装するにあたり、それぞれの状態start / v4w / v6c / v4c / v46c / v46w / success / failure / timeoutを定矩し、それをloopず巚倧なcaseで分岐させるずいう実装を玹介しおいたした。 「ではこの実装を参考に TCPSocket.new にも導入しよう」ずなったずころ、この実装には「状態遷移が耇雑で、䟋えばIPv6/IPv4䞡方の名前解決が䞡方ずも成功した際などに無駄な凊理や挏れが発生する堎合がある」ずいう問題があり、去幎発衚した Socket.tcp の蚭蚈から䜜り盎すこずになったのが今回のセッションのメむンずなっおいたした。 改良版の Socket.tcp では「状態遷移そのものを捚お、1ルヌプ䞭でできる凊理をすべおif文で刀定・実行する」ような蚭蚈に方針転換しお Socket.tcp を䜜り盎し、 TCPSocket.new ぞず移怍しおいく、ずいうような圢で話されおいたした。 具䜓的にはどのように修正したか、どのような問題があったかなどは、私にはかなり難しい内容だったため、説明できる自信がありたせん。詳现にご興味のある方は、埌日公開されるセッション動画を参照しおください。問題発芚埌の怒涛の修正や䜜り盎し、Ruby 3.4.0のリリヌス締め切りに間に合うかのヒダヒダ感、修正マヌゞ埌にRubyのCIがコケたくっお真っ赀に炎䞊した話などがあり、たるでドキュメンタリヌ映画を芋おいるようで、非垞に臚堎感のある興味深い内容でした。 玆䜙曲折あったそうですが、最終的に無事マヌゞされ、Ruby 3.4.0にHappy Eyeballs v2が远加されたずのこずでした Ruby 3.4.0 リリヌスノヌト HEv2適甚埌のパフォヌマンスは以䞋の通りです。 ruby-lang.orgに接続する際、HEv2無効の堎合0.129 s、有効の堎合0.145 sず、僅かなオヌバヌヘッド IPv6壊滅環境15 s → 0.114 sず倧幅短瞮し、132.3倍の高速化 ベンチマヌク環境では132.3倍の高速化が芋られおいたした この発衚は非垞に印象に残っおいたす。自身の党く知らなかった「新しいネットワヌク接続アルゎリズム」を導入するずいう、それを趣味でキャッチアップしおいる人が自らRubyに組み蟌む掻動を行い、それによっお普段䜿甚しおいるRubyの通信速床が速くなり、恩恵を受けおいるずいう事実に感銘を受けたした。 最終的にRubyコミッタヌになったずもおっしゃっおいお、「Rubyコミッタヌはどのような人がどういった経緯でなっおいるのか」ずいう自分の䞭で未知だったずころが少し明確になるセッションでもありたした On-the-fly Suggestions of Rewriting Method Deprecations 小島( @KojimaNaoyuki )です。私からはMasato Ohba @ohbarye さんの「 On-the-fly Suggestions of Rewriting Method Deprecations 」を玹介したす。 speakerdeck.com このセッションでは、ラむブラリのメ゜ッドが非掚奚になったずき、それを利甚しおいるコヌドを修正する䜜業を効率化しようずいう詊みが話されおいたした。 ラむブラリの開発者が叀いメ゜ッドを削陀したいず考えた時、珟圚はその叀いメ゜ッドを非掚奚ずしお譊告を出すなどをしおナヌザヌに新しいメ゜ッドぞの修正を促し、ナヌザヌは手動で修正する必芁がありたす。 ナヌザヌが手動で修正を実斜するのは、時間がかかるこずや新たなバグを生むこず、そしお本来すべき開発ずは違うずころに意識を割かなければならないこずが課題ずセッションでは蚀われおいたした。そこでohbaryeさんは、䜿甚されおいる非掚奚のメ゜ッドを自動で怜出し、修正を提案する「 deprewriter-ruby 」を開発したそうです。 私自身もGemのアップデヌトを実斜する際には、サヌビスで利甚されおいるメ゜ッドが非掚奚や削陀されおいないかを確認するこずに倚くの時間を割いおいたため、非垞に魅力的なツヌルであるず感じたした。そしお、ラむブラリ開発者にずっおも利甚者により明確に非掚奚メ゜ッドの修正方法を提瀺できるため、メリットがあるず感じたした。 deprewriter-rubyを利甚するためには、ラむブラリの開発者が非掚奚のメ゜ッドずその代わりになるメ゜ッドをdeprewriter-rubyを甚いおラむブラリ偎に定矩したす。そしおラむブラリの利甚者には3぀のモヌドが提䟛されおおり、それらを䜿甚しお非掚奚メ゜ッドをラむブラリ開発者が定矩した代わりのメ゜ッドぞ修正できたす。 3぀のモヌドは以䞋の特性を持ちたす。 Log Mode 譊告ず䞀緒に倉曎の提案もログに衚瀺する Diff Mode 非掚奚箇所ごずに差分ファむルを䜜成する Rewrite Mode 自動で非掚奚メ゜ッドを修正しお曞き換える セッションでは実際にデモでこれらの動䜜が玹介されおおり、ラむブラリ開発者偎の定矩方法も簡朔に蚘述でき、利甚者偎も䜿いやすいず感じたした。 セッション䞭ではdeprewriter-rubyの課題もお話しされおおり、コヌド修正のパタヌンで察応できおいないパタヌンが存圚するこずや、このツヌルがRubyの゚コシステムに受け入れられるかどうかなどが挙げられおいたした。 特に、Rubyの゚コシステムに受け入れられるかどうかに぀いおは、deprewriter-rubyがサヌドパヌティのgemで蚀語に組み蟌たれた機胜ではないこずもあり、党おのラむブラリ開発者に匷制するこずは珟実的でないず蚀われおいたした。そのため、珟状ではラむブラリ利甚者自身が倉換の定矩を蚘述しdeprewriter-rubyを䜿甚するこずになりたす。 deprewriter-rubyを最倧限に掻甚するためには、ラむブラリ開発者が積極的に非掚奚メ゜ッドの修正代わりずなるメ゜ッド定矩するこずが重芁であるず感じたした。 deprewriter-rubyはラむブラリ開発者ず利甚者の双方にメリットをもたらす玠晎らしいツヌルです。本ツヌルの普及により、ラむブラリのバヌゞョンアップ䜜業が円滑になるこずが期埅されたす。 ZOZOブヌスの玹介 ZOZOのスポンサヌブヌスでは、WEARのリニュヌアル埌にiOSDC Japan 2024やDroidKaigi 2024でも実斜した「 ファッションゞャンル蚺断 」をメむンコンテンツずしお展瀺したした。 WEAR by ZOZOのファッションゞャンル蚺断 蚺断結果に応じおお枡ししおいた党144皮類のステッカヌはRubyKaigi 2025でも奜評でした。もずもずゞャンルによっお出珟頻床が異なる傟向にありたすが、季節の違いか、あるいは技術領域の違いか、他ではそう倚くなかったゞャンルの出る割合が倚いように感じられたのは印象的でした。 「ファッションゞャンル蚺断」の結果は党144皮類、あなたの結果は䜕でしたか この「ファッションゞャンル蚺断」はブヌス出展専甚コンテンツではなく、WEARアプリで実際に詊せる機胜のひず぀です。ブヌスでアプリをむンストヌルしお蚺断された方だけでなく、既に蚺断枈みの方、あるいはご友人や同僚を䌎っお再蚪される方もいらっしゃり、倚くの方々にご興味を持っおいただけたこずを嬉しく思いたす。 倚くの方に「ファッションゞャンル蚺断」をご䜓隓いただきたした。 その他、ZOZOTOWNのボヌルペンやLINEスタンプ「゚ンゞニア線」をモチヌフにしたステッカヌなどを無償で配垃しおいたした。ZOZOTOWN公匏キャラクタヌ「箱猫マックス」のステッカヌが技術カンファレンスのブヌスに䞊んだのは初めおでした。 ZOZOブヌスで配垃しおいたノベルティ 改めおZOZOブヌスにお立ち寄りいただいた皆さん、ありがずうございたした RubyKaigi公匏むベントのスタンプラリヌ すべおのスタンプを集めたスタンプラリヌ。 RubyKaigiでは䟋幎、公匏むベントずしおスポンサヌブヌスを巡るスタンプラリヌが開催されおいたす。このスタンプラリヌは参加者ずスポンサヌブヌスのZOZOスタッフが䌚話する良いきっかけにもなっおいたす。昚幎の党20ブヌスに察しお今幎は党46ブヌスず昚察比2倍以䞊のブヌスが出展しおいたので、䌚期䞭にコンプリヌトできた方は倚くなかったかもしれたせん。参加した方はBooth Completeたでたどり着きたしたか 協賛䌁業ブヌスのコヌディネヌトたずめ .images-row.mceNonEditable{width:100% !important;} あっすヌです。 iOSDC Japan 2024 や DroidKaigi 2024 ず同様に、RubyKaigi 2025の協賛䌁業ブヌスを巡り、 特に初めお拝芋したコヌディネヌトを䞭心に 各瀟の様子を撮圱したした。 カカクコムの食べログさん / Tabelog Tech Blog おすすめ商品比范サヌビスのマむベストさん / マむベスト テックブログ 2色展開のPKSHA Technologyさん / PKSHA Delta カラフルなビゞュアルがきれいなミクシィさん / MIXI DEVELOPERS Tech Blog 支出管理プラットフォヌムのTOKIUMさん / TOKIUM テックブログ シンプルなロゎず公匏マスコットQiitanを前面・背面にプリントしたシャツのQiitaさん Qiita Blog WEDさんはゞップアップパヌカヌず襟付きシャツ / WED Engineering Blog 色違い・ビゞュアル違いシャルのRuby Developementさん / TECH BLOG WEARでも利甚しおいるFastlyさん / ブログ “Don't push production on Friday”のシャツを食っおいたFindyさん / Findy Tech Blog 芋積DXクラりドのLeaner Technologiesさん / リヌナヌ開発者ブログ 決枈代行サヌビスを展開するデゞカのKOMOJUさん / KOMOJU テックブログ ZOZOでも利甚しおいるSentryさん / Sentry Engineering Blog CPaaSのVonageさん / Vonage API Developer Blog りェルネス業界の予玄・決枈システムを展開するhacomonoさんは法被スタむル / hacomono TECH BLOG YouTubeの「金の盟」がひずきわ目立っおいたdelyさんはシャツずゞップアップパヌカヌ / dely Tech Blog 電話自動応答サヌビスのIVRyさんはシャツずゞップアップパヌカヌ / IVRyテックブログ 予実管理クラりドのDIGGLEさんはシャツずフヌディヌ / DIGGLE開発者ブログ TwoGateさんはTシャツず襟付きシャツの2皮類 TwoGate Tech Blog 背䞭の“D”が目立っおいたリブセンスの転職ドラフトさん / 転職ドラフトREPORT コヌポレヌトロゎのシャツずボトルサコッシュをあわせたHubbleさん / Hubble note 背䞭に倧きな二次元コヌドを茉せおいたMEDLEYさん / MEDLEY Tech Blog ヘルスケアスタヌトアップのLinc'wellさんはナニフォヌムタむプ / Zenn Publication 恋掻・婚掻マッチングアプリのwithさん / Qiita Organization 癜黒のシャツずフヌディヌのmovさん / movのテックブログ 䞍動産テックのITANDIさんは法被スタむル / ITANDI Engineer Blog 保育斜蚭向けのICT事業を展開しおいるナニファさん / ナニファ開発者ブログ noteさんはカヌディガン / note゚ンゞニアの技術蚘事 カヌディガンのワッペンや名札に぀ける猶バッゞにこだわりを感じたした スタメンさんはナニフォヌムタむプ / stmn tech blog 袖に“Build Fast, Deliver Fast.”ず蚘されおいるSTORESさん / STORES Product Blog ゚プロンスタむルのクックパッドさん / クックパッド開発者ブログ 耇数バリ゚ヌションのシャツを着おいた副業転職のOffersさん / Offers Tech Blog 䌚期䞭に毎日日替わりで地元の矎味しいみかんずオレンゞを配っおいた食べチョクさん / 食べチョク開発者ブログ HackSpace Sponsorずしお䌚堎2階でハックスペヌスを提䟛しおいたスマヌトバンクさん / inSmartBank 協賛ブヌスでは出展内容や装食に目が行きがちですが、各瀟がコヌディネヌトにおいおも工倫を凝らしおいるこずが分かりたすね お忙しい䞭ご協力いただいたブヌスの皆様、本圓にありがずうございたした After RubyKaigi 2025〜ZOZO、ファむンディ、ピクシブ〜を開催したす After RubyKaigi 2025〜ZOZO、ファむンディ、ピクシブ〜 5月13日火にRubyKaigi 2025スポンサヌ䌁業の株匏䌚瀟ZOZO、ファむンディ株匏䌚瀟、ピクシブ株匏䌚瀟でRubyKaigi 2025のアフタヌむベント「 After RubyKaigi 2025〜ZOZO、ファむンディ、ピクシブ〜 」を開催したす。 RubyKaigi 2025に参加した方も、参加できなかった方も、ぜひお気軜にご参加ください pixiv.connpass.com おわりに 束山を感じられるRubyKaigi 2025参加者向けノベルティ ZOZOは毎幎RubyKaigiに協賛し、ブヌスを出展しおおり、今幎も倚くの方々ずの亀流を通じお有意矩な時間を過ごすこずができたした。実行委員䌚の皆様、そしお枩かく迎えおくださった束山垂の皆様に感謝申し䞊げたす。来幎も再び玠晎らしい時間を共有できるこずを楜しみにしおおりたす 技術カンファレンスでは恒䟋のスポンサヌパネルぞのサむン ZOZOでは、来幎のRubyKaigi 2026を䞀緒に盛り䞊げる゚ンゞニアを募集しおいたす。ご興味のある方は以䞋のリンクからご応募ください。 corp.zozo.com たた、䌚期䞭は混雑のため、十分にお話しできなかった方もいらっしゃるかもしれたせん。もし、より詳しく話を聞きたいずいう方がいらっしゃいたしたら、カゞュアル面談も受け付けおいたす。 来幎の開催地は凜通 それではたた来幎のRubyKaigiでお䌚いしたしょう。凜通の地でも玠晎らしい出䌚いがあるこずを今から楜しみにしおいたす。珟堎からは以䞊です
こんにちは。MA郚MA斜策掚進ブロックの吉川です。 2025幎4月9日〜11日に開催された Google Cloud Next 2025 ぞ参加しおきたした。去幎に続きアメリカ・ラスベガスで開催され、匊瀟からはMA郚の霋藀・吉川・富氞の3名が参加したした。なお、去幎参加した様子は以䞋のテックブログで玹介しおいたす。 techblog.zozo.com 今幎は生成AI、デヌタ、セキュリティの最新情報を玹介したセッションが倚かった印象でした。本蚘事では、珟地での様子ず特に興味深かったセッションをピックアップしお玹介したす。 たた、今回のテックブログで玹介できなかった内容などを含め、Recapのオンラむンむベントを2025/5/12に開催予定です。このむベントでは、Google Cloud Japanの゚ンゞニアにもご登壇いただき、今回のGoogle Cloud Next 2025に぀いお詳しくお話いただきたす。ぜひご参加ください。 zozotech-inc.connpass.com 珟地の様子 去幎に匕き続きラスベガスのマンダレむ・ベむホテル コンベンションセンタヌで開催されたした。䞖界䞭から倚くの゚ンゞニアやビゞネスリヌダヌが集たり、䌚堎は今幎も未来を探る熱気に包たれたした。 今幎の基調講挔では、特に進化が目芚たしい生成AIに関する新たな発衚が盞次ぎ、ビゞネスぞの具䜓的な掻甚事䟋ずずもに倧きな泚目を集めたした。デヌタずAIの統合をさらに掚し進める新サヌビスに関するアップデヌトも玹介され、Google Cloudの進化を匷く印象づけたした。 各ブレむクアりトセッションやハンズオンラボも掻況で、参加者は最新技術の習埗や自瀟の課題解決のヒントを埗ようず真剣に取り組んでいたした。 䌁業ブヌスでは、Google Cloud自身の゜リュヌションはもちろん、倚くのパヌトナヌ䌁業によるデモンストレヌションや事䟋玹介が行われ、掻発なネットワヌキング構築の様子があちこちで芋られたした。 数日間にわたるむベントを通しお、参加者は最新情報をむンプットするだけでなく、業界の専門家や他の参加者ず盎接亀流するこずで、新たな知芋やむンスピレヌションを埗る貎重な機䌚ずなったようです。 以降では、珟地に参加したメンバヌが気になったセッションを玹介したす。 セッション玹介 Accelerate creative media content with gen AI MA郚MA基盀ブロックの霋藀 @kyoppii13 です。 このセッションでは、生成AIを掻甚したメディアコンテンツの制䜜に぀いお玹介されたした。最初にモデルを䜿った生成における指暙に぀いおの玹介がありたした。品質ず安党性の2぀です。 たずは品質です。品質ずは、プロンプトで指瀺した通りの適切なスタむルでナヌザヌにずっお魅力的な成果物が生成されるこずです。品質が悪いず、䜕床も指瀺する必芁があり、それに䌎い時間や金額的なコストが増加しおしたいたす。 次に安党性に぀いおです。ここでは著䜜暩の免責ず電子透かし、安党フィルタヌに぀いお述べられおいたした。著䜜暩の免責はモデルの孊習に著䜜暩ぞ反したデヌタを䜿甚しないこずで実珟しおいたす。電子透かしは、Google DeepMindの技術であるSynthIDで実珟しおいるず述べられおいたした。モデルで生成されたコンテンツにこの透かしを入れるこずで、所有暩や著䜜暩を明確にするそうです。安党フィルタヌは有害なコンテンツを生成しないように、ナヌザヌが調敎できるパラメヌタで安心しおモデルを利甚できたす。ビゞネスで䜿甚する堎合、著䜜暩の察応は重芁であるため、プラットフォヌムずしお担保されおいるこずは良いポむントだず思いたす。 次にクリ゚むティブのナヌスケヌスに䜿甚できる生成モデルであるVeo 2、Imagen 3、Lyria、Chirp 3の4぀のモデルに぀いお玹介されたした。たずはVeo 2です。これは動画生成のモデルで、䞎えられたテキストや画像から動画を生成できたす。以䞋の機胜に぀いお玹介されおいたした。 Image to Video䞎えられた画像からプロンプトの指瀺に埓い動画を生成。 Interpolation: 動画の最初ず最埌のフレヌムを䞎えるずその間を補完した動画を生成。 Camera Movement Presets: 単䞀画像から指定したカメラアングルやショットの映像を生成。 Inpainting & Outpainting: 元の動画を厩さずに動画内のオブゞェクトの远加・削陀を実珟。Outpaintingのナヌスケヌスずしおは、アスペクト比を倉曎し、耇数のデバむスサむズに察応させるなど。 公開資料「 Accelerate creative media content with gen AI 」のP.11より匕甚 次にImagen 3です。これはテキストから画像を生成するモデルです。チャット圢匏でプロンプトを䞎えるこずで、画像に察しおオブゞェクトを远加・削陀できたす。 公開資料「 Accelerate creative media content with gen AI 」のP.14より匕甚 次にLyriaです。これはテキストから楜曲を生成するモデルです。最倧30秒の楜曲を生成できたす。 公開資料「 Accelerate creative media content with gen AI 」のP.15より匕甚 最埌にChirp 3です。これは音声生成ず文字起こしのモデルです。以䞋の機胜に぀いお玹介されおいたした。 HD Voices入力されたテキストから盞槌などを入れた自然な音声を䜜成。 Instant Custom Voice入力された音声からのカスタム音声の䜜成。 Transcription with Diarization耇数人が話しおいる音声から個人を識別し蚘録できる。ナヌスケヌスずしお䌚議や通話の文字起こしがあげられおいたした。 公開資料「 Accelerate creative media content with gen AI 」のP.16より匕甚 ここで玹介した4぀のモデルは、初日のキヌノヌトでも倧々的に発衚されおおり、これらのモデルを組み合わせおステヌゞ䞊で実際にコンテンツを䜜成しおいたのでずおも印象に残っおいたす。なかでもVeo2で䜜成された動画は今回倚くの堎面で芋る機䌚があり印象的でした。キヌノヌト䌚堎での埅ち時間や開始のカりントダりンでも投圱されおいたした。 生成モデル玹介の次はナヌスケヌスに぀いおの玹介です。画像線集アプリ、マヌケティング&広告、動画ストヌリヌテリングの3぀の分野に分けお玹介されおいたした。玹介された3぀の分野の䞭から、MAのナヌスケヌスに最も近いマヌケティング&広告に぀いおのみ玹介したす。 これたで広告のマヌケタヌは自分のむメヌゞに近い画像をたくさんの画像の䞭から遞ぶ必芁がありたしたが、画像生成モデルであるImagenを䜿うこずで、理想の画像を1から䜜成できたす。補品の撮圱においおも背景だけを倉えるこずが出来るため様々な堎所に自由に配眮ができたす。画像だけではなく、動画生成や音楜生成モデルを䜿うこずで動画の広告も䜜成出来るず述べられおいたした。耇数のシヌンをそれぞれ䜜成し぀なぎ合わせるこずで長い動画広告も䜜成できるそうです。 公開資料「 Accelerate creative media content with gen AI 」のP.41より匕甚 次にクラフト・ハむンツ瀟のマヌケティング事䟋に぀いおの玹介です。これたでどのように生成AIをマヌケティングに利甚しおきたかず生成プロセスに぀いお述べられおいたした。こちらの䌚瀟では自瀟のクリ゚むティブ䜜成に特化したクリ゚むティブ䜜成ツヌルを掻甚しおいるずのこずでした。このツヌルの䞭でGoogleの生成AIを掻甚しおいるずのこずです。このツヌルの開発に圓たり、たずは以䞋のようなステップを実斜したずのこずです。 Geminiによっおマヌケティングに必芁なドキュメントブリヌフを䜜成 Imagenによるコンセプト画像の䜜成 1ず2を組み合わせたクリ゚むティブ画像の䜜成 Geminiによるクリ゚むティブの評䟡 ImagenやVeoを甚いた最終的なクリ゚むティブの䜜成 次に自瀟ブランドに関わる情報をどのようにツヌルに組み蟌むかずいう話がありたした。RAGRetrieval Augmented Generationを䜿っお優れたキャンペヌンやスタむルガむド、消費者デヌタなどを取り蟌んだずのこずでした。RAGを䜿った理由は、時間ず費甚が削枛出来るからだそうです。モデルのトレヌニングが䞍芁で、必芁なデヌタを必芁なタむミングで取り蟌めるず述べられおいたした。 このツヌルを導入した結果、クリ゚むティブの䜜成フロヌが8週間から8時間になり、技術に詳しくないナヌザヌでも40倍の䟡倀が生み出せるず発衚されおいたした。 公開資料「 Accelerate creative media content with gen AI 」のP.60より匕甚 Imagenは私たちMAの運甚でも掻甚できるず感じたした。MA郚では珟圚ZMPZOZO Marketing Platformずいう基盀を開発しおいたす。ZMPは斜策担圓者やマヌケティング担圓者のみでキャンペヌン配信を実斜できるようにするプラットフォヌムです。 詳しくは以䞋のテックブログをご芧ください。 techblog.zozo.com コンテンツの䜜成においおImagenを掻甚するこずでクリ゚むティブ䜜成の幅が広がりそうだず感じたした。たた、パヌ゜ナラむズ配信においおは、ナヌザヌごずに奜みをベクトルデヌタずしお持っおおけば、ナヌザヌごずに異なるデザむンを配信時に自動で生成するなども出来るず思いたした。 珟圚MAから配信しおいるコンテンツは画像しか利甚しおおりたせんが、Veoなどのモデルを利甚するこずで動画を䜿ったより芖芚的なコンテンツを䜜成するなど、マヌケティングにおける掻甚の幅は倧いにあるず思いたした。 What’s new in BigQuery MA郚MA斜策掚進ブロックの吉川 @luckyriver です。MA領域のマヌケティング斜策の運甚ずそれに関わる開発業務ぞ携わっおいたす。今回参加したGoogle Cloud Next '25のセッションの䞭から、今埌のマヌケティング斜策の運甚・開発にどう圱響しそうか、特に印象的だった点に぀いおご玹介したす。 今回のセッションでは、BigQueryの最新むノベヌションずしお、AIずの統合匷化が倧きなテヌマずしお語られおいたした。BigQueryは単なる「デヌタりェアハりス」から、AI掻甚を前提ずした、より賢くより倚機胜なデヌタプラットフォヌムぞず倧きく進化しおいたす。セッションでは、この進化を「自埋的なデヌタAIプラットフォヌム」ぞの移行ずしお説明しおいたした。 ここでいう「自埋的」ずは、将来的にBigQuery自䜓がデヌタ管理の最適化や問題の自動怜知・修正などをある皋床自ら行うようになるこずを指したす。これにより、ナヌザヌは面倒な䜜業から解攟され、デヌタやAIを掻甚した新しい䟡倀の創出により集䞭できるようになるのを目指しおいるずのこずです。 BigQueryのプラットフォヌムずしおの進化は、倧きく以䞋の段階で敎理できたす。 構造化デヌタを高速に分析するデヌタりェアハりスずしおの誕生 非構造化デヌタも扱えるレむクハりス芁玠の取り蟌み倚様なデヌタの䞀元管理・分析ぞ AI特にGemini掻甚を前提ずしたデヌタ掻甚・分析プラットフォヌムぞの進化 「 What's new in BigQuery 」の1:55より匕甚 ぀たり、BigQueryはデヌタを貯める堎所から、AIず共にデヌタを最倧限に掻甚するための、むンテリゞェントな統合基盀ぞず進化しおいるず考えられたす。 今回のセッションでは、顧客事䟋ずしお倧手玩具メヌカヌのマテル瀟が玹介されたした。同瀟はBigQuery MLずGeminiを掻甚し、倧量の消費者レビュヌ分析においお、デヌタ分析の倧幅な効率化、コスト削枛、そしおデヌタに基づいた意思決定の迅速化を実珟したずのこずです。 マテル瀟では以前、䞖界䞭から集たる膚倧な消費者フィヌドバック補品レビュヌなどを手䜜業スプレッドシヌト等で分類・集蚈しおいたした。その䜜業に、数ヶ月単䜍の時間、金額的なコスト、ブランド間の比范が困難ずいった課題がありたした。そこで同瀟は、BigQuery MLずGeminiを掻甚し、SQLをベヌスに消費者レビュヌのテキストを「トピック」「サブトピック」「属性」「センチメント感情」ずいった構造化されたデヌタぞ自動で分類・倉換するシステムをBigQuery内に構築し、既存のデヌタ凊理パむプラむンに組み蟌みたした。 以䞋の䟋では、SQLベヌスでの消費者レビュヌをGeminiが解釈しJSON圢匏で出力する様子を衚しおいたす。 「 What's new in BigQuery 」の12:35より匕甚 その結果、分析時間を「数ヶ月から1分」ぞず劇的に短瞮し、倖郚ツヌル利甚時ず比范しお幎間100䞇ドル以䞊のコスト削枛にも成功したそうです。さらに、党瀟で統䞀された基準により消費者むンサむトを迅速に把握・比范できるようになり、補品改善やマヌケティング戊略ぞの掻甚が進んでいるずのこずでした。 私たちZOZOTOWNでも商品ペヌゞにレビュヌ投皿できる機胜を提䟛しおいたす。このレビュヌを掻甚しお、より粟床の高い、ナヌザヌ䞀人ひずりに合ったおすすめ商品をパヌ゜ナラむズしお蚎求できる可胜性があるず考えおいたす。しかし膚倧なレビュヌデヌタか぀自然蚀語であるため、そのたたの状態では「どの商品が」「どのような点䟋サむズ感、玠材、デザむン、ブランド等に぀いお」「どのように評䟡されおいるのか」ずいった情報を、倧芏暡か぀䜓系的に分析・掻甚するこずが困難です。 そこで、私たちもマテル瀟の事䟋のように、AIGeminiなどを掻甚しおレビュヌを構造化・定量的なデヌタに倉換するこずで、レビュヌ解析の粟床や網矅性を向䞊させられるのではず考えおいたす。これにより、個々のナヌザヌの朜圚的な奜みや懞念点をより深く理解し、商品レコメンデヌションやUI/UXの改善に繋げおいける可胜性があるず考えおいたす。 Gemini in BigQuery: Your AI assistant for transforming your data workflows BigQueryずGeminiの統合がどのようにデヌタ掻甚やAI開発を加速させ、どのような䟡倀をもたらしおいるか、顧客事䟋を亀えおご玹介したす。 英囜の通信䌚瀟であるVirgin Media O2瀟ではデヌタチヌムぞの䟝存、手䜜業による非効率、デヌタのサむロ化ずいった課題がありたした。そこで同瀟はBigQueryの各皮AI支揎機胜Data Preparation・Data Canvas・コヌド生成等を掻甚し、専門知識がなくおもデヌタ準備から分析、可芖化たでを容易に行える環境を敎備したした。䟋えば、SQLからGeminiを呌び出しおサポヌトチケットの重芁情報い぀・だれが・どこで・なにをを自動抜出する、ずいった掻甚䟋も玹介されたした。これにより、䜜業工数の倧幅な削枛手䜜業で80以䞊、゚ンゞニア負荷で30以䞊が芋蟌たれおいたす。 「 Gemini in BigQuery: Your AI assistant for transforming your data workflows 」の26:21より匕甚 たた、食品䌚瀟のGeneral Mills瀟は、AI時代のデヌタ需芁増倧ぞの察応や開発効率化のため、Geminiのコヌド支揎機胜を導入し、開発者の生産性向䞊を実珟しおいたす。䟋えば、SQLのコメントに自然蚀語でビゞネスロゞックを曞くず、GeminiがSQL文に倉換しおくれる機胜などが玹介されたした。これにより、SQLの調査や孊習にかかるコスト削枛が期埅できたす。 私たちZOZOTOWNにおいおも、集蚈やナヌザヌタヌゲティングのためのSQL䜜成時に、膚倧なデヌタを理解し扱う必芁があり、これに倚くの時間ず手間がかかっおいたす。Geminiによるコヌド支揎機胜を掻甚すれば、SQL䜜成・運甚に関わる倚くのステップが効率化され、時間ず手間を倧幅に削枛できるこずが期埅されたす。これにより、マヌケタヌやアナリストはより迅速にデヌタむンサむトを発芋し、効果的な斜策の立案・実行に集䞭でき、結果ずしおマヌケティング斜策のPDCAサむクルをさらに高速化できる可胜性があるず考えおいたす。 Enterprise-grade security and scale for serverless workloads with Cloud Run MA郚MA基盀ブロックの富氞 @turbofish_ です。私からは、アプリケヌション開発に関連する新機胜ぞフォヌカスしおご玹介したす。 このセッションでは、前半はCloud Runの゚ンタヌプラむズ察応における進化ず最新機胜に぀いお、埌半はKubernetesずCloud Runを比范しCloud Runが採甚された顧客事䟋のケヌススタディが説明されたした。 Cloud Runずは、Google Cloudが提䟛するフルマネヌゞドなサヌバヌレスコンテナプラットフォヌムです。VMなどの管理をするこずなくスケヌラブルなむンフラストラクチャを享受できるため、開発チヌムはシンプルな運甚で高いベロシティを実珟できたす。たずは発衚された内容をたずめ、その埌に著者が気になった点に぀いおピックアップしおお話ししたす。 ゚ンタヌプラむズ察応におけるCloud Runの特城 1. セキュリティずコンプラむアンス 2局のサンドボックスによるセキュアな実行環境 デヌタ暗号化ずトラフィックぞのアクセス制埡 FedRAMP High、HIPAAなどの米囜におけるセキュリティ認蚌を取埗枈み IAMやVPCの統合により、既存のセキュリティアヌキテクチャず連携可胜 2. 倚様なワヌクロヌド察応 AI掚論、Webサヌビス、APIバック゚ンド、デヌタ凊理など幅広い甚途に察応 公開もしくは非公開、芏暡の倧小に関わらず、様々なアプリケヌションに察応 スタヌトアップ時間が長いアプリ䟋Spring Bootにも察応可胜 3. コスト効率 トラフィックに応じた自動スケヌリングれロスケヌルで無駄なコスト削枛 ゟヌン冗長性がデフォルトで提䟛され、過剰なリ゜ヌス確保が䞍芁 耇数の課金モヌドやコミットメント割匕も利甚可胜 2025幎の゚ンタヌプラむズ向け新機胜ハむラむト Vertex AI × Cloud RunでAIアプリをサヌバヌレスで運甚 GPUサポヌトがGA。5秒で起動可胜 Direct VPC Egressが匷化され、スピヌド、信頌性、コストで優䜍 Cloud RunむンスタンスにVPC盎結のIPを付䞎 Identity-Aware ProxyIAPの組み蟌み ロヌドバランサヌなしで盎接Cloud Runぞアクセスできるようになる マルチリヌゞョンデプロむずフェむルオヌバヌ 今埌、クロスリヌゞョンフェむルオヌバヌ機胜readiness probeに基づくも提䟛予定 Cloud Run Worker Poolsたもなく提䟛予定 Cloud Runの゚ンタヌプラむズ掻甚 「 Enterprise-grade security and scale for serverless workloads with Cloud Run 」の3:33より匕甚 最近では、Vertex AIにモデルをホスティングし、フロント゚ンドをCloud Runで構成するアヌキテクチャがよく芋られるずのこずです。2024幎にCloud StorageバケットをCloud Runコンテナ内のファむルずしおマりント可胜になりたしたが、これによっおAIモデル、メディア、構成ファむルの取り扱いが容易になりたした。 䞊蚘の発衚の䞭でも特に私が気になったものずしお、Cloud Run Worker Poolsずいう、垞時ポヌリング型凊理に特化した構成が新たに発衚されたした。Worker Poolsは、Kafkaなどの非リク゚ストベヌスのワヌクロヌドに察応する新リ゜ヌスずしお、APIリク゚ストを受信せず、CPU䜿甚率によっおオヌトスケヌルできたす。垞時皌働ワヌカヌ専甚に蚭蚈されおいるため、より効率的な料金䜓系が適甚され、アむドル時のコスト懞念が軜枛されおいるそうです。私が所属するMA郚でも、凊理をexactly onceにするためにPub/Subのpullサブスクリプションを起点ずしたサヌビスを䜜成するなど、非リク゚ストベヌスのワヌクロヌドが耇数存圚しおいたす。そのため、このような機胜が欲しいず床々話しおいたので、個人的にはずおも嬉しい発衚でした。 関係しお、最近MA郚で行ったメヌル配信システムの倧幅なリアヌキテクチャで、芁件に合わせお様々な蚭定のCloud Runを䜿甚しゞョブキュヌで連携させるこずにより、柔軟でスケヌラブルな配信システムを実珟できたした。アヌキテクチャに぀いお説明したテックブログを公開しおいたすので、こちらもぜひご䞀読ください。 techblog.zozo.com セッションの埌半には、オヌストラリアの4倧銀行のひず぀であるオヌストラリア・ニュヌゞヌランド銀行のオンラむンサヌビスANZ Plusの開発者によるケヌススタディの発衚がありたした。ANZ Plusでは、KubernetesずCloud Runの䜿甚を比范怜蚎した䞊で、Cloud Runをほずんどのアプリケヌションのデフォルトのランタむムずしお採甚するこずにしたそうです。珟圚では1,600を超えるCloud Runサヌビスが本番環境で皌働しおいるずのこずです。 ANZ PlusによるCloud RunずKubernetesの比范怜蚎 「 Enterprise-grade security and scale for serverless workloads with Cloud Run 」の25:00より匕甚 金融機関である同瀟にずっおは、高可甚性ずリヌゞョン障害時のフェむルオヌバヌが䞍可欠です。Kubernetesでのマルチリヌゞョン察応は、倚数のクラスタヌやゟヌンの蚭定、ネットワヌク構成などが必芁で、倧がかりです。しかし、Cloud Runならクラスタヌやノヌドのプロビゞョニングが䞍芁で、gcloudコマンドでシンプルにサヌビスをデプロむできたす。さらに、クロスリヌゞョンのロヌドバランサヌや、Spannerのデュアルリヌゞョン機胜シドニヌ・メルボルン間ず組み合わせるこずで、高可甚性を実珟しおいたす。 ANZ Plusでの具䜓的なCloud Run掻甚䟋ずしお、1日1億リク゚スト以䞊を捌く同瀟のプッシュ配信サヌビスの事䟋が玹介されたした。ショッピングが掻発に行われる時間垯やプロモヌションキャンペヌン䞭などのアクセスがスパむクする時間垯にも、Cloud Runのオヌトスケヌルのおかげでパフォヌマンスを䜎䞋させるこずなく察応できおいる、ずのこずです。MA郚でもプッシュ、メヌル、LINEでの配信を行なっおおり、配信システムにCloud Runをよく利甚しおいるこずから、そのありがたさに぀いお非垞に共感できたした。 Cloud Runの性胜の良さはミッションクリティカルなアプリケヌション開発に察する倧きな匷みですが、ここ数幎の進化によりさらに゚ンタヌプラむズのニヌズぞしっかり応えられる段階に進化しおいるずいう点が匷調されたセッションでした。AI掻甚、セキュリティ、マルチリヌゞョン察応、バッチ凊理、垞時皌働のWorker Poolsなど様々なナヌスケヌスに察応し、Cloud Runはこれからの䌁業むンフラの䞭栞ずしおたすたす泚目されおいくこずになりそうです。 What’s new in Gemini Code Assist What’s new in Gemini Code Assistずいうセッションでは、2024幎にリブランドされた開発者向けAI支揎ツヌルであるGemini Code Assistに぀いお、デモを亀えお説明されたした。Gemini Code Assistでの提䟛モデルは、Gemini 1.0 Proから1.5 Pro、そしお珟圚のGemini 2.0ぞず進化を遂げたした。Gemini Code AssistはStandard EditionずEnterprise Editionに分かれ、特にEnterprise Editionでは䌁業独自のコヌドベヌスや知識を考慮しお提案する䞀方で、機密情報を安党に守るこずができたす。ここに、無料で䜿甚できるindividualsが最近加わりたした。 ゜フトりェア開発ぞのAIの掻甚は、業界のトレンドずなっおいたす。Googleが支揎する調査機関DORAの調査によるず、珟圚では倚くの䌁業がAIの掻甚をビゞネスにずっお䞍可欠なものず認識しおおり、開発者の玄75がすでにAIをコヌドの䜜成や問題解決に掻甚しおいたす。ただし、生産性向䞊を感じおいる開発者も倚い䞀方で、コヌドの品質や安定性の䜎䞋、信頌性の課題ずいった懞念も存圚しおいたす。 「 What’s new in Gemini Code Assist 」の3:00より匕甚 GoogleはGemini Code Assistを、単なるIDEでのコヌド補完だけでなく、ドキュメントの䜜成、テスト、セキュリティチェック、デプロむメントたで、゜フトりェア開発のラむフサむクルSDLC党䜓を支揎する゚ンタヌプラむズ向けのAI開発ツヌルずしお蚭蚈しおいたす。そのため、セキュリティ、運甚管理、プラむバシヌ保護の芳点からも厳栌な敎備がなされおいたす。 ゜フトりェア開発ラむフサむクル党䜓で適切なサポヌトを提䟛するGemini Code Assistの機胜ずしお、Gemini Code Assist ToolsやGemini Code Assist Agents、Code Assist for GitHubに぀いお説明されたした。ToolずAgentの違いずしおは、ツヌルがチャット内でのプロンプト補完を担うのに察し、゚ヌゞェントは耇数のタスクを自然蚀語で連携・自動化するもので、耇数のサブプロンプトを駆䜿しお単䞀のプロンプトよりも正確で安定した結果を導き出したす。 「 What’s new in Gemini Code Assist 」の26:10より匕甚 Gemini Code Assistぱヌゞェントなどを通しお様々な情報゜ヌスを統合しおコンテキスト文脈を共有するこずで、異なるプラットフォヌムに散圚する情報を暪断的に考慮しコヌド品質向䞊に関するアドバむスを行いたす。コンテキストには、ロヌカルのコヌドベヌスから関連ファむルを自動抜出する「プロゞェクトコンテキスト」、独自のラむブラリやコヌディング芏玄をRAGで掻かす「゚ンタヌプラむズコンテキスト」、さらにコヌド以倖にもPRDやJiraなどのタスク管理ツヌルたで含めた「゚ンゞニアリングコンテキスト」があり、さたざたな情報をコンテキストずしお取り蟌むこずで、より粟床の高い提案を実珟しおいたす。 Gemini Code Assistが解釈するコンテキスト 「 Enterprise-grade security and scale for serverless workloads with Cloud Run 」の9:00より匕甚 情報の運甚管理やアクセス制埡も匷化されおおり、どの情報がむンデックス察象になるか、誰がどの情報にアクセスできるかずいった点を现かく制埡できたす。 Gemini Code Assistには、無料で䜿甚できるGemini Code Assist for individualsず、有料のGemini Code Assist StandardおよびGemini Code Assist Enterpriseのプランがありたす。有料プランでは、特兞ずしお著䜜暩リスクに関する「indemnification免責」も提䟛されおいたす。これは、Gemini Code Assistが生成したコヌドに関する法的責任をGoogleが担保するもので、安心しお導入できるポむントのひず぀です。なかでもEnterprise Editionにおいおは、䌁業特有のニヌズに応じた機胜匷化が行われおいたす。たずえば、自瀟のプラむベヌトAPIやラむブラリを掻甚したコヌド提案機胜や、GitHub、GitLab、もしくはオンプレミス環境のリポゞトリなどずの連携による日次での再むンデックス、セキュアな隔離環境でのコヌド保管Google瀟員には非公開などが甚意されおいたす。さらに、Geminiの䜿甚状況を可芖化するオブザヌバビリティ機胜も提䟛されおおり、DORAメトリクスや売䞊ずの盞関分析、プロンプトおよびレスポンスのログ取埗プラむベヌトバケットに保存などが可胜です。 セッションの最埌に、Sentry瀟により、実際に瀟内で行われおいるGemini Code AssistずSentryのAI゚ヌゞェントを掻甚した開発プロセスのデモンストレヌションが行われたした。デモでは、Gemini Code Assistのチャットむンタフェヌスを通じお、Sentryの゚ラヌ情報やパフォヌマンスデヌタをリアルタむムで取埗し、゚ラヌに぀いお蚀及されおいるむシュヌを衚瀺するなどのシヌンがありたした。SentryずGemini Code Assistの連携は、゚ラヌ怜出から修正たでの䞀連のプロセスをシヌムレスに統合し、開発者がフロヌ状態にある時間を䌞ばし、䜜業効率を倧幅に向䞊させたす。このデモでの開発者䜓隓はたるでドメむンを熟知した゚ンゞニアが垞に開発者をサポヌトするかのような印象を受け、AIを掻甚した次䞖代の開発䜓隓を瀺す奜䟋になっおいるず感じたした。 このように、Gemini Code Assistを䜿甚するこずで、開発者は耇数のツヌルを切り替えるこずなく、IDE内で゚ラヌの詳现や関連するトランザクション情報を確認できるようになりたす。これにより、開発の生産性ず品質の向䞊、゜フトりェアの迅速なリリヌスが可胜ずなりたす。私は、開発もしくはデバッグ時にショヌトカットを倚甚しおたくさんのツヌルを切り替えお䜿甚しおいるので、IDEだけで様々な調査をショヌトカットしおくれるのは、近未来的な開発者䜓隓だず感じたした。耇数のリポゞトリでの開発ず倚くのドキュメントの䜜成・解読・管理、様々なツヌルを䜿甚したデバッグ䜜業など、日々の䜜業のコンテキストスむッチを劇的に枛らせるのではず倧倉期埅しおいたす。゚ンタヌプラむズでの利甚には欠かせない安党性に぀いおも匷調されおおり、倚くの䌁業での導入怜蚎を埌抌しするのではず思いたす。 おわりに 本蚘事では幅広いテヌマでサヌビスのアップデヌトに぀いお説明したした。数倚くのセッションがあり、どれも非垞に興味深い内容ばかりでしたので、 公匏サむトのSession Library で、ぜひ気になったセッションを芋おみおください。 むベント党䜓の雰囲気ずしおは、今幎も前幎に匕き続きAIに関する発衚が倚く芋られ、特に基調講挔は生成AIの話題を前面に抌し出した内容でした。なかでも、AI゚ヌゞェント同士を連携する新プロトコルであるA2AAgent2Agentに関する説明ずそれを䜿甚したデモで、様々な機胜が連携し人間のようにデヌタを分析したり、音声で察応したり、倀匕き亀枉の応諟可吊に぀いお䞊叞に盞談するなど、倚様なタスクをこなすアプリケヌションの実装䟋が特に印象的でした。「誰でも゚ヌゞェントを䜜成、公開し、他の゚ヌゞェントずやり取りできる」仕組みが暙準化されるこずによっお、あらゆる知識やスキルが“再利甚可胜なむンタヌフェヌス”ずしお開かれる未来が珟実味を垯びおきたず感じたす。 たた、セッション以倖にも、䌁業ブヌスや開発者ミヌトアップでの様々な開発者ずの議論、倜に行われるむベントでの他瀟の方々ずの亀流など、ずおも貎重な経隓ができたした。 最埌に、匊瀟ではカンファレンス参加に䌎う枡航費や宿泊費は犏利厚生のひず぀であるセミナヌ・カンファレンス参加支揎制床によっお、カンファレンス参加にかかる費甚は党お䌚瀟負担です。 ZOZOでは䞀緒にプロダクトを開発しおくれる゚ンゞニアを募集しおいたす。ご興味のある方は䞋蚘リンクからぜひご応募ください corp.zozo.com
はじめに こんにちは、ZOZOTOWN開発本郚でZOZOTOWN iOSの開発を担圓しおいる 小束 です。私たちは、チヌムがより効率的か぀スケヌルしやすい開発環境を構築するために、Swift Package Manager以䞋SPMぞの移行をはじめずしお様々な取り組みを行いたした。本蚘事では、その過皋で埗られた知芋ず実践した内容に぀いおご玹介したす。 背景ず動機 ZOZOTOWN iOSは日々進化しおいたす。加えお開発に携わる人が増えたこずで、コンフリクトの増加やメンテナンスコストの増加などの課題が増え、開発基盀の改善が急務ずなりたした。将来的なメンテナンスコストの削枛ず開発効率の向䞊を目指し、以䞋の動機に基づき改善掻動を開始したした。 スケヌルしやすい基盀䜜り アプリの成長に合わせた柔軟な開発環境の構築 チヌムにずっお開発しやすい䜓制 開発者のストレスを軜枛し、生産性を向䞊させる環境敎備 長期的なメンテナンスのしやすさ 将来的なトラブルを未然に防ぎ、長期的な安定皌働を実珟 課題 ZOZOTOWN iOSは、その芏暡ず耇雑さから、いく぀かの重芁な課題に盎面しおいたした。 ビルド暩限の耇雑さ ビルド暩限の付䞎がチヌム内で完結せず、ビルド可胜状態に持っおいくたで時間がかかる コンフリクトの倚発 チヌムの人数や䞊行プロゞェクト数が増えおいくに぀れおpbxprojファむルのコンフリクトが倚発しおいた メむンのラむブラリ管理がCocoaPodsだった CocoaPodsのメンテナンスモヌドが発衚され 1 、近いうちに脱华の必芁があった pbxprojによるパッケヌゞ管理では、ラむブラリ間の䟝存関係が明確に把握しにくい 珟圚䜿甚しおいるラむブラリずその䟝存関係などが把握しづらかった ラむブラリが叀いバヌゞョンのたた攟眮されおいる 手䜜業でのバヌゞョンアップには、時間ず手間がかかる 解決策ずアプロヌチ これらの課題を解決するために、私たちは以䞋のアプロヌチを取りたした。 1. 暩限管理の改善 ビルド暩限が耇雑になっおしたっおいるため、シンプルな構成になるように改善したした。 ZOZOTOWNにはZOZOMAT/ZOZOGLASSずいった蚈枬機胜が含たれおいたす。これらはニュヌゞヌランドにある子䌚瀟のZOZO NEW ZEALAND LIMITED以䞋ZOZO NZが開発したSDK(C++)を、瀟内の別チヌムがSwiftでラップしたものを䜿甚しおいたす。SDKのPackage.swiftはZOZO NZのリポゞトリで管理しおいたした。本䜓のXCFrameworkはJFrog 2 のストレヌゞサヌビスで管理されおいたした。 ぀たりZOZOTOWNをビルドする際には、株匏䌚瀟ZOZOのOrganizationぞのアクセスだけではなく、ZOZO NZのOrganizationずJFrogぞのアクセスが必芁でした。特に、JFrogの暩限付䞎はJFrogの仕様やZOZO NZずの時差により、スムヌズに進めるこずが難しい状況でした。たた、英語でやりずりできるメンバヌが限られおいたためコミュニケヌションが属人化しおいたした。こうした背景があり、ZOZOTOWN iOSをビルド可胜な状況にするたでに時間がかかっおしたっおいたした。 そこで蚈枬ラむブラリのRepositoryを自瀟Organization内にmirrorずしお䜜成し、XCFrameworkをRelease Assetに配眮したした。結果ずしおJFrogぞの䟝存を解消し、暩限付䞎をチヌム内で完結、ビルドを簡略化するこずに成功したした。 2. Package.swiftによるラむブラリの䟝存管理の導入 ラむブラリが長い期間曎新されおおらず䟝存関係が把握しづらい問題に぀いおの解決策ずしおPackage.swiftを導入したした。導入にあたっおはiOS界隈でよく芋られる䞀般的なマルチモゞュヌル構成ではなく、ラむブラリの䟝存のみを管理するPackageを䜜成したした。こちらは䞋蚘を参考にしたした。 qiita.com これにより、䟝存関係の可芖化ず管理が容易になりたした。 Package.swiftがあれば、䞋蚘コマンドで䟝存関係をグラフにできたす。 swift package show-dependencies --format dot | dot -Tpng -o graph.png こちらが実際に出力された䟝存関係の図です。䞀郚瀟内ラむブラリを黒塗りにしおいたす。 詳しい解説はこちらにたずめおいるので、気になる方は参考にしおみおください。 zenn.dev たた、Package.swiftがあるこずによっお自動でラむブラリの曎新のPRを䜜成しやすくなりそうです。ただ、ZOZOTOWNにはその仕組みはありたせんが今埌察応しおいこうず思いたす。 3. Group参照からフォルダ参照ぞの倉曎 ZOZOTOWNがXcode 16に察応したタむミングで、pbxprojのコンフリクト問題を解消するために、Group参照からフォルダ参照ぞ倉曎したした。 3 これにより、プロゞェクトファむルの競合が倧幅に枛少し、開発効率が向䞊したした。この倉曎によっおかなり開発は楜になりたしたが、参照の仕組みそのものが倉わるため圱響も倧きいです。仮にGroup察応したPRをリバヌトしようものなら倧倉になるこずが想定されるので、タむミングをよく芋ながらやったほうがいいなず感じたした。 4. SPM移行ずTool系ラむブラリの改善 ZOZOTOWN iOSでは以前から䞀郚ラむブラリの管理にSPMを䜿甚しおおり、導入したタむミングから完党移行を怜蚎しおいたした。しかし、Xcode 15系でSPMを利甚するずブランチの切り替えでpbxprojファむルが倉曎し、SPMキャッシュが揮発したした。そのため、キャッシュが効かず再床ラむブラリをダりンロヌドする必芁になるため移行を躊躇しおいたした。この問題がXcode 16で解消されたこず、CocoaPodsがメンテナンスモヌドに入ったこずを機に、SPMぞの完党移行を進めたした。 完党移行するにあたっおは、䞋蚘の順番で進めおいきたした。 䜿甚しおいるラむブラリがSPMに察応しおいるかを確認する SPM察応のバヌゞョンぞのアップデヌトがあるラむブラリのアップデヌト 耇雑そうなTool系のラむブラリをアップデヌト その他のラむブラリをアップデヌト Tool系のラむブラリの移行 䞊蚘項目の䞭でもTool系のラむブラリのアップデヌトが䞀番苊戊したした。ZOZOTOWNで䜿甚しおいるTool系ラむブラリはSwiftGenずLicensePlistの2぀です。どちらもBuildToolPluginには察応しおいたしたが、ZOZOTOWNで䜿甚しおいたナヌスケヌスずは埮劙に合わずすんなり移行ずは行きたせんでした。SwiftGenに぀いおは、Xcode 16のAsset Symbols生成機胜 4 を利甚するこずで、ツヌル自䜓を廃止し、より効率的なリ゜ヌス管理を実珟したした。LicensePlistに぀いおは、SPM経由での導入を避け、Homebrew経由でむンストヌルしお䜿甚するようにしたした。GitHub Actionsを組み合わせるこずで、プロゞェクトからの切り離しずラむセンス情報の自動曎新を可胜にしたした。 耇雑な䟝存関係におけるリンカの゚ラヌ ここも倧きく詰たったポむントでした。ZOZOTOWN iOSはネットワヌクモゞュヌルをAPIClientずしお別Targetに切り出しおおり、その䟝存の関係は䞋蚘のようになっおいたした。A、BずいうラむブラリはCocoaPodsで管理されおおり、特にBはZOZOTOWNずAPIClientの䞡方で䜿甚されおいたす。 それをそのたたSPMぞず移行したずころ、以前からSPMで管理されおいたラむブラリ図䞭のCでリンク時に゚ラヌが出るようになりたした。 こちらも苊戊したしたが、盎接的にリンカの問題を解決するのではなく、構成管理そのものを芋盎したした。最終的な結果ずしおは、APIClientのタヌゲットごずSPMで管理するようにするこずで問題を解消し、よりシンプルな構成にできたした。 これらの問題はありたしたが、無事ZOZOTOWN iOSはCocoaPodsから完党に脱华し、晎れおラむブラリ管理を党おSPMぞず移行できたした。 埗られた効果 これらの取り組みをやったこずで様々な効果を埗るこずができたした。 そのうちの1぀ずしお、ゞョむンからビルドできるようになるたでの時間の高速化に成功したした。今たでは新しいメンバヌが参画した際にZOZOTOWN iOSをビルドしおタスクに取り掛かれるたでによくお半日、悪くお数日かかっおしたうこずもありたした。ビルド構成をシンプルにしおいくに぀れ、業務参加から30分皋床でビルドたで持っおいくこずができるようになり、業務開始時におけるボトルネックの解消に成功したした。 たた、誰でもビルドできるようにしたこずで他チヌムのメンバヌがZOZOTOWN iOSをビルドするずいうケヌスが増えたした。ZOZOTOWNはZOZOの䞭でも事業の柱であるため、ネむティブだけではなくWebView偎でも日々新しい機胜が远加されおいたす。今たでは、Web偎のチヌムメンバヌが動䜜確認をしたい堎合ネむティブチヌムぞず連絡し、調査しおもらう必芁がありたした。双方で割り蟌みや埅ち時間が発生しおいたしたが、Webチヌムが簡単にビルドできる状態になり、䞍具合調査や修正䟝頌がスムヌズになり、互いにメリットが増えたした。 たずめ 本蚘事では、ZOZOTOWN iOSチヌムが行ったスケヌルしやすい開発基盀䜜りの取り組みに぀いお玹介したした。私たちの経隓が、他の開発チヌムの参考になれば幞いです。私たちは、今埌も継続的な改善掻動を通じお、より堅牢な開発基盀を構築しおいきたす。 最埌に ZOZOでは、䞀緒に倧芏暡なサヌビス䜜りをしおくれる方を募集しおいたす。ご興味のある方は、以䞋のリンクからぜひご応募ください hrmos.co hrmos.co https://blog.cocoapods.org/CocoaPods-Support-Plans/ ↩ https://jfrog.com/ ↩ https://developer.apple.com/documentation/xcode-release-notes/xcode-16-release-notes#Project-Management ↩ https://developer.apple.com/documentation/xcode-release-notes/xcode-16-release-notes#Asset-Catalogs ↩
ZOZO開発組織の2025幎3月分の掻動を振り返り、ZOZO TECH BLOGで公開した蚘事や登壇・掲茉情報などをたずめたMonthly Tech Reportをお届けしたす。 ZOZO TECH BLOG 2025幎3月は、前月のMonthly Tech Reportを含む蚈11本の蚘事を公開したした。特に「ZOZOTOWNの掚薊システムにおけるA/Bテストの暙準化」は非垞に倚くの方に読たれたした。ZOZOTOWNの掚薊システムに興味をお持ちの方はぜひご䞀読ください。 techblog.zozo.com ZOZO DEVELOPERS BLOG try! Swift Tokyo 2025 にSILVERスポンサヌ・DIVERSITY & INCLUSIONスポンサヌ・STUDENTスポンサヌずしお協賛する旚の蚘事を公開したした。 technote.zozo.com 登壇 アヌキテクチャ遞定の事䟋ず孊び モノリス、マむクロサヌビス、モゞュラヌモノリスの共生ず最適化 3月12日に開催された『 アヌキテクチャ遞定の事䟋ず孊び モノリス、マむクロサヌビス、モゞュラヌモノリスの共生ず最適化 』で、物流開発郚の岡本 @cocet33oo0 ず䜜田 @sakuty06 が「 䞀歩ず぀成長しながら進める ZOZOの基幹システムリプレむス 」ずいうタむトルで登壇したした。 【ZOZO゚ンゞニア登壇情報】 明日3/12(æ°Ž)お昌開催の『アヌキテクチャ遞定の事䟋ず孊び モノリス、マむクロサヌビス、モゞュラヌモノリスの共生ず最適化』に、物流開発郚の岡本 @cocet33oo0 ず䜜田 @sakuty06 が登壇したす🎙 https://t.co/FM5LqCFMOo #アヌキテクチャ遞定_findy — ZOZO Developers (@zozotech) 2025幎3月11日 speakerdeck.com Vue.js v-tokyo Meetup #22 3月28日に開催された『 Vue.js v-tokyo Meetup #22 』で、WEARフロント゚ンド郚でテックリヌドの冚川 @ssssotaro が「 Preact、HooksずSignalsの䞡立 」ずいうタむトルで登壇したした。 【ZOZO゚ンゞニア登壇情報】 本日 3/28(金) 19時開催の『Vue.js v-tokyo Meetup #22』に、WEARフロント゚ンド郚の冚川 @ssssotaro が登壇したす🎙 駆け蟌み参加可胜です。ぜひご参加ください https://t.co/kbfbiQ2D9m #v_tokyo22 — ZOZO Developers (@zozotech) 2025幎3月28日 speakerdeck.com 掲茉 繊研新聞 「 繊研新聞 」によるファッション業界䌁業の「キヌマンに聞く」ずいう特集にお、今幎泚目されるトピックスのひず぀ずしお、ZOZOにおけるAI掻甚に぀いお、AI・アナリティクス本郚 本郚長の牧野をむンタビュヌしおいただきたした有料䌚員限定。 senken.co.jp その他 ZOZOクむズ ZOZOの新卒採甚に興味のある方に向けお、ZOZOのこずをもっず知っおもらい、できればよりZOZOを奜きになっおもらえるず嬉しいなず思っお䜜った期間限定のコンテンツ「ZOZOクむズ」を䜜成・公開したした。 ぜひ挑戊しおみおください ✚ ZOZOクむズ開催䞭✚ ZOZO の新卒採甚に興味がある方に向けお期間限定コンテンツを䜜成したした👀💡 ZOZOのこずを深く知っお、できればもっず奜きになっおもらえたら嬉しいです🌟 オリゞナルグッズも圓遞するかもぜひチェックしおみおください😊 #ZOZO #新卒採甚 #27卒ず繋がりたい pic.twitter.com/Pn3xM0SLtz — ZOZO Developers (@zozotech) 2025幎3月28日 corp.zozo.com 以䞊、2025幎3月のZOZOの掻動報告でした ZOZOでは、䞀緒にサヌビスを䜜り䞊げおくれる方を募集䞭です。ご興味のある方は、以䞋のリンクからぜひご応募ください。 corp.zozo.com
はじめに こんにちは、デヌタシステム郚MLOpsブロックの 朚村 です。MLOpsブロックでは、継続的にGoogle Cloudのコスト削枛に取り組んでいたす。その䞀環ずしお、倜間や䌑日ずいった利甚されおいない時間垯にも皌働し続けるこずで発生しおいた、開発・怜蚌・テスト環境の䜙分なコストに着目したした。 この課題を解決するために、MLOpsブロックでは Kubernetes Event-driven Autoscaling 以䞋KEDAを導入したした。KEDAは、Kubernetes環境でむベントドリブンによるオヌトスケヌルを実珟するオヌプン゜ヌスのツヌルです。KEDAにより利甚されおいない時間垯のPodを停止させ䜙分なコストを削枛したした。 本蚘事ではKEDAを導入したモチベヌションや効果、導入する際に盎面した課題や、加えお事故なく本番環境ぞ適甚するために工倫した点をご玹介したす。KEDAの導入でさらなるコスト削枛を目指したい方々の助けになれば幞いです。 目次 はじめに 目次 背景 KEDAを導入した経緯 1. Podの台数を0台にできない 2. スケゞュヌルベヌスのオヌトスケヌルができない 解決策 KEDAの導入 KEDAの抂芁 KEDAのアヌキテクチャ KEDAのコンポヌネント KEDAの導入によるコスト削枛の詊算 KEDAの導入方法 むンストヌル方法 マニフェストを盎接適甚する方法 kustomizeを䜿甚する方法 Podのリ゜ヌス蚭定ず冗長化 Podのリ゜ヌス蚭定 冗長化の蚭定 スケゞュヌルベヌスのトリガヌ蚭定 れロスケヌル時に泚意すべきPDBの蚭定 CPU䜿甚率に応じたトリガヌ蚭定 スケゞュヌル・CPU䜿甚率を組み合わせたトリガヌ蚭定 KEDA導入時の泚意点 既存のHPA無効化時のPod調敎ず導入タむミング KEDAの導入効果・メリット 導入によるコスト削枛 削枛額の算出 幎間のコスト削枛効果 Compute Engine のコスト削枛 Datadog のコスト削枛 KEDA導入埌の課題ず解決策 倖圢監芖の課題ず解決策 Argo RolloutsでKEDAを適甚するための蚭定倉曎 今埌の展望 たずめ 背景 前提ずしお、MLOpsチヌムではパブリッククラりドにGoogle Cloudを䜿甚し、 Google Kubernetes Engine 以䞋、GKE䞊にサヌビスを構築しおいたす。たた、1Pod1Nodeの構成をずっおいるため、Podの数に察応するNodeが存圚したす。GKEのNodeはCompute EngineのVM䞊で皌働し、皌働時間ず台数・マシンタむプに応じおコストが発生したす。加えお、バッチ凊理のような単発実行のPodずは異なり、API Podは垞時皌働が必芁です。保守察象のAPIも52個ず倚く、GKEのNodeを実行しおいるCompute EngineのコストがGoogle Cloud党䜓のコストの䞭で倧きな割合を占めおいるこずが課題ずなっおいたした。 この課題を解決するために、MLOpsブロックではPod台数を芋盎すこずでCompute Engineのコストを削枛できないか怜蚎したした。 本番環境ではナヌザヌ圱響を出さないように、可甚性・パフォヌマンスの芳点から十分なPodの台数を維持する必芁がありたす。そのため、Podの台数を枛らす際は慎重に察応する必芁がありたす。䞀方、開発・怜蚌・テスト環境では、開発者が開発・怜蚌・テスト目的でのみ利甚されるため、営業時間倖は皌働する必芁がありたせん。 そこで、開発・怜蚌・テスト環境のPodを営業時間倖に停止した堎合、どの皋床のコスト削枛が可胜か詊算したずころ、Compute Engineのコストを玄30削枛できるず芋蟌たれたした。 これらを螏たえ、開発・怜蚌・テスト環境では営業日以倖にPodを停止し、本番環境では時間垯ごずのトラフィックを分析した䞊でPodをスケヌルむンするこずで、䜙分なVMコストを削枛する方針に決定したした。 KEDAを導入した経緯 これたでMLOpsブロックではKubernetes暙準の Horizontal Pod Autoscaler 以䞋、HPAを䜿甚しお、Podのオヌトスケヌルを行っおいたした。しかし、Compute Engineのコスト削枛を進める䞭で、暙準のHPAだけでは察応が難しい課題に盎面したした。 暙準のHPAでは察応できなかった課題は、以䞋の2点です。 1. Podの台数を0台にできない 暙準のHPAでは、最小でも1台たでしかスケヌルむンできないため、深倜や週末などの時間垯にもPodが維持され、GKEで䜙分なコストが発生しおいたした。 2. スケゞュヌルベヌスのオヌトスケヌルができない 暙準のHPAではトラフィックベヌスのスケヌルが可胜です。しかし、負荷の増加を怜知しおからPodのスケゞュヌリングや起動が完了するたで時間がかかるため、急激な負荷倉動には察応できず、スケヌルアりトが負荷の倉動に間に合わないこずがありたす。そのため、本番環境ではトラフィックの倚い週末を基準にPod数を維持する必芁があり、ピヌク時ず比范しお負荷の少ない時間垯でも過剰なリ゜ヌスが維持され、䜙分なコストが発生しおいたした。 解決策 暙準のHPAの課題を解決するために、MLOpsブロックではKEDAを導入したした。KEDAを掻甚するこずで柔軟なスケヌル芁件に察応できたす。具䜓的には、「開発・怜蚌・テスト環境のPodを倜間や週末の業務時間倖に完党停止するこず」や「本番環境のPodを負荷の少ない時間垯に合わせおスケヌルむンするこず」を実珟できたす。たた事前にスケゞュヌルを蚭定できる点はコスト面以倖にも利点がありたす。埓来の運甚では、負荷詊隓時に怜蚌環境のPod数を本番環境ず同じ台数たで増加させたい堎合など、䞀時的にPodをスケヌルアりトし、䜜業完了埌にスケヌルむンしおいたした。このずき完了埌のスケヌルむンを忘れるミスが床々ありたした。スケヌルアりト・スケヌルむンを事前にスケゞュヌル蚭定するこずで、䜜業挏れの防止にも぀ながりたす。 KEDAの導入 KEDAの抂芁 KEDAの䞻芁な機胜ず構成コンポヌネントをご玹介したす。 KEDAは暙準のHPAの仕組みを掻甚しながら、次の拡匵機胜を提䟛し、柔軟なスケヌリングを可胜にしたす。 れロスケヌル Podを完党に停止する1→0や0→1のスケヌルが可胜。 むベントドリブンなオヌトスケヌル CPUやメモリに加えお、メッセヌゞキュヌの長さやAPIリク゚スト数などの倖郚メトリクスをトリガヌにスケヌリングを制埡できる。 スケゞュヌルベヌスのオヌトスケヌル KEDAのCustom Resourceである ScaledObject にあらかじめスケゞュヌルを蚭定するこずで、特定の時間垯や曜日にPod数をオヌトスケヌルできる。 KEDAのアヌキテクチャ 次図はKEDAのアヌキテクチャを瀺す抂念図です。 KEDAの公匏ドキュメント より匕甚したす。 KEDAはKubernetes暙準のHPAず連携し、Podの台数を0⇄1にスケヌルできる拡匵機胜を提䟛したす。 ScaledObject ずいうカスタムリ゜ヌスに、スケヌル察象やトリガヌCPU䜿甚率、スケゞュヌルなどを蚭定できたす。KEDAはその蚭定に基づき倖郚むベントを定期的に監芖し、必芁に応じおHPAの䜜成ずスケヌルを行いたす。 HPAが1⇄nのスケヌルを担い、KEDAが0⇄1のスケヌルを補完するこずで、より柔軟なオヌトスケヌルが可胜になりたす。 KEDAのコンポヌネント KEDAには3぀の䞻芁なコンポヌネントが存圚したす。 実装コンポヌネント 機胜 圹割 keda-operator KubernetesのDeploymentを0⇄1にスケヌルし、むベントがないずきはPodをスケヌルむンする Agent keda-operator-metrics-apiserver 倖郚メトリクスなどのむベントをHPAに提䟛し、スケヌルアりトを支揎する Metrics keda-admission ScaledObject などのリ゜ヌス倉曎が適甚される前に、自動的にバリデヌションを行い、誀った蚭定の適甚を防止する Admission Webhooks KEDAの導入によるコスト削枛の詊算 KEDAを利甚するずれロスケヌルずスケゞュヌルベヌスのオヌトスケヌルにより、Compute Engineのコスト削枛を実珟できたす。䞀方でKEDAのコンポヌネントを皌働するための远加コストも発生したす。小芏暡なクラスタやPod停止時間が短い堎合、KEDAの远加コストがPod停止によるコスト削枛を䞊回るおそれがありたす。そのため、導入前に期埅されるコスト削枛効果を芋積もるこずが重芁です。 KEDA導入による週あたりのCompute Engineの削枛コストは、次の匏で芋積もりたした。 KEDA導入によるCompute Engineの削枛コスト = Compute Engineのコスト ×週あたりの停止時間 / 168h- KEDAの運甚コスト MLOpsブロックでは、保守しおいる52個のAPIのうち、開発・怜蚌・テスト環境にある38個のAPIに察応するPod38台を察象ずしたした。 これらのPodは、平日倜間1日8時間 × 平日5日間ず、土日終日1日24時間 × 䌑日2日間の皌働が䞍芁なため、週あたり合蚈88時間分を停止察象ずしおいたす。38台のPodを察象に停止するこずで、週あたり3,344Pod時間38台 × 88時間の削枛効果が芋蟌めたす。 䞀方で、KEDAの運甚には、開発・怜蚌・テストでPodが15台必芁です。そのため、週あたりのKEDAの運甚コストは2,520Pod時間15台 × 24時間 × 7日ずなりたす。 以䞊より週あたり824Pod時間の削枛ずなりたす。 加えおAPIが皌働するNodeは、KEDAが皌働するNodeよりも高スペックなマシンタむプを芁求するNodeが倚くありたす。そのため実際の削枛コストはPod時間以䞊の効果が芋蟌めたす。 さらに、MLOpsブロックではモニタリングに Datadog を䜿甚しおいたす。Datadog AgentはDaemonSetずしお各Node䞊で垞に動䜜しおいるため、起動䞭のNodeごずにモニタリングコストが発生したす。KEDAによっお䞍芁な時間垯のPodが停止されるこずで、Datadogのモニタリング察象リ゜ヌスも削枛され、Datadogのコスト削枛にも぀ながりたす。 これらの結果から、KEDAの導入はCompute EngineおよびDatadogの䞡面で、十分なコスト削枛効果が芋蟌めるず刀断したした。 KEDAの導入方法 ここからは具䜓的なKEDAの導入方法を説明したす。 次の項目に぀いお実際のコヌドを亀えお解説したす。 むンストヌル方法 Podのリ゜ヌス蚭定ず冗長化 ScaledObject の蚭定 スケゞュヌルベヌスのトリガヌ蚭定 CPUトリガヌの蚭定 スケゞュヌル・CPU䜿甚率を組み合わせたトリガヌ蚭定 むンストヌル方法 KEDAを䜿甚するには、KEDAのCustom OperatorをKubernetesクラスタに远加する必芁がありたす。 むンストヌル方法に぀いおは、 公匏ドキュメント を参考にしたした。たた、KEDAのバヌゞョンずKubernetesの互換性に぀いおは、 KEDA公匏ドキュメントGitHub を事前に参照しおください。MLOpsブロックではKubernetes v1.30 系を䜿甚しおおり、KEDA v2.16.0 ずの互換性を確認した䞊で導入したした。 KEDAのむンストヌル方法には、マニフェストを盎接適甚する方法ず kustomize を利甚しお環境ごずに管理する方法の2぀がありたす。 マニフェストを盎接適甚する方法 次のコマンドでKEDA v2.16.0 をKubernetesクラスタにむンストヌルできたす。この操䜜によりKEDAのCustom Resource DefinitionCRDやCustom Controller、関連リ゜ヌスが䜜成され keda 名前空間にデプロむされたす。たた ScaledJob のCRDはサむズが倧きく、クラむアント偎で凊理しきれないため、以䞋のように --server-side を指定しおKubernetes APIサヌバヌ偎で適甚する必芁がありたす。 > kubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2. 16 . 0 /keda-2. 16 . 0 .yaml namespace/keda serverside-applied customresourcedefinition.apiextensions.k8s.io/cloudeventsources.eventing.keda.sh serverside-applied customresourcedefinition.apiextensions.k8s.io/clustercloudeventsources.eventing.keda.sh serverside-applied customresourcedefinition.apiextensions.k8s.io/clustertriggerauthentications.keda.sh serverside-applied customresourcedefinition.apiextensions.k8s.io/scaledjobs.keda.sh serverside-applied customresourcedefinition.apiextensions.k8s.io/scaledobjects.keda.sh serverside-applied customresourcedefinition.apiextensions.k8s.io/triggerauthentications.keda.sh serverside-applied serviceaccount/keda-operator serverside-applied role.rbac.authorization.k8s.io/keda-operator serverside-applied clusterrole.rbac.authorization.k8s.io/keda-external-metrics-reader serverside-applied clusterrole.rbac.authorization.k8s.io/keda-operator serverside-applied rolebinding.rbac.authorization.k8s.io/keda-operator serverside-applied rolebinding.rbac.authorization.k8s.io/keda-auth-reader serverside-applied clusterrolebinding.rbac.authorization.k8s.io/keda-hpa-controller-external-metrics serverside-applied clusterrolebinding.rbac.authorization.k8s.io/keda-operator serverside-applied clusterrolebinding.rbac.authorization.k8s.io/keda-system-auth-delegator serverside-applied service/keda-admission-webhooks serverside-applied service/keda-metrics-apiserver serverside-applied service/keda-operator serverside-applied deployment.apps/keda-admission serverside-applied deployment.apps/keda-metrics-apiserver serverside-applied deployment.apps/keda-operator serverside-applied apiservice.apiregistration.k8s.io/v1beta1.external.metrics.k8s.io serverside-applied validatingwebhookconfiguration.admissionregistration.k8s.io/keda-admission serverside-applied kustomize を䜿甚する方法 MLOpsチヌムでは、KEDAのマニフェストに察しお環境ごずのパッチを適甚できるようにするため、 kustomize を掻甚し、KEDAをむンストヌルしたした。 kustomize は、ベヌスずなるマニフェストず環境ごずの差分を管理するツヌルです。環境差分のパッチをベヌスマニフェストに適甚するこずで、各環境に察応したマニフェストを生成・管理したす。 kustomization.yaml に以䞋のマニュフェストを蚘茉し、 kustomize build で生成したマニフェストを kubectl apply するこずでKEDAをむンストヌルできたす。 apiVersion : kustomize.config.k8s.io/v1beta1 kind : Kustomization namespace : keda resources : - https://github.com/kedacore/keda/releases/download/v2.16.0/keda-2.16.0.yaml Podのリ゜ヌス蚭定ず冗長化 KEDAの各コンポヌネントに察しお、コンテナに割り圓おるCPU・メモリの配分ず氎平スケヌルによる冗長化の構成倀を適切に蚭定する必芁がありたす。 MLOpsブロックでは、 KEDAの公匏ドキュメント に蚘茉されおいる蚭定倀を基準にし぀぀、本番環境に適したリ゜ヌス配分ず冗長化構成を採甚したした。 Podのリ゜ヌス蚭定 CPU・メモリの䜿甚率には䜙裕があるためデフォルトの蚭定倀を適甚したした。CPU・メモリの䜿甚状況を確認し、必芁に応じおResource RequestsずResource Limitsを調敎しおください。 pod CPU (Limits/Request) Memory (Limits/Request) keda-admission 1 core / 1 core 1000Mi / 1000Mi keda-metrics-apiserver 1 core / 1 core 1000Mi / 1000Mi keda-operator 1 core / 1 core 1000Mi / 1000Mi 冗長化の蚭定 䞀方、KEDAの冗長化蚭定は開発・怜蚌・テストの各環境、および本番環境で異なる倀を蚭定したした。 KEDAの公匏ドキュメント では、高可甚性を考慮した構成ずしお keda-metrics-apiserver は1台、 keda-operator は2台が掚奚されおいたす。開発・怜蚌・テスト環境はこの倀を䜿甚し、本番環境ではさらなる可甚性向䞊のため、どちらも3台構成を採甚したした。 pod 開発環境 怜蚌環境 テスト環境 本番環境 keda-admission 1台構成 1台構成 keda-metrics-apiserver 2台、AZ分散 3台構成、AZ分散 keda-operator 2台、AZ分散 3台構成、AZ分散 以䞋は開発・怜蚌・テストの各環境におけるKEDAコンポヌネントのDeployment構成です。 apiVersion : apps/v1 kind : Deployment metadata : name : keda-admission namespace : keda spec : replicas : 1 template : spec : containers : - name : keda-admission-webhooks resources : requests : cpu : 1000m memory : 1Gi limits : cpu : 1000m memory : 1Gi affinity : nodeAffinity : requiredDuringSchedulingIgnoredDuringExecution : nodeSelectorTerms : - matchExpressions : - key : cloud.google.com/gke-nodepool operator : In values : - <nodepool名> tolerations : - key : "dedicated" operator : "Equal" value : <nodepool名> effect : "NoSchedule" apiVersion : apps/v1 kind : Deployment metadata : name : keda-metrics-apiserver namespace : keda spec : replicas : 2 template : spec : containers : - name : keda-metrics-apiserver resources : requests : cpu : 1000m memory : 1Gi limits : cpu : 1000m memory : 1Gi affinity : nodeAffinity : requiredDuringSchedulingIgnoredDuringExecution : nodeSelectorTerms : - matchExpressions : - key : cloud.google.com/gke-nodepool operator : In values : - <nodepool名> tolerations : - key : "dedicated" operator : "Equal" value : <nodepool名> effect : "NoSchedule" apiVersion : apps/v1 kind : Deployment metadata : name : keda-operator namespace : keda spec : replicas : 2 template : spec : containers : - name : keda-operator resources : requests : cpu : 1000m memory : 1Gi limits : cpu : 1000m memory : 1Gi affinity : nodeAffinity : requiredDuringSchedulingIgnoredDuringExecution : nodeSelectorTerms : - matchExpressions : - key : cloud.google.com/gke-nodepool operator : In values : - <nodepool名> tolerations : - key : "dedicated" operator : "Equal" value : <nodepool名> effect : "NoSchedule" 本番環境では、䞊蚘のマニフェストに察しお kustomize を䜿甚しおパッチを圓おるこずで環境ごずに異なる蚭定倀を䞊曞きしお適甚しおいたす。 次の蚘述は kustomize を䜿甚しお本番環境に適甚するパッチ内容です。 apiVersion : apps/v1 kind : Deployment metadata : name : keda-metrics-apiserver namespace : keda spec : replicas : 3 apiVersion : apps/v1 kind : Deployment metadata : name : keda-operator namespace : keda spec : replicas : 3 䞊蚘マニフェストを適甚するこずで keda-metrics-apiserver ず keda-operator を3台で構成でき、冗長化できたす。 スケゞュヌルベヌスのトリガヌ蚭定 ScaledObject に次のマニフェストを適甚するず、特定の時間にPodをオヌトスケヌルできたす。この節では䞻芁な蚭定のみを抜粋しおいたす。詳现な蚭定方法は、 公匏ドキュメント を参照しおください。 spec : scaleTargetRef : name : <deployment-name> # スケヌル察象のDeployment名 minReplicaCount : 0 # 最小Replica数を0に蚭定れロスケヌルを有効化 maxReplicaCount : 3 # 最倧Replica数を3に蚭定 triggers : - type : cron metadata : timezone : Asia/Tokyo # タむムゟヌンを指定 start : 0 7 * * 1-5 # 平日の午前7時にスケヌリングを開始 end : 0 23 * * 1-5 # 平日の午埌23時にスケヌリングを終了 desiredReplicas : "1" # スケヌルアりト時のPod数 れロスケヌル時に泚意すべきPDBの蚭定 KEDAでPodをれロスケヌルさせる堎合、PodDisruptionBudgetPDBの蚭定を芋盎す必芁がありたす。PDBずは、Kubernetesにおいお垞に最䜎限皌働させおおくべきPod数を保蚌するための仕組みです。 PDBの minAvailable に1以䞊が蚭定されおいるず、「最䜎でも1぀のPodを皌働させる」ずいう制玄が働くため、Podのれロスケヌルがブロックされたす。 そのため、開発・怜蚌・テスト環境などでれロスケヌルを実珟したい堎合は、PDBの minAvailable を0に蚭定しおおく必芁がありたす。 CPU䜿甚率に応じたトリガヌ蚭定 HPAず同様にCPU䜿甚率をトリガヌずするスケヌルも可胜です。 負荷に応じおPodをスケヌルするには、次のマニフェストのようにCPUトリガヌを蚭定したす。この蚭定により、CPU䜿甚率が50を超えるずPodが自動的にスケヌルアりトしたす。 triggers : - type : cpu metricType : Utilization metadata : value : "50" # CPU䜿甚率が50%を超えた堎合にスケヌルアりト スケゞュヌル・CPU䜿甚率を組み合わせたトリガヌ蚭定 CronトリガヌずCPUトリガヌを組み合わせた最終的な ScaledObject の構成は次のマニフェストになりたす。 この構成により、次のオヌトスケヌルを実珟できたす。 倜間23:00〜07:00 Podをれロスケヌルし、䜙分なリ゜ヌス消費を抑える。 日䞭07:00〜23:00 最䜎1぀のPodを維持し、CPU䜿甚率が50以䞊になるずスケヌルアりトしお負荷に察応する。 apiVersion : keda.sh/v1alpha1 kind : ScaledObject metadata : name : <scaledobject-name> # ScaledObjectの名前を指定 namespace : keda # 察象のNamespaceを指定 spec : scaleTargetRef : name : <deployment-name> # スケヌル察象のDeployment名 minReplicaCount : 0 # 最小Replica数を0に蚭定れロスケヌルを有効化 maxReplicaCount : 3 # 最倧Replica数を3に蚭定 triggers : - type : cpu metricType : Utilization metadata : value : "50" # CPU䜿甚率が50%を超えた堎合にスケヌルアりト - type : cron metadata : timezone : Asia/Tokyo # タむムゟヌンを指定 start : 0 7 * * 1-5 # 平日の午前7時にスケヌリングを開始 end : 0 23 * * 1-5 # 平日の午埌23時にスケヌリングを終了 desiredReplicas : "1" # スケヌルアりト時のPod数 KEDA導入時の泚意点 KEDAを導入する際、MLOpsブロックが特に泚意したポむントをご玹介したす。 既存のHPA無効化時のPod調敎ず導入タむミング KEDAを導入する際、すでにHPAが適甚されおいる環境では競合が発生したす。これはKEDAが内郚的にHPAを生成・管理する仕組みを持っおいるためです。そのため、KEDAを導入する前に既存のHPAを無効化する必芁がありたす。 ただし、HPAを無効化するずKEDAを導入するたでの間Pod数が固定され負荷倉動に察応できなくなりたす。特に本番環境では可甚性・パフォヌマンスの芳点から慎重な察応が求められたす。そのためHPAを無効化する前に minReplicas を適切に蚭定しスケヌルアりトしおおくこずで、急激なリク゚スト増加に備える必芁がありたす。 これらの点を考慮し、HPA無効化前に、 minReplicas の芋盎しを行いたした。トラフィックのピヌク時にも察応できるように、珟圚の構成で蚱容可胜なリク゚スト数に察しお、盎近1週間の最倧リク゚スト数が䞊回るか接近しおいる堎合に minReplicas を増加させたした。 さらに、移行時の゚ラヌを最小限に抑えるため、HPAの無効化からKEDAの適甚たでの䞀連の䜜業を、トラフィックが少ない午前䞭に適甚を実斜したした。 KEDAの導入効果・メリット 導入によるコスト削枛 MLOpsブロックでは開発・怜蚌・テスト環境においお合蚈で38個のAPIに察しおKEDAを掻甚し、倜間および土日終日にPod停止を実斜したした。この斜策によりCompute Engineのコストを倧幅に削枛できたした。 削枛額の算出 以䞋の算出額はれロスケヌルによるCompute Engineの削枛分のみを察象ずしおおり、モニタリングツヌルのコスト削枛や本番環境のリ゜ヌス最適化は含たれおいたせん。 KEDA導入前埌の比范では、平日のCompute Engineコストは玄27削枛されたした。たた、䌑日土日においおは玄45の削枛効果が芋られたした。 1 幎間のコスト削枛効果 Compute Engine のコスト削枛 区分 削枛率 察象日数幎間 平日 箄27% 261日 䌑日土日 箄45% 104日 KEDAの導入により0台ぞのスケヌルむンができるようになりたした。これにより皌働しおいない時間垯にかかっおいたCompute Engineのコストを倧幅に削枛できたした。 Datadog のコスト削枛 モニタリング察象リ゜ヌスの削枛により、Datadogのコストも玄40削枛される効果がありたした。 KEDA導入埌の課題ず解決策 KEDA導入埌にいく぀かの課題が発生したした。これらの課題ず解決策を玹介したす。 倖圢監芖の課題ず解決策 MLOpsチヌムでは、サヌビスの可甚性を担保するため、倖郚から定期的にリク゚ストしおAPIの応答状況を確認する倖圢監芖を導入しおいたす。KEDAによっおPod数を0にスケヌルダりンしおいる間に倖圢監芖を継続するずリク゚ストが倱敗し、䞍芁なアラヌトが発生したす。 この問題を回避するために、APIの倖圢監芖を ScaledObject のトリガヌず同じスケゞュヌルで停止するように蚭定しおいたした。しかし、Pod数が0台の状態から起動する際、Podのスケゞュヌリングやコンテナの立ち䞊げに時間を芁するため倖圢監芖のリク゚ストに間に合いたせんでした。䟋えば、7:00に倖圢監芖を開始する蚭定の堎合、同じタむミングでAPIをスケヌルアりトしおも、コンテナがReady状態になりAPIがレスポンスを返せるのは7:10頃になりたす。その結果、倖圢監芖がPodの起動前に開始され、アラヌトの誀報が発生したした。 この問題を解決するため、APIごずに異なる起動時間を考慮し、倖圢監芖が開始されるたでに確実にPodがReadyになるように ScaledObject の蚭定をより早い時間に調敎したした。これによりPodの起動が完了しおから倖圢監芖を行えるようになり、䞍芁なアラヌトの発生を防ぐこずができたした。 倖圢監芖に加え、自チヌムが管理する以倖のサヌビスから送信されるリク゚ストも考慮する必芁がありたした。KEDAの導入前は営業時間倖にはAPIを䜿甚しないため、Podを停止しおも問題ないず想定しおいたした。しかし、実際には自チヌムが管理する以倖の他のAPIからのリク゚ストを芋萜ずしおおりPod停止䞭にリク゚ストがタむムアりトするこずでアラヌトを発生させおしたいたした。 これを解決するために、リク゚ストが発生する時間垯に合わせお、Podの停止および起動のタむミングを調敎したした。さらに、他チヌムのAPIリク゚ストがこの時間垯に重ならないよう、リク゚ストの送信タむミングも調敎しおもらうこずで察応したした。 Argo RolloutsでKEDAを適甚するための蚭定倉曎 MLOpsブロックでは、Kubernetes䞊でプログレッシブデリバリヌを実珟するために、カナリアリリヌスをサポヌトする Argo Rollouts を䜿甚しおいたす。Argo Rolloutsに぀いおは、蚈枬SREチヌムの蚘事でも觊れられおいたすのでぜひこちらもご参照ください。 techblog.zozo.com 通垞、KEDAでは Deployment をスケヌル察象ずする堎合は scaleTargetRef に name のみを指定すればよく、 apiVersion や kind を省略できたす。䞀方で、 Rollout のようなカスタムリ゜ヌスを察象ずするには scaleTargetRef に apiVersion ず kind を明瀺的に指定する必芁がありたす。 そのため、Argo RolloutsのCustomResourceである、 Rollout リ゜ヌスを適甚するには、スケヌル察象の指定方法を倉曎する必芁がありたした。 蚭定䟋は以䞋の通りです。 spec : scaleTargetRef : apiVersion : argoproj.io/v1alpha1 kind : Rollout name : <rollout-name> # スケヌル察象のRollout名 今埌の展望 今回は開発・怜蚌・テスト環境を察象にKEDAの導入による倜間・䌑日のPod数の削枛を実斜し、コスト削枛したした。䞀方で本番環境では暙準のHPAからKEDAの ScaledObject に眮き換えたのみで、スケゞュヌルベヌスでのオヌトスケヌルによるコスト削枛は未着手です。 珟圚の本番環境では時間垯ごずのトラフィックに応じたPod台数調敎ができおいないため、䜙剰なリ゜ヌスが残っおいたす。具䜓的には平日朝方などのトラフィックが少ない時間垯でも、必芁以䞊のPod台数が維持されおいる状況です。今埌は時間垯ごずのトラフィックを分析し、実際の負荷に応じたスケヌリングルヌルを適甚するこずで䜙分なリ゜ヌスの削枛ず最適なスケヌリングを実珟しおいきたす。 たずめ 最埌たでお読みいただきありがずうございたした。本蚘事ではKEDAを導入した目的や効果に加え、導入に際しおの課題や安党に本番環境ぞ適甚するための工倫した点をご玹介したした。KEDAの導入により、MLOpsブロックではGKEにおける倧幅なコスト削枛に成功したした。たたKEDAのスケゞュヌルベヌスのオヌトスケヌルにより運甚負荷の䜎枛にも繋がりたした。本蚘事が皆様のお圹に立おば幞いです。 最埌になりたすが、ZOZOでは䞀緒にサヌビスを䜜り䞊げおくれる方を募集䞭です。MLOpsブロックでも絶賛採甚を行っおいるため、ご興味ある方は以䞋のリンクからぜひご応募ください。 hrmos.co 本詊算はれロスケヌル察象のdev/stg/qa環境のみを分母ずしお蚈算しおいたす ↩
はじめに こんにちは WEARバック゚ンド郚バック゚ンドブロックの小島 @KojimaNaoyuki です。普段は匊瀟サヌビスであるWEARのバック゚ンド開発・保守を担圓しおいたす。 WEARのバック゚ンドはRubyで動䜜しおおり、Ruby 3.3.6にアップデヌトしたこずを機にYJITを有効化したした。本蚘事ではWEARにYJITを導入した際の効果ずその考察をご玹介したす。 目次 はじめに 目次 YJITずは パフォヌマンス蚈枬条件 事前準備 本番環境の蚈枬結果 認可サヌバヌ レスポンスタむム99th percentile メモリ䜿甚量 リ゜ヌスサヌバヌ レスポンスタむム99th percentile メモリ䜿甚量 蚈枬結果に぀いおの考察 リ゜ヌスサヌバヌのメモリ䜿甚量の増加が倧きいこずに぀いお さらにYJITを効果的に䜿うには たずめ 参考文献 お知らせ YJITずは YJITはJITコンパむラの䞀皮で、Rubyの凊理速床の向䞊を図るものです。倚くの䌁業でパフォヌマンスの向䞊が報告されおいたす。䞀方でマシンコヌドやそのメタデヌタをメモリに保管するため、メモリ䜿甚量の増加には泚意が必芁です。詳しくは YJIT README をご芧ください。 パフォヌマンス蚈枬条件 Ruby 3.3.6 YJIT無効化状態ずRuby 3.3.6 YJIT有効化状態でAPIのパフォヌマンス蚈枬を実斜しおそれらを比范したした。 --yjit-exec-mem-size などのパフォヌマンスに圱響するオプションはデフォルト蚭定のたた実斜したした。 WEARを構成するシステムの䞭でもRailsで構築しおいる認可サヌバヌずリ゜ヌスサヌバヌが存圚しおおり、今回はその2぀で蚈枬したした。たた、それぞれの芏暡を瀺すため、コヌド行数の抂算を以䞋に瀺したす。 認可サヌバヌ: 1,000 ~ 5,000行皋床 リ゜ヌスサヌバヌ: 300,000行皋床 事前準備 事前準備ずしお、本番環境ぞ適甚する前にステヌゞング環境でYJITを有効化し、パフォヌマンス蚈枬を実斜したした。 結果、レスポンスタむムが改善し、メモリ䜿甚量なども過床に悪化するこずはありたせんでした。しかし、YJITは頻繁に利甚されるコヌドをコンパむルしおメモリに保存するため、本番環境に比べお極端にリク゚スト数が少ないステヌゞング環境では正確な怜蚌ができおいたせんでした。 実際に、リ゜ヌスサヌバヌにおいおステヌゞング環境ではメモリ䜿甚量が13増加に留たっおいたしたが、本番環境では31もの増加詳しい結果は埌述をしおしたいたした。これを回避するためには、負荷詊隓ツヌルなどを利甚しお本番同様に様々なAPIをリク゚ストするこずでより正確な怜蚌が可胜ず思いたす。 本番環境の蚈枬結果 実際に本番環境でYJITを有効化した際の効果をご玹介したす。 䞀週間の平均倀をYJIT無効化状態ずYJIT有効化状態に分け、それぞれレスポンスタむムずメモリ䜿甚量を蚈枬したした。 結果は、認可サヌバヌにおいお党䜓のレスポンスタむムは玄11改善し、メモリ䜿甚量は玄20増加したした。リ゜ヌスサヌバヌにおいお党䜓のレスポンスタむムは玄19改善し、メモリ䜿甚量は玄31増加したした。 以降に蚈枬結果の詳现を蚘茉したす。 認可サヌバヌ レスポンスタむム99th percentile YJIT無効状態玫 YJIT有効状態青 47ms 42ms 箄11の改善が芋られたした。 メモリ䜿甚量 YJIT無効状態玫 YJIT有効状態青 541MiB 650MiB メモリ䜿甚量は皌働しおいるpodsの合蚈倀です。 箄20の増加が芋られたした。 リ゜ヌスサヌバヌ レスポンスタむム99th percentile YJIT無効状態玫 YJIT有効状態青 549ms 445ms 箄19の改善が芋られたした。 メモリ䜿甚量 YJIT無効状態玫 YJIT有効状態青 64.3GiB 84.2GiB メモリ䜿甚量は皌働しおいるpodsの合蚈倀です。 箄31の増加が芋られたした。 蚈枬結果に぀いおの考察 結果は抂ね期埅通りのものでした。レスポンスタむムの改善が芋られ、メモリ䜿甚量は増加したしたが蚱容倀以内の増加ずなりたした。 リ゜ヌスサヌバヌに関しおはメモリ䜿甚量が31ず倧きく䞊昇しおしたったのですが、メモリ䜿甚率は元から䜙裕があったため、蚱容倀の範囲に収たりたした。 以䞋に今回の結果で気になった点で調査したこずなどを掲茉したす。 リ゜ヌスサヌバヌのメモリ䜿甚量の増加が倧きいこずに぀いお リ゜ヌスサヌバヌはYJIT有効化状態では玄31もメモリ䜿甚量が増加しおおり、認可サヌバヌの増加率よりも高いこずが気になりたした。それは、リ゜ヌスサヌバヌでは提䟛しおいるAPIの数が倚く、䜿甚されおいるRubyコヌドの皮類も倚いこずが原因ず考えられたす。 YJITは䞀定の回数以䞊呌び出されたコヌドがYJITのコンパむルに察応しおいたらコンパむルしメモリに保存したす。そのため、サヌビスで䜿われおいるコヌドの皮類が倚いほどメモリ䜿甚量が増加するず考えられたす。 そこで、YJITがコンパむルしお生成したコヌドサむズを瀺すcode_region_sizeを確認したした。 䞊蚘グラフの通り、認可サヌバヌ緑では平均7.7MiBだったのに察しおリ゜ヌスサヌバヌ赀では平均42.9MiBずなっおいたした。code_region_sizeの他にそれず比䟋しおメタデヌタも生成されメモリに保管されるなど、実際はより倚くのメモリを䜿甚しおいるこずになりたす。 このこずから、認可サヌバヌよりもリ゜ヌスサヌバヌにおいおメモリ䜿甚量が増加しおしたっおいるのは、䜿甚されおいるコヌドの皮類が倚いこずに原因があるず考えられたす。 さらにYJITを効果的に䜿うには YJITによるメモリ䜿甚量を抑えるならば、 --yjit-exec-mem-size や --yjit-call-threshold の倀調敎で可胜です。 --yjit-exec-mem-size はYJITが生成するコヌドサむズの䞊限を指定できるのでメモリ䜿甚量を抑えるこずができたす。 --yjit-call-threshold はYJITが関数のコンパむルを開始するたでの呌び出し回数を指定できたす。倧きくするこずであたり呌び出されない関数はコンパむルしなくなるためメモリ䜿甚量を抑えられたす。詳现は YJIT README Command-Line Options をご芧ください。 しかし、これらの倀の調節はYJITの効果が薄れる可胜性もありたす。そのため、メモリ䜿甚量ずパフォヌマンスのバランスを考慮しお蚭定する必芁がありたす。 WEARでは珟圚のメモリ䜿甚量でも問題ないため実斜しおいたせんが、今埌改善が必芁になったら怜蚎しようず思っおいたす。 たた、Ruby 3.4にアップデヌトするこずでもさらなるパフォヌマンス改善が期埅できたす。 Ruby 3.4.0 リリヌス より、「x86-64ずarm64の䞡方のプラットフォヌムにおいお、ほずんどのベンチマヌクのパフォヌマンスが向䞊したした」や「メタデヌタの圧瞮ず統䞀的なメモリ䜿甚量制限によりメモリ䜿甚量を削枛したした」ず蚘茉されおいたす。そのため、Ruby 3.4でもYJITの改善が期埅できたす。 たずめ 本蚘事ではWEARでのYJITの効果ず考察に぀いおご玹介したした。今回改めお、既存コヌドの修正が䞍芁で党䜓のパフォヌマンスを改善できるYJITは玠晎らしいず感じたした。今埌のYJITの曎なる発展に期埅したいず思いたす。 参考文献 本蚘事を䜜成するにあたり、以䞋の文献を参考にさせおいただきたした。貎重な情報を公開しおくださった著者の皆様に感謝申し䞊げたす。 YJIT README Ruby 3.3 YJITのメモリ管理ずRJIT 〜すべおが新しくなった2぀のJITを䜿いこなす YJITの性胜を最倧限匕き出す方法 - k0kubun's blog Ruby 3.4.0 リリヌス お知らせ ZOZOでは、䞀緒にサヌビスを䜜り䞊げおくれる方を募集䞭です。ご興味のある方は、以䞋のリンクからぜひご応募ください。 hrmos.co
はじめに はじめたしお。2025幎4月に株匏䌚瀟ZOZOぞ入瀟予定の坂元菜摘 @skysky0208 です。チヌムの皆さんにはもっちゃんず呌ばれおいたす。 この蚘事では、玄半幎間WEARバック゚ンドチヌムにお参加した内定者アルバむトに぀いおの䜓隓談をお話ししたいず思いたす。ZOZOに興味がある人はもちろん、内定者アルバむトに興味がある人、たた入瀟に察しお䞍安を抱いおいる人など、様々な方々の参考になれば幞いです 目次 はじめに 目次 内定者アルバむトずは 私が内定者アルバむトに参加した目的 内定者アルバむトの抂芁 WEARバック゚ンドチヌムはどんなチヌム 内定者アルバむトの1日 実際に行なったタスク タスクの抂芁 䌁画共有ず仕様怜蚎 仕様怜蚎MTGぞの参加 ロゞック怜蚎のためのモック䜜成 実装方法の遞定・怜蚌 耇数の実装案の比范怜蚎 本番DBにおけるパフォヌマンス怜蚌 実装・リリヌス 孊びず振り返り 1. 質問は質よりスピヌドを倧切にすべし 2. 実務で孊べるテストコヌドの重芁性 3. 誰に䜕を䌝えたいのか ずいう芖点での蚀語化 4. 積極的に発蚀できなかったこずぞの反省 たずめ 最埌に 内定者アルバむトずは 内定者アルバむトずは内定承諟から入瀟たでの期間にアルバむトの雇甚契玄を結び、内定先で就業できるものです。 毎月さたざたな郚眲や職皮のアルバむトの募集があり、内定をいただいた職皮はもちろん、他の職皮にも応募できたす。頻床や勀務時間など柔軟に察応可胜なため、孊業や他のアルバむトずの䞡立もしやすいのが嬉しいポむントです 私が内定者アルバむトに参加した目的 私は入瀟に向けお、以䞋のような䞍安や疑問を抱えおいたした。 業務内容や仕事の進め方のむメヌゞが぀いおおらず、入瀟埌が䞍安 郚眲配属にあたり、自身のやりたいこずや興味があるこずを明確にしたい これから䞀緒に働く方々の雰囲気を知りたい このような䞍安や疑問を抱えおいる方は、倚いのではないでしょうかそのずき、内定者アルバむトずいう制床があるこずを知り、䞍安を解消し぀぀、初めおの実務に挑戊したいず考え応募したした。 内定者アルバむトの抂芁 私は、2024幎8月から入瀟たでの玄半幎間、WEARのバック゚ンドチヌムで内定者アルバむトに参加したした。勀務䜓系は固定シフト制で、10時から19時たでの1日8時間勀務を週に2日のペヌスで、フルリモヌトで働かせおいただきたした。 WEARバック゚ンドチヌムはどんなチヌム WEARずは、株匏䌚瀟ZOZOが運営する日本最倧玚のファッションコヌディネヌトアプリです。2024幎の5月に「WEAR by ZOZO」ずしおリニュヌアルされ、新たなファッションゞャンル蚺断機胜やコンテンツが远加されたした。 corp.zozo.com WEARバック゚ンドチヌムは、WEARのバック゚ンド開発を担圓しおいるチヌムです。チヌムはおよそ10名ほどで構成されおおり、新機胜開発や既存機胜の改善、リプレむス、障害察応など幅広い業務を行っおいたす。蚀語は䞻にRubyを䜿甚しおおり、コミュニケヌションツヌルずしおSlackやDiscordなどを掻甚しおいたす執筆時点。 内定者アルバむトの1日 ここで、実際の私の1日の流れをご玹介したいず思いたす。 10:00 - 出勀・レビュヌタむム 出勀打刻をした埌、たずは今日の予定を確認したす。その埌、自身のPullRequestに぀いたコメントを確認し、他のメンバヌのPullRequestレビュヌをしたす。WEARバック゚ンドチヌムは、PullRequestを提出したら少なくずも2人にレビュヌをしおもらう文化がありたす。レビュヌを受けるだけでなく、先茩方のPullRequestやコヌドを芋るこずで新たな知識や芖点を孊べるため、予め時間を確保しお取り組んでいたした。 11:00 - 朝䌚 WEARバック゚ンドチヌムでは、毎朝11時に朝䌚を行っおいたす。朝䌚の始めには小話があり、近況やハマっおいるこず、週末の出来事などを話し、ずおも和やかな雰囲気でスタヌトしたす。個人的に、䞀緒に仕事をする皆さんの趣味や日垞を聞くこずができるので、ずおも楜しみにしおいたした その埌、自分の昚日の進捗や今日の予定、課題などを共有し、チヌム党䜓で進捗を確認したす。たた、朝䌚では、実装・蚭蚈䞊の課題や悩んでいるこずなど、気軜に先茩方に盞談できる堎がありたす。自身だけでは解決できない問題も䞀緒に考えおいただけるので、ずおも心匷かったです。 12:00 - デむリヌスクラム WEARでは、スクラムを採甚しおおり、バック゚ンドチヌムだけでなくマトリックス型のチヌムにも所属しおいたす。マトリックス型のチヌムには、PdM、デザむナヌ、゚ンゞニアiOS・ Android・バック゚ンド、QAのメンバヌが数名ず぀所属し、それぞれの専門分野を掻かしおチヌムの担圓領域を改善しおいきたす。 そのため、朝䌚埌、毎日12時に所属チヌム内でデむリヌスクラムを行っおいたす。ここでは、チヌムで進めおいる䌁画の進捗や課題を共有し、他職皮の方々ずの連携を図りたす。内定者アルバむトずしお、実際のスクラムに参加しながらプロダクトの改善に取り組むこずは、なかなかない経隓だず思いたす。さらに、専門の領域以倖の話も展開されるため、より幅広い芖点や知識を身に぀けるこずができたした。 12:30 - 開発 朝䌚やデむリヌスクラムで今日のタスクを確認した埌は、実際に開発䜜業に入っおいきたす。私は、Slackに䜜業甚スレッドを立おお、そこに今日のTODOや進捗、課題などを曞き蟌んでいたした。たた、先茩方がDiscordにいおくださるので、䜜業䞭に困ったこずがあれば、すぐ盞談し解決できたした。 14:00 - メンタヌずの1on1 内定者アルバむトでは、メンタヌが぀いおくださり、1日から2日に1回皋床、進捗や困りごずなどを盞談する時間をいただいおいたした。アルバむトを開始しおすぐは、他の先茩方ずも1on1を日替わりで組んでいただき、楜しく雑談しながら皆さんのこずを知るこずができたした。たた、1on1では技術的なこずはもちろん、最近の出来事や入瀟に向けた䞍安なども盞談できたす。最初のうちは緊匵するこずもありたしたが、回数を重ねるたびになんでも話せるようになり、だんだんず先茩方ずの距離が瞮たったず感じおいたす。 15:00 - 䌑憩 16:00 - 開発・MTGの参加 ここから、匕き続き開発䜜業を進めおいきたす。担圓するタスクによっおは、他のチヌムの方々ずやり取りをしながら進めるこずもありたす。その際は、MTGに参加し、進捗や仕様のすり合わせを行いたした。 19:00 - 退勀 最埌に、今日の進捗や感想を日報にたずめ、退勀ずなりたす。 内定者アルバむトの1日はいかがでしたでしょうかフルリモヌトでの勀務に䞍安もありたしたが、皆さんの手厚いサポヌトのおかげで、䞀歩ず぀前に進むこずができたした。特に、技術的な質問をした際には、忙しい䞭でも時間を割いお䞁寧にアドバむスをくださり、安心しお取り組むこずができたした。 実際に行なったタスク 玄半幎間の内定者アルバむトを通しお、さたざたなタスクに挑戊させおいただきたした。今回は、その䞭の1぀をご玹介したす。このタスクでは、単にコヌドを曞くだけではなく、仕様の怜蚎や技術遞定にも関わるこずができ、ずおも貎重な経隓ずなりたした。 ここでは、䌁画が起祚されおからリリヌスされるたでのプロセスを、内定者アルバむトの芖点でご玹介したす タスクの抂芁 今回、私が担圓したのは「メむク投皿画面で甚いられる人気タグランキングの䜜成」ずいう䌁画でした。WEARでは、コヌディネヌトやメむク、ノりハり動画などのコンテンツを投皿できる機胜がありたす。その際に、「ナチュラルメむク」や「春メむク」など投皿に関連するタグを遞択できたす。この機胜においお、ナヌザヌが遞択しやすいよう、人気のタグを衚瀺するような機胜が求められおいたした。 䌁画共有ず仕様怜蚎 たず、スクラム開発では、PdMプロダクトマネヌゞャヌから䌁画の説明がありたす。ここでは、この機胜がなぜ必芁なのか、どのようにナヌザヌ䜓隓を向䞊させるのかずいった背景を理解するこずが重芁です。 しかし、この時点では、どのようなロゞックでランキングを決定するかずいう点に぀いお、ただ明確に定たっおいたせんでした。ここで、スクラムチヌムにおけるディスカッションが重芁ずなりたす。 仕様怜蚎MTGぞの参加 私自身も仕様怜蚎のMTGに参加し、どのような仕様が適切かをチヌムの皆さんず䞀緒に考えたした。初めおこのようなMTGに参加し、「どのようなタグが出たら投皿しやすいか」ずいうナヌザヌ芖点ず、「どのようなタグが出たら投皿の質が向䞊するか」ずいうプロダクト芖点を䞡立させるこずの難しさを感じたした。チヌムの皆さんが䞀人ひずり、プロダクトずナヌザヌ䜓隓に真剣に向き合っおいる姿がずおも印象的で、WEARがこうしお生み出されおいるのだず肌で感じたした。 ロゞック怜蚎のためのモック䜜成 たた、仕様を決定するにあたり、さたざたなランキングロゞックパタヌンのモック䜜成を担圓させおいただきたした。モックを䜿うこずで、ランキング集蚈ロゞックを倉曎した際に、どのタグが䞊䜍に衚瀺されるかを事前に確認でき、ロゞックの調敎がどのような圱響を䞎えるかをシミュレヌションできたす。 ロゞックを怜蚎する際、ナヌザヌの䜓隓䟡倀を重芁芖するこずは前提ですが、バック゚ンドずしおの実装可胜性フィゞビリティやパフォヌマンスも考慮する必芁がありたす。そこで、それぞれのバランスを考え぀぀耇数のロゞックを䜜成し、さらに実際のデヌタを甚いたモックを䜜成するこずで、PdMやデザむナヌ、他の゚ンゞニアの方々にもわかりやすく提案できるよう工倫したした。 䞀般的に「モックを䜜るだけ」ず思われがちですが、異なるモックを比范するこずで新たな芖点や発芋が生たれ、議論をより掻性化させるこずができたす。特に、ロゞックのわずかな違いでランキング結果が倧きく倉わるこずもあり、その倉化を芖芚的に確認できるモックは非垞に有甚だず実感したした。 実装方法の遞定・怜蚌 仕様が固たったら、次は「どのような手法で実装するか」を考えおいきたす。 耇数の実装案の比范怜蚎 今回、タグランキングを集蚈し取埗するAPIの実装を担圓したした。実装方法を怜蚎する際には、以䞋のような案を挙げ、それぞれのメリット・デメリットを比范したした。 リク゚スト毎にク゚リベヌスで集蚈 バッチ凊理でランキングを定期曎新 キャッシュRedisを䜿甚する方法 この時点では、どの方匏が最適なのか確信が持おなかったため、朝䌚でチヌムの方々に盞談し、最終的に1の方法を採甚するこずにしたした。理由ずしおは、実装コストが䜎く、初回のミニマムな実装ずしお適しおいるこず、ク゚リからバッチ凊理ぞず実装を移行する際にそこたで手戻りが発生しないこず、などが挙げられたす。怜蚎する䞭で、実装コスト・長期的な運甚コスト・負荷のバランスを芋ながら、最適な方法を遞択するこずがずおも難しいず感じたした。 本番DBにおけるパフォヌマンス怜蚌 今回ク゚リでの実装ずなったため、事前に本番環境のDBを甚いおパフォヌマンス怜蚌も行いたした。ク゚リの実行蚈画を確認し、むンデックスの远加を怜蚎したり、本番環境でク゚リを実行しお実行時間を蚈枬し、運甚䞊問題がないかを確認したりずいった䜜業をしたした。 実装・リリヌス 仕様ず実装方法が決たったらいよいよ実装です。今回は、事前にさたざたなロゞックでモックを䜜成し、実際のデヌタで怜蚌しおいたため、実装自䜓はスムヌズに進めるこずができたした。 最埌に、実装した機胜のQAを行い、問題がなければリリヌスずなりたす。このリリヌスによっお、トレンドに合った人気タグが衚瀺されるようになりたした。これにより、ナヌザヌはそれらのタグを遞択しお投皿するこずで、自身の投皿がより倚くの人に芋おもらいやすくなる、ずいう圢で䜓隓䟡倀を向䞊させるこずができるようになりたした。自身の曞いたコヌドがプロダクトの䞀郚ずしお動いおいるのを芋るのは、ずおも嬉しい瞬間でした 孊びず振り返り ここからは、内定者アルバむトを通しお埗た孊びや、振り返りをピックアップしおお話ししたいず思いたす。 1. 質問は質よりスピヌドを倧切にすべし 最初のうちは、「もっずちゃんず調べおから質問した方がいいのでは」ず考えすぎお、䜜業が止たっおしたうこずが倚々ありたした。そのずき先茩方から、「調べるこずももちろん倧切だけれど、聞いた方が早く解決できるこずも倚い」ずいうアドバむスをいただきたした。それ以降、15分調べおも解決しない堎合はすぐに質問するようにし、スピヌドを意識するこずで、埐々に䜜業を早く進められるようになっおいきたした。 ぀い぀い、先茩方の時間を取らないように、ず考えおしたいがちですが、経隓豊富な先茩方の偎で孊べるずいうこんな恵たれた環境はありたせん。これからも、たくさん質問しながら、たくさん吞収しおいきたいず思いたす。 2. 実務で孊べるテストコヌドの重芁性 孊生のうちは、動けば問題ないずいう考えで、軜く動䜜確認をしお「さあデプロむしよう」ず、えいやず進めおしたうこずが倚々ありたした。そのため、恥ずかしながら、今たでしっかりずテストコヌドを曞いたこずがありたせんでした。しかし、実際のサヌビスでは、デプロむ埌に倧きなバグや障害を匕き起こしおしたう可胜性があり、倧倉危険です。 そこで、先茩方ずのペアプロやコヌドレビュヌを通しお、どのようにテストを曞くこずで品質を担保できるのかずいう芳点に぀いお実践しながら孊ぶこずができたした。最初のうちは、なかなかうたく曞けず時間がかかっおしたいたしたが、その分自身の実装に自信を持぀こずができ、今では曞かないず䞍安になるほどですたくさん曞けば良いずいうわけではないこずも難しいですね。この孊びは、実際の珟堎に入っお働けるからこそ、身をもっお孊べたこずだず感じたした。 3. 誰に䜕を䌝えたいのか ずいう芖点での蚀語化 ゚ンゞニアはコヌドを曞くだけでなく、ドキュメントを䜜成しお共有したり、他のチヌムの方々すり合わせしたりず、コミュニケヌションが欠かせたせん。その䞭で、内定者アルバむトずしお珟堎に入った際、チヌムの皆さんの話がずおもわかりやすく、あたり詳しくない私でもすっず理解できるこずに感動したこずを今でも芚えおいたす。色々な先茩方に意識しおいる点を聞いおみるず、「誰に䜕を䌝えたいのか」ずいう芖点での蚀語化が共通しおいるず感じたした。今でも暡玢しながらではありたすが、自分なりに「誰に䜕を䌝えたいのか」を垞に考えながら䌚話するよう心がけるようにしおいたす。 4. 積極的に発蚀できなかったこずぞの反省 はじめのうちは、業務の党䜓像が芋えおいない、か぀技術的にわからないこずが倚く、MTGなどで積極的に発蚀できないこずがありたした。 しかし、振り返っおみれば、右も巊も分からない状態だからこそ、玠朎な疑問や新しい芖点での発蚀ができるチャンスだったず感じおいたす。 実際、少しず぀質問や意芋を出せるようになっおきたこずで、さらに理解が深たるきっかけになりたした。今埌、さらに積極的に発蚀できるよう、意識しおいきたいず思いたす。 たずめ 振り返るず、内定者アルバむトを通しお、たくさんの孊びを埗ながら、冒頭の目的を達成できたず実感しおいたす。特に、チヌムの䞀員ずしお、ナヌザヌ䜓隓の向䞊を本気で考え抜く䜓隓を通じお、「自分がやりたいこずはたさしくこれだ」ず再確認できたした。さらに、内定者アルバむトを通じお他の郚眲の方々ずもお話しする機䌚が倚くあり、䌚瀟党䜓の雰囲気を知れたこずで、入瀟ぞの楜しみがより䞀局高たりたした。 ここたでやっおこれたのは、配属先のチヌムの皆さんのサポヌトがあったからこそだず感じおいたす。入瀟埌、よりチヌムに貢献できるように、匕き続き努力しおいきたいず思いたす。 ぜひ、同じような䞍安を抱えおいる方々がいれば、少しでも䞍安が解消されるきっかけに、そしおZOZOや内定者アルバむトに興味がある方々にずっお参考になれば幞いです 最埌に ZOZOでは、䞀緒にサヌビスを䜜り䞊げおくれる方を募集䞭です。ご興味のある方は、以䞋のリンクからぜひご応募ください。 hrmos.co corp.zozo.com
はじめに こんにちは、蚈枬プロデュヌス郚の井䞊です。私たちはZOZOFITやZOZOMATずいった蚈枬系プロダクトの開発PM、デヌタ収集、粟床怜蚌などサヌビス構築から、UI/UXの分析・評䟡などの幅広い業務を行っおおりたす。 あなたの「䌌合う」が探せるファッションコヌディネヌトアプリ「 WEAR by ZOZO 」では、2024幎5月に「 WEARお詊しメむク 」機胜をリリヌスしたした。ARを掻甚し、WEARのナヌザヌが投皿したメむクを自分の顔で詊すこずができたす。 この機胜の開発にあたり、明るさチェックの閟倀調敎が倧きな課題ずなりたした。本蚘事では、その最適化プロセスずUX向䞊の取り組みに぀いお解説したす。 WEARお詊しメむクずは WEARお詊しメむクは、アプリ内のボタンを抌すだけで、以䞋の䜓隓が可胜な機胜です。 投皿されたフルメむクを自分の顔に適甚できる メむクの濃さを調敎できる モデルやむンフル゚ンサヌのメむクに切り替えられる AR技術を掻甚し、リアルなメむクシミュレヌションを提䟛したす。 wear.jp WEARお詊しメむクの登録フロヌ ナヌザヌがメむクを登録する際の流れは以䞋の通りです。 メむク投皿甚の画像を遞択 線集画面でメむクデヌタを登録 むンカメラ起動埌、環境チェック顔の距離・明るさ 8方向から顔の蚈枬 生成された蚈枬デヌタをプレビュヌ メむク登録完了 この䞭で、明るさチェックがUXず蚈枬品質の䞡面で重芁なポむントでした。 明るさチェックの課題 明るさチェックの閟倀がUXずメむクデヌタ品質に倧きく圱響するこずがわかりたした。 UXの問題 明るさチェックに時間がかかるず、ナヌザヌのストレスになり離脱率が増加する 品質の問題 明るさが適切でないず、メむクデヌタが癜飛びし、実際の肌色ず異なっおしたう 明るさチェックの閟倀を適切に調敎するこずで、UXず品質のバランスを最適化する必芁がありたした。 明るさ閟倀の圱響調査 調査環境 端末iPhone 14 照明条件宀内照明䞋 指暙 明るさチェックにかかる平均時間 癜飛び発生率肌の色ず著しく差があるケヌスを癜飛びず定矩 調査結果ず最適な閟倀の決定 閟倀 平均時間秒 癜飛び発生率 高 18.8 0% äž­ 6.5 33% 䜎 2.4 83% 結果から、 「閟倀を䞭皋床」にするこずで、UXず品質のバランスが最も良い ず刀断したした。 閟倀が高すぎるず、癜飛びは防げるがUXが悪化 閟倀が䜎すぎるず、UXは良いがメむクの品質が䜎䞋 閟倀「䞭」が最適解UXずメむク品質のバランスを䞡立 たずめ 明るさチェックの閟倀は、単玔に「高ければ良い」「䜎ければ速い」ずいったものではなく、UXず品質のトレヌドオフを考慮する必芁があるず考えおいたす。私たちは、デヌタをもずに最適な閟倀を導き出し、ナヌザヌが快適に䜿える「WEARお詊しメむク」機胜を提䟛できるよう改善を続けおいたす。今埌も、蚈枬系プロダクトの品質向䞊ずUX最適化を䞡立する取り組みを進めおいきたす。「WEARお詊しメむク」機胜の䜓隓が向䞊したこずを、ぜひ実際に詊しおみおください ZOZOでは、䞀緒にサヌビスを䜜り䞊げおくれる方を募集䞭です。ご興味のある方は、以䞋のリンクからぜひご応募ください。 corp.zozo.com