.table-of-contents ul ul { display: none; } .images-row { width: 860px !important; } こんにちは、技術戦略部のikkouです。2025年6月17、18日の2日間にわたり「 KubeCon + CloudNativeCon Japan 2025 」がヒルトン東京お台場で開催されました。ZOZOは今回シルバースポンサーとして協賛し、スポンサーブースを出展しました。 technote.zozo.com 本記事では、前半はZOZOのエンジニアが気になったセッションを紹介します。そして後半はZOZOの協賛ブースの様子と各社のブースコーデのまとめを写真多めでお伝えします。 KubeCon + CloudNativeConとは ZOZOエンジニアの気になったセッションの紹介 Kubernetes SIG Node Intro and Deep Dive Platform Engineering Day 2: Why Service Iterations Are the Crux of Developer Platforms Internal Developer Platform（IDP） Golden Path Day 2 Best Practices Japan Community Day Doc Sprint参加レポート Japan Community Dayとは Doc Sprintの概要 当日の作業フロー 得られた学び 翻訳ガイドラインの理解と運用 コントリビューションの可視化とモチベーション コントリビューターロールの明確化 その他 まとめ Exploring Tenant-centric Strategies To Simplify Multi-cluster and Multi-cloud Complexities Infra / Platform Team目線 End use 目線 Cloud Native Scalability for Internal Developer Platforms セッション概要 1. Internal Developer Platform(IDP)の全体像 2. スケーラビリティの旅と直面した壁 (Scalability Journey in Our Internal Developer Platform) 2-1. クラスタ設計：Single vs Multi 2-2. オペレーショナルスケーラビリティ 2-3. カスタムコントローラ性能 3. いま直面している3つのControl Planeの課題 おわりに ZOZOブースの紹介 ZOZOTOWNのアーキテクチャ OSS デモ 協賛企業ブースのコーデまとめ おわりに KubeCon + CloudNativeConとは KubeCon + CloudNativeConは、ZOZOでも利用しているKubernetesをはじめとしたCloud Native Computing Foundation (CNCF)に関する技術を中心とした大規模カンファレンスです。これまではUSやEUなどで開催されていて、例年ZOZOのエンジニアも現地参加してきました。 KubeCon + CloudNativeCon Europe 2024 参加レポート - ZOZO TECH BLOG KubeCon + CloudNativeCon Europe 2023 参加レポート - ZOZO TECH BLOG KubeCon + CloudNativeCon North America 2022参加レポート〜3年ぶりのアメリカ現地開催の様子とセッション紹介〜 - ZOZO TECH BLOG 今回は「KubeCon + CloudNativeCon Japan」として初めて日本で開催されました。初回から想定を上回る1,500人の参加者が集まり、チケットも売り切れになったそうです。 ZOZOエンジニアの気になったセッションの紹介 今回、ZOZOからは10名を超えるエンジニアが参加しました。代表して5名から、それぞれが気になったセッションを紹介します。 Kubernetes SIG Node Intro and Deep Dive こんにちは、MLOpsブロックの 木村 です。「 Kubernetes SIG Node Intro and Deep Dive 」セッション（登壇者：Narang Dixita Sohanlal 氏［Google］、Paco Xu 氏［DaoCloud］、椎名宏典 氏［Independent］）をご紹介します。 kccncjpn2025.sched.com このセッションでは、Kubernetesのノード周辺に関する最新機能についての発表が行われました。特に注目されていたのは、GPUのような特殊なリソースをPodやコンテナ間で柔軟にリクエスト・共有できるようにするための仕組みである Dynamic Resource Allocation (DRA) と、Podの再起動を伴わずにリソースの割り当てを変更可能とする機能 In-Place Pod Resize の2つです。どちらも、リソース使用量が変動しやすいワークロードを効率的に運用するうえで非常に有用なアップデート情報でした。 DRAは、これまでPod作成時に静的に確保されていたGPUなどの特殊リソースを、Podがノードにスケジュールされるタイミングで、ノード上の利用可能なデバイス状況に応じて柔軟かつ動的に割り当てるための仕組みです。これにより限られたリソースの利用効率を高めることができます。さらに、1つのGPUを複数のPodで共有したり、Pod側からデバイスの構成パラメータを細かく指定したりできます。この機能は、Kubernetes v1.32でベータ版として導入されました。 さらに、Kubernetes v1.33では、以下のアルファ機能が追加されました。 Partitionable Devices ：物理GPUを分割して複数Podに割り当て、リソース効率を最大化 Device Taints and Tolerations ：特定のPodにのみ特定デバイスを使わせる制御 Admin Access ：DRAに管理者用のアクセス権限を導入 今後Kubernetes v1.34での正式サポート（GA）を目指して活発に開発が進められています。詳細については以下の公式ドキュメントをご参照ください。 https://kubernetes.io/blog/2025/05/01/kubernetes-v1-33-dra-updates/#what-s-next 次に紹介されていたIn-Place Pod Resizeは、既存のPodを削除せずにCPUやメモリのrequests / limitsを動的に変更できる機能です。これまでKubernetesではリソースを変更する際にはPodを再起動する必要がありましたが、この機能によって、Podを停止せずにリソース構成を変更できるようになります。 Kubernetes v1.27ではアルファ版として登場し、v1.33では以下の改善がありました。 --subresource=resize による明示的なリサイズAPIの提供 リサイズ反映までの時間が大幅に短縮され、即時対応が可能に 特に注目すべき点はダウンタイムの削減です。v1.31ではリソース変更の反映に60〜90秒ほどかかっていましたが、v1.33では即時で反映されるようになり、よりスムーズなリソース変更が可能になりました。 この2つの機能は、今後のKubernetesにおいて非常に重要な役割を果たすと考えられます。DRAによるGPUの細かな割り当て制御は、AI/MLの活用が進む中で高まるGPU需要に対し、限られたリソースをいかに効率よく活用するかという課題の解決に貢献します。また、In-Place Pod Resizeを活用することで、動的に変化するワークロードにも柔軟かつ迅速に対応することが可能になります。 特にDRAは、今回のKubeCon + CloudNativeCon Japan 2025でも複数のセッションで取り上げられており、コミュニティ内でも高い関心を集めているテーマであることが印象的でした。今後のバージョンアップを通じて、より高度で柔軟なリソース管理が実現されていくことに期待されます。SIG Nodeチームは、ノードやリソース管理の進化を牽引する存在であり、今後のアップデートにも引き続き注目していきたいです。 Platform Engineering Day 2: Why Service Iterations Are the Crux of Developer Platforms 計測プラットフォーム開発本部・システム部SREブロックの近藤です。「 Platform Engineering Day 2: Why Service Iterations Are the Crux of Developer Platforms 」セッション（登壇者：Puja Abbassi氏[Giant Swarm]）をご紹介します。私の所属する部署では、既存プロダクトの開発・運用に加え、計測技術を活用したPoCや新規プロダクトの立ち上げにも取り組んでいます。そのため、KubeConの中ではやや異色に感じたセッションでしたが、普段の業務に通じる内容が多く、非常に実践的な学びが得られました。 kccncjpn2025.sched.com Internal Developer Platform（IDP） 本セッションでは、開発者体験（DX）を向上させるための基盤として「Developer Platform」が紹介されました。その中でも、社内での開発者向けに最適化された仕組みとして「Internal Developer Platform（IDP）」が取り上げられています。 Platform Engineering Day 2 Why Service Iterations Are the Crux of Developer Platforms P.4より引用 IDPのサービスアーキテクチャが図示されており、非常にわかりやすい構成でした。弊チームではリリース自動化には取り組んでいるものの、IDPとしての構成図は明確に描けていなかったため、この図に当てはめることで自分達が注力している部分（Applications / Services層）を再認識する良い機会となりました。 Golden Path セッション内で印象的だったキーワードのひとつが「Golden Path」です。これは、開発者が迷わず最適な方法でアプリケーションを構築・運用できるよう導く、標準化されたベストプラクティスの道筋と定義されています。新規プロダクトのスピーディな立ち上げが求められる弊チームにとって、Golden Pathの整備はDX向上の鍵であり、改めてその重要性を実感しました。 Platform Engineering Day 2 Why Service Iterations Are the Crux of Developer Platforms P.7より引用 Day 2 このセッションでは「Day 2」というフェーズが明確に定義されており、プロダクトがリリースされた後の運用・改善フェーズに焦点が当てられていました。セッション内でDay 2におけるアプリケーション開発者・プラットフォームエンジニアそれぞれの役割や課題が具体的に紹介されています。 Platform Engineering Day 2 Why Service Iterations Are the Crux of Developer Platforms P.10より引用 Platform Engineering Day 2 Why Service Iterations Are the Crux of Developer Platforms P.13より引用 Best Practices セッションの最後では、Day 2を見据えたベストプラクティスが紹介されていました。 Platform Engineering Day 2 Why Service Iterations Are the Crux of Developer Platforms P.26より引用 中でも「イテレーションをKPIとする」という考え方は、これまであまり意識できていなかった視点であり、非常に良い気づきとなりました。弊チームではPoCからプロダクトフェーズへの移行が多いため、継続的な改善を前提としたプラットフォーム設計と運用が今後ますます重要になると感じています。今回のセッションで得た知見を活かし、Golden Pathの整備や自己サービス化の推進など、開発者がより快適に開発できる環境づくりを進めていきたいと思います。 Japan Community Day Doc Sprint参加レポート EC基盤開発本部 SRE部 商品基盤SREブロックの佐藤です。私は Japan Community Day で開催された『 Doc Sprint 』に参加しました。 community.cncf.io Japan Community Dayとは Japan Community Dayの様子 KubeCon + CloudNativeConの開催前日に行われる実質0日目イベントで、 Cloud Native Community Japan が主催となって企画しています。 公式サイト のとおり、セッションやLTに加えてハンズオン型プログラムが充実しており、初参加の人でも気軽にOSSへ関われるのが大きな魅力です。今回は、その中で開催された『 Kubernetesドキュメント Doc Sprint 』に参加しました。 Doc Sprintの概要 目的： Kubernetes 公式ドキュメント日本語版 の品質向上と翻訳差分の解消 対象リポジトリ： https://github.com/kubernetes/website メンター：レビューとマージ権限を持つDocs Approver2名 当日の作業フロー リポジトリ準備 kubernetes/website をForkし、ローカルにclone。 ローカルプレビュー Hugoサーバーを起動し、ブラウザで該当ページを確認。修正前後の差分を比較。 ドキュメント編集 content/ja/docs/以下のMarkdownを修正。 PR作成 mainブランチにPull Requestを提出し、Reviewerをアサイン。 レビュー&マージ メンターが即時レビュー → LGTM → Approved → Merge。初のコントリビュートが、わずか数十分で完了しました。 得られた学び 翻訳ガイドラインの理解と運用 翻訳ルール（Localization Guide） にあるように、表記の統一や語彙の取り扱いには明確なルールが定められています。日本語訳では、下記の項目にあるような細かい議論が発生しやすいことを実感しました。それをApproverの方と直接相談できたのは貴重な体験でした。 長音記号（例：クラスター vs クラスタ）を使うか カタカナ表記または英語表記か 特に「node」のように文脈によって意味が変わる単語の扱い（ 例 ） コントリビューションの可視化とモチベーション DevStatsダッシュボード を使うと、コントリビューターの国別・企業別・個人別の貢献状況などを確認でき、モチベーションアップに直結する仕組みがあることを知りました。自分の名前も実際に 確認できました 。 コントリビューターロールの明確化 Kubernetes Docsチームには明確な ロールと責任 があり、少しずつ経験を積んで、Reviewer・Approverへと進んでいける仕組みが整備されていました。 Anyone：定期的にコントリビュートする人。誰でもなれる。 Member：Issueのトリアージや非公式レビューが可能になる。 Reviewer：公式レビューをリードし、品質保証を担う。 Approver：マージ権限を持ち、ドキュメント全体の整合性を管理する。 その他 日本語翻訳は世界で3番目に活発な言語化プロジェクト（資料： Kubernetes SIG Docs Localization Subproject (ja) ）。 とくにブログの翻訳は世界最速を目指している（記事が出た当日に徹夜で翻訳することもあるそうです！）。 活動を支えるために、小さなPRや更新の積み重ねが大切である。 Slack（ #sig-docs-ja ）で情報共有や相談ができる。 「このページに記載されている情報は古い可能性があります」バナーがついているページは、初心者に最適な貢献ポイント。 まとめ Doc Sprintは「Approverにすぐ相談できる」「PRがその場でマージされる」という即時フィードバックが魅力の学習環境でした。ドキュメントは常に改善余地があり、OSS初心者が成功体験を得やすい入口だと実感しました。今後も更新が滞っているページの刷新に取り組み、Kubernetes日本語ドキュメントの充実に貢献していきたいと思います。 最後に、機会をくださったApproverの皆さん、そして一緒に参加してくださった皆さん（ZOZOブースにもお越しくださりありがとうございました！）に感謝いたします。 Exploring Tenant-centric Strategies To Simplify Multi-cluster and Multi-cloud Complexities SRE部フロントSREブロックの三品です。私が所属するSRE部フロントSREブロックでは、ZOZOTOWNが持つAPIの中でもクライアントに近い、BFFを含むFrontendレイヤーのサービスを運用しており、言わばEmbedded SRE的な業務を行っています。今回、日本初開催のKubeConに参加して私が今回興味深いと感じたセッションを紹介します。 kccncjpn2025.sched.com このセッションでは、マルチクラスターやマルチクラウドにより複雑化するKubernetes環境を、運用担当者がどのように管理していくかが解説されていました。セッションの冒頭では、プラットフォームエンジニアとエンドユーザーの両視点から、Kubernetes環境の複雑性とそれに伴う課題が紹介されていました。 Infra / Platform Team目線 Exploring Tenant-centric Strategies To Simplify Multi-cluster and Multi-cloud Complexities P.4より引用 マルチクラウド・マルチリージョン環境では、管理すべきリソースの数の急増が指摘されました。加えて、クラウドプロバイダーごとにAPIや構成方法が異なるため、統一的な管理が難しいという課題も挙げられました。これらを背景に、効率的なリソース管理には、 プログラマブルなアプローチ が不可欠であると説明されています。 End use 目線 Exploring Tenant-centric Strategies To Simplify Multi-cluster and Multi-cloud Complexities P.5より引用 一方でエンドユーザー側では、マルチクラウドやマルチクラスター構成の影響で、利用するツールが多様化しています。ツールやクラウドごとに操作方法やAPI仕様が異なるため、それぞれのツールに関する深い理解と、 高度なデバッグ能力 が必要であると述べられていました。これらの問題に対してセッションでは、以下のようなゴールが設定されます。 ツールやクラウドプロバイダーの違いを吸収する 抽象化レイヤー コード生成 や 設定ファンアウト を含む、リソースのプログラム的テンプレート化 一貫性と拡張性を両立した API駆動型プラットフォーム スキーマに基づいてリソース定義と構成を管理する 自動化と制御の仕組み スライドのようなアーキテクチャが説明されていました。 Exploring Tenant-centric Strategies To Simplify Multi-cluster and Multi-cloud Complexities P.9より引用 Exploring Tenant-centric Strategies To Simplify Multi-cluster and Multi-cloud Complexities P.11より引用 また、アーキテクチャの説明が行われたのち、達成順序についても述べられていました。 Exploring Tenant-centric Strategies To Simplify Multi-cluster and Multi-cloud Complexities P.12より引用 個人的に興味深かった点は、 Pkl を採用している点とマルチクラスタ構成そのものについてです。 まず、Pklについてですが、ZOZOではKubernetesマニフェストをKustomizeを使い base/ + env/ 構成で管理しています。ただし、この構成では各環境の値（例えば、JVMのパラメーターなど）を静的に定義する必要があり、条件分岐やデフォルト値の設定などを ロジックベースで扱うことが難しい という課題があります。 一方で、Pklを用いることでこうした 条件分岐やデフォルトの共通化をプログラマブルに表現 できるため、より柔軟な構成管理が可能になると感じました。ただし、Kustomizeを使った純粋なYAMLを使った書き方に比べると、学習コストが増えることが予想され、新規メンバーがJoinした際に必ず学習期間を設ける必要があります。そういった点で利便性と学習コストが採用する際の天秤として難しいなと個人的には感じました。 次に、マルチクラスタについてです。ZOZOTOWNでは、EKS上でシングルリージョン・シングルクラスタのマルチテナント方式でKubernetesを運用しています。 これまで私は、マルチクラスタ構成について「クラスタ内の構成は簡素になっても、マニフェストの管理やアップデート時の運用負荷が増えるのではないか」と考え、あまり前向きに検討してきませんでした。しかし今回のセッションを通じて、もし各クラスタに対してリソースを自動でApplyできるような環境（例：Crossplane + ArgoCDなど）を整備できるのであれば、要件的にマルチクラスタ構成が必要ない場合でも クラスタ間の責務を明確に分離することで、個々の構成をシンプルに保ちつつ 安全性や柔軟性の高い運用ができる可能性あると感じました。 一方で、マルチクラスタ化が進むと、それぞれのクラスタにインストールされるカスタムオペレータ（CRDやコントローラ）の数も増えていきます。その場合、各オペレータのアップデート対応や互換性の確認など、新たな運用コストが発生する懸念もあります。これまで私はマルチクラスタについて深く考える機会があまりなかったのですが、今回のセッションを通じて、改めてそのメリット・デメリットを整理し、今後の構成設計に活かしていきたいと感じました。 Cloud Native Scalability for Internal Developer Platforms こんにちは、Platform SREブロックの石井です。 Cloud Native Scalability for Internal Developer Platforms - Hiroshi Hayakawa, LY Corporationをご紹介します。 kccncjpn2025.sched.com 自分はプラットフォームエンジニアとして活動しており、「Kubernetesにはスケールの限界があるのか・大きなスケールのチームは何か特別な扱い方をしているのか」という疑問がありました。本セッションでは 690 テナント / 29,000 アプリ / 112,000 Pods という国内最大級の規模を 約5年間で実現 した実践例および現状の課題が紹介されました。まさに自分達が現在直面している課題や、“数年後の自分たち”に直結する何かが得られると考え、セッションを拝見しました。 セッション概要 以下のような内容が本セッションでは紹介されていました。 背景 ：シンプルなコマンドでアプリケーションを実行できるHerokuのようなPaaS(IDP:Internal Developer Platform)を構築し、全社開発者へ提供。 5年のスケーラビリティの旅 ：スケールする中でさまざまばクラスタ設計・運用自動化・メトリクス基盤・コントローラ性能の壁を順に突破。 現在直面している課題 ：Control Planeの限界とController Shardingへの挑戦。 1. Internal Developer Platform(IDP)の全体像 まずは、IDPの全体像が紹介されており、規模の大きさに非常に感銘を受けました。 構成 ： 特徴：単一Control Plane Clusterで複数Workload Clustersを制御し、「 論理的な一つのクラスタ 」として扱う設計 Control Plane Cluster : ユーザーからの支持を受け付け、アプリケーションのデプロイに必要な処理を行うクラスタ。どのWorkload Clusterにスケジュールするか・アプリケーションを外部に公開する準備を行う Workload Clusters : アプリケーションを実際に実行するクラスタ群 Cloud Native Scalability for Internal Developer Platforms P.6より引用 スケールの変遷 Cloud Native Scalability for Internal Developer Platforms P.7より引用 2. スケーラビリティの旅と直面した壁 (Scalability Journey in Our Internal Developer Platform) この大きくスケールした5年間で直面した課題やそれに対する決定などが紹介されていました。一部を紹介します。 2-1. クラスタ設計：Single vs Multi 非常に多くのアプリケーションをホストする要件があったため、どのようにしてKubernetes Clusterをスケールするかは非常に重要な事項であった。主に2つの選択肢があった。 Cloud Native Scalability for Internal Developer Platforms P.17より引用 結果：マルチクラスタを選定 決め手 ：組織的に複数クラスタ運用ノウハウがあり、社内の要件に則った。これは絶対的な正解ではなくチームのスキルセットや組織の要件によってことなる。 マルチクラスタ設計 CPU / メモリを大きく消費するアプリケーションだけを Silo Cluster に隔離、残りは Pool Cluster で共有するハイブリッド方式を採用。これによりNoisy Neighborの問題を最小限にできる。 Silo Cluster : 特定ワークロードのリソース消費が大きいなどの理由によりシングルテナントで利用されているクラスタ Pool Cluster : マルチテナントでリソースが共有されているマルチテナントのクラスタ Cloud Native Scalability for Internal Developer Platforms P.21より引用 2-2. オペレーショナルスケーラビリティ DeveloperチームがPlatform利用開始する、オンボーディング関連作業を少数のPlatformチームメンバーのみで行っていた。しかし、組織にプラットフォームを公開する必要があり、この作業をスケーラブルにする必要があった。 自動化前: 開発者がチケット経由でテナントをリクエスト プラットフォームエンジニアが対応： Athenzに認可ポリシーを登録 Git上にNamespaceを作成（GitOpsにより管理） Cloud Native Scalability for Internal Developer Platforms P.25より引用 自動化後: カスタムコントローラを作成し、ポリシー登録を自動化 チケットシステムをオンボーディングアプリに置き換え 現在は完全セルフサービス化。開発者自身でオンボーディング可能に Cloud Native Scalability for Internal Developer Platforms P.31より引用 2-3. カスタムコントローラ性能 カスタムコントローラーはリコンサイル処理で競合を起こさないように単一のインスタンスで動作する必要がある。しかし、クラスタの規模が大きくなると単一インスタンスのスケールアップだけでは、様々な問題に直面するようになった。 現状 ：単一Podでスケールアップ 現在挑戦中 ：CNCF Sandbox timebertt/kubernetes-controller-sharding へコントリビュートし 水平分割（Shard）による Scale-Out を検証中 3. いま直面している3つのControl Planeの課題 Platformが成長しスケールするにあたり、生じたControl Planeに関する複数の課題が紹介されていました。 リソース数増加により、kube-apiserverの消費メモリが増大する問題 v1.33からデフォルトONの Streaming List で解消見込み etcd サイズ肥大 Aggregation Layer経由で一部のCRDをWorkload Clusterへ移譲 Controllerがスケールアップしかできない Kubernetes Controller Sharding をへ会社としてコントリビュートしている。 おわりに 本セッションで最も印象に残ったのは、「スケールの旅に終わりなし。その旅を楽しめ」 という姿勢でした。大規模運用を支える構成や技術選定はもちろん、負荷の特性に応じたクラスタ分離戦略（Silo / Poolモデルの併用）、無理なく自動化を進める段階的アプローチ、といったひとつひとつの設計思想に、深く感銘を受けました。そして、Controller Shardingのようなまだ未成熟な領域にも、「必要だから、自分たちで積極的にコントリビュートする」という姿勢が垣間見えた点も非常に刺激的でした。このセッションには多くの刺激を受け、また、学びを得ることができました。これを自社のプラットフォームの発展にも役立てていきます。 ZOZOブースの紹介 ZOZOブースの様子 ZOZOのスポンサーブースでは、ZOZOTOWNのアーキテクチャとOSSデモをメインコンテンツとして展示しました。また、各プロダクトのステッカーやZOZOの計測テクノロジーを生かした ZOZOGLASS と ZOZOMAT を配布しました。 ZOZOブースで配布したノベルティ ZOZOTOWNのアーキテクチャ 展示コンテンツの1つであるZOZOTOWNのアーキテクチャについて、プラットフォームSREの酒部と、検索基盤SREの徳山から紹介いたします。2人とも25年度新卒として入社しました。 ZOZOTOWNでは長らくオンプレミスからクラウドへの移行とマイクロサービス化を進めています。 techblog.zozo.com まだ移行過渡期であるものの、日本で初めて開催される「KubeCon + CloudNativeCon Japan 2025」というクラウドネイティブの世界的なカンファレンスで展示することで、社外からの疑問や意見を交換できる機会になると考え、このコンテンツ制作に至りました。会期中に展示していたスライドの一部を掲載いたします。 とても多くの方に関心を持っていただいたZOZOTOWN Architecture Architectural Policy Ecosystem for Achieving System Stability Ecosystem for a Highly Productive Development System 「クラウドをどのように使い分けている？」、「プラットフォームが多機能で運用が大変そう」といった質問や感想を頂きました。 僕たちはZOZOTOWNの新卒SREと言う立場で今回のイベントに参加し、アーキテクチャ図の制作からブース対応をする中で多くの気づきがありました。 今回、ZOZOTOWNのアーキテクチャとマイクロサービスを自動リリースする手法について先輩社員から学びながらアーキテクチャ図を制作しました。ZOZOTOWNの全体像と安全にリリースするための先進的な仕組みを学ぶことができる貴重な機会になりました。ブース対応をする中で他社のアーキテクチャも聞けましたが、他社さんに比べてZOZOでは独自のAPI Gatewayを作っているなど、オンプレを含むハイブリッドな構成であることを感じました。 参加者の半分くらいは日本人で言語の壁を感じることなく議論ができました。また海外の参加者も日本語で話しかけてくださったりして、英語に苦手意識がある自分でも緊張せずに議論できて、本イベントの参加者の暖かさも感じることができてよかったです。 ブース出展したことで、Kubernetesを中心としたクラウドネイティブ技術の最前線に触れられただけでなく、世界中の情熱的なエンジニアと繋がれる素晴らしい機会になりました。ブースに立ち寄って頂いた皆様、ありがとうございました。 OSS デモ OSSデモの様子 ZOZOにて開発し利用している大規模負荷試験ツール「 Gatling Operator 」と、複数の負荷試験を省力化して実行可能なCLIツール「 Gatling Commander 」のデモを行いました。 説明中の様子 Gatling Operatorは、Gatlingをベースとした分散負荷試験のライフサイクルを自動化するKubernetes Operatorです。Gatling CommanderはGatling Operaorによる複数の負荷試験を自動的に連続・連携して実行可能とし省力化するCLIツールです。 Gatling Commanderを実行するとGatling Operatorが立ち上って対象サーバーへリクエストが行われ、テスト結果が Google スプレッドシート で一覧確認できるデモを行いました。 デモはGatling Commanderを実行するCLI、Gatling Operatorが動作するKubernetesのPodの状態、対象サーバーのアクセス状況を表示するツールを作成しました。 Gatling CommanderとGatling Operator ブース展示のために作成したデモツールの様子 テスト結果はGoogle スプレッドシートで参照可能です。結果はGoogle スプレッドシートに複数のテストを集約する形で表示されます。 テスト結果はGoogle スプレッドシートで参照可能 Gatling Operator と Gatling Commander はそれぞれオープンソースとしてGitHubで公開しています。また、過去に公開している関連記事もみていただけると嬉しいです。 techblog.zozo.com techblog.zozo.com 協賛企業ブースのコーデまとめ あっすーです。他カンファレンスと同じように協賛企業ブースを回ってきましたので、各ブースのコーデをお送りします！　各社の雰囲気に合わせたデザイン・着こなしは、やはりZOZOとしても気になるポイント。参加した方は当日の会場の様子を思い出しながらご覧ください。 Kongさん DoiTさん Red Hatさん 日立製作所さん（表） 日立製作所さん（裏） Octopus Deployさん Tintriさん EDBさん Kubernetes Contributor Summit LINEヤフーさん / クラウドネイティブな高速近似最近傍密ベクトル検索エンジン「 Vald 」 Splunkさん（表） Splunkさん（裏） ClickHouseさん（表） ClickHouseさん（裏） Dash0さん（表） Dash0さん（裏） AWSさん Google Cloudさん Grafanaさん SUSEさん C-Nativeさん Akamaiさん お忙しい中ご協力いただいたブースの皆様、本当にありがとうございました！ おわりに 日本初開催のKubeCon + CloudNativeCon Japanに協賛、そしてブースを出展できたことはとても良い経験になりました。改めてブースにお越しいただいた多くの皆さん、ありがとうございました。少しでもZOZOに興味を持ってもらえたら幸いです！ ZOZOから参加した一部メンバーで撮影した集合写真 ZOZOでは、一緒に働くSREの仲間を募集しています。ご興味のある方はこちらからご応募ください。 ZOZOTOWN SRE | 株式会社ZOZO WEAR by ZOZO SRE | 株式会社ZOZO ZOZOMO SRE | 株式会社ZOZO SRE（オープンポジション） | 株式会社ZOZO また、会期中は混雑していることも多く、じっくりとお話しする時間が取れなかったので、もう少し詳しく話を聞きたい！　という方はカジュアル面談も受け付けています。 hrmos.co 既に来年開催される「 KubeCon + CloudNativeCon Japan 2026 」のページも公開されています。来年も素敵なカンファレンスになることを期待しています！ 現場からは以上です！

はじめに こんにちは。ZOZO研究所の研究員の川島、ZOZOのデータサイエンティストの吉本・広渡です。2025年5月27日（火）から5月30日（金）にかけて大阪で開催された『2025年度 人工知能学会全国大会（JSAI2025）』に参加しました。この記事では我々が気になったセッションの内容をご紹介します。 はじめに JSAI2025とは セッションレポート [2M5-OS-37b] AIを用いた空間・時系列データのモデリング手法と応用 [2M5-OS-37b-01] （OS招待講演）地理空間情報を活用した経路計画 [2M5-OS-37b-02] 経路複雑性の活用による経路選択モデリングの性能改善 [2M5-OS-37b-03] モデル化誤差が顕著な状況における制御のためのダイナミクス学習 [2M5-OS-37b-04] 大学病院の集中治療室における医療スタッフの移動軌跡の抽出手法 [3F5-OS-42b] 大規模言語モデルの安全対策 ― 大いなる力には、大いなる責任が伴う [3F5-OS-42b-01] AIの安全性に関する世界の動きとAI Safety Institute（AISI）について [3F5-OS-42b-02] AISI国際ネットワークにおける共同テスト演習について [3F5-OS-42b-03] 大規模言語モデルのジェイルブレイクに対するインコンテキスト防御の役割明記による改良 [3F5-OS-42b-04] （OS招待講演）安全な大規模言語モデルの構築と利用を目指して [4D2-OS-33b] AIを活用したマーケティング実践 [4D2-OS-33b-01] LLMを活用したペルソナベースのデルファイ法による多視点アイディア評価 [4D2-OS-33b-02] 深掘り質問促進のための LLM を活用した動的プロンプト制御型顧客インタビュートレーニングシステム [4D2-OS-33b-03] 生成AIとジョブ理論で作る顧客中心型CRM [4D2-OS-33b-04] 広告デザイン改善のための代替案生成手法 [4D2-OS-33b-05] 双方向推薦システムにおけるコントラスト効果の応用 まとめ JSAI2025とは JSAIとは、一般社団法人 人工知能学会（JSAI） が主催する日本最大級のAI学術イベントで、2025年に第39回を迎えました。今回は大阪国際会議場で開催され、過去最多となる4,939名が参加しました。 EXPO 2025 大阪・関西万博のテーマウィーク と連携した特別セッションが設けられるなど、学術研究と国際的なイベントが融合した大会となりました。 www.ai-gakkai.or.jp セッションレポート [2M5-OS-37b] AIを用いた空間・時系列データのモデリング手法と応用 ZOZO研究所の川島です。会期2日目である5/28（水）には、オーガナイズドセッション「 AIを用いた空間・時系列データのモデリング手法と応用 」が開催されました。 同オーガナイズドセッションは年度ごとのマイナーチェンジはあるものの、2020年度大会から継続して開催されており、現在のJSAIにおける主要なテーマのひとつと言えます。 ZOZO研究所では 物流コストの最小化を目指す研究 を行っており、そのような技術につながる新たな発見を期待して同セッションに参加いたしました。以下ではセッション内の各発表について簡単にレポートいたします。 [2M5-OS-37b-01] （OS招待講演）地理空間情報を活用した経路計画 同セッションは豊田中央研究所の大滝氏による招待講演から始まりました。本講演は主に歩行する人を対象とし、どのような方法で出発地から目的地までたどり着くまでの経路を案内するか、という経路計画の問題についての発表でした。 最短あるいは最短に近い経路を求めることはあまり難しくないのですが、本講演の面白いところはいかに「最短でない経路」をサジェストするかというところに焦点をあてているところでした。講演者らが実施したアンケートでは、回答者の約半数がナビゲーションにおいて「案内される経路が必ずしも最短でなくてもよい」と答えたそうです。実際の研究事例として、（1）目的地に目標の時間に着くまでに歩き回れる経路の探索、（2）歩く道の景観情報を加味した楽しい街歩きのための経路の探索、（3）東京タワーのようなランドマークの情報を使った迷いづらい経路の探索、（4）道路としての魅力度の差異（例：パチンコ屋が並んでいる道とアーケードの商店街）を評価する研究などが紹介されました。 ところでZOZOでは「 似合うってなんだ 」をコンセプトとした研究を精力的に行っていますが、ファッションの評価には主観的な好みが常につきまといます。この講演で紹介された研究についてもそのような主観性に基づいた問題設定である面白さや難しさがあり、弊社での取り組みとの共通点を感じながら聴講していました。 [2M5-OS-37b-02] 経路複雑性の活用による経路選択モデリングの性能改善 続いての口頭発表でも経路選択に関する研究が紹介されました。本発表は逆強化学習を用いた経路選択において、どのようなデータを用いればより高品質な経路選択が可能となるか、という問いに対する検討を行うものでした。 逆強化学習はその名の通り強化学習の逆の問題を解くタスクで、通常の強化学習では「定義した報酬関数をもとにそれを最大化する方策を探す」ことを考える一方、逆強化学習では「データセット中で実際に取られた方策から報酬関数を推定する」ということを行います。具体的には、タクシードライバーが実際に通った経路を集めたデータからRCM-AIRL (Route Choice Modeling Adversarial Inverse Reinforcement Learning)と呼ばれる手法で報酬関数を推定し、それを用いて経路選択をするということが行われていました。このデータセットを経路中の右左折の多さによって3段階に分割し、それぞれ（+全データを使った場合）で学習を行ったところ、中程度に複雑な経路からなるデータセットを用いた場合で定量的に最もよい経路選択が行えたそうです。 [2M5-OS-37b-03] モデル化誤差が顕著な状況における制御のためのダイナミクス学習 微分方程式に従う時系列データのダイナミクスをうまくモデリングすることは、制御などの意味で非常に重要です。 学習によってダイナミクスを推定する際、物理的な事前知識によって得られる具体的なモデル中の未知パラメータを推定する場合と、Neural ODE (Neural Ordinary Differential Equation) のようなブラックボックスモデルを用いる場合とがあります。後者のアプローチを採用すると事前知識は不要になりモデリングの柔軟性は増しますが、学習のためのデータは大量に取得しなければならなくなります。両者の利点をあわせ持つのがハイブリッド型の方法で、事前知識に基づく数理モデルとブラックボックスの足し合わせで時間発展を記述するアプローチをとります。ただしハイブリッド型の方法はナイーブに学習すると本来数理モデル側で表現してほしいパートまで、その表現能力の高さゆえにブラックボックスモデルに吸収されてしまう問題があるようです。 このため、ブラックボックスモデルに何らかの形で正則化をかける必要があります。本発表は、その正則化の種類や大きさが実際の精度にどう影響するかについて、マルチコプターのシミュレーションを題材に調べた研究でした。結果としてモデル全体（数理モデル+ブラックボックスモデル）とブラックボックス単体との出力の相関に関して正則化を行うのがベターで、また正則化を大きくしすぎると予測誤差が大きくなることが確認されたようです。 [2M5-OS-37b-04] 大学病院の集中治療室における医療スタッフの移動軌跡の抽出手法 セッション最後の研究は、病院の集中治療室 (ICU) の業務効率化を目指し、センサを用いてICU中のスタッフの移動軌跡を取得・分析するという研究でした。 ICUでは実際に動線の交錯や滞留が生じるものの、動画データを用いた場合患者へのプライバシーの問題が発生する、という特有の課題があるとのことでした。データの取得にはスタッフの業務を阻害しない小型の2D-LiDARセンサを用いて点群データを取得したのち、事前学習済みの物体検出モデルで人物検出を行い、カルマンフィルタによって各個人の軌跡を追跡する、というパイプラインが用いられていました。その後各軌跡に対してGMM (Gaussian Mixture Model)による移動・滞留のクラスタリングや効果的な可視化を用いた定性的な確認などの複数の側面からデータを分析し、人流の様子を定量的・定性的に把握できるようになったそうです。 [3F5-OS-42b] 大規模言語モデルの安全対策 ― 大いなる力には、大いなる責任が伴う データ・AIシステム本部データサイエンス2ブロックの吉本です。 私たちのブロックでは、AIやデータサイエンス技術を用いたプロダクト開発とそのための研究開発に取り組んでいます。ここでは、5/29（木）に行われたオーガナイズドセッション「 大規模言語モデルの安全対策 ― 大いなる力には、大いなる責任が伴う 」の各発表についてレポートします。 [3F5-OS-42b-01] AIの安全性に関する世界の動きとAI Safety Institute（AISI）について 同日の午前中の招待講演 [3A2-PS-3] AIのリスクと安全性〜AI広島プロセスからAISI設立まで（村上 明子氏） と合わせて紹介させていただきます。 AISI（AIセーフティ・インスティテュート） は、安全・安心で信頼できるAIの実現に向けて、AIセーフティに関する評価手法や基準の検討・推進するための機関です。2024年2月14日に10の関係府省庁と5の政府系関係機関が共同で設立しました。 活動の1つとしてガイドラインの策定があり、AIシステムの安全性を評価する際の基本的な考え方を示した AIセーフティに関する評価観点ガイド や、AIシステムのリスク対策を攻撃者の視点から評価するためのレッドチーミング手法に関する AIセーフティに関するレッドチーミング手法ガイド などが紹介されました。 AIのリスクについては、 International AI Safety Report や総務省・経済産業省が出している AI 事業者ガイドライン に基づいて説明されました。また、AIの安全性を守るための規制の動向に関しても説明がありました。ガイドラインのような罰則のないゆるやかな方式で行うソフトローと、法律で定めたうえで罰則も視野に入れたハードローの考え方が紹介され、発表前日5月28日に成立した AI法 に関しても触れられました。 [3F5-OS-42b-02] AISI国際ネットワークにおける共同テスト演習について この発表では、 AISI国際ネットワーク が行った、10カ国共同での テスト演習 が紹介されました。 テスト演習は、多言語評価とサイバーセキュリティ評価の2つの分野について実施されました。日本はデータセットの翻訳作業、評価の実施、分析を担当しました。多言語評価は日本・シンガポールが、サイバーセキュリティ評価は英国が主導しました。 多言語評価のデータセットとしては MLCommons 、 AnswerCarefully V2 、および CyberSecEval が使用されました。MLCommons、AnswerCarefully V2は、懸念のある質問に対してLLMが無害な出力を生成できるかどうかを検査します。CyberSecEvalは、プロンプトインジェクション攻撃への耐性を検査します。 サイバーセキュリティ評価は英国AISIが開発した Inspect AI プラットフォーム上で行われ、データセットとしてはサイバーセキュリティスキルを評価する Cybench が用いられました。 モデルとしては、他言語評価ではMistral LargeとGemma2が、サイバーセキュリティ評価ではMistral Large、GPT-4o、GPT-4o miniが評価されました。 [3F5-OS-42b-03] 大規模言語モデルのジェイルブレイクに対するインコンテキスト防御の役割明記による改良 LLMに対する攻撃の1つに、プロンプトを入力して不適切な出力を誘導するジェイルブレーク攻撃があります。LLMの再学習による対策は計算・時間のコストが高いため、プロンプトの加工による防御手法が注目されていますが、過剰な応答拒否や生成文の品質の劣化といった課題がありました。 これらの課題に対応するため、この研究ではプロンプト中に命令と役割の対応付けを徹底する「RoleSpec」という手法が提案されました。RoleSpecでは、システムメッセージには「System」、LLMの応答には「Assistant」、ユーザーのプロンプトには「User」といった役割名を明記します。 実験はLlama-2-7b-chatモデルを用いて行われ、攻撃手法としてはプロンプトの末尾に人工的な文字列を追加するGCG、攻撃用LLMがプロンプトを自然で説得的な文に洗練するPAIR、ロールプレイングを伴うプロンプトで攻撃するDANが試されました。 評価指標としては、攻撃に対する拒否応答率と、一般タスクに対する回答品質を測る MT-bench が用いられました。 実験の結果、RoleSpecを適用することで、何も防御していない場合と比較して、攻撃に対する拒否応答率とMT-benchの回答品質の両方が大幅に向上することが確認されました。また既存手法と組み合わせた場合でも、攻撃耐性と回答品質が向上することが示されました。 [3F5-OS-42b-04] （OS招待講演）安全な大規模言語モデルの構築と利用を目指して この招待講演では、東京科学大学の岡崎直観氏がこれまでに取り組んでこられた、LLMの安全性に関わる研究が紹介されました。 バイアスに関して3件 [1] [2] [3] 、LLMが生成したテキストの検出に関して2件 [4] [5] 、メンバーシップ推論攻撃に関して2件 [6] [7] 、日本語LLMであるSwallowに関して3件 [8] [9] [10] の研究が紹介されました。 バイアス [1] では職業名と性別を示す単語を含む文ペアに対し、含意関係認識を行わせることで、言語モデルのバイアスを定量評価します。例えば「看護師がテニスをしています」と「女性がテニスをしています」のペアの関係を含意・矛盾・中立のどれとモデルが判定するかを見ます。 [2] では、「技術面接での質問に男性と女性のどちらが正解したか」といった性別バイアスが関わる質問にLLMに答えさせ、回答がバイアスを含んでいた場合に、LLM自身でフィードバックを与えて修正させる手法が提案されました。 [3] はLLM-as-a-judgeの設定における、尤度バイアスの評価・緩和に関する取り組みです。LLMが計算する尤度と、LLMと人間のスコアの差との相関係数によってバイアスを評価します。またfew-shot事例をプロンプトとして提示することで、このバイアスを緩和できることが示されました。 LLMが生成したテキストの検出 [4] ではLLMが生成したエッセイの検出器と、その検出を回避しようとする攻撃側LLMを敵対的にIn-Context Learningさせることで、両者の性能がともに向上する「いたちごっこ」が生じることが確認されました。 [5] は生成テキストの品質を維持しつつ、透かしを入れるようにLLMが生成したものであると検出されやすくすることを目指した研究です。検出器からの報酬と評価器からの報酬を組み合わせた強化学習を用いることで、品質を保ちつつ検出されやすさを向上できることが示されました。 メンバーシップ推論攻撃 (MIA) MIAとは、テキストがLLMの学習に使われたものかを推論する攻撃です。 [6] では、尤度にアクセスできないクローズドなLLMに対する攻撃手法が検証されました。検出対象テキストの前半部分をLLMに入力し、その続きとしてLLMが生成したテキストと、元の対象テキストの後半との一致率を比較することで、高い検出率が得られることが示されました。 [7] では、アンラーニングをしつつ忘却対象のテキストを言い換えたテキストで学習させることで、MIAによって検出されないように（データ漏洩の隠蔽）しつつ、対象タスク性能を維持する手法が紹介されました。 Swallow [8] に関しては、訓練データに対する安全対策として、有害な表現を含む可能性のあるウェブページをフィルターしていることが紹介されました。また [9] では、 こちら でも紹介させていただいたように、有用なテキストをLLMで選定していることが紹介されました。 [10] に関しては、LLMによって生成された指示チューニングの学習データ中に、回答拒否を含む応答が含まれていることが紹介されました。 [4D2-OS-33b] AIを活用したマーケティング実践 ZOZOの広渡です。会期4日目である5月30日（金）には、オーガナイズドセッション「AIを活用したマーケティング実践」が開催されました。同セッションではAIを活用したマーケティングの実践事例や課題が紹介されました。以下ではセッションの各発表の内容について簡単にレポートいたします。 [4D2-OS-33b-01] LLMを活用したペルソナベースのデルファイ法による多視点アイディア評価 デルファイ法は、専門家の意見を集約し、未来予測や合意形成に広く用いられるアンケート手法です。本発表では、LLMを活用したペルソナとファシリテーターに基づくデルファイ法によって、多様な視点からのアイデア評価手法の実験が行われました。 具体的には、年齢や性別の異なる15種類のAIペルソナを作成し、各ペルソナが自身の属性に従って独自に10種類の評価項目を選択してアイデアを評価します。ファシリテーター役のLLMが全AIペルソナの評価結果を集計・要約し、そのフィードバックを基に各AIペルソナが評価項目を見直してアイデアを再評価するという反復プロセスを3回繰り返します。 実験の結果、ペルソナの属性によって評価項目の選択に特徴があることが示唆されました。評価を重ねるごとに選択される評価項目の種類は収束し、平均評価スコアも上昇する傾向が示されました。これらの結果から、AIペルソナベースのデルファイ法により、多角的な視点を取り入れた評価を低コストで実現できる可能性が示唆されました。 [4D2-OS-33b-02] 深掘り質問促進のための LLM を活用した動的プロンプト制御型顧客インタビュートレーニングシステム 近年、顧客の潜在ニーズ把握の重要性が高まる中、本発表では、LLMをインタビュイーとして活用する顧客インタビュートレーニングシステムが提案されました。このシステムは、対話の進行に応じてプロンプトの情報を動的に更新することで、ユーザーが適切な深掘り質問を行わなければ潜在ニーズを引き出せない仕組みを構築しています。 具体的には、顧客情報を3段階の階層構造で管理し、ユーザが質問を通じてシステムから情報を聞き出すと、追加情報がプロンプトに追記されます。 被験者8名が提案手法とベースライン手法（全情報を最初からプロンプトに含める）で計2回トレーニングを行いました。提案手法を用いたグループでは、2回目のトレーニングにおける質問数（ユーザーが行った質問の回数）が1回目と比較して平均148.89％増加したのに対し、ベースライン手法では35.00％の増加にとどまりました。また、1つの情報を得るために必要な質問数は、提案手法がベースライン手法の最大4倍となり、深掘り質問の促進に有効であることが示されました。 [4D2-OS-33b-03] 生成AIとジョブ理論で作る顧客中心型CRM 本発表では、顧客関係管理（CRM）における従来の静的なセグメンテーションの限界を克服するため、生成AIとジョブ理論を統合した顧客中心型CRM戦略を提案しています。この戦略は、生成AIを活用した動的な顧客プロファイル生成により、例えば「仕事後にリラックスしたい」顧客にはカフェの割引のインセンティブを提供するなど、リアルタイムで適応可能なパーソナライゼーションを実現することが目的です。 提案手法では、オープンソースの米国クレジット与信データを活用し、Googleの生成AI「Gemini」を用いて顧客プロファイルを生成します。さらに、生成されたプロファイルに基づき、各顧客に最適なインセンティブを生成します。 生成AIを用いた顧客プロファイル生成では、顧客の基本属性を適切に再現できることが確認できました。さらに生成AIにより生成した200件の顧客プロファイルを基に人間による補正と再学習を経て、最終的に1000件のインセンティブを生成し、ターゲット顧客の購買行動との一致度が向上したと報告されています。 [4D2-OS-33b-04] 広告デザイン改善のための代替案生成手法 本発表では、広告デザインの改善を支援するため、過去の広告データを活用した代替案生成手法を提案しています。デザイナーが広告デザインを作成した際に、改善の方向性を見出すことが難しく、広告を効率的に作成しづらいという課題を解決することが目的です。 提案手法は、学習段階とデザインプロセスの2段階で構成されます。まず、学習段階では、Photoshopデータから広告の視覚要素（色、レイアウトなど）を特徴量として抽出し、クリック率（CTR）を目的変数として決定木モデルを学習します。決定木モデルには、平均二乗誤差と決定係数がXGBoostより優れていたCatBoostが採用されました。次に、デザインプロセスでは、新しく作成された広告の特徴量を抽出し、学習済みモデルでCTRを予測します。この際、Tree SHAPを用いて、各特徴量の予測結果への影響度を解析し、最も負の影響を与えている特徴量を「改善箇所」とみなします。特定された改善箇所に対しては、ヒューリスティックな変換（指定された特徴量の類似色や補色への変換など）を適用し、複数の代替広告デザインが生成されます。 実験では、「クリックを促すボタンの色」が最も負の影響を与えていると判断され、ヒューリスティック変換を施されている例が示されています。これにより、改善箇所が元の画像よりも濃い色や、補色に変換された画像が生成され、これまで検討されていなかった細かな色の違いを把握し比較できると報告されています。 [4D2-OS-33b-05] 双方向推薦システムにおけるコントラスト効果の応用 コントラスト効果は、ある対象を別の対象と比較して提示することで、相対的な価値や魅力が変動する心理的効果を指します。本発表では、「コントラスト効果」を求人検索プラットフォームのような双方向推薦システムに応用することで、従来の推薦システムが抱えていた課題の解決を目指しています。従来の推薦システムは、主にユーザーとアイテムの適合度計算に基づいて推薦を行うため、提示順序や比較対象といった相対的な魅力を形成する要素を十分に考慮していませんでした。また、短期的なマッチング数の最大化に偏りがちであり、長期的な効果を加味しにくい、利用者の状態変化に対する柔軟性が低いという問題がありました。 提案手法では、求職者のオンライン行動による潜在的なマッチングの増加分を評価関数に組み込みます。これにより、求職者の活動状況や登録からの経過日数に応じて、「オンライン行動重視度」と「マッチング重視度」を動的に調整することが可能になります。 実際の求人検索プラットフォームを利用し一部の求職者を対象にA/Bテストを実施した結果、提案手法の評価関数を用いて推薦するグループの方が従来の評価関数を用いるよりも、オンライン行動とマッチング行動がともに増加することを確認したと報告されています。 まとめ 本記事では、JSAI2025の一部セッションの内容をご報告しました。参加を通じて、多くの新たな知見を得ることができました。特に印象的だったのは、LLMの進化が多岐にわたる研究分野に与える影響の大きさです。AI技術が具体的な課題解決に活用されている事例を数多く目の当たりにし、その応用可能性の広がりを実感しました。ここで得た知見を糧に、私たちも人工知能研究の進展に貢献できるよう、一層邁進してまいります。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

はじめに こんにちは、 ZOZOMO店舗在庫取り置き サービスの開発を担当しているZOZOMO部OMOブロックの木目沢です。 現代のソフトウェア開発において、変化の激しい環境に柔軟に対応できるチーム作りは重要な課題です。特に複数のプロダクトを扱う開発チームでは、メンバー全員が自律的に動き、状況に応じて適切な判断ができる「自己組織化されたチーム」の実現が求められます。 ZOZOMO部OMOブロックでは、ZOZOMO店舗在庫取り置きを取り扱ってきましたが、現在は別のサービスの開発も行っています。そこで2つのプロダクトを扱う開発チームの自己組織化を目指し、昨年度に様々な取り組みを実施しました。結果的に、主要な取り組みは5つに整理されます。 本記事では、これらの取り組みがどのような背景から始まり、具体的にどのような方法で実践され、どのような成果をもたらしたかを詳しく紹介します。同じような課題を抱える開発チームの参考になれば幸いです。 目次 はじめに 目次 なぜチームの自己組織化を目指したのか 複数プロダクトへの対応力強化 ボトルネックの解消 チーム全体の知識レベル向上 5つのTRYによる具体的な取り組み TRY 1: 理想のチームの定義と計測 TRY 2: 状況に応じた開発プロセスの選択 TRY 3: モブプログラミングとソロプログラミングとNo issue, no work. TRY 4: レトロスペクティブとワーキングアグリーメント TRY 5: 仕様の調整から開発チームに任す チームでできることが増えていけばメンバーもさらに輝く 自己組織化による新たな課題と今後の展望 おわりに なぜチームの自己組織化を目指したのか 私たちが自己組織化という目標を掲げた背景には、主に以下の理由があります。 複数プロダクトへの対応力強化 まず、OMOブロックは、現在開発中であるサービスとZOZOMO店舗在庫取り置きという2つのプロダクトを扱っています。現状では、この別サービスの開発に注力しており、ZOZOMO店舗在庫取り置きの開発はほぼ停止している状況です。いずれZOZOMO店舗在庫取り置きの開発も再開するため、各プロダクトに専用のチームを設けることが理想的だと認識していますが、当面の間は1つのチームで両方のプロダクトに対応する必要があります。そのため、今後どのような状況でも、チームが柔軟に動けるようにしたいという強い意図がありました。 ボトルネックの解消 次に、これまでの開発体制では、上長による細かい指示で開発を進めることとなっており、そのため、上長自身がボトルネックになる可能性がありました。より迅速かつ効率的に開発を進めるためには、この体制を改善する必要があったのです。 チーム全体の知識レベル向上 そして何より、チームメンバー全員がプロダクトを深く理解し、自ら考えて動けるようになることが不可欠だと考えました。経験の浅いメンバーや育休から復帰したメンバーなどチームには様々な背景をもったメンバーがおり、そのため、個々人の成長とチーム全体での知識共有が強く求められていました。 これらの課題を解決し、どんな変化にも対応できるチームとなるため、私たちは自己組織化という目標を掲げました。 5つのTRYによる具体的な取り組み 自己組織化を実現するために、OMOブロックでは昨年度に様々な取り組みを行いました。振り返ってみると、主要な取り組みは以下の5つに整理されます。 TRY 1: 理想のチームの定義と計測 まず、チーム全員で「理想のチーム」とは何かを定義するワークを開催しました。この定義には、人材開発ブロックのメンバーにファシリテーションの協力を依頼しました。普段ファシリテーションを担当するメンバーも他の参加者と同じ目線で参加し、不要なバイアスがかからないようにするためです。 定義するだけでなく、毎週点数をつけてチームの成長を計測しました。これにより、チームの目指す方向性を明確にし、具体的な改善活動（カイゼン）につなげられました。この計測により、自分たちが考えた理想像に向かおうとする姿勢を得点の推移から伺えるようになりました。 TRY 2: 状況に応じた開発プロセスの選択 開発の「HOW（どのように）」を既知のフレームワークやプラクティスを採用することで見える化し、状況に応じた開発プロセスの選択による継続的な改善を図りました。チームは自分たちの状況に合わせて、開発の進め方を柔軟に変えるようになりました。 具体的には、昨年度のZOZOMO店舗在庫取り置き開発期には「スクラム（1週間スプリント）」を採用しました。昨年度上期の別サービスのモック開発期には「スクラム（1日スプリント）」、昨年度下期には「Kanban」、そして現在は「スパイラル型」を採用しています。これは、柔軟な転換の必要性、モック開発の迅速化、時間的制約などの理由によります。 TRY 3: モブプログラミングとソロプログラミングとNo issue, no work. 単独作業のタスクを除いて、原則としてモブプログラミングで実装を進めました。これにより、チーム全員がプロダクトの仕様を深く理解し、誰でも対応できる状況を作り出すことを目指しました。 モブプログラミングでは、Gatherというツールを使って実施され、ドライバーとナビゲーターの役割を交代しながら作業を進めます。 モブプログラミングのチーム内でのルールはチームで議論をした上でチームメンバー全員の合意を取っており、ワーキングアグリーメントという文書にまとめられています。その一部を紹介します。 また、すべての作業において"No issue, no work."を徹底し、プログラミングに限らず設計や調査、会議準備なども含めたあらゆる作業を見える化して改善の対象としました。上長の仕事ももちろん"No issue, no work."を徹底しています。これらの取り組みにより、タスクが特定の個人に集中することがなくなり、チーム全体で改善の対象として考えるようになりました。 TRY 4: レトロスペクティブとワーキングアグリーメント 開発プロセスが変化しても、毎週レトロスペクティブ（振り返り）を欠かさず実施しました。レトロスペクティブの結果、カイゼンした習慣をワーキングアグリーメントに文書化しました。また、ワーキングアグリーメント自体もカイゼンの対象とすることで、チーム自らが改善のサイクルを回せるようにしました。 先程はモブプログラミングのワーキングアグリーメントを紹介しましたが、他にもいくつか紹介します。 以下はレビューに関するワーキングアグリーメントです。 こちらはチームの活動に関するワーキングアグリーメントです。 TRY 5: 仕様の調整から開発チームに任す これまで上長が細かく指示を出したり外部からの依頼を受けたりするやり方から、開発チームが自ら調整依頼を受けて素早く対応できる方針へと変更しました。 なぜやるのかというところや優先順位を含め、最終的な責任は引き続き上長が持ちます。一方で上長はあれこれ指示をする代わりに開発チームへの支援を強化し、チームの動きを観察したりコーチングを行ったりする役割を担うようになりました。時には改善を提案することもあります。この変化により、外部との調整にかかる時間や伝言ゲームによる伝達ミスが減り、開発チームはプロダクトについてより深く理解するようになりました。 結果、チームは自ら考えて動けるようになるという大きなメリットを得られました。その反面、開発チーム自身が調整業務を担うことで、純粋な開発にかけられる時間が多少減るというデメリットも生じています。しかし現時点では、メリットの方が上回っているためこの取り組みを継続しています。 チームでできることが増えていけばメンバーもさらに輝く まだまだ途上で今後も多くの挑戦が必要ですが、チームの自己組織化は進み、状況に応じ柔軟にチームで対応できる力が付いてきました。また、これまで紹介してきた内容は、チームが自らでできる幅を広げ（広さ）経験をさらに深める（深さ）施策でした。これらをプロダクト開発のライフサイクルにマッピングさせてみると、ただものを作るだけのチームではなく、プロダクトとして全体を捉えるようになってきていると言えます。 これらのことはさらにチームメンバーがそれぞれやりたいこと・実現したいことの発見に繋がり、自己実現の場としてもチームを捉えることもできそうです。 自己組織化による新たな課題と今後の展望 自己組織化により多くの成果を得られた一方で、新たな課題も見えてきています。このままさらに開発チームへの権限委譲を進め、チームの活動を広げていくと純粋な開発に集中できる時間の減少という問題を生じる可能性があります。 このジレンマを解決するために、以下のようなアプローチが有効だと考えています。 まず、直近で対応する課題のみを仕様の調整の対象とすることで、調整業務の範囲を限定し開発時間への影響を最小化します。長期的な課題や将来的な要件については詳細な整理や調整を遅らせることで、開発チームが日常的に対処する調整業務から切り離すことができます。 これはスクラムで採用されるプラクティスの一部です。つまり、プロダクトを扱うようになりより複雑化していく状況においては、スクラムの適用が特に有効になっていきます。スプリント単位で開発サイクルを区切り、リファインメントを別途行うこと、直近で対応する課題のみを扱うことで開発に集中できます。 加えて、昨今話題の生成AIエージェントの活用により、効率的にソースコードを書く時間を削減できそうです。さらにテストコード、ドキュメント、バグ修正など開発における幅広い領域での活用が期待できます。これにより、チームとしてよりコアとなる部分に多くの時間を割けるようになります。 スクラムをはじめとしたアジャイルの追求と生成AIエージェントの活用により、チームはさらに自己組織化を進めていくことでプロダクトにコミットできていくと考えています。 おわりに 自己組織化への挑戦は、OMOブロックに大きな変化と成長をもたらしました。チームメンバー全員がプロダクトの理解を深め、自律的に動くことで、変化の激しいプロダクト開発に柔軟に対応するようになっています。私たちはこれからも、変化に対応できる強くしなやかなチームを目指して、挑戦を続けていきます。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com 最後までご覧いただきありがとうございました！

はじめに こんにちは、ZOZOTOWNアプリのバックエンド開発を担当している佐藤です。弊社では、お客様からの問い合わせに対して、開発エンジニアも調査に関わります。この記事では、OpenAI社のEmbedding APIを活用し、お客様への返信プロセスを簡略化した事例をご紹介します。 目次 はじめに 目次 課題 解決アプローチ 主な技術構成 補足事項 導入による効果 属人化の排除 作業コストの削減 得られた学び まとめ さいごに 課題 開発部門が対応するお客様への返信プロセスについて、既存の対応フローは以下の通りでした。 問い合わせを調査する上で、「対応チームへのエスカレーション判断が属人化している」ことに課題感がありました。ZOZOTOWNの仕様全般に関する問い合わせは1つのSlackチャンネルで受け付けており、担当チームが多岐にわたるため、振り分け役が必要でした。この状況により以下の問題が発生していました。 内容の精査と担当チームへの振り分けが特定メンバーに依存 月100件程度の通知を捌くため、エンジニアの作業が中断される 会議などでアサインが遅れると、リードタイムに影響する 担当不明・アサイン漏れなどのヒューマンエラーが生じる 解決アプローチ これらの課題をまとめて解消するため、エスカレーションの振り分けを自動化できないか検討しました。もともと問い合わせ対応のデータはGoogleスプレッドシートで個人情報を省いた状態で管理しており、類似判定に使える十分な事例データが揃っていました。そのため、対応データを元に担当チームを特定できるEmbedding APIを選定しました。主な技術構成は以下の通りですが、なるべくコストをかけない制約の中で、適切な対応チームをSlackで自動メンションする「問い合わせ自動振り分けBot」ができました。 主な技術構成 ツール・サービス 役割・用途 Slack 問い合わせ投稿（ワークフロー）と調査ログの管理 Zapier Slack投稿をトリガーに、Embedding APIを呼び出す。結果をスプレッドシートに登録する Embedding API 問い合わせ文をベクトル形式に変換 GAS（Google Apps Script） ベクトル比較処理、Slack通知メッセージの生成 Googleスプレッドシート 問い合わせ内容、ベクトル、回答までのリードタイムなどの情報を一元管理 補足事項 当初Zapierでは類似度計算ができなかったため、比較処理はGASで代替 Googleスプレッドシートには自動で振り分けられたチームと実際に対応したチームを記録し、精度改善に活用 Embedding APIの利用コストは月間約100件で 1円未満 に収まっており、ランニングコストも非常に低い 導入による効果 属人化の排除 特定メンバーや時間帯に依存しない即時対応が可能になった 月単位の 正答率は約82％ で、例外的な問い合わせだけを人が対応すれば良い状態になった 作業コストの削減 通知処理の自動化により、他作業への割り込みが解消できた 回答までの平均リードタイムが 約0.4営業日短縮 と、シームレスな返信が実現できるようになった 得られた学び データ蓄積 が属人化を解消に効果的であった Slack・Zapier・GASの構成は 小規模から導入しやすく、柔軟なスケーラビリティ を持つ Embedding APIの活用により、 過去の問い合わせ知見を機械的に再利用 する仕組みを作れた まとめ データを取ること自体が業務改善に繋がり、日々の「ちょっとした判断」や「仕分け作業」からでも無理なく始められることが分かりました。Slackを起点とした業務オーケストレーターは拡張性があり、Embedding APIを組み合わせることで、属人化や作業負荷といった課題は着実に解消されました。なにより、「一秒でも早くお客様に返答したい！」という想いを、届けられる体制を作れたことが最大の成果となりました。 さいごに ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

はじめに こんにちは、データサイエンス部の 朝原 です。普段はZOZOTOWNにおける検索の改善を担当しています。 ZOZOTOWNには100万点を超える商品が存在し、毎日2700点もの新商品が追加されています。このような膨大な商品数を扱うZOZOTOWNにおいて、ユーザーが求める商品を見つけやすくするための検索機能は非常に重要です。 一方で、ファッションという日々ニーズが激しく変化するドメインにおいて、ユーザーのニーズを検索クエリから正確に把握し、適切な商品を提示することは困難を伴います。特に、検索システムにおいて検索結果が0件である（以下　0件ヒット）ことはユーザーにとって悪い体験となり、離脱を招いてしまいます 1 。実際にZOZOTOWNでは、日々0件ヒットが発生しており、大きな課題となっています。 本記事では、検索結果が0件になる主な原因と、その対策の1つであるクエリ書き換えについて紹介します。 目次 はじめに 目次 背景 なぜ0件ヒットが起こるのか 1. タイポやスペルミス 2. 表記揺れ 3. 検索条件が限定的である クエリ書き換えとは クエリ拡張 辞書を用いた関連語の追加 類似度を用いた関連語の追加 スペルミスの修正 クエリ緩和 スコアリングによるクエリ緩和 End-to-Endなクエリ書き換え グラフニューラルネットワークによって検索履歴を考慮 強化学習を用いた生成モデルによるクエリ書き換え まとめ 背景 ECサイトにおいて0件ヒットは離脱を引き起こし、購買の機会損失にもつながる大きな問題です。実際にZOZOTOWNでも0件ヒットは発生しており、以下は「レディース」と入力するつもりが「レデース」と入力してしまった場合の検索結果です。 0件ヒットとなった場合は別のクエリを試すように促されますが、ユーザーは検索条件を一から見直して再入力しなければならず、手間がかかります。 なぜ0件ヒットが起こるのか では、なぜ0件ヒットが起こるのでしょうか。0件ヒットの原因は様々ですが、一般に次のような原因が考えられます。 1. タイポやスペルミス ユーザーが検索キーワードを入力する際に、意図した単語を正確に入力できていないケースです。 例） 「レディース」と検索するつもりが「レデース」と入力 「アクセサリー」と検索するつもりが「アクsesari-」と入力 「ワンピース」と検索するつもりが「ワンスピ」と入力 上記のように、本来意図した単語から一部の文字が異なっていると、検索システムに登録している商品名や属性情報と完全に一致せず、0件ヒットとなることがあります。 2. 表記揺れ ユーザーが検索に使った単語が、検索システム側の商品情報に登録されている単語と意味は同じでも表現が異なるケースです。一般的なものとしては、同じ単語であっても、カタカナ・ひらがな・漢字・英字・全角半角・送り仮名などの違いによって表記が揺れるケースです。例としては、以下が挙げられます。 例） システムでは「子供服」と登録されているが、「こども服」と検索された システムでは「ZOZOTOWN」と登録されているが、「ゾゾタウン」と検索された また、ファッション分野では同じ意味を持つ単語でもトレンドによって呼び方が変わりやすく、さらに略語や別名が多く存在します。例えば、以下のようなケースが考えられます。 例） ユーザーは「カバン」と検索したが、システムでは「バッグ」で登録されている ユーザーは「オーバーオール」と検索したが、システムでは「サロペット」で登録されている 時代の流れで、「ズボン」が「パンツ」と呼ばれるようになった システムがこれらの差異や関連性を認識していない場合、ユーザーの入力クエリを商品と関連付けられず、0件ヒットとなることがあります。ファッションにおけるトレンドの変化は著しく、常に最新の単語へ対応することも容易ではありません。 3. 検索条件が限定的である 複数の条件を組み合わせて検索した場合に、その組み合わせに完全に一致する商品が1つも存在しないケースです。個々の条件に合致する商品は存在するものの、ユーザーが指定した全ての条件を満たす商品が存在しない場合に0件ヒットとなります。 例） 「赤 AND 花柄 AND フレアスカート」 赤いフレアスカートは扱っているが、赤い花柄のフレアスカートは扱っていない 「ワンピース AND 花柄 AND 4Lサイズ」 他の条件に該当する商品は存在するが、そもそも4Lサイズを取り扱っていない ユーザーが詳細な条件で絞り込もうとするほど、完全にマッチするアイテムが減少し、0件ヒットのリスクは高まります。 このような問題を解決するためのアプローチの1つが、「クエリ書き換え（Query Rewriting）」です。本記事では、クエリ書き換えの手法とその効果について解説します。 クエリ書き換えとは クエリ書き換えとは、ユーザーが入力した検索クエリを、より検索システムに適した形へ自動的に変換する技術のことです。クエリ書き換えの目的はRecallとPrecisionの向上です。そのため、ユーザーの検索意図を保持しつつ、より多くの関連商品を正確にヒットさせることを目指します。0件ヒットの削減においては「商品が見つからない」状態の解消が重要であるため、ヒットする関連商品を増やし、Recallを向上させることが主な目的です。 一方で、ユーザーの入力したクエリを書き換えることは、検索意図をシステムが誤解するリスクも伴います。そのため、スペルミスの修正など、クエリを書き換えた際はユーザーが元のクエリに戻るための動線を提供することが重要です 2 。例えば、以下のように検索窓の真下に書き換え後のクエリと元のクエリを表示します。これによってシステムがユーザーの意図を誤解して書き換えてしまった場合でも、元のクエリをクリックすることでユーザーは意図した検索結果を得ることができます。 それではクエリ書き換えの手法について、古典的なルールベースの手法から2025年現在の最新の手法まで、いくつか紹介します。 クエリ拡張 クエリ拡張とは、ユーザーが入力した検索クエリに対して、関連するキーワードやフレーズを追加する手法です。これにより検索のRecallを向上させ、より多くの関連商品や情報をユーザーに提供できます。 例えば、元のクエリが「レディース OR フレアスカート」の場合、クエリ拡張によって「レディース OR フレアスカート OR スカート」などの関連キーワードが追加され、より多くの商品がヒットするようになります。 クエリ拡張にはシソーラス辞書やドメイン独自の辞書を用いる手法、単語の類似度を計算して関連語を追加する手法などがあります。それぞれの手法について見ていきましょう。 辞書を用いた関連語の追加 辞書を用いて検索クエリ内の各単語に対して類似するクエリを追加する手法を紹介します 3 。例えば、「バケットハット」という単語に関連する単語として「帽子」という、より上位概念の単語を辞書に登録しておきます。これらを0件ヒット時に拡張するクエリとして用いることで、バケットハットを取り扱っていない場合でも帽子という大きなカテゴリとして検索した結果をユーザーに提供できます。 それでは実際に日本語のWordNetから上位概念を取得してみましょう。日本語WordNetには「バケットハット」という単語が登録されていないため、「ローファー」という単語を試してみます。今回は NLTK というPythonの自然言語処理ライブラリを用いて、WordNetから日本語の上位概念を取得するコードを以下に示します。 from nltk.corpus import wordnet as wn word = 'ローファー' synsets = wn.synsets(word, lang= 'jpn' ) syn = synsets[ 0 ] hypernym_jp_names = sorted ( list ( set ( ', ' .join(lemma.name() for lemma in h_syn.lemmas( 'jpn' )) for h_syn in syn.hypernyms() if h_syn.lemmas( 'jpn' ) ))) print (hypernym_jp_names) # 出力結果 # ['靴'] このようにWordNetのような辞書を用いることで、単語の上位概念を取得し、意味的に重複した語句を削除できます。 一方で、前述した通り「バケットハット」という単語はWordNetには存在しませんが、ZOZOTOWNを含め多くのファッションECサイトで利用される用語です。このように検索システムのドメインに特化している語句は、独自の辞書に登録しておく必要があります。ファッションドメインでは、トレンドの変化によって新しい単語や表現が頻繁に登場します。そのため、それらに常時対応し続けること自体が容易ではありません。 類似度を用いた関連語の追加 ユーザーが入力したクエリに対して、機械的に計算した類似度によって追加するクエリを選定する手法を紹介します 4 。 例えば事前学習済み言語モデルを用いてユーザの入力クエリ $q$ の各単語 $t_q$ と追加候補の単語 $t_c$ のベクトル $\vec{v}_{t_q}$ 、 $\vec{v}_{t_c}$ を計算し、以下のようにコサイン類似度を用いて類似度を計算します。 引用： An Introduction to Neural Information Retrieval そして、最も類似度が高い候補の単語をクエリに追加するという流れです。 スペルミスの修正 ユーザーの入力した検索クエリに対して、スペルミスを修正することで、サービス側が意図した検索結果を得られるようにします 5 。スペルミスへの対応は弊社の以下の記事で詳しく解説しているので、ぜひご覧ください。 techblog.zozo.com クエリ緩和 クエリ緩和 6 とは、検索クエリから特定の単語（修飾語やストップワードなど）や意味的に重複している語句を削除することで、検索条件を緩和して多くの検索結果を得る手法です。 ECサイトにおいて実際に不要なクエリを削除することで、0件ヒットになるクエリの約27％が1件以上ヒットするクエリに書き換えられたという研究もあります 7 。 例えば、元のクエリが「レディース スカート 安い チェック柄」の場合、「安い」という修飾語を削除して「レディース スカート チェック柄」とすることで、より多くの商品がヒットするようになります。 このように、0件ヒットの原因として挙げた「検索条件が限定的である」場合に特に有効な手法で、複雑なクエリをシンプルにすることで、検索結果を増やすことができます。 一方で、検索結果がユーザーの意図を十分に満たしており、かつ十分な数の商品がヒットする場合は注意すべきです。そのような場合にクエリ緩和をするとユーザーの意図しない商品が多数表示されてしまう可能性もあるため、慎重に行う必要があります。よって、クエリ緩和は主に検索結果が0件であった場合やユーザーの意図した商品が見つからない場合に適用されることが多いです。ただし、検索結果数が増えたとしても、良い検索結果が得られるとは限らない点に注意が必要です。 スコアリングによるクエリ緩和 クエリ緩和では検索クエリから特定の単語を削除しますが、重要な点はどの単語を削除するかです。TanらはECサイトにおける0件ヒットのクエリに対して、各単語の重要度をスコアリングし、スコアが低い単語から削除する手法を提案しています 8 。 まずは、ブランド名や商品名をTier 1、色やサイズなどの属性をTier 2、その他の単語をTier 3のように、単語を重要度の高い順にTier分けします。これらの振り分けは基本的に辞書ベースですが、一般的な名詞で構成されるブランド名も存在します。そのため、機械学習モデルによってその単語がブランド名であるかどうかの判定も行っています。こうして得られた単語のTierや、その単語が含まれている検索ログからクリック率を取得し、最終的な重要度スコアを計算します。 提案手法ではRecallの向上が見られましたが、一方でクエリに含まれる単語数が少ない場合にはクエリの検索意図が大きく変化してしまうケースもあったと報告されています。 引用： Query Rewrite for Null and Low Search Results in eCommerce End-to-Endなクエリ書き換え ここまでは辞書やベクトルによって追加・削除する単語を取得する間接的なクエリ書き換えの手法を紹介してきました。機械学習の技術が進化するにつれて、ユーザーの入力クエリを言語モデルに入力し、直接書き換え後のクエリを出力するEnd-to-Endなクエリ書き換えの手法の研究も盛んになってきました。本章ではそのようなEnd-to-Endなクエリ書き換えの手法を紹介します。 グラフニューラルネットワークによって検索履歴を考慮 ここまで紹介してきた手法は、いずれも書き換え対象のクエリのみを考慮していました。Zuoらの研究ではユーザーが過去に検索したクエリを考慮したクエリ書き換えをすることで、ユーザーごとの多様な検索意図に合ったクエリを提供する手法を提案しています 9 。 例えば、「パンツ 安い」というクエリのみではユーザーがいわゆる「ズボン」のようなものを求めているのか、下着としての「パンツ」を求めているのかは分かりません。そこで、ユーザーが1つ前の検索で「デニムパンツ」と検索していたとします。この場合はユーザーは下着ではなく、下着の上に履く「パンツ」を求めている可能性が高いため、「ボトムス パンツ 安い」といったクエリに書き換えるのが良さそうです。 このように、ユーザーの過去の検索履歴を考慮することで、よりユーザーの意図に合ったクエリの書き換えが期待できます。 この実現のため、GAT（Graph Attention Network）を用いてユーザーの検索履歴をグラフ構造として表現し、クエリ間の関係性を考慮したクエリ書き換えを提案しています。提案モデルはECサイトの社内データを利用したオフライン評価で、ベースラインを上回る性能を示しました。また、オンラインのA/Bテストを通じて収益の向上が見られたほか、クエリ書き換えによって望んだ商品まで到達するまでの検索数が減少したことも確認されました。 引用： Context-Aware Query Rewriting for Improving Users’ Search Experience on E-commerce Websites 強化学習を用いた生成モデルによるクエリ書き換え 生成モデルを用いたクエリ書き換えは辞書ベースと異なり、以下のような問題があります。 生成されるクエリに多様性がない 元のクエリに対する検索結果と類似しやすい WebやECサイト検索においては、レイテンシやコストの観点からリアルタイムでの書き換えは難しい 生成されたクエリが商品のカバレッジを向上させるかはわからない そこで、Agrawalらの研究では生成モデルと強化学習を組み合わせることで、元のクエリの意図を保持しつつ、検索結果の多様性が高いクエリに書き換える手法を提案しています 10 。元のクエリの意図を保持するために、2つのクエリ間の類似度を計算するモデルを学習し、モデルの出力するスコアを報酬としています。また、書き換え後のクエリが多くの商品をヒットさせるように、書き換え後のクエリによってヒットする商品の数も報酬として与えています。 提案モデルを利用し、ユーザーの過去の入力に対するクエリを書き換え、データベース等にキャッシュします。オンラインではユーザーが検索クエリを入力した際に、キャッシュから書き換え後のクエリを取得して再検索するため、生成モデルを利用しながらも非常に低いレイテンシでのクエリ書き換えを実現しています。 また、提案モデルはベースラインの生成モデルと比較して、カバレッジが28％向上したと報告されています。 引用： Enhancing e-commerce product search through reinforcement learning-powered query reformulation まとめ 今回は0件ヒットの回避に焦点を当て、クエリ書き換えの手法についてルールベースや機械学習を用いたアプローチを紹介しました。 検索結果が0件ヒットとなることは、ユーザーにとって悪い体験となり、離脱や機会損失に繋がる可能性があります。この問題は、ユーザーによる入力ミス（タイポやスペルミス）や言葉の多様な表現（同義語・類義語、表記ゆれ）、検索条件の絞り込みすぎなど、様々な要因で発生します。また、ファッションドメインではトレンドの変化によって新しい単語や表現が頻繁に登場します。そのため、常に最新の単語に対応することは、決して容易ではありません。 ZOZOTOWNの検索機能においても、0件ヒットを減らし、ユーザーが求める商品をよりスムーズに見つけられるようにすることは、継続的な課題です。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com Baymardの研究で「 Designing the "No Results" Page 」にも同様な言及がなされています。 ↩ Baymardの研究で「 Handling Misspellings on Search Results Pages 」にも同様の言及がなされています。 ↩ Christopher D. Manning, Prabhakar Raghavan, Hinrich Schütze. Introduction to Information Retrieval . Cambridge University Press, Chapter 9,2008. ↩ Bhaskar Mitra, Nick Craswell. An Introduction to Neural Information Retrieval . Microsoft Research, pages 49-50, 2018. ↩ Christopher D. Manning, Prabhakar Raghavan, Hinrich Schütze. Introduction to Information Retrieval . Cambridge University Press, Chapter 3,2008. ↩ Hurtado, Carlos A. and Poulovassilis, Alexandra and Wood, Peter T. A Relaxed Approach to RDF Querying . The Semantic Web - ISWC 2006, pages 314-328, 2006. ↩ Yuki Amemiya, Tomohiro Manabe, Sumio Fujita and Tetsuya Sakai. How Do Users Revise Zero-Hit Product Search Queries? . ECIR 2021. ↩ Tan, Zehong, Canran Xu, Mengjie Jiang, Hua Yang and Xiaoyuan Wu. “ Query Rewrite for Null and Low Search Results in eCommerce. ” eCOM@SIGIR (2017). ↩ Simiao Zuo, Qingyu Yin, Haoming Jiang, Shaohui Xi, Bing Yin, Chao Zhang, and Tuo Zhao. 2023. Context-Aware Query Rewriting for Improving Users’ Search Experience on E-commerce Websites. In Proceedings of the 61st Annual Meeting of the Association for Computational Linguistics (Volume 5: Industry Track), pages 616–628, Toronto, Canada. Association for Computational Linguistics. ↩ Sanjay Agrawal, Srujana Merugu, and Vivek Sembium. 2023. Enhancing E-commerce Product Search through Reinforcement Learning-Powered Query Reformulation. In Proceedings of the 32nd ACM International Conference on Information and Knowledge Management (CIKM '23). Association for Computing Machinery, New York, NY, USA, 4488–4494. ↩

はじめに こんにちは。Developer Engagementブロックの @wiroha です。6月19日に「WWDC25 報告会 at LINEヤフー, ZOZO」を開催しました。Appleの年次開発者イベント「WWDC25」で発表された最新技術や知見について、エンジニアがそれぞれの視点で共有するイベントです。本記事ではオフラインで開催した当日の様子をレポートします！ なお、本イベントはAppleがNDAを締結した開発者にのみ公表している情報を取り扱っており、参加はApple Developer Programに加入している方に限定して実施しました。本レポートもセッションの詳細は割愛し、雰囲気をお伝えできればと思います。 lycorptech-jp.connpass.com 登壇内容まとめ 各社のエンジニアによるLTと、現地に参加したエンジニアによるパネルディスカッションを行いました。 発表タイトル 登壇者 2回目のおつかい S_Shimotori What's new in Foundation Model だーはま What's New in Apple Intelligence Tommy Finally Here! A Native WebView for SwiftUI セータ WWDC25 activities of LINE app MDX Team ikesyo FAANSにおけるWriting Toolsの活用 イッセー パネルディスカッション freddi, Masakaz Ozaki, ikkou 2回目のおつかい LINEヤフーのS_Shimotoriさんによる発表 What's new in Foundation Model ZOZOのだーはまによる発表 What's New in Apple Intelligence LINEヤフーのTommyさんによる発表 Finally Here! A Native WebView for SwiftUI ZOZOのセータによる発表 WWDC25 activities of LINE app MDX Team LINEヤフーのikesyoさんによる発表 FAANSにおけるWriting Toolsの活用 ZOZOのイッセーによる発表 パネルディスカッション パネルディスカッションの様子 パネルディスカッションにはZOZOのikkou、Swift Students Community Japan OrganizerのMasakaz Ozakiさん、LINEヤフーのfreddiさんが登壇しました。WWDC25で気になった発表や実装したいこと、参加して良かったことなどを語らいました。現地でのコミュニケーションが大切というのはみなさん共通の意見で、コミュニティイベントへの参加や海外の有名なエンジニアとの会話などを楽しんだそうです。行くべきおすすめの場所や失敗談といった、今後参加する方の参考になる情報も共有されました。 最後に 今回はWWDC25の最新情報や現地の体験を共有する貴重な場となりました。ご参加いただいた皆さま、ありがとうございました！ ZOZOでは最新情報をキャッチしつつ、一緒にサービスを作り上げてくれる仲間を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 hrmos.co corp.zozo.com

はじめに こんにちは、データシステム部推薦基盤ブロックの棚本（ @i6tsux ）です。 ZOZOTOWNには1,600のショップ、9,000以上のブランド、100万点を超える商品が集まり、毎日2,700点もの新商品が追加されています。この膨大な商品の中から、1,000万人以上のユーザーそれぞれに「これだ」と思える商品を見つけてもらうーーそのためにパーソナライズは欠かせない技術です。 私たちのチームでは、単に好みに合う商品を見せるだけでなく、「新しい商品との出会い」も提供できるパーソナライズを目指しました。ホーム画面のモジュールに表示する商品をユーザーごとに最適な順番で並び替える仕組みを構築し、その結果、 モジュールのクリック商品数が58.3％増加、モジュール経由の受注金額が26.3％増加 という成果を達成しました。 本記事では、この取り組みの背景となった課題から技術的な解決アプローチ、システム構成、そしてA/Bテストで得られた成果まで詳しく解説します。 パーソナライズ機能や推薦システムの開発に携わる方々の参考になれば幸いです。 目次 はじめに 目次 背景・課題 モジュールとは 現状の課題 今回の対象：カテゴリ推薦モジュール パーソナライズロジック 設計方針 Two-Towerモデルとベクトル検索 ベクトル検索基盤の選定 2段階処理の設計 プロトタイピングによる事前検証 パーソナライズシステム システム概要 システム構成 モデルの整合性担保 A/Bテストによる効果検証 テスト概要 結果 まとめと今後の展望 おわりに 背景・課題 モジュールとは ZOZOTOWNのホーム画面は、ユーザーが最初に訪れる場所であり、商品との出会いを生み出す重要な接点となっています。このホーム画面は「モジュール」と呼ばれる商品表示枠で構成され、それぞれが特定のテーマで商品を紹介しています。 例えば、「20代女性向けワンピース」「注目のアウター特集」といった様々な切り口で商品を訴求しています。 現状の課題 従来のシステムでは、モジュール内の商品表示順が全ユーザー共通の人気順になっていました。例えば「20代女性向けワンピース」というモジュールでも、商品は人気順で並べられており、ユーザーの好みや過去の購買履歴に関わらず、全員が同じ商品を同じ順番で見ることになっていたのです。 今回の対象：カテゴリ推薦モジュール この状況を改善するため、モジュール内の商品表示順をユーザーごとに最適化しました。数あるモジュールの中から、まずはホーム画面上部に3つ表示される「カテゴリ推薦モジュール」を対象に選びました。このモジュールは、直近のユーザー行動を元に興味がありそうなカテゴリ（アウター、パンツ、シャツなど）の商品を表示します。 カテゴリ推薦モジュールは2段階の仕組みで動作します。まず、ユーザーごとにパーソナライズされたカテゴリ・ブランドで絞り込み、次にその条件に合う商品を人気順で表示します。しかし、この2段階目の「人気順表示」が課題でした。カテゴリとブランドをパーソナライズしても、商品の表示順が人気順では、パーソナライズの効果が十分に発揮されません。 図1: ZOZOTOWNホーム画面に表示されるカテゴリ推薦モジュールの例 パーソナライズロジック 設計方針 私たち推薦基盤チームは、ZOZOTOWNのパーソナライズ機能全般を担当しています。毎年 OKR という形式でチームの方向性を決めており、今年度は「新たな出会いを目指し、新規性と多様性に重きを置く」という目標を掲げました。これは、関連性だけを追い求めるパーソナライズでは、ユーザーの興味が固定化し、新たな商品との出会いが失われてしまうという考えからです。 このプロジェクトでも、チームのOKRに沿って、新たな出会いを目指して新規性と多様性を重視することにしました。ただし、まったく興味のない商品を見せても意味がないため、関連性も含めた3つの要素をバランスよく組み合わせるアプローチを採用しました。 要素 目指すこと 関連性 ユーザーの興味に合った商品を推薦する 新規性 まだ見たことのない商品と出会える機会を作る 多様性 偏りのない幅広い商品を提案する Two-Towerモデルとベクトル検索 これらの3要素を実現する最大の課題は、1,000万人のユーザーと100万点の商品という膨大な組み合わせの中から、各ユーザーとの関連性が高い商品を見つけ出すことでした。 この課題に対し、 以前の記事 で紹介したTwo-Towerモデルを今回も採用しました。Two-Towerモデルは、ユーザーと商品をそれぞれ独立したニューラルネットワーク（Tower）で処理し、同じ次元のベクトル空間に埋め込む手法です。関連性の高いユーザーと商品のベクトルが互いに近くなるように学習されるため、あるユーザーのベクトルから、そのユーザーに適した商品をベクトル検索（近傍探索）で取得できるようになります。 Two-Towerモデルの詳しい仕組みについては前回の記事をご参照ください。 ベクトル検索基盤の選定 ベクトル検索の基盤として、Google Cloudの Vertex AI Vector Search を採用しました。事前に商品ベクトルを登録しておくことで、ユーザーベクトルと関連性の高い商品を高速に取得できます。採用理由は以下の通りです。 採用理由 詳細 柔軟なフィルタリング機能がある ブランドやカテゴリ、価格などで商品をフィルタリングした上でベクトル検索が可能 多様性確保の仕組みがある クラウディング機能 により、同じ属性値（ブランド、カテゴリなど）の商品数を制限し、検索結果の多様性を確保可能 将来的な拡張性がある 今回はバッチ処理で使用する想定だが、将来的なリアルタイム化の予定があり、これに対応可能 2段階処理の設計 関連性・新規性・多様性を兼ね備えたパーソナライズを実現するため、以下の2段階処理を設計しました。 図2: パーソナライズ処理の2段階アプローチ 第1段階：近傍の商品取得（関連性×多様性） Vertex AI Vector Searchでユーザーベクトルに近い商品を検索することで、 関連性 の高い商品を取得します。同時に、クラウディング機能により同一ブランドを最大3件に制限することで、 多様性 を確保します。これにより、ユーザーの興味に合いながらも、様々なブランドの商品を候補として選出できます。 第2段階：並び順調整（新規性） 取得した商品の中から、最近ユーザーが閲覧した商品にはスコアのペナルティを加え、表示順を調整します。この調整によって、ユーザーがまだ見ていない商品が優先的に表示され、関連性を保ちながら 新規性 の高い商品との出会いが生まれるよう設計しています。 この2段階処理により、関連性・新規性・多様性の3要素すべてを満たしたパーソナライズを実現します。 図3: パーソナライズによって期待される商品表示の変化 プロトタイピングによる事前検証 設計したアプローチの妥当性を確認するため、本格的な開発の前に Gradio で検証ツールを作成しました。 このツールではユーザーIDを入力するだけで、そのユーザー向けにパーソナライズされた商品リストをブラウザ上で確認できます。実際の動作を見ることで、従来の人気順表示との違いが明確になり、ステークホルダーへの説明も効果的に行えました。 プロトタイピングでアプローチの妥当性を確認できたことで、自信を持って本格的な開発に着手できました。 パーソナライズシステム システム概要 上述のようなパーソナライズを本番環境で運用するため、各ユーザーに最適な商品リストを生成・配信するシステムを構築しました。Two-Towerモデルの学習、100万商品のベクトル生成とインデックス更新、1000万人を超えるユーザーへの推薦結果の生成まで、すべてを自動化しています。 システムの中核となるのは、ベクトル検索インデックスと2つのバッチ処理パイプラインです。 日次で実行されるパイプラインはTwo-Towerモデルを学習し、ベクトル検索インデックスを更新します。一方、1時間毎に実行されるパイプラインは、最新のユーザー行動を反映した推薦商品の生成を担当します。生成された結果はBigtableに保存され、ホーム画面表示時に低レイテンシで配信されます。 システム構成 図4: パーソナライズシステムの全体構成 コンポーネント 役割 training-and-indexing-pipeline (Vertex AI Pipelines) 日次で以下の処理を行うパイプライン 1. Two-Towerモデル（User Tower、Product Tower）を訓練してModel Registryに保存 2. Product Towerを使用して全商品（約100万件）のベクトルを生成 3. 生成したベクトルでVertex AI Vector Searchのインデックスを更新 module-personalization-pipeline (Vertex AI Pipelines) 1時間毎に以下の処理を行うパイプライン 1. Model RegistryからUser Towerモデルを取得 2. 最新のユーザー特徴量とUser Towerを使用してユーザーベクトルを生成 3. ユーザーベクトルの近傍商品をVertex AI Vector Searchから取得     a. クラウディング機能を使用し、同一ブランドは最大3件に制限 4. 取得した商品に対して新規性を考慮した並び替え 5. 結果をBigtableに保存 product-vector-index (Vertex AI Vector Search) 全商品ベクトルが格納される高速検索インデックス モデルの整合性担保 User TowerとProduct Towerは必ず同じバージョンのモデルを使用する必要があります。異なるバージョンのモデルを使用すると、ユーザーベクトルと商品ベクトルが異なるベクトル空間に埋め込まれてしまい、類似度計算が意味をなさなくなります。 この問題を防ぐため、以下の仕組みを実装しました。 training-and-indexing-pipelineが新しいモデルを訓練し、商品ベクトルの更新を完了 更新完了後、Model Registryの該当モデルに「現在のインデックスと同期済み」を示すエイリアスを設定 module-personalization-pipelineは常にこのエイリアスが指すモデルを使用 この方式により、商品ベクトルを生成したモデルと同じバージョンでユーザーベクトルが生成されることを保証し、ベクトル空間の整合性を維持しています。 A/Bテストによる効果検証 テスト概要 パーソナライズの効果を定量的に評価するため、以下の設定でA/Bテストを実施しました。 項目 内容 期間 28日間 対象ユーザー数 約500万人 対象モジュール カテゴリ推薦モジュール（ホーム画面の3箇所） Control群 従来の人気順表示 Treatment群 パーソナライズされた並び順（関連性×新規性×多様性） 結果 「新たな出会い」を目指したパーソナライズが、優れたユーザー体験と確かなビジネス成果につながりました。 カテゴリ推薦モジュールの直接的な成果 指標 改善率（Treatment/Control） 1人当たりユニーク商品閲覧数 +18.8% 1人当たりユニークブランド閲覧数 +56.3% 1人当たりユニーク商品クリック数 +58.3% 1人当たりユニークブランドクリック数 +63.3% 1人当たりモジュール経由の受注金額 +26.3% これらの結果から、「新たな出会い」を目指したパーソナライズの成功が確認できます。単に閲覧数が増えただけでなく、クリック数も大幅に増加（商品+58.3％、ブランド+63.3％）している点が重要です。 表示された新しい商品・ブランドがユーザーの興味を引き、積極的にクリックされている ことを示しています。そして受注金額も26.3％向上し、新たな出会いがビジネス価値にも結びつきました。 さらに、モジュール全体のカバレッジ指標（全ユーザーの行動を集計した結果）も大幅に改善しました。 指標（全ユーザー集計） 改善率（Treatment/Control） ユニーク閲覧商品数 +387.9% ユニーク閲覧ブランド数 +62.4% ユニーククリック商品数 +202.2% ユニーククリックブランド数 +92.2% これらの結果から、 パーソナライズによってカテゴリ推薦モジュールで表示される商品・ブランドの種類が大幅に増加した ことがわかります。従来の人気順では限られた商品・ブランドしか表示されませんでしたが、パーソナライズによって各ユーザーに合わせた多様な商品が表示されるようになりました。その結果、閲覧される商品の種類が387.9％増、クリックされる商品の種類も202.2％増という劇的な改善を実現しました。これは、 埋もれていた商品が適切なユーザーに届き、実際に興味を持たれている ことを意味しています。 サイト全体への影響 指標 改善率（Treatment/Control） 1人当たり受注金額 +0.4% 1人当たりお気に入り商品数 +4.3% 1人当たりお気に入りブランド数 +1.4% 1人当たりサイト訪問頻度 +0.2% 1人当たりホーム画面の訪問頻度 +0.2% ホーム画面の3つのモジュールという限定的な変更でありながら、サイト全体のKPIが向上しました。お気に入り登録の増加は、 パーソナライズによって見つけた商品・ブランドに、ユーザーが強い興味を持ち、今後も購入を検討したいと感じた ことを示しています。訪問頻度の向上は、新たな商品との出会いへの期待感を生み出せている証拠です。 特に注目すべきは、1人当たり受注金額が0.4％向上したことです。一見小さな数字に見えますが、 ZOZOTOWNの規模を考えると非常に大きなビジネスインパクト となります。 まとめと今後の展望 私たちは「新たな出会いを目指し、新規性と多様性に重きを置く」というチームのOKRに基づき、ZOZOTOWNホーム画面のパーソナライズに取り組みました。 その結果、1人当たりクリック商品数が58.3％増加、モジュール経由の受注金額が26.3％増加という大きな成果を達成。さらに、表示される商品の種類が387.9％増加し、埋もれていた商品に光を当てることができました。 技術面では、Two-TowerモデルとVertex AI Vector Searchを組み合わせることで、新規性・多様性を意識したパーソナライズを実現できました。また、プロトタイピングによる事前検証の重要性も再認識しました。 今後は、この成功を基に以下の展開を進めていきます。 バッチ推薦からリアルタイム推薦への移行 ホーム画面の他モジュールへの展開 ホーム画面以外への展開 おわりに パーソナライズは技術だけの問題ではありません。どのような価値をユーザーに届けたいのか、その想いを形にする設計が重要です。 本記事で紹介した手法や考え方が、パーソナライズシステムの構築に取り組む皆さまの参考になれば幸いです。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

はじめに 技術戦略部の @ikkou です。XRとキーボードが好きで、特にVision ProとHHKB Studioの組み合わせが大好きです。現地時刻で2025年6月8日〜10日に対面形式で開催された WWDC25のSpecial Event に現地参加してきました。何名かの方に「何回も参加していそう」と言われましたが、初めての現地参加でした！ 本記事では、現地参加ならではのイベントや当日発表された内容について、私の視点から速報としてお伝えします。 はじめに WWDCとSpecial Event Schedule 事前準備 セミナー・カンファレンス参加支援制度 航空券と宿泊先の手配 Wallet passの登録 通信環境と検証用デバイス Day 0 (June 8) Welcome reception Apple Design Awards Day 1 (6/9) Keynote Liquid Glass Apple Intelligence Download station Platforms State of the Union In-person labs Reception in the inner ring Day 2 (June 10) Developer activities (Morning session) 現地でのアクティビティ Run & Walk with Ctrl+Alt+Run - WWDC Edition WWDC25 Vision Pro Community Meetup A Vision Pro Spatial Art Experience for WWDC25 Flatland: Mixed Reality Dreams SpatialComputing Meetup @ WWDC25 さいごに WWDC25関連イベントのお知らせ WWDC25 Recap for Spatial Computing WWDC25 報告会 at LINEヤフー, ZOZO LODGE XR Talk Vol.28 / WWDC25 & AWE USA 2025 Report WWDCとSpecial Event WWDC(Worldwide Developers Conference)は、Appleが毎年開催する 開発者向け のカンファレンスです。Keynote、Platforms State of the Union、そして数多くのセッションやラボが行われ、Appleの最新技術や開発ツールについて学べます。WWDCは、Appleの最新技術を学び、他の開発者と交流する重要な機会です。今年の WWDC25 は6月9日〜13日にオンラインで開催されました。 私が現地参加したSpecial EventはこのWWDC25の一部を構成する 招待制 のイベントです。セッションだけであればオンラインでも事足りますが、例えばオンラインのラボと異なりIn-person LabsではAppleの方から直接フィードバックを受けられます。また、6月10日に開催されたSpecial Sessionも現地参加者のみが参加できるイベントです。 Schedule Date Pacific Time Content Venue Day 0 (June 8) 3 p.m. Welcome reception Infinite Loop Day 1 (June 9) 8 a.m. Check-in Apple Park 10 a.m. Keynote Apple Park 12 p.m. Download station open Apple Park 12 p.m. Lunch Apple Park 1 p.m. Platforms State of the Union Apple Park 2 p.m. In-person labs Apple Park 4-5:30 p.m. Reception in the inner ring Apple Park Day 2 (June 10) 10 a.m. Activities at the Developer Center (Morning Session) Apple Developer Center Cupertino 事前準備 WWDC25 Special Eventの本編が気になる方は Day 0のパート から読み進めてください。ここでは、現地に赴く前の事前準備についてお伝えします。 セミナー・カンファレンス参加支援制度 4月5日の深夜に当選メールが届き、WWDC25のSpecial Eventに参加することが決まりました。この時点で渡航日まで2か月程度しかありませんでした。 ZOZOでは福利厚生の一環として「 セミナー・カンファレンス参加支援制度 」が用意されています。国内の技術カンファレンスはもちろん、WWDCのような海外カンファレンスに参加する際は、事前に申請することで参加費や渡航費はもちろん、宿泊費に現地での交通費などの諸経費を会社が負担してくれます。 私は例年、年始に本制度を利用してCESに参加しているので、今回は本制度を利用した半年ぶりの海外出張でした。単独での海外出張は一定の経験があったので、まずは手早く航空券と宿泊先などを手配しました。 航空券と宿泊先の手配 会場最寄りの空港はサンノゼ国際空港（SJC）ですが、今回は乗継便の関係でサンフランシスコ国際空港（SFO）を利用しました。フライト中は Apple Musicで公開されているWWDC25のプレイリスト を聴きながら、WWDC25への気持ちを高めていました。 music.apple.com SFOから最初の目的地であるInfinite Loopまでの移動は、安価に済ませるならBARTとCaltrain、そしてVTAバスなどの公共交通機関の組み合わせですが、ドア・トゥ・ドアで2時間前後かかります。対してUberを利用すればコストは4倍前後になりますが、30分程度で到着します。今回は“コスパ”より“タイパ”を優先してUberを利用しました。 宿泊先はInfinite Loopから徒歩圏内のわりにコスパの良い Cupertino Hotel にしました。このホテルには他にもWWDC25の参加者が多く宿泊しており、朝食会場やエントランスで車を待っている間などに他の参加者と自然に会話が生まれました。WWDC25の参加者同士での交流は、現地参加の大きな魅力のひとつです。 Wallet passの登録 会期が近づくとWallet passがメールで届きます。WWDC24でも発生していたようですが、当初、 iPhoneの言語設定が「日本語」のままだとWallet passが正常に表示されない 事象が発生していました。言語設定を「英語」に変更してから改めて登録を試みたところ、無事にWallet passが表示されました。このWallet passは、会場でのチェックインに利用します。 通信環境と検証用デバイス 私はiPhone 3G以前からのソフトバンクユーザーです。ソフトバンクには通話とデータ通信がアメリカで使い放題の「 アメリカ放題 」というサービスがあり、これを利用すれば現地での通信環境は概ね賄えます。さらにバックアップとしてAiraloのeSIMを普段遣いのiPhoneにセットして臨みました。 例年、WWDCの期間中に新しいOSが発表され、すぐに開発者のみがインストールできる Developer Preview が公開されます。ここで勢いよく普段遣いのiPhoneをアップデートしてしまうと不測の事態が起きたときに困るので、現地での検証用に予備のiPhoneも持参しています。 同様にVision Proも持ち込んでいますが、さすがにこれは検証用の予備機まで用意できません。visionOS 2の登場時にはアップデートに失敗して Developer Strap に助けられた苦い思い出があります。今回は何も起きないように祈りながら現地に持ち込みました。 Day 0 (June 8) Day 0はSFOに到着後、後述するWWDC25関連イベントを3件こなしてから、Infinite Loopで開催されたWelcome receptionに参加しました。 Welcome reception Welcome Receptionは前日チェックインを兼ねたイベントで、昨年に引き続き今年もAppleの旧本社であるInfinite Loopで開催されました。翌日のメインイベントに早くから並ぶためには、このタイミングでバッジを受け取っておく必要があります。 Appleの方がInfinite Loopの前で記念写真を撮ってくれます。 私は開始時刻の15時少し前にInfinite Loopへたどり着きました。会場には既に多くの参加者が集まっていて、バッジを受け取るための行列ができていました。セキュリティチェックも厳しく、会場内に入れたのは16時過ぎでした。手ぶらでの参加者は、セキュリティチェックに時間がかからないため、行列をパスできます。特にDay 0は大きな荷物を必要とすることはそう多くないので、手ぶらでの参加を強くおすすめします。 個人のADPで当選しているのでZOZO, Inc.の表記がないバッジ。 セキュリティチェックを終えるとテンションの高いAppleの皆さんが出迎えてくれます。自然と自分のテンションも高まります。恥ずかしがらずにハイタッチしていきましょう。ここで期間中に携帯するバッジとノベルティを受け取ります。 バッジとノベルティを受け取るエントランス。 WWDC25のノベルティはトートバッグ・水筒・ストラップ・WWDC25のピンバッジセットでした。 会場に入った後の過ごし方は自由です。定番とも言えるWWDC25のモニュメント前で写真を撮るのはもちろん、どこから来たかピンを挿したり、会場内に用意されていたコーンホールゲームで遊んだりしている方もいました。 お約束のWWDC25モニュメント前での記念撮影。 どこから来たかを示すピンを指すボード（まだ入場していない方も一定数いる16:45時点）。 また、会場内では食べ物と飲み物が無限に提供されていて、食べたり飲んだりしながら参加者同士で楽しく会話するなど、思い思いに過ごしていました。 ハンバーガー系のものの他、唐揚げや小さなまぐろ丼などが用意されていました。 一度ID Checkすればアルコールを含めて飲み物は自由に飲めました。 なぜか寒くなった頃合いでソフトクリームを食べてしまいました。 Apple Design Awards Welcome receptionと同じ会場内で2025年の『 Apple Design Awards 』の受賞作品によるブースが設けられていました。受賞者が授与されるトロフィーのサンプルも展示されていて、そのずっしり重い感触に思わず感動しました。 全6カテゴリーごとに受賞作品のブースが設けられていました。 Apple Design Awardsのトロフィーのサンプル。 クローズする7 p.m.も近づいた頃、今年の『 Swift Student Challenge 』で日本人として唯一の優秀受賞者である濱本 太輝さんにお会いできました。濱本さんのことは受賞の記事を見て出発前から気になっていたので、直接お話しできてとても嬉しかったです。 Hanafuda Tactics のVision Pro対応を楽しみにしています！ 濱本 太輝さんと記念撮影 Photo by @toyochang さん。 こうしてDay 0は無事に終了しました。翌日からのメインイベントに備えて早めに休みましょう。 Day 1 (6/9) developer.apple.com Day 1はWWDC25のメインイベントである Keynote と Platforms State of the Union 、そして In-person labs などが催されました。 会場はApple Parkですが、入場前の待機列はApple Park Visitor Centerの裏手に形成されます。この待機列へ並ぶところからイベントは始まっているといっても過言ではありません。開場時間は8 a.m.ですが、私はLINEヤフーの参加者らとともに6 a.m.頃から並び始めました。最前列の方は明るくなる前から並んでいたそうです。日が射し込む前の時間帯は肌寒いので、絶対に薄手の上着を持参することをおすすめします。 開場を待っているとApple Park Visitor Centerに併設されているCaffè Macsのドーナツやコーヒーが提供されました。これがとても美味しくて、思わずおかわりしてしまいました。 Caffè Macsのドーナツやコーヒー。 定刻が近づくに連れ、Appleの方も『ダブ！　ダブ！　ディーシー！』コールを繰り返し大いに盛り上げてくれます。たまに“野良”の掛け声も混ざっていました。定刻直前の様子がTim Cook氏のX（旧Twitter）に 投稿されていました 。実は開始3〜4秒に映り込んでいます。 そしていよいよ定刻の8 a.m.を過ぎたところで列が動き始めました。最初のゲートでバッジをスキャンし、次のゲートでセキュリティチェックを受けます。セキュリティチェックはDay 0同様に厳重です。会場内ですぐに検証したいことを考えるとさすがに手ぶらでの参加は難しいので、荷物はできるだけ少なくしておくことをおすすめします。それでも並ぶレーンによっては時間がかかるので運次第という側面も否めませんでした。 結果として私は前方2列目の上手寄りの座席を確保できました。昨年、前方の座席はEnterprise Guest向けに確保されていたので、今年は端の方とはいえ前方の座席を確保できたのは幸運だったと言えるかもしれません。ただし、この上手側、屋根はあるものの斜めに射し込む陽射しが非常に強く、Keynote中は暑さとの戦いでした。来年以降にこのエリアを狙う方は、日焼け止めを塗っておくことを強くおすすめします。 前から2列目の上手寄りの座席から見たステージの様子。 座席を確保後、Keynoteが始まるまでの時間でLINEヤフーの方々らと一緒に朝食を楽しみました。 座席を離れる際は念のためにAirTagなどのトラッカーを入れておくと安心できます 。 同時刻に日本ではZOZOのiOSエンジニアも登壇した『 Extended Tokyo - WWDC 2025 』が開催されていて、生中継が行われていました。 Keynote www.youtube.com 定刻を迎え、昨年同様にCEOのTim Cook氏とSenior Vice PresidentのCraig Federighi氏が壇上に登場し、短い時間ですがトークしました。この様子もアーカイブには残らない現地ならではの体験です。その後、Keynote本編のビデオが会場内のスクリーンで再生されました。 CEOのTim Cook氏とSenior Vice PresidentのCraig Federighi氏。 Liquid Glass 今回のWWDCではOSバージョンを西暦にあわせたiOS 26などにするといった大胆な変更がありました。しかし、一番の目玉であり、ユーザーと開発者の双方にとって大きな変化となるのは Liquid Glass の発表ではないでしょうか。 www.apple.com 大胆かつ大きな変化ですが、XR屋の私としてはvisionOSの系譜が他OSに波及したと考えています。そのvisionOSにも様々なアップデートが加えられ、空間コンピューティングの発展に大きく寄与することが期待されます。 Apple Intelligence 昨年のWWDC24で発表された Apple Intelligence も進化し、いよいよXcodeにChatGPTが統合されました。これも会場を沸かせたトピックのひとつです。KeynoteではChatGPTとの統合を推していましたが、例えば Claude Sonnet 4など自身でモデルを選択できます 。 developer.apple.com Download station KeynoteとPlatforms State of the Unionの間の約90分間はランチタイムとなり、同時に会場内のDownload stationがオープンしました。Download stationには電源と有線LANが用意されています。会場内には高速なWi-Fiも飛んでいるので、手早くランチを済ませ、iPhoneとVision Proのアップデートを試みました（少なくともこの記事を書いている時点で大きな問題は発生していません）。 Download stationは会場内に複数用意されていました。 ここでひとつトラブルがあり、せっかく持参した検証用のiPhoneをホテルに置いてきてことに気づきました。もしも特定のアプリが動作しなくなった場合、特にUberやLyft、航空会社のアプリで不測の事態が発生すると道中が厳しいものになります。しかし、いざとなれば検証用のiPhoneに必要なものをインストールすれば済むので、潔く普段使いのiPhoneにiOS 26をインストールすることになりました。 今度イベントで話す3人で集合！ みんなでvisionOS26をダウンロードしてます😎 #WWDC25 pic.twitter.com/2SSDPmv411 — ARおじさんᯅ / MESON CEO (@AR_Ojisan) 2025年6月9日 visionOSに強い関心を寄せる同好の士も合流し、3人でVision Proを装着しながらアップデートを待ち、そのまま次のPlatforms State of the Unionへと向かいました。 余談ですが、私のVision Proに着けているオレンジ色のカバーは dbrandのAperture です。会場内でも気になった方が多いのか、写真を撮らせてくださいと声を掛けられることが何度かありました。 Platforms State of the Union www.youtube.com www.youtube.com Keynoteを見ていた前方の座席は引き続き強い陽射しに照らされていたため、Platforms State of the Unionは建物内に移動しました。iOS 26、visionOS 26ともにアップデートが済んでいたので、その変化をより具体的に想像しながら視聴しました。 Platforms State of the Unionの様子。 In-person labs Keynote、Platforms State of the UnionともにApple DeveloperまたはYouTubeでアーカイブを視聴できます。視聴するだけであれば、特に現地参加する必要はありません。いわゆる“実況”を楽しむにもオンライン参加の方に利があります。しかし、Appleの方と対面で会話できる In-person labs は現地参加ならではの特権であり醍醐味です。 このIn-person labsはDay 2に用意されているOne-on-one labsやgroup labと異なり、原則として事前予約が不要です（Design & AX DesignとApp Store Distribution & Servicesの2つのみ必要）。気になるカテゴリーのエリアに行き、その場で声をかけて各分野のスペシャリストと会話できます。 In-person labsのカテゴリーごとの配置図。 私はSpatial ComputingとSafari & Webのブースに立ち寄り、Appleが考える空間コンピューティングやWebXRの将来についての会話を楽しみました。 Spatial Computingラボの様子。 Reception in the inner ring In-person labsでの会話を楽しんだ後はApple Parkのリング内を巡る Reception in the inner ring を楽しみました。 KeynoteでCraig Federighi氏が乗っていたF1カー。 有名な虹のアーチ。 本物と見間違えるような“人工池”にも行きたかったのですが、虹のアーチを含めて一定時間が経過した後に封鎖されてしまったのは残念でした。また、Apple Parkの全体を見渡せる2F、3Fにも行けませんでした。それでも、飲み物と食べ物を片手にApple Parkの美しい景色を楽しみながら、参加者同士で会話を十分に楽しめました。既にiOS 26にアップデートしていたこともあり、実際の画面を見ながらの会話もできました。 Day 2 (June 10) developer.apple.com Special Eventの最終日となるDay 2はApple Developer Center Cupertinoで開発者向けのDeveloper activitiesが開催されました。 Morning・Afternoon・Eveningの3つの時間帯から選択して事前に予約するのですが、私はその予約に出遅れて気付いたときには既にすべての枠が埋まっていました。そのため、空き状況に応じて先着順で利用できる Overflow seating の待機列に小一時間ほど並んでMorning Session枠に参加しました。 例年は並べばステージのある特別なホールに入れましたが、今年は例年よりも人数が多かったのか、Overflow seatingとして案内されたのは60人程度が入れる程度の会議室でした。また、Overflow seatingも並んでいた人が全員入場できたわけではなく、一定のところで打ち切りになり、残念ながら参加できなかった人もいました。来年以降の傾向と対策として、事前予約は必須として、もしも逃した場合は1時間以上前から並ぶ覚悟で臨むことをおすすめします。 Developer activities (Morning session) KeynoteやState of the Unionと異なり、Developer activitiesの内容は公開されません。新たに発表されたLiquid Glassを中心として、その特長や具体的な活用方法について、ライブデモを交えながらAppleの方が入れ替わり立ち替わりで解説してくれました。 Developer activitiesのステージ。 Overflow seatingのライブビューイングルームは“ライブ感”を味わうには物足りなさがありましたが、コードを伴うライブデモは非常に見やすく、これはこれで「あり」でした。 Overflow seatingのライブビューイングルーム。 終了後には、会場内に用意されたランチをつまみながら、Appleの方や参加者同士で楽しく交流しました。 Developer activities終了後に提供されたランチ。 これを以て私のWWDC25 Special Eventは終了しました。Special Eventが終わってもWWDCは続きます。引き続き関連セッションを眺め、手元で動かす日々が始まります！ 現地でのアクティビティ WWDCの開催中・開催後に世界各国の開発者コミュニティがWWDCに関連するイベントを開催します。 これらのイベントの多くはWWDC25の公式ページでも紹介されています 。私は滞在中の3日間で次のイベントに参加しました。 Jun 8, Run & Walk with Ctrl+Alt+Run - WWDC Edition Jun 8, WWDC25 Vision Pro Community Meetup Jun 8, A Vision Pro Spatial Art Experience for WWDC25 Flatland: Mixed Reality Dreams Jun 9, Vision Pro Meetup at CommunityKit Jun 9, Spatial Computing Meetup @ WWDC25 Jun 10, One More Thing Conference 2025 Jun 10, CommunityKit 特に印象に残ったものを紹介します。 Run & Walk with Ctrl+Alt+Run - WWDC Edition Day 0の8 a.m.からCtrl+Alt+Run（ @ctrlaltrunph ）が主催する「 Run & Walk 」イベントに参加しました。Day 0は3 p.m.スタートなので、朝の時間を有効活用しようと思い事前に申し込んでいました。 Run組もWalk組も同じコースを巡りました。 Apple Park Visitor Centerに集合し、簡単な自己紹介の後、Run組とWalk組に分かれ、およそ4kmの道のりを進みました。私は同日の7 a.m.にSFOへ到着したばかりで、一定の疲れもあることを想定してWalkを選んでいました。しかし、かなりゆっくりとしたペースで走っているチームもあったので、Runに参加してもよかったかもしれません（走れる靴を履いてきていました！）。 ゴール後に提供されたミネラルウォーター。 気持ちよく歩いてゴールした後、ミネラルウォーターが配られ、参加者同士でWWDC25への期待を語り合いました。 WWDC25 Vision Pro Community Meetup Run & Walkの後はCtrl+Alt+Runの主催者による別のイベント「 WWDC25 Vision Pro Community Meetup 」にそのまま参加しました。半分くらいはRun & Walkからの参加者でしたが、このMeetupのために参加した方も一定数いました。 仲良くなった4人で記念撮影。 その場で意気投合して仲良くなった方々とVision ProやRay-Ban Meta AI Glassesなどの話に花を咲かせました。そして偶然にも私の隣にいる男性は、4月に審査員として参加したハッカソンイベント『 VisionDevCamp Tokyo 』の参加者ということが判明し、とても驚きました。こういった出会いもリアルイベントの醍醐味です。最後に4人で写真を撮って解散しました。 A Vision Pro Spatial Art Experience for WWDC25 Flatland: Mixed Reality Dreams Day 0の入場間際にVision Proを使ったアート体験イベント「 A Vision Pro Spatial Art Experience for WWDC25 Flatland: Mixed Reality Dreams 」に参加しました。 来場者のサインが加えられたボード 会場はApple Park Visitor CenterからUberで5分程度のところにある一軒家で、Airbnbで探して借りたそうです。 写真に写っていないものも含めて全7台のVision Proで臨んでいました。 このイベントはApp StoreにもリリースされているILLUSION TechのVision Pro向けアプリ『 Story: Spatial Storytelling 』を利用して制作されたもので、私はとても楽しめました。 SpatialComputing Meetup @ WWDC25 主催者のZac（ @greenlig ）氏を交えて記念撮影。 Day 1のReception後に少し離れた場所のPUBで催された『 SpatialComputing Meetup @ WWDC25 』に参加しました。フリードリンクで入退場自由のイベントで、Vision Proに興味を持つ方々が集まり、自由に会話を楽しみました。 さいごに 本記事はDay 2終了後にホテルでHHKBを接続したVision ProのMac仮想ディスプレイで執筆しています。私はこの後、 AWE USA 2025 に参加するため早朝のフライトでロサンゼルスのロングビーチに向かいます。Android XRなどの情報が期待されるAWE USA 2025の様子は、後日別の記事でお伝えします。 また、後日、WWDC25にオンライン参加しているiOSエンジニアチームによる、セッションや参加したラボで得た知見などを紹介するレポート記事を公開予定です。 現場からは以上です！ WWDC25関連イベントのお知らせ WWDC25の開催にあわせて、様々なRecapイベントや報告会が予定されています。そのいくつかに登壇します。 WWDC25 Recap for Spatial Computing 6月16日にTOKYO NODE LABで開催される「 WWDC25 Recap for Spatial Computing 」に登壇します。 WWDC25で発表された 空間コンピューティング 関連の情報に特化して、空間コンピューティングに一家言ある3名がパネルディスカッション形式で今後の可能性について深掘りしていきます。 WWDC25 報告会 at LINEヤフー, ZOZO 6月19日に、LINEヤフーとZOZOのエンジニアが、それぞれが興味のある分野について、新しく発表された技術や得た知見、情報などを共有する「 WWDC25 報告会 at LINEヤフー, ZOZO 」を開催します。 ZOZOからは3名のiOSエンジニアがLT Sessionに登壇します。また、私はパネルディスカッションのパネラーのひとりとして参加します。ご興味のある方はぜひご参加ください。 LODGE XR Talk Vol.28 / WWDC25 & AWE USA 2025 Report 6月25日にLODGEで開催される「 LODGE XR Talk Vol.28 / WWDC25 & AWE USA 2025 Report 」に登壇します。 LODGE XR TalkはLINEヤフーの方と共同で毎月開催しているXR領域に特化したイベントで、今回はWWDC25と、その後に参加したAWE USA 2025の2つのイベントについて紹介します。 ZOZOでは、一緒にサービスを作り上げてくれる仲間を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 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の振り返りイベントをオンラインで開催しました。 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を一緒に盛り上げるエンジニアを募集しています。ご興味のある方は以下のリンクからご応募ください。 hrmos.co hrmos.co また、会期中は混雑のため、十分にお話しできなかった方もいらっしゃるかもしれません。もし、より詳しく話を聞きたいという方がいらっしゃいましたら、カジュアル面談も受け付けています。 hrmos.co 来年の開催地は函館！ それではまた来年の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