はじめに 技術戦略部の @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では、一緒にサービスを作り上げてくれる仲間を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 hrmos.co 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

はじめに こんにちは。データシステム部推薦基盤ブロックの佐藤（ @rayuron ）と住安（ @kosuke_sumiyasu ）です。私たちはZOZOTOWNのパーソナライズを実現する推薦システムを開発・運用しています。 ZOZOTOWNでは、様々な改善施策の効果を検証するためにA/Bテストを実施していますが、そのプロセスには多くの工程があり、効率化の余地がありました。本記事では、A/Bテストの工程を自動化・標準化し、効率化を図った取り組みについてご紹介します。 はじめに 背景 課題 1. A/Bテスト設計書のテンプレートがない 2. A/Bテストの開催期間が決め打ち 3. 有意差検定をするために手動運用が必要 4. チーム間で集計定義とダッシュボードが複数存在している 5. 施策ごとに新しいダッシュボードを作り直す必要がある 6. システム改修漏れが発生する 解決策 1. A/Bテスト設計書のテンプレートを作成 2. A/Bテストの開催期間の自動見積もり 3. 有意差検定の自動化 4. 集計定義とダッシュボードの統一 5. ダッシュボードの再利用 6. システム改修の手順書の作成 課題と解決策のまとめ 効果 1. A/Bテスト設計開始から意思決定までの時間の削減 2. ヒューマンエラーの低減 今後の展望 A/Bテスト体制の評価と改善 おわりに 背景 推薦基盤ブロックでは、ZOZOTOWNのトップページやメール配信などにおいて、ユーザーに最適なアイテムを推薦するシステムを開発・運用しています。これらのシステムを改善する際には、A/Bテストを通じて効果を検証します。 課題 まず、推薦基盤チームで運用されているA/Bテストの開始から終了までのプロセスは以下のようになっています。 上記のプロセスで運用を続けていましたが、以下の課題に直面していました。 A/Bテスト設計書のテンプレートがない A/Bテストの開催期間が決め打ち 有意差検定をするために手動運用が必要 チーム間で集計定義とダッシュボードが複数存在している 施策ごとに新しいダッシュボードを作り直す必要がある システム改修漏れが発生する 1. A/Bテスト設計書のテンプレートがない A/Bテスト設計を行う際には、A/Bテストの目的や、テストの内容、テスト期間、モニタリング指標などを記載したA/Bテスト設計書を作成します。しかし、明確なフォーマットが定められておらず、その結果、以下のような問題が生じていました。 必要項目が抜け落ちる 設計時の留意点がチーム全体で共有されず、共通認識が不足する フォーマットや記載文言にばらつきが生じ、読み手の認知コストが高くなる 2. A/Bテストの開催期間が決め打ち 従来のA/Bテストでは、テスト期間を固定し、その期間のデータをもとに任意の指標に関して有意差を判定していました。しかし、A/Bテスト期間を決め打ちする方法には2つの問題点があります。 1つ目は、「余分なリードタイムによる機会損失」です。これまでのA/Bテストはテスト期間を4週間に固定して実施していました。もし、A/Bテスト期間を短縮できれば、売上向上が期待できる施策は早期にリリースし、迅速に利益を得ることができます。 2つ目は、「十分なサンプルサイズが確保できない可能性」です。A/Bテストにおいてリリース判断を行うために、観察された差が統計的に偶然に起こる確率が十分に低いことを示す必要があります。しかし、A/Bテスト期間を単に短縮すると、サンプルサイズが減少し、指標にポジティブな効果があった場合でも統計的に有意差を確認できないリスクがあります。回避するためには、事前にMDE（Minimal Detectable Effect）を算出し、その効果の有意差を示すのに必要なサンプルサイズを見積もった上で、十分なテスト期間を確保する必要があります。 3. 有意差検定をするために手動運用が必要 A/Bテストの意思決定の段階では、有意差検定にJupyter Notebookを手動実行しており、分析作業が自動化されていませんでした。これにより、意思決定プロセスに余計な時間がかかっていました。 4. チーム間で集計定義とダッシュボードが複数存在している 指標をモニタリングするチームが複数あり、それぞれが集計定義とダッシュボードを個別管理していました。あるチームではスプレッドシートを使って指標の集計と可視化をしています。一方で別のチームでは、BigQueryのスケジュールクエリ機能を使って指標を集計しLooker Studioを使って可視化しているという状態でした。そのため以下の問題が生じていました。 クエリとダッシュボードの管理が属人化している クエリをGit管理できていないので、変更履歴を追跡できない レビュープロセスが十分でないため、品質が担保されていない 同じ意味を持つ指標でも集計定義が異なり混乱する どのダッシュボードを参考にすべきか混乱する 5. 施策ごとに新しいダッシュボードを作り直す必要がある 従来の運用では、A/Bテストごとにモニタリング指標に関するテーブルを作成し、そのテーブルを用いてLooker Studioで指標の紐付けやグラフ化を行い、ダッシュボードを新規作成していました。しかし、テーブルとLooker Studioを連携させる際、施策ごとにアドホックなクエリを記述していたため、バグ混入のリスクがありました。さらに、A/Bテストの件数増加に伴い、作成されるテーブルやダッシュボードの数も増加し、管理が非常に煩雑になるという課題も生じていました。 6. システム改修漏れが発生する A/Bテストに関するシステム改修には、ユーザー振り分けシステムの改修やテスト集計用の改修およびダッシュボード作成、結果を保存するための改修などの様々な作業が必要になります。しかし、これらの作業手順の標準化をしていなかったため、設定漏れや改修漏れの発生により、結果として意図したA/Bテストを実施できないケースが確認されていました。 解決策 これらの課題を解決するために、以下の解決策を採用しました。 1. A/Bテスト設計書のテンプレートを作成 A/Bテスト設計書のテンプレートとして、表形式で必要な項目を記入するだけで設計が完了する資料を作成しました。このテンプレートは、A/Bテストのシステム改修内容を除いた、テスト実施に必要なすべての情報を網羅しているため、設計時に必要な情報を一目で確認できます。具体的には、以下のような項目が含まれています。 - 概要 - 目的 - テスト内容 - UXの改善の仮説 - A/Bテスト設定 - A/Bテスト期間 - 対象の出面 - 対象デバイス - テスト対象ユーザーの割合 - 対象ユーザーの振り分け方法 - 分析対象のユーザー - 改善案 - テストパターン - モニタリング指標 - 意思決定方法 - A/Bテスト関係者へのアナウンス（設計後のアナウンス用） また本資料では項目ごとに詳細な記入例を記載しており、テンプレート利用者の解釈の差異を無くし、記入内容の統一化を図っています。例えばモニタリング指標の項目ではあえて55個もの指標を網羅的に記載しており、実際の記載時には必要な指標のみ残すようにしています。こうすることで、必要な指標が抜け落ちるリスクを確実に回避できるようにしています。 以下に、テンプレートの内容をイメージしていただくための一部を示します。 2. A/Bテストの開催期間の自動見積もり A/Bテストの期間見積もりプロセスを整備・自動化しました。このプロセスは、有意差を検出したい各指標について、以下の3つのステップに基づいてテスト期間を算出することで、A/Bテスト期間を見積もります。 1週間あたりのサンプルサイズの計測 有意差検定に必要なサンプルサイズの算出 A/Bテスト期間の見積もりと調整 1. 1週間あたりのサンプルサイズの計測 まず、過去のユーザーの行動ログをもとに、テスト期間中のユニークユーザー数を大まかに見積もります。これにより、1週間あたりのユニークユーザー数が把握でき、必要なサンプルサイズが何週間分に相当するかの概算が可能となります。私たちのブロックでは、他のA/Bテストとのスケジュール調整が円滑にできる4週間をテスト期間の上限として運用しています。そのため、4週間分のユニークユーザー数の合計を4で割って1週間あたりの数値を算出します。ただし、同じユーザーの複数回の訪問が多いため、初週や2週目の予測値は実測値よりも低くなる傾向があります。その結果、必要なサンプルサイズを過小に見積もってしまい、有意差を検出するのに十分なサンプルサイズを確保できないリスクが生じます。これを回避するため、予測値が実測値より低い状況を前提に見積もりを算出します。 2. 有意差検定に必要なサンプルサイズの算出 私たちのチームでは、A/Bテストでリリース判断を行うには、実際の施策が単なる偶然の結果ではなく、統計的に有意な効果をもたらしているかどうかの確認をしています。MDEは、リリースに必要な最低限の効果量を示すものです。このMDEが統計的に有意であるかどうかが、最終的なリリース判断の根拠となります。しかし、施策ごとに影響を及ぼす範囲や期待される効果量は異なります。そのため、あらかじめ正確なMDEを設定するのは難しいです。そこで、現状では過去に実施したA/Bテストの中から、施策内容や規模が類似している事例を参考にして、適切なMDEを見積もる方法を採用しています。これにより、施策ごとに「どれくらいの効果があればリリースすべきか」という判断基準を示すことができます。ここで見積もったMDEをもとに、統計的に有意な効果を検出するために必要なサンプルサイズを算出します。 必要サンプルサイズ は以下のように計算できます。 ：有意水準 ：検出力（Power） ：検出したい差（実際は、MDE * 平均値で計算している） ：分散 任意の期間におけるユニークユーザー数が、このサンプルサイズ より大きい場合、その期間内でMDEを検出するために必要なサンプルサイズが十分に確保されていると言えます。 3. A/Bテスト期間の見積もりと調整 手順1で求めた1週間あたりのユニークユーザー数と、手順2で計算されたサンプルサイズを比較して、テスト期間を見積もります。具体的には、まず有意差を検出したい全ての指標について手順2を実施し、その中で最も大きなサンプルサイズを採用します。ここで最も大きなサンプルサイズを選択する理由は、全ての指標に対して有意差を検出するために必要なサンプルサイズを確保するためです。次に、手順1で算出された1週間あたりのユニークユーザー数を使用して、最大サンプルサイズをまかなうために必要な週数を計算します。これにより、各指標で必要なサンプルサイズがテスト期間内に十分集まるかどうかを判断します。 ただし、実際のユニークユーザー数に対し、手順2で求められる必要サンプルサイズが非常に大きくなる場合があります。特に、MDEが小さい施策では、有意差検定に必要なサンプルサイズが急激に増加する傾向があります。このような状況を踏まえ、運用上はA/Bテスト期間にあらかじめ下限と上限の日数を設定しています。推薦基盤では、下限を2週間、上限は「1. 1週間あたりのサンプルサイズの計測」で言及した4週間としています。下限が2週間である理由は、曜日ごとのユーザーの行動パターンの違いを捉えたり、プロモーションやイベントがA/Bテスト期間と重なる可能性を考慮したりするためです。もし手順2で求めたサンプルサイズが、手順1で見積もった期間内に集まらない場合、その旨をリリース判定者へ伝え、指標を相対的な基準に基づいた判断を促す運用としています。 自動的なA/Bテスト期間の見積もり ここまでに示したA/Bテスト期間見積もりのプロセスをコード化しました。 その結果、施策者はMDEや各指標の分析対象ユーザー数を求めるクエリの記載のみ行えば、自動的にテスト期間の見積もりが得られる運用体制になりました。これにより、施策者の負担が低い状態で統計的に有意な効果を検出するためのサンプルサイズを算出でき、効率的なA/Bテスト期間見積もりとA/Bテスト期間の短縮を実現しました。 from scipy.stats import norm import numpy as np import pandas as pd # 有意差検定に必要なサンプルサイズの算出 def sample_size_for_mde ( s: pd.Series, mde: float , alpha: float = 0.05 , beta: float = 0.2 ) -> float : variance = np.var(s, ddof= 1 ) z_alpha = norm.ppf( 1 - alpha / 2 ) z_beta = norm.ppf( 1 - beta) average_value = np.mean(s) diff_value = average_value * mde sample_n = 2 * variance * (z_alpha + z_beta) ** 2 / diff_value** 2 return sample_n 3. 有意差検定の自動化 過去に以下の記事でも取り上げましたが、KPIをモニタリングする文脈で私たちのチームではKPIの集計にVertex AI Pipelinesを活用したパイプラインを構築している最中でした。このパイプラインは、BigQueryからデータを取得し、データの前処理、特徴量エンジニアリング、モデルの学習、評価、デプロイまでの一連の処理を自動化しています。 techblog.zozo.com 今回の改修では上記のパイプラインに対し自動的に有意差検定をし、結果をBigQueryに保存する処理を追加しました。 これにより、ノートブックの手動実行の必要がなくなり有意差検定の自動化が実現しました。 4. 集計定義とダッシュボードの統一 これまでGit管理されていなかったクエリをGitHubリポジトリで一元管理しました。さらに、上記で説明した通りに、KPIの集計をVertex AI Pipelinesで統一し、ダッシュボードはLooker Studioに統一しました。 上記の取り組みによって、以下のような効果が得られました。 クエリとダッシュボード管理の属人化が解消された Git管理によって変更履歴の追跡が可能になった コードレビュープロセスを通じて品質を担保できるようになった 複数チームで指標の定義を一覧化できるようになった どのダッシュボードを参照すべきかが明確になった 5. ダッシュボードの再利用 まず、テーブル構造を標準化し、すべてのA/Bテストの指標データをひとつの統合テーブルに保存するように変更しました。この統合テーブルには、各A/Bテストの識別子としてA/Bテストのバケット名も保存されており、これがダッシュボード上での識別キーとして使用します。 この統合テーブルを用いてLooker Studioでダッシュボードを作成することで、各A/Bテストの結果をひとつの画面上で一元管理・表示できるようになりました。具体的には、Looker Studioのフィルタ機能を活用し、プルダウンメニューからA/Bテストバケット名を選択するだけで対象データが自動的にフィルタリングされ、指標の数値が切り替わります。 この変更により、新しい施策のためにダッシュボードを再作成する必要がなくなり、過去に実施されたテストについても、簡単に結果を確認できるようになりました。実際に作成されたダッシュボードは、以下の画像に示されている通り、直感的な操作でA/Bテストの成果を確認できる仕組みとなっています。 6. システム改修の手順書の作成 A/Bテストシステム改修内容のテンプレートとして、改修項目、改修内容、担当者、ステータス、対応内容、という5つの項目で表形式に管理できる資料を作成しました。 資料には、改修の条件の記述から、具体的な改修内容、動作確認の方法、そして改修作業時に特に注意すべき点が詳細に記載されています。これにより、担当者は改修作業の背景や目的、手順、検証方法を明確に把握でき、漏れなく作業を実施することが可能となります。 このテンプレートを活用することで、システム改修漏れのリスクを低減し、担当者、進捗、対応状況の情報を一元的に記入・管理できる環境が整いました。その結果、事前調査や過去施策の検索にかかる工数が削減され、誰でも迅速かつ正確に改修作業を進められるようになりました。また、レビュアーや関係者は、1つの資料で全ての改修作業とその進捗状況を包括的に把握できるため、進捗の透明性が向上しました。 課題と解決策のまとめ 以下の表に、今回の取り組みで対処した課題と解決策をまとめます。 課題 解決策 1 A/Bテスト設計書のテンプレートがない A/Bテスト設計書のテンプレートを作成 2 A/Bテストの開催期間が決め打ち A/Bテストの開催期間の自動見積もり 3 有意差検定をするために手動運用が必要 有意差検定の自動化 4 チーム間で集計定義とダッシュボードが複数存在している 集計定義とダッシュボードの統一 5 施策ごとに新しいダッシュボードを作り直す必要がある ダッシュボードの再利用 6 システム改修漏れが発生する システム改修の手順書の作成 効果 これらの取り組みにより、以下の効果が得られました。 1. A/Bテスト設計開始から意思決定までの時間の削減 A/Bテストの設計から意思決定までの工程を標準化・自動化したことで、全体的な工数が大幅に削減されました。標準化後、はじめてのA/Bテストで工数を計測したところ、具体的には以下の改善が見られました。 工程 改善前 改善後 A/Bテスト設計 24h 8h ダッシュボード作成 16h 0h 有意差検定の実行と分析 2h 0h これらを合計すると、A/Bテスト1回あたり34hの工数削減を実現したことになります。 2. ヒューマンエラーの低減 標準化・自動化の取り組みにより、ヒューマンエラーのリスクが大幅に低減しました。 解決策 効果 A/Bテスト設計書のテンプレートを作成 必要項目の抜け漏れ防止 クエリの集計定義を一元管理 コードレビュープロセスを通した品質の向上 ダッシュボードの統一 指標解釈時の混乱の低減 システム改修の手順書の作成 システム改修漏れの防止 上記の取り組みによって、以前は年に数回発生していた集計ミスやシステム改修漏れの発生リスクを大幅に低減しました。 今後の展望 今回の取り組みにより、A/Bテストの効率化と標準化が進みましたが、まだ以下のような課題や今後の展望があります。 A/Bテスト体制の評価と改善 現在、A/Bテストの各工程にかかる工数や、問題が発生した工程を記録する仕組みがありません。ボトルネックを特定し、A/Bテストのサイクルを高速化するために、今後は各工程の工数、問題の発生率、発生原因を記録・分析できる仕組みを導入したいと考えています。 おわりに 本記事では、A/Bテストの設計から意思決定までの工程を標準化し、効率化を図った取り組みについてご紹介しました。標準化されたテンプレートの導入、有意差検定の自動化、ダッシュボードの統一など、様々な改善により、A/Bテストの実施工数の削減とヒューマンエラーのリスク低減を実現しました。 今後も継続的に改善し、より効率的かつ効果的なA/Bテストの実施体制を整えていきたいと考えています。 ZOZOでは一緒にサービスを作り上げてくれる方を募集しています。ご興味がある方は以下のリンクからぜひご応募ください！ corp.zozo.com

ZOZOTOWN開発本部でAndroidのテックリードをやっている いわたん です。最近はでっかいモンスターをハントするゲームにハマっており、夜な夜な一狩りしてます。 今回は、私たちのチームで行っている業務効率化の一例を紹介します。 背景・課題 解決方法 スクリーンショットをトリガーにしたフィードバック 必要な情報を自動的に収集する ログの収集 アプリ内情報の収集 課題を作成する機能 別アプリとして実装する フィードバック内容の取得 アクセストークンの管理 Activity破棄対応 実際に運用した結果 まとめ 背景・課題 私たちのチームでは、デザイナーやプロジェクトマネージャーによる動作確認のためにDeployGateとGoogle Play Consoleの内部テストを使用しています。また、QAチームによるテスト時の不具合や日々のタスク、プロジェクトマネージャーやデザイナーからのフィードバックの修正管理にJiraを利用しています。 しかし、現状のフィードバック収集プロセスには以下の課題がありました。 QAチームからの不具合チケットの起票 開発中のデバッグ情報やログイン状態などのアプリ内情報や、実行時のログ情報を添付するのに手間がかかる。 デザイナーやプロジェクトマネージャーからのフィードバック Slackでフィードバックを受けることが多く、情報が散逸しやすい。 Jiraに慣れていないメンバーにとって、課題起票や情報添付のハードルが高い。 これらの課題により、フィードバックの収集に時間がかかり、効率が低下していました。 解決方法 フィードバックの収集を効率化するために次の仕組みを構築しました。 フィードバックを手軽に送信できるようにする 必要な情報を自動的に収集する DeployGateからインストールしたときのみフィードバックを送信できるように、別アプリからフィードバックをする ZOZOTOWNアプリのスクリーンショットを撮影するとDeployGateのキャプチャ機能が起動する DeployGateのキャプチャ機能が完了するとDeployGateからZOZOTOWNアプリへコールバックが呼び出される ZOZOTOWNアプリがコールバック内でアプリの情報を自動で収集する ZOZOTOWNアプリとは別アプリとして実装されているフィードバック用アプリにIntent経由で収集した情報を渡して起動する フィードバック用アプリがIntentの内容をもとにJiraのIssueを作成する 次の章から具体的な実装方法を紹介します。 スクリーンショットをトリガーにしたフィードバック フィードバックを簡単に送信できるよう、アプリ内で明確なトリガーを設ける必要があります。本記事ではDeployGateの キャプチャ機能 を利用します。 キャプチャ機能はスクリーンショット撮影時に端末情報やLogcatを自動で収集し、DeployGate上に登録します。また、DeployGate SDKを利用することでキャプチャ完了時にアプリ内でコールバックを受け取ることができます。このコールバックを利用してフィードバックの送信処理を行います。 次に実装方法を紹介します。 まずはDeployGateのキャプチャ機能のコールバックを利用するためにバージョン4.9.0以降のDeployGate SDKをlibs.versions.tomlに追記します。 deploygate = "4.9.0" [ libraries ] deploygate = { group = "com.deploygate" , name = "sdk" , version.ref = "deploygate" } 続いて、app/build.gradleのdependenciesにDeployGateを追加します。 dependencies { implementation libs.deploygate } 続いてDeployGateのキャプチャ機能が完了した際にフィードバックを送信するため、キャプチャ機能が完了した際に呼び出されるコールバックをApplicationを継承しているクラスに追加します。 まずはコールバックの登録だけを行い、具体的なフィードバックの送信処理は後述します。 class App : Application() { override fun onCreate() { DeployGate.registerCaptureCreateCallback { url -> // TODO ここでフィードバックを送信する } } } 必要な情報を自動的に収集する 次に、フィードバックを送信する際に以下の情報を自動で収集する機能を実装します。これらの情報は、開発チームが問題を特定し修正するために必要な情報と、QAチームが課題を管理するために必要な情報を含んでいます。 アプリに関する情報 ログ アプリのバージョン 接続先の環境 ユーザー情報 ログイン済みかどうか ユーザー名 UUID 端末情報 端末名 OSバージョン ログの収集 まずは操作ログです。ストアに公開するReleaseビルドでは、パフォーマンス向上やセキュリティ対策のため、 Timber などのライブラリを使用してログの出力を抑制することが一般的です。しかし、QAにおいては詳細なログ情報が問題の原因究明に役立ちます。そこで、DeployGate経由でインストールされたReleaseビルドでのみログを出力できるように変更を加えます。 具体的には、DeployGate SDK 4.9.0で導入された DeployGate.registerStatusChangeCallback メソッドを利用します。このメソッドで登録したコールバックの第一引数は、アプリがDeployGateで管理されているかどうかを示すフラグです。このフラグを参照し、DeployGate経由でインストールされた場合にのみLogcatを有効化します。 class App : Application() { override fun onCreate() { DeployGate.registerStatusChangeCallback { isManaged, _, _, _ -> if (isManaged) { // ここでlogcatを有効にする Timber.plant(DebugTree()) } } } } アプリ内情報の収集 続いてアプリ内の情報を収集します。これらの必要な情報は開発しているアプリによって異なります。 ReportBuilder は、フィードバック情報を構築するためのインタフェースであり、build()メソッドによって情報を収集し、文字列形式で返します。このインタフェースを実装するクラスを複数利用することで、必要な情報を組み合わせたフィードバック内容を生成できます。 /** * フィードバック情報を作成するためのインターフェース */ fun interface ReportBuilder { /** * 必要な情報を収集してフィードバック情報として文字列を返す */ fun build(): String } 本記事では ReportBuilder を実装した、 BasicReportBuilder クラスと DebugReportBuilder クラスを用意しました。 BasicReportBuilder クラスは全てのBuild Variantで共通して必要なユーザー情報、アプリのバージョン、端末情報などを提供します。サンプルではイメージしやすいように UserRepository を仮で用意しています。 build()メソッドでこれらの情報をフォーマットし、フィードバック情報の文字列として返します。 /** * すべてのBuild Variantで収集したい情報を返す */ class BasicReportBuilder @Inject constructor ( private val userRepository: UserRepository, ) : ReportBuilder { override fun build(): String { val user = userRepository. get () val loginName = user.loginName val uid = user.uid val versionName = BuildConfig.VERSION_NAME val versionCode = BuildConfig.VERSION_CODE val buildVariant = BuildConfig.BUILD_TYPE return """ 【概要】 【再現手順】 【補足】 【確認アカウント】 loginName: $loginName uid: $uid 【アプリ情報】 Version: ${ versionName } ( ${ versionCode } ) Variant: $buildVariant 【端末情報】 Build.VERSION.SDK_INT: ${ Build.VERSION.SDK_INT } Build.VERSION.BASE_OS: ${ Build.VERSION.BASE_OS } Build.VERSION.RELEASE: ${ Build.VERSION.RELEASE } Build.BRAND: ${ Build.BRAND } Build.DEVICE: ${ Build.DEVICE } Build.MODEL: ${ Build.MODEL } Build.PRODUCT: ${ Build.PRODUCT } """ .trimIndent() } } DebugReportBuilder クラスはDebugビルド時にのみ必要な情報、たとえばデバッグメニューの状態や設定を提供します。これらはアプリによって異なりますのでサンプルは仮のクラスを用意しています。 これら以外にもBuild Variantによって収集する情報が変わる場合はそれぞれ必要な情報を集める ReportBuilder クラスを実装します。 /** * Debugビルド時に収集したい情報を返す * @param DebugOption デバッグ時の情報を保持するオブジェクト */ class DebugReportBuilder( private val debugOption: DebugOption ) : ReportBuilder { override fun build(): String { return """ 【デバッグ情報】 ${ debugOption } """ .trimIndent() } } Reporter クラスは ReportBuilder を使って複数のフィードバック情報を結合し、それをIntentのエクストラとして追加する役割を担います。builderリストには複数の ReportBuilder が含まれ、それぞれのbuildメソッドの結果を結合し、1つのフィードバック情報として出力します。 /** * [other]で指定されたReportBuilderを後に続けて結合する */ fun ReportBuilder.compose(other: ReportBuilder): ReportBuilder { return ReportBuilder { build() + other.build() } } class Reporter( private val builder: List <ReportBuilder> ) { /** * フィードバック用アプリを起動するIntentを作成する */ fun createReportIntent( additionalBuilder: ReportBuilder, ): Intent { return Intent( "com.example.report" , ).apply { flags = Intent.FLAG_ACTIVITY_NEW_TASK // すべてのReportBuilderを結合 val composedReportBuilder = builder.fold(additionalBuilder) { acc, reportBuilder -> acc.compose(reportBuilder) } // レポートをIntentに追加 val description = composedReportBuilder.build() putExtra(Intent.EXTRA_TEXT, description) } } } これらのクラスはHiltによる依存性注入でBuild Variantごとに異なるReporterのインスタンスを提供しています。 Debugビルド時のHiltのModuleは次のようにDebug関連の情報を集める RepoterBuilder を使用します。 @InstallIn (SingletonComponent :: class ) @Module object ReporterModule { @Provides fun provideReporter( userRepository: UserRepository, debugMenu: DebugMenu, ): Reporter { return Reporter( versionName = BuildConfig.VERSION_NAME, builder = listOf( BasicReportBuilder(userRepository), DebugReportBuilder(debugMenu), ), ) } } Releaseビルド時のHiltのModuleは次のように最低限の情報を集める RepoterBuilder を使用します。 @InstallIn (SingletonComponent :: class ) @Module object ReporterModule { @Provides fun provideReporter( userRepository: UserRepository, ): Reporter { return Reporter( versionName = BuildConfig.VERSION_NAME, builder = listOf( BasicReportBuilder(userRepository), ), ) } } DeployGateのキャプチャ機能が完了した際のコールバックで、作成したIntentを利用してフィードバック送信用アプリを起動します。 class App : Application() { @Inject lateinit var reporter: Reporter override fun onCreate() { // DeployGate経由でインストール時にログを有効化する DeployGate.registerStatusChangeCallback { isManaged, _, _, _ -> if (isManaged) { // ここでlogcatを有効にする Timber.plant(DebugTree()) } } // DeployGateにスクリーンショットを保存した際にフィードバックを作成する DeployGate.registerCaptureCreateCallback { captureUrl, _ -> val intent = reporter.createReportIntent { """ 【スクリーンショット】 $captureUrl """ .trimIndent() } startActivity(intent) } } } 課題を作成する機能 私たちのチームではJiraで課題管理していますが、課題を作成する実装を変更することで別の課題管理ツールを使用している場合でも応用が効くと思います。 課題を作成する機能の実装部分はチームごとで必要な実装が異なるため、本記事は他チームでも参考になりそうな部分を紹介します。 別アプリとして実装する フィードバック機能は、JiraのAPIトークンや開発用の課題管理ツールのURL等の機密情報や、ログ取得・内部状態の出力等のデバッグ機能を含みます。これらの情報は、セキュリティやアプリのパフォーマンス、ユーザーエクスペリエンスの観点から、ストアに公開するReleaseビルドには含めるべきではありません。 そのため、Jiraへの課題作成は開発中のアプリとは別アプリとして実装します。 フィードバック内容の取得 Reporter で作成したIntentで ReportActivity を起動するようにAndroidManifest.xmlを設定します。 <? xml version = "1.0" encoding = "utf-8" ?> <manifest xmlns : android = "http://schemas.android.com/apk/res/android" > <application android : label = "フィードバック送信" > <activity android : name = "com.example.ReportActivity" android : windowSoftInputMode = "adjustResize" android : theme = "@style/Theme.Design.NoActionBar" android : exported = "true" > <intent-filter android : label = "@string/report_create" > <action android : name = "com.example.report" /> <category android : name = "android.intent.category.DEFAULT" /> </intent-filter> </activity> </application> </manifest> Intentからフィードバック内容を取得し、descriptionに格納しています。このdescriptionを各チームに合わせてAPI等を呼び出してフィードバックの課題を作成します。 class ReportActivity : ComponentActivity() { // フィードバック内容 val description = intent.getStringExtra(Intent.EXTRA_TEXT) ?: "" } アクセストークンの管理 JiraのアクセストークンやHostの情報はGit上で直接管理するのはセキュリティ上の懸念があります。そこで、環境変数からBuildConfigへ登録できるよう、次のようにbuild.gradle.ktsに設定を追加します。 // 必要な部分のみ抜粋 android { defaultConfig { buildConfigField( "String" , "JIRA_TOKEN" , " \" ${ System.getenv( "JIRA_TOKEN" ) } \" " ) buildConfigField( "String" , "JIRA_HOST" , " \" ${ System.getenv( "JIRA_HOST" ) } \" " ) } } そして、フィードバックを入力して送信するためのActivityでBuildConfigから情報を取得します。 class ReportActivity : ComponentActivity() { private val jiraHost: String get () { // build.gradleの設定経由でJIRA_HOSTで定義された環境変数を取得している val env = BuildConfig.JIRA_HOST require(env.isNotEmpty()) { "環境変数JIRA_HOSTが空文字でビルドされています" } require(env != "null" ) { "環境変数JIRA_HOSTが未定義でビルドされています" } return env } private val jiraToken: String get () { // build.gradleの設定経由でJIRA_TOKENで定義された環境変数を取得している val env = BuildConfig.JIRA_TOKEN require(env.isNotEmpty()) { "環境変数JIRA_TOKENが空文字でビルドされています" } require(env != "null" ) { "環境変数JIRA_TOKENが未定義でビルドされています" } return env } } Activity破棄対応 QA期間中などに開発者向けオプションで、「アクティビティを保持しない」を有効にしているケースがあるかと思います。このオプションを有効にした状態で、フィードバック送信用アプリからQA対象のアプリを再度表示した等のタイミングでフィードバック内容が消えてしまう可能性があります。そのため、先述のReportActivityでは簡略化していましたが、rememberSaveableやonSaveInstanceState等でActivityの破棄に対応した実装が必要になります。 実際に運用した結果 実際にシステムの運用を開始し、現場での実証テストを通じて、QAチームから様々な意見が寄せられました。全体的に概ね好評であり、現場で感じた使いやすさや業務効率の向上についての具体的なフィードバックは以下の通りです。 ログをスクリーンショットと同時に用意できる点 QAチームはこれまで手動でログやスクリーンショット画像を用意し、必要に応じて添付していました。DeployGateのキャプチャ機能によって自動で同時に用意できるようになり、負担削減が好評でした。 各種情報の自動記録 ログイン状態、UID、アプリのバージョン、接続先環境、端末情報といった重要な情報が自動的に記録されるため、従来必要であった手作業が省略でき、入力ミスも防止できる点が便利だと好評でした。 Jiraの必須項目の自動記入 各種アプリ関連情報に加え、Jira上で必須となる担当者や影響を受けるバージョンなどの定型的な入力項目についても、自動で記入される仕組みが実装されています。これにより、手動での入力作業が省け、全体の作業負担が大幅に軽減される点が非常に有用であるとの評価を受けました。 特定画面での準必須情報の自動記録への期待 一方で、商品詳細画面における問い合わせ番号や検索結果画面での絞り込み条件など、頻繁に記載が求められる情報については機能拡張が欲しいという意見もありました。これらの情報はReporterの実装を工夫することで実現が可能と考えられるので今後追加する予定です。 まとめ 本記事ではDeployGateのキャプチャ機能を利用して、フィードバック用アプリ、そしてJiraとの連携を活用することで、従来プロセスの手作業や情報散逸の問題を解消しました。主なポイントは以下の通りです。 自動化による効率化 スクリーンショット撮影をトリガーに、ログやアプリ・ユーザー、端末情報などの必要情報を自動で収集し、手動での情報添付やPCへのデータ転送の手間を削減しました。 安全かつ柔軟な設計 機密性の高いJiraのAPIトークンやデバッグ情報は別のフィードバック用アプリで管理し、環境変数を利用することでセキュリティ面も考慮しています。 現場からの好評と今後の展開 QAチームや関係者からは、ログとスクリーンショットの同時送信による効率向上や、Jiraの必須項目の自動入力による入力ミス防止が高く評価されています。さらに、特定画面で必須情報の自動記録など、さらなる機能拡張が期待されています。 このシステムにより、開発・テスト・運用の各フェーズでのフィードバック対応がスムーズになり、結果として業務全体の効率化と品質向上が実現されました。今後は、さらなる改善と機能追加を通じて、より充実したフィードバック環境の構築を目指していきます。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

はじめに こんにちは。計測プラットフォーム開発本部で研究開発をしている 皆川 です。2024年の10月にスイスで2日間に渡って開催された3DBODY.TECHに、同部署でプロジェクトマネジメントをしている嶺村と二人で参加しました。カンファレンスの開催から少し時間が経ってしまいましたが、参加レポートをお届けします。 目次 はじめに 目次 3DBODY.TECHとは？ 日本からルガーノへの行き方 ルガーノという街 ZOZOとの関わり カンファレンスの特色 新しいレビュー方式 特に印象に残った発表 “Advancements in Body Composition Assessment using Mobile Devices” プレゼンテーション概要 精度検証のプロセス 検証結果 感想 “3D Bodyscan in Professional Sports: Practical Use Cases in Prevention, Bodytracking and Rehabilitation” プレゼンテーション概要 ユースケース1：脚長さの左右差のデータを活用したケガの予防 ユースケース2：計測結果のトラッキング ユースケース3：ケガのリハビリへの活用 感想 ”Learning to Predict Anthropometric Landmarks via Feature Refinement” by Yibo Jiao, University of British Columbia 背景 方法 結果 感想 ”From Smartphone 3D Scanning to Body Measurements Extraction” by Olivier SAURER, Astrivis Technologies 汎用性の高いSDK 顔のスキャンとその精度 足のスキャンとその精度 感想 ”Fast and Accurate 3D Foot Reconstruction from a Single Image” by Joaquin SANCHIZ, IBV 概要 方法 結果 感想 さいごに 3DBODY.TECHとは？ 毎年10月に開催される人体計測に関する国際カンファレンスです。最近はほぼ毎年スイスのルガーノで開催されていますが、2017年にはカナダのモントリオールでも開催されています。正式名称は 「3DBODY.TECH Conference & Expo」 で、今回は15回目の開催でした。 公式発表 によると、参加者は200名（うちオンラインが20％）、発表は80件、さらに20の企業が展示したとのことです。会場はティチーノ州ルガーノにある「ルガーノ国際会議場（Palazzo dei Congressi Lugano）」です。 ルガーノ国際会議場の外観。 日本からルガーノへの行き方 日本からスイスへ行く場合、成田空港からチューリッヒ空港への直行便がスイス航空から出ています（執筆時点）。チューリッヒからルガーノへはスイス鉄道に乗って約2時間。2016年にできた世界最長のトンネルであるゴッタルド基底トンネルのおかげで、スイスの他の地域で乗る山間を縫うような山岳鉄道と比べて乗り心地がとても良いです。成田からチューリッヒまでの約14時間にわたる空路は大変ですが、チューリッヒからは快適な旅が期待できます。 チューリッヒ駅のホームの様子。 チューリッヒからルガーノへ向かう途中の車窓からの風景。 ルガーノ駅の様子。 ルガーノという街 ルガーノはイタリア語圏であるティチーノ州に位置し、その街並みもどこかイタリアっぽさが感じられます。住民はみなイタリア語で会話し、図書館や本屋はイタリア語の本であふれ、街はジェラート屋やイタリア料理屋で溢れています。住民の雰囲気もドイツ語圏のチューリッヒやダボスとは大きく異なります。英語はときどき通じない方がいるので、簡単な日常会話はイタリア語でできるようにしておいた方が良いかもしれません。この点は英語だけで安心して歩けるチューリッヒと比べると大きな違いです。 ルガーノ駅付近から観た市街地の様子。 ルガーノ市街の中心地。手前に見えるのはジェラート屋。 ルガーノ湖周辺エリア。ルガーノ駅から徒歩十分ほど。 ZOZOとの関わり ZOZOはコロナ禍を含めこのカンファレンスに頻繁に参加、発表してきました。2020年にはZOZO New Zealand Ltd.（以降ZOZO NZ）のCTOであるBoがZOZOSUITやZOZOMATの技術的側面について 発表 しています。2022年には同じくZOZO NZのEugeneがZOZOMATのサイズ推奨アルゴリズム開発時の技術的課題について 発表 しています。また同年に計測プラットフォーム開発本部の本部長（執筆時点）の山田がZOZOの計測事業の歴史と今後について 発表 しています。同年には展示ブースでZOZOSUIT、ZOZOMAT、ZOZOGLASSの展示も行っています（ その様子 ）。 今回は2020年から数えて5年連続での参加となりました。そのためかZOZOを認知している他の参加者から様々な場面で話しかけられることが多かったように感じます。 カンファレンスの特色 3DBODY.TECHは、全発表の3割以上がアパレル分野での計測技術の応用をテーマにしており、その点で他に類を見ないカンファレンスとなっています。 アパレル分野では、いかに正確に身体を3Dスキャンして計測するかというテーマ以上に計測結果をどう活かすかというテーマが多かったように感じます。具体的に以下がテーマとして多かったです。 身体にフィットしたアパレルのサイズ推奨やアパレルのデザイン 着用した際の見た目を再現できる、実際のサイズを反映した（size awareな）アパレルのバーチャル試着（Virtual Try-On） アパレルのサイズ推奨やデザインは事例が多くサービス化が着実に進んでいる一方で、実際の服のサイズを反映したバーチャル試着はまだ事例が少なかったです。 メイン会場。ここで全体の半分にあたる発表が行われる。 Bodidata社のサイズ推奨デモ画面。主催者の許可を得て発表スライドより抜粋。なお、発表の動画は2025年の7~9月頃にカンファレンスの 抄録集 にアップロードされるとのことです(スライド自体へのアクセスは参加者のみ可能です)。 Alter Ego AI社のバーチャル試着デモ画面。画像では身長183センチ、体重75kgの男性がSサイズのTシャツを着用した様子を再現している。 公式HP より抜粋。 新しいレビュー方式 これまでは要旨のレビューをもって採択が決められ、受理された発表は全て抄録集（Proceedings。なお抄録とは学会発表をするときに提出する発表内容の要旨のこと）として発行、という形をとっていました。今回からは受理された発表のうち、内容のレビューを受けたものを新しく発行を開始する学会誌「 3DBODY.TECH Journal 」に載せる、という形をとっています。また、全体の発表の約3割にあたる27の発表が、学会誌に収録されています。 逆に言うと残りの約7割の発表は内容のレビューを受けておらず、その中には普通の研究発表のフォーマットとは大きく異なる発表もあり、最初は少し戸惑いました。例えば、発表の冒頭でその会社のプロダクトがいかにECアパレルにおけるサイズのずれという問題を解決するか雄弁に語っていながら、それを客観的に支持するデータがひとつも出てこない。あるいは彼らのプロダクトが身体計測の新しい、革新的な方法として紹介されたものの、具体的な手法の詳細や精度などの情報が発表中に出てこないなどです。 特に印象に残った発表 計測プロデュース部データ開発ブロックの嶺村です。 ここからはカンファレンス参加時に見た発表の中から、特に印象に残ったものについて紹介します。私から2本、皆川から3本の発表についてご紹介いたします。なお、論文として発行されているものは論文のURLを発表のタイトルに埋め込んでいます。またすべての発表は動画が 抄録集 にて2025年中に公開される予定です。 “Advancements in Body Composition Assessment using Mobile Devices” プレゼンテーション概要 私から紹介する1つ目の発表は、Size Stream社の体脂肪率および体脂肪量の計測精度について詳しく紹介したものです。 www.sizestream.com 同社から過去に販売されていたハードウェアを用いた3Dボディスキャナと、現在提供中のスマホアプリでの計測結果が比較され、後者も前者に匹敵する計測精度が出せていることが強調されていました。 Size Stream社はかつて、体脂肪を含む様々な指標の計測ができるブース型の3Dボディスキャナを販売していました。近年では、ブース型スキャナからモバイル端末での計測に力を入れており、MeThreeSixtyというスマートフォンアプリで身体計測サービスを提供しています。 www.methreesixty.com 精度検証のプロセス MeThreeSixtyアプリの計測精度を検証するために、Size Stream社はテキサス工科大学と共同で研究を行いました。118人の被検者から209のスキャンデータを収集し、同アプリの計測結果をベンチマークと比較した精度検証を実施しました。ベンチマークとしたのは、二重エネルギーX線吸収測定法、空気置換法および生体インピーダンス測定システムを組み合わせて計測した体脂肪の計測結果です。モバイルアプリでの計測結果をインプット、ベンチマークである体脂肪率や体脂肪量をアウトプットにし、回帰分析を行い、モバイルアプリの計測結果とベンチマークの計測結果との相関関係を明らかにしました。 検証結果 体脂肪率と体脂肪量の計測結果をプロットしたところ、モバイルアプリとベンチマークとの間に強い相関関係が見られました。95％区間での最大誤差は、体脂肪率においては±7.5％、体脂肪量においては±5kgに収まっていました。さらに、他社の体脂肪を計測可能な製品やSize Stream社のブース型の3Dボディスキャナとの計測精度の比較も行われました。結果として、Size Streamのモバイルアプリが他社のサービスと同等ないしより高い精度を持ち、自社のボディスキャナに匹敵する精度となる結果だったことが説明されました。 感想 こちらの発表では、検証内容やその結果が詳細に紹介されており、情報量が非常に豊富で密度が濃い印象を受けました。検証のために集めたデータ量の規模や、ベンチマークとの比較誤差についても具体的に明示されていたため、Size Stream社のプロダクトの計測精度を明確に理解できる発表でした。ヒップの周囲長などのシンプルな寸法値とは異なり、体脂肪量・体脂肪率は人体の3Dモデル生成だけでは計測が難しいです。そのため、それを計算するアルゴリズムが必要となりますが、その計算式の中身についても具体的な言及がありました。ZOZOFITでも体脂肪率の計測機能を提供しています。こちらの発表で触れられていた検証方法、アルゴリズムの内容や精度などの情報は、弊社内での開発や検証内容と比較してみたいと考えています。 “3D Bodyscan in Professional Sports: Practical Use Cases in Prevention, Bodytracking and Rehabilitation” プレゼンテーション概要 2本目にご紹介するのはVITRONIC社による発表です。 www.VITRONIC.com VITRONIC社は、ハードウェアを用いた3Dボディスキャナを販売しており、欧州のプロサッカーチームのメディカルチームに同社製品を提供しています。このプレゼンテーションでは、同社の3Dスキャナの計測データがスポーツの現場でどのように活用されているかについて説明されました。具体的な活用事例として、発表の中では3つのユースケースが紹介されました。 ユースケース1：脚長さの左右差のデータを活用したケガの予防 発表の中では、両脚の長さの左右差が9mm以上あると腰椎に影響を及ぼす可能性のあることが説明されました。脚長さに左右差があることで腰の脊椎周辺の姿勢に影響が出てしまい、その結果として腰回りの不調につながることがあります。IFD cologne（ドイツのスポーツ整形外科病院）に通うサッカー選手をVITRONIC社の3Dボディスキャナで計測したところ、計測した選手のうち33％に9mm以上の左右差があったそうです。 ユースケース2：計測結果のトラッキング 姿勢のバランスの悪さは競技のパフォーマンス低下につながります。特に、若い選手の姿勢が身体的成長に伴ってどのように変化しているのかを把握することは重要です。成長やトレーニングに伴う姿勢変化を早期に捉えるため、VITRONIC社の3Dボディスキャナが活用されています。シーズン前に計測した結果をレファレンスとし、シーズンイン後、4〜8週間ごとにスキャンしシーズン前の結果と比較することで姿勢の変化を継続的に確認しています。 ユースケース3：ケガのリハビリへの活用 前十字靭帯の損傷はプレイ中にしばしば発生するケガのひとつです。前十字靭帯のケガのリハビリにおいても計測データが活用されています。具体的には、リハビリを開始できるかどうかの判断をする際に上膝部分の周囲およびボリュームを確認しています。リハビリ開始後は、太ももと膝上部分の周囲長を確認することで、リハビリがどの程度完了しているかを把握しています。 感想 カンファレンス全体では計測の応用分野としてファッション・アパレル領域のものが多くを占めていましたが、こちらの発表は数少ないスポーツ分野での事例として非常に新鮮で勉強になりました。特に、各ユースケースの説明の中で、どの身体部位の計測結果をどのように利用するのかが具体的に解説されており、身体計測の活用の幅広さを改めて実感しました。任意の部位の計測結果から健康状態を把握し改善するという観点では、弊社でも ZOZOSUITを用いた側弯症検知 や リンパ浮腫四肢測定 の研究実績があり、これらの取り組みと類似していると感じました。ZOZOSUITやアプリのみの身体計測データを活用することで、弊社でも同様のサービスを提供できる可能性があると期待しています。 ”Learning to Predict Anthropometric Landmarks via Feature Refinement” by Yibo Jiao, University of British Columbia ここからは再び皆川が、印象に残った発表を3つご紹介します。 背景 基準点（landmark）とは、身体の部位の長さ計測の際に参照する解剖学的な点のことです。一般的には経験を積んだ専門家が1箇所ずつ触診によって検出していくため時間のかかるプロセスです。また、その精度は測定者のスキルに依存することも知られています。著者によると、人体表面のメッシュデータから基準点の検出を行うアルゴリズムは一部の基準点で精度が著しく低下するという問題があったそうです。この論文では、新しい損失関数を導入することによってSOTA、すなわち最高精度を達成しています。 誤差が生じやすい身体の基準点の例として、上前腸骨棘が挙げられています（論文中ではASISと呼ばれている。下記の画像を参照）。 上前腸骨棘（Anterior superior iliac spine、通称ASIS）の位置。緑の丸が触診による正解値。黄色の丸は以前のSOTA手法、赤の丸は提案手法によって推測された頂点。 本論文 の図1より引用。 方法 論文の中では、これまで取られてきたさまざまな方法の紹介とトレードオフについての議論があります。以下に要点をまとめました。 身体の基準点はラベリングのコストが高く、データセットがCAESARなど一部のものに限られていることが現状の教師あり学習の課題。 近年ではDeepShellsに始まる教師なし学習がSOTAを叩き出している。 近年2次元画像のキーポイント検出タスクで、ロバスト性と精度が示されてきたヒートマップベースのアプローチを採用した。 ヒートマップベースアプローチの中でも頻出手法であるガウス分布（ある一点を中心とした2次元のガウス分布）の回帰を採用しようとしたが、3Dメッシュへの回帰が技術的に難しく断念した。 なおヒートマップベースのアプローチとはターゲットの座標を直接予測するのではなく、ターゲットの確率分布を予測する方法のことです。 提示される方法では、この課題があると言われている教師あり学習を用い、SOTAを叩き出しています。以下に方法をまとめました。 学習時のパイプラインの全体図。 本論文 の図2より引用。 上図はモデル学習の全体図です。提案手法のゴールは、入力となるメッシュの各頂点で、その頂点がある特定の基準点である確率を算出することです。そのためにニューラルネットワークを学習させるのですが（上図のDiffusionNetに相当）、その学習のための損失関数として以下の2つの関数を提案しています。 基準点のポテンシャル（P）関数：対象の頂点（vertex）が基準点である確率を示す関数 相似関数（D）：対象の頂点が基準点からどれくらい離れているかを示す関数 相似関数Dはニューラルネットワークとは独立に、正解データである基準点と対象の頂点間の距離で決まります。一方でポテンシャル関数は入力であるメッシュの情報とそれを処理するニューラルネットワークの重みで決まります。基準点に近い頂点でポテンシャル関数が大きく反応するように学習したいので、学習時には相似関数とポテンシャル関数の相関係数が最大化するように学習させます。結果、基準点付近ではポテンシャル関数の低くなるような重みをニューラルネットワークが学習します。そして最もポテンシャルの低い点が予測点として出力されます。モデルの学習フェーズが終わると、ニューラルネットワークとポテンシャル関数だけを用い入力のメッシュに対して基準点の予測される頂点が出力されます。なお学習にはFAUSTデータセットから50サンプルを抽出して使用したと記述があります。 学習パイプラインの詳細や、関数PとDの相関最大化問題の緩和（relaxation）のための手法（核ノルムの導入）といった詳細な議論については論文を参照してください。 結果 提示される方法では、従来の方法に比べて大きな精度向上がみられています（下記の画像を参照）。また検証にはFAUSTデータセットおよびCAESARデータセットからそれぞれ50サンプルずつ使用したとあります（FAUSTは学習時に使われたデータは除外してあります）。 正解値（緑色）、従来のSOTAモデルであるDeep Shellsの出力（黄色）、提案されたモデルの出力（赤色）。なお、青いエリアは、頂点が基準点である確率を表すポテンシャル。 本論文 の図3より引用。 また、提案モデルは学習データに含まれていないポーズや3Dメッシュの欠損に対してもロバスト性を示しています（下図参照）。より細かい結果については論文を参照してください。 さまざまなポーズや部分的なメッシュの欠損があるときの提案モデルの出力。 本論文 の図4より引用。 感想 提案されたモデルは、 SMPL のようなパラメトリックメッシュではなく、生の3Dメッシュを入力として想定しているモデルです。本カンファレンスではブース型の3Dスキャナーも多数展示されており、それらから得られる高精度な生のメッシュを元に計測値を抽出する方法のニーズが高まっていることが伺えます。本研究はそのニーズを反映していると考えることもできそうです。 方法に関しては基準点検出でSOTAを達成した一方で、基準点ごとに異なるニューラルネットワークを学習させる必要がある点には注意が必要です。このために演算コストや実装コストが高くなりそうだと思いました。 身体の高精度なスキャンだけでは、必ずしもサイズ推奨やアパレルデザインといった用途に活かすことができません。場合によってはそこから腹囲や肩幅といった計測値の抽出が必要になることがあります。この研究は生のメッシュからの基準点の検出というタスクを、新しい学習機構を導入することで一歩進めています。また発表を聞いた感想としては、学習用のデータセットをスケールさせることでどこまでモデルのパフォーマンスが増加するか気になりました（もちろんそれには大きなコストがかかります）。 また現在、スマホを用いた身体計測アプリの主流は先述のパラメトリックメッシュを用いた方法のため、この研究のように生のメッシュを処理するタイプの研究はあまり関連性がないかもしれません。ただし今後、ブース型の3Dスキャナーを検討する際は押さえておきたい技術だと思いました。 ”From Smartphone 3D Scanning to Body Measurements Extraction” by Olivier SAURER, Astrivis Technologies 3Dスキャンを専門とするチューリッヒに本籍のあるAstrivis TechnologiesのSDKについて、この分野で20年以上の経験があるというCTOのOliver Saurer氏が発表しています。 汎用性の高いSDK Astrivis Technologiesが提供するSDKは3DスキャンのソフトウェアにフォーカスしたSDKであり、LiDARやFaceIDといった特殊なハードウェアを必須としません。またiOSやAndroidだけでなく、Windows等のPC上でも動作するとのことです。 顔のスキャンとその精度 計測方法は一般的なスマホの3Dスキャンアプリと同様です。計測対象が満遍なく映るようにスマホを動かして顔をスキャンしていきます。スキャンはおよそ10秒くらいあれば完了するそうです。 計測の様子。発表中のスライドより抜粋(カンファレンス主催者の了承を得て掲載。以降のスライドも同様)。なお、発表の動画は2025年の7~9月頃にカンファレンスの 抄録集 にアップロードされるとのことです(スライド自体へのアクセスは参加者のみ可能です)。 スキャン完了後、処理時間として10秒ほど待つと顔の3D再構成が完了します。得られた3Dメッシュは専用の高額な3Dスキャナーと比較した場合ほぼ1mm以下の誤差に収まっています。 3DハンドスキャナーArtec Eva HDと比較した誤差(メッシュ間の距離をヒートマップとして表示)。 足のスキャンとその精度 足も顔と同様のプロセスでスキャンが可能です。 フットスキャンの様子。 スキャン後、計測値を自動で抽出する機能もあります。発表中に明言はされていませんでしたが、3Dスキャンで得られた生のメッシュから不要なメッシュを除去し、足のメッシュを取得し、そこに計測抽出アルゴリズムを適用しているようでした。テンプレートメッシュを使用したかどうかや、計測抽出アルゴリズムがルールベースのものかAIを使用しているか等、技術的な詳細はほとんど触れられていませんでした。なお計測箇所は下図の画像の通りです。 スキャンされた3Dメッシュから自動で計測値を抽出する機能。 以下の画像は、上記の足の計測値（足の長さやかかとの幅）についての結果です。計156回の計測の結果のうち、ほとんどの試行で誤差がほぼ2mm以下に収まっています。ただし、結果は3Dプリントされた足型を用いているとスライド上部に記載があり、注意が必要です。 156回の試行における計測値の誤差の分布。 また以下の画像は、計測値の信頼性（繰り返し同じものを計測した際にどれくらい試行間で誤差があるか）についての結果です。37回の試行に関して、誤差が3mmくらいの範囲内に収まっています。なお、先ほどの結果は3Dプリントされた足に対してのデータでしたが、こちらは実際の足に対しての計測結果のようです。発表中はこの点が強調されておらず、ここは聴衆に誤解を与えかねないと思いました。 繰り返し計測した際の計測値の分布。 感想 筆者は発表を聞いて、長さ参照物なしで誤差2mm以下の精度が達成されていると解釈しました。この2mm以下という誤差は、長さ参照物なしの計測精度だとすれば驚くべき精度です（注：2mmは3D身体計測の国際規格であるISO 20685における、足計測の互換性に関わる許容誤差です。詳しくは ”Anthropometry, Apparel Sizing and Design” edited by Norsaadah Zakaria, Deepti Gupta” のp.41を参照してください）。しかし本発表では、計測方法についての詳細は省かれているため、必ずしも長さ参照物なしとは断言できないことに注意が必要です。この発表はJournal用の発表枠ではなかったため、技術詳細や精度計測方法について曖昧な点がいくつか残る発表でした。今後同社から更なる情報が公開されることを期待します。 現状、スマートフォンを用いた計測では物理参照物を使わない場合、スケール推定がボトルネックになり計測精度が落ちてしまいます。この精度の低下が足のサイズ推定にはクリティカルになるらしく、スマホを用いた足の計測アプリは現状なんらかの物理参照物を要しています（A4の紙やZOZOMATなど）。この物理参照物が必要なくなれば計測に対するユーザーの敷居は大きく下がると思うので、今後も本発表のような関連ある研究を注視していきたいと思います。 ”Fast and Accurate 3D Foot Reconstruction from a Single Image” by Joaquin SANCHIZ, IBV 概要 従来の足の3Dスキャンは画像が複数枚必要だったり、演算に時間のかかったりするものが多いですが、この手法では1枚の画像からほぼリアルタイムに高精度な形状の推論が可能になっています。従来のスマホを使った足の3Dスキャンの簡易化や短時間化が狙えるほか、靴のバーチャル試着にも応用が可能です。 方法 モデルの詳細や学習方法について論文中に詳細な記載はなく、概要のみ説明されています（下図参照）。モデルはエンコーダー・デコーダー型です。エンコーダーの2つの出力ヘッドでセグメンテーション情報（バイナリーマスク）と9つの基準点の位置情報を出力します。またデコーダーは足のパラメトリックモデルの形状パラメーターと位置、角度情報を出力します。 モデル学習の全体図。 本論文 の図1より引用。 また学習に用いたデータセットに関しても学習方法と同様、概要のみ記載されています。IBVの所有するAvatar 3D Feetデータセットを増分処理をしたものが50万セット（増分処理前のサンプル数に関しては記載なし）。IBV所有の足のパラメトリックモデルを用いて合成したデータセットが100万セット。どちらのデータセットも付加情報として、カメラパラメーター、基準点の3次元位置情報、セグメンテーション情報、PCAの形状パラメーター等がそれぞれの画像とセットになっています。 Avatar 3D Feetデータセットの一例。画像中に写っているA4紙はカメラのキャリブレーションに用いる。 本論文 の図2より引用。 結果 評価には先述のAvatar 3D Feetデータセットから674サンプルを抽出して、正解データとモデルの出力のメッシュ間距離を算出し、評価しています。下図は誤差の平均を可視化したものです。平均の誤差が0.9mmであり、高い精度で足の形状が推定できている事がわかります。論文中には明記されていませんが、3D Avatar FeetデータセットはA4紙という長さの参照物が含まれていることに注意が必要です。 評価データ（n=674）における平均誤差をヒートマップで表現したもの。単位はmm。 本論文 の図4より引用。 下図は3つの実装パターンにおける推論時間です。組み合わせが包括的でないため特定の結論を導くことは難しいですが、およそリアルタイムに動かせるくらいの速度で推論できている事がわかります。 演算装置、およびモデルタイプごとの推論時間の変化。 本論文 の表2より引用。 感想 論文は全体として明瞭に書かれていて学ぶことが多かった一方で、この研究の要となる3D Avatar Feetデータセットが公開されていないのは少し残念でした。また未公開のデータセットを使用していることの欠点として客観的な性能評価や他のモデルとの性能比較の難しい点があります。 ただし足の計測がリアルタイムでかつ高精度に行えている点は目を見張るものがあります。従来、計測目的でテンプレートメッシュを使う際は、時間がかかるが高精度の出やすい最適化手法を使うのが通例だと思います。しかしこの研究は、最適化手法より一般に高速と言われている回帰手法でも、高精度な足の計測が可能であることを示唆しています。今後、ZOZOMATやZOZOSUIT等の計測プロセスの簡易化にも活かせそうな研究だと感じました。また本研究は、靴のバーチャル試着に関しても今後の進化が期待できるような内容でした。 さいごに 昨年10月にスイスで開催された身体計測のカンファレンス3DBODY.TECHについて参加レポートをお届けしました。このレポートではほんの一部しかご紹介できませんでしたが、計測技術の進化を感じることができる刺激的なカンファレンスでした。また今回で15回目の開催ですが、ジャーナルの発行開始やレビュープロセスの変化など、カンファレンス自体の進化も感じることができました。今後もZOZOの既存の計測プロダクトの進化や新規のサービスにつながるような研究を求め、3DBODY.TECHを注視していこうと思います。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com