はてなブックマーク

はじめに こんにちは、ECプラットフォーム部の権守です。普段はZOZOTOWNの会員基盤やID基盤の開発に携わっています。 本記事では、会員基盤で導入したデータベースへの書き込みを伴う処理のテスト手法について紹介します。この手法では実行前後のデータベースの差分に注目することで特定のレコードだけでなく、データベース全体への副作用を網羅的に検知することを目的とします。 目次 はじめに 目次 従来手法の課題 差分検証によるアプローチ Goによる差分検出ツールの実装 利用イメージ 差分抽出の実装 複数データベースへの対応 導入時の工夫点 非固定値の取り扱い 期待値の正規化 差分の除外 まとめ 従来手法の課題 データベースへの書き込みを伴う処理のテストでは、一般的に以下のように関数の返り値と処理対象である特定のレコードを検証することが多いと思います。 // 1. テスト対象の関数を実行 refund

はじめに こんにちは。商品基盤部の藤本です。 私たちのチームでは、Spring Bootで実装したJavaアプリケーションの起動時間の短縮に取り組んでいます。今回の記事では、Class Data Sharing（以下、CDS）を本番で稼働しているアプリケーションに実際に適用した内容を紹介します。 導入時には、Datadog Java Agentとの両立という課題にも直面しました。そのため、トレースとメトリクスの送信をOpenTelemetryとMicrometerに置き換える対応もあわせて実施しました。 本記事では、CDSの概要、導入効果、導入手順、Datadogの問題とOpenTelemetryへの移行までを順に説明します。 環境 今回の取り組みは次の環境で実施しました。 Java 21 (Eclipse Temurin) Spring Boot 3.5 Class Data Shari

はじめに こんにちは、新規事業部バックエンドブロックの三浦です。2025年6月にリリースされたマッチングアプリ「ZOZOマッチ」のバックエンド開発を担当しています。 ZOZOマッチでは、App StoreやGoogle Playの決済システムを利用したアプリ内課金を提供しており、定期購読（サブスクリプション）することで一部機能の制限解除や機能拡張が可能になります。アプリ内課金の実装には、アプリからの購入処理と購読のキャンセル・返金・自動更新といったライフサイクルイベントの同期処理が必要です。ZOZOマッチではこれらの処理をスクラッチで開発しました。 本記事では、特に開発が難航した、ライフサイクルイベントによって変更される課金ステータスをバックエンドに同期する仕組みについて紹介します。AppleとGoogleそれぞれが提供する通知の仕組みの違いや、同期処理の実装における課題と工夫についても解

目次 目次 はじめに この記事の対象読者 背景・課題 背景 課題 AI駆動開発ワークフローの概要 AIサービスごとの役割 Devin Playbook ユーザー起動のPlaybook（Slack → Devin） !ai_task（単一タスク実装） !ai_tasks（タスク分割＆並列実装） !human_review（人間承認フロー） 人間レビューが必要なケース ワークフロー自動呼び出しのPlaybook !fix_ci_failure（CI失敗時の自動修正） !fix_review_comments（レビュー指摘の自動修正） !context_curation（AIコンテキストの週次更新） 使用技術 機能一覧 アーキテクチャ SlackからPR承認までの完全フロー 2つのワークフローの役割 フロー別の使い分け 実装 設定ファイル AI Task Implementation：Issue

はじめに こんにちは、検索基盤部の朝原です。ZOZOTOWNの検索改善を担当しています。 日々の分析業務では、ユーザーの行動ログを集計するSQLクエリを頻繁に作成します。クエリ作成には定型的なパターンも多く、作業時間を短縮する手段として生成AIの活用を検討しました。しかし、社内固有のログ構造や前提条件が多く、生成AIを利用しても期待どおりにクエリを作成できないという課題がありました。 本記事では、Claude CodeのSkills機能やサブエージェント機能を活用してこの課題を解決した方法を紹介します。 目次 はじめに 目次 なぜ生成AIでログ分析のSQLを書くのが難しいのか 1. 社内固有のログ構造を参照できない 2. チームのSQL規約に準拠した出力が担保できない 3. 暗黙的に共有されているナレッジを生成AIが持っていない 解決策の全体像 技術的アプローチ 1. Claude Cod

はじめに こんにちは。Developer Engagementブロック（略称DevEngブロック）の@wirohaです。ZOZO TECH BLOGの運営や、開発者向けイベントの企画・運営などを担当しています。 TECH BLOGの運営において、レビューには一定の工数がかかるため、効率化を進めています。その一環として、Claude CodeのAgent Skills（以下、スキル）を用いたレビュー支援の仕組みを整備しました。Claude Code上で記事のレビューを依頼すると、定義したルールに基づくレビュー結果を得られます。 以下は、スキルによるレビュー結果の抜粋です。 本記事では、このスキルを用いたTECH BLOGレビューの取り組みについて紹介します。 目次 はじめに 目次 背景・課題 解決の方針 スキルの設計 SKILL.md rules.md スキルの使用方法 実行例 導入効果 運

はじめに こんにちは、ZOZOTOWN開発2部Androidブロックの大江です。普段はZOZOTOWN Androidの開発を担当しています。 UIのリグレッション防止を目的として、2024年からVisual Regression Testing（VRT）の導入に取り組んできました。その第1弾として共通UIコンポーネントのモジュールに対してJetpack ComposeのPreviewを使ったVRTを運用しています。 本記事では、VRT導入について、VRTをCI/CDツール上で実行するための工夫を中心に紹介します。 目次 はじめに 目次 ZOZOTOWN Androidの課題 VRTとは VRTの冗長な処理を防ぐための工夫 画像生成 画像比較 結果出力 まとめ ZOZOTOWN Androidの課題 ZOZOTOWN Androidは画面の数が多く、長年の開発によってモジュールの依存関係や

はじめに こんにちは、情報セキュリティ部の兵藤です。日々ZOZOの安全を守るためSOC業務に取り組んでいます。 本記事ではサイバー脅威インテリジェンスプラットフォーム「OpenCTI」からSplunkへの脅威インテリジェンスの取り込みについて紹介します。また、この内容については以下の「OpenCTIをSentinelに食わせてみた」に関連した内容となっています。 techblog.zozo.com 目次 はじめに 目次 背景と概要 構築 Splunkへのログ移行 Splunk Add-on EventhubとMDEの設定 SplunkでのOpenCTI連携設定 OpenCTI Add-on for Splunkの利用 OpenCTI側のStream設定 運用 Splunk ESでのThreat Intelligence framework OpenCTIのインジケータをThreat Int

はじめに こんにちは、データシステム部MLOpsブロックの木村です。MLOpsブロックではZOZOTOWN、WEAR by ZOZOをはじめとして、弊社で提供するさまざまなサービスに関わるML機能を開発・運用しています。 本記事で紹介するZOZOマッチ（以下、本アプリ）は「ファッションで恋する」をコンセプトとしたマッチングアプリです。本アプリもML機能を持ち、MLOpsブロックが機能を開発・運用しています。 本アプリの特徴的なML機能としてファッションジャンル診断（以下、ジャンル診断）があります。ジャンル診断とは全身画像をストリートやモードなどZOZOが定義した12種類のファッションジャンルに分類し、該当するジャンルの割合を「ジャンル傾向」として円グラフで表示する機能です。 ジャンル診断には2つの利用方法があります。1つ目はプロフィールに登録した自分の全身画像から自分の「ジャンル傾向」を判

こんにちは。検索基盤部の橘です。検索基盤部では、ZOZOTOWN検索の品質向上を目指し、検索結果の改善に取り組んでいます。 ZOZOTOWN検索の並び順の精度改善の取り組みについては以下の記事をご参照ください。 techblog.zozo.com 検索基盤部では新しい改善や機能を導入する前にA/Bテストを行い効果を評価しています。A/Bテストの事前評価として、オフラインの定量評価と定性評価を実施しています。これらの評価によりA/Bテストの実施判断をしています。 過去のフィルタリング処理の効果検証として導入したオフライン定量評価の方法については以下の記事をご参照ください。 techblog.zozo.com techblog.zozo.com 本記事では、検索基盤部が最近実践したLLMを用いた新しいオフライン定量評価の手法についてご紹介します。 目次 目次 オフライン定量評価の課題 課題解決

はじめに こんにちは、ZOZOMO部FBZブロックの杉田です。普段はFulfillment by ZOZOが提供するAPIシステムを開発・運用しています。昨年からは、社内における開発者向けAI支援ツール（Claude、Devin、MCPなど）の導入・教育・推進・管理を担う専門チームでも兼務で活動しています。 本記事では、開発ガイドライン準拠チェックをClaude Code Plugins × Atlassian MCPで全社展開した取り組みを紹介します。手作業の確認コストを下げつつ、最新ガイドラインに基づいたレビューを日常的に回せるようにした経緯と、実装・運用のポイントをまとめます。 目次 はじめに 目次 背景・課題 開発ガイドラインについて 開発ガイドラインにまつわる課題 Claude Code Pluginsとは Claude Code Pluginsを採用した理由 実施内容 開発ガイ

はじめに こんにちは、ZOZOTOWN開発本部リプレイスバックエンドブロックのばやです。普段はZOZOTOWN BFFのリプレイス開発を担当しています。 システムリプレイスのプロジェクトでは、実装に入る前段階として既存コードの調査が必ず発生します。特にレガシーシステムの場合、ドキュメントが整備されていなかったり、仕様が暗黙知として埋もれていたりすることが多く、コードを読み解くことでしか仕様を把握できないケースも少なくありません。 一方で、この調査フェーズは成果物の形式や進め方が属人化しやすく、プロジェクト全体の生産性に大きな影響を与えるポイントでもあります。調査に時間がかかればプロジェクト全体のスケジュールに影響しますし、調査品質が低ければ後工程での手戻りにつながります。 本記事では、リプレイスにおける既存コード調査の課題に対し、調査業務をテンプレート化しその後、Claude CodeでA

はじめに こんにちは、2025年にiOSエンジニアとして新卒入社したZOZOTOWN開発1部iOSブロックのだーはまです。普段はZOZOTOWNのiOSアプリを開発しています。本記事では、新卒1年目の私がZOZOTOWNの画面へMVVM+UseCaseアーキテクチャを導入した過程と、工夫を紹介していきます。 目次 はじめに 目次 背景と目的 チーム配属から1か月でMVVM+UseCaseアーキテクチャ導入を担当した経緯 デバッグ画面について 課題 コードやドメインに対する知識不足 700行以上に及ぶFatViewController 課題を解決するための取り組み Claude CodeのSubagentsを使いキャッチアップを高速化 MVVM+UseCaseアーキテクチャ導入 結果 デバッグ画面のテストカバレッジ0→93.5％ UI実装をStoryboardからSwiftUIへ完全移行 開

はじめに こんにちは、データシステム部MA推薦ブロックの佐藤（@rayuron）です。私たちは、主にZOZOTOWNのメール配信のパーソナライズなど、マーケティングオートメーションに関するレコメンドシステムを開発・運用しています。本記事では、GitHub Projects、BigQuery、Looker Studioを組み合わせて作業工数を可視化し、改善サイクルを回すための仕組みを構築した取り組みについてご紹介します。 はじめに 背景と課題 1. ボトルネックの特定に手間がかかり改善に着手しにくい 2. 工数に対する事業価値を把握できていない 3. AI活用の効果測定とナレッジの蓄積ができていない 解決策 1. GitHub Projectsの運用整備 カスタムフィールドの作成 自動入力の仕組み 2. データ収集の自動化 BigQueryへのデータ保存 GitHub Actionsで日次エ

はじめに こんにちは、検索基盤部検索研究ブロックの小倉です。普段はZOZOTOWNの検索精度改善を担当しています。検索研究ブロックでは2020年から検索結果の「あなたにおすすめ順」（以降「おすすめ順」と呼びます）とその改善に取り組んできました。その過程で「これまで積み重ねてきた改善は、トータルでどの程度効果があったのか？」を確かめるために、ネガティブテスト（最新のロジックと古いロジックを比較するA/Bテスト）を導入・運用してきました。しかし実際に運用を重ねる中で、ユーザー体験の悪化やロジック改善の機会損失といった問題も見えてきました。本記事では、ZOZOTOWN検索おすすめ順におけるネガティブテストを「導入して効果を測った段階」から「運用を見直すに至った段階」まで、その経緯と学びをご紹介します。 目次 はじめに 目次 背景・課題 ZOZOTOWN検索おすすめ順の改善 「1年間の積み上げ改善

はじめに こんにちは、グローバルシステム部フロントエンドブロックの平田です。 私が所属するチームでは ZOZOMETRYというtoBサービスを開発しています。スマートフォンを用いて身体計測し、計測結果を3Dモデルやデータとして可視化します。計測結果はWeb上で管理できます。 このサービスのフロントエンドではReact（Next.js）を採用しています。さらにそれらの知見を深めるために、NYで開催されたJSNation、React Summit US 2025に参加してきました。 この記事では現地参加ならではの経験や、参加したセッションへの考察などを紹介していきます！ はじめに JSNationとReact Summitとは？ Day 1 - JSNation Day 2 - React Summit After Party 気になったセッションについて The AI-Native Soft

はじめに こんにちは。SRE部会員ID基盤SREブロックの田中です。 ZOZOではマイクロサービスの増加に伴い、昨今高度化するサイバー攻撃に対応しつつ、各システム間のセキュリティとその統一性を維持するための仕組みが求められていました。なかでも、認可基盤の統一は長年にわたる重要な課題のひとつでした。 そこで今回、Istioを活用することで認可機能をアプリケーションから切り離し、ZOZOTOWN共通の認可基盤を実装する方針を採用することにしました。 本記事では、IstioのAuthorizationPolicy機能を利用した認可制御の実装方法について紹介します。 目次 はじめに 目次 Istioとは 課題 Istioを選定した理由 AuthorizationPolicyによる認可制御 AuthorizationPolicyの基本構造 metadata selector（適用対象） action

こんにちは、ZOZOの市橋です。2025年6月にリリースされたマッチングアプリであるZOZOマッチのバックエンド開発を担当しています。本記事では、ZOZOマッチのリアルタイムメッセージング機能を実現するために、AWS AppSyncとGraphQL Subscriptionを活用したアーキテクチャと実装について紹介します。 なお、本記事ではバックエンドのアーキテクチャにフォーカスして解説しますが、ネイティブアプリ側の実装については別記事「ZOZOマッチアプリのメッセージ機能を支えるFlutter × GraphQLの実装」で紹介しています。こちらもご確認いただくことでより理解を深められます。 目次 目次 ZOZOマッチシステム全体の構成 AWS AppSyncとは GraphQLとは AppSyncの基本概念 GraphQLスキーマ Resolver なぜZOZOマッチでGraphQLを採

はじめに こんにちは、ブランドソリューション開発本部プロジェクト推進部PMOブロックの三谷です。普段はPMOとして、ファッションコーディネートアプリ WEARの開発組織が企画を実現する上で発生する様々な課題の解決サポートを行っています。 WEARは2014年のローンチ以来アップデートを繰り返し、様々な機能をリリースしてきました。その中で、1つ1つの案件が大きくなってしまうことがしばしばあり、リリースまでのリードタイムや価値検証のサイクルが長くなりすぎてしまうことがありました。この課題を解決すべく、2024年5月より私たちPMOブロックは開発責任者@tsuwatchのもと、スクラム開発の導入を推進しました。本記事では、スクラム導入におけるPMOの取り組みをご紹介します！ なお、今回ご紹介する内容はWEARのアプリ開発に限った話であり、Webサイトの開発は対象外としています。 目次 はじめに

1. はじめに 検索基盤部 検索基盤ブロックの佐藤（@satto_sann）、岡田（@ryokada33）、SRE部 検索基盤SREブロックの富田（@kei_gnu622）です。 ZOZOTOWNアプリ用に検索機能を提供していたオンプレサーバー上のレガシーなAPIを、約1年かけてクラウド環境へ全面リプレイスしました。 このリプレイスプロジェクトではスパイラル開発の導入や開発初期からの環境整備といった工夫を積み重ねることで、当初のスケジュールどおり移行を完了しています。 また、副次的な効果として、検索速度が約2倍に向上しユーザー体験の改善にもつながりました。 本記事では、大規模リプレイスを円滑に進めるために実践したプロジェクト運営の取り組みを、以下の流れで紹介します。リプレイスをはじめとした、ソフトウェアやマイクロサービス開発プロジェクトの参考になれば幸いです。 【2章】リプレイスプロジェク

はじめに こんにちは、ビジネス・アナリティクス部マーケティング・サイエンスブロックの茅原です。普段はマーケティング施策の効果検証を担当しています。マーケティング・サイエンスブロックではAI協働型分析フロー構築の取り組みをしています。本記事では本取り組みの詳細や、この中で得られた知見をご紹介します。 目次 はじめに 目次 背景・課題 取り組みの紹介 分析環境の標準化 AI活用フロー検証のためのGitHubリポジトリ構築 分析設計書の活用 分析作業フローの定型化 再利用性を高める工夫 文化の醸成 まとめ 背景・課題 近年、生成AIの発達が目覚ましく、開発をはじめとするエンジニアリング組織ではその活用事例が多く見られるようになってきました。一方でデータ分析組織においては、エンジニアリング組織ほど生成AIとの協業事例が見られないという所感があります。これは分析組織にとって、生成AIの持つ不確実性の

はじめに こんにちは、AI・アナリティクス本部データサイエンスブロックの大戸徳仁です。普段は、サービスや機能の現状把握・要因分析、施策の効果検証、需要予測モデルの開発・運用などを担当しています。私が所属するチームでは、「データに基づいた意思決定を支援すること」をミッションに、社内の各部門に対してデータ分析サービスを提供しています。 その取り組みの一環として、ZOZOの物流拠点「ZOZOBASE」のデータ活用に取り組んでいます。中でも、出荷計画や人員配置の判断材料となる「注文数の予測」については、予測精度が安定しない、予測工数がかかるといった課題があります。本記事では、これらの課題に対してどのようにアプローチしたのか、そしてプロジェクトを通じて得られた気づきについて紹介します。 目次 はじめに 目次 背景 課題 課題解決アプローチ 1.評価指標の設計 2.EDA（探索的データ分析） 3.予測

はじめに こんにちは、EC基盤開発本部SRE部の金田、花房、松石です。普段はSREとしてZOZOTOWNのインフラ運用や開発を担当しています。 ZOZOではgatling-operatorをOSSの負荷試験ツールとして公開・運用してきました。しかし、Gatling本体の破壊的変更やメンテナー不足といった課題に直面し、新たな負荷試験ツールとしてk6の導入を進めています。 本記事では、gatling-operatorが抱えていた課題と、k6への移行に至った経緯、そしてClaude Codeを活用した既存シナリオの移行方法についてご紹介します。 目次 はじめに 目次 背景・課題 gatling-operatorとは Gatlingの破壊的変更 Gatling 3.11での変更 Gatling 3.12での変更 メンテナー不足 検討した対応策 なぜk6を採用したのか 要件 k6を採用した理由 導入

はじめに こんにちは、SRE部 検索基盤SREブロックの花房です。2025年12月11日に東京の虎ノ門で開催された「OpenSearchCon Japan 2025」にZOZOのエンジニア5人が参加しました。本記事では、会場の様子と印象に残ったセッションについて紹介します。 はじめに OpenSearchCon Japanとは 会場の様子 セッションレポート Maximize Resource Efficiency with Separated Index and Search Workloads 課題 解決策: ワークロードの物理的分離(Reader-Writer Separation) Remote Store(S3など)でデータの共有を実現 感想 Intelligent Japanese Search With OpenSearch 感想 Lessons From Migrating

はじめに こんにちは、「ZOZOMO」のブランド実店舗の在庫確認・在庫取り置き機能の開発を担当しているZOZOMO部OMOブロックの木目沢です。先日、プロダクト開発メンバーとビジネスメンバー合同で2日間の「ユーザーストーリー」ワークショップを開催しました。 1日目は「キャンプ」を題材にユーザーストーリーの型と会話を体験し、2日目は実際のZOZOMO店舗在庫取り置きでユーザーストーリーを書き、優先順位を決めて実際に開発するところまで行いました。 この記事では、その2日間をまとめて振り返ります。 目次 はじめに 目次 開発チームの課題感と、ワークショップのねらい なぜ「ユーザーストーリー」なのか？ 1日目：キャンプでユーザーストーリーの型を体験する メインワーク１：キャンプで“WHAT”を考える メインワーク２：WHYを考える──価値の核心を探る メインワーク３：WHAT/WHYを“実現したと

こんにちは、プロダクト戦略部の土屋です。普段はFAANS（アパレル店舗で働くショップスタッフ向けの業務支援ツール）のプロダクトマネジメントを担当しています。 「新しいことをやりたいけれど、既存タスクで手一杯」プロダクト開発の現場では、こうした状況は珍しくありません。特に、特定の領域や役割にタスクが偏りやすい構造的な課題を抱えた組織では、新しいチャレンジが後回しになってしまうケースも多いのではないでしょうか。 この記事では、チーム内のリソースの偏りという組織的な課題に対して、私たちが取り組んだ「PoC専用開発レーン」の設計と運用についてご紹介します。設計思想から開発フローまで具体的な内容をお伝えできればと思います。 FAANSの開発チームについて FAANSの開発チームは、バックエンド、フロントエンド（Web/iOS/Android）、デザイン、プロダクトマネジメントの各専門領域で構成されて

はじめに こんにちは、ZOZOMO部SREブロックの中村です。普段はZOZOMOのSREを担当しています。 本記事では、ECS on FargateにPipeCDを導入してGitOpsベースのデプロイ基盤を構築した取り組みをご紹介します。デプロイ経路の複数存在による管理の煩雑さと、段階的デプロイができない課題をPipeCDでどのように解決したかを解説します。 本記事がECS on Fargateを運用していてGitOps化に興味がある方や、PipeCDの導入を検討している方の参考になれば幸いです。 目次 はじめに 目次 導入前の課題 デプロイ経路の複数存在による管理の煩雑さ 段階的デプロイができない 解決アプローチ PipeCDとは 導入構成 実装 Control Planeの構築 Control Planeの初期設定 Pipedの構築 マニフェストファイルの構成 アプリケーションの登録

はじめに こんにちは。ブランドソリューション開発本部WEARバックエンド部SREブロックの和田です。 普段はWEARのSREチーム（以下、WEARSRE）に所属し、開発や運用に加えて、ここ3年ほどはマネージャーとしてチーム運営にも携わっています。 WEARSREは発足以来、クラウドを活用した課題解決に取り組んできました。その一方で、10年以上稼働し続けているオンプレミス環境の運用については、長らく他部署に任せきりの状態が続いていました。 プロダクト専任のSREチームでありながら、システム全体にアプローチできていない。この矛盾を解消すべく、私たちはオンプレミス環境への関与を少しずつ拡大し、最終的に自チームでの運用を実現しました。 本記事では、これら一連の取り組みを振り返りつつ、チームの成長と現場で得られた気づきをご紹介します。 目次 はじめに 目次 これまでの取り組み 取り残されたオンプレミ