cTrader CloudとVPS・ローカルでcBotの挙動は変わる？ログが保存される仕組みを解説

最初に知っておきたい用語

この記事ではcTraderの保存機能を説明するため、いくつか専門用語が登場します。

まずは次の言葉だけ知っておけば、内容を理解しやすくなります。

cTrader Cloud・ローカルPC・VPSの違いを先に整理

cTraderでcBotを動かす場合、どの環境でも基本的な売買プログラムは同じように作れます。

しかし、保存機能を使う場合には、cBotを停止したあとに情報がどう扱われるかを確認する必要があります。

PCとVPSは、LocalStorageを使う場合の基本的な動作が似ています。

どちらも保存した情報が残るため、同じcBotを停止して再び動かしたときに、以前の状態を引き継ぐことができます。

一方、Cloudでは、インスタンスが再起動したときに以前の保存ファイルが利用できるとは限りません。

また、ここで説明する保存データとは、cBotがLocalStorageやJSON、CSVなどへ書き込んだ情報です。

cTraderの画面で確認する通常のログと、次回起動時にも利用する保存データは、分けて考える必要があります。

cTrader Cloudでは停止・再起動後のファイル保存を前提にしない

cTrader Cloudでは、インスタンスが停止・再起動すると、cBotが作成したファイルやフォルダーは削除されます。

2026年10月10日に確認したcTrader公式の「Cloud requirements」でも、Cloudインスタンスが停止または削除されると、その実行環境に割り当てられた情報は解放されると説明されています。

そのため、Cloud内に保存したファイルが次回起動時にも残っていることを前提にしてはいけません。

この問題を防ぐには、保存ファイルがなくても安全に起動できる仕組みが必要です。

例えば、現在の口座情報や取引履歴から、必要な計算結果を作り直す方法が考えられます。

Cloudではファイルの保存場所にも注意

cTrader Cloudでは、ファイル操作の方法にも条件があります。

公式ドキュメントでは、Cloud上のLocalStorageとファイル操作は、相対パスを指定する場合や、新しいフォルダーを最初から作成する場合に動作すると案内されています。

簡単にいうと、PC上の特定のフォルダーを指定したプログラムが、Cloudでも同じように動くとは限らないということです。

また、cTrader CloudはLinuxという環境で動作します。

そのため、Windows専用の画面機能や外部プログラムに依存するcBotは、そのままCloudで動かせない場合があります。

ローカルPCではLocalStorageを停止・再起動後も利用できる

ローカルPCでcTraderを動かす場合、LocalStorageはPC内の保存領域を利用します。

cTrader公式では、LocalStorageはcBotやインジケーターを停止したあとでも、以前の情報を利用するための機能として説明されています。

つまり、同じcBotを一度停止して再び起動しても、保存した情報を読み込めます。

cTraderの現在の仕様では、LocalStorageへ記録した情報は通常1分ごとに自動保存されます。

また、cBotインスタンスを停止するときにもデータが保存されます。

すぐに保存したい場合には、LocalStorage.Flush()という命令を使います。

例えば、注文が成立した直後や、損失管理の基準値を変更した直後などです。

このような重要な場面では、次の自動保存を待たずに記録しておく方法が考えられます。

VPSもcTraderを通常実行するならローカルPCと基本は同じ

Windows VPSへcTraderをインストールし、cBotを通常の方法で動かしている場合、LocalStorageの基本的な仕組みはローカルPCと同じです。

違いは、保存場所が自宅のPCではなく、VPS側のディスクになることです。

通常の永続ディスクを利用しているVPSなら、cTraderを再起動しても、保存した情報を引き続き利用できます。

ただし、VPSを新しいサーバーへ移行した場合や、ディスクを初期化した場合などは、以前の情報が利用できなくなることがあります。

Cloudではデータが消える場合への備えが大切ですが、PC・VPSでは反対に、以前のデータをいつ使い、いつ初期化するかを決める必要があります。

LocalStorageのInstance・Type・Deviceは何が違う？

LocalStorageには、保存した情報をどこまで共有するかを決める仕組みがあります。

これをScope（スコープ）と呼びます。

少し難しく聞こえますが、簡単にいうと「誰がその保存データを使えるのか」を決める設定です。

例えば、同じcBotを複数のチャートで動かす場合を考えてみます。

Instanceを使えば、それぞれのcBotが自分専用の情報を保存できます。

一方、Typeを使うと、同じ種類のcBot間で情報を共有できます。

Deviceはさらに範囲が広く、同じデバイス上の異なるcBotやインジケーターからも利用できます。

保存するときと読み込むときで動作が違う

ここは少し注意が必要です。

LocalStorage.SetString()やSetObject()で保存範囲を指定しなかった場合、基本的にはInstanceへ保存されます。

一方、GetString()やGetObject()で保存範囲を指定せずに読み込む場合は、次の順番で情報を探します。

また、以前のcBotインスタンスを削除して新しいものを作った場合、同じcBotでも以前のInstance領域をそのまま使えるとは限りません。

「保存したはずなのに読み込めない」という問題が起きたときは、ファイルが消えたのか、それとも違う保存場所を見ているのかを確認してください。

バックテストではLocalStorageがディスクへ保存されない

cTraderのバックテストでは、LocalStorageの扱いがリアルタイム運用と異なります。

バックテストやパラメーターの最適化中は、LocalStorageの情報がメモリ上だけで処理されます。

つまり、売買のバックテストが正常に終了しても、PCへ正しく保存できることや、再起動後に以前のデータを読み込めることまで確認できたわけではありません。

これ、バックテストだけ見ていると気づきにくいんですよね。

私なら、売買ロジックのバックテストとは別に、停止・再起動・保存・復元の動作確認を行います。

日付や週が変わっても保存した値は自動でリセットされない

例えば、1週間単位で損益を集計するcBotを考えてみます。

金曜日にLocalStorageへ計算結果を保存し、cBotを停止したとします。

月曜日に同じcBotを起動すると、PCやVPSでは金曜日の情報がそのまま残っている可能性があります。

LocalStorageには、日付や週が変わったからといって、自動で損益をリセットする機能があるわけではありません。

ただし、プロップファームの日次損失管理では、日本時間の午前0時が必ずリセット時刻になるとは限りません。

会社ごとに決められた基準時刻や計算方法があります。

そのため、単純にPCの日付が変わったかどうかだけではなく、利用するプロップファームのルールに合ったタイミングで切り替える設計が必要です。

口座番号や基準残高が変わった場合も確認する

プロップファーム向けのcBotでは、口座変更も重要なポイントです。

例えば、チャレンジの次の段階へ進んだ場合や、新しい口座を発行した場合です。

また、報酬の受け取りなどによって口座残高が変わり、以前のリスク管理基準を見直す必要が生じる場合もあります。

このとき、以前の口座情報をそのまま新しい口座へ引き継いでよいとは限りません。

例えば、ロット設定や表示色などは、新しい口座でも引き継げるかもしれません。

しかし、日次損失の基準値や以前の口座に関係する計算結果は、そのまま利用すると問題になる可能性があります。

プロップファームの出金後にリスク管理をどう見直すかについては、 プロップファーム出金後のEA・cBotのリスク管理 でも詳しく解説しています。

Cloud用cBotは「保存」より「復元」を重視する

cTrader Cloud向けcBotで私が特に重視するのは、保存データがなくなっても安全な状態へ戻せることです。

例えば、日次損失を管理するプログラムなら、基準値をファイルへ保存するだけでは十分ではありません。

保存したファイルがなくなった場合に、現在の口座情報や取引履歴から必要な情報を調べ直す仕組みを用意します。

こうした情報を組み合わせることで、保存データがなくても、ある程度の状態を復元できる場合があります。

ただし、すべての情報を完全に再現できるとは限りません。

例えば、過去の特定時刻における有効証拠金は、当時の保有ポジションや価格などが必要になるため、現在の残高だけでは正確に分からない場合があります。

プロップファームでは、日次損失制限や最大損失制限を超えると、評価に失格する可能性があります。

そのため、売買ロジックが正常に動いていても、リスク管理が正しい状態で再開できなければ意味がありません。

Fundoraを例にした具体的な考え方は、 FundoraのcBotで日次損失を管理するCloud再起動後の復元設計 で詳しく解説しています。

外部サーバーへ保存すれば解決するとは限らない

Cloud内のファイルが消えるなら、外部のサーバーへ保存すればよいと考える方もいると思います。

しかし、ここにも注意点があります。

2026年10月10日時点のcTrader公式Cloud requirementsでは、Algo APIのHTTP機能について、CloudではHTTPリクエストが送信されないと案内されています。

つまり、PCでは外部のWebサービスと通信できたcBotでも、Cloudで同じように動くとは限りません。

外部サービスへ情報を送る仕組みを作るなら、Cloudで利用できる通信方法や制限を確認する必要があります。

cTrader CloudとVPS・PCはどちらを選ぶべきか

cTrader CloudとVPS・ローカルPCは、どちらかが必ず優れているというものではありません。

使いたいcBotの機能と、保存データの管理方法によって選びます。

例えば、外部のデータベースやWindows用ツールを利用せず、cBot単体で運用するならCloudは便利です。

一方、複数のプログラムを連携させる場合や、独自の保存システムが必要な場合はVPSも検討できます。

ただし、VPSにはWindowsの更新、再起動、ネットワーク障害などの管理が必要です。

Cloudを選ぶ場合も、停止後にどう復元するかという問題は残ります。

cTrader Cloudの利用環境については、 cTrader CloudでcBotを動かす場合のFundora・Fintokei・PipFarmの比較記事 も参考にしてください。

実運用前に確認したいcBotの保存・再起動テスト

LocalStorageを利用するcBotは、実際に動かす環境で停止・再起動テストを行うことが大切です。

バックテストでは問題がなくても、ファイルが消えたり、以前の情報が残ったりすると、実運用で動作が変わる可能性があります。

特にプロップファーム向けcBotなら、日次損失の基準値が正しいか、現在のポジションを認識できるかを確認します。

複数のcBotを同じ口座で動かす場合は、それぞれが出した注文を含めて、口座全体の損失を管理できるかも重要です。

例えば、1つのcBotだけを見れば許容損失内でも、複数のcBotが同時に損失を出せば、口座全体の制限に近づく場合があります。

AIでcBotを開発するときも保存・復元の確認は必要

最近はChatGPTなどの生成AIを利用して、cBotのコードを作ることもできます。

以前と比べてプログラムを作る作業は進めやすくなりました。

しかし、AIが生成したコードだからといって、Cloud停止や口座変更など、すべての状況に対応できているとは限りません。

特に保存機能では、通常どおり動いているときには問題が見つからず、再起動したときに初めて不具合が分かることがあります。

EA・インジケーターなどを200個以上開発・制作・検証してきましたが、状態を引き継ぐシステムでは、売買条件そのものより、停止・再起動後の処理が複雑になることもあります。

AIは開発の助けになりますが、最後は実際の環境で正しく動くかを確認することが欠かせません。