オファー（Mirakl Offer）（オファー）

Miraklのカタログは「商品（Product）」と「オファー（Offer）」の2層に分かれている。

• 商品: 商品そのものを表すマスタ情報。JAN／GTINなどの識別子、オペレーターが定めたカテゴリ（タクソノミー）、必須属性、商品名、説明、画像など。セラーが変わっても内容は変わらない
• オファー: セラーが商品に紐づけて登録する販売条件。価格、在庫数、商品状態（新品・中古など）、出荷リードタイム、配送条件、セラー側の商品コード、セール価格と期間、有効・無効の状態など
• 紐づけ: オファーは商品識別子（JAN／GTIN）またはマーケットプレイス側の商品IDで既存の商品に結びつく。オペレーターの設定によっては、承認済みの商品にしかオファーを付けられない
• API: 商品は商品インポート（P41）、オファーはオファーインポート（OF01）と、別々のAPIで登録・更新する

買い手が見る商品ページは1つで、その下に各セラーのオファーが価格や配送条件の順で並ぶ。同じ商品を複数セラーが売る「1商品・N オファー」がマーケットプレイスの基本形になる。

商品とオファーを分けるのは、カタログの品質管理と価格競争を切り離すためである。商品情報はオペレーターが審査・統制し、重複や属性の欠落を防ぐ。一方で価格や在庫はセラーごとの裁量で、頻繁に変わる。ひとつのレコードにまとめると、あるセラーの価格変更が商品ページ全体の更新になり、他セラーの情報にも影響が及ぶ。

システム連携で効いてくるのは更新頻度の差である。商品情報はカタログ登録時に整えれば以後の変更は少ないが、在庫と価格は日に何度も動く。そのため連携基盤では商品の同期と、在庫・価格（オファー）の同期を別の処理として組み、失敗時の再送やレート制限の扱いも分ける設計が一般的になる。

もうひとつの論点は、オファーという概念を持たないシステムとの対応関係である。ShopifyのデータモデルにはProductとVariantはあるがオファーはない。Mirakl側の複数オファーをShopifyでどう表現するか（バリアント、メタフィールド、別商品）は、マーケットプレイス化するストアの設計上の決めどころになる。受注管理システム（OMS）側でも、マーケットプレイスの「オファー」を自社の「商品」と「在庫・価格」にどう対応させるかを最初に決める必要がある。

当社のConnector for Miraklは、商品同期、在庫同期、価格同期、注文同期を分離したアーキテクチャになっている。この分け方はMiraklの商品とオファーの2層構造に沿ったもので、更新頻度の高い在庫・価格を商品情報から独立して流せるようにしている。セラー側の受注管理システムでは、Miraklのマーケットプレイスを「もうひとつのモール」として扱い、自社の商品マスタをMiraklの商品に、在庫と価格をオファーに対応させる。商品インポートで受け付ける属性はマーケットプレイスごとに異なるため、商品属性のマッピングはオペレーター単位で設定できる設計を取っている。

Shopifyでは価格は商品オブジェクトの一部なので、最初にオファーの概念を知ったときは「なるほど」と感じた。同じ商品を複数のセラーが出品する構成を想定しており、その場合は価格もセラーごとに異なるからである。