1. HistoryDealGetString関数の概要と実務での活用法
MQL5におけるHistoryDealGetStringは、過去に行われた「約定(Deal)」の履歴から、文字列型のプロパティを取得するための関数です。MQL5では「注文(Order)」「約定(Deal)」「ポジション(Position)」が明確に区別されており、この関数は実際に売買が成立した結果の記録にアクセスするために使用します。
実務レベルでは、主に以下のようなシーンで活用されます。
* 約定コメントの解析: 注文時に入力した「DEAL_COMMENT」を取得し、どのロジックで発生したトレードかを識別する。
* 通貨ペアの特定: DEAL_SYMBOLを取得し、多通貨ペア運用のEAで履歴集計を行う。
* 外部IDの照合: 業者側の管理番号(DEAL_EXTERNAL_ID)を取得し、外部データベースやスプレッドシートと照合する。
初心者が特につまずきやすいポイントは、「履歴を選択状態にしないと値が取得できない」という点です。事前にHistorySelectやHistoryDealSelectを呼び出さずにこの関数を使っても、空の文字列しか返ってこないため注意が必要です。
2. 構文と戻り値
HistoryDealGetString関数の構文は以下の通りです。
string HistoryDealGetString(
ulong ticket_number, // 約定チケット番号
ENUM_DEAL_PROPERTY_STRING property_id // プロパティ識別子
);
パラメーター
- ticket_number: 取得したい約定のチケット番号(ulong型)を指定します。
- property_id: 取得したい情報の種類を
ENUM_DEAL_PROPERTY_STRING列挙型から指定します。
主なプロパティ識別子
DEAL_SYMBOL: 約定が発生した通貨ペア名(例: “USDJPY”)。DEAL_COMMENT: 約定に関連付けられたコメント。DEAL_EXTERNAL_ID: 外部取引システムでのID(業者によって提供される場合がある)。
戻り値
指定したプロパティの値(string型)を返します。指定したチケットが存在しない場合や、プロパティが文字列型でない場合は空の文字列を返します。
3. 具体的な使い方・実践サンプルコード
以下のコードは、直近1週間の履歴の中から、特定のコメントが含まれる約定を探し、その詳細をエキスパートログに出力する例です。
void OnStart()
{
// 1. 履歴を取得する範囲(現在から過去1週間分)を指定
datetime end = TimeCurrent();
datetime start = end - PeriodSeconds(PERIOD_D1) * 7;
// 2. 履歴をメモリ上にロード(これを行わないとHistoryDealGetStringは動作しない)
if(!HistorySelect(start, end))
{
Print("履歴の取得に失敗しました。");
return;
}
// 3. 取得した約定の総数を確認
int total_deals = HistoryDealsTotal();
PrintFormat("取得した約定数: %d", total_deals);
// 4. 履歴をループで回して情報を取得
for(int i = 0; i < total_deals; i++)
{
// インデックスからチケット番号を取得
ulong ticket = HistoryDealGetTicket(i);
if(ticket > 0)
{
// HistoryDealGetStringを使って情報を取得
string symbol = HistoryDealGetString(ticket, DEAL_SYMBOL);
string comment = HistoryDealGetString(ticket, DEAL_COMMENT);
// 取得したデータの型はstringなので、そのまま出力や比較が可能
PrintFormat("チケット: %I64u | 通貨ペア: %s | コメント: %s",
ticket, symbol, comment);
// 特定のコメントを持つ約定を見つける例
if(StringFind(comment, "TP") != -1)
{
Print("--> このトレードは利確(Take Profit)で終了しています。");
}
}
}
}
4. 使用上の注意点とよくあるエラー
-
HistorySelectの実行漏れ:
MQL5の履歴系関数は、必ずHistorySelect(from, to)またはHistoryDealSelect(ticket)を先に実行し、内部的なキャッシュにデータを呼び出す必要があります。これを忘れると、関数はエラーを出さずにただ「空」を返します。 -
Order(注文)とDeal(約定)の混同:
OrderGetStringは「これから出そうとする、あるいは出された注文」を対象とし、HistoryDealGetStringは「すでに成立した取引」を対象とします。指値が刺さった後の結果を分析したい場合は、必ずHistoryDeal...を使用してください。 -
チケット番号の有効性:
ループ内でチケット番号を取得する際は、必ずHistoryDealGetTicket(index)を介して正しいチケット番号を取得してからHistoryDealGetStringに渡すようにしてください。
5. 【重要】自動売買における約定スピードと環境の罠
どれほど完璧なロジックをHistoryDealGetStringなどで管理しても、エンジニアとして見落としてはならないのが「物理的な実行環境」の壁です。自宅のPCや一般的な光回線を利用した自動売買は、ブローカーのサーバーとの間に数百ミリ秒単位のネットワーク遅延(レイテンシ)を発生させます。この遅延は、相場急変時のスリッページを増大させ、バックテストの結果とリアルトレードの結果が乖離する最大の原因となります。
アルゴリズムトレードにおいて、約定スピードの遅れはダイレクトに期待値の損失を意味します。極限までレイテンシを削り、ミリ秒単位の優位性を確保するためには、ブローカーのデータセンターに物理的に近い場所にある専用のVPS(仮想専用サーバー)を利用することが必須条件です。24時間稼働の安定性と、ネットワーク遅延の極小化を実現して初めて、あなたのコードは本来のポテンシャルを発揮できるのです。
💡 この記事の内容を実運用で活かすには?
この記事の内容を実運用で活かすには、正しい環境が必要です。
特にVPSを使わないと、このロジックは再現できません。

コメント