更新日：2026年10月10日｜Fundora × cTrader Cloud × Risk Manager
- FundoraのcBotで日次損失5％を守る方法｜cTrader Cloud再起動後のEquity復元とリスク管理
- 最初に知っておきたい用語
- Fundoraの日次最大損失5％は朝のEquityが重要
- cTrader Cloudでは保存したデータが再起動後に消えることがある
- Cloud再起動後にResetEquityを復元するには？
- 過去のEquityを計算するときは買値と売値の違いにも注意
- 部分決済や追加注文があるとEquityの復元はさらに難しくなる
- Fundoraで複数cBotを動かす場合は口座全体の損失を見る
- 私ならcBotごとの損失枠と口座全体の監視を組み合わせる
- 複数cBotと1本の複数通貨対応cBotはどちらが管理しやすい？
- Fundora向けcBotのRisk Managerに必要な機能
- 重要経済指標の前後はcBotを止める判断も必要
- FundoraのcBotは原則として自作・自主管理が前提
- Cloud再起動直後は売買を停止し、安全確認後に再開する
- 実運用前にはバックテストだけでなく再起動テストも必要
- Fundora以外のプロップファームとも比較して判断する
- まとめ｜FundoraのcTrader Cloudでは復元できるRisk Managerが重要
- 公式情報・参考資料
FundoraのcBotで日次損失5％を守る方法｜cTrader Cloud再起動後のEquity復元とリスク管理
FundoraでcBotを使って自動売買する場合、 「1日の損失が5％に達したら自動で止めれば大丈夫」 と思うかもしれません。
しかし、実際にはそれだけでは十分ではありません。
特に注意したいのが、cTrader Cloudが途中で停止・再起動した場合に、それまでの損失情報を正しく引き継げるかという問題です。
Fundoraでは、日次損失を計算する基準時刻が決まっています。 その時点で保有しているポジションの含み益・含み損も、損失管理に関係します。
もしcBotが再起動したときに、朝の口座資産やそれまでの損益を忘れてしまったら、日次損失を正しく管理できなくなる可能性があります。
私ならFundora向けcBotを開発する場合、 「保存したデータを読み込むだけの仕組み」ではなく、「データが消えても取引履歴から復元できる仕組み」 を作ります。
そして、複数のcBotを動かす場合は、それぞれの損失を制限しながら、口座全体の損失も監視します。
さらに大切なのが、必要な情報を復元できなければ、新しい注文を出さずに停止することです。
この記事では、Fundoraの日次損失ルールと、それをcBot側で管理する方法を開発者目線で解説します。
私は2020年からMT4・MT5のEAやインジケーター、cTrader・cBot関連システムの開発に取り組み、これまで200個以上を開発・制作・検証してきました。
プロップファーム向けの自動売買では、利益を狙う売買ロジック以上に、損失制限をどう守るかが難しい部分です。
今回はFundoraとcTrader Cloudを組み合わせた場合の注意点を、なるべく難しい言葉を使わずに説明していきます。
最初に知っておきたい用語
この記事では、cBotの開発や損失管理に関する言葉が登場します。 まずは重要な用語だけ、簡単に整理しておきましょう。
| 用語 | 簡単な意味 |
|---|---|
| cBot | cTraderで動く自動売買プログラム |
| Equity | 含み損益を含めた現在の口座資産 |
| Balance | 決済済みの損益を反映した口座残高 |
| ResetEquity | 日次リセット時刻のEquity |
| Risk Manager | 損失を監視・制限する仕組み |
| LocalStorage | cBotが情報を保存する機能 |
| History | 決済した取引の履歴 |
| Positions | 現在保有しているポジション |
| Recovery | 失われた情報を復元すること |
| Fail Safe | 異常時に安全のため停止する仕組み |
特に覚えておきたいのが、BalanceとEquityの違いです。
例えば口座残高が1,000万円で、現在保有している取引に50万円の含み損があれば、Balanceは1,000万円、Equityは950万円になります。
そしてResetEquityとは、Fundoraが定める1日の切り替え時刻におけるEquityのことです。
この記事の中心になるのは、cBotを再起動したあとも、その日の基準となるResetEquityを正しく把握できるかという問題です。
Fundoraの日次損失ルール
Fundoraの日次最大損失5％は朝のEquityが重要
口座残高だけでは正しい損失管理にならない
Fundoraでは、1日の最大損失率が5％と定められています。
ただし、1日の区切りは日本時間の午前0時ではありません。
2026年10月10日時点で確認したFundora公式の取引ルールと利用規約では、夏時間は日本時間午前6時、冬時間は午前7時に日次の計算が切り替わると案内されています。
そして重要なのが、リセット時点の有効証拠金、つまりEquityを基準として損失を計算することです。
含み益・含み損も日次損失に関係する
ポジションを持たずに朝のリセット時刻を迎える場合、BalanceとEquityは基本的に同じになります。
しかし、ポジションを保有したまま朝を迎えると話が変わります。
例えば口座残高が2,000万円で、保有中の取引に100万円の含み益があるとします。
この場合、リセット時のEquityは2,100万円です。
この基準額の5％は105万円になります。
単純化した計算例では、2,100万円から105万円を引いた1,995万円が、日次損失ラインになります。
その後、含み益100万円がなくなっただけでも、Equityは2,000万円へ減少します。
つまり利益を確定していなくても、日次損失ラインまでの余裕が小さくなる可能性があります。
これ、バックテストの利益グラフだけを見ていると気づきにくいんですよね。
売買ロジックが正常でも、日次損失の計算を間違えていれば、Fundoraのルールへ抵触する可能性があります。
Fundoraのリスク1％ルールも忘れてはいけない
日次損失5％とは別に、Fundoraでは1回の取引におけるリスク管理も重視されています。
公式の説明では、デモ口座の有効証拠金の1％を超える損失が一時的に発生した場合、注意・警告・失格の対象になる可能性があります。
また、関連性が高い複数ポジションで過剰なリスクを抱える取引も注意対象として示されています。
例えば1つのcBotが大きなロットで取引し、1回の注文で3％の損失を出したとします。
1日の損失合計が5％以内だったとしても、Fundoraの1％リスク基準に抵触する可能性があります。
そのため、1回の取引の損失と、1日全体の損失は別々に管理する必要があります。
なお、1％を一度超えたら必ず即時失格という説明ではありません。 ただし、警告や失格につながる可能性があるため、安全側で運用することが重要です。
cTrader Cloudでは保存したデータが再起動後に消えることがある
ここからが、cTrader Cloudを利用するときの大きな注意点です。
cBotは、取引に必要な情報をファイルやLocalStorageへ保存できます。
例えば、朝のEquity、当日の損失額、最後に注文した時刻などを記録しておけば、cBotが動いている間はその情報を利用できます。
しかし、cTrader Cloudではインスタンスを停止・再起動すると、内部に保存したファイルが残らない仕様になっています。
これはcTrader公式ドキュメントでも説明されています。
ローカルPC・VPSとCloudでは保存の考え方が違う
| 実行環境 | 保存データの扱い | 注意点 |
|---|---|---|
| ローカルPC | 保持できる | 古い情報に注意 |
| VPS | 保持できる | 初期化条件が必要 |
| cTrader Cloud | 再起動で消失 | 復元処理が必要 |
PCやVPSであれば、ディスクに保存した情報を再起動後も読み込める場合があります。
一方、Cloudでは保存データがなくなった状態から始まることを想定する必要があります。
私なら、保存したResetEquityを最初に確認し、利用できればその値を使います。
しかしデータがなければ、取引履歴や口座情報から必要な状態を復元する仕組みを用意します。
このような、一時的に保存した情報を利用しつつ、消えても復元できる設計が重要です。
CloudとVPSの保存方法については、 cTrader CloudとVPS・ローカルPCで保存データがどう変わるかを解説した記事 でも詳しく説明しています。
Cloudでは外部サイトから設定を取得する方法にも注意
cTrader公式ドキュメントでは、Cloud実行中の通常のHTTPリクエストは送信されないと案内されています。
そのため、CloudのcBotから外部サイトへアクセスして、毎朝Fundoraのルールを取得するような仕組みには依存できません。
私なら日次リセット時刻や損失上限は、cBotの設定画面から変更できるようにします。
Fundoraのルールが変わった場合でも、プログラムそのものを書き換えずに対応しやすくなるためです。
Cloud再起動後にResetEquityを復元するには？
cTrader Cloudを再起動したあと、ResetEquityが保存されていなかったらどうすればよいのでしょうか。
私なら、cTraderの取引口座に残っている情報を組み合わせ、日次リセット時点の状態を復元する方法を検討します。
ここで利用するのが、History、Positions、Transactions、MarketDataという4つの情報です。
| 取得する情報 | 主な用途 |
|---|---|
| History | 決済済み取引を確認 |
| Positions | 現在の保有状況を確認 |
| Transactions | 口座残高の変化を確認 |
| MarketData | 過去の価格を取得 |
難しい名前ですが、考え方はシンプルです。
朝の時点で、口座にいくらあり、どんな取引を何ロット保有していたのかを調べ直すということです。
日次リセット時点のEquityは、次の関係で考えられます。
ResetEquity ≒ 朝の口座残高 ＋ 朝の含み損益
ただし、実際には取引手数料や金利調整なども関係するため、単純な価格差だけでは完全に再現できない場合があります。
Historyから決済済みの取引を調べる
Historyには、過去に決済した取引の情報が残っています。
取引した銘柄、注文方向、取引時刻、決済時刻、確定損益などを確認できます。
例えば朝6時以降にどの取引を決済したか調べれば、現在の口座残高がどのように変化したかをたどる手掛かりになります。
また、cTraderのHistoricalTradeには決済後のBalanceも記録されます。
こうした情報を組み合わせることで、朝の口座残高を推定できる場合があります。
現在の口座残高だけで朝の残高を決めない
「現在のBalanceから今日の利益を引けば朝の残高になる」と考えたくなるかもしれません。
しかし実際には、取引手数料、スワップ、部分決済、口座調整などによって計算が複雑になります。
そのため、現在のBalanceだけから単純に逆算する設計は避けた方が安全です。
Transactionsなども確認し、必要な履歴がそろっているかを調べる必要があります。
現在のポジションだけでは朝の状態が分からない
例えば、朝6時にUSDJPYの買いポジションを持っていたとします。
その取引を8時に決済し、10時に新しく売りポジションを持った場合、現在のPositionsには売りポジションしか表示されません。
しかし日次リセット時刻に保有していたのは、すでに決済した買いポジションです。
そのため、現在のPositionsだけでは朝のEquityを復元できません。
cTraderでは、PositionIdという番号を使って取引を識別できます。
HistoryのFindByPositionId()という機能を利用すれば、同じポジションに関係する決済履歴を調べられます。
私ならポジション番号と取引時刻を使い、朝のリセット時点で存在していた取引を確認する設計にします。
過去のEquityを計算するときは買値と売値の違いにも注意
朝のEquityを復元するときには、その時点の為替価格も必要になります。
ここで注意したいのが、チャートに表示される価格をそのまま使えばよいとは限らないことです。
FXには売値のBidと買値のAskがあり、買いポジションと売りポジションでは、損益を評価するときに使う価格が異なります。
| ポジション | 損益評価に使う価格 |
|---|---|
| 買い（BUY） | Bid（売値） |
| 売り（SELL） | Ask（買値） |
例えば、朝6時の買いポジションの含み損益を計算するなら、その時点のBidを確認する必要があります。
cTraderには過去の細かな価格変動を取得する機能もあります。 利用可能なTickデータがあれば、1分足の終値だけを使うより細かく計算できます。
過去価格を取得しても完全一致するとは限らない
ただし、過去の価格を使えばFundoraの公式判定値を完全に再現できるわけではありません。
実際のEquityには、取引手数料やスワップ、注文価格のずれなども影響します。
特に日次リセットの前後は、スプレッドが広がることもあります。
cBotが計算したResetEquityと、Fundora側が記録した数値が完全に一致する保証はありません。
だからこそ、日次損失5％ぎりぎりまで取引する設計ではなく、公式上限より手前で停止する仕組みが重要になります。
部分決済や追加注文があるとEquityの復元はさらに難しくなる
ここまでの説明は、1つのポジションをそのまま保有している場合を中心に考えています。
しかし、実際のcBotでは途中で一部を決済したり、同じ方向へ注文を追加したりすることがあります。
こうした取引では、現在のロットと朝のロットが違う可能性があります。
部分決済した場合
朝6時にUSDJPYを1ロット保有していたとします。
その後8時に半分を決済すると、現在の保有量は0.5ロットになります。
しかし、朝6時時点の含み損益は1ロット分で計算する必要があります。
現在の0.5ロットだけで過去の損益を計算すると、朝のEquityを正しく再現できません。
途中で追加注文した場合
追加注文も同じように注意が必要です。
例えば朝は1ロットだったポジションに、その後0.5ロットを追加したとします。
現在の1.5ロットで朝の含み損益を計算すると、実際より大きな保有量として扱ってしまいます。
そのため、ポジションの番号だけでなく、いつ増えたのか、いつ減ったのかまで確認する必要があります。
部分決済や追加注文の履歴が不足している場合、朝のポジション量を正確に再現できないことがあります。
私なら、その状態で無理に売買を再開させません。
必要な情報が確認できるまで新規注文を停止する設計にします。
Fundoraで複数cBotを動かす場合は口座全体の損失を見る
FundoraのcTrader口座で複数のcBotを利用する場合、もう一つ重要になるのが口座全体の損失管理です。
例えば、Gold用、USDJPY用、EURUSD用の3本のcBotを同時に動かすとします。
それぞれが別の売買ルールで動いていても、同じ口座を使っていれば、損失は同じ口座に反映されます。
つまり、各cBotが自分の損失だけを管理していても、Fundoraの日次損失5％を守れるとは限りません。
私なら、各cBotには自分が使用できる損失枠を設定します。
そのうえで、Account.Equityを利用して口座全体の損失も監視します。
1本のcBotが正常でも、ほかのcBotで大きな損失が出ているなら、新しい注文を止める必要があります。
cTrader Cloudで複数cBotを稼働できる数は、口座の表示区分や提供環境によって異なります。
FundoraとFintokeiの違いについては、 cTrader CloudでcBotを何個動かせるか実際に検証した記事 も参考にしてください。
複数cBotが同時に注文すると損失枠を超えることがある
開発者として特に注意したいのが、複数のcBotがほぼ同じタイミングで注文するケースです。
例えばGold用cBotとUSDJPY用cBotが、同時に口座情報を確認したとします。
どちらも「まだ損失枠に余裕がある」と判断し、ほぼ同時に注文を出す可能性があります。
この場合、片方の注文が口座情報へ反映される前に、もう片方の注文も通ってしまうことがあります。
その結果、予定していた損失上限を超えるリスクが発生するかもしれません。
Account.Equityを監視する機能は重要ですが、それだけで複数cBotの同時注文による問題を完全に防げるわけではありません。
各cBotに使える損失枠をあらかじめ割り当て、1本だけで過剰なリスクを取らないようにすることも必要です。
私ならcBotごとの損失枠と口座全体の監視を組み合わせる
複数cBotを運用する場合、私はリスクを2段階で管理する設計を考えます。
1つ目は、それぞれのcBotが使える損失枠を決めることです。
2つ目は、口座全体のEquityを監視し、危険な状態ではすべての新規注文を停止することです。
開発では、前者をPer-Bot Risk Budget、後者をAccount Global Guardと呼ぶことがあります。
損失枠をcBotごとに配分する
例えば、口座全体で使用できる内部の損失枠を100％として、稼働するcBotの数に応じて分配する方法があります。
| 稼働数 | 1本あたりの配分 |
|---|---|
| 1本 | 100％ |
| 2本 | 50％ |
| 3本 | 約33％ |
| 4本 | 25％ |
ここでいう100％は、口座資金をすべて失ってよいという意味ではありません。
cBot側で設定した内部の損失許容枠を100％として考えるという意味です。
Fundora公式の日次最大損失率は5％ですが、cBot側では余裕を持って3.5％を内部の停止基準として設定すると仮定します。
4本のcBotへ均等に配分すれば、1本あたりの損失枠は0.875％相当になります。
ただし、3.5％はあくまで計算例であり、すべての運用に適した推奨値ではありません。
また、この配分は日次損失を管理するためのもので、Fundoraの1取引あたりのリスク1％基準とは別です。
RiskSharePercentを設定できるようにする
cBotごとに損失枠を配分する場合、RiskSharePercentという設定項目を用意する方法があります。
例えばGold用を20％、USDJPY用を40％、EURUSD用を40％に設定するイメージです。
すべて同じ割合にする必要はありません。 売買回数や値動きの大きさなどに合わせて調整できます。
私ならcBotの名前から自動的に配分を決めるより、設定画面で明示的に指定できるようにします。
名前を変えたことで損失管理の設定まで変わってしまうと、思わぬトラブルにつながるからです。
1回の取引・cBot単位・口座全体を分けて管理する
Fundora向けcBotでは、損失管理をさらに3つに分けて考えると整理しやすくなります。
| 管理する範囲 | 役割 |
|---|---|
| 1回の取引 | 過大な損失を防ぐ |
| cBotごと | 割り当てた損失枠を守る |
| 口座全体 | 日次損失上限を監視 |
この3つを分けることで、どこに問題があるのか判断しやすくなります。
例えば1本のcBotだけが損失枠を使い切ったなら、そのcBotの新規注文を停止します。
一方、口座全体が内部停止ラインに達した場合は、すべてのcBotで新しい注文を止める必要があります。
なお、全cBotが同時に停止を確実に共有できるかどうかは実装方法によって異なります。 独立したCloudインスタンスだけで完全な一元管理ができると考えず、発注競合にも対策することが重要です。
複数cBotと1本の複数通貨対応cBotはどちらが管理しやすい？
複数の通貨ペアを自動売買する場合、銘柄ごとにcBotを分ける方法と、1本のcBotで複数銘柄を管理する方法があります。
どちらが必ず優れているというわけではありません。
銘柄ごとに分ける
- 個別停止
- しやすい
- 機能修正
- 分離できる
- 損失共有
- 工夫が必要
1本にまとめて管理
- 損失管理
- 一元化
- 注文順序
- 制御しやすい
- 開発規模
- 大きくなる
例えばGold用とUSDJPY用でまったく違う売買ルールを使うなら、別々のcBotにした方が修正しやすいことがあります。
一方、すべての通貨ペアを同じRisk Managerで管理したいなら、1本にまとめる方法も有効です。
私なら売買ロジックの複雑さと、損失管理のしやすさを比較して判断します。
Fundora向けcBotのRisk Managerに必要な機能
ここまでの内容を実際のシステム開発に落とし込むと、どんな機能が必要になるのでしょうか。
私なら、次のように役割を分けて設計します。
Risk Managerの役割は、利益を大きくすることではありません。
損失が増えすぎる前に新規注文を制限し、異常が発生したときには安全側へ停止することです。
プロップファーム向け自動売買では、この考え方が特に重要だと私は考えています。
重要経済指標の前後はcBotを止める判断も必要
Risk Managerが正しく動いていても、相場が急変すると予定していた損失額を超えることがあります。
例えば米国雇用統計、CPI、FOMCなどの重要な経済イベントでは、短時間で価格が大きく動く場合があります。
普段は小さな値幅で売買するcBotでも、急変時には損切り注文が予定した価格で成立しないことがあります。
特に逆張り型やナンピン型では、相場が一方向に動き続ける場面に注意が必要です。
私はEAやcBotを作るとき、売買する時間帯を限定することも検討します。
重要経済指標の前後は新しい注文を出さない、相場の急変時はロットを下げる、必要に応じて停止する、といった設計です。
自動売買だからといって、完全に放置できるわけではありません。
特にFundoraのように日次損失制限がある場合は、相場が大きく動いたときの損失拡大を想定しておく必要があります。
日次損失5％ちょうどを内部停止ラインにすると、注文価格のずれなどで制限を超える可能性があります。
だからこそ、Risk Manager側で余裕を持った損失制限を設定することが重要です。
FundoraのcBotは原則として自作・自主管理が前提
Fundoraでは、EA・cBot・ツールによる自動売買が認められています。
ただし、2026年10月時点の公式FAQでは、原則として利用者自身が作成したEAやツールが対象とされています。
場合によっては、本人が作成したものであることを確認するために、コードの提出を求められる可能性も案内されています。
そのため、他人が作成したcBotをそのまま購入して動かす場合は、利用条件に注意が必要です。
AIを利用してcBotを作る場合でも、コードの内容を確認することが重要です。
どの条件で注文するのか、何ロットで取引するのか、どんなときに停止するのか。
私なら、これらを自分で説明できる状態にしてからテストします。
特にプロップファーム向けでは、売買ロジック以上に損失制限の動作確認を重視します。
Fundoraのプランや自動売買ルールを確認したい方は、以下の公式サイトを参考にしてください。
【PR】Fundoraの最新プラン・利用条件を見る※PR・アフィリエイトリンクを含みます。参加料金や取引ルールは変更される可能性があります。
Cloud再起動直後は売買を停止し、安全確認後に再開する
Fundora向けcBotでRisk Managerを作るなら、起動時の処理順序も重要です。
私なら、Cloudを再起動した直後に売買ロジックを動かす設計にはしません。
まず必要な情報を確認し、安全に取引できると判断してから新しい注文を許可します。
最初に新規注文を停止した状態で起動します。
次に、現在の日次リセット時刻を確認し、保存データが残っているかを調べます。
保存データがなければ、取引履歴やポジション情報を使って朝のEquityを復元します。
その後、現在のEquityと日次損失ラインを比較します。
必要な情報がそろい、安全が確認できてから新規注文を許可するという流れです。
情報が復元できない場合は取引しない
例えば、必要な取引履歴が不足している場合や、朝のポジション量を再現できない場合です。
このような状態で「おそらく大丈夫」と判断し、新しい注文を出すのは危険です。
そこで利用するのがFail Safeという考え方です。
Fail Safeとは、異常が発生したときに無理に処理を続けず、安全な状態に移行する仕組みです。
履歴が不足している、計算結果が矛盾している、リセット時刻が確認できない。
こうした場合は新規注文を停止し、利用者が確認できる状態にします。
ただし、新規注文を止めるだけで、すでに持っているポジションの損失がなくなるわけではありません。
既存ポジションをどう扱うかも、別途ルールを決めておく必要があります。
私なら、売買機会を逃すことより、誤った損失管理で取引を続けるリスクを小さくすることを優先します。
実運用前にはバックテストだけでなく再起動テストも必要
ここまで説明したRisk Managerは、通常のバックテストだけでは十分に確認できません。
特にCloud停止、再起動、保存データの消失、複数cBotの同時注文などは、実際の運用環境に近い条件でテストする必要があります。
| テスト内容 | 確認すること |
|---|---|
| 日次リセット | 朝の基準値を正しく更新 |
| Cloud再起動 | 保存データなしで復元 |
| 部分決済 | 過去のロットを認識 |
| 追加注文 | 保有量の変化を反映 |
| 複数cBot | 口座全体の損失を確認 |
| 急変相場 | 損失超過時の動作 |
| 情報不足 | 安全に新規注文を停止 |
バックテストでは正常に動いていても、Cloudを再起動したときだけ問題が発生することがあります。
例えば、保存ファイルが存在する前提でコードを書いていると、ファイルがなくなったときにエラーになる可能性があります。
また、再起動後に以前の損失額がゼロとして扱われる設計も避けたいところです。
私なら、保存データを削除した状態からcBotを起動するテストも実施し、取引履歴から必要な情報を復元できるかを確認します。
そして復元できない場合に、新規注文が正しく停止することまで確認します。
プロップファーム向けcBotでは、利益率や最大ドローダウンだけでなく、停止・再起動・異常時の動作も重要です。
プログラムがエラーなく動くことと、Fundoraの損失ルールを守れることは別だと考えておきましょう。
Fundora以外のプロップファームとも比較して判断する
cBotで自動売買を行う場合、Fundora以外のプロップファームと比較してみることも大切です。
特に確認したいのは、自動売買の利用条件、日次損失の計算方法、同時保有ポジションのリスク、cTrader Cloudへの対応です。
例えばFintokei、PipFarm、FTMOなどでも、自動売買に関する条件や取引ルールはそれぞれ異なります。
同じcBotでも、会社ごとに損失制御や設定の調整が必要になる場合があります。
各社の特徴をまとめて比較したい方は、 日本人トレーダー向けプロップファーム比較記事 も参考にしてください。
※上記にはPR・アフィリエイトリンクを含みます。各社の最新ルールは公式サイトでご確認ください。
まとめ｜FundoraのcTrader Cloudでは復元できるRisk Managerが重要
Fundoraの日次最大損失5％をcBot側で管理するとき、重要なのは単純に5％を掛け算することではありません。
日次リセット時点のEquityを正しく把握し、Cloud再起動後にも必要な情報を復元できることが大切です。
cTrader Cloudでは、保存したLocalStorageやファイルが再起動後も残る前提では設計できません。
そのため、取引履歴、現在のポジション、口座残高の変化、過去価格などから、必要な情報を復元できる構成を考えます。
また、複数cBotを動かす場合は、それぞれの損失枠と口座全体の損失を分けて監視する必要があります。
部分決済や追加注文などによって、朝のEquityを正確に復元できない場合もあります。
そうしたときに無理に売買を続けず、安全側へ停止する仕組みが重要です。
私ならFundora用のRisk Managerを、この4つを中心に設計します。
保存データが残っていれば利用し、消えていれば取引履歴などから復元する。
それでも安全に取引できる状態か分からなければ、新しい注文を出さない。
EA・インジケーターなどを200個以上開発・制作・検証してきた立場からも、プロップファーム向け自動売買では、このような損失管理の考え方が重要だと感じています。
Risk Managerは、Fundora公式の損失判定システムを置き換えるものではありません。
公式の5％ぎりぎりまで取引するためではなく、制限に達する前に安全側へ停止するための仕組みとして利用することが重要です。
これからFundoraでcBotを利用する方は、まず公式ルールと自分のcBotの損失管理方法を確認し、デモ環境で再起動テストまで行ってから運用を判断してください。
公式情報・参考資料
Fundoraの取引ルールやcTrader Cloudの仕様は変更される場合があります。
実際にcBotを動かす前には、以下の公式情報をご確認ください。
※本記事は2026年10月10日時点のFundora公式FAQ・取引ルール・利用規約、cTrader公式ドキュメント、および筆者のEA・cBot開発経験をもとに作成しています。
※Fundoraの日次最大損失率、リセット時刻、リスク1％基準、EA・cBot利用条件などは変更される可能性があります。利用前には必ず最新の公式ルールをご確認ください。
※取引履歴や過去価格からResetEquityを復元する方法は、cBotのリスク管理システムを設計するための考え方です。Fundora側の判定値と完全に一致することを保証するものではありません。
※内部停止ラインとして例示した3.5％は説明用の数値であり、すべてのEA・cBotや運用方法に適した設定値を意味しません。
※本記事は情報提供を目的としたものであり、投資助言・売買推奨ではありません。プロップファームには参加料金、評価不合格、口座停止、報酬条件未達などのリスクがあります。EA・cBotの利用によって利益やチャレンジ合格が保証されるものではありません。
※本記事にはPR・アフィリエイトリンクが含まれます。
