はじめに こんにちは。医療プラットフォーム本部ビジネス基盤グループでエンジニアをしている熊本です。 ブログへの登場は久々となりますが、2019年に新卒で入社して以来、長らくプロダクト開発のエンジニアをしてきました。そんな私は現在、医療プラットフォーム全体のMA（マーケティングオートメーション）、SFA（営業支援）、CRM（顧客管理）といったITツールおよび業務フローの設計・改善を通じて、事業パフォーマンスの向上を担う開発組織のマネージャーを務めています。 メドレーでは、患者・生活者と、病院・有床診療所、医科診療所、歯科診療所、調剤薬局といった各医療機関向けに事業・プロダクトを展開していますが、今回は、これらの事業を支えるITツールの Salesforce を kintone へ移行したプロジェクトについてお話しします。 背景 SFAが抱えていた課題 弊社では長年、医療プラットフォームにおける複数の事業部門で共通のSalesforceを利用してきましたが、運用を続ける中で以下のような課題が顕在化していました。 最新・正しい情報の把握が困難 ：正規化されていないデータや重複管理による情報の分散 データ分析の壁 ：分析を見据えた設計になっておらず、プロダクト側の利用状況との突合など、柔軟なデータの加工に工数がかかっていた 非効率な業務フロー ：複数ツールの併用や重複する項目の存在などを背景に、手動での転記やダブルチェックが発生している状態 システム管理の属人化 ：目的が不明な項目が乱立し、メンテナンス・レポート作成ができる人が限られている状態 また、130個近くのライセンスを保有していたため、これらの課題を踏まえるとコスト過多な状況にも陥っていました。 全ての顧客体験をプロダクト側が理解し、設計責任を持つ 私たちは、 営業・カスタマーサクセスといった顧客活動から、契約・請求に至るまでを「一連のプロダクト体験」として捉え 、その設計・実装にエンジニアが深く関わることを大切にしています。 この考えに基づき、単なるツールのリプレイス（お引っ越し）ではなく、より良い顧客体験につながる合理的で整理された事業オペレーションを実現するため、 業務・データ・ツールを一体でエンジニアが設計し直す 。これが本プロジェクトの重要なポイントでした。 取り組み 体制構築とアーキテクチャ設計 前述の通り、Salesforceはこれまで複数の事業部門で活用してきました。1人で各事業の業務フローや必要データを把握し再設計するのは困難ですし、何より私たちが大切にしている考え方も踏まえ、プロダクトエンジニアが各事業に深く潜り込んで再設計すべきだと考えました。そこで、各事業領域からプロダクトエンジニアを1名ずつアサインする体制としました。私はPMとして全体設計や車輪の再発明が起きないよう各部門の連携をコントロールする役割を担い、各環境のデータ設計・構築はその事業領域担当のエンジニアが主導する形をとりました。 kintoneは責務分離やメンテナビリティを考慮し、事業領域ごとに環境を分けるアーキテクチャを採用しました。また、kintoneへの移行に伴い、コストや親和性を加味してMAツールの移行も行いましたが、本記事では詳細を割愛させていただきます。 医療プラットフォーム本部の組織体制 ツールの移行イメージ 業務理解と要件定義 まずは、日々の事業活動の中で発生するデータや、業務上必要となるデータ、およびそのフローの現状とあるべき姿を描くため、事業部とコミュニケーションを重ねました。長年利用してきたこともありデータ項目が膨大となっていたため、「このデータをどう活用するのか」を重点的に会話し、そもそも不要ではないか、より活用しやすくするにはどうすべきか、などの整理に時間をかけました。 データ設計 特に工夫したのは、DB観点での「正規化」とユーザー観点での「入力のしやすさ」のバランスをとったデータ設計です。kintoneはDBとUIが一体型であるため、このバランス調整にとても苦労しました。一般的なRDBMSではデータの履歴を残すために専用のテーブルを設けイミュータブルモデリングなどを採用する場面でも、kintoneだとテーブル≒アプリとなるため、テーブルを分けることは単純にユーザーの画面遷移や入力箇所を増やすことに直結してしまいます。こういった場合は完全な正規化をするのではなく、普段の商談管理で使用するアプリとその商談ステータスの履歴を管理するアプリを分け、それぞれのアプリに同類のフィールド（RDBMSのカラムをkintoneではフィールドと呼びます）を設置することを許容しつつも、JavaScriptを用いた自動転記の仕組みを作ることで、ユーザーは商談管理アプリだけに入力していれば良いようにするといった工夫をしました。 泥臭く戦ったポイント：データ移行と同期システム ここからは、エンジニアとして特に苦労した2つのポイントをご紹介します。 1. 冪等性と再現性を追求したデータ移行 100名以上が利用するシステムにおいて、特にデータ移行には慎重を期しました。具体的な方法としては、Salesforceのスキーマをkintoneのスキーマに変換し、データをマッピングした結果をCSVに出力するという一連の処理を、CLIコマンド等の整備によりスクリプト化しました。 データ移行では、一度kintoneに投入した後、UAT期間中に事業部からのフィードバックを受けて設計を見直し、再投入が必要になるケースがありました。また、リハーサル目的で、本番移行前にも何度でも再実行できる仕組みが必要でした。そのため、前述のように一連の処理をスクリプト化し、「再現性」を確保しました。さらに、「冪等性」も重要なポイントでした。今回のケースでは、それぞれのアプリにユニークキーを設けて常にUPSERT処理を行うことで、元データが同じであれば、何度実行しても同じ状態を再現できるようにしました。 kintoneへのインポート処理自体はレコード数に比例して一定の時間がかかってしまうものの、事前に手順化しリハーサルを重ねたことで、本番稼働前日の夜間作業で無事に移行を完了させることができました。ただし、（一定の想定範囲ではあったものの）移行作業直前にSalesforce側でデータの更新や削除が行われたことで、kintone側で関連データ同士の紐付けがうまく設定できないケースも発生しました。これはエラーログを見て個別に対処するしかなく、大変苦労した部分でもありました。 2. Salesforceとkintoneの双方向同期システム Salesforceは長年活用してきたことから、いわゆるSFAとしての機能だけではなく、請求や契約管理としての役割も担っていました。今回のプロジェクトでは事業部側が利用するSFAとしての機能はkintoneへ移行しつつも、請求や契約管理といったバックオフィス領域に関しては将来的な販売管理システムへの移行も見据えてスコープ外としていました。よって、これまでは一つのシステムの中で顧客・商談から契約・請求まで一元管理していたものを分離したため、システム間でデータを連携させる必要がありました。 詳細は省きますが、Salesforceに残った契約・請求関連データの一部は、営業やカスタマーサクセスなどの事業部側と契約・請求処理を担うバックオフィス部門の双方向による書き込みが業務上必要であったため、単にkintoneから必要なデータを一方向で送るだけでは要件を満たせませんでした。そのため、SFA領域とバックオフィス領域のハブとなる「商談」などのデータに関しては、Salesforceとkintone間で一部のスキーマ定義を揃え、両システムを一定間隔で同期させる仕組みとしました。 具体的な仕組みとしては、両システムのスナップショットを一定間隔で取得し、前回との差分を検知して互いのシステムへ反映し合う形をとりました。 ここで壁となったのが、「準リアルタイム性」の要求と「データの競合」です。両方のシステムで日常的にトランザクションが発生するため、「同じレコードの同じ項目が、それぞれのシステムで同時に別の値へ書き換えられる」可能性がありました。この競合状態を安全に解決するためのロジックを構築する必要があり、非常に苦労しました。 この対応にあたっては、当初想定していた対象項目が、本当に準リアルタイムで同期が必要なのかを関係者と徹底的に精査しました。その結果、同期間隔の調整や同期対象の大幅な絞り込みができ、現在は安定して稼働する仕組みを実現できています。 ※ データ移行や同期処理のディープな話は盛りだくさんな内容となってしまうため、また別の機会にブログ化できればと思います！ 成果 80%以上のランニングコスト削減 契約・請求などを担う組織の必要分を除き、90個ほどのアカウントを削除することができました。kintoneの費用を加味しても、全体のランニングコストとして80%以上削減することができました。 BigQuery集約によるデータ分析・可視化の実現 Salesforceのレポート機能の制約から解放され、より柔軟なデータ活用ができるようになりました。 KPIダッシュボードの構築 ：Looker Studioなどのアセットと連携したデータの分析・可視化が可能に 自律的な分析文化 ：勉強会の開催やマニュアル整備のおかげもあり、事業部メンバーが生成AIも活用しながら、より自律的かつスピーディなデータ分析が可能に 横断的分析 ：kintoneの顧客・商談データ、契約データ、プロダクトデータなどをBigQueryに集約し、多角的な分析を実現 また、横断組織にあるデータ戦略グループが、最近「自然言語でBigQuery等のデータを分析できる社内システム」をリリースしました。今回のプロジェクトによるデータ整備とこのシステムが組み合わさり、よりスピーディにデータ分析を行える環境づくりが加速しています。 関連記事： データ分析AIエージェントの実践 - Slack × Devin × Context Engineering 今後の展望 本プロジェクトによって多くの成果を得られましたが、私たちはまだ「業務やデータの一部をツールの移行と共に再設計し、基盤を整えた」に過ぎません。 今後はこの基盤を活かし、KPIなどの定量的なデータや現場ヒアリングを通じて事業の課題・ボトルネックを特定し、継続的に改善を回すサイクルを作っていきたいと考えています。 また、日々顧客と向き合う事業部のメンバー自身が、データ活用や拡張性を見据えて自律的にツールを改修できる状態こそが、組織のアジリティを最も高く保ちながらスケールできる理想の形だと考えています。その実現に向けて、エンジニアリングの専門性を持つ私たちビジネス基盤グループが、誰もが改修・改善しやすい仕組みづくりを牽引していきたいと考えています。 まとめ エンジニアが事業の深い部分に入り込み、業務・データ・ツールを一体で再設計するプロジェクトについてご紹介させていただきました。 メドレーでは、「医療ヘルスケアの未来をつくる」というミッションのもと、エンジニアがビジネスの根幹に関わり、プロダクトと事業を共に成長させる文化があります。自ら課題を発見し、設計から運用までをエンジニアとしてのリーダーシップを発揮しながら一気通貫で推進できる方を絶賛募集しています。 メドレーで働く｜株式会社メドレー メドレーでの働き方や人事制度、求人情報など、採用に関する情報をご紹介します。 www.medley.jp 少しでも興味を持っていただけましたら、ぜひメドレーの採用ページをご覧ください！

.table-of-contents > li > ul > li > ul { display: none; } はじめに こんにちは。データシステム部・MA推薦ブロックの伊藤（ @rabbit_x86 ）です。私たちのチームでは、メール配信などのマーケティングオートメーション（MA）に関する推薦システムを開発・運用しています。 従来、ZOZOTOWNのMA施策における推薦システムでは、 開発リードタイムと推薦精度のトレードオフ が課題でした。この課題を解決するため、ユーザーとアイテムをベクトルで表現したEmbeddingとBigQuery Vector Searchを活用し、施策を横断して利用可能な 汎用推薦システム を開発しました。本システムにより、開発リードタイムを 約1/3 に短縮し、A/Bテストで 配信当たりのMA経由流入数・購入数の改善 を達成しました。 本記事では、このシステムの設計思想・アーキテクチャ・構築時の技術的な課題と工夫、そして実際の事例を紹介します。 目次 はじめに 目次 背景と課題 従来の推薦アプローチとそのトレードオフ 機械学習ベースの開発リードタイム ルールベースによる推薦の限界 システム要件 アプローチ 前提知識：EmbeddingとEmbedding基盤 汎用推薦システム 全体構成 1. セグメント抽出 2. Embedding取得 3. Vector Index作成 4. Vector Search 5. スコアブースト・フィルタリング 6. 評価・バリデーション 技術的な課題と工夫 Vector Indexの非同期構築への対処 Vector Searchのスロット消費問題 運用事例 開発リードタイムの短縮 推薦精度の向上 まとめ 今後の展望 最後に 背景と課題 従来の推薦アプローチとそのトレードオフ MA施策では、対象ユーザー（ユーザーセグメント）と対象アイテム（アイテムセグメント）を施策ごとに定義し、パーソナライズされた商品を提供しています。その推薦システムは、「ルールベース」と「機械学習ベース」の2つのアプローチで構築されています。ルールベースは閲覧したカテゴリの商品を推薦するなど、行動ログに基づくルールでスコアリングするアプローチです。機械学習ベースは行動ログを活用しつつ、モデルが学習した潜在的な嗜好をもとに推薦するアプローチです。 これらのアプローチには精度と開発リードタイムのトレードオフが存在し、ルールベースは 高速だが推薦精度が低く 、機械学習ベースは 精度が高い一方で開発リードタイムが長い という課題がありました。 ルールベース 機械学習ベース ロジック 閲覧履歴・お気に入りなどの行動ログに基づくヒューリスティクス 専用の推薦モデルが学習した潜在的な嗜好に基づくスコアリング 開発リードタイム 短い 長い 精度 低い 高い 機械学習ベースの開発リードタイム 機械学習ベースの推薦にはモデルを実装する必要があり、施策ごとに以下の一連の開発工程を繰り返します。 工程 所要期間 探索的データ分析 約2週間 モデルの設計・実装 約3週間 パイプラインの設計・実装 約2週間 実験・評価・チューニング 約3週間 この結果、 1施策あたり約10週間の開発リードタイム が必要となり、仮説検証のサイクルが遅くなっていました。 ルールベースによる推薦の限界 一方、ルールベースのロジックでは、閲覧履歴やお気に入りブランドなど、ユーザーの顕在的な嗜好に基づく推薦が中心です。たとえば、「ブランドAを閲覧したユーザーにブランドAの値下げ商品を推薦する」といったルールなどです。こうしたルールは設計が容易な反面、ユーザーが触れた商品のみを推薦し、ユーザーの潜在的な嗜好を考慮した推薦ができないという課題がありました。 システム要件 そこで、 高速なモデル構築と高い推薦精度を両立 する仕組みが必要でした。 要件をまとめると以下のとおりです。 要件 詳細 高速な推薦システム構築 推薦システムを短期間で構築できること 高い推薦精度 ユーザーの潜在的な嗜好を捉えた推薦ができること アプローチ 上記の要件を満たすため、社内のEmbedding基盤とBigQuery Vector Searchを活用した汎用推薦システムを開発しました。 前提知識：EmbeddingとEmbedding基盤 Embeddingとは、データを固定長のベクトルとして表現する手法です。社内のEmbedding基盤では、ユーザーの行動履歴をもとにTwo-Towerモデルを使い、ユーザーとアイテムの類似度が意味を持つように共通の次元数の埋め込み空間へそれぞれエンコードします。ベクトル間のコサイン類似度を計算することで、ユーザーの潜在的な嗜好に近いアイテムを特定できます。 Embedding基盤については、推薦基盤ブロックで執筆した以下の記事で詳しく紹介しています。 techblog.zozo.com 汎用推薦システム 本システムは1つのモデルで複数の施策に対応できる汎用的な仕組みです。セグメントを定義してEmbeddingを抽出し、BigQuery Vector Searchで類似度を計算することで、パーソナライズされた推薦結果を生成します。従来必要だった 特徴量作成やモデル学習が不要 になるため、開発リードタイムを短縮できます。 さらに、Embeddingを利用することで、ルールベースでは捉えられなかったユーザーの潜在的な嗜好を反映した 高い推薦精度 を実現します。施策の目的に応じて関連スコアの調整やフィルタリングなどの後処理も適用でき、細かなチューニングにも対応できます。 全体構成 本システムは、社内のMLパイプライン基盤であるVertex AI Pipelinesで実行されます。 パイプラインの主要ステップを以下の表にまとめます。 ステップ 処理内容 実行環境 1. セグメント抽出 ユーザーセグメント・アイテムセグメントをSQLで抽出 BigQuery 2. Embedding取得 セグメントに対応するEmbeddingをEmbedding基盤から取得 BigQuery 3. Vector Index作成 アイテムEmbeddingにTREE_AHインデックスを作成し、完了まで待機 BigQuery 4. Vector Search ユーザーEmbedding × アイテムEmbeddingの関連スコアを算出 BigQuery 5. スコアブースト・フィルタリング 関連スコアのブースト・ペナルティによるリランキング BigQuery 6. 評価・バリデーション 定量評価（Vertex AI Experiments）、ポリシーチェック BigQuery / Vertex AI 1. セグメント抽出 施策ごとに定義されたSQLクエリで、対象ユーザーと対象アイテムを抽出します。たとえば、「過去30日以内にアクティブなユーザー」や「特定カテゴリの新着アイテム」などです。このSQLを差し替えるだけで、さまざまな施策へ対応できる設計です。 2. Embedding取得 Embedding基盤から、抽出したユーザー・アイテムに対応するEmbeddingを取得します。 3. Vector Index作成 Vector Searchの高速化のため、アイテムEmbeddingテーブルへ CREATE VECTOR INDEX でインデックスを作成します。本システムでは大規模バッチ向けの TREE_AH （GoogleのScaNNアルゴリズムベース）を採用しています。Vector Indexの構築にまつわる課題と対処法は、後述の「技術的な課題と工夫」で説明します。 4. Vector Search BigQueryの VECTOR_SEARCH 関数を用いてユーザーEmbeddingとアイテムEmbeddingのコサイン類似度を計算し、ユーザーごとに関連スコアの高い上位N件のアイテムを取得します。 -- Vector Searchの実行例（簡略化） SELECT query.member_id, base.product_id, distance FROM VECTOR_SEARCH( ( SELECT * FROM candidate_embeddings), -- アイテムEmbedding ' embedding ' , ( SELECT * FROM query_embeddings), -- ユーザーEmbedding ' embedding ' , top_k => 100 , distance_type => ' COSINE ' ) 5. スコアブースト・フィルタリング Vector Searchで得られた関連スコアは、そのままでは施策の目的に最適化されていません。そこで、ブーストやペナルティによるリランキングとフィルタリングを行い、最終的な推薦結果を生成します。 生成された推薦結果はBigQueryのテーブルに保存され、MAの配信システムがこのテーブルを読み込むことで連携します。 6. 評価・バリデーション パイプラインの最終ステップとして、推薦結果の品質を評価・検証します。 評価種別 内容 記録先 定量評価 NDCG、Precision、Recall等の指標を記録 Vertex AI Experiments ポリシーチェック 推薦結果がセグメント条件を満たすか、1ユーザーあたりの推薦数が閾値以上かなどを検証 BigQuery 技術的な課題と工夫 Vector Indexの非同期構築への対処 BigQueryのVector Indexは 非同期で構築 されるため、実行直後にはインデックスが利用可能になりません。インデックスが未完成の状態でVector Searchを実行すると、ブルートフォース（全件スキャン）で計算するため、実行時間とスロット消費が膨大になります。 この問題に対処するのが、全体構成図における Index完了待ち のコンポーネントです。以下のクエリで INFORMATION_SCHEMA.VECTOR_INDEXES の coverage_percentage を定期的にポーリングし、インデックス構築の完了を確認しています。 SELECT table_name, coverage_percentage FROM `{project_id}.{dataset_id}`.INFORMATION_SCHEMA.VECTOR_INDEXES WHERE table_name IN UNNEST(@expected_tables) coverage_percentage が100％に達した後、Vector Searchステップへ進むことでブルートフォース計算を回避しています。 Vector Searchのスロット消費問題 もう1つの大きな課題は、 共有スロット の大量消費による他ジョブへの影響 でした。Vector Searchはユーザーとアイテムの全組み合わせに対してコサイン類似度を計算するため、1回の実行で大量のスロットを占有します。 社内ではBigQueryのジョブを共通の容量ベースプロジェクトで実行しています。そのため、Vector SearchがBigQueryの共有スロットを圧迫すると自チームの実行時間の増大やSLO超過だけでなく、他チームのクエリ遅延・タイムアウトを引き起こすリスクがありました。 また、今回のケースではBigQueryのスキャン量が少ないという特徴がありました。そこで、 オンデマンド課金用の専用プロジェクト を用意してVector Searchのみをそのプロジェクトで実行するようにしました。オンデマンド課金はスキャン量に対して課金されるため、コストを抑えつつ共有スロットへの影響を回避し、十分な計算リソースを確保できました。 運用事例 上記の汎用推薦システムを実際のMA施策に適用し、開発スピードと推薦精度の両面で効果を検証しました。 開発リードタイムの短縮 施策ごとに約10週間かかっていた推薦システムの構築が 約3週間 で完了し、 約1/3 に短縮されました。以下の表に、従来と汎用推薦システムの工程比較を示します。 工程 従来 汎用推薦システム 探索的データ分析 約2週間 不要（Embedding基盤を利用） モデルの設計・実装 約3週間 不要（Embedding基盤を利用） パイプラインの設計・実装 約2週間 約1週間（セグメント設定と既存パイプラインの利用） 実験・評価・チューニング 約3週間 約2週間（後処理によるチューニング） Embeddingを活用することで、探索的データ分析やモデルの設計・実装が不要になりました。また、パイプラインの設計・実装についても、セグメント抽出用のSQLを変更するだけで新しい施策に対応できるため、短期間で実装できるようになりました。さらに、実験・評価・チューニングではモデルのパラメータの調整が不要であり、過去の評価コンポーネントや実験の仕組みも再利用できるため、後処理のチューニングへ集中できるようになりました。 推薦精度の向上 従来のルールベースの推薦（Control）と汎用推薦システム（Treatment）のA/Bテストを実施し、以下の結果を得ました。 指標 有意差の有無 配信当たりのMA経由流入数 有意差ありの勝ち 配信当たりのMA経由購入数 有意差ありの勝ち 配信当たりのMA経由受注額 有意差なしの勝ち 主要KPIである配信当たりのMA経由流入数・購入数で統計的に有意な改善を確認したため、汎用推薦システムの本番導入に至りました。 まとめ 本記事では、ZOZOTOWNのMA施策向けに構築した汎用推薦システムについて紹介しました。 本システムは、EmbeddingとBigQuery Vector Searchを活用し、施策を横断して利用できる汎用的な推薦システムです。従来必要だった特徴量作成やモデル学習が不要になることで開発スピードを向上させつつ、Embeddingによりユーザーの潜在的な嗜好を反映した高い推薦精度を実現しています。 実際のMA施策への適用では、開発リードタイムを約10週間から約3週間に短縮しました。さらに、A/Bテストでは配信当たりのMA経由流入数・購入数の改善を確認し、本番導入に至っています。 今後の展望 今後は以下の取り組みを予定しています。 Rerankerの導入 : 現在のスコアブースト・フィルタリングはルールベースで煩雑なため、機械学習ベースのRerankerを導入し、MA施策に最適化されたチューニングを実現する セグメント設定の効率化 : セグメント定義をviewなどで共通管理し、パイプラインごとの再実装をなくす 最後に ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

CRM（顧客管理システム）、SFA（営業支援システム）、MA（マーケティングオートメーション）ツールの役割、機能、活用方法、選定ポイントを紹介しています。各ツールの目的や管理対象、主な機能を比較し、企業の活用事例や選定時のポイントを解説しています。