初めてのお客様へのアドバイス

はじめに

有名人の格言ではよくこう言われます。「失敗を恐れる者はなにもなしえない。」怠慢自体が誤りであることを認めなければ、この言葉を語るのは難しいでしょう。しかし、将来の過ちを最小にするために過去の過ち（自分自身または他者の）を分析することは常に可能です。これから、同じ名前のサービスにおけるジョブ実行中に再発生可能性な状況を検証していこうと思います。

われわれの目標はそれをできる限り客観化することです。どんな場合でも、実行する者、すなわち開発者の視点を表します。実際の状況に進む前に、以下を指摘する必要があると思います。

1. 「ジョブ」サービス： そもそもなぜそれが必要か？

「ジョブ」サービスを利用すべきかしないべきか、判断は各個人が行うものです。私に言わせていただくなら、もちろん利用する、です。そして以下がこれに関する見解です。購入者と開発者の間の相互交流において発生しうる主な問題を考えると、以下を特に取り上げることができます。

• 不明瞭なまたは抽象的な要件仕様（RS）により、その後の開発者によるアウトプットが注文者が期待したものと全く異なる。
• ジョブをしなかったり、部分的にしかしないのに料金を受け取る開発者にだまされるのではないかという注文者の不安
• 完成したジョブを受け取りながら、同意した金額の残額を支払わない注文者にだまされるのではないかという、開発者の不安
• 両者共100%自分が正しく、妥協点を探す必要がないと思うような議論の余地がある（しばしば行き詰った）状況の発生

上記の最後の3件の状況は完全に解決可能です。不明瞭な RS もまた対処可能です。基本的に1つだけ欠点があります。購入者または開発者が必要以上の動きをする必要です。発注、支払い転送、中間進捗を調査する、など。でも私は、これは心の平穏のための小さな代価で、お金は無駄にはならず作業は行われるという確信であると信じています。

みなさんはついに「ジョブ」サービスを利用し、インディケータ、EA、スクリプトの開発や変更の発注をしようと決めたわけです。次の事柄を理解した上でスタートすることが期待されます。それは「ジョブ」サービス利用上のルールです。まだなら今がこの知識の小さな差を埋めるタイミングです。

記事"How to Order an Expert Advisor and Obtain the Desired Result" および "How to Order a Trading Robot in MQL5 and MQL4"を注意して読むことをさらにお薦めします。 これらはすべて本格的で効果的なビジネスに踏み込むのに役立ちます。結局みなさんはまじめな人で、今後安定したトレーダーになるのです。なぜならこの職業は思慮ある慎重なアプローチを要求するからです。

2. オーダーの共通タイプ

問題の状況に関連しがちな共通したオーダータイプを分類してみます。理解しやすいようにリストは以下のオーダータイプから構成しています。

2.1. Forexはひじょうにやさしい

何を目的としているのかわからず、またそれがどのように機能するのか理解をあまりしていない購入者。概してこれは Forex の初心者で生半可な情報を取り上げて Forex はひじょうにやさしいと考えています。交わるМА と別の MACD が最高レベルに達する（こういったものは実は同じチャートのМАであることも判らずに）利益を生むセクションに注目して、がっぽり稼ぎ始めるのに Expert Advisor 形式でコードを書けばいいだけの優れたトレーディングシステムを見つけたと信じているのです。

そのような購入者の出す発注はおおざっぱに次のようなものです。『シンプルな Expert Advisor』、『シンプルなインディケータ』、また『シンプル』および『やさしい』という語を含むその他のバリエーションです。よって支払いとしてオファーされるものは10～20クレジットです。「ジョブ」サービスでは単純にそれ以上低いオファーをすることはできません。

そのような購入者は自分が初心者であること、自分のオーダーが適切な価格ではないばかげたものでさえあることを認めようとしません。なんらかの理由で英語話者はすぐにそれを認め、自分達のシステム処理について価格のアドバイスを求めることもあるほどです。

2.2. インディケータの荒野で

初心者に特有のもう一方の極端な例としては、ときとして相互排他的なシグナルを産むさまざまなインディケータをひじょうに多用することです。一つのインディケータウィンドウで異なるスケール（ときどき異なる複数オーダーとして）で数多くのインディケータの組合せを使用し、それらの間を横切っているインディケータシグナルを注意して見るのもよくあることです。またはこの悪習の傾向があるのは Forex 初心者ばかりというわけではありません。

それがふさわしくないことを説明するすべての試みは、絶えざる理解の欠如と ABC などと同じくらいにたやすくそれを行うプログラマーを漠然と参考にすることにより多大な費用がかかります。とはいうものの、端末を使用する時間が短いほど、理解の欠如は長引き、そこには反比例があるようです。

そのようなインディケータの組合せ例を示します。正規化レンジ 0 ～ 100 を持つRSI と、非正規化レンジ（0 ～単位元よりかなり小さい未知の値）を持つATR を取ります。次のバーで ATR が下から上に RSI をクロスするとき「買い」にエンターします。下の画像（図1）上のグレーの長方形は発生する売りシグナルを表しています。

それを縦の破線でマークし、次に何が起こるか見ます。

図1　出現した「買い」シグナル

次の画像（図2）は買いシグナルがまだそこにあって、さらに強まっているが、なんらかの理由で左に移動した（時間軸におけるタテ破線の位置は変わりません）ことを示しています。もっと早くエンターすべきだったようです。ここでは何か異常があります。

図2　「買い」シグナルはまだそこにある

三番目の画像（図3）は完全に混乱しています。シグナルがなくなってしまいました。まったくこれまでになかったかのように消えています。これらはスケーリングの結果です（異なる値レンジをもつ複数インディケータが同じチャートに表示される必要があると、そのすべてが同時に表示されます）。

図3　シグナルは消え去りました。

共通するもうひとつ別の状況は履歴上であるインディケータのパフォーマンス結果を見ているとき、錯覚にとらわれることです。価格変動に応じた数多くのインディケータの変化と、実際にポジションをオープンするには遅すぎるタイミングでチャート上でいくつかのバーが完了するとき作成されるその最終値を読むことについて明確な理解がないのです。これが『再作成』に関するすべてです。そのようなインディケータの最大のグラフィック例はおそらく Zig Zag です。

暗い部屋で黒猫を探そうとしているような購入者と話をするのには両者の忍耐が続く限りの時間がかかります。そしてそのような話し合いは心理テストのようなものです。

2.3. 手動システムの自動化

これはもっとも複雑なタイプの一つです。だれしも名声が確率した、成功したトレーダではあるがアルゴリズム形式で自分のシステムに入れようとすると困惑したり、価格仕様とインディケータ値で一つ一つのバーを記述することになってしまうトレーダーになる可能性があります。これが起こるのは、その人のトレーディングが直観を基にしているからです。すなわちトレーディング情報の処理が潜在意識下に隠れ、最終結果だけがアウトプットとして作成されるということです。そのようなトレーダーは、実際結果がどのように出たのか理解していません。

システム公式化がうまくいかなければ、最良の選択肢はトレーディング手順を徐々に自動化することかもしれません。どんなシステムも標準エレメントでできています（ポジション／オーダーのオープン／クローズ、リスク管理、ポジション管理等）。作業を段階ごとに細分化し、各段階を個別に処理します。次第に、段階を踏んでトレーディング処理はほとんど完全自動化されます。

二番目の選択肢は、完全自動化トレーディングシステムの考えをすぐに捨て、半自動化システムの開発に着目することです。それはざっと次のように一般化することができます。Expert Advisor で残りの作業が行われているあいだにトレーダーはどこでいつポジションをオープンするか判断するのです。 その代りに特定の条件でエントリーができる時間および／または価格レンジを設定することもできます。そうすると Expert Advisor がこういった条件を監視し指定されたレンジ内でポジションをオープンします。

2.4. お茶を入れるための Expert Advisor を手に入れる

ときどき、直接トレーディングに関連する関数リストが RS のほんの小さな一部を形づくるようなオーダーがあります。そこでは主要部分にはコンピュータの調子とネットワークを監視すること、 SMS や Eメールを送ること、さまざまな誤動作を追跡すること、以上を少しずつを含み、Expert Advisor 周辺の環境で変化するのです。所有者が利用可能な上記すべてについての音声通知で締めくくりです。

これらすべてはもちろん購入者と開発者が意欲を持って目指すものです。ただし、購入者は概してこういった関数の開発のために資金を調達するとなるとひじょうにしぶるものです。それに Expert Advisor はそれらすべてを備える必要があるのでしょうか？私はその必要はないと思います。そのような Expert Advisor はとりわけ必ずしも自律的に処理を行うことができないものです。そこには致命的なエラーといったものが存在します（たとえば長期におよぶ電力障害）。

2.5. なにかわからなくても、とにかくそれをする。

有名なこの一文の冒頭「とりあえず行こう」は通常購入者と開発者が作業の終了時にお互いに対して使う言葉です。そのようなトレーディングシステムはあまりよく考え抜かれていないという事実により、Expert Advisor （またはインディケータ）の開発中に購入者は RS への変更、追加、 RS からの内容削除などを持ち出し始めます。

私の意見では、プログラミングの視点からあまり大きい労力を必要とするものでないなら、そのような変更は問題なく許容できるものだと思います。しかしひじょうに細かい点は見過ごされたり、単に忘れられたりするかもしれません。ただ、そういう点は購入者にとってたいして重要ではないが、実は Expert Advisor のかなりの部分の変更を要求する変更に関わることが多いものです。もっとも重要なのは、そのような変更はプログラムロジックの変更を必要とすることです。一般的な例のひとつは、マーケットオープンの注文の代わりに Expert Advisor が指値注文をしたりその逆をしたりする置き換えです。

3. 理想的な RS とはどんなもの？

抽象的開発に対する要件仕様書（RS）の構造について話すと、理想的な RS はちょうど以下のようなものかもしれません。

3.1. 処理環境

必要な開発のためのターミナル（MetaTrader 4またはMetaTrader 5）この最重要事は通常 RS では取り上げられず、オーダーの話題からすら落とされています。開発者が全員 MQL5 言語について豊富な知識を持っているとは限らず、また逆に MQL4 については学習せずにMQL5 から始めているかもしれないため、このことはオーダーの題材で指定する必要があります。

3.2. 開発者が応募するディールセンターまたは仲介会社

本情報は主に EA （またはトレーディングスクリプト）を開発する際必要となります。さまざまな特殊性があります。オーダー実行における相違、最大／最小ロットサイズ、夜間ポジション、クオートの桁数、アカウント通貨、週末クオートおよびその処理の必要性、固定または浮動スプレッド、新規バーオープンまたはティックに基づく作業等々。

のちに開発者に提供される予想アカウント通貨で DC/Broker を伴う購入者によってデモアカウントが開かれればそれがベストでしょう。これが必要なのは、いくらか DC（例： Oanda）を伴なうデモアカウントをオープンするためでも特定の登録フォーム記入によってそういったウェブサイトに登録する必要がある、などの理由によります。開発者の時間節約をしましょう。作業をデバッグし検証するのが必要なこともあります。

3.3. 開発が実アカウント向けであろうと、検証またはデモアカウント向けにしかすぎなくても、

違いは実際にきわめて重要です。一方で、検証（最適化時間に影響します）においてはオープンするスピードがもっとも重要であり、異なる接続不良における Expert Advisor の正常な状態を回復するエラー処理とリカバリ構造、ターミナルのリブート等は実アカウントで処理する際には優先事項となります。それは実アカウントに対して Expert Advisor を検証するスピードは数十倍遅くなるのでなければ数倍速くなります。ここでもこれは開発費用に大きく影響します。高くなるにも低くなるにも。

ご自身で問いかける時です。ほんとうに実アカウント向けの Expert Advisor が必要なのだろうか？開発が実験的なもので、アルゴリズムがまだ最終的に設定されておらず、今後変更したり改定されるようならば、で実アカウントを考慮して注文する意味はありません。それ以上に、それはまた逆でひじょうに遅い最適化を起こします。アルゴリズムが有効であれば、のちに実アカウント向けの追加開発が注文される可能性があります。それにはあまりお金がかかることはありません。

3.4. 処理アルゴリズムの記述

好みの名前およびデフォルト値を指定して、外部パラメータ（使用しようとしているなら）の暫定的なリストを出すのがよいでしょう。こういったことはすべて開発者のルーチン作業段階をスピードアップし、必要な質問を投げかけたり購入者からの計算を探したりするのに役立ちます。

3.5. 表示される情報タイプ

購入者が望むものがすべて表示されるわけではないので、これは指定する必要があります。そしてなおよいのは、遅くとも RS 仕上げるときにはまとめることです。Expert Advisor やインディケータの処理中に何かを表示したいと思ったら、だいたいの形式を提示して、そのようは処理に期待されるチャートの背景色（黒、光、白、その他）を指定するとよいでしょう。

処理アルゴリズムを説明するのに図が必要であれば、提供します。適切なコメント入りの図は、数ページにおよぶだたの文章よりもアルゴリズムについての考えをシンプルかつ明確に伝えることができます。

3.6. その他もろもろ

ここに通常、一般条件および要件があります。最終作業段階が終了したらソーステキスト（コード）、ソーステキスト内の広範なコメント、エラー修正保証期間、その他要件を提供することが要求されます。

4. デバッグおよび検証について

これはインディケータまたは Expert Advisor により実際に処理される関数が RS にリストアップされている関数に対して確認される段階です。ご存じのように、コンピュータプログラミングの「マーフィーの法則」の一つは次のようなものです。：それぞれプログラムは最低ひとつはバグを持つ。このポイントについての必然的帰結もあります。：見つけ出し修正したバグですべてだ。最後の1つを除いては。これはもちろんジョークですが、上記の『法則』は、複雑なプログラム（Expert Advisorsもインディケータも）となると真実からそう遠くはないものです。

よって、もう一つ別の結論が考えられます。：プロダクツが届けられ、作業受け入れをしたあとに複数のバグが検出されたらすぐに開発者の悪意と無能を疑うべきではありません。私は、開発者から提供されるサービスの質は作業中に検出されるエラーの速やかで効果的な修正によって主に判断されると考えています。

私の意見では、徐々に増える開発または検証は、複数の理論条件や分岐を持つアルゴリズムを実装する複雑なソリューションを検証するとき最適なものとなります。購入者および開発者双方により徐々に解決または検証する理論的に自立した複数部分に問題を分割する必要があります。最終段階で、検証は前に検証された部分と作業全体の連携に関わるものです。

複雑／シンプルという考えは確かに主観的で、開発者の経験や購入者による作業の細かい部分すべての理解度におおきく左右されるものです。MetaTrader 4 および MetaTrader 5により提供される検証方法と技術はひじょうに多様で、そのためテスターの履歴データで Expert Advisor を実行することができると思ってない（または忘れている。実際過去にそういうことに出くわしました）購入者も中にはいます。ただもっとも重要なことはテスターがビジュアル検証モードで利用可能であることです。

これはインディケータまたは Expert advisor が、実行されるトレードや表示される情報によって表現されるパフォーマンス結果を目で監視することで数分間の高速モードで受け取られる履歴クオート上で検証を行うことができる点でもっとも力強く都合のよい検証方法のひとつです。クオートの表示は速度を落とすことも、特定トレードの詳細を分析するための時間をとるのに一時的に保留にすることすらできます。

それにテスターでの検証が続き、デモアカウントで実行することにより Expert Advisor の動作効率を確認することができます。完全に確認するには、通常デモアカウントで1日半リアルタイムの動作を行うことで十分です。つねにあまり長い時間枠（1週間以上）は使用しない条件です。

5. 検出されるエラーの記述

購入者によって検出されるエラーの最適な記述方法についてすこしお話したいと思います。エラーが記述されるべきではない極端な例について述べると、それはこのようなものです。：「貴方の Expert Advisor は動作しません。多数のポジションをオープンするはずですが、一つもオープンしません。」

インスツルメント、時間枠、パラメータセット等といった情報なしに、開発者はこの購入者の端末で起こっていることを推測することしかできません。

私の意見では、見つかるエラーまたは不具合はグラフィック画像を用いて最大に記述するのがよいと思います。MetaTrader 4 および MetaTrader 5に は画像ファイル；としてチャートを保存するオプションがあります。ファイル形式は、MT4では GIF と BMPive、 МТ5 では BMP と PNG です。PNG は画像の鮮明度を完全に保つので好ましい形式です。

МТ4 ターミナルでは、それは以下（図4）に示されているとおりに表示されます。それにはターミナルの必要なチャートの上で右クリックをするとポップアップメニューが表示されます。

図4　チャート画像のファイルへの保存

In МetaТrader 5 では、類似の手順があります。同じコマンド「描画として保存する」がメニューで選択されますが、そこでは含まれるコマンドでいくらか相違があります。

メニューコマンドが選択されると、別のダイアログボックスがもう一つ表示されるので、そこで解像度と、保存する描画の領域を設定します。これは図5に示しています。

図5　保存する描画のパラメータ設定

チャートを伴うウィンドウの画像だけを保存するには「アクティブチャート（そのまま）」を選択します。選択されたオプション「アクティブなワーク領域」は、ターミナルウィンドウ全体の画像を保存します。それは、同時に複数のチャートを表示する必要がある場合に便利なこともあります。

保存する描画のクオリティーを低下させるという理由で、アクティブチャートの解像度を変更することは推奨されません。

画像はまたショートカットキー Alt+PrtScr や、グラフィックエディタでのちに処理するため、現ウィンドウまたはクリップボードの全スクリーンショットのキャプチャを保存でき PrtScr を単独で使うことにより保存することも可能です。

それからグラフィックエディタ内に出来上がった画像ファイルを開き、それを編集（必要ならば）します。たとえば、チャートの適切な位置の可能なエラーについてのテキストノートを追加する、など。編集にあたりもっとも簡単な方法は、Windows とセット販売されているPaint グラフィックエディタです。ただし、それは好みと習慣の問題です。

6. RS に隠された落とし穴

概して、それらはさまざまな理由により出現します。：株式市場や Forex の価格の微妙な部分の理解不足、時間軸や価格軸に応じたスケーリングの特殊亭に対する無配慮などです。開発者がRS について論じるときこれらの点に注意を向けようとするかしないか 、またはその人の技能やマーケットトレードの特殊性についての知識に大きく左右される形式的手法を選択するかしないか、そしてもちろん正直さによります。

民族的比喩表現を用いて言えば、 RS を書くとき、購入者はしばしば現実の外為や金融マーケットではなく『真空の球体の牛』の振る舞いについて考えます。それで価格系列の動きを理想化しているのです。

6.1. 価格変動の離散性

以下の実用例を見ていきます。要求仕様書の文は実質的に次の効果を持ちます。価格が外部パラメータによって設定される値に達すると買いポジションをオープンする。人はこう考えるでしょう。それについて疑問はまったくうかばないだろう。価格があり、値が設定され、開始条件を書くだけだ。

ここで見逃されている『ささいなこと』は価格はチャート上で個別に（ある点から別の点へ）連続的に変動するということです。ターミナルオプション「チャートを破線として表示する」 を有効にし、画面で見ることができるようにすることは価格変動を連続的にしません。チャート内の実際の価格系列はまた離散点で構成されます。

そのことは以下のティックチャート例（ラフ型）で説明することができます。

図6　個別価格変動

指定の価格値は水平の実線で表示され、赤とブルーの実線が実際に観測される価格変動を表します。チャートをよく見ると、技術的に価格は決して指定のレベルに到達しないことが判ります。それは、元の RS のロジックによると条件は決して満たされたことがない、ということです。

よって、価格が指定のレベルに到達したように見えても、提示の RS に設定されているように条件は決して満たされていないのです。現実に合った RS に導入される理想的な価格概念を持つためには以下を行う必要があります。既存レベルに上限および下限の2つの限度を追加します。それらは図6に破線で表示されています。この上下限は特定のトレーディングシステムに依存します。たいていの場合、2～3ユニットの平均的広がりで十分です。

破線間領域にあるすべての点は指定値に到達したとみなされます。上図ではグリーンの丸で囲まれている点がそれにあたります。

RS に戻り、次のように修正します。価格が外部パラメータにより＋/－Δ に到達すると買いポジションをオープンする。ずっとよくなりました。

配慮すべき点がもう一つあります。それは仲介会社のサーバーとの接続はいつなんどき失われるかわからないことです。接続が戻るまで、価格は指定レベルからいくらでも上下するかもしれません。この領域（仲介会社のサーバーとの接続が失われている）は図6ではピンクで囲われています。明らかにこの種の状況も RS で考慮されるべきです。

もう一度 RS を修正します。以前の価格値が外部パラメータの－Δ によって設定された値よりも低く、現在値が外部パラメータ＋/－Δ によって設定される範囲にあれば、それらの間の時間間隔が指定されたものより大きくないという条件で、買いポジションをオープンします。これですべてが正しくなりました。

6.2. 正確に指定した時刻での動作

RS にあるように「外部パラメータによって設定された価格から既定の距離で2つの指値買いと売り注文を出します。」ここで2タイプのターミナル、МТ4 および МТ5 の間で区別をする必要があります。MetaTrader 5 では1秒という最小の離散性で同じ時間のカウントダウンのタイマーを使用できるのに対し、MetaTrader 4 の MQL4 言語にはタイマーが使えません。

よって、МТ4 での標準時間カウントダウンについては、Expert Advisor またはインディケータが使用されるインスツルメントの通常着信価格ティック時間を利用します。ティックは定期的に表示されるものではなく、うまくいったティックの時間間隔は閑散市場では数十秒、ときには数分ときわめて大きいため、指定の時刻に絶対的に正確に注文を開始する保証ができないことがわかります。МТ4 での時間カウントダウンの標準的方法は開発するのに都合がよく不都合な点が多々あるループになった Expert Advisor を使用することです。

そのため RS のこの部分は以下のように修正するとよいでしょう。「指定のエラーを持つ 外部パラメータによって設定された時刻の価格から既定の距離で2つの指値買いと売り注文を出します。」

6.3. 一般的な多元タームの使用

ここに典型的な例があります。マーケットが平坦なときは、へフラットに。あきらかにトレンドがあるときは、トレンドが現れるようにします。その際、購入者はトレンド／フラットをプログラムするというようなシンプルで簡単なタスクにそれ以上の細かいことが要求されるとは信じません。ここではコメントは必要ないでしょう。

別の例があります。極値で指値注文を出す。RS にはもちろん購入者の極値解釈は含まれていません。実際にそれがチャートから派生しうるものならなぜ説明をするのでしょうか？それぞれメリット、デメリットがある数多くの異なるアルゴリズムを用いて極値を取得できるということは購入者にとっては驚きです。

6.4. 一般的意味を持つ共通語の使用

日常生活で使用されるとき意味がはっきりしている語です。それは要求仕様書で使うには適当ではありません。いくつか例があります。RS では次のようにあります。 インディケータラインに連続する2つの隆起があれば、二番目の隆起は最初のよりも低い などです。

上記を読むと多くの疑問が生まれます。何が隆起とみなされるのか？お互いにそのような『隆起』が位置する最大／最短距離は？二番目の隆起は一番目よりどの程度低くなるべきか？などです。

たくさん／少し、小さい／大きいなどという語もひじょうに多用されます。プログラミングは正確な定量的定義を要求する数学に基づいていることを理解する必要があります。それ以外の方法はありません。

7. いつ調停を頼るか？

あきらかに作業完了前に調停を申し出る必要があります。すなわち、最終段階、作業結果の引き渡し／支払いが終了する前です。そうでないと開発者と購入者をバインドする財政的な要因がなくなるからです。これは基本条件です。

調停に頼る唯一の理由は、開発者－購入者間にて個人的に解決することができない問題が発生することにあるようです。たとえば、引き渡された作業結果に購入者が誤った処理（RS内容との不一致）を確認し、開発者は逆を証明しようとしているとき。

もうひとつの可能性は購入者または開発者が長期にわたり『姿を消し』、その間個人メッセージやメールに返信しないことなどです。この間、購入者の資金はアカウントでブロックされ、作業は行われません。または逆に作業はとっくに終わっていても支払いを受ける方法がない、というのもあります。さまざまな状況がありますが、いずれにせよ状況は調停によって解決される必要があり、解決されます。

両者が RS を急いで仕上げ、作業を開始するというのがひじょうによくある状況です。それはのちに書面で提示される RS は使用されることができず、いくつかの点でより詳細な内容と明確さが要求されることになります。結果、オーダー値は変更される必要が生じるかもしれません。調停によってのみ、作業はこの段階から後戻りする可能性があります。よって作業の開始を急がず、むしろもう一度時間をかけて RS を調べるべきです。

おわりに

本稿が「ジョブ」サービスの初心者ユーザー、とりわけ初めて利用するユーザーに役立つことを願っています。本稿が問題をすべて挙げているとは思えませんが、千里の道も一歩から、です。お互いにやさしく、われわれを取りまく世界の多くのネガティブな感情を爆破させないことです。それでは誰も幸せになれません。購入者も開発者も、です。

購入者からよくある質問

1. 開発者が Skype、ICQ、電話、Ｅメールなどで話すのに気が進まない理由は？

2つの大きな理由があると思います。

まず、一人の開発者が多くの購入者をかかえており、その全員とオンラインで話し始めたら（同時にしなくてよければいいですが）、プログラミングの時間がほとんどなくなることです。Skype やICQ を使って説明すると速くすむというのは俗説です。

二番目に、こういった選択肢は一つ重要な機能を欠いています。話されたことの記録を取る機能です。重要なことはもめごとや調停に関しては、該当する注文に関する書面でのコミュニケーションがいずれかの過ちや無実を証明できるということです。

2. コンパイルされた EA またはインディケータ（ファイル .ex4 または .ex5）を起動するとき端末がシャットダウンされる理由は?

インストールされた端末のバージョンがコンパイルに使用されているものより古いためと思われます。端末を最新バージョンにアップデートする必要があります。

3. EA またはインディケータファイルをコンパイルするとき発生する「関数 'xxxxxx' は参照されておらず exp ファイルから消去されます。」というエラーはなにですか？

それはエラーではありません。メッセージの内容は「関数 'xxxxxx' が使用されておらず（'xxxxxx' は指定の関数名と置き換わっています）、コンパイルされたファイルの中にない」ということです。この『余分な』関数の存在は EA やインディケータの処理に影響することはまったくないので、そのメッセージは無視して構いません。

4. EA またはインディケータファイルをコンパイルするとき発生する「インクルードファイル 'xxxxxx' を開くことができません。」というエラーはなにですか？

このメッセージの意味は、「ファイル "хххххх" はファイルをご自身のコンピュータに転送する際コピーされなかった、または誤ったディレクトリにコピーされた」というものです。通常、.mqh ファイルは端末のインクルードディレクトリに入れる必要があります。

5. Expert Advisor の処理中、テイクプロフィット／ストップロスレベルでポジションがクローズされた位置をマークしない理由は？

この機能はストラテジーテスタで Expert Advisor を検証するときのみ有効です。実アカウントまたはデモアカウントで動作する場合は、利用することができません。そのトランザクションはチャートについてアカウント履歴からマウスの左ボタンを押してドラッグすることができます。ポジションのオープンやクローズを指すマークはチャートに表示され、ストラテジーテスタの検証中と同様、破線でつながれています。

6. チャートはエントリーの条件がすべてそろっていることを示しているのに、ポジションがオープンしません（発注ができていません）。

これはExpert Advisor で読み取りをするインディケータを再描画した結果であると思われます。想定エントリーの際にある条件（インディケータの値）がポジションをオープンするシグナルと一致していないのです。それから、バー数本ののち、インディケータ値は変わり、履歴で確認できる最終形を取ったのです。これはテスターのビジュアルモードで簡単に確認することができます。

7. デモンストレーション段階のプロトタイプ／パイロットモデルでの作業をキャンセルする方法は？

調停でのみキャンセル可能です。

推奨リンク

1. 「ジョブ」サービス利用ルール
2. Expert Advisor を注文し望む結果を手に入れる方法
3. MQL5 および MQL4での売買ロボット注文法