FundingPips の Shared CID / Device fingerprint BAN は、いま一番ザワついている話題です。Hola Prime 側でも近い話題が出ていて、「結局どこまでが噂で、どこからが技術なのか」が分かりにくくなっているんですよね。
ここでは、断定合戦はやめて、検知される面を分解して見ます。先に結論だけ言うと、怖いのは「VPS が別人のマシンになる」ことより、同じ VPS に別人の手元から入っていると読まれることです。RDP 常用なら一度運用を見直したほうがいい、という話です。
まず一次情報：何が公開されているか
FundingPips の公開ヘルプには、少なくとも次が明記されています。
- 購入時・サイトログイン時・運用時の IP 地域の一貫性 を重視
- 地域変化があれば証憑（渡航情報や請求情報等）を求める運用
- 複数デバイス利用は一定条件下で許容されるが、審査対象にはなる
ここまでは「会社が公開している運用」。 一方、Shared CID の判定ロジックそのもの（どの値を何個合わせるか）は公開されません。ここを全部知ろうとすると、当然ですが外からは見えないです。
「Device fingerprint」は 1 個の番号ではない
コミュニティでは「Device ID が一致した」で語られがちです。実務的には、単一キーというより 複数シグナルの組み合わせで見ていると考えるのが自然です。
| 層 | 代表シグナル | 事故りやすいポイント |
|---|---|---|
| ネットワーク層 | IP、ASN、地域、接続時刻パターン | 回線切替、旅行、DC IP 多用 |
| 端末 / OS 層 | ホスト情報、セッション特性、RDP 接続元デバイス | 手元 PC の切り替え、家族・チーム共有ログイン |
| MT5 層 | 端末インストール構成、データフォルダ系の一貫性 | インストール先変更、複製運用、雑な移行 |
ここを雑にすると「本人なのに別人っぽい」も「別人なのに同一群っぽい」も起きます。正直この手の切り分け、地味で面倒です。
MT5 側で見えるもの：instance_id の誤解
MT5 公式ヘルプにある通り、AppData/Roaming/MetaQuotes/Terminal/... 配下の instance_id は、インストールパス由来の識別子です。
これ自体は「端末の物理指紋」そのものではありません。
要するに、
instance_idは「この MT5 インストールの入れ物 ID」に近い- 端末再作成やパス変更で変わりうる
- だから、これ単体で本人性を証明する用途には弱い
ただし、審査側から見ると 一貫性チェックの材料にはなります。 いつも同じ運用のはずなのに、周辺シグナルが毎回大きく揺れると、レビュー対象になりやすいです。
なぜ RDP でこじれやすいのか（ここが本題）
よくある誤解は、「RDP するとトレードマシン自体が別人扱いになる」という読み方です。 現場でより刺さりやすいのは、逆方向です。
RDP は「接続元（手元）デバイス」の情報を、セッション側に載せやすい。
VPS 上の MT5 は同じ箱で動いていても、入ってくる側のノート PC / デスクトップが揺れると、ログや指紋側にはこう見えることがあります。
| 見えるもの（イメージ） | 読み方 |
|---|---|
| トレード実行マシン（VPS）は同一 | 「同じ口座・同じ環境」 |
| 接続元デバイス A / B / C が混在 | 「同じマシンに複数人が入っている」 |
| 接続元の切り替えが頻繁 | 合格代行・チーム運用・グループトレード疑い |
つまり Shared CID 文脈での怖いパターンは、
- 同一の Funded / Challenge マシン（VPS）がある
- そこに RDP で入る手元端末が複数ある
- 接続元デバイス情報がセッションに露出する
- 審査側は「複数人が同じトレード環境にアクセスしている」と解釈する
家族のノートから入った、会社 PC から入った、スマホの RDP クライアントから入った——本人でも、機械側には「接続元が別人」に見えうる。ここがイラッとするポイントです。
公開されているのは「CID 一致＝BAN」の詳細アルゴリズムではなく、コミュニティ側の技術仮説＋現場報告の束です。でも、RDP が接続元を露出するプロトコルであること自体は、この仮説の土台として十分に強い。
VNC が相対的にマシと言われる理由
VNC は画面共有・遠隔操作に近く、RDP ほど「Windows セッションに接続元クライアントの身元を載せる」感じが薄い、というのが実務側の感覚です。 トレード本体は固定の 1 台（VPS でも mini PC でも）に置き、手元からはその画面を覗くだけ、に寄せやすい。
なので回避策の骨はこれです。
- RDP をやめる（または極力使わない）
- 監視・操作は VNC に寄せる
- どうしても RDP が必要なら、接続元端末を 1 台に固定する（複数ノートからの入り直しをやめる）
ただし「VNC なら絶対安全」は言えません。IP 地域や口座間行動が荒れていたら普通に止まります。
実務チェックリスト（BAN 回避というより誤検知回避）
やることは派手じゃないです。
- トレード実行マシンを固定（本番口座の実行環境をむやみに変えない）
- 接続元も固定（RDP を使うなら、入る手元 PC を 1 台に限る）
- できれば RDP → VNC（接続元デバイス露出を薄くする）
- IP 地域を固定（購入・ログイン・運用で整合）
- 運用変更の証跡を残す（移行日、渡航、回線変更理由）
- 口座間の同時同型挙動を抑える（時間・サイズ・銘柄の完全同期を避ける）
審査チームと揉めたとき、最後に効くのは「説明できる運用履歴」です。
まとめ
Shared CID 問題は、陰謀論で片付けるより、接続設計で潰せる部分が多いです。
- FundingPips 側は IP 地域整合と審査運用を公開している
- Device fingerprint は単一番号というより複合シグナルと見るべき
- MT5 の
instance_idは物理端末 ID そのものではない - RDP の論点は「別マシン化」より、接続元デバイスの不一致＝複数人アクセス＝グループトレード疑い
- VNC は、その露出を薄くしつつ同一実行環境を保ちやすい
「RDP しないで VNC に寄せる」は、現場ではかなり筋のいい判断だと思います。 地味ですが、こういう基盤の整合が、出金前レビューの通りやすさを左右します。