LLMを活用した「しゃべるおさいふ」のバックエンド設計

こんにちは。メルペイバックエンドエンジニアの @kobaryo です。 この記事は、Merpay & Mercoin Advent Calendar 2025 の20日目の記事です。 はじめに メルカリグループは現在、AI Nativeな会社を目指しており、開発プロセスへの活用はもちろん、社内のさまざまな業務においてAIを使った効率化の取り組みが進んでいます。それ以前にも、プロダクト面ではメルカリの「AI出品サポート」やメルカリ ハロの「かんたん求人作成」など、AIを活用した機能がこれまでに複数リリースされてきました。 そして今回、メルペイでもAI Nativeなプロダクトを実現すべく、2025年9月に「しゃべるおさいふ」機能のPoCを開始しました。この機能は一部のお客さま向けに限定提供しているため、体験できていない方もいらっしゃるかもしれませんが、本記事では、この「しゃべるおさいふ」機能のバックエンド設計について解説します。 まずは機能の概要を紹介し、その後、アーキテクチャやLLMを利用するがゆえに発生する特有のポイントについて説明していきます。 「しゃべるおさいふ」機能とは 「しゃべるおさいふ」は、メルカリアプリのおさいふタブを開くと、LLMがお客さま一人一人の決済履歴やポイントの有効期限などをもとに、ひとことコメントを返してくれる機能です。 「◯◯ポイントがあと×日で失効するので、よく行くカフェで使いませんか？」といった実用的な提案から、画像のようにちょっとした雑談めいたコメントまで返してくれます。 [画像] 近年のLLM活用はチャットUIのようにお客さまが能動的に行動する形式が主流ですが、この機能は「日常的なメルペイの利用の中でAIからのコメントが届く体験」がアプリ訪問や決済行動に寄与するのかを検証する狙いがあります。この機能によって「今日はいつもと違う買い物をしたけれど、どんなコメントが返ってくるのだろう？」と、決済体験を少しでも楽しくしたいと考えています。 アーキテクチャ ここからは、具体的な設計について説明します。PoCであることから、少人数・短期間での開発を前提とし、シンプルな構成を重視しています。 [画像] 短期間でのリリースを実現するため、新たなマイクロサービスは作らず、既存サービスにエンドポイントを追加する形を採用しました。ただし、LLMへのリクエストはレイテンシが大きくなることが予想され、さらにPoCのため解放人数が動的に変化し、負荷の変動が大きくなり得ます。そのため、APIサーバーとは独立したworkerを設けて処理を非同期化し、他機能への影響を避けつつ、「しゃべるおさいふ」だけを容易にスケールできるよう設計しました。この構成によって、設計開始から社内テスト用の実装まで1ヶ月弱、そこからリリースまでにもおよそ1ヶ月とスムーズに進めることができ、短期間での立ち上げに大きく寄与しました。 大まかなフローは次のとおりです。 1. メルカリアプリがエンドポイントを叩くと、jobがPub/Sub経由でworkerに送信され、アプリ側はjob完了までポーリングする 2. workerがお客さまの情報をもとにLLMに問い合わせ、生成したコメントを保存する 保存したコメントは、後述するコスト削減のためのキャッシュとしても活用されます。 実装におけるポイント ここでは、LLMを用いることで生じた課題と、その解決方法について解説します。LLMの設定により解決したものもあれば、そうではないものもあります。 フィルタリング LLM活用における最大の懸念点は、不適切または意図しない出力がそのままお客さまに表示されてしまうことです。LLM自身がある程度有害な内容を抑制するとはいえ、プロダクトとして避けたい表現は依然として存在します。 そのため生成コメントに対して、次の3段階のフィルタリングを行い、いずれかに該当した場合は再生成する仕組みにしています。 * 文字数制限 * 表示上の都合から、決済に関わる重要情報（バーコードや残高など）と干渉しない長さに収める必要があります。トークン数制限もしていますが、文字数とトークン数は必ずしも比例しないため文字数チェックも併用しています。 * 単語単位でのフィルタリング * 明らかにNGな語句については、後述のLLMによるフィルタを通す前に弾くことで、レイテンシとコストを抑えています。 * LLMによるフィルタリング * 設定したポリシーを添えて、生成コメントを再度LLMに渡し、内容がポリシーに沿っているかチェックしています。 さらに、これらのフィルタリングが有効に機能しているかを検証するため、バックエンドでは任意のお客さまデータやプロンプトをrequest bodyとして渡し、それを基にコメントを生成できるQA用エンドポイントも用意しました。QAではポリシーに抵触しそうなプロンプトやデータを入力し、その返答を確認するサイクルを繰り返すことで、フィルタリングの有効性を検証しています。 コスト・レイテンシ LLMを利用するうえで、コストとレイテンシの問題は避けられません。この機能はお客さまの操作なしで自動表示されるため、リクエスト数が増えることが予想されますし、表示が遅れるとおさいふタブからの離脱につながります。 コスト観点では、LLM側の設定と仕様側の工夫の両面から対処しています。LLM側の設定としては、プロンプトの静的な部分と動的な部分を切り分け、前者をプロンプトキャッシュすることでコストを削減しています。仕様面では、1人のお客さまに対して1日に生成するコメント数に上限を設けることで、過剰な生成を抑えています。上限を超えた場合は、既に生成済みのそのお客さまに向けたコメントを再利用するようにし、推論コストを減らしています。ただし、体験面では「コメント→決済→コメント」というサイクルが心地よく回ることが重要なため、決済が行われた際にはこの上限を緩和する仕組みを取り入れています。これにより過剰な生成は抑えつつ、決済行動に応じたコメント更新の楽しさは損なわないよう工夫しています。 レイテンシ観点では、事前にバッチでコメントを生成しておく方法も検討できるものの、決済直後の情報がすぐにコメントへ反映される体験を重視し、リアルタイム生成を採用しています。ただし表示までに時間がかかると離脱につながるため、モデルやlocationの選定により、概ね3〜4秒以内に返答されるよう調整しています。 その他 これらの課題以外にも、いくつか工夫が必要な点があります。 1つ目は、お客さまにとってコメントが自然に感じられるかどうかです。たとえば、レイテンシの項で述べたように、決済情報を即座にコメントへ反映する仕組みはその一例です。また、LLMは現在の日付や時刻、日付から曜日への変換をしばしば誤るため、日時情報はバックエンド側で生成し、プロンプトとして明示的に与えるようにしています。さらに、ポイントのように時間経過で値が変わる情報を使用するコメントについては、キャッシュとして表示しないようにしており、自然さが損なわれないよう配慮しています。 2つ目は、モデルやプロンプトなどの設定を容易に変更できるようにすることです。しゃべるおさいふでは複数のLLMプロバイダのリクエスト形式に対応しつつ、コメント生成とフィルタリングの双方について、リリース作業なしでモデルやtemperatureなどの設定値を変更できる仕組みを備えています。また、ランダムに選択されるコメント種別、そのプロンプト、お客さまデータの組み合わせを宣言的に記述できるようにすることで、変更のしやすさも確保しています。 おわりに 本記事では、メルペイのPoC機能「しゃべるおさいふ」について、その概要と設計上のポイントを紹介しました。 LLMモデルが強化され、幅広いタスクを汎用的にこなせるようになってきた今、LLMを使ったプロダクトの差別化にはUXの工夫がますます重要になっていると感じます。この「しゃべるおさいふ」プロジェクトで得られたLLMのプロダクト活用に関する知見を基盤に、今後もLLMをプロダクトにどのように組み込むべきかを継続して探求していきます。 明日の記事はntkさんです。引き続きお楽しみください。

LLMを活用した「しゃべるおさいふ」のバックエンド設計

背景や根拠まで確認しますか？

調べる

選ぶ

サイト