この記事はAIで自動翻訳されており、誤りが含まれる場合があります。
※文章内のリンクは海外サイトのものとなります。あらかじめご了承ください。
成功しているエンタープライズマーケットプレイスには、ある共通点があります。それは規模ではなく、独自性です。長年にわたるセラーとの交渉の積み重ねで築いたコミッションルール。自社のカテゴリー構成に合わせて設計した返品ロジック。競合他社が思いつかないようなコンプライアンスチェック。これらは業務上の余分な手間ではなく、そのマーケットプレイスが他社に真似されにくい理由そのものです。
しかし、この独自性には常に代償がありました。プラットフォームの標準機能で対応できない要件が出てきた場合、これまでオペレーターには2つの選択肢しかありませんでした。社内のエンジニアリングチームを動かしてプラットフォームの外側で回避策やパッチワークを構築するか、あるいはベンダーのロードマップにリクエストを出すか。どちらも確実な手段ですが、いずれも「待ち行列」であり、その順番を決めるのはオペレーター自身ではなくベンダー側です。一方で、オペレーター側のエンジニアリング組織のあり方も変わってきました。およそ4分の3の企業 (opens in a new tab)が、セルフサービス型の開発を前提とした専任のプラットフォームチームを持つようになっています。設定変更しか許さないコマースプラットフォームは、こうしたチームに対し、自社の他のスタックではもう通用しないやり方での作業を強いることになります。
Mirakl Extensionsは、まさにこのジレンマを解消するために開発されました。ガバナンスが効いたアップグレード対応の拡張フレームワークであり、御社のエンジニアリングチームがバックオフィスメニュー、バックエンドのビジネスロジック、独自のUIコンポーネントといったカスタム機能を、Miraklの中でネイティブに、御社自身のスケジュールで構築できます。しかも、これまで享受してきたSaaSとしての保証を犠牲にすることはありません。
プラットフォームの外側で構築することの本当のコスト
プラットフォームがビジネス要件を吸収できないとき、その要件が消えてなくなるわけではありません。ただ場所を移すだけです。オペレーターはプラットフォームの周辺に、カスタム連携、ミドルウェア、外部スクリプト、スプレッドシートといった仕組みを積み重ねていきます。そして気づかないうちに、それらが業務を支える重要な基盤になっていきます。回避策はその場の問題を解決する一方で、翌日にはメンテナンスという新たな負担を生み出します。
この負担を抱えるオペレーターのエンジニアリングリソースは、いつの間にか2つに分断されます。一部はマーケットプレイス自体の前進に使われ、もう一部はその周りに築かれた足場のような仕組みの維持に費やされ、こちらは決して資産として積み上がっていきません。さらに深刻なのは、そのマーケットプレイスを独自たらしめているビジネスロジック——特定のセラーセグメント向けのコミッション計算方法、返金を認める条件、配送条件に応じた配送料の再計算方法など——が、プラットフォームの外側に置かれてしまうことです。そこでは監査もバージョン管理もできず、一つのまとまりとして統制することもできません。
プラットフォームのリリースがあるたびに、テストサイクルそのものになってしまいます。カスタムレイヤーは、そもそもアップグレードに耐えられるようには設計されていないからです。その脆弱性は、何かが壊れるまで見えてきません。
組織面でのコストも存在します。エンジニアリングチームが優秀であるほど、設定はできても拡張はできないプラットフォームの限界を強く感じ取ります。この能力こそ、御社の最大の資産の一つです。拡張できないプラットフォームは、それを摩擦の原因に変えてしまいます。
プラットフォームの拡張性とは何か——重要なのは「ガバナンス」という言葉
プラットフォームの拡張性とは、御社のチームがプラットフォーム自体に機能を追加できることを意味します。見た目、動作、アップグレードの仕方までネイティブ機能と同じように振る舞う新しい機能を、脇に取り付けるのではなく、プラットフォームが公開したインターフェースの上に構築するということです。
ただし、この価値を本当に支えているのは「拡張可能」という言葉ではありません。
「ガバナンスが効いている」という言葉です。
理由をご説明します。DORAの最近の調査 (opens in a new tab)によると、ソフトウェアや機能をより速くリリースすることは、必ずしも品質の向上を意味しません。リリース速度の向上は、不安定さや手直し作業の測定可能な増加と表裏一体でした。速度と脆弱性を分けるのは、その土台となるプラットフォームです。安全にスピードを高めるためのガードレール、契約、自動化されたチェックの存在が、この差を生み出します。
ガバナンスの効かない拡張性は、技術的負債を溜め込む速度を上げるだけです。それに対し、ガバナンスの効いた拡張性は、設計そのものから違います。
- 拡張機能はMiraklの内側で動作し、外側で動くことはありません。 サンドボックス化され監視された環境の中で、バージョン管理されたAPI上に構築されます。
- アップグレードにも自動的に対応し続けます。 今日書いた拡張機能は、次のプラットフォームリリースの後も引き続き動作します。これは約束された仕様です。
- インフラの管理はMiraklが担います。 セキュリティ、スケール、自動アップグレードはすべて維持されます。御社のチームは配管部分ではなく、ビジネスロジックに集中できます。
この点は正直にお伝えする必要があります。技術に精通した方であれば必ず質問されるからです。拡張機能は、プラットフォームの内部構造にアクセスしたり、コアの動作を変更したりすることはできません。この境界線があるからこそ、アップグレード保証が成立しています。これは明確な契約に基づいて範囲を定めた柔軟性であり、抜け道ではありません。他のスタックで「クリーンコア」への移行を経験したことがある方なら、この境界線が細かい注意書きではなく、むしろ価値そのものである理由をすでにご存知でしょう。
御社のチームがMiraklの中で構築できること
Mirakl Extensionsは、3つの領域を段階的にカバーするフレームワークです。
- Menu Extensions： セラー向けドキュメント、オンボーディング用のアカデミー、サポートポータルといったオペレーターツールを、Mirakl内の1つのハブにまとめられるカスタムバックオフィスメニューです。セラーが一つひとつ覚える必要のある複数のシステムに分散させる必要はありません。
- Backend Extensions： コミッション構造、注文ステータス管理、商品検証ワークフローなど、御社のマーケットプレイスを独自のものにしているルールのためのカスタムビジネスロジックを、プラットフォームの中で御社のチームが定義し、管理できます。
- UI Extensions： プラットフォームの操作体験を御社の業務にネイティブに合わせる、カスタムのインターフェースコンポーネントです。
その実際の違いは、スピードに表れます。
これまで5万〜20万米ドル規模のプロフェッショナルサービス契約を数ヶ月かけて行っていたようなカスタム要件が、御社のチームが数週間で実装できる作業に変わります。しかも優先順位を決めるのは御社自身です。
この点は、ロードマップ全体を見ても重要な意味を持ちます。
2025年のロードマップの30%以上は、個別のお客様からのリクエストに基づいたものでした。これはMiraklの開発が顧客中心である証ですが、すべてのお客様にとって最も効率的なやり方とは言えないことも認識しています。企業のあり方は一社一社異なります。Extensionsは、その違いを尊重しながら、御社のチームが自社ならではの要件を直接構築できる自律性を提供するために存在します。
フェーズ1が利用可能に：Menu Extensions
Menu Extensionsは、Miraklのバックオフィスメニュー、セラー向けバックオフィスメニュー、あるいはその両方に、御社独自のページやナビゲーション項目を直接追加できる新しい仕組みです。
現在、こうしたツールは別々のタブやシステムに存在しており、セラーが新しく覚えるツールが増えるたびに、離脱のリスクも高まります。Menu Extensionsを使えば、御社のチームがこれらをMiraklの中にネイティブに構築できます。たとえば次のようなものです。
- セルフサービス型のセラー向けサポートポータル
- ヘルプ・ドキュメントハブ
- 組み込み型の分析ダッシュボード
仕組みは意図的にシンプルにしてあります。JSON設定で拡張機能を定義し、対象のページやツールを指定して、表示を許可するロールを選ぶだけです。あとは御社のMiraklメニューにネイティブに表示されます。セキュアで、アップグレードにも安心して対応できます。
なぜこれが重要なのか。
- 時間とリソースを節約できます — 数ヶ月ではなく数日で構築できます。長期プロジェクトも、ロードマップの順番待ちも必要ありません。
- ネイティブでガバナンスも効いています — Miraklの中で動作し、すべてのアップグレードとの互換性を保ちます。
- Miraklだけの強みです — 御社のチームが本当にプラットフォームの内側で構築できる、唯一のマーケットプレイスプラットフォームです。
Backend Extensionsは今年後半に登場予定で、UI Extensionsが2027年にフレームワークを完成させます。
ベータプログラムの一環として、米国の大手小売業者様は、これまで完全に手作業だったメール対応のサポートプロセスを、Mirakl内にネイティブなセラー向けサポートポータルに置き換えました。このポータルはよくある質問に対してヘルプ記事を提案し、Miraklのセキュアなトークンコンテキストを使って各ケースを適切な担当者へ自動的に振り分けます。別途ログインの仕組みを作って維持する必要もありません。同社は現在、ベータ版でテストを行いながら、本番環境でのセラーへの展開を準備しています。
「設定する製品」から「その上に構築するプラットフォーム」へ
Mirakl Extensionsは、単なる新機能のリリースではありません。Miraklという存在そのものの、意図的な進化です。「設定する製品」から「その上に構築するプラットフォーム」へ。あらゆるニーズを事前にすべて想定しようとするのではなく、オペレーターの皆様に、自社のマーケットプレイスに固有のものを、完全な制御のもとで、妥協なく構築できる手段を提供します。
このパターンは実証済みです。最も長く生き残ってきたエンタープライズソフトウェアのエコシステムは、顧客に構築させることで成功を収めてきました。これまで欠けていたのは、セラー、コミッション、注文、カタログといったエンタープライズマーケットプレイス特有の複雑さに向けて設計され、なおかつSaaSとしての保証をそのまま維持できるモデルです。Extensionsはまさにそれを実現するものであり、Menu Extensionsはその最初の一歩です。
御社のチームにとっての問いは、もはや「プラットフォームでこれができるか」ではなく、「最初に何を構築するか」です。
Menu Extensionsは、Marketplace、Dropship、One creditorの各プラットフォームで既にご利用いただけます。拡張機能の作成方法については、Miraklのドキュメント（こちら (opens in a new tab)）をご覧ください。
よくある質問
Mirakl Extensionsは、ガバナンスが効いたアップグレード対応の拡張フレームワークであり、エンタープライズのマーケットプレイスおよびドロップシップのオペレーターが、Miraklプラットフォームの内部で直接カスタム機能を構築できるようにするものです。オペレーターのエンジニアリングチームは、カスタムのバックオフィスメニュー、バックエンドのビジネスロジック、独自のUIコンポーネントを作成でき、それらはネイティブ機能と同様に動作し、アップグレードにも対応します。このフレームワークは3つのフェーズで展開され、Menu Extensionsは現在利用可能で、Backend ExtensionsとUI Extensionsは今年後半に登場予定です。
プラットフォームの拡張性とは、顧客企業のエンジニアリングチームが、ベンダーが提供する機能を設定するだけでなく、SaaSプラットフォーム自体に新しい機能を追加できる能力を指します。拡張機能はプラットフォームが公開しバージョン管理されたAPI上に構築されるため、ネイティブに統合され、プラットフォームのアップグレードを経ても機能し続けます。エンタープライズのマーケットプレイスオペレーターにとって、拡張性とは、外部スクリプトやミドルウェア、スプレッドシートではなく、自社固有のルールやワークフローをプラットフォームの内部に持てるということを意味します。
スケーラビリティとは、セラー数、注文数、カタログデータといった増加するボリュームを、パフォーマンスを落とさずに処理できるプラットフォームの能力です。一方、拡張性とは、ベンダーがそもそも用意していなかった新しい機能を取り込めるプラットフォームの能力です。マーケットプレイスプラットフォームは高いスケーラビリティを持ちながらも、柔軟性に欠ける場合があります。拡張性があることで、オペレーターは自社固有のビジネスロジックにプラットフォームを適応させることができます。
はい。ただし、そのカスタマイズにガバナンスが効いていることが条件です。ガバナンスの効いていないカスタマイズ——フォークされたコード、後付けのミドルウェア、サポート対象外の回避策——は、基盤となるプラットフォームがアップグレードされた際に破綻します。これが、SaaSのカスタマイズにおいて柔軟性と安定性のどちらかを選ぶしかないとされてきた理由です。Mirakl Extensionsのようなガバナンスの効いた拡張フレームワークは、このトレードオフそのものを解消します。拡張機能はサンドボックス化され監視された環境の中で、バージョン管理されたAPI上で動作するため、セキュリティ、スケール、自動アップグレードは完全に維持されます。
アップグレード対応とは、今日構築した拡張機能が、将来のあらゆるプラットフォームリリースの後も、自動的に動作し続けることを意味します。拡張機能はプラットフォームの内部構造ではなくバージョン管理されたAPI上に構築されているため、Miraklのアップグレードによって拡張機能が壊れることはなく、オペレーターはリリースごとにカスタム機能を再テストしたり再構築したりする必要がありません。この境界線は意図的なものです。拡張機能はプラットフォームのコアの動作を変更できず、この制約こそがアップグレード保証を可能にしています。
Mirakl Extensionsを使えば、オペレーター自身のエンジニアリングチームが、プロフェッショナルサービスの契約やロードマップへのリクエストを必要とせず、自社のスケジュールでプラットフォーム内にカスタム機能を構築・展開・管理できます。これまで数ヶ月とかなりのコンサルティング費用を要していたカスタム要件が、社内チームが数週間で実装できる作業に変わり、優先順位もオペレーター自身が管理できます。
Mirakl Extensionsの最初のフェーズであるMenu Extensionsを使うと、オペレーターはMiraklのバックオフィスにカスタムメニューを追加できます。最も一般的な最初の活用方法は、セラー向けドキュメント、オンボーディング用のアカデミー、サポートポータル、コンプライアンス関連のリソースを、プラットフォーム内の1つのハブに統合することです。これにより、セラーは業務を行うために複数の外部システムを行き来する必要がなくなります。
