English Русский 中文 Español Deutsch Português
preview
自動で動くEAを作る(第13回):自動化(V)

自動で動くEAを作る(第13回):自動化(V)

MetaTrader 5トレーディング | 19 7月 2023, 11:21
269 0
Daniel Jose
Daniel Jose

はじめに

基本的な骨格の作成が完了したので、いよいよEAを自動化して、定義した操作ルールに従って100%自動的に動作するようにします。この記事の目的は、操作モデルを構築することではなく、手動のエキスパートアドバイザー(EA)を自動化することによって、ここで提案されているシステムを使用する方法を示し、準備することです。

100%自動化されたEAを使用したいと考えているほとんどのトレーダー(必ずしも読者の皆さんのことではありません)の大きな問題は、彼らがプログラミングについてまったく何も知らないこと、あるいはさらに悪いことに、金融市場について何も知らず、このエリアを探索したいと思わないことだと思います。

多くの人は、舞台裏で何が起こっているのかを実際には理解せずに、魔法のようにお金を生み出すコンピュータープログラムを実行したいだけです。特定のプラットフォーム、システム、EAについて良くも悪くも話している人をたくさん見かけますが、大多数の人は、自分たちがどのようなリスクにさらされているのか全く理解しておらず、MQL5で書かれてMetaTrader 5上で実行されるか、他のプログラミング言語で開発された単純なコンピュータープログラムがATMになると想像しています。

多くの人がそんな「夢」や「幻想」を抱いています。彼らは、プログラマーや自分自身さえも、魔法のように証券口座にお金を生み出す方法、プログラム、アルゴリズムを開発できると考えています。彼らの多くは金融市場の基本を学ぶ必要さえありますが、誰かに自分たちが間違っていると言われることを好みません。

金融市場で何らかの方法でプログラムをマネーファクトリーに変えるために使用、作成、開発できるものは間違いなくすべて、すでに作成され、テストされ、開発されています。不適切であることが判明したものもあれば、適切なリスク管理をおこなって一定期間にわたってある程度の利益を生み出すことができたものもあります。

したがって、この情報は最終的には金持ちになれる魔法のシステムを見つけたいと思っている方向けではないので、そのような方は読み続けるのをおやめください。この記事で魔法の公式を期待している方にも同じことが当てはまります。読み続けるのをおやめください。

ここでは、すでに使用されているシステムを自動化するためのトリガーを開発する方法を説明します。

EAを自動化する方法を考えてみましょう。実際に何をする必要があるかを計画することから始めましょう。


自動化の計画

まず、何を取引するかは関係ありません。どの指標、チャートの時間枠、シグナルを使用するかも関係ありません。自動化プロセスは常に同じタイプの計画に従います。唯一の違いはトリガーの構築方法ですが、計画は常に同じです。

システムを自動化する方法を計画するには、まず、しばらく使用されている取引モデルを用意する必要があります。これが最も重要です。未知のモデルを自動化しようとしないでください。その特定のモデルを使用する習慣を身に付ける必要があります。

したがって、これが自動化の最初の要件です。モデルの使用方法を知っておく必要があります。次に、取引を実行するためのルールを明確に定義する必要があります。これは明確かつ客観的な方法でおこなう必要があります。「「これがこうなら」、「おそらくこれがそうでないなら」、これがうまくいくことを願っています。これは間違っています。ルールは「こうなったら売り、ああなったら買う」のようになるべきです。ルールは客観的なものでなければなりません。覚えておいてください、私たちは感情を持たないロボットに教えているのです。ロボットは恐怖も後悔も感じません。よって客観的になってください。

明確なルールを決めたら、プログラミングロジックの作成を開始します。プログラミングの時点で、システムをより良く、より収益性の高いものにしようとして新しいルールを発明しようとするため、多くの人がこの時点で迷ってしまいます。繰り返しますが、これは間違いです。EAはモデルがおこなうことと同じことをおこなう必要があります。まったく同じことです。

例として、9期間指数移動平均として知られるラリーウィリアムズモデルのルールを作成する方法を見てみましょう。モデルには多くのバリエーションがありますが、このオリジナルのものは非常にシンプルです。これは単なる例であることに注意してください。実際にどのように機能するかを理解していない場合は、使用をお勧めしません。それでは、このモデルのルールの計画を見てみましょう。

バーが9期間の指数移動平均を上回って終了した場合は買い、終値が安くなった場合は売ります。

これはモデルをプログラミングするための重要なルールです。すべてが明確で客観的です。トレーリングストップを追加したい場合、そのアプローチは次の例のように単純である必要があります。

取引ストップは常に、買い取引の場合は閉じたバーの安値より1ティック上、売り取引の場合は閉じたバーの高値より1ティック下になります。

繰り返しますが、ルールは簡単です。このようにして、独自のルールを作成する必要があります。これを明確にするために、RSI指標を使用する別の例を見てみましょう。このロジックは他の指標にも適用できます。ここでの目的は、正しいアプローチを示すことです。

指標が80のレベルを超えている場合は、売りエントリを待ちます。80を下回ったらすぐに売ります。指標が20を下回っている場合は、買い取引に入る準備をします。20を超えたらすぐに買います。

このルールはシンプルで効果的ですが、それでもストップレベルまたはトレーリングストップルールが必要です。このために、別の指標を使用することも同じ指標を使用することもできます。繰り返しますが、ルールが明確である限り、これは問題ではありません。次に、20期間の算術平均に基づいたルールを定義しましょう。ルールは次のようになります。

買うか売るかに関係なくストップレベルは20期間の算術移動平均​​の価格に設定されます。

ただし、このルールを次のように変更することもできます。

ロングの場合、価格が20期間の算術MAを下回って終了した場合、取引を終了します。売りポジションの場合、価格が20期間算術MAを上回って終了した場合、ポジションをクローズします。

実際に物事をどのようにおこなうべきかは明確になっているでしょうか。妥協点はなく、可能性を発明したり想像したりすることなく、すべてを白か黒かで判断する必要があります

このため、自動化する前に、目的のモードを使用する習慣を身に付ける必要があります。ここには不確実性が存在する余地はありません。ルールは厳格であり、厳密に従わなければなりません。覚えておいてください。ロボットに何を計算するかを指示しているのです。ルールに従って行動しようとして、偏見を持ってしまう方法を教える方法はありません。適応型システムであっても、厳密で非常に明確に定義されたルールに従います。彼らが市場に適応できるという事実は、これらの厳格なルールの中に、市場が許容できる何らかのエラーを置いているという事実によるものにすぎません。

システムに許容可能なレベルの誤差を追加すると、システムがより主観的になる可能性があるため、システムに「買うかもしれない」「売るかもしれない」と言い始めることになります。この方法は興味深いように思えますが、制御が複雑になります。プログラミングや数学の観点からではなく、EAを制御するトレーダーにとっての難しさです。これには、EAのアクションを分析し、それが何か間違っているかどうかを判断するために、市場に関する深い知識が必要です。

システムを適応させる方法を理解するために、9期間の指数移動平均の例を使用してみましょう。この例は、モデルに適合するルールを追加することで、任意のモデルに適用できます。買いのルールは次のようになります。

バーが9期間の指数移動平均を上回って終了したら、前の5つのバーを分析します。それらがより低い高値を形成している場合は、取引に参加しません。

私たちはシステムに数学的主観性のレベルを追加しました。以前は、バーが平均を上回って終了した場合に買っていましたが、現在はさらに過去の高値に依存して買いを入れています。これらすべてをリアルタイムで分析するには、経験豊富なトレーダーである必要があります。

多少の主観があっても、ルールは厳格であることに注意してください。EAの仕組みを見ると、市場に適応しているように見えるかもしれません。しかし、その操作は依然として厳格なルールによって管理されているため、これは単なる幻想にすぎません。

同じルールを生成するためにデータ分析プログラミングをよく使用する人もいます。このようなプログラミングにより、システムが人工知能を使い始めたと言う人もいるかもしれません。

しかし、私のプログラミング経験から言えば、これはナンセンスです。実際にアルゴリズムを使用するのは、観察されたパターンに基づいて数学的曲線と機会グラフを作成するためだけです。

これらの機会曲線は、市場の観察や経験ではなく数学的分析に基づいた厳格なルールにつながります。問題は、私たちは理性を持たない機械を扱っているため、そのようなシステムが市場の変化にすぐに適応できないことです。これらは単なる計算機であり、プログラムされるまでは何もおこないません。

これで、私たちがどこまでできるか理解できたと思います。魔法のようなシステムを探すことに意味はなく、何をすべきかを明確かつ客観的に判断する必要があります。これで、次のステップに進むことができます。


アイデアをコードに変える

多くの人は、アイデアをコードに変換することは非常に複雑で、プログラミング科学の専門家、修士号か博士号を持つ人のみがアクセスできるものであると考え、警戒しているかもしれません。しかし、これは真実ではありません。常識、用心深さ、規律、好奇心、興味を持っている人なら誰でも、そのアイデアが明確かつ客観的に述べられていれば、実際にそのアイデアをコードに変えることができます。実装しようとしているアイデアを明確に定義できなかった場合は、前のステップに戻って、アイデアを明確かつ簡単な方法で紙に書き留めてください。

次に、アイデアをコードに変換する方法を見てみましょう。アイデアが短すぎる場合は、詳細な説明を入力してください。段階的なプロセスとイベントがどのように展開するかを説明します。説明に含める手順が多ければ多いほど、コードはより良いものになります。

説明が確実に適切であるかどうかを確認するには、次のフローチャートを完了できるかどうかを確認してください。

図01

図01:実装ブロック図

多くの人がこの画像を見て、非常に奇妙に感じるでしょう。おそらく、そのようなものを使用している人、特にプログラマーは見たことがないでしょう。

図01は、プログラミングやその他の分野で広く使用されているフローチャートです。ただし、ここではプログラミングを扱っているので、この点に焦点を当てましょう。図01にあるのは、手動か自動かに関係なく、メカニズムが動作する方法です。それぞれのプログラムには、図01に示す独自のマップがあります。各項目を正しく記入できれば、実際にプログラムを作成することができ、完璧に動作します。このようなフローチャートはフラクタルに基づいて機能します。

しかし、どうしてそんなことが可能なのでしょうか。フローチャートはどのようにしてフラクタルになり、どのようにプログラムすべきかを表現できるのでしょうか。😵😱図01がどのようにして何でも構築できるフラクタルになるのかを考えてみましょう。どんなに複雑なものであっても、この図の枠内で表現できれば構築できます。

各プロセスはP1から始まります。 次に、P2で何らかの決定をおこないます。 決断が何であるかは関係ありません。常に、P3に向かうパスまたはP4に向かうパスのいずれかを選択します。 取るべきパスはP2で決定されます。

P3P4はどちらも図01と同様のイメージを表すことができ、プロセスは最終的に終了するまで繰り返されます。ただし、説明を簡単にするために、P3P4は、すぐに返される単純な計算または呼び出しであると仮定します。最終的には両方ともP5に収束します。

ここでは、P3またはP4からの通知に基づいて新たな決定を下します。P5の決定に応じて、P2に戻るかP6に進むことができます。P2に戻ると、プロセスが繰り返され、フィードバックシステムが作成されます。P6に進むとプロセスは終了します。

このダイナミクスのおかげで、P1を出てP6に到着するメッセージまたは実行フローが得られます。P3P4でも同じフローが発生する可能性があります。これが発生すると、フラクタルはP3またはP4に表示されますが、フローチャートの他の場所には表示されません。

プログラミングの話に戻りましょう。MQL5では、P2P5IF ELSEまたはSWITCH CASEに置き換えることができます。したがって、自分のアイデアをこのフローチャートで表現し、適切に説明して記述することができれば、プログラミングの知識がなくても何かを作成することは可能です。

P1は、関数またはプロシージャが受け取る引数のセット、またはコードがチャート上に配置されたときにコードの実行を開始する点です。すべての初期値と必要な値をP1に配置することを理解することが重要です。

P6RETURNコマンド、またはP1に入力された値に基づいて応答を提供するその他のものです。

P3P4については、決定方法を示す別のフローチャート、またはP1の値を処理する単純な因数分解のいずれかにすることができます。私たちの目的は、図01のシステムを自動化できるように説明することです。

理解しやすくするために、いくつかの例を見てみましょう。9期間の指数移動平均から始めましょう。手順の説明をプログラム可能な形式に変換し、フローチャートに組み込みます。次のことを考慮してください。

例01:9期間の指数移動平均を使用した売買

  • P1には、MA値と足の終値を入力します。
  • P2では、価格が指定された平均を上回ったか下回ったかを確認します。
  • 価格が高く終了した場合は、P4(買い呼び出し)に進みます。
  • 安値で終了した場合は、P3(売り呼び出し)に進みます。
  • 売買後はP5へ進みます。
  • EAが自動化されている場合は、P2に戻り、次のバーの手順を確認します。EAが手動の場合は、他に実行するアクションがないため、P6に進みます。
例02:トレーリングストップと損益分岐点

  • P1では、希望する利益と現在の足の価格を示します。
  • P2では、ポジションが希望の利益に達したかどうかを確認します。そうであればP3、そうでない場合は、P4を実行します。
  • P3では、新しいフローチャートを開始します(P1-ストップ価格の値を指定します)。
  • P2のこの新しいフローチャートでは、損益分岐点が既に発生しているかどうかを確認します(損益分岐点が発生していない場合はP3を実行し、損益分岐点が発生している場合はP4を実行します)。
  • 損益分岐点が実行されなかった場合は、さらに進みます。P5とP6に進み、前のフローチャートに戻り、新しいトレーリングストップと損益分岐点プロシージャコールを待ちます。
  • ネストされたフローチャートのP2に戻り、損益分岐点が発生したかどうかを確認します。答えが「はい」の場合は、P4(トレーリングストップ)を実行します。
  • P4が呼び出されると、新しいフローチャートを開いて価格を変更できるかどうかを確認します。これは、他のフローチャートを使用していくつかの方法で実行できます。最後に、メインフローチャートに戻り、手順を終了して、新しい呼び出しを待ちます。

例03:RSIまたはIFRの作業

フローチャートは例01と似ています。こちらです。

  • P1では指標値を取得します。
  • P2で、値が80より大きいか20より小さいかを確認します(注:デモのために任意の値が示されています))。
  • 80以上の場合はP3(売り)を実行します。
  • 20未満の場合はP4(買い)を実行します。
  • 結果に関係なく、P5に進みます。システムが自動の場合はP2に戻ります。それ以外の場合は、それ以上のアクションは必要ないため、P6に進みます。

仕組みが明らかになったでしょうか。😁これができれば、自動化されたEAを作成できるようになります。

おそらくコードを見るのが待ち遠しいと思います。コードは最も簡単な部分なので心配しないでください。重要なことは、これを達成する方法と、独自の自動化されたEAを作成する方法を理解することです。プロのプログラマーかどうかに関係なく、誰でもEAを作成し、複雑で安全性の低いプログラミングに依存することなく、最適なモデルを使用できることを実証したいと考えています。

すぐにコードに到達しますので、しばらくお待ちください。自動EAの作成方法を説明しますが、その前にシステムの使用方法を知る必要があります。そうしないと、システムはさらに多くの可能性を提供できますが、提示されたコードに制限されることになります。この短い連載では、私の知識の一部を共有します。


自動化の理解と実装

前のトピックを理解したら、コードに進むことができます。ただし、これについてはこの記事では扱いません。コードのビルド方法については後ほど詳しく説明したいと思います。特定のモデルの使用を提案しているわけではないため、この部分については非常に詳細な説明が必要になります。

この連載の目的は、特定の操作モデルを作成するのではなく、すでにテストされ手動で操作されているモデルを自動システムに変換する方法を教えることです。この記事では、EAの作成に使用されるクラスシステムを操作する方法を説明します。ただし、上記の理由により、実際の実装については次の記事に譲ります。

この連載で紹介するEAには、機能の簡潔なリストが含まれていますが、ほぼ100%のケースをカバーできます。コードへの追加が必要となる予期せぬ状況が発生する可能性がありますが、それは非常にまれです。ほとんどのユーザーは指標を使用するため、提案されたクラスシステムにより指標が使いやすくなり、ユーザーが大規模なコードを記述することがなくなります。データと値を受け取るために指標がチャート上にある必要はないため、EAの動作を通知するためにいくつかのアラートをオンにする必要がある場合があります。指標は取引を観察できるようにチャートを実行している可能性がありますが、これはEAにとっては問題ではありません。

もう1つの重要なケースは、特定のモデルをカバーするためにコードを追加する必要がある場合です。これは、コードのセキュリティを侵害したり、コンパイル関連の問題を引き起こしたりしないように、カプセル化と継承の概念を維持しながら、クラスシステム内で実行する必要があります。

以前の記事ですでに述べたように、コンパイラによって生成される警告メッセージに注意してください。ソリューションがまだ完成していないテスト段階を除いて、これらは無視すべきではありません。ただし、コードがより具体的になったら、コードがすでにコンパイルされている場合でも、コンパイラメッセージを無視しないでください。警告の存在は、コードが完全に安全ではない可能性があるか、100%自動化された使用に十分な安定性と精度がない可能性があることを示しています。ここで作成しているシステムを編集するときは、このことに留意してください。

図02に示す手動操作のシステム構成を見てみましょう。

図02

図02:手動操作

この図では、EAまたはそのクラスの1つを直接扱っているように見えるかもしれませんが、これは真実ではありません。トレーダーは実際にプラットフォームを操作しますが、EAはプラットフォームによって生成されたコマンドには応答しますが、ユーザーのコマンドには応答しません。

多くの人は、EAを使用するとき、EAと直接対話していると考えていますが、実際にはEAにコマンドを送信するプラットフォームと対話しているのです。この点に留意することが非常に重要です。これについては、この連載の以前の記事ですでに説明しています。EAを自動化する前に、図02を理解する必要があります。プログラマーによって形式は異なる場合がありますが、原理は同じです。つまり、EAではなくプラットフォームと対話します。

これに基づいて、トリガーシステムをどこに配置するかを考えることができます。図02は、クラスの内部構造ではなく、ファイルの構造を示していることに注意してください。何らかの方法でシステムを変更する場合は、このことに留意してください。私が説明したいのは、いかなる変更もシステムの安定性を損なわないように、あるいはさらに悪いことに、システムの外見上信頼性を失わないように、慎重におこなう必要がある一方、これらの変更は実際にはいつでも爆発しかねない時限爆弾であるということです。

システムがどのように機能するかを考えてみましょう。トレーダーは、C_Mouseクラスと対話することで、特定の価格で売買する意図をMetaTrader 5プラットフォームに通知します。

このクラスは、マウス移動イベントを受信し、価格ラインを配置する場所をC_Mouseクラスに通知するEAに接続されています。マウスをクリックすると、ポイントがC_MouseからEAに渡され、トレーダーが買るのか売うのかをEAが分析します。次に、EAはC_Managerクラスにリクエストを送信し、C_ControlOfTime時間の条件を確認します。

C_Managerクラスの作成パラメータに応じて、リクエストは受け入れられるか拒否されます。受け入れられると、対応する注文がC_Ordersクラスに送信され、C_Ordersクラスがリクエストを取引サーバーに送信します。サーバーがリクエストに応答すると、MetaTrader 5プラットフォームで新しいイベントが発生し、OnTradeTransactionイベントを通じてサーバーで何が起こったかをEAに通知します。

EAはこの情報を分析し、コンテキストに応じてトレーダーのリクエストの結果についてC_ManagerクラスとC_Ordersクラスに通知します。したがって、ポジションはEAに存在するコードと対話することによってオープン、変更、またはクローズされます。ただし、トレーダーはツールバーを使用して、サーバー上でEAによってオープンされた注文またはポジションをクローズまたは変更できます。これが発生した場合、MetaTrader 5プラットフォームはOnTradeTransactionを使用してイベントを生成し、トレーダーに変更を通知します。該当する場合、EAは情報をC_Managerクラスに渡す必要があります。

この仕組みを理解すると、自動化システムがトリガーシステム全体を初期化するC_Mouseクラスを置き換える必要があることがわかります。システムを自動化するときにC_Mouseクラスは削除されますが、C_Mouseは引き続きEAと対話し、C_Managerクラスへの呼び出しを生成するため、自動化はおこなわれません。

C_Mouseクラスは、EAとC_Managerクラスの間に何らかの接続を確立することもできます。ただし、C_Mouseクラスがシステムから削除されることは事前にわかっていたため、システム全体がC_Mouseクラスを簡単に削除できるように設計されています。このステップでは自動化がおこなわれます。

それでも、トレーダーとMetaTrader 5プラットフォームのやり取りによって引き起こされるイベントのトリガーに関連する問題に対処する必要があります。この場合、EAはリクエストを単に無視し、トレーダーのアクションを認識できるように注文システムに関連するイベントについてC_Managerクラスに通知するだけです。このプロセスは次の記事でより明確になり、自動化について詳しく説明します。


結論

今回は、フローチャートを使って操作ルールを設定する方法を紹介しました。人工知能について議論するとき、このような質問がよく起こります。このアイデア自体は新しいものではないのですが、それを最近のことのように話している人をよく見かけます。いずれにしても、ここで紹介した資料は、既存の可能性のほんの一部にすぎませんが、貴重なものです。

ここで説明した各手順を理解するために、時間をかけてこの記事と関連記事をお読みください。次の記事では、ここで説明した内容に基づいて、システムが魔法のように自動的にどのように機能するかを見ていきます。この内容をよく理解することは連載全体の結果を理解する手助けとなります。

MetaQuotes Ltdによりポルトガル語から翻訳されました。
元の記事: https://www.mql5.com/pt/articles/11310

多層パーセプトロンとバックプロパゲーションアルゴリズム(その3):ストラテジーテスターとの統合 - 概要(I) 多層パーセプトロンとバックプロパゲーションアルゴリズム(その3):ストラテジーテスターとの統合 - 概要(I)
多層パーセプトロンは、非線形分離可能な問題を解くことができる単純なパーセプトロンを進化させたものです。バックプロパゲーションアルゴリズムと組み合わせることで、このニューラルネットワークを効果的に学習させることができます。多層パーセプトロンとバックプロパゲーション連載第3回では、このテクニックをストラテジーテスターに統合する方法を見ていきます。この統合により、取引戦略を最適化するためのより良い意思決定を目的とした複雑なデータ分析が可能になります。この記事では、このテクニックの利点と問題点について説明します。
MQL5を使用したカスタムTrue Strength Index指標の作成方法 MQL5を使用したカスタムTrue Strength Index指標の作成方法
カスタム指標の作成方法についてご紹介します。今回はTSI (True Strength Index)を扱い、それに基づいてエキスパートアドバイザー(EA)を作成することにします。
自動で動くEAを作る(第14回):自動化(VI) 自動で動くEAを作る(第14回):自動化(VI)
今回は、この連載で得た知識をすべて実践してみましょう。最終的には、100%自動化された機能的なシステムを構築します。しかしその前に、まだ最後の詳細を学ばなければなりません。
MQL5の圏論(第7回):多重集合、相対集合、添字集合 MQL5の圏論(第7回):多重集合、相対集合、添字集合
圏論は、数学の多様かつ拡大を続ける分野であり、最近になってMQL5コミュニティである程度取り上げられるようになりました。この連載では、その概念と原理のいくつかを探索して考察することで、トレーダーの戦略開発におけるこの注目すべき分野の利用を促進することを目的としたオープンなライブラリを確立することを目指しています。