2026年9月6日時点・Fundora × cTrader Cloud
- FundoraのcBotで日次損失5%を守るには？Cloud再起動後のEquity復元まで設計する
- Fundoraの日次最大損失5%は「リセット時のEquity」が基準
- cTrader CloudではJSONやLocalStorageを「永久保存」と考えない
- 解決策｜リセット時点のEquityをHistory・Positions・過去価格から復元する
- 過去価格はローソク足よりTickを優先したい
- 実装で一番ハマりやすいのが「部分決済」とPositionId
- 複数cBotでも口座全体のPositionsとHistoryは確認できる
- ただし複数cBotには「同時発注」という別の危険がある
- 私なら「Per-Bot Risk Budget ＋ Account Global Guard」にする
- Single・Twin・QuadをcBot名で判定するよりRiskShareを直接設定する
- 起動直後は売買させず、Recovery完了後にEAを有効化する
- 複数戦略なら「1つのMulti-Symbol cBot」にまとめる方法もある
- Fundora向けcBot Risk Managerを要件定義するとこうなる
- 重要指標や急変相場ほどEquity基準が重要になる
- Fundoraは自作cBotを作れる開発者と相性を考えやすい
- Fintokei・FTMO・Funded7とも比較してから選びたい方へ
- まとめ｜cTrader Cloudでは「保存するRisk Manager」より「復元できるRisk Manager」
- プロップファーム向けEA・cBotを自分で設計するのが難しい方へ
FundoraのcBotで日次損失5%を守るには？Cloud再起動後のEquity復元まで設計する
FundoraでcBotを自動売買させるとき、 単純に「損失が5%になったら止める」というコードを書くだけでは十分ではありません。
本当に難しいのは、 Fundoraの日次損失基準となるリセット時点のEquityを、cTrader Cloudが再起動したあとも正しく把握できるか という部分です。
Fundoraでは、1日の最大損失率5%について、 夏時間は日本時間6:00、冬時間は日本時間7:00時点の 有効証拠金、つまりEquityを基準として再計算します。
ポジションを持ったままリセット時刻を跨いだ場合は、 Balanceだけを記録しても基準値を再現できません。
さらにcTrader Cloudでは、 cBot内部でJSONやLocalStorageへ保存したデータを PC上のファイルのような永続データとして考えることもできません。
私ならFundora向けcBotでは、 「日次Equityを保存しておくRisk Manager」ではなく、 「保存データがなくても口座履歴から日次Equityを復元できるRisk Manager」 を作ります。
具体的には、cTraderの History、Positions、PositionId、過去価格を利用して リセット時点の口座状態を再構築します。
さらに複数cBotを動かす場合は、 各cBotへ個別のRisk Budgetを与えたうえで、 口座全体のAccount.Equityを監視する Global Guardを重ねる設計が現実的です。
履歴と過去価格から再構築したEquityは、 Fundora側が内部で記録した値と1円単位まで完全一致するとは限りません。
Bid・Ask、スプレッド、Swap、Commission、部分決済、 約定時刻などで誤差が発生する可能性があります。 そのため実際のRisk Managerでは、 公式5%より手前に内部停止ラインを置く設計を私は重視します。
MT4・MT5のEAやインジケーター、 cTrader・cBot関連システムなどを開発し、 これまで200個以上を開発・制作・検証してきました。
プロップファーム向け自動売買では、 エントリーロジック以上に 「失格条件をどうコードで再現するか」が難しくなることがあります。
今回はその中でも、 Fundora × cTrader Cloudだからこそ出てくる 日次損失管理の問題を開発者目線で掘り下げます。
まずFundora側の判定方法を理解する
Fundoraの日次最大損失5%は「リセット時のEquity」が基準
Balanceだけを監視するRisk Managerでは足りない
Fundoraの利用規約では、 日次最大損失率の判定について、 夏時間は日本時間6:00、冬時間は7:00時点の 有効証拠金残高、つまり含み損益を含むEquity を基準に計算すると定められています。
ここが通常口座用の単純なDaily Loss Managerと違うところです。
例えばリセット時刻のBalanceが2,000万円だったとしても、 その瞬間に100万円の含み益を持っていればEquityは2,100万円になります。
反対に50万円の含み損があれば、 Equityは1,950万円です。
日次最大損失5%を単純化して考えると、 2,100万円 × 5% ＝ 105万円です。
その日のRisk Managerでは、 Fundora側の基準を再現するために 「朝のBalance」ではなく「朝のEquity」 を把握する必要があります。
これ、ポジションを持たずに毎日リセット時刻を迎えるのであれば簡単なんですよね。
問題は、 cBotがポジションを持ったまま朝6時・7時を跨いだ場合です。
しかもCloudインスタンスを途中で止めたり、 再起動したりした場合には、 「その朝のEquityはいくらだったのか」をあとから復元する必要があります。
cTrader CloudではJSONやLocalStorageを「永久保存」と考えない
MT4・MT5をVPS上で動かす場合、 私なら日次リセット時刻になった瞬間のEquityや日付を CSVやJSONへ保存する方法をよく考えます。
VPS上のファイルが残っていれば、 MT5を再起動したあとも読み直せるからです。
ところがcTrader Cloudでは事情が変わります。
cTrader公式ドキュメントでは、 Cloudインスタンスが停止または削除された場合、 割り当てられていたCloudリソースが解放され、 cBotが作成したファイルやLocalStorageのデータも インスタンス再起動時に失われると説明されています。
ファイル永続化を使いやすい
- CSV / JSON
- 残しやすい
- 再起動後
- 読み込みやすい
- 共有ファイル
- 設計しやすい
復元できる設計を優先
- ファイル作成
- 可能
- Cloud再起動
- 永続性に注意
- 推奨
- Historyから復元
JSONへResetEquityを保存すること自体は無駄ではありません。 正常稼働中なら毎回履歴を再計算するより高速だからです。
ただし、 JSONが消えたら日次リスク管理そのものが動かなくなる構造にはしません。
ファイルが存在すれば読む。存在しなければ口座履歴から再構築する。 私はこの考え方にします。
Cloudでは公式サイトからルールを自動取得する設計にも頼りにくい
cTrader CloudではHTTPリクエストにも制限があります。
そのため、 cBotを起動するたびにFundora公式サイトへHTTPアクセスして 「今日のResetHourは何時か」 と自動取得するような仕組みへ安易に依存するのもおすすめしません。
Fundoraのリセット時刻はルール変更の可能性もありますから、 Risk Manager側に ResetHourをパラメーターとして持たせ、 変更しやすくしておく方が保守しやすいです。
解決策｜リセット時点のEquityをHistory・Positions・過去価格から復元する
ではCloudを再起動してResetEquityの保存値が消えていたら、 どうすればいいのか。
私なら、 取引口座そのものに残っている情報を正解データとして利用します。
cTrader Algoでは、 Historyからその口座の過去取引を取得でき、 Positionsから現在その口座で開いているポジションを取得できます。
つまり、 Cloud内部のファイルがなくなっていても、 取引サーバー側に残っている履歴まで消えるわけではありません。
復元ResetEquity ＝ 復元ResetBalance ＋ ResetTimeに存在していた全ポジションのFloating P/L
ここで重要なのは、 「現在保有しているポジション」ではなく 「ResetTimeの瞬間に存在していたポジション」 を復元することです。
10時現在のPositionsだけを見ても朝6時の状態は分からない
例えば朝6:00にUSDJPYのBUYを持っていたとします。
そのBUYを8:00に決済し、 10:00に新しいUSDJPY SELLへ入りました。
10:00現在のPositionsを見るとSELLしかありません。
しかし日次損失基準を決めた6:00時点に存在していたのはBUYです。
つまり、 現在のPositionsだけを調べるRisk Managerでは 朝6:00のEquityを復元できません。
同じUSDJPYだから同じポジションと判断するのではなく、 PositionId、EntryTime、ClosingTimeを利用します。
EntryTime ≦ ResetTime ＜ ClosingTime となるPositionがあれば、 そのPositionはリセット時点に存在していたと判断できます。
すでに決済されたPositionについてはHistoryから探し、 現在も保有しているPositionについてはPositionsから確認する。
そして各銘柄についてResetTime付近の過去価格を取得して、 その瞬間の含み損益を再計算します。
過去価格はローソク足よりTickを優先したい
リセット時点のFloating P/Lを復元するとき、 どの価格を使うかも重要です。
1分足のCloseだけで計算する方法は簡単ですが、 朝のスプレッドが広がっていた場合などには 実際のEquityとの差が大きくなる可能性があります。
可能であれば、 ResetTime直前または直近のTickデータを優先して利用した方が 再現性を高めやすくなります。
HistoryとTickを使えばResetEquityへかなり近づけられる可能性があります。
しかしFundora側の内部計算値と完全一致することを保証する仕組みではありません。
Risk Managerは公式判定を置き換えるものではなく、 公式ラインへ到達する前に自動売買を止めるための安全装置 として考えた方がいいです。
実装で一番ハマりやすいのが「部分決済」とPositionId
Equity復元ロジックを作るとき、 実際にコードを書き始めると難しくなるのが部分決済です。
例えば朝6:00時点で1lot持っていたPositionを、 8:00に0.5lotだけ決済したとします。
10:00現在のPositionsを確認すると、 残っているのは0.5lotです。
しかし6:00時点では1lot持っていました。
現在Volumeだけを使って過去Equityを計算すると、 朝6:00の含み損益を半分しか再現できないことになります。
cTraderのHistoryにはPositionIdがあり、 同じPositionに関連するHistoricalTradeを取得できます。
そのため部分決済がある場合は、 現在残っているVolumeと、 ResetTime以降に部分決済されたVolumeをPositionId単位で集計して、 ResetTime時点の保有数量を復元する必要があります。
これはかなり細かい話ですが、 プロップファーム用Risk Managerではこういう部分が大事なんですよね。
コードがエラーなくコンパイルできることと、 Fundora側と同じ意味の数字を管理できることは別問題です。
複数cBotでも口座全体のPositionsとHistoryは確認できる
FundoraではcTrader Cloudを利用して、 複数cBotを動かす運用も考えられます。
例えばGold用、USDJPY用、EURUSD用に 別々のcBotをCloudへ起動するケースです。
Cloudインスタンスごとのファイル領域は別々なので、 GoldBotが作ったJSONをUSDJPYBotへ共有する、 といった仕組みには向きません。
しかしcTrader Algo APIの PositionsとHistoryは口座単位の情報として取得できます。
つまりUSDJPYBotであっても、 同じ取引口座でGoldBotが保有しているPositionを Account全体のリスク計算へ含めることができます。
これはcTrader CloudでRisk Managerを作るうえで大きなメリットです。
個々のcBotが別インスタンスでも、 現在のAccount.Equity、口座全体のPositions、Historyを利用すれば、 他のcBotが作ったリスクまで考慮できます。
FundoraとFintokeiでcTrader Cloudの同時稼働数を実際に検証した結果については、 cTrader CloudでcBotは何個動かせる？FundoraとFintokeiを実機比較した記事 で詳しくまとめています。
ただし複数cBotには「同時発注」という別の危険がある
口座全体のPositionsを見られるからといって、 複数cBotへそれぞれ5%まで使わせてよいわけではありません。
むしろ危ないのが、 複数cBotがほぼ同時に新規エントリー条件を満たした場合です。
例えばGoldBotとUSDJPYBotが同じ瞬間に 「まだ日次損失まで4%余裕がある」と判定したとします。
両方が同時に注文を出せば、 お互いの新規ポジションがAccount.Positionsへ反映される前に リスク判定を通過してしまう可能性があります。
これは単純なAccount.Equity監視だけでは完全には防ぎにくい部分です。
Account.EquityによるGlobal Stopは最後の防波堤として重要です。
しかし新規発注前には、 各cBot自身が利用できるRisk Budgetも制限しておいた方が、 同時発注時のオーバーシュートを抑えやすくなります。
私なら「Per-Bot Risk Budget ＋ Account Global Guard」にする
複数cBotをCloudで運用する場合、 私ならリスクを二段階で管理します。
一段目が各cBotのRisk Budget。
二段目が口座全体のGlobal Guardです。
ここでいう100%は口座資金の100%ではありません。
Risk Manager内部で使用を許可したDaily Risk Budgetの100% という意味です。
Fundora公式の日次最大損失は5%ですが、 Risk Manager側では安全余裕を取り、 例えば4%を内部上限にしたとします。
4つのcBotへ均等に25%ずつ割り当てれば、 1つのcBotへ許可する日次Risk Budgetは 口座Equityのおおむね1%相当になります。
さらにAccount全体が内部4%ラインへ近づけば、 各cBotに個別余裕が残っていても すべての新規エントリーを停止します。
「自分のcBotが使いすぎない」と 「口座全体が使いすぎない」は別の問題です。
私は両方をチェックし、 どちらか一方でも危険なら新規取引を止める構造にします。
Single・Twin・QuadをcBot名で判定するよりRiskShareを直接設定する
複数cBotのRisk Budgetを設定するとき、 Bot名へSingle、Twin、Triple、Quadなどを入れて、 名前から台数を自動判定する方法も考えられます。
ただ私は、 この方法へRisk Managerの根幹を依存させるのは避けます。
Quadという名前なのに3台しか起動していない。
Bot名を変更したらRisk Budgetまで変わった。
こうした設定事故が起こり得るからです。
自動だが設定ミスへ弱い
- Twin
- 50%と推定
- Quad
- 25%と推定
- 名前変更
- 影響あり
明示的に設定
- Single
- 100%
- Twin
- 50%ずつ
- 自由配分
- 可能
例えばGoldは値動きが大きいから20%、 USDJPYを40%、 EURUSDを40%とするなど、 戦略ごとに配分を変えることもできます。
将来的な拡張を考えても、 RiskSharePercentをcBotパラメーターとして明示的に持たせる 方が分かりやすいと思います。
起動直後は売買させず、Recovery完了後にEAを有効化する
こうしたRisk Managerを実装するとき、 私は起動順序も重要だと考えています。
Cloudインスタンスを再起動した直後に、 いきなりエントリーロジックを有効にするのは危険です。
OnStart → 現在の日次ResetTimeを決定 → Cacheを確認 → CacheがなければHistory Recovery → ResetBalanceを復元 → ResetTimeのPositionsを復元 → 過去価格からFloating P/Lを再計算 → ResetEquityを確定 → Daily Stop Lineを計算 → 現在のAccount.Equityを確認 → 安全が確認できたら売買ロジックを有効化
ここで一番大切なのは、 Recoveryに失敗したら取引しないことです。
履歴が取得できない。
ResetTime付近の価格を取得できない。
部分決済を正しく復元できない。
こうした状態で、 「よく分からないけれど多分大丈夫」とEAを動かすのは Risk Managerとして逆です。
プロップファーム用システムでは、 情報不足時のデフォルトを 「取引続行」ではなく「新規発注停止」にします。
復元が終わり、 リスク状態を確認できてから稼働を再開する方が安全です。
複数戦略なら「1つのMulti-Symbol cBot」にまとめる方法もある
ここまで複数cBotを別インスタンスで動かす方法を説明しましたが、 Risk Managerを最もシンプルにしたいのであれば 別の方法もあります。
複数通貨・複数ロジックを1つのcBotへまとめる方法です。
一つのcBotの中で USDJPY、EURUSD、XAUUSDなどを監視すれば、 Risk Budgetを一つのプロセス内で一元管理できます。
別Cloudインスタンス同士の同時発注競合も減らしやすくなります。
保守を分離しやすい
- ロジック分離
- しやすい
- 個別停止
- しやすい
- リスク同期
- 工夫が必要
口座リスクを集約しやすい
- Risk Manager
- 一元化
- 同時発注管理
- しやすい
- コード規模
- 大きくなりやすい
どちらが正解という話ではありません。
保守性を優先するなら複数cBot、 リスク管理の一貫性を優先するならMulti-Symbol化というように、 システム全体で判断する必要があります。
Fundora向けcBot Risk Managerを要件定義するとこうなる
ここまでを実際の開発要件へ落とすなら、 私は次の機能を一つのRisk Managerとしてまとめます。
5%になった瞬間を正確に当てることではありません。
Fundora側の失格ラインへ到達する前に、 cBotを安全側へ止めることが本来の目的です。
重要指標や急変相場ほどEquity基準が重要になる
普段の値動きだけ見ていると、 ResetEquityの多少の違いは大きな問題に感じないかもしれません。
しかしFOMC、米国CPI、雇用統計、 要人発言、為替介入などで大きく相場が動けば話は変わります。
例えばリセット時点で大きな含み益を持っていたPositionが、 その後急落して利益を吐き出した場合、 Balanceだけを見ているRisk Managerでは Fundora側の日次基準とのズレが大きくなります。
逆に大きな含み損のまま日を跨いだ場合も同じです。
私はEA・cBotを「選手」、 利用者を「監督」と考えています。
選手であるcBotへ売買を任せても、 監督である人間は重要経済指標、 異常ポジション、日次損失、 プロップファームのルール変更を確認する必要があります。
Fundoraは自作cBotを作れる開発者と相性を考えやすい
FundoraではEA・cBotなどの自動売買を利用できますが、 公式FAQでは原則として 自分自身で作成したEA・cBot・ツールを対象としています。
場合によっては、 本人が作成したシステムであることを確認するため コード提出を求められる可能性もあります。
そのためFundoraは、 市販EAをそのまま動かす使い方より、 C#でcBotやRisk Managerそのものを自分の運用ルールへ合わせて作り込む スタイルと相性を考えやすいプロップファームです。
コードを書くだけなら生成AIでもかなり楽になりました。
でも今回のResetEquityのように、 「Fundoraのルールをどういう状態として定義するか」 「部分決済をどう再現するか」 「復元できないときにどう止めるか」 という部分は、まだ設計者側で考える必要があります。
※上記Fundoraリンクにはアフィリエイトリンクが含まれます。日次損失、リセット時刻、EA・cBot利用条件等は変更される可能性があるため、利用前に必ずFundora公式サイトで最新情報をご確認ください。
Fintokei・FTMO・Funded7とも比較してから選びたい方へ
FundoraではcTraderと自作cBotを中心に考えやすい一方、 MT4・MT5のEAを利用したい場合や、 市販EAをカスタマイズして使いたい場合には 他のプロップファームの方が合うケースもあります。
特に自動売買では、 対応プラットフォームだけでなく、 日次損失、最大損失、 EA・cBot利用条件、 秒スキャ、 一貫性ルールまで含めて比較することが重要です。
【2026年版】人気プロップファーム5社をEA・cBot目線で比較するまとめ｜cTrader Cloudでは「保存するRisk Manager」より「復元できるRisk Manager」
Fundoraの日次最大損失5%をcBot側で管理するとき、 難しいのは5%という数字を掛け算することではありません。
本当に重要なのは、 Fundoraが日次基準としているリセット時のEquityを、 Cloud再起動後にも再構築できることです。
cTrader Cloudでは、 JSONやLocalStorageを永続データベースのように扱うことはできません。
だから私は、 保存データはCacheとして使い、 消失した場合にはHistory、Positions、PositionId、 過去価格からResetEquityを再構築できる構造にします。
さらに複数cBotでは、 各BotのRiskSharePercentを制限しながら Account.EquityによるGlobal Guardも入れる。
部分決済まで考慮し、 復元できない場合はFail Safeで停止する。
この3つを基本に、 Safety BufferとFail Safeを重ねる。
私はこれが、 Fundora × cTrader CloudでcBotを運用するときの Risk Managerとしてかなり現実的な構成だと考えています。
ただし、 Risk ManagerはFundora公式の判定システムそのものではありません。
過去価格から復元したEquityとFundora側の内部値には 誤差が生じる可能性があります。
公式5%ぎりぎりまで使うためのシステムではなく、 5%へ近づく前に止めるためのシステム として設計することが重要です。
プロップファーム向けEA・cBotを自分で設計するのが難しい方へ
Fundora用cBotを実際に作ろうとすると、 売買ロジック以外にも考えることがかなりあります。
日次Equityの復元。
複数cBotのリスク配分。
部分決済。
Cloud再起動。
Fail Safe。
重要指標時の停止。
こうしたRisk Managerやプロップファーム向けEA・cBotの設計を個別に相談したい方向けに、 EA自動売買・プロップファーム対応マスタークラスも案内しています。
既存EA・cBotの修正、 Risk Manager、 Fundora・Fintokei・Funded7などのルールに合わせた設定、 バグ確認・修正などを扱っています。
EA自動売買・プロップファーム対応マスタークラスを見る※利益やプロップファームチャレンジの合格を保証するサービスではありません。
※本記事は2026年9月6日時点のFundora公式サイト・利用規約、cTrader公式ドキュメント、および筆者のEA・cBot・システム開発経験をもとに作成しています。
※Fundoraの日次最大損失率、リセット時刻、EA・cBot利用条件、取引ルール等は変更される可能性があります。利用前およびcBot稼働前には必ずFundora公式サイトで最新情報をご確認ください。
※History・Positions・過去価格を利用したResetEquityの復元方法はRisk Managerを構築するための技術的な設計例です。Fundora側の内部計算値との完全一致を保証するものではありません。
※Risk Managerの内部停止率として記載した3.5%～4%などの数値は設計例であり、すべての戦略に適した推奨値を意味しません。銘柄、ロット、最大スプレッド、スリッページ、保有時間などに合わせて安全余裕を検討してください。
※Fundora公式ではEA・cBot等の自動売買は原則として利用者自身が作成したものを対象としており、場合によってコード提出を求められる可能性があります。
※本記事は情報提供を目的としたものであり、投資助言・売買推奨ではありません。EA・cBot、自動売買、バックテスト、Risk Manager等の利用によって将来の利益やプロップファームチャレンジの合格が保証されるものではありません。
※記事内にはアフィリエイトリンクが含まれます。
