【超入門】MQL5 ＥＡ講座第60回「OrderSend関数とMqlTradeRequest構造体」【EAの作り方】

———–

前回は　フィルポリシー　について解説しました。

改めて前回の内容をおさらいをしておくと、

フィルポリシーとは、流動性が極端に低下する等の事情で、発注した量のロット数では約定できないときの対応方法のことである。

FOKポリシーは発注した後、指定したロット数でのオーダーをサーバーが受け付けられないときは注文自体がキャンセルになる、というフィルポリシーである。

IOCポリシーは、指定したロット数でのオーダーをサーバーが受け付けられないとき、約定可能なロット分だけ約定させ、残りはキャンセルとなるフィルポリシーである。

RETURNポリシーは指定したロット数でのオーダーをサーバーが受け付けられないとき、約定可能なロット分だけ約定させ、残りの約定できなかったロット分も継続して注文処理を行うフィルポリシーである。

どのフィルポリシーを選択すればよいのかは、執行方式によって変わる。

フィルポリシーを指定しないと自動的にReturnポリシーを選択したことになる。

market執行方式口座では、Returnポリシーは無効である。

間違ったフィルポリシーを選択すると「Unsupported filling mode 」エラーが発生し売買をしてくれないので、適切なフィルポリシーを選択できるようなコーディングをしてEA(自動売買プログラム)を作る必要がある。

ということをお伝えしました。

今回からは、何度かに分けて　注文を出す方法　について解説していきます。

EAとは自動売買プログラムなわけですから、注文を出すプログラムコードをかければ、その時点で「EA(自動売買プログラム)を作れるようになった」とさえ言えるかもしれません。

逆に言えば、今回解説していく部分を中途半端な理解で済ませてしまうと、損失ばかり膨らむ駄目EA(自動売買プログラム)さえ作ることができないということです。

そして、恐らく多くの方がMQL5を勉強していて、苦しんでいるのがこの部分なのではないか？と考えています。

ですが、ご安心ください。

この記事では、世界で最もわかり易く、微に入り細に入り、皆さんを苦しめている

・OrderSend関数

・MqlTradeRequest構造体

・MqlTradeResult構造体

について解説しています。

そして、今回解説する内容を理解する為の前提知識に関するリンクも細かく張り巡らせているので、「聞いたことあるけどなんだっけ？」みたいなモヤモヤを抱かなくても済むような工夫を凝らして執筆しております。

なので安心して、しっかりと一つづつ着実に進めていきましょう👍

OrderSend関数について
MqlTradeRequest構造体について
1. MqlTradeRequest構造体のメンバ構成
まとめ

OrderSend関数について

MQL5でEA(自動売買プログラム)を作るにあたり、注文を出すには、OrderSend関数を使います。

OrderSend関数の引数構成は以下のようになっています。

bool  OrderSend( 
   MqlTradeRequest&  request,     
  MqlTradeResult&   result       
  );

戻り値はトレードサーバーの受入可否

第１引数にはMqlTradeRequest構造体 を、

第2引数には MqlTradeResult構造体を渡します。

MqlTradeRequest構造体 もMqlTradeResult構造体もMQL5側で事前に定義済みの構造体です。

※MqlTradeResult構造体については、今回の記事では触れません。次回に解説予定です。

OrderSend関数の引数に構造体が設定されているという事は、構造体を理解していないと、注文さえままならないということです。

構造体について「なんだったっけ？・・・」という方は↓の記事をご覧ください。

また、MqlTradeRequest構造体とMqlTradeResult構造体のところに&（アンパサンド）がついているのは、引数が参照渡しでOrderSend関数に渡される事を意味しています。

※参照渡しについては覚えていますでしょうか？

参照渡しの場合、関数に渡すのは元のデータのある場所(アドレス)です。

これは渡した関数の処理によって、元のデータが変わる事を意味します。

詳しくは↓の記事をご覧ください。

※併せて値渡しも確認したい場合は↓をご覧ください。

MQL5　ＥＡ講座　第43回「値渡しについて」

ちなみに、MQL4 のOrderSend関数の引数は↓のようになっております。

これに比べると、MQL5の引数はった２つ。なので、人によっては「４に比べて簡単そう(^^♪」

そう思うかもしれません。

が！残念ながら、そんな単純な話でもありません。引数が大幅に変わっているのは、注文の概念自体もMQL4から変わっているからです

そのあたりのことも、これから解説するMqlTradeRequest構造体の中で触れていきたいと思います。

※MQL4のOrderSend関数は戻り値としてチケット番号を返しますが、MQL5のOrderSend関数の戻り値は「トレードサーバーの受入可否」です。 trueだからと言って注文成功を意味しませんので注意しましょう。

注文成功可否はあくまで次回解説するMqlTradeResult構造のリターンコードで確認します。

コンパイル警告回避以外に受皿となるbool型の変数は用意した方がいい気がしますが、今のところ他に有効な利用方法は思いつきません。

MqlTradeRequest構造体について

そもそも、MQL4におけるOrderSend関数は、新規にポジションを持つための要求をトレードサーバーにするだけの機能しかありません。

MQL4において、ポジションの決済やSLTP修正、待機注文の削除などの要求はOrderClose,OrderClose,OrderModify,OrderDeleteなどの別の関数を使って行う必要がありました。

それに対し、MQL5では新規注文・SLTP修正、決済、注文削除等のサーバーへの要求を包括的に「注文」と捉え、MQL4では分散していたOrder～系の関数をOrderSend関数に集約させました。

その代わりMqlTradeRequest構造体にて、サーバーへの要求内容を調整していくことになります。↓

MqlTradeRequest構造体のメンバ構成

MqlTradeRequest構造体のメンバ構成は以下のようになっています↓

struct MqlTradeRequest 
  { 
   ENUM_TRADE_REQUEST_ACTIONS   action;           // 取引の種類 
  ulong                         magic;           // エキスパートアドバイザー ID（マジックナンバー） 
  ulong                         order;           // 注文チケット 
  string                       symbol;           // 取引シンボル 
  double                       volume;           // 約定のための要求されたボリューム（ロット単位） 
  double                       price;           // 価格 
  double                       stoplimit;       // 注文のストップリミットレベル 
  double                       sl;               // 注文の決済逆指値レベル 
  double                       tp;               // 注文の決済指値レベル 
  ulong                         deviation;       // リクエストされた価格からの可能な最大偏差 
  ENUM_ORDER_TYPE               type;             // 注文の種類 
  ENUM_ORDER_TYPE_FILLING       type_filling;     // 注文実行の種類 
  ENUM_ORDER_TYPE_TIME        type_time;       // 注文期限切れの種類 
  datetime                     expiration;       // 注文期限切れの時刻 （ORDER_TIME_SPECIFIED 型の注文） 
  string                       comment;         // 注文コメント
  ulong                         position;         // Position ticket
   ulong                         position_by;     // The ticket of an opposite position 
  };

OrderSend関数の引数は２つ。「２つなら簡単そう(^^♪♪」と一瞬思わせといてのこの所業です・・・。

ただ、一瞬「うわっ」となりますが、よく見ればほとんどがMQL4でも扱っていた項目であることがわかります。

一つ一つゆっくり見ていけば大丈夫です。

ただし、詳細に触れる前に１点だけ。

これも構造体を理解する事と同じ話ですが、

MqlTradeRequest構造体のインスタンスを生成して、そのメンバを呼び出して値を埋め、その集積をOrderSend関数に一括で渡す形式ですから、インスタンスの仕組みも理解している必要があります。

インスタンスについては大丈夫でしょうか？↓

MqlTradeRequest構造体は、定義済み構造体につき、メンバの定義は不要です。

↓の動画のように、インスタンスを生成後は必要に応じて定義済みのメンバを呼び出して、それぞれに適切な値を入力すればＯＫです（適切な値の入力については、これから説明していきます）

MQL4の OrderSend関数のようにの順番に気を配る必要はない反面、それゆえにコンパイルが通っても、入力漏れ等で、正常に売買しない事態が発生しやすいです。

.action →取引の種類を設定するメンバ変数

MqlTradeRequest構造体のインスタンスが呼び出すメンバ変数　 .actionは取引の種類を設定するのに利用します。

先述したように、ポジションの決済やSLTPの修正、待機注文の削除などのMQL4では個別の関数で処理していた要求を、MQL5ではOrderSend関数が一括して行いますから、メンバ変数　.actionにて、それを設定します。

.actionへの値の入力は必須です。

データ型の種類は、ENUM_TRADE_REQUEST_ACTIONSです。

定義済みのEnum列挙型ですね。

Enum列挙型については↓の記事をご参照ください

ちょっと面倒くさいですが、ENUM_TRADE_REQUEST_ACTIONS列挙の定数値を見ていきましょう。

TRADE_ACTION_DEAL→新規成行注文を出す

TRADE_ACTION_DEALは新規成行注文を出すときに メンバ変数 .actionに設定する定数値です。

TRADE_ACTION_DEALはおそらく、メンバ変数 .actionに設定する定数値としては一番使われるものになるでしょう。

※、公式リファレンスにはTRADE_ACTION_DEALのサンプルコードがあり、これを利用することで、メンバ変数の埋め方などの参考にすることができます。

・・・が！現在、実はこれをそのまま実行してもMarket執行方式口座だと売買されません。

理由は フィルポリシーが記述されていない為です。自身で適切なフィルポリシーを記述する必要があります。

TRADE_ACTION_PENDING→新規の待機注文を出す

TRADE_ACTION_PENDINGは、新規の待機注文を出すときにメンバ変数 .actionに設定する定数値です。

※待機注文というのは、成行注文のようにマーケットの現在値でポジションを持つのではなく、特定の価格に到達したらポジションを持つような要求をトレードサーバーにする注文方式です。

※TRADE_ACTION_PENDINGを使って、実際に待機注文を出すコード記述例については、

以下の講座記事を参考にして頂ければと思います。

TRADE_ACTION_ＳＬＴＰ→保有ポジションのSLTPを変更する

TRADE_ACTION_ＳＬＴＰは、現在すでに保有しているポジションの、SL(ストップロス→損切り価格)やＴＰ（テイクプロフィット→利益確定価格）を変更する時に、メンバ変数 .actionに設定する定数値です。

※TRADE_ACTION_ＳＬＴＰを使って、保有ポジションのSLやTPを変更する具体的なコード記述例はこの先の、以下の講座記事を参考にして頂ければと思います↓

TRADE_ACTION_MODIFY→待機注文のパラメータを修正

TRADE_ACTION_MODIFYは、待機注文のパラメータ（指値価格やＳＬ，ＴＰなど）を修正したい時に、メンバ変数　.actionに設定する定数値です。

注意したいのが、先述したTRADE_ACTION_ＳＬＴＰとの違いです。

TRADE_ACTION_ＳＬＴＰはすでに保有しているポジションに対してのＳＬＴＰ変更をしたい時に使うのに対して、TRADE_ACTION_MODIFYは、注文は出したものの、まだ指値価格に到達しておらず、ポジション保有に至っていない待機注文の変更をしたい時に使うものです。

TRADE_ACTION_REMOVE→待機注文を削除する

TRADE_ACTION_REMOVEは、一度出した待機注文を削除する時に、メンバ変数 .actionに設定する定数値です。

.actionにTRADE_ACTION_REMOVEを指定した場合、そのほかに埋めるべきメンバ変数　は、この後解説する.orderだけです。

↓の動画は公式リファレンスにあるTRADE_ACTION_REMOVEのサンプルコードをそのままコンパイルして、待機注文がある状態のデモ口座に適用した様子です。

待機注文が削除されているのがお分かりいただけたかと思います。

この先の講座記事↓

・MQL5　ＥＡ講座　第67回「待機注文の削除」

TRADE_ACTION_CLOSEBY→両建てポジションを同時決済する

TRADE_ACTION_CLOSEBYは、Buy(買い)ポジションとSell(売り)ポジションを両建てで保有している時に、その両方を同時に決済したい時に、メンバ変数　.actionに設定する定数値です。

MQL5になってから追加された新機能です。反対方向にポジションを保有する事ができないネッティングシステム口座では使いません。

↓の動画は公式リファレンスのCLOSEBYサンプルコードを拝借して、その挙動を試したものです。BuyとSellが同時に決済されているのがわかります。

.magic →マジックナンバーを設定するメンバ変数

MqlTradeRequest構造体のインスタンスが呼び出すメンバ変数　.magicは

マジックナンバーを入力・設定するのに使います

※メンバ変数　.magicのデータ型を見ると　ulong となっています。

ulong は覚えていますでしょうか？

簡単に言うと　int型と同じく整数型ではありますが、負の値は保有することができず、正の方向にint型より大きな値を所持できるデータ型です。詳しくは↓の記事をご覧ください。

マジックナンバーとは？

マジックナンバーとはEA(自動売買プログラム)固有の識別番号です。

１つのメタトレーダー5(MT5)で複数のEA(自動売買プログラム)を運用する時、保有しているポジションやオーダーがどのEA(自動売買プログラム)に由来するものかをえり分けるための番号となります。

.magicへのマジックナンバー記述は必須ではありません。ただし、１つのメタトレーダー5(MT5)で複数のEA(自動売買プログラム)を運用する時は、誤動作を招く可能性があるため設定する必要があります。

↓の動画は、.magic部分を最初はコメントアウトし、注文→その後コメントアウトを削除して再度注文を出しなおしたものです。

.magicをコメントアウトして無効化しても注文自体はできていますね。

※マジックナンバーはinput変数でパラメータ化しておくと便利です。

input変数については↓の記事をご覧ください。

.order →待機注文のチケット番号を入力・設定する。

MqlTradeRequest構造体のインスタンスが呼び出すメンバ変数　.orderは、

待機注文のオーダー番号を入力・設定するのに使います。

オーダー番号は、待機注文のSLTP等を修正したり、待機注文自体を削除したりするときに使います。

従って、メンバ変数　.actionで指定した取引種類が

TRADE_ACTION_MODIFY（待機注文内容を修正する）

または

TRADE_ACTION_REMOVE（待機注文を削除する）

の時は入力が必須になります。

オーダー番号とは？

オーダー番号とは、注文ごとに与えられる認識番号です。「どの注文に対して、指定した処理を施すのか？」を選り分ける為に使われます。

オーダー番号は、

OrderGetTicket関数を使う、

OrderGetInteger関数を使い、引数に　ORDER_TICKETを設定する

などの方法で取得します。

オーダー番号と、

この後出てくる　.positionの項で解説予定のポジション番号との違いには注意が必要です。

オーダー番号はまだ有効化していない待機注文も含めて「注文」単位に割り振られる番号で、

ポジション番号はすでに保有しているポジションに対して割り振られる番号です

（また、心苦しいのですが、次回のMqlTradeResult構造　では、約定番号（ディール番号）という新キャラも登場します(-_-;) )

※OrderGetTicket関数についての詳細は↓の記事をご参照ください

.symbol →取引銘柄を設定する。

MqlTradeRequest構造体のインスタンスが呼び出すメンバ変数　.symbolは、

取引銘柄を設定する時に使います。

例えばユーロドルに対して処理を実施したいのであれば、”EURUSD”のように記述します。

EA(自動売買プログラム)をチャートに挿入した銘柄に対して処理を実施したいのであれば、定義済み変数の_Symbolを使います。

メンバ変数　.symbolへの値入力は必須です。

※定義済み変数については→コチラ

.Volume →取引数量（ロット）を設定する。

MqlTradeRequest構造体のインスタンスが呼び出すメンバ変数　.Volumeは、

取引数量（ロット）を設定する時に使います。

メンバ変数　.Volumeへの値入力は必須です。

.Price →ポジションを保有する価格の設定をする

MqlTradeRequest構造体のインスタンスが呼び出すメンバ変数　.Price は、

ポジションを保有する価格の設定をする時に使います。

成行注文の時は現在のAsk値（買い注文の時）、かBid値(売り注文の時)しか指定できません。

EA(自動売買プログラム)を運用する口座がMarket執行方式か、Exchange執行方式　の場合、成行注文(=TRADE_ACTION_DEAL)の時は、メンバ変数　.Priceへの入力は必須ではありません。（リクオートが発生しないので、必要がないということでしょう）

↑の動画を見てもわかるように、後半、.Priceをコメントアウトした後でも特に問題なく注文は約定はしていますね、

待機注文の時は、現在値より上か下の価格を、自分の希望で決めて入力します。

※待機注文時、ストップレベルに抵触しないようにする必要はあります。ストップレベルについては講座記事78回、79回、80回で解説予定なので、もうしばらくお待ちください。

ここまでの説明を言い換えれば、

Market執行方式か、Exchange執行方式以外の執行方式における成行注文(=TRADE_ACTION_DEAL)
TRADE_ACTION_PENDING
TRADE_ACTION_MODIFY

の時は、.Priceへの入力は必須ということです。

※成行注文の執行方式についての詳細は↓をご覧ください

.stoplimit →stoplimit待機注文のリミット価格を設定する

MqlTradeRequest構造体のインスタンスが呼び出すメンバ変数　.stoplimitは

stoplimit待機注文のリミット価格を設定する時に使います。

stoplimit待機注文はMQL5から追加された注文方式で

ストップとリミットを両方設定します。ブレイクアウト後少し戻すことを想定した待機注文です。↓

現在値の500ポイント上に逆指値注文（Stop注文）を入れ、もし逆指値注文（Stop注文）に到達したら、現在値の300ポイント下に指値注文(Limit注文)でポジションをとるようなスクリプトの挙動です。

この時、

メンバ変数　.Priceには逆指値注文（Stop注文）を入れ、

メンバ変数　.stoplimitには指値注文(Limit注文)を入れます。

メンバ変数　.Priceに入れた価格は「その価格に到達したらポジションを保有する」性質のものではなく、メンバ変数　.stoplimitに入れた指値注文(Limit注文)を有効化させるためのトリガーになっています。

メンバ変数　.Priceに入れた価格に到達すると注文タイプがbuy stop limit→buylimitに変わります。

待機注文なので、

メンバ変数　.actionにはTRADE_ACTION_PENDINGが、

この後間もなく解説するメンバ変数　.type には

ORDER_TYPE_BUY_STOP_LIMITかORDER_TYPE_SELL_STOP_LIMITが入ります。

言うまでもなく、stoplimit待機注文を出す場合には、メンバ変数　.stoplimitへの値入力は必須です。

.sl →ストップロス（損切り価格）を設定する

MqlTradeRequest構造体のインスタンスが呼び出すメンバ変数　.sl は、

ストップロス（損切り価格）を設定する時に使います。

執行方式がinstant執行方式、またはRequest執行方式の場合、成行注文時にメンバ変数　.sl への値入力は必須です。

第58回「成行注文と執行方式について」でも書いたことですが、MQL5を学習した時期によっては、「market執行方式においては発注時にストップロスとテイクプロフィットの設定はできない」

という認識の人もいるかもしれませんが、現在はmarket執行方式でも成行注文時、ストップロスとテイクプロフィットの設定はできます。

.tp →テイクプロフィット（利益確定価格）を設定する

MqlTradeRequest構造体のインスタンスが呼び出すメンバ変数　.tpは、

テイクプロフィット（利益確定価格）を設定する時に使います。

執行方式がinstant執行方式、またはRequest執行方式の場合、成行注文時にメンバ変数　.tpへの値入力は必須です。

.deviation →スリッページを設定する

MqlTradeRequest構造体のインスタンスが呼び出すメンバ変数　.deviation は、

スリッページを設定する時に使います。

※スリッページとは、発注後に激しく価格が変動した局面において、現在値と発注前のレートとの乖離がどれくらいまでなら取引を許容するか、という設定値です。

執行方式がinstant執行方式、またはRequest執行方式の場合、成行注文時にメンバ変数　.deviation への値入力は必須です。

.type →オーダー種類を設定する

MqlTradeRequest構造体のインスタンスが呼び出すメンバ変数　.type は、

オーダー種類を設定する時に使います。

メンバ変数　.type のデータ型は、定義済みEnum列挙型である　ENUM_ORDER_TYPE　です。

ENUM_ORDER_TYPEの定数値は以下の通りです。↓

ORDER_TYPE_BUYは成行買い注文のこと

ORDER_TYPE_BUYは成行買い注文のことです。現在のAsk値でポジションを持つよう要求します。

成行注文なので、

メンバ変数　.action には　TRADE_ACTION_DEALが入ります。

メンバ変数　.Priceには現在のAsk値を入れます。Ask値の取得にはSymbolInfoDouble関数を使います。第2引数に　SYMBOL_ASK　を記述します。

request.action   =TRADE_ACTION_DEAL; 　　　　　　　　　　　//　取引操作タイプ
request.type     =ORDER_TYPE_BUY;                       // 注文タイプ
request.price    =SymbolInfoDouble(Symbol(),SYMBOL_ASK); // 発注価格

ORDER_TYPE_SELLは成行売り注文のこと

ORDER_TYPE_SELLは成行売り注文のことです。現在のBid値でポジションを持つよう要求します。

成行注文なので、

メンバ変数　.action には　TRADE_ACTION_DEALが入ります。

メンバ変数　.Priceには現在のBid値を入れます。Bid値の取得にはSymbolInfoDouble関数を使います。第2引数に　SYMBOL_BID　を記述します。

request.action   =TRADE_ACTION_DEAL; 　　　　　　　　　　　//　取引操作タイプ
request.type     =ORDER_TYPE_SELL;                       // 注文タイプ
request.price    =SymbolInfoDouble(Symbol(),SYMBOL_BID); // 発注価格

ORDER_TYPE_BUY_LIMITは買い指値注文のこと。

ORDER_TYPE_BUY_LIMITは買い指値注文のことです。現在値よりも有利な価格（＝安く）でポジションを持つよう要求します。

待機注文なので、

メンバ変数　.action には　TRADE_ACTION_PENDINGが入ります。

メンバ変数　.Priceには希望する価格が格納されるよう記述します。

request.action   TRADE_ACTION_PENDING; 　　　　　　　　　　　//　取引操作タイプ
request.type     =ORDER_TYPE_BUY_LIMIT;                       // 注文タイプ
request.price    =希望する価格が格納されるような記述をする; // 発注価格

ORDER_TYPE_SELL_LIMITは売り指値注文のこと。

ORDER_TYPE_SELL_LIMITは売り指値注文のことです。現在値よりも有利な価格（＝高く）でポジションを持つよう要求します。

待機注文なので、

メンバ変数　.action には　TRADE_ACTION_PENDINGが入ります。

メンバ変数　.Priceには希望する価格が格納されるよう記述します。

request.action   TRADE_ACTION_PENDING; 　　　　　　　　　　　//　取引操作タイプ
request.type     =ORDER_TYPE_SELL_LIMIT;                       // 注文タイプ
request.price    =希望する価格が格納されるような記述をする; // 発注価格

ORDER_TYPE_BUY_STOPは買い逆指値注文のこと。

ORDER_TYPE_BUY_STOPは買い逆指値注文のことです。現在値よりも不利な価格（＝高く）でポジションを持つよう要求します。

※逆指値注文は、指定した価格の方向へ、そのままトレンドが形成されることを想定した注文方法になります。

待機注文なので、

メンバ変数　.action には　TRADE_ACTION_PENDINGが入ります。

メンバ変数　.Priceには希望する価格が格納されるよう記述します。

request.action   TRADE_ACTION_PENDING; 　　　　　　　　　　　//　取引操作タイプ
request.type     =ORDER_TYPE_BUY_STOP;                       // 注文タイプ
request.price    =希望する価格が格納されるような記述をする; // 発注価格

ORDER_TYPE_SELL_STOPは売り逆指値注文のこと。

ORDER_TYPE_SELL_STOPは売り逆指値注文のことです。現在値よりも不利な価格（＝安く）でポジションを持つよう要求します。

待機注文なので、

メンバ変数　.actionには　TRADE_ACTION_PENDINGが入ります。

メンバ変数　.Priceには希望する価格が格納されるよう記述します。

request.action   TRADE_ACTION_PENDING; 　　　　　　　　　　　//　取引操作タイプ
request.type     =ORDER_TYPE_SELL_STOP;                       // 注文タイプ
request.price    =希望する価格が格納されるような記述をする; // 発注価格

ORDER_TYPE_BUY_STOP_LIMITは買いのストップリミット待機注文のこと。

ORDER_TYPE_BUY_STOP_LIMITは買いのストップリミット待機注文のことです。

ストップリミット待機注文がどのような注文方法であるか、という事はメンバ変数 .stoplimitの項で説明をしました。

価格がブレイクアウトした後、長期的にはブレイクアウトした方向に向かうが、若干押し目をつくるという想定をしている時に利用する注文方法になります。

待機注文なので、

メンバ変数　.actionには　TRADE_ACTION_PENDINGが入ります。

メンバ変数　.Priceには希望するストップ注文価格が格納されるよう記述します。この価格でポジションを保有する訳ではないので注意しましょう。

メンバ変数　.stoplimitには希望するリミット価格が格納されるよう記述します。この価格でポジションを保有します。

.Priceに格納されている価格に到達する事がトリガーとなって、.stoplimitに格納されている価格のリミット買い注文が発動するイメージです。

request.action   TRADE_ACTION_PENDING; 　　　　　　　　　　　//　取引操作タイプ
request.type     =ORDER_TYPE_BUY_STOP_LIMIT;                       // 注文タイプ
request.price    =希望するストップ価格が格納されるような記述をする; // ストップ注文価格
request.stoplimit==希望するストップ価格が格納されるような記述をする; // リミット注文価格

ORDER_TYPE_SELL_STOP_LIMITは売りのストップリミット待機注文のこと。

ORDER_TYPE_SELL_STOP_LIMITは売りのストップリミット待機注文のことです。

メンバ変数　.actionには　TRADE_ACTION_PENDING、

メンバ変数　.Priceには希望するストップ注文価格、

メンバ変数　.stoplimitには希望するリミット価格、

をそれぞれ入力します。

request.action   TRADE_ACTION_PENDING; 　　　　　　　　　　　//　取引操作タイプ
request.type     =ORDER_TYPE_SELL_STOP_LIMIT;                       // 注文タイプ
request.price    =希望するストップ価格が格納されるような記述をする; // ストップ注文価格
request.stoplimit=希望するストップ価格が格納されるような記述をする; // リミット注文価格

ORDER_TYPE_CLOSE_BYは両建て状態のポジション決済注文のこと？

ORDER_TYPE_CLOSE_BYは両建て状態のポジション決済注文に使われる・・・と思われるのですが、.action,.position,.position_byメンバが適切に埋まっていれば.type にこれがなくても作用しており、2017のMT5アップデートで実装された定数ですが、2023年9月現在正直よくわかりません(-_-;)

CLOSE_BY注文については

メンバ変数　.actionの定数値TRADE_ACTION_CLOSEBYの項でも出てきました。詳しくはそちらを参照してください。

メンバ変数　.actionにTRADE_ACTION_CLOSEBYが入力されている時は、

取引種類をCLOSE_BYにしているわけですから、

メンバ変数　.type に入力するのは必然的にORDER_TYPE_CLOSE_BYとなって、↓

request.action   TRADE_ACTION_CLOSEBY; 　　　　　　　　　　　//　取引操作タイプ
request.type     =ORDER_TYPE_CLOSE_BY;                       // 注文タイプ
request.position＝決済するポジションチケット番号
request.position_by＝反対決済するポジションチケット番号

↑のようなセッティングをするのかな？とも思ったのですが、メンバ変数　.type にこの定数値を入力していなくても現状CLOSE_BY注文は成立するのでは？というのが現時点での、私の理解です。

なにぶんORDER_TYPE_CLOSE_BYについては公式リファレンスも含めて、ほとんど情報がない為、今後も検証・注視していきたいと思います。

↑のサンプルコードで出てきたメンバ変数　.positionと.position_byについてはこの後解説をします。

.type_filling →フィルポリシーを設定する

MqlTradeRequest構造体のインスタンスが呼び出すメンバ変数　.type_filling は

フィルポリシーを設定する時に使います。

フィルポリシーとは、流動性が極端に低下する等の事情で、発注した量のロット数では約定できないときの対応方法

を指します。

フィルポリシーについての詳細は↓の記事をご覧ください↓

.type_fillingに入力する値は、ENUM_ORDER_TYPE_FILLING列挙で定められたものになります。

ORDER_FILLING_FOK→FOKポリシーを設定する

ORDER_FILLING_FOKはFOKポリシーを設定するのに使います。

FOKポリシーは発注した後、指定したロット数でのオーダーをサーバーが受け付けられないときは注文自体がキャンセルになる、というフィルポリシーです。

※どのフィルポリシーを選択すればよいのかは、執行方式によって変わります。

コチラの→フィルポリシーの確認方法をご参照ください。

ORDER_FILLING_IOC→IOCポリシーを設定する

ORDER_FILLING_IOCは、IOCポリシーを設定するのに使います。

IOCポリシーは、指定したロット数でのオーダーをサーバーが受け付けられないとき、約定可能なロット分だけ約定させ、残りはキャンセルとなるフィルポリシーです。

例えば、1.0ロットの発注を出したとして、市場の流動性低下の問題から、1.0ロットの約定ができないけど、0.5ロット分なら約定可能な場合、0.5ロット分だけ約定し、残り0.5ロット分はキャンセルとなります。

※どのフィルポリシーを選択すればよいのかは、執行方式によって変わります。

コチラの→フィルポリシーの確認方法をご参照ください。

ORDER_FILLING_RETURN→RETURNポリシーを設定する

ORDER_FILLING_RETURNは、RETURNポリシーを設定するのに使います。

RETURNポリシーは、指定したロット数でのオーダーをサーバーが受け付けられないとき、約定可能なロット分だけ約定させ、残りの約定できなかったロット分も継続して注文処理を行うフィルポリシーです。

例えば、1.0ロットの発注を出したとして、市場の流動性低下の問題から、1.0ロットの約定ができないけど、0.5ロット分なら約定可能な場合、0.5ロット分だけ約定し、残り0.5ロット分も約定できるように追尾処理を行う仕組みになっています。

※どのフィルポリシーを選択すればよいのかは、執行方式によって変わります。

コチラの→フィルポリシーの確認方法をご参照ください。

.type_time→注文の有効期限を設定する

MqlTradeRequest構造体のインスタンスが呼び出すメンバ変数　.type_timeは、

.type で設定した注文の有効期限を設定する時に使います。

.type_timeに設定するのは、ENUM_ORDER_TYPE_TIME で定められた値です。

.type_timeに何も指定しない場合、初期値である　ORDER_TIME_GTC（有効期限なし）

が適用されます。

ORDER_TIME_GTC→有効期限なし

ORDER_TIME_GTCのGTCは(Good Till Cancel)の略です。

直訳すれば「キャンセルするまでは有効」

即ち、ORDER_TIME_GTCに設定した場合、その待機注文は有効期限がない、という事になります。

ORDER_TIME_DAY→待機注注文が出された取引日中のみ有効

ORDER_TIME_DAYは、待機注注文が出された取引日中のみ有効、という設定です。

メンバ変数　.type_timeにORDER_TIME_DAYを設定した場合、待機注文が出された取引日中に、注文が有効化しなければ、その待機注文は削除されます。

↑の動画は、動画は、待機注文の期限を注文修正によってORDER_TIME_GTC（有効期限なし）からORDER_TIME_DAY（当日中）に変えた物です。 注文修正プログラム実行後、注文プロパティを見ると「無期限」→「当日中」になっているのがわかると思います。

ORDER_TIME_SPECIFIED→指定した特定の期限まで有効

ORDER_TIME_SPECIFIEDは、指定した特定の期限まで有効、という設定です。

メンバ変数　.type_timeにORDER_TIME_SPECIFIEDを設定した場合、この後出てくるメンバ変数　.expirationにて有効期限を指定する必要があります。

従って、ORDER_TIME_SPECIFIED設定の場合、メンバ変数　.expirationへの値入力は必須となります。

※.expirationへの明示的な値入力がない場合、ORDER_TIME_GTC（有効期限なし）となります。

↑の動画を見ると、ORDER_TIME_SPECIFIEDも、ORDER_TIME_SPECIFIED_DAYにと同様、.expirationへの明示的な値入力がない場合、無期限のままになっています。

日付を202210/1/18:00と明示した上でプログラムを再度実行すると、今度は有効期限が変わったのがわかると思います。

ORDER_TIME_SPECIFIED_DAY→指定した特定の期日の23：59まで有効

ORDER_TIME_SPECIFIED_DAYは、指定した特定の期日の23：59まで有効　という設定です。

ORDER_TIME_SPECIFIEDは日にち以降の時間分秒まで設定できますが、ORDER_TIME_SPECIFIED_DAYの場合は指定するのは日にちまで、ということです。

メンバ変数　.type_timeにORDER_TIME_SPECIFIED_DAYを設定した場合もメンバ変数　.expirationへの値入力は必須となります。

※.expirationへの明示的な値入力がない場合、ORDER_TIME_GTC（有効期限なし）となります。

↑の動画ですが、注文修正時、ORDER_TIME_SPECIFIED_DAYにしているにも関わらず、メンバ変数　.expirationへの明示的な値入力がなかった為、最初有効期限が変わっていません。日付を202210/1と明示した上でプログラムを再度実行すると、今度は有効期限が変わったのがわかると思います。

.expiration→有効期限の時刻を設定する

メンバ変数　.type_timeにORDER_TIME_SPECIFIED、もしくはORDER_TIME_SPECIFIED_DAYを設定していた場合、待機注文の具体的な有効期限を設定する必要があります。

メンバ変数　.expirationは有効期限の時刻を設定するのに使います。

メンバ変数　.type_timeにORDER_TIME_SPECIFIED、もしくはORDER_TIME_SPECIFIED_DAYを設定していた場合、.expirationへの値入力は必須です。

.expirationへの値入力をする際はdatetime型の値を入力しますので、「datetime型って何？」という方は↓の記事をご参照ください。

.comment→注文コメントを設定する

メンバ変数　.commentは、注文コメントを設定する時に使います。

注文コメントというのは、注文を出したときに、MT5のツールボックスに表示されるコメント欄の事です。↓

コメントを残すので、必然的に入力データは文字列であるstring型になります。

メンバ変数　.commentへの入力は必須ではないので、省略可能です。

.position→ポジション番号を設定する

メンバ変数　.positionはポジション番号を設定するのに使います。

ポジション番号とは？

ポジション番号というのは、保有している各ポジションに割り振られている固有の番号です。

ポジションを決済したり、ポジションに設定されている注文内容を変更する時などに利用します。

・PositionGetTicket関数を使う。

・PositionGetInteger関数を使い、引数にPOSITION_TICKETを設定する

などの方法で取得します。

※メンバ変数　.orderの項でも言及しましたが、

このポジション番号と、

メンバ変数　.orderのところで出てきたオーダー番号を

混同しないよう注意してください。

大事なことなのでもう一度書きますが、

オーダー番号は、まだ有効化していない待機注文も含めて「注文」単位に割り振られる固有の番号で、

ポジション番号は、すでに保有しているポジションに対して割り振られる固有の番号

になります。

ただ、成行注文でポジションを持った場合はオーダー番号とポジション番号は同じ番号になります。

じゃあ、待機注文の時はどうなるのか？というと、ポジションが有効化していないうちはポジション番号は０になっています。ポジションが有効化した時点でオーダー番号に付与されていた番号がポジション番号に付与されます。

.position_by→close_by決済における反対ポジションのポジション番号を設定する

メンバ変数　.position_byはclose_by決済における、反対ポジションのポジション番号を設定する時に使います。

従って、メンバ変数　.actionにTRADE_ACTION_CLOSEBYが入力されている場合は、.position_byへの値入力は必須です。

close_by決済はbuy と　sell両建てで所有しているポジションを両方決済しようという処理ですから、

メンバ変数　.positionのポジション番号のポジション方向が仮にbuyだとしたら、.position_byにはポジション方向がsellのポジション番号を格納することになります。

ポジション番号の取得方法は、.positionの時と同じくPositionGetTicket関数やPositionGetInteger関数を使います。

まとめ

今回は　OrderSend関数とMqlTradeRequest構造体　について解説しました。

今回の記事では以下のことを学びました

MQL5でEA(自動売買プログラム)を作るにあたり、注文を出すには、OrderSend関数を使う。

MQL4におけるOrderSend関数は、新規にポジションを持つための要求をトレードサーバーにするだけの機能しかなかったが、MQL5のOrderSend関数は新規注文・SLTP修正、決済、注文削除等の要求を包括的に「注文」とみなし、トレードーサーバに送信する役割を担っている。