6つのブランド、1つのプラットフォーム：東南アジアのブローカーがプロダクト—マーケットフィットに至る道

導入企業について

導入企業は、地域のトレーダーベースを対象とする確立された東南アジアの個人向けFXブローカーです。登録クライアントの大半が単一の国に集中しており、登録クライアントのうち約97％が同一の母国市場から来ています。一方で、地域内の他国には駐在員トレーダーが細く分布しています。獲得モデルはIB（Introducing Broker）主導が強く、約7〜10のクライアントのうち7はIBパートナーシップ経由で登録されています。また、単一のトップIBが、プラットフォーム上の完了した入金取引の約3分の1を牽引しています。

この導入企業がKenmoreに初めて関与したのは数年前で、その時点で既にFX事業を運営しており、立ち上げたい新しい市場向けブランドをどれだけ速く試したいかに合わせてついてきてくれるプラットフォームを探していました。一度きりの導入は望んでいませんでした。市場投入の仮説が進化するたびにバックオフィスの再プラットフォーム化を毎回行うことなく、トレーディングブランドを立ち上げ、改名し、休止し、再ローンチできる基盤が欲しかったのです。

ローンチ

この導入企業に対する初めてのTrader’s RoomおよびCRMの導入は、契約から本番稼働システムまで約3週間でした。提供内容には、MetaTraderに接続されたTrader’s Room、マルチティアのIBモジュール、支払い集約としてのNinjaCharge連携、営業とサポートの振り分けのためのカスタムワークフローを備えたCRM、マルチ言語対応、そしてライブチャットのレイヤーが含まれていました。

この事例の分析対象データを通じて最初に登場する地域ブランドは、分析期間の1ヶ月目の初めに本番稼働しました。2ヶ月目までに、月間入金量は、指数成長の測定に用いるベースラインの閾値を超えました。3ヶ月目には、その量はベースラインの約20倍にまで増えました。8ヶ月目には、68倍に到達し、運用上のピークとなりました。

リージョン・アーキテクチャ—なぜ今回の導入は異なっていたのか

KenmoreのCRMは、導入企業が成長戦略全体の中核レバーとして使っていた概念に基づいて構築されています。それが「Regions」です。Regionとは、同じバックオフィスの上に重ねられた、完全に隔離され、完全にブランド化されたプラットフォームの一画面（スライス）です。各Regionには次のものがあります：

• それぞれ独自のクライアント向けドメインとビジュアルブランド；
• それぞれ独自のトレーディング・プラットフォーム接続（別のMTサーバー、別の口座グループ）；
• それぞれ独自の通貨ルールと換算レート；
• それぞれ独自のPSPルーティング—Regionごとに異なる決済プロセッサーを有効化できます；
• それぞれ独自のフロントエンドデザイン、ヘッダー、フッター、メールテンプレート；
• それぞれ独自のワークフロー規則—営業、サポート、会計、そしてKYCルーティングがRegionごとにすべて設定可能；
• それぞれ独自の管理者権限—スタッフは1つのRegionにスコープすることも、グローバルに稼働させることもできます。

統一されるのは運用のコアです：管理者チームは1つ、レポーティング層は1つ、チケッティングシステムは1つ、IB階層は1つ、KYCパイプラインは1つ。導入企業は「新しいブランドを作りたい」と「初日から運用チームの生産性を維持したい」のどちらかを選ぶ必要がありませんでした。

このブローカーにとってそれは、ほとんどの企業がランディングページをテストするのと同じようにブランド・アイデンティティを試せるということを意味し、実際にそれを行いました。導入企業は、Kenmoreのプラットフォームを通じて、地域ごとに6つの異なるブランドを運用しています。このうち2つのブランドが、本事例のデータの対象です。立ち上げを支えた一次ブランドと、導入企業が約10ヶ月後に別のポジショニングを検証するために発注した後継ブランドです。

提供されたモジュール

Trader’s RoomおよびCRMのコア

導入企業は、ライブ／デモ口座の開設、KYC書類のアップロード、入金および出金リクエスト、ならびに個人情報と口座履歴のためのトレーダー自身によるセルフサービスを、扱えるTrader’s Roomを求めて当社に相談しました。そして、それらはCRMに接続され、入ってきたアクティビティを適切な担当スタッフへルーティングします。約3週間で、埋め込み型CRMを備えたNew Edition Trader’s Roomを提供しました。運用上のピーク時には、別のチケットツールなしで、システムが月間1,100件超の内部タスクを処理していました（登録承認、KYCレビュー、入金確認、出金承認、そしてIB口座の開設など）。

MetaTrader連携

導入企業のトレーダーはMTで取引します。この導入における各Regionは、独立して設定された自社のMT取引サーバーに対して動作します。導入企業が2つ目のRegionを追加したいと考えた際、2つのブランドがバックオフィスを共有していても、取引インフラは共有しないようにするため、別のMTサービス接続をプロビジョニングしました。口座タイプ、レバレッジ階層、グループ名の命名規則はいずれもRegionごとにスコープされています。

マルチティアIB管理

IBプログラムは導入企業の主要な獲得チャネルです。アクティブトレーダーのうち約7割が、IBまたはサブIBに起因するとされています。Kenmoreは初日から、既存のマルチティアIB階層を新しいプラットフォームへ移行しました。紹介URLの追跡、階層別のコミッションルール、利益分配のオプション、そしてTrader’s Room内の「My IBs / My Traders」アナリティクスビューを備えています。システムは、単一のIB系統が両方のRegionにまたがるように構成されており、導入企業はブランドごとにコミッション追跡を分断したくありませんでした。

NinjaChargeによる決済ソリューション

NinjaChargeは導入企業の決済集約（PSPの上に乗るルーティングレイヤーであり、PSPそのものではありません）です。導入企業はローカル通貨のレール上で、NinjaCharge配下に30以上のPSPエンドポイントを統合しました。主に母国市場向けにはVNDを使用し、さらに地域内の他の顧客向けとしてMYR、THB、IDR、BTCの設定も行いました。PSPの可視性はRegionごとに制御されます。2つ目のRegionは、1つ目のRegionとは異なる独自にキュレーションしたPSPセットで立ち上がりました。30以上の統合エンドポイントのうち、だいたい2/3はその時点でTrader’s Room上に公開されています。残りは予備として保持しています。

入金および出金の管理

入金はNinjaChargeを通過し、自動のコールバック処理が行われます。トレーダーはTrader’s Roomでリアルタイムのステータスを確認できます。出金はCRM上で、タスク駆動の手動承認ワークフローを通して処理されます。導入企業が要望したカスタム検証ルール（残高チェック、通貨換算ガード、PSPごとの受取人名の確認）も組み込まれています。入金および出金の各イベントはCRMタスクを生成し、適切なオペレーターチームへルーティングされ、トレーダーの口座履歴へ反映されます。

マルチ言語対応

CRMは6つの対応言語で構成されており、Trader’s Roomおよびメールテンプレートの両方で、言語ごとに文言を維持しています。ジオベースの言語検出により、トレーダー向けサイトは初回訪問時に適切な言語へ切り替わります。

ボーナス／クレジット・システム

導入企業は、IBコミッションのフローの一部およびプロモーションキャンペーンのために、ボーナスとクレジットのオペレーションを使用しています。プラットフォームは、入金と同じタスクおよび承認パイプラインを通じてルーティングされる残高調整をサポートしています。

Webデザイン

各Regionにはそれぞれ独自のブランド用グラフィック—ロゴ、カラーパレット、ヘッダー、フッター、フォント、カスタムテーマCSS—が備わっています。このデータセットの2つのRegionは、見た目のアイデンティティが明確に異なります。あるトレーダーがどちらかのRegionに着地しても、それが同じ基盤のCRM上にあることを知る手がかりはありません。

カスタム開発

関与期間を通じて、標準モジュールの納品と並行して継続的なカスタム開発スレッドが実行されました。クライアントには、標準製品ではカバーできない具体的な要件があり、Kenmoreは数週間ではなく、通常「数日」のペースで不具合修正や機能強化を取りまとめて対応しました。開発ログからの例：

• VNDの固定レート通貨換算。 クライアントは、ライブ市場レートではなく、クライアントが管理する固定のVND/USDレートで入金・出金を決済してほしいと要望し、そのレートを関与期間中に複数回見直しました。最初の月に初期の固定レート・ハンドラを納品し、その後は必要に応じてレート更新の変更を出荷しました。
• PSP固有の受取人名の取り扱い。 特定のローカルPSPでは、受取人フィールドの形式がトレーダー表示名とは異なる必要がありました。出金フローに対して、PSPごとの受取人名の上書きを作成しました。
• 出金残高の検証。 クライアントは、オペレーターのキューに到達する前に、残高超過のリクエストを検知するため、手動出金に対する事前承認のバリデーションをより厳格にしてほしいと依頼しました。CRMの出金ワークフローに対するカスタムバリデータとして提供しました。
• Slack通知のWebhook。 入金・出金・登録のリアルタイムイベントは、クライアントの社内Slackにルーティングされます。Regionごとに別々のWebhookを用意し、2つ目のRegionの運用チームが専用のチャンネルを持てるようにしました。
• 電話番号ルール。 クライアントは電話番号のバリデーションを何度か反復しました。まず電話番号の一意性を固定し、その後、IBプログラムで緩和が必要になったときに一意制約を削除し、さらにRegionの1つについて6桁の最小値を設定しました。
• アーカイブトレーダー管理。 アーカイブ解除およびアーカイブ済みのトレーダープロフィールを確認するための専用管理ページを用意し、アカウントおよびKYC履歴も含めてメインのクライアント・ロスターから分離しました。
• 手動入金・出金のメール本文。 手動入金および出金ステータス変更に応じてトリガーされるカスタムのメールテンプレートを作成しました。口座番号、金額、通貨は動的に反映されます。
• Regionごとの出金ワークフロー。 2つ目のRegionが立ち上がると、1つ目のRegionとは異なる承認フローが必要になりました。異なるオペレーター、異なるルーティングルール、異なる通知チャネルです。これをRegionを意識したワークフローエンジンに組み込みました。

カスタム開発の進め方（cadence）が、クライアントが複数年にわたり、複数のブランド展開でもプラットフォームを使い続けている理由の一部です。彼らのGo-to-marketが進化しても、プラットフォームは四半期ではなく数日で適応します。

第2リージョンのロールアウト

分析期間の第10か月ごろ—最初のRegionがピークに近い入金量をまだ投稿していた時期に、クライアントは第2リージョンを発注しました。要件はシンプルでした。別ブランド、別ドメイン、別MTサーバー、別PSPセットですが、同じチームが同じCRMで管理すること。6週間希望でしたが、6週間で実現しました。内訳：

• 第1週。 調査、ブランドのグラフィック受領、MTサーバーの認証情報、PSPルーティング要件。
• 第2〜4週。 Region設定—ドメインのプロビジョニング、Region固有のトランザクショナルメール向けのMailgun設定、MTサービス接続、ヘッダー/フッター/テーマの適用、新しいMTサーバー上でのアカウントタイプ設定、新しいRegion向けのマルチティアIBモジュール有効化。
• 第5週。 QA—エンドツーエンドの登録、KYC、入金、出金、IB紹介の各フローを、それぞれ2つのRegionに対して個別にテストしました。
• 第6週。 Go-liveおよびトレーナーへの引き継ぎ。

第12か月の開始時点で、第2リージョンは最初のトレーダーの登録を行っていました。第14か月までに、月次の新規登録数で第1リージョンと同水準に到達しました。第18か月までに、第2リージョンは第1よりも多い入金ボリュームを処理していました。第20か月までに、第1リージョンは停止され、第2リージョンが新規ビジネスの100%（登録、入金、口座）を担う状態になりました。移行はプラットフォームの切替なし、データ移行なし、オペレーターの再トレーニングなしで行いました。同じCRM、同じ管理チームで、ただ別のRegionをオンにしただけです。

これは、Regionsアーキテクチャが実現できることの“教科書的”な事例です。クライアントのブランド構想は進化しましたが、運用側は追随する必要がありませんでした。

データが示すこと

基準月に対する入金成長

分析期間の第2か月（非自明な入金アクティビティがあった最初の月）を、インデックス基準として1×に設定して使用します：

期間	入金ボリューム指数	注記
第1か月	0.04×	ソフトローンチ
第2か月	1.00×	基準
第3か月	19.67×	最初のIBコホートが稼働開始
第4か月	31.09×
第5か月	32.51×
第6か月	33.63×
8か月	68.36×	運用上のピーク（最初のリージョン）
10か月	33.39×	入金件数によるピーク（1か月で227件）
11か月	13.30×	最初のリージョンが冷え、2つ目のリージョンを稼働開始
14か月	6.86×	2つ目のリージョン稼働中
17か月	8.38×	2つ目のリージョンが最初を上回る
18か月	24.33×	2つ目のリージョンが引き継ぐ
20か月	42.90×	2つ目のリージョンは自社のピーク。最初のリージョンは縮小へ

基盤は何も変えずに、2つの異なるブランドで2つの異なる成長波を取り込んだ。

獲得チャネルの構成

• 約活動中のトレーダーの7人に1人 はIBによって占められる。IBプログラムは主要な獲得チャネルである。
• 最高のIBは、入金件数において最大の単独貢献をしている—およそ入金完了取引の3件に1件 は、そのIBのダウンラインにたどり着く。
• 活動中のトレーダーベース全体におけるメール確認率はわずかに下回る89%。
• KYC承認率はおよそ登録トレーダー全体の3分の1 であり、多くのトレーダーが登録する一方で、オンボーディングの最終完了まで進むのは意欲の高い層に限られる、深いファネル構造を示している。
• 登録トレーダーのうち約5人に1人 は少なくとも1回の入金を完了する。実際に入金した人の中では、平均が1入金者あたり6回を超える—これは、ワンアンドダンのカジノ風フローよりも、アクティブなリテール・トレーダーのベースにより典型的な、高いリピート入金の頻度だ。

地域別のトレーダー行動

2つのリージョンは、ファネルの特性が明確に異なることが示される。

指標	最初のリージョン	2つ目のリージョン
IB帰属の割合	70.5%	61.0%
入金コンバージョン（登録→入金）	17.5%	31.4%
平均入金回数（入金者あたり）	6.4	5.5

2つ目のリージョンは、登録トレーダーを入金者へ変える率が最初のリージョンのほぼ2倍である。同じ基盤のCRM、同じ運用チーム、同じPSPレイヤー—しかしブランドが異なり、獲得チャネル構成が異なり、トレーダー行動も異なる。これは、クライアントのブランド反復（イテレーション）仮説が機能していたことを、読み取れるシグナルである。

入金に対する出金比率

分析対象期間全体で、合計の出金依頼は、完了した入金に対して約1.34:1のUSD換算比となっています。なお、入金・出金はいずれも異なる通貨建てで、また異なる業務フローで処理されます。入金はPSPアグリゲータを通じて自動的に流れ、出金は手動の承認キューを通るため、この比率は「当該期間において、プラットフォームがバランスの取れた双方向の資金フローを維持し、トレーダーへの支払いは入金に対してわずかに上回るペースで行われた」と解釈するのが最適です。これはIB主導のリテール・フォレックスブックにとって健全な維持状況の示唆です。

ピーク時の業務処理能力

第1年の終盤における業務ピーク時、CRMは月あたり1,100件超の社内タスクを処理していました——登録承認、KYCレビュー、入金確認、出金承認、IB口座の開設、サポートチケット——すべてを1つのワークフローエンジンにルーティングしていました。この同一エンジンは、移行後の地域ではより小さく、安定したボリュームの処理にも引き続き対応しています。

本分析で何が証明されるか

この関与は、KenmoreのRegionsアーキテクチャが何のためにあるのかを、最も明確に示したものです。話は「CRMをリリースした」ということではありません。ほとんどのCRMベンダーはCRMを出せます。ポイントは次のとおりです。

ローンチまでのスピード。 契約からおよそ3週間でクライアントの最初のRegionが稼働開始しました。次のRegion（別のMTサーバ上で、別のPSPセットを用いる完全に別ブランド）は、キックオフからQA完了まで約6週間で稼働開始しました。

再プラットフォームなしでのブランド反復。 クライアントのGo-to-marketの仮説が進化した際、移行（マイグレーション）はしませんでした。Regionを追加し、立ち上げ、IBやトレーダーが移っていくのに合わせて、先行するRegionが自然に縮小していくようにしたのです。データ移行なし、オペレーターの再トレーニングなし、ダウンタイムなし。

複数ブランドをまたぐ1つの運用チーム。 同じCRM、同じ管理担当者、同じワークフロー、同じKYCパイプラインで、2つのRegionを同時に運用していました——そして、より広い関係の中でも、合計で6つが提供されてきました。

継続的なカスタム開発のリズム。 プラットフォームの標準製品は、最初から必ずしも完璧にフィットする必要はありません。カスタムバリデータ、リージョン単位のワークフロー、固定通貨レートのハンドラ、PSP固有の受取人（payee）ロジック、そして小さな改善が連なる長いテールまで、これらは数日単位のリズムで提供されてきました。クライアントは何年にもわたって、カスタム価値を積み増しています。

負荷下での業務スケーリング。 プラットフォームは、ある1つのRegionにおいて月次入金ボリュームが68倍に跳ね上がったのを吸収し、その後別のRegionではほぼピーク時の上昇を同様に吸収しました——同時に、共有インフラ上で行い、その間にアーキテクチャの作り直しは一切ありませんでした。

ここまでくると、フォレックスブローカーがCRMを固定の導入物としてではなく、ブランド反復のプラットフォームとして捉えるようになった姿が見えてきます。

主要KPI（ひと目で）

指標	値
運用稼働までのリードタイム（最初のRegion）	約3週間
2つ目のRegionの稼働までのリードタイム	約6週間
ピーク時の月次入金ボリューム vs ベースライン	68倍
2つ目のRegionのピーク vs ベースライン	43倍
稼働中の地域ブランドは単一のCRM上で運用	6+（より広い関係の中で）
NinjaCharge経由で統合されたDistinct PSPエンドポイント	30+
対応言語	6
MT取引サーバー接続	2（Regionごとに1つ）
IB紐づけの顧客シェア	約70%
メール確認率	約89%
KYC承認率	約33%
登録→入金のコンバージョン	約19%（全体、2つ目のRegionでは約31%）
入金者あたりの平均完了入金件数	6+
出金に対する入金のUSD換算比率	約1.34:1
移行期間中に同一CRM上で稼働する併存Region数	2
Region移行：データ移行ゼロでのブランド切替	✓

---