ID:84327さん

# プロジェクト経験概要 EC事業者向けに、サイト内検索エンジンとレコメンドエンジンを B2B SaaS で提供している会社です。 バックエンドエンジニアとして検索まわりを担当しています。 提供形態は API です。マルチテナントではなく顧客ごとに独立した検索サーバーを立てる方式なので、 案件ごとにインデックス設計とチューニングを個別にやる必要があります。 商品データは1案件あたり数万点から約100万点。累計20件弱を担当し、常時10案件以上を並行しています。 担当は、検索API、インデックス設計、クエリ解析、データ連携、バッチ処理、管理画面、ログ分析、ランキング改善。 要件確認から設計・実装・リリース・運用保守・障害対応・顧客折衝まで、案件の主担当として通しで見ています。 # チーム情報 検索プロダクトの開発と導入を担当するエンジニアチームで、人数は2名です。1案件あたりの担当は2〜3名。 案件ごとに主担当を決めていて、私は主担当として担当案件を一人で回しています。 仕様の判断、スケジュール、複数案件の優先度の差配も主担当の裁量です。 ほかに新卒メンバーのOJT担当として、タスクの割り振りとマージリクエストのレビュー、質問対応をしていました。 顧客・営業・インフラチームとのやり取りは非同期が中心で、進捗は毎朝の朝会で報告しています。 **以下の記載は、断りがない限り自分が担当したものです。チームで分担した箇所はその都度明記します。** --- # 開発・実装内容A: 検索エンジンの導入とインデックス設計・検索ロジック調整 【概要】 自社の検索エンジンを顧客のECサイトに導入し、商品データの構造と検索要件に合わせてインデックスと検索ロジックを設計する。累計20件弱。 【どのような機能の開発・実装か】 Solr のスキーマ設計とインデックス設計（フィールド設計、アナライザ構成）。 スコアリング、並び順、絞り込み条件、キーワード一致条件、カテゴリ判定、在庫考慮、人気順・売上順、商品属性の重み付けの調整。 検索対象データの前処理（商品説明文のHTMLタグ除去など）もここに含まれます。 プロダクト本体の共通機能はチームで開発し、案件ごとの設計・調整を私が担当しました。 【課題・問題点】 商品ドメインが変わると「良い検索結果」の中身も変わります。 アパレルなら色とサイズのバリエーション、総合通販ならカテゴリ階層の深さ、紳士服なら性別の出し分けが論点になる。 プロダクトの標準設定のままでは要件を満たせません。 かといって案件ごとに作り込むと、導入後に何年も続く運用で保守しきれなくなります。 【打ち手・使用した技術】 顧客要件を、設定値やデータ側で吸収できるものと、個別実装が要るものに切り分けました。 できる限り設定側に寄せて、コード分岐を増やさないようにしています。 紳士服ECでは、上位キーワードごとのブースト設計を対応表にまとめました。 「スーツ」でメンズをレディースより上に出す、といった単位で表にして顧客と合意し、開発環境で確認してから本番に入れる流れです。 アパレルECでは、性別ブーストの `bq` を OR 条件で1クエリにまとめて指定回数を減らしました。 正規表現の先読み・後読みを使う案も出ましたが、パフォーマンスのリスクがあるので採用していません。 使用技術は、Solr（スキーマとインデックス設計、`bq` でのブースト設計、クエリチューニング）、 Python / Django（検索API、管理画面）、MySQL（商品マスタと設定データ）、Linux / Apache / Docker（検索サーバー）。 【成果】 累計20件弱の導入から運用までを担当し、常時10案件以上を並行しています。 ブースト設計を対応表にして顧客と合意する形にしたことで、 顧客が出したい商品とユーザーの検索意図のずれを、実装前に潰せるようになりました。 --- # 開発・実装内容B: インデックス更新基盤の開発・運用と障害対応 【概要】 連携データの取込から検索インデックスへの反映までのバッチ処理と検索API。あわせてバッチ失敗とインフラ障害への対応。 【どのような機能の開発・実装か】 連携データの取込処理、インデックス更新バッチ（全件更新と差分更新の2系統）、検索APIの開発と改修。 バッチ失敗、データ反映遅延、検索結果とマスタの不整合の調査と改修。 インフラ障害が起きたときの、顧客ごとの影響範囲の精査と障害報告書の作成も担当しました。 【課題・問題点】 検索結果の正しさは、インデックスに入っているデータの鮮度と正確さで決まります。 ところが原因は、連携データ、取込処理、インデックス、クエリのどこにでもあり得ます。 「検索結果に出ない」「価格が古い」という形でエンドユーザーに見えるので、切り分けに時間をかけられません。 全件更新の負荷も問題で、更新中に検索を止めるわけにいきませんでした。 【打ち手・使用した技術】 全件更新でも検索を止めない方式で運用しています。 作業テーブルを作り直してからXMLを並列生成し、ユニークキーで上書き投入して最後にコミットする。 コミットまでは旧インデックスで検索が生き続けます。 障害の切り分けは、連携データ → 取込バッチ → インデックス → 検索クエリの順に上流から見る手順に固定しました。 データセンターのネットワーク障害では、6社が同時に影響を受けました。 顧客ごとに契約している製品が違うため、製品単位で影響の有無を精査しています。 このとき、当初の報告に入っていなかった広告連携への影響を見つけて報告書に追記しました。 報告は二段階に分けました。確定している事象と影響範囲だけで第一報を出し、 原因と再発防止はデータセンターの正式報告を受けてから第二報として送っています。 使用技術は、Python / Django（バッチ、XML生成、API）、Solr（インデックス更新とコミット制御）、 MySQL、Linux と cron（実行基盤、失敗検知）、Zabbix（サーバー監視）。 【成果】 全件更新中も検索を止めずに運用を続けています。 切り分けの順序を固定してから、問い合わせを受けて原因にたどり着くまでの手戻りが減りました。 障害時は6社分の影響範囲の精査と報告を担当しています。 --- # 開発・実装内容C: ゼロ件ヒット対策と検索品質の月次改善 【概要】 検索ログからゼロ件ヒットなどの課題を洗い出し、辞書やロジックを直して顧客に報告するところまで。 【どのような機能の開発・実装か】 クエリログの集計によるゼロ件ヒットキーワードの特定。 同義語辞書とユーザー辞書の整備、および自動反映の仕組みへの載せ替え。 月次レポート（ゼロ件ヒットと検索ヒットランキング）の作成と顧客への納品。 【課題・問題点】 化粧品ECで「機内持ち込み」「海外輸送」が0件になっていました。 ユーザーは用途で探しているのに、商品側は容量表記でしか書かれていない。語彙のギャップです。 それと、単発で直しても翌月には別のキーワードで同じことが起きます。 【打ち手・使用した技術】 商品データ側にその語が含まれていないことを確認したうえで、同義語辞書に登録し、以後は自動反映される仕組みに載せました。 商品データそのものを直す案もありましたが、顧客側の運用負荷が大きいので辞書側で対応しています。 アパレルECでは、月次のゼロ件ヒットレポートを継続して納品する運用にしました（2025年6月から継続）。 効果は、対応したキーワード単位のヒット確認と、月次レポートの推移の両方で見ています。 商品の入れ替えという交絡があるので、全体率の増減だけでは判断していません。 使用技術は、Solr（同義語辞書、ユーザー辞書、アナライザ）、DuckDB（ログ集計）、Python（集計とレポート生成）。 【成果】 依頼のあったキーワードについて、対応後にヒットすることを確認して顧客に報告しています。 レポート → 対応 → 翌月の数字で確認、というサイクルにしたことで、 その場しのぎの修正ではなく、品質を維持し続ける運用になりました。 --- # 開発・実装内容D: 「おすすめ順」の改善 【概要】 ホビー通販ECのおすすめ順を、アクセス解析のデータをもとに自分から提案して改善した案件。分析から本番リリースまで担当。 【どのような機能の開発・実装か】 GA4 の計測結果の分析と、改善方針の提案。 おすすめ順のスコアリング設計（大ジャンルを参照した重み付け、新着商品の重み付け、在庫のある商品の上位化）。 本番リリースとリリース後の確認、月次の定性評価レポートでの追跡。 【課題・問題点】 顧客からの不満が起点ではありません。 GA4 の数字を見ていて、CVRを上げるならおすすめ順の最適化が効くと判断し、自分から持ちかけました。 ただ、重みを感覚で決めると他のキーワードで検索結果が悪化します。 【打ち手・使用した技術】 GA4 で売上上位500件の商品傾向を調べ、大ジャンルを参照した重み付けを顧客定例で提案しました。 根拠を売上データから作ったので、顧客と議論できる形になっています。 その後、新着商品の重み付けと、在庫のある商品を上位に出す調整を実装して本番リリースしました。 使用技術は、GA4（提案の根拠）、Solr（スコアリングとブースト設計）、Python / MySQL（在庫・新着の属性連携）。 【成果】 要望を受けての対応ではなく、アクセス解析のデータを根拠にした提案から本番リリースまで持っていけました。 リリース後はカテゴリ絞り込みの検索結果で在庫商品が上位に来ることを確認して報告し、月次の定性評価レポートで追っています。 --- # 開発・実装内容E: 生成AIの活用 【概要】 対話型検索機能での社内ホストLLMのプロンプトチューニングと、ハッシュタグ機能でのタグマスタ生成の自動化。 【どのような機能の開発・実装か】 対話型検索では、自然言語の入力を検索クエリに変換する部分のプロンプト設計と改訂。 ハッシュタグ機能（ゲーム系EC）では、タグマスタをLLMで自動生成する仕組みの設計と、生成から登録までの自動化。 あわせて、生成結果の品質を測る仕組みを作りました。 【課題・問題点】 LLMの出力は同じ入力でも揺れます。 プロンプトを変えて出力が良くなったように見えても、改善なのかたまたまなのか判別できませんでした。 タグマスタのほうは、作成と確認が手作業で担当者の負荷になっていました。 【打ち手・使用した技術】 独立した132商品の検証セットを用意して、生成されたタグに違和感がないかを別のLLMに判定させる形にしました。 これで、同じ入力に対する出力の差分でプロンプト改訂の可否を判断できます。 あとはこのサイクルで改善を反復しました。 使用技術は、社内ホストLLM（タグ生成と判定）、Python（生成から登録までの自動化、評価の実行）。 【成果】 違和感のある行の割合が 19.1% から 0.2% になりました（独立132商品の検証セットでの評価）。 手作業だったタグの作成・確認を自動化して、担当者の負荷とリードタイムも減っています。 --- # 開発・実装内容F: 商品数増加に伴うキャパシティ試算とサーバー構成変更 【概要】 航空系ECで商品数が増える計画が出たときに、既存の検索サーバー構成で耐えられるかを試算し、構成変更と切替検証まで担当。 【どのような機能の開発・実装か】 商品数増加に対する検索性能の試算。サーバー構成の変更（2台から3台）の検討と顧客への回答。 切替時の動作確認手順の整備と検証。 【課題・問題点】 商品数が70万件から約100万件、およそ1.43倍に増える計画でした。 「増えるので危ない」では、構成を変えるべきかどうかも、変えなくていいのかも決められません。 【打ち手・使用した技術】 検索処理の計算コストを商品数 N に対して N^α とモデル化し、やや重めに α=0.5 と置いてQPSの低下を見積もりました。 結果は、商品数1.43倍でQPSが8割強まで下がる見込み。 現状の負荷に余裕があることを確認したうえで、2台構成から3台構成に変えれば対応できると顧客に回答しています。 切替のときは、検索の各号機・ロードバランサ・フロントの動作確認手順をコマンドレベルで書き出して検証しました。 使用技術は、Solr（性能測定と構成変更）、Linux / Apache（サーバー構成とロードバランサ）。 【成果】 データ量の増加が検索性能にどう効くかを数字で見積もり、構成判断の根拠として顧客に出しました。 切替は手順を整備したうえで実施しています。 --- # その他の担当範囲 - パーソナライズ検索。閲覧履歴・購買履歴・クリックログ・会員属性を使った検索結果の出し分け - レコメンドAPIの開発と運用 - ECプラットフォームの移行。顧客サイトの Shopify リニューアルに伴い、既存の検索仕様を新環境に移しました。 仕様書に残っていない挙動があったので、設定とインデックス定義から実際の動きを洗い出したうえで設計し直しています - ソート仕様の設計と顧客調整。スコア第一ソートに `bq` の重み付けを組み合わせて関連度順を実現。 カテゴリとジャンルを同時指定したときの関連度の基準は顧客に確認しました - 問い合わせ調査。アクセスログから実際のリクエストを特定し、同じ条件で検索エンジンに直接クエリを投げて再現してから原因を判断しています。 絞り込み条件ではなく商品側の表示先設定が原因で、仕様どおりの挙動だったケースもありました