「EAは何個まで動かせますか？」という疑問に対して、明確な上限値はありません。動作可能な数は、端末やVPSの性能、EAの処理の重さ、同時に開くチャート数、ブローカー側の発注制限、ネットワーク品質など、複数の要因で決まるからです。とはいえ、実務上の目安や設計の考え方を押さえておくことで、安定性とパフォーマンスを両立しやすくなります。
まず理解しておきたいのは、EAは「チャート単位」で動作し、価格が更新されるたびに処理が走るという点です。複数のEAを並行させるほどティック到着のたびに全EAが計算を行い、CPU負荷とメモリ消費が増えていきます。特にカスタムインジケーターを多用するEA、マルチタイムフレームの参照やファイル入出力を頻繁に行うEA、最適化用のログを大量に吐くEAなどは負荷が高く、同時稼働数を抑えないと端末が重くなりやすいです。また取引処理は一度に一つずつしか通らない性質があり、複数のEAがほぼ同時に発注・変更・決済を要求すると、処理が待たされたりリトライが発生したりして約定機会を逃すことがあります。発注タイミングの衝突を避ける工夫は、稼働数が増えるほど重要になります。
次に、現実的な稼働数の目安についてお話しします。軽量なロジックで、インジケーター呼び出しが少なく、発注頻度も低いEAであれば、一般的な2vCPU（仮想CPUが2つ割り当てられたサーバー）・2～4GBメモリ程度のVPSでも10～20個程度は安定運用しやすい感覚があります。これに対して、スキャル系のようにティックごとに重い判定を行い、さらに複数通貨で走らせる場合は、同条件のVPSでは5～10個でも限界が近づきます。ハードウェアを強化し、ネットワーク遅延が小さい環境を用意すれば30個以上動くこともありますが、ティック集中時のスパイクや同時発注の競合が増え、全体の約定品質が下がるなら本末転倒です。無理に数を増やすより、1端末あたりの負荷を見ながら分散する考え方が有効です。
分散の方法としては、通貨グループや手法の系統ごとに端末を分ける、同一手法のパラメータの違うEAは別端末に逃がす、バックテストや最適化用の端末とリアル運用端末を切り分ける、といったやり方があります。こうすることで、一時的に負荷が跳ね上がっても、すべてのEAが同時に遅延する事態を避けやすくなります。ブローカー側の制限にも目を向けてください。口座あたりの同時保有可能な注文・ポジション数、注文レートの制限、短時間の発注回数制限などは業者や口座タイプで異なります。複数EAが同時に指値・逆指値を大量に置くと上限に達し、期待通りの配分ができないことがあります。事前にサポートへ具体的な数値を確認しておくと安心です。
端末側の軽量化も、稼働数を押し上げるうえで効果的です。不要なチャートは閉じ、マーケットウォッチから使わない通貨の気配値配信を止め、履歴本数の設定を見直してメモリ使用量を抑えます。ログ出力は開発・検証時以外は最小限にし、秒間に何度もファイルアクセスを行う処理は避けます。インジケーターを複数EAで共有的に使う場合、計算の重複が積み上がることがあるので、処理の簡素化や呼び出し頻度の最適化が効いてきます。さらに、全体のリスク管理を「口座単位」で見ておくことも大切です。EAを増やすほど証拠金の取り合いが起き、同時ドローダウンの局面では証拠金不足や強制ロスカットに近づきます。各EAのロットを個別に決めるだけでなく、口座全体で許容する最大損失や最大同時ポジション数を決め、条件を満たしたら新規を自動的に見送る仕組みを設けると、数が増えても破綻しにくくなります。
監視のポイントは、CPUの常時使用率、ピーク時のスパイク、メモリの残量、ネットワークの遅延とパケットロス、そしてジャーナルに現れる約定遅延や注文拒否の記録です。これらが健全な範囲に収まり、かつ実際のパフォーマンスが単体運用時と比べて劣化していないのであれば、その環境における「何個まで」が見えてきます。最初から上限ギリギリを狙うのではなく、段階的にEAを追加し、増やすたびに安定度と成績を確認する手順が結局は近道になります。
以上のように、EAの同時稼働数に絶対的な上限はありませんが、端末性能、EAの負荷、発注の競合、ブローカーの制限、口座全体のリスクという五つの視点を丁寧に整えることで、無理なく増やせる数が自然に定まります。目安としては、軽量EA中心なら1端末あたり10～20個、重めの戦略が混ざるなら5～10個程度から始め、負荷計測と成績を見ながら分散するのがおすすめです。最終的な答えは環境と設計次第ですが、数そのものよりも「安定して狙い通りに約定し、想定どおりのリスクで回せているか」を基準に判断すると、過不足のない最適な稼働数に落ち着きます。
