2026年10月21日に公表されたPHPの脆弱性(CVE-2026-109618 および CVE-2026-109619)に関し、当社の全Shopifyアプリ(Japan Order CSV、Delete Me、Mockingbird、B2E 社販アプリ)への影響を確認いたしました。いずれのアプリもPHPを使用しておらず、本脆弱性の影響はございません。ご利用のマーチャント様において、アップデートや設定変更などの対応は不要です。

当社では、公表される脆弱性情報を継続的に監視しており、ご利用の皆様に影響が想定される場合には速やかにお知らせいたします。本件についてご不明な点がございましたら、各アプリのサポート窓口までお問い合わせください。

Miraklオペレーター / セラー(ミラクルオペレーター/セラー)

定義

Miraklで構築されたマーケットプレイスには、必ず1つのオペレーターと複数のセラーがいる。

  • オペレーター(Operator): マーケットプレイスの運営者。自社ECサイトやブランドを持ち、そこに他社の商品を並べる側。カテゴリ(タクソノミー)と必須属性を定義し、商品情報を審査し、手数料率を決め、購入者から代金を受け取ってセラーに精算する。購入者との顧客接点と、セラーの品質管理(KPI監視)も担う
  • セラー(Seller): マーケットプレイスに出品する販売者。在庫を持ち、オファー(価格・在庫)を登録し、注文を受けて出荷し、返品や問い合わせにオペレーターのルールの範囲で対応する。売上から手数料を差し引いた金額を受け取る
  • 管理画面とAPI: オペレーター用とセラー用のバックオフィスは別で、APIも「Operator API」と「Seller API」に分かれる。同じ注文でも、オペレーターは全体を、セラーは自分の分だけを見る
  • 1P と 3P: オペレーター自身が販売する商品を1P(ファーストパーティ)、セラーの商品を3P(サードパーティ)と呼ぶ。1つのカートに両方が入る構成が一般的

背景

自社ECとマーケットプレイスの違いは、この2者が分かれることに集約される。自社ECでは仕入れ・在庫・販売・出荷を1社で担うが、マーケットプレイスでは在庫と出荷はセラー側にあり、オペレーターの売上は商品代金ではなく手数料(テイクレート)になる。流通取引総額(GMV)と自社売上を分けて見る必要が生じるのはこのためである。

運用面では、1回の注文が複数セラーに分割されること、配送や返品の条件がセラーごとに異なること、決済はオペレーターが一括で受け取りセラーに精算することが、システムと業務の設計を左右する。Miraklはこれらを前提に、オペレーター側の審査・手数料・精算の仕組みと、セラー側の出品・受注・出荷の仕組みを分けて提供している。

日本では、オペレーターにあたる企業は小売やメーカーで、既存の自社ECを拡張してマーケットプレイスを立ち上げるケースが多い。セラーにあたる企業は、複数モールに出店している事業者が中心で、受注管理システム(OMS)を通じてモール運営をしている。セラーにとってマーケットプレイスへの出店は「もうひとつのモール」であり、既存の運用フローに載るかどうかが出店のハードルになる。オペレーターにとっては、セラーをどれだけ早く集められるかが立ち上げ後の最大の課題になる。

Flagshipでの関わり

当社はオペレーター側とセラー側の両方に関わっている。オペレーター側では、Miraklの導入・設定と、基幹システム(ERP)やShopifyとの連携構築を担う。セラー側では、ネクストエンジン・ロジレス・クロスモールといった受注管理システム向けにConnector for Miraklを提供し、既存の運用フローを変えずにMiraklのマーケットプレイスへ出品・受注・出荷できるようにしている。導入時のドキュメントもオペレーター向けガイドとセラー向けスタートアップガイドを分けて用意しており、セラー側の初期設定の負担を下げることが、オペレーターのセラー獲得スピードにつながると考えている。

関連リンク