MQL5 および MQL4での売買ロボット注文法

28 10月 2015, 13:04
MetaQuotes Software Corp.
0
2 826

 

MetaTraderにおける自動トレーディング

MetaTrader トレーディングターミナルの主なメリットは、トレーダーの干渉なしにトレーディング処理を行うことによりトレード結果に対する心理的影響を排除することのできる自動トレーディングシステムを作成する能力です。これにはトレーディング戦略を策定し、それを MQL 言語でプログラム形式で実装する必要があります。また、マーケットの標準的なテクニカルインディケータ以外に自身のインディケータを作成し、それをトレーディングターミナル内で視覚化することができます。

 

トレーディングプログラム記述

ただ、すべてのトレーダーがプログラマーというわけではないため、フォーラムでは「プログラマー求む」といったような掲示をよく見かけます。数多くのプログラマーが MQL 言語で Expert Advisors やインディケータを書くといったサービスを提供しています。他者のためにトレーディング用 Expert Advisors を書くことにはある種の特異性が求められます。アルゴリズムは判りやすく形式化されている必要があります(注文に向けて作成される Expert Advisor 。トレーダー用マニュアルを参照ください)。そうでなければ注文者は期待しているものを入手できなかったり、誤解を生んだりすることになるかもしれません。

契約の両側にいる者(注文者とソリューションを実装するプログラマー)はそういった不愉快な要因を減らしたいと思っています。プログラマーは確かにタスクが明確に定式化され、受け入れられ、遅延なく支払いが行われることを望んでいます。一方注文者は、希望の時間内に指定のボリュームで仕事が行われることを必要としています。周知のように最良の広告は口コミです。適任プログラマーリスト(ロシア語)についてはフォーラムで定期的に話し合われます。そこでこれを一か所に集約しようとしました。

 

MQL5.comの「ジョブ」セクション

MQL5.community「ジョブ」 サービスと、類似リソースの多くとそのウェブサイトにおけるサービスの違いは安全性です。注文者とプログラマーは、全協業期間中お互いの不注意な行いから守られています。もめごとが起こった場合は MetaQuotes Software Corp. 調停者としての役割をすることになっています。

購入者として、このタスクを喜んで引き受けてくれるプログラマーをすでに見つけていたとしても、この新サービスを利用することを推奨します。なぜなら事前の話し合いで見過ごされがちな細かい点を数多くこのサービスが提供するからです。また、逆にプログラマーとして自動売買システム、インディケータ、スクリプトのプログラムに対して指定された金額での提案を受けていたとしても同じです。注文者との関係を最大限正式なものとし、プロジェクトを単一の共通基準で行うためには「ジョブ」セクションに注文者が新規注文の同意書を提出するよう提案することができます。

本稿ではタスクの広告を掲載し、それを遂行するための「ジョブ」サービス利用法について話していきます。

 

1. 新規ジョブ作成

Expert Adviser 作成の注文を出すには、「ジョブ」セクションに行き「新規」を選択します。

図1 新規ジョブ作成

図1 新規ジョブ作成

こののち、タスクの詳細を指定することができるようになります。

図2 タスク編集

図2 タスク編集

  • 名前 (完了される必要のあるタスクの簡潔な情報)
  • 価格または見積もり料金 (米ドルにて指定)
  • 期間または仮の時間枠 (日数にて指定)
  • カテゴリー(タスクのカテゴリーを1つあるいは2つ指定)インディケータ、エキスパート、ライブラリ、スクリプト、インテグレーション、その他
  • 内容 タスクの基本情報。この段階では要求仕様詳細は不要です。

あらゆるビジネス同様、現実的である必要があります。報酬について細かい指定をし過ぎるとタスク実現に対して提案を一つも得られない、またはクオリティーの低い提案を受け取ることになるという危険があります。タスクがどの程度込み入ったものか判断できず、よってコストについてまだ決断できなければ、金額を指定するのを延期することもできます。

「カテゴリー」セクションで、タスクのカテゴリーを1つか2つ(それ以上にはならない)指定するよう求められます。指定したら「適用」をクリックします。

図3 ジョブカテゴリー

図3 ジョブカテゴリー

われわれの場合、ジョブはExpert Advisor を書くことです。よってカテゴリーExpert Advisorを選択します。

この後「新規」セクションでタスク遂行の注文を確認し、さらにこの注文が全 MQL5 ユーザーに向けた「ジョブ」セクションに表示されているのを確認します。

図4 タスク発注

図4 タスク発注

最初のステップは終了しました。ここからはだれかが注文を取るのを待って、注文に関する質問に備えるだけです。

 

2. ジョブ実行に対するオーダー処理

ジョブを引き受ける意欲を注文者に伝えるために、志望者はそのジョブ実施に応募する必要があります。

図5 タスク発注

図5 タスク発注

現在のタスク注文はMQL5.communityメンバー全員から閲覧されます。応募者によりオーダーが提出されるとそれは「未処理」カテゴリーに入ります。

注文を取るつもりがあれば、応募内容に追加情報を指定することができます。それはご自身が適任な開発者であることを示すものとなります。その情報はご自身の記事「コードベース」に発表されたスクリプト、ジョブポートフォリオへのリンクであったりするでしょう。そういった情報により注文者はみなさんについてよりよい理解を得、よってみなさんについて有利な判断がされるのに役立つわけです。

重要点:みなさんの応募においては最初のメッセージのみ公に閲覧が可能であり、それ以外の注文者と応募者間コミュニケーションは非公開となり、両者にのみアクセス可能です。

ジョブに新規メッセージがあれば、ジョブにおける更新情報を通知するカバン型アイコンが表示されます。

図6 ジョブの更新情報

図6 ジョブの更新情報

カバン型アイコンをクリックし新規メッセージを確認します。

その後注文者が行うことはジョブ実施への応募を処理することです。それは応募を「選択済み」「候補者」「落選」などのカテゴリーに移動することです。

図7 ジョブ参加候補者からの応募リスト

図7 ジョブ参加候補者からの応募リスト

ジョブに対する適任者は「候補者」グループに入れ、その人達とジョブ詳細について話し合いを進めることができます。

応募者が候補者グループに入れられると、その人達には候補者グループに入ったことが知らされ、以下のメッセージが各注文に分類されます。

重要:注文の注釈書によってこの段階だけでなくその後もできる限りお互いにコミュニケーションを取るようにします。往々にして人はまったく同じ言葉に異なった解釈をするものです。行程中お互いに質問を投げ合うほど、結果はより良いものとなります。.

注文者がジョブ実行に関して最適な応募者を決めると、応募情報は「選択済み」カテゴリーに移動する必要があります。

図8 ジョブ請負者の選択

図8 ジョブ請負者の選択

重要:現在の注文以外に別の注文を選択する場合は、前回選択された注文は選択済みカテゴリーから消去されます。 

この例では、注文者 Alexander_Demidov がユーザー Mikhail_Antonov および Greg_Maltsev のオーダーを候補者グループに入れました。ユーザー Mikhail_Antonov のオーダーは「選択済み」カテゴリーに移動します。注文が「選択済み」カテゴリーに転送されることは注文者がタスクに関する請負者を選択したことを示します。

いまいちど、「選択済み」カテゴリーには1応募者からのオーダーのみが存在可能であることに注意することが必要です。この時点で提案されているジョブに関する疑問は全て解くようにします。次の段階に進む前にお互いにやりとりしたメッセージを再読することが望まれます。

 

3. ジョブの実行

ジョブ実行プロセスには6ステップあります。最初の5ステップ経過は注文者および請負者が確認します。

最終ステップ、ジョブ完了への支払いは自動的に行われます。

注文者および請負者の各ステップにおける行動は表1に簡潔に述べられています。

ステップ 名前 注文者の対応 請負者の対応
1 作業同意 ジョブ遂行に対する請負者の選択を確認する ジョブ遂行に対する同意書を確認する
2 交渉要件 請負者に技術仕様書を提供する
最終料金およびジョブ開始時期を確認する
最終的技術仕様書、価格、ジョブ開始時期を確認する
3 プロトタイプ/モデル 提出された資料を理解する。変更や修正が必要であれば、請負者は提出されたモデルにコメントを入れる。その際変更理由を示し、自身のモデルの変更バージョンを提供する。

要求されるプロトタイプまたはモデルを取得したら、注文者は提案のプロトタイプまたはモデルを承認する
ジョブのプロトタイプまたはモデルを提供し、資料の条項を確認する

注文者の要求により請負者はプロトタイプまたはモデルに変更を加える
4 デモンストレーション 作業資料の受け取りにあたり、提出された未導入の技術仕様リストで注文者は提出資料がオーダーの性質に応じたものか確認するかまたはオーダーを却下する すべての技術仕様パラメータが取り入れられていれば請負者はジョブのデモを見せ、注文者が完成したソリューションを受けることを確認する。
5 作業承認 提出された資料を検証し、ジョブ承認を行う。 注文者にジョブを提供し、ジョブが提出されたことを確認する。
6
支払い 注文者がジョブを承認したら、システムは自動的に注文者のアカウントから請負者のアカウントに支払いを転送

表1 各ステップにおける注文者と請負者の対応

詳細の話し合いおよび資料交換は該当タスクに関するメッセージの形で行います。

注意! 重要なメッセージはすべて注釈の形式で残すことを忘れないようにします。すでにチャット、個人メッセージ、口頭でなどコミュニケーションの別の手段でそういった事柄について話し合い済みであってもです。つねに同意に至った内容については注釈に直接掲示されるメッセージの形で確保しておきます。

 

3.1ステップ1:作業同意

特定の請負者と作業を開始することを確認するには、注文者は選択したジョブオーダーを「選択済み」カテゴリーに入れ、オーダーの記載者との合意を確定する必要があります。

図9 請負者選択確認

図9 請負者選択確認

このあと、話し合いにおいてステップ『作業同意書』の確認をします。

図10 注文者による『作業同意書』ステップの確認

図10 注文者による『作業同意書』ステップの確認

注文者による『作業同意書』ステップの確認後、開発者は以下のプッシュ通知を受け取ります。

ジョブ:注文者 Alexander_Demidov は『作業同意書』を確認しました。

プッシュ通知を受け取るためには MQL5.community プロフィールでMetaquotes ID を指定する必要があります。プッシュ通知については メタトレーダーモバイル端末におけるMetaQuotes ID を参照ください。

ステップを通過するごとに注文者、請負者双方ともそのようなプッシュ通知を受け取ります。

請負者はまたジョブ遂行に対する同意書も確認する必要があります。

図11 請負者による『作業同意書』ステップの確認

図11 請負者による『作業同意書』ステップの確認

請負者がジョブ遂行同意書を確認したら、作業同意書は完成です。

図12 二者により確認された『作業同意書』ステップ

図12 二者により確認された『作業同意書』ステップ

図11にあるように、今、ステップ『作業同意書』は薄緑色で表示されています。これはステップが完了したことを示します。

注文者と請負者は技術仕様の詳細、最終料金、実装の仮の期間について交渉を続けます。

注文者は技術仕様書の最終バージョンが承認されて初めて次のステップに進みます。

 

3.2 ステップ2:要件交渉

要件交渉はその後の協力関係について重要なステップです。今後のソリューションの細かい内容をすべて話し合います。答えが判っている場合でも、質問をします。結局、よくある問題は理解不足です。片方がある事柄について明白で、解りきったことだろうと思っても、片方は同じように受け取っていない、というものです。そのように両者にとって特定の要因の重要性が異なるため、適切に処理されない場合があるのです。

図13 Expert Advisorへの要件

図13 Expert Advisorへの要件

要件について話し合う時、その内容を許可された範囲でファイルとしてコメントに添付することもできます。

図14 ジョブ協議中の要件添付

図14 ジョブ協議中の要件添付

技術仕様の各項目は明確に理解する必要があります。提示されたプロトタイプ、デモ、遂行されたジョブを転送する形式の指示を忘れないことです。

ステップ2を確認する前、注文者は添付として要件の最終リストを提示します。 要件は全て指定する必要があります。必要であれば、画像を用いて要件を提示することも可能です。

注文者は技術仕様の最終バージョンを提示し、報酬額、条件、ジョブ締切を決定します。

図15 注文者による技術仕様確認とジョブの最終料金承認

図15 注文者による技術仕様確認とジョブの最終料金承認

請負者は技術仕様の条件およびジョブの最終報酬額に同意します。

図16 請負者による技術仕様確認とジョブの最終料金承認

図16 請負者による技術仕様確認とジョブの最終料金承認

両者による技術仕様の確認にはオーダーの全要件が含まれます。

既定のステップにおける確認はすべてのジョブが技術仕様書の最終バージョンを順守して行われることを示しています。書面または口頭によるその他の事前同意は、技術仕様書に記載がなければ、問題や苦情を判定する際考慮されません。

『要件交渉』ステップが両者によって確認されたら、議論の中に以下のようなメッセージが表示されます。

図17 『要件交渉』ステップの確認

図17 『要件交渉』ステップの確認

『要件交渉』ステップ完了後、ジョブ議論のあらゆる注釈を変更することができます。変更が必要な場合には、必要な変更を詳細に記述した新規メッセージを送信します。

 

3.3 ステップ3:プロトタイプ/モデル

オーダーを遂行する最初のステップはオーダーのプロトタイプまたはモデルに同意することです。この段階では、以下の事柄を指定することができます。インターフェースのエレメント、オーダーおよび入力パラメータ名、インディケータの概観、発信メッセージタイプなど。通常、このモデルタイプにより今後のプログラムの要件および外観について理解を得ることができます。

オーダーの主な目的が、トレーダーが現在のマーケット状況を分析するのを助ける情報システムを作成することであれば、モデルはすべての管理エレメントをインクルードした将来システムのデザインとして表されることができます。Expert Advisorについてはモデルはフローチャートの可能性もあります。それは将来の売買ロボットで意思決定をするプロセスを表すものです。基本的にこの段階では、選択された方向で判断を行い、後にそれに従うのです。

プロトタイプ/モデルの調和は作業過程の注文者と請負者の相互理解において重要なステップなのです。オーダーの実行プロセスの妨げにならないような許容できるソリューションを探すようにします。

請負者は注文者に対してのちのプログラムプロダクトのプロトタイプ/モデルを提供します。注文者が請負者によって提示された資料になにもコメントをしなければ、それは注文者が次のステップに進むために確認したとみなされます。

プロトタイプ/モデルの重要箇所が技術仕様書に記載された要件を満たさない場合は、プトロタイプは改定に送ることができます。その際、改定理由とコメント消去の提案を付けます。オーダーの小さな依頼、変更、改善に見えるものが実際にはコードの大きな変更につながり、開発時間や将来的ソリューションコストを増やすことになる可能性があることを理解するのは重要です。よってつねに注文者、請負者双方の妥協点を見つけるようにします。

注文者がプロトタイプ/モデルの確認をしたら、主な協議はプログラムロジックに限られるようになり、コメント欄に以下のメッセージが表示されます。

図18 『プロトタイプ/モデル』ステップの確認

図18 『プロトタイプ/モデル』ステップの確認

このオーダーの作業中に技術仕様書の要件とのずれが発生すれば、問題を解決するために注文者は調停者に問い合わせをすることができます。

 

3.4 ステップ4:デモンストレーション

プログラムのプロトタイプに同意したら、請負者はオーダーの最終遂行に進みます。ジョブを遂行するプロセスにおいては、請負者が注釈で発生する問題を明確にし続けることが望まれます。

技術仕様書に指定された要件がすべて実装されたら、出来上がったジョブを注文者に実演します。ジョブは、注文者によって承認された技術仕様書の公式要件とプロトタイプ/モデを満たすものである必要があります。ジョブ作業中に発生する追加コメントは以前の段階で話し合われたものでなければ請負者によって却下される可能性があります。

デモが行われる形式はオーダーの性質によります。Expert Advisorsに対してはこれはあらかじめ指定された期間に対する検証レポートの提供かもしれません。これはまた指定の仲介会社等の指定のデモアカウントにおける Expert Advisor の動作に関する追加ログの提出を要求する可能性もあります。これは添付されたビデオ、ビデオ会議、完成したプログラムが実行される請負者の端末へのリモートアクセスとして提供されることもあります。

すべてのデモ段階にはオーダーに対する注釈が反映されます。ここでは注文者が添付のスクリーンショットによって質問をし、請負者はこの質問に回答します。デモンストレーションとその議論の目的は注文されたジョブが適切に合意されたボリュームで仕上がったことを注文者が確認することです。

デモンストレーションが行われたら、注文者は提出された素材がオーダーの性質を満たしていることを確認するか、または却下するかします。その際、技術仕様書の要件を満たしていない内容のリストを提出します。必要であれば、請負者は少し時間をかけて特定された不十分な箇所を修正し、新たにデモンストレーションを行います。

『デモンストレーション』ステップの検証プロセスもジョブサービスによって自動的に記録されます。

図19 『デモンストレーション』ステップの確認

図19 『デモンストレーション』ステップの確認

このオーダーの作業中に技術仕様書の要件とのずれが発生すれば、状況を解決するために注文者または請負者は調停者に訴えることができます。

 

3.5 ステップ5:作業受け入れ

請負者は最終的に遂行したジョブの素材を指定のボリュームで注文者に渡します。よくあるのが、ソリューションがそのソースコードに転送されることです。これはコンパイラのバージョンが将来変わる可能性があり、それがソリューションのコンパイルを要求するからです。なんらかの理由でソースコードが転送されなければ、コンパイルされた実行コードが一つしか利用できず、その場合は技術仕様書の準備段階で将来のアップデートについての問題を記載する必要があります。ソリューションのアップデートに関する問題はジョブリソースの管理者によって処理されることはないため、調停者への訴えを起こすことはできません。

有料または無料で第三者へ配布する権利、注文者または請負者によって別の開発においてのちにコードを利用することについての疑問も技術仕様書に記載します。また、転送が完了した後に、調停者の前で取り上げることはできません。ジョブセクションの管理者はそのような依頼の実行を追跡することはできず、その際、両者にとって最良の保証人は両者の個人的評判です。

遂行されたジョブの転送は注釈に反映します。そこで、転送を実行した方法の詳細を記載します。ジョブがEメールで転送される場合、請負者はその旨注釈に記載し、いつ、どのメールボックスにジョブが送信されるか指摘します。次に注文者はそのようなレターの受け取りを確認し、受信時間を示します。 転送がオーダーの注釈にあるとおりに実行されたとしても、請負者が技術仕様書に完全に従った最終ソリューションを転送する旨を注釈に述べます。

素材が転送されたら、請負者は注文者からの受領確認を待ちます。注文者がジョブに関して生じる問題についてオーダーの注釈になにも書かなければ、または請負者が転送を確認した後3日間になにもコミュニケーションがなければ、自動的にジョブは受け入れられたとみなされます。

図20 『作業同意書』ステップの確認

図20 『作業同意書』ステップの確認

このオーダーの作業中に技術仕様書の要件とのずれが発生すれば、状況を解決するために注文者または請負者は調停者に訴えることができます。

 

3.6 ステップ6:支払い

『作業受け入れ』ステップののち、ジョブは完了したとみなされ、自動的にそれに対する料金が注文者のアカウントから請負者のアカウントに転送されます。支払い実行においては注文者になにもアクションが求められることはありません。

図21 ジョブの支払い

図21 ジョブの支払い

その完了後、ジョブは『完了』セクションに移されます。

図22 ジョブ完了

図22 ジョブ完了

 

4. ジョブに関するフィードバック

ジョブの完了後、注文者と請負者は共同作業に関するフィードバックを書き、そのジョブのクオリティーをランクづけする機会があります。

注文者や請負者が完了したジョブリストはユーザープロフィールの「ジョブ」セクションにあります。

注文者から出されたフィードバック例は以下の図23に示します。

図23 Mikhail Antonov によって完了されたジョブリスト

図23 Mikhail Antonov によって完了されたジョブリスト

請負者もまた終了したジョブに関するフィードバックを掲示することが可能です。

図24 Alexander Demidov に採用されたジョブ請負者からのフィードバック

図24 Alexander Demidov に採用されたジョブ請負者からのフィードバック

 

おわりに

あなたが既製のトレーディング戦略を使用し、MQL5またはMQL4でプログラム作成する方法を知らないトレーダーであれば、「ジョブ」サービスはまさにうってつけです。このサービスによって、シンプルで管理可能で安全にあなたのためにExpert Advisorやインディケータを書いてくれる適切な開発者を見つけるチャンスを得るのです。登録しているユーザーはだれでもあなたのオファーを受け入れ、望むプログラムを作成してくれます。

「ジョブ」サービス開始に伴い MQL5.community はプロダクツを発注、プログラムサービスを提供する理想的な場となりました。日々何千人というトレーダーや開発者がこのリソースを訪れ、造作なくお互いを助け合っています。トレーダーにとっては「ジョブ」サービスはたやすく自分の Expert Advisors を入手するチャンスとなっています。MQL5 開発者にとっては簡単にクライアントを見つけるチャンスとなっています。

MetaQuotes Software Corp.によりロシア語から翻訳された
元の記事: https://www.mql5.com/ru/articles/117

テクニカル分析:何を分析するのか? テクニカル分析:何を分析するのか?

本稿では MetaTrader クライアント端末において利用可能なクオート表示の特殊性をいくつか分析してみます。本稿は一般論を述べるものでプログラムについては述べていません。

テクニカル分析:どのように分析するのか? テクニカル分析:どのように分析するのか?

本稿ではインディケータ、マルチタイムフレームインディケータの再作成および日本式ろうそく足を使用するクオート表示に関する著者の意見を簡潔に述べます。本稿はプログラムの特定部分には言及せzす、一般的特徴を述べるものです。

インターネットを介して端末間でデータ交換をするためのWinInet.dll利用 インターネットを介して端末間でデータ交換をするためのWinInet.dll利用

本稿は HTTP リクエストを介することでインターネットに連携する原理、および仲介サーバーを用いた端末間でのデータ交換について述べます。MQL5 環境でインターネットリソースと連携するためのMqlNet ライブラリクラスについて述べます。異なる仲介会社からの価格をモニターし、ターミナルを終了 することなく他のトレーダーとメッセージ交換をし、インターネットで情報検索をする。これらは例に過ぎませんが、本稿で検討します。

MQL5 コード用自動作成ドキュメンテーション MQL5 コード用自動作成ドキュメンテーション

Java プログラマーの多くは JavaDocs により作成することのできる自動作成ドキュメンテーションを熟知されていることと思います。その考え方は、検索が簡単なヘルプファイルに抽出できる半構造法によりコードにコメントを追加するというものです。C++ 言語界にもまたドキュメンテーション自動作成機能があります。 Microsoft の SandCastle と Doxygen が代表的な2つです。本稿は MQL5 コードで構成済みコメントから HTML ヘルプファイルを作成するための Doxygen 使用について述べます。実験はひじょうにうまくいきましたから、Doxygen が MQL5 コードから作り出すヘルプのドキュメンテーションは大きな価値を加えると信じています。