G-gen の奥田です。当記事は、Google Cloud Next 26 Tokyo の1日目に行われたカスタマーセッション「 CDP だけで顧客理解は不十分？Google Cloud と生活者データで実現する「Why 分析」最前線 」のレポートです。 他の Google Cloud Next Tokyo 26 の関連記事は Google Cloud Next Tokyo 26 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 データはあるのに顧客が見えない データの量ではなく種類が足りない 再発する 5 つの症状 Why を補ってきた「勘と経験」の正体 5W1H を同時に読む力 勘と経験がもつ 3 つの限界 生活者データという「Why の辞書」と Why 分析の方法 Why の辞書とは ID 突合ではなく確率的な意味マッチング 処理の 4 ステップ 既存テーブルを変更せずに列が増える Google Cloud だから実現できた 3 つの発見 Google Cloud を選定した理由 実運用から得られた発見 発見 1: 直感を再現する VECTOR_SEARCH 発見 2: Gemini による出力品質の独立検査 発見 3: 承認済みルーティンによる双方の資産保護 Why 分析の先にあるもの AI の均質化とブランドらしさ 業種を越えた共通フレームワークへ 関連記事 セッションの概要 当セッションでは、株式会社博報堂による発表が行われました。CDP（Customer Data Platform、顧客データを個人単位で統合管理する基盤）だけでは捉えられない「顧客が行動した理由（Why）」を、生活者データと BigQuery の機能を組み合わせて補完する手法が紹介されました。 セッションは以下の 5 章で構成されていました。 データはあるのに顧客が見えない Why を補ってきた「勘と経験」の正体 生活者データという「Why の辞書」と Why 分析の方法 Google Cloud だから実現できた 3 つの発見 Why 分析の先にあるもの 当記事では BigQuery の基礎的な説明は割愛します。BigQuery そのものについては、以下の記事を参照してください。 blog.g-gen.co.jp データはあるのに顧客が見えない データの量ではなく種類が足りない セッション前半では、多くの企業が直面する課題として「データ量は十分にあるが、データの種類が足りていない」という点が提示されました。 CDP に記録されるのは、会員属性、購買履歴、行動ログ、解約記録といった「What（結果）」のデータです。一方、価値観、生活文脈、意思決定の傾向、不安や願望といった「Why（原因）」は、CDP のどこにも記録されません。登壇者はこれを氷山にたとえ、水面上に見えるのが What、水面下に隠れているのが Why であると説明しました。 たとえば「妥協して選んだ」という本音は、購買履歴という結果データからは読み取れません。同じ商品を買った顧客でも、買った理由は三者三様です。 再発する 5 つの症状 この構造的な欠落が原因となり、データを精緻化しても再発する症状として、以下の 5 つが挙げられました。 セグメントの画一化 メッセージの一律化 LTV（Life Time Value、顧客生涯価値）向上の頭打ち 静かな離反の見落とし 新規獲得の非効率 登壇者は、CDP や CRM（Customer Relationship Management、顧客関係管理システム）の整備自体は不可欠な土台であり、ID 統合、行動ログの蓄積、施策の自動化という期待された役割は果たしていると強調しました。問題は、CDP だけではカバーできない領域（なぜ買ったのか、なぜ離れたのか、なぜ選んだのか）が存在することです。 Why を補ってきた「勘と経験」の正体 5W1H を同時に読む力 これまで Why の欠落を埋めてきたのは、マーケターの「勘と経験」でした。セッションでは、その正体は「5W1H を同時に読む力」であると定義されました。 ベテランマーケターは、Who（どんな生活状況か）、When（いま何が起きそうか）、Where（どこで接点を持つか）、Why（なぜその選択か）、How（どう情報収集し選ぶか）を、過去事例の蓄積による暗黙のパターンマッチで同時に推論しています。たとえば「40 代男性が SUV を購入した」という購買データから、「家族の安全を重視する層である」と言い当てる、といった推論です。 勘と経験がもつ 3 つの限界 一方で、この勘と経験には 3 つの構造的な限界があると指摘されました。 スケールしない: 顧客一人ひとりに勘と経験を働かせるのは物理的に不可能 引き継げない: ベテランの退職は「顧客理解資産」の消失を意味する 共有できない: 「なんとなく刺さる」という判断では合意形成が属人的になる 生活者データという「Why の辞書」と Why 分析の方法 Why の辞書とは この課題に対する解決策として、博報堂が保有する生活者データを「Why の辞書」として使用し、マーケターの脳内プロセスを機械化する手法が紹介されました。材料となるのは、圧倒的な量の Why の語彙と、生活者インサイト（購買行動の背後にある価値観や動機）を推論する技術の 2 つです。 博報堂独自の観点として、価値観、動機、幸福感といった軸（たとえば購入時の価値観として、価格、幸せ、機能性など）が生活者データの中で 5W1H により体系化されています。 ID 突合ではなく確率的な意味マッチング 特徴的なのは、顧客データと生活者データを ID 突合（異なるデータベース間で共通の ID をキーにレコードを結合すること）ではなく「確率的な意味マッチング」で接続する点です。これにより以下の 3 点が実現されます。 個人を特定しない 既存の CDP をそのまま使用できる Cookie 規制（サードパーティ Cookie によるトラッキングの制限）の影響を受けにくい 処理の 4 ステップ 処理は以下の 4 ステップで構成されます。 翻訳: 企業ごとに異なる顧客 CDP の項目を、生活者データの共通言語にマッピングする 数値化: 顧客データと生活者データを「意味の座標」上に配置し、意味の近さを距離として比較できるようにする 検索: 生活者データの中から、意味的に最も近い人を選ぶ 特徴付与: 生活者データに近い特徴を顧客データにも付与する 既存テーブルを変更せずに列が増える この手法の利点は、既存の顧客テーブルを変更する必要がないことです。顧客 ID、属性、購買金額といった従来の列はそのままに、以下のような生活者インサイトの列が追加されます。 価値観（なぜ買うのか。指名買い、コスパ重視など） 意思決定傾向（どう選ぶのか。SNS 影響、即決型など） ライフスタイル（どう生きるのか。都市型ライフ、子育て重視など） 既存の顧客データ基盤が、そのまま顧客理解基盤へ進化するという表現が用いられました。 Google Cloud だから実現できた 3 つの発見 Google Cloud を選定した理由 博報堂独自の生活者データを AI 時代に使用するには 3 つの条件が必要であり、Google Cloud はそのすべてを満たすと説明されました。 意味の近さを計算できる BigQuery が標準機能としてベクトル検索（テキストなどを数値ベクトルに変換し、意味の近さで検索する仕組み）を備えています。 マーケターが直接触れる SQL やダッシュボードで完結し、ノーコードまたはローコードで操作できるため、マーケター自身が仮説をすぐ検証できます。 データを動かさない 顧客データは企業環境から一切出さず、顧客環境内で処理が完結します。 実運用から得られた発見 発見 1: 直感を再現する VECTOR_SEARCH セッション後半では、実運用から得られた発見として次の3点が紹介されました。1 つ目は、マーケターの直感を SQL で再現できたことです。「この人は、こんな価値観の人と似ているな」というベテランマーケターの頭の中の処理は、これまで言語化も再現もできない暗黙知でした。この処理を、BigQuery の標準機能である VECTOR_SEARCH 関数への変換（SQL Translation）によって再現しています。 これにより「意味の近さ」が可視化され、感覚でしかなかった判断を数字として表現できるようになりました。 参考 : ベクトル検索の概要 発見 2: Gemini による出力品質の独立検査 2 つ目は、出力品質を Gemini で独立検査する仕組みです。付与されたインサイトが施策の判断材料になる以上、品質に責任を持つ必要があります。人間による品質検査には量的な限界があるため、Gemini による5観点の独立評価を、品質保証レイヤーとして組み込んでいます。これは LLM ジャッジ（Large Language Model による評価）と呼ばれる、大規模言語モデルに出力の良し悪しを判定させる手法です。5 観点は以下のとおりです。 一貫性: 矛盾するタグがないか 妥当性: その人らしいか 網羅性: 必要な観点があるか 不足検出: タグの抜けはないか 実用性: マーケティング施策に使えるか 発見 3: 承認済みルーティンによる双方の資産保護 3 つ目は、データを守りながらロジックも守る仕組みです。顧客データは企業環境から一切出さない一方で、博報堂の推論ロジックも公開しません。この双方の資産保護を、BigQuery の承認済みルーティン（Authorized Routine）で実現しています。承認済みルーティンは、呼び出し元に定義内容を開示せず、実行権限のみを付与できる機能です。 参考 : 承認済みルーティン Why 分析の先にあるもの AI の均質化とブランドらしさ 最終章では、AI エージェントが購買の意思決定を担う時代の展望が語られました。購買が AI エージェント経由になるほど、効率最適化により「どのブランドも同じ答え」に収束するリスク（AI の均質化）があります。 エージェントが最適解を出す時代では、生活者の「なぜ（Why）」への深い理解こそがブランドらしさの源泉であり、ブランドに求められるのは最適化ではなく「選ばれる理由」を持ち続けることである、と締めくくられました。 業種を越えた共通フレームワークへ また、この設計様式は博報堂だけの話ではない、という点も強調されました。ID 突合に依存しないポストクッキー時代（サードパーティ Cookie が使えなくなる時代）のマーケティング手法として、また「データを動かさず、処理を動かす」という厳格なデータガバナンス下で AI 利用を進めるための共通フレームワークとして、規制業界を含むデータを持つすべての企業に波及していくという展望が示されました。対象業種の例として、小売、金融、通信、旅行、メディアが挙げられました。 関連記事 blog.g-gen.co.jp 奥田 梨紗 (記事一覧) クラウドソリューション部データインテリジェンス課 Google Cloudの可能性に惹かれ、2024年4月G-genにジョイン。 Google Cloud Partner Top Engineer 2025&2026 Follow @risa_hochiminh

はじめに 本記事は、2026年3月10日に開催された Elastic{ON} Tokyo での発表「 『定型』を許さない製造業データへの挑戦 」の内容をもとにした連載の第2回です。 第1回：ビジュアル情報を活かす 第2回（本記事）：分断されたデータを繋ぐ 第3回：止めずに進化させる 前回は、製造業の検索に「ビジュアル」が外せないこと、Elasticsearch の kNN 検索を使った類似図面検索について書きました。 今回は、次に立ちはだかる「データ規模と結合」の壁について掘り下げます。複数のデータソースを横断した検索を、どうやって高速に実現しているかという話です。 「探索」に必要なデータ横断 前回も触れた通り、私たちが実現したいのは「探索」です。たとえば調達部門が「より良い発注」を目指す場合、こういうプロセスを一気通貫で回したい。 発注予定の図面に対して、視覚的に似た過去の図面を検索する 見つかった図面に紐づく発注実績をシステム横断で確認する 集まった情報をもとに今回の発注額を適正化する この②「システム横断での実績確認」が、技術的にはかなり重い問題を含んでいます。 製造業データの「分断」 製造業の現場には、PLM、EDI、SCM、CRM といった業務ドメインごとのシステムが並んでいます。それぞれの業務には最適化されていますが、システム間でデータが分断されているのが常です。 この分断を解決するために ERP が導入されてきました。ただ、ERP はあくまで組織の「管理」が目的のシステムです。前回書いた「ビジュアルな情報をビジュアルなまま扱う」という発想にはなっていないので、ERP に実績データが集まっても、現場が判断の拠り所にする「モノの形」とは切り離されたまま。分断は形を変えて残り続けます。 CADDi Drawer は、こうしたバラバラのデータソースを統合し、一つの画面から横断的に探索できるようにするプロダクトです。 データ規模と「結合」の壁 日本の製造業は数十年、時には100年を超える歴史があり、蓄積されたデータは膨大です。図面だけで100万枚以上、受発注実績は1,000万レコード以上。仕様書やトラブル記録などの非定型な文書も含めるとさらに増えます。 これらを統合して扱うとき、RDB のようにテーブルを繋ぎ合わせる素朴な結合をやると、組み合わせは10兆件規模に達します。インデックスがなければ全件走査になるので、対話的な速度は到底出ません。 では、図面と実績をデータ種別ごとに別のインデックスに入れればいいかというと、それだけでは不十分です。片方のインデックスで検索した結果をもう片方と突き合わせる必要があり、突き合わせ側はインデックスが効かず全件走査に落ちるケースが出てきます。クエリの絞り込みが弱い場合や結合キーの値の種類が少なく多対多の組み合わせが膨らむ場合、この突き合わせのコストが支配的になって応答速度が崩れます。 この10兆通りの組み合わせを、検索エンジンが得意な形にどう落とし込むか。ここがアーキテクチャ上の大きな問題でした。 複数インデックス構造による解決 私たちがとったのは、複数のデータソースを統合したうえで、用途別のインデックス群を構築するアプローチです。 万能なインデックスは作れない 私たちも最初は「すべての要件を満たすインデックスをどう設計するか」と考えていましたが、うまくいきませんでした。 データソースごとにインデックスを分けると、前述の通りクエリ時の突き合わせで全件走査が走って遅いという課題があります。その一方で非正規化して複合インデックスにまとめれば検索は速くなりますが、あるデータソースの1レコードを変えただけで紐づく全ドキュメントに波及して大量更新が走る。検索を速くすると更新が重くなるし、その逆もまた然りで、一つのインデックスでは両立しません。 なので発想を変えて、万能なインデックスを作ろうとするのをやめました。代わりに要件を分解して、用途ごとに別のインデックスを持たせています。例えば、データソースごとにオンライン更新が走るインデックスと、データ鮮度には多少の遅延があるもののデータソースを横断して検索できるインデックスを分けて持つ、といった具合です。 動的なインデックス選択 ここで鍵になるのが、クエリ実行時の制御層です。ユーザーから投げられたクエリの内容をシステムが解析し、そのとき最も効率的なインデックスを自動で選択します。 単一データソース内の検索ならそのデータソースのインデックスを使い、複数データソースにまたがる検索なら横断用のインデックスを使う。こうした切り替えが裏側で動いています。 ユーザーから見ると、データがどこにあるか、どのインデックスが使われているかは一切見えません。透過的な検索体験を維持したまま、裏では用途に応じた最適化が走っている、という構成です。 類似検索 × フィルタリングの両立 データソース横断検索の難しさは、「類似検索」と「フィルタリング」を組み合わせたときに顕著になります。 そして現場では、この掛け合わせがないと使い物になりません。「この図面に似た形のもの」を探すだけでなく、「その中で、今取引のある会社に発注したことがあるものだけ」に瞬時に絞り込めなければ、実際の比較検討には使えないからです。 なぜ難しいのか 類似検索（kNN）はベクトル空間上の距離計算、フィルタリングは転置インデックスによる構造化データの絞り込みで、それぞれ背後のデータ構造もアルゴリズムも違います。素朴に組み合わせると、どちらかの速度が犠牲になります。 さらに、フィルタリング対象のデータが別のデータソースに由来する場合（発注実績は ERP、図面はファイルサーバーなど）、結合処理のコストも乗ってきます。 どう解決したか kNN 検索とフィルター条件を同一クエリ内で組み合わせることで、ベクトル検索の結果に対して構造化データの絞り込みをかけています。 加えて、前述の横断検索用インデックスで図面と実績の関連を事前に非正規化しているため、検索時のデータソース間結合は発生しません。 Elasticsearch が kNN とフィルタを同一クエリ内で同時実行できることと、事前結合による非正規化インデックスの組み合わせで、類似検索とデータソース横断のフィルタリングをサブセカンドで安定して返せるようになりました。 アーキテクチャの全体像 データが取り込まれてからユーザーに届くまでの流れを整理します。 PLM、ERP、ファイルサーバーなど複数のデータソースからデータを収集する AI による図面解析、メタデータの抽出、ベクトル化などの処理を行う 用途別のインデックスにデータを振り分ける ユーザーのクエリを解析し、最適なインデックスを動的に選択する サブセカンドで結果を返し、ファセットやハイライトとともに表示する 図面と実績は更新頻度も構造も違うデータですが、探索に最適な形に統合・変換してインデックスし続けることで、ユーザーはデータの所在を意識せずにあらゆる情報を横断できます。 まとめ 製造業のデータを素朴に結合すると10兆件規模の組み合わせになる。これをどう捌くかが今回のテーマでした。 私たちの答えは、用途別に最適化した複数のインデックスと、クエリに応じてそれらを動的に選択する制御層です。特に、非正規化による事前結合で検索時の結合コストをなくしたことと、Elasticsearch が kNN とフィルターをネイティブに統合できることが、類似検索とフィルタリングの両立を可能にしています。 ただ、ここまで作り込んだインデックス構造も、現場の変化に追従できなければ意味がありません。次回の最終回では、このインデックスを「サービスを止めずに進化させ続ける」ための仕組みについて書きます。

こんにちは。メルペイ Growth Platform チームでエンジニアリングマネージャーをしている @yo-gawa です。この記事は Merpay & Mercoin Tech Openness Month 2026 の 19 日目の記事です。 私は 2018 年にメルペイに入社し、メルペイクーポンや決済に応じたポイント還元の仕組みなど、メルペイのキャンペーンを支える基盤の開発・運用に携わってきました。 【書き起こし】メルペイのキャンペーンの舞台裏 〜Growthを支える仕組み〜 – 小川 芳樹【Merpay Tech Fest 2021】 | メルカリエンジニアリング 現在は、メルカリグループ全体のグロース基盤のエンジニアリングを統括しています。 本記事では、私の視点からメルカリグループのグロース基盤の歴史と、どのようにチームが拡大してきたのかをお伝えします。 Growth Platform の立ち上げ メルカリグループでは、ポイントやクーポンを用いたマーケティング／キャンペーンが非常に活発に行われています。既存のお客さま向けの施策に加え、メルカリハロやメルカリモバイルといった新規事業のグロースにも活用されています。また、お客さまとのコミュニケーションチャネルとして、アプリ内バナー、メール、Push 通知、「あなたへのお知らせ」等も併せて使われています。Growth Platform チームは、こうしたグロース活動を支える基盤・仕組みづくりを担うチームとして機能しています。 「Growth Platform」というチーム名称が生まれたのは、ちょうど 5 年前の 2021 年 7 月でした。 「Growth UXチーム」が「Growth Platformチーム」に名称変更！　組織改編で見えたPMの役割やチームの変化 | mercan (メルカン) 上記の記事にもある通り、「共通する機能・基盤を横断的に見て、システム開発や運用の観点から下支えする」というミッションのもと、さまざまな取り組みを進めてきました。 Growth Platform というチームが生まれる前、2019 年のメルペイサービス開始直後は、より多くのお客さまにメルペイを使っていただくため、決済に絡めたクーポンやポイント還元キャンペーン施策を次々と打ち出していました。そのスピード感を支えるべく、独自にキャンペーン基盤を開発してきました。 一方で、マーケットプレイス事業にも同様にキャンペーンや Customer Relationship Management（CRM）を実行する基盤が存在していましたが、長いメルカリの歴史の中で生み出されてきた PHP 製ツールには多くの負債があり、メンテナンス性の観点からも、オペレーション事故が起きやすい構造になっていました。メルペイ側でも、それらのツールを利用することにリスクを感じていました。 そこで、メルカリとメルペイのエンジニア間で実務的なコラボレーションをスタートし、古いツールを廃止して、新たに Engagement Platform (EGP) という内製マーケティングエンジンを共同開発する方向性で合意しました。 その後、2023 年 1 月よりメルペイ内に統合組織を作り、「JR (Japan Region) Growth Platform」として、一丸となった開発体制をスタートさせました。詳細は当時のエンジニアリング統括であった keigoand の記事にまとまっています。 Merging Teams for a Growth Platform | Mercari Engineering 記事にもありますが、当初はそれぞれのチームで開発の進め方が大きく異なりました。メルペイが比較的小規模で立ち上げを進めた背景もあり、独自のオペレーションツールやミドルウェアがあり、エンジニアリングカルチャーも異なっていました。また、メルペイは金融事業を担っていることもあり、システム品質の担保も重要です。リリースプロセスの厳格化や、QAなどの各種基準への準拠などについて認識を合わせながら開発を進めることは苦労も伴いましたが、チームのケイパビリティは格段に向上しました。 グループの拡大とともに 先述した通り、Growth Platform チームはメルペイに所属しながらも、メルカリグループ全体を支えるチームです。 この数年、メルカリでは複数の新規事業が立ち上がりました。 メルカリShops メルコイン メルカリNFT メルカリハロ メルカリモバイル 越境ビジネス メルカリグローバルアプリ etc これらのビジネスやプロダクトの Product-Market Fit を支えるべく、Growth Platform ではさまざまな開発を行ってきました。例えば、新しいサービス画面上でのキャンペーンバナー表示や訴求、新規のお客さまへのクーポン／ポイント進呈、利用実績に応じたロイヤリティプログラムなどは、一見共通でありつつも、それぞれのサービスのデータを基盤に統合し、マーケティングチームが柔軟かつ高速にキャンペーンを打ち出せる仕組みが必要です。また、グローバル展開においては、各地域の言語や、クーポンにおける通貨の違いへの対応などもスコープになります。 さらに（一部例外はありますが）、メルカリのサービスは 1 つのメルカリアプリ上で動いています。起動直後に表示される「ホーム画面」や、マーケットプレイスにおける「商品詳細画面」「取引画面」でのキャンペーン訴求は、お客さまにサービス認知を獲得するうえで非常に重要です。そのような訴求エリアが限られる中で、どのサービスがそれぞれのお客さまにとって有用なキャンペーンであるのか、コミュニケーションチャネルがノイジーになりすぎないのか、といった最適化にも Machine Learning チームが取り組んでいます。 組織の拡大 事業の拡大に対応するため、Growth Platform 組織も拡大を続けてきました。 2022 年 6 月にインド・ベンガルールに開発拠点として Mercari India を設立して以降、設立当初から一緒に開発を進めています。当初はクーポンドメインを共同で開発するところからスタートしました。新たなビジネスに対応したクーポン機能の開発を進めながら、mercari-api という PHP 製モノリスからマイクロサービスへのマイグレーションという大規模プロジェクトも自律的に推進しています。 Migrating Coupons from Monolith to Microservice – Mercari India 近年ではクーポンドメインだけでなく CRM ドメインでも開発体制を拡大し、Backend、Frontend、Mobileのエンジニアが一体となってインド拠点のみで機能開発を完結するような事例も出てきています。 現在は日本とインドのエンジニアが約2:1の割合で協働しています。また、日本とインドのエンジニアリングマネージャー同士、密に連携しながら開発を推進しています。 Growth Platform の全体ミーティングでは、知見共有を含めた交流をエンジニア同士で積極的に行っています。加えて、定期的にインドオフィスへ出張したり、インドのエンジニアが東京オフィスを訪問するタイミングに合わせて交流を深めたりしています。 (インドオフィスに設置されているオブジェへのサイン) 一方で、使用言語の壁は依然として課題です。メルペイは従来、日本語中心でコミュニケーションしてきましたが、元マーケットプレイスのメンバーやインドオフィスのメンバーは英語中心です。Growth Platform チームの全体ミーティングは英語で行う一方、メルペイ全体のミーティングは日本語で実施しているといった状況下で、GOT（通訳）チームのサポートも借りながら、日本語話者・英語話者の双方が歩み寄ってコミュニケーションを進めています。 次なるチャレンジへ Growth Platform チームの成熟は、メルカリグループのグロースとともにありました。 EGP は、さまざまな機能開発を経て大きな進化を遂げています。 EGP – Mercari’s CRM Platform: Built Once, Powering Many | mercari GEARS 2025 AI と作る HTML ベースの LP エディタ EGP Code を内製した理由 | メルカリエンジニアリング また、メルペイに特化した基盤である Santa サービスも進化を続けています。 メルペイのキャンペーン基盤をルールベース汎用システムに書き直し、Otoku Revolutionするまでの話 | メルカリエンジニアリング 基盤開発フェーズは一巡したと捉えていますが、ビジネスを支える基盤としてはまだ道半ばにあります。特に、ビジネスの要求に対するアジリティとシステムの信頼性向上は継続的な課題です。 そこで今後は、グループそれぞれのビジネスグロースをより直接的に支えつつ、守りも固められる開発体制をつくるために、Growth Platform 体制としては一区切りとし、組織を CRMチーム と Incentiveチーム に分け、それぞれのミッションを担っていきます。 CRM チームは、マーケットプレイスをはじめとする各事業の成長を後押しするため、プロダクトと密に連携しながら、EGP を活用したお客さま向けコミュニケーション機能の開発・改善を進めていきます。 Incentive チームは、メルペイ Payment & Customer Platform の一員として、インセンティブを汎用的かつ安全に取り扱える仕組みづくりを推進していきます。 チームは分かれますが、メルカリグループ全体で活用される共通 Foundation として、連携は継続していきます。 まとめ ここまで、Growth Platform のプロダクトやチームの拡大について簡単にご紹介しました。プロダクトや技術の詳細は、本エンジニアリングブログやカンファレンスでメンバーが紹介していますので、そちらもぜひご覧ください。 これからもメルカリグループの可能性を広げるための仕組みづくりを追求していきます。 次の記事は abcdefujiさん と becosukeさんです。引き続きお楽しみください。