メルカリのエンジニアリングブログが2026年11月10日に、社外の事業者が持つ商品データを、メルカリの「商品カタログ」の形に変える処理を、AIを前提に作り直した事例を公開しました。以前は、人が決めたルールをGoのバッチで実装していました。新しい方式は、変換ルールを自然言語のプロンプトに移し、LLMに変換させ、そのプロンプトを書く作業もAIエージェントに任せるものです。メルカリは、導入した四半期に「ほぼ同じ人数で6カテゴリーを連携でき、連携件数は導入前の40倍以上、新しいカテゴリー1つを連携する工数は約55%減った」と書いています。
先に、数字の読み方を分けます。「全項目が正しい」レコードの割合は、ポケモンカード1,000件のオフライン評価で、ルールベースが69.6%、本番で使うモデル（gpt-5.4-mini）にエージェントが調整したプロンプトを使うと85.2%でした。この評価はポケモンカードだけで、15項目すべてが一致して初めて正解という厳しい指標です。40倍や55%は、導入した四半期と導入前の四半期の比較で、条件をそろえた実験ではありません（メルカリの記載）。下で、確認できる構成から順に整理します。
何を置き換えたのか
- ▸対象：商品カタログへの外部データの連携。商品カタログは、「製品そのもの」を1つにつき1レコードで持つマスタデータです。出品（個体）はその製品に紐づきます。ポケモンカードなら、「ピカチュウex」のような1枚のカードが1レコードで、カード名・収録セット・レアリティ・カード番号などの属性を持ちます。人が1件ずつ登録するだけでは、網羅できる商品に限界があるので、商品データを持つ事業者のデータを取り込みます
- ▸変換が必要な理由：外部のデータは、その事業のために作られていて、たとえばカード名・レアリティ・加工が、商品説明の文章の中にまとめて書かれていることがあります。メルカリのカタログは、それらを別の項目として持つので、文章から抜き出す必要があります。ほかにも、表記をそろえる、カタログとして掲載するかを決める、商品名や説明文を組み立てる、といった作業があります
- ▸旧方式：カタログスペシャリスト（データとドメインに詳しい担当者）がルールを仕様書にまとめ、エンジニアがGoのバッチに実装していました。レアリティの「SR」やセット売りの「まとめ売り」など、文字列や辞書で探すルールです
- ▸旧方式の限界は2つ。書き方は同じレアリティでも「SR」「スーパーレア」と分かれ、新しい書き方が出るたびにルールを足すことになり、足す間は取りこぼします。ルールを直すには、仕様書の更新・実装・テスト・レビュー・デプロイを踏むので、スペシャリストは自分で直せません。また、新しいカテゴリーを連携するたびに作業を一からやり直すので、1四半期に1カテゴリーが限界でした
ブログで確認できるアーキテクチャ（2つの部品）
- ▸LLM Data Conversion（変換の仕組み）：外部データの1レコードと、変換プロンプトを、LLMに渡します。LLMの出力は、出力スキーマに沿ったJSONで受け取り、それをコードでメルカリのカタログの属性に対応付けて登録します。本番では、外部データを取り込む既存のバッチのうち、変換の部分だけをこの仕組みに置き換えました。変換ルールの大部分は、「セット売りは掲載しない」のように、パターンの列挙ではなく意味でプロンプトに書きます。細かな表記の違いは、LLMが吸収します
- ▸プロンプトはMarkdownのファイル：リポジトリにMarkdownとして置くだけで、ほぼそのまま本番の変換に使われます。そのため、連携を始めたあとに誤りや新しい書き方が見つかっても、スペシャリストがエンジニアを介さずにルールを直せます。ルールが固まったあと、エンジニアがするのは、バッチにプロンプトを登録して少しのコードを足すことです
- ▸Prompt Generation Agent（プロンプトを作るエージェント）：スペシャリストが、Claude Codeに「ワンピースカードの変換プロンプトを作って」のように頼むと、データの調査・プロンプトの作成・サンプルでの評価・改善までを、対話しながら進めます。新しいアプリではなく、Agent Skills（手順書・参考資料・スクリプトの一式）として作って配布しました。手順を良くしたいときは、指示書を書き換えるだけです
- ▸エージェントの5つのステップ：①対象のカテゴリー・提供元・既存の資料を確かめる。②社外データをBigQuery上でSQLで調べ（欠損率、値の分布、表記の違い、鑑定品やセット売りのような例外）、メルカリの属性との対応を整理して、スペシャリストに確かめてもらう。③プロンプトと出力スキーマを作る。④数百件で手元で実行して評価する。⑤問題があれば③に戻り、評価を通ったものを確定版として出す。数百を超える列があるデータで、人が何日もかけていた確認が、対話しながら数十分で終わる、と書かれています
LLMの誤りを、どう抑えているか
- ▸①出力の形を縛る。LLMを呼ぶときにStructured Outputs（項目と取りうる値をJSON Schemaで渡すと、その形のJSONしか返さなくなる機能）を使います。レアリティを「SR」などの決まった値から選ぶ項目にすれば、「スーパーレア」のような決めていない書き方や、項目の抜けは起きません。ただし、縛れるのは形までで、決められた値の中から別の値を選ぶ誤りは防げない、とも書かれています
- ▸②LLMに任せることと、任せないことを分ける。基本は任せますが、ロジックが単純で任せる利点が小さい処理と、出力が揺れるとデータの整合性が崩れる処理は、あえてコードで書きます。例は、メルカリのカタログにすでにある商品は新しく登録しない、という判定です。ここが揺れると同じ商品のレコードが2つできるので、コードで行い、テストで保証しています。どちらに分けるかは、実際のサンプルを手元で変換して、出力の揺れを見て決めます
- ▸③誤りを見つけて直す運用ループ。登録したデータを定期的に確かめて誤りを見つけ、まずその場で手で直します。ただ、バッチは外部データを取り込むたびに変換し直すので、手で直しただけでは次の更新で元の誤りに戻ります。そこで、直したデータにフラグを付けて、バッチの更新から外し、誤りの原因のプロンプトを直します。直したプロンプトは、本番と同じコードで変換し、登録せずに結果をCSVに出すdry-runで、直したい誤りが直ったか、これまで正しかったデータが崩れていないかを確かめます。本番に入ったらフラグを外して、更新に戻します
確認できる数字（メルカリの記載）
- ▸オフライン評価の設定：ポケモンカード。社外データとメルカリのカタログの組を1,000件取り出して評価用にし、エージェントは、調整のあいだ評価用のデータを見ず、開発用のデータだけを見ました。採点はカード名・収録セット・レアリティ・カード番号など15項目の完全一致で、主な指標はすべての項目が正しいレコードの割合（全項目正解率）です。プロンプトを作る側のエージェントは、Claude Code上で動かし、モデルはClaude Opus 5.5と書かれています
- ▸ルールベースの全項目正解率：69.6%。
- ▸本番で使うgpt-5.4-mini：例を並べただけのプロンプト（Few-shotのみ）は66.2%（ルールベースを下回る）。エージェントが調整したプロンプトは85.2%で、ルールベースを15.6ポイント上回りました。調整では、入力にない値を自分の知識で補ってしまう誤りを防ぐ「入力にない値を補わない」といったルールを足し、選択肢の並べ方を工夫したと書かれています
- ▸より性能の高いgpt-5.6：Few-shotのみで92.3%、調整後は98.7%で、ルールベースを29.1ポイント上回りました。本番で使っているのはgpt-5.4-miniで、コストも考えた選択と書かれています
- ▸導入した四半期の成果（導入前の四半期との比較）：導入前は1四半期に1カテゴリーが限界だったが、ほぼ同じ人数で6カテゴリーを連携し、連携した件数は導入前の40倍以上。新しいカテゴリーを1つ連携するまでの工数は約55%減。特に、社外データの中身の確認と変換処理を作る作業は、導入前の3分の1以下。LLMの利用料は新しくかかるが、1件あたりはごくわずかで、人手でルールを作る工数と比べて十分に小さい、とある（金額は書かれていません）
数字の読み方（当サイトの見方）
- ▸「85.2%」は、ポケモンカード1,000件・15項目すべて一致という指標での値です。ほかのカテゴリーや、実際に運用しているデータ全体の精度ではありません。1項目でも誤れば不正解になるので、項目ごとの正解率より低く出る、とブログも書いています
- ▸「40倍以上」は、ブログの表現では「連携した件数」です。何の件数か（カタログのレコードか、外部データの件数か）は、ブログの本文からは確かめられませんでした。カテゴリー数（1→6）とは別の数字です
- ▸「約55%減」は、新しいカテゴリー1つあたりの工数です。導入した四半期と、導入前の四半期の比較で、条件をそろえた実験ではありません
- ▸「98.7%」は、本番で使っていないモデルの値です。本番のgpt-5.4-miniの85.2%と混ぜないでください。同じFew-shotでも、gpt-5.4-miniは66.2%、gpt-5.6は92.3%と、モデルの世代で差が大きく、調整しても埋まりきらない、とブログは書いています
- ▸モデル名は、ブログの記載どおりです。当サイトでは、各モデルの仕様や提供状況を確認していません
まだ人手が残っているところ
メルカリ自身が、誤りを見つけて直すループには「まだ人の手が多く残っている」と書いています。誤りは、人が定期的にデータを確かめて見つけ、プロンプトの修正を本番に反映するにはリリースが要ります。連携するカテゴリーが増えるほど、ここがボトルネックになる、とあります。次の計画として、自動評価で誤りを見つけ、エージェントが修正案を作り、デプロイなしで本番に反映できるようにして、スペシャリストの役割を、修正案の確認と承認に寄せていく、と書かれています。これは計画で、すでに動いているとは書かれていません。
確認できなかったこと
- ▸6カテゴリーの内訳と、連携先の事業者名。ブログに書かれていません。評価に使ったのがポケモンカードで、プロンプトの例にワンピースカードが出る、という範囲です
- ▸「40倍以上」の件数の具体的な数。導入前後の件数は書かれていません
- ▸LLMの利用料の金額。「1件あたりはごくわずか」とだけ書かれています
- ▸本番に出したあとの実際の誤り率。ブログの精度の数字は、オフライン評価のものです
- ▸検索や出品の体験が、どれだけ良くなったか。カタログが検索の絞り込みや出品の入力の手間を減らす、という一般的な説明はありますが、この取り組みでの効果の数字はありません
- ▸ブログの図1〜4と表1〜4の中身。当サイトが取得できた本文には、図表の内容が文字として含まれていませんでした（画像と思われます）。本文の文章から確認できた範囲で書いています。表3・表4の数字は、本文に書かれていたものだけを使いました
この事例から持ち帰れること（当サイトの見方）
- ▸ルールが「書き方の数だけ増える」仕事は、意味で書くプロンプトに向く。そのうえで、LLMに任せない処理を決めておくのが大事です。メルカリは、重複登録を防ぐ判定のような、揺れると整合性が崩れる処理をコードに残しています
- ▸出力の形は、先に縛る。JSON Schemaで値の候補を決めておけば、決めていない書き方は出せません。ただし、候補の中の取り違えは防げないので、運用で見つける仕組みが要ります
- ▸手直しだけで終わらせない。手で直したデータが次の更新で元に戻らないよう、フラグで更新から外し、原因のプロンプトを直し、dry-runで確かめてから戻す、という順序は、LLMを使った変換の運用で参考になります
- ▸プロンプトを書く作業を、評価つきで自動化する。エージェントがデータを調べ、数百件で評価してから直す、という形です。ここで、評価用のデータを調整のあいだ見せない、というのは、数字を信じるための前提です
- ▸数字は、評価の条件とセットで読む。「正解率が上がった」は、どのデータで、どの指標で、どのモデルかを確かめてからにしてください