1. HistoryOrdersTotal関数の概要と実務での活用法
MQL5におけるHistoryOrdersTotalは、指定した履歴期間内に存在する「注文(Orders)」の総数を取得するための関数です。
ここで注意が必要なのは、MQL5の設計思想です。MQL5では「注文(Order)」「約定(Deal)」「ポジション(Position)」が明確に区別されています。HistoryOrdersTotalが取得するのは、あくまで「既に処理が完了した注文(約定して消えた、またはキャンセルされた待機注文など)」の数です。
実務開発において初心者が特につまずきやすいポイントは、「注文の数=取引の数」ではないという点です。1つの注文から複数の約定が発生することもあるため、取引結果の損益計算などを行う場合は、通常HistoryDealsTotal(約定の総数)を使用します。
一方で、HistoryOrdersTotalは以下のような場面で非常に重宝します。
– キャンセルされた指値注文の履歴を確認したいとき
– 特定の注文が「拒否(Rejected)」された回数をカウントし、ロジックにフィードバックしたいとき
– EAの注文ロジックが正常に取引サーバーに受理・処理されたかを監査するとき
このように、取引の結果(損益)ではなく「注文のプロセス」を追跡する際に、クオンツ的な分析やリスク管理の観点から欠かせない関数です。
2. 構文と戻り値
HistoryOrdersTotal関数の構文は非常にシンプルです。引数は必要ありません。
int HistoryOrdersTotal();
- 戻り値: 履歴内に存在する注文の総数を
int型で返します。 - 重要な前提条件: この関数を呼び出す前に、必ず
HistorySelect関数またはHistorySelectByPosition関数を使用して、ターミナル内のどの期間の履歴をメモリにロードするかを指定しておく必要があります。これを行わないと、戻り値は常に0になってしまいます。
3. 具体的な使い方・実践サンプルコード
以下は、過去24時間以内に「キャンセルされた指値注文」の数をカウントする実践的なスクリプトの例です。MQL5の履歴取得のフロー(HistorySelect → HistoryOrdersTotal → HistoryOrderGetTicket)を網羅しています。
void OnStart()
{
// 1. 履歴を取得する範囲を指定(現在の時刻から24時間前まで)
datetime endTime = TimeCurrent();
datetime startTime = endTime - (24 * 60 * 60);
// 2. 指定した期間の履歴をメモリにロードする(これが必要!)
if(!HistorySelect(startTime, endTime))
{
Print("履歴の取得に失敗しました。");
return;
}
// 3. 履歴内の注文総数を取得
int totalOrders = HistoryOrdersTotal();
int canceledOrdersCount = 0;
PrintFormat("過去24時間の全注文数: %d", totalOrders);
// 4. ループで個々の注文を精査する
for(int i = 0; i < totalOrders; i++)
{
// インデックスから注文チケット番号を取得
ulong ticket = HistoryOrderGetTicket(i);
if(ticket > 0)
{
// 注文のプロパティを確認(キャンセルされたかどうか)
long state = HistoryOrderGetInteger(ticket, ORDER_STATE);
if(state == ORDER_STATE_CANCELED)
{
canceledOrdersCount++;
// 詳細をログ出力
string symbol = HistoryOrderGetString(ticket, ORDER_SYMBOL);
PrintFormat("キャンセルされた注文: チケット#%I64u, 通貨ペア:%s", ticket, symbol);
}
}
}
PrintFormat("合計キャンセル注文数: %d", canceledOrdersCount);
}
4. 使用上の注意点とよくあるエラー
開発現場でよく遭遇するトラブルを回避するためのポイントは以下の通りです。
-
HistorySelectの呼び出し忘れ
最も多いミスです。HistoryOrdersTotalを呼ぶ前に必ずHistorySelectで期間を確定させてください。これを忘れると、口座に数千件の履歴があっても取得数は「0」になります。 -
「注文」と「約定」の混同
前述の通り、HistoryOrdersTotalは「注文(リクエスト)」の履歴です。決済したあとの損益や手数料、スワップを知りたい場合は、HistoryDealsTotalとHistoryDealGetDouble等を使用してください。 -
インデックスの順序
履歴内の注文は、通常古いものから順に 0, 1, 2… とインデックスが割り振られます。最新の注文を確認したい場合は、HistoryOrdersTotal() - 1のインデックスにアクセスすることになります。 -
パフォーマンスへの影響
数年単位の膨大な履歴をHistorySelectでロードしてからループを回すと、処理負荷が高まり、EAの動作が重くなる原因になります。必要な期間だけを絞り込むクオンツ的な最適化が実務では求められます。
5. 【重要】自動売買における約定スピードと環境の罠
アルゴリズムトレードにおいて、ロジックの正確さと同じか、それ以上に重要なのが「実行環境」です。多くの日本人開発者が自宅のPCや一般的な光回線でEAを稼働させようとしますが、これはプロの視点から見ると非常に危険な行為です。ネットワークの遅延(レイテンシ)は、注文がブローカーのサーバーに届くまでの間に価格を変動させ、致命的なスリッページを引き起こします。特にボラティリティが高い局面では、わずかコンマ数秒の遅れが、本来得られるはずだった利益を損失へと変えてしまいます。
極限まで約定スピードを高め、意図した価格で注文を成立させるには、ブローカーのデータセンターに近い場所に設置された「専用のVPS(仮想専用サーバー)」の利用が必須です。VPSを利用することで、物理的な距離による通信ラグを最小限に抑え、PCのフリーズや停電、Windows Updateによる予期せぬ再起動といったリスクからも解放されます。安定した高速環境を確保することは、勝てるシステムを構築するための「最低限の投資」と言えるでしょう。
💡 この記事の内容を実運用で活かすには?
この記事の内容を実運用で活かすには、正しい環境が必要です。
特にVPSを使わないと、このロジックは再現できません。

コメント