EAは購入・自作・開発依頼のどれにする？仕様・納品・保守の確認点

カエルさん

EAは買うのと自作、どちらがいい？
開発を頼めば、あとで自由に変更できる？
どんな売買にするか、依頼してから考えてもいい？

まず何を変えたいかと、誰が修正・保守するかを決めよう。既製EAは説明された機能や入力の範囲を使う選択、自作や開発依頼はルールを仕様にする準備も必要だよ。依頼しただけでソース・改変の許可・将来の保守が全部そろうとは考えず、納品条件まで確認しよう。

たけたけ

📖 この記事でわかること

・　既製EAの購入・自作・開発依頼で、自分が決める範囲

・　依頼前に整理する注文ルールと、納品物・変更条件の違い

・　仕様どおりかの確認と、修正・保守・利用期間の費用の見方

「こんな条件で動くEAが欲しい」と思っても、すぐに購入や開発依頼へ進む前に、必要な動作を説明できるかを確認しましょう。既製品の入力設定で足りるのか、売買ルールそのものを作り替えたいのかで、準備することが変わります。

この記事は2026年11月14日に確認したMetaQuotesの公式情報をもとに、入手方法を選ぶ際の確認点を説明します。開発業者への依頼や支払い、個別EAの実装・実運用は行っていません。費用や納期の相場、利益を出せる方式の順位も示していません。

購入・自作・開発依頼は、変えたい範囲から選ぶ
先に注文ルールを、文章と例で決める
ソース・実行ファイル・変更できる権利を分ける
動作確認・修正対応・費用を利用期間で考える
EAの購入・自作・開発依頼でよくある質問
まとめ｜欲しい動作と、作成後の担当を決めてから選ぶ

購入・自作・開発依頼は、変えたい範囲から選ぶ

MetaTrader 5の公式入手ガイドでは、Marketの製品、Code Baseのソース、Freelanceでの開発依頼、自分でMQL5を使う方法が案内されています。どれも利用できる可能性がありますが、確認する対象は同じではありません。

手段の名前だけで選ばない
選択肢	合うかを考える場面	自分が確認すること
既製EAを購入・利用する	説明された売買ルールや入力で、必要な動作を満たせる	機能・対応環境・利用条件・作者のサポート範囲
自分で作成・修正する	ルールをコードにでき、修正や検証にも取り組める	使うソースの条件、開発環境、注文と異常時処理の確認
開発を依頼する	実装してほしいルールを、仕様として具体的に伝えられる	納品物・変更条件・受入基準・修正と保守の分担

既製EAで数量や稼働時間を変えられても、売買ルール全体を自由に変更できるとは限りません。ほしい動作が入力欄の調整で足りるなら、説明書と作者への確認から進めます。ソースからルールを変更する必要があるなら、入手・変更の条件と実装する担当を確認します。

自作には、条件をコードへ起こすだけでなく、エラーや想定外の注文を調べる作業も伴います。学習から始める場合は、必要な知識と取り組める範囲を整理してから進めましょう。

FX自動売買の参考書おすすめ4冊｜MT4・MT5別の学び方と最初の1冊

先に注文ルールを、文章と例で決める

開発依頼でも「自動で利益を出してほしい」だけでは、何を実装し、どこまでできたら完了なのかが決まりません。新規注文の条件、数量、追加注文、決済、停止、エラー時の対応を具体化します。自作する場合も、この整理が実装と確認の土台になります。

たとえば、同じ条件が何度も続くときに毎回注文するのか、1回だけなのかを決めます。既存の建玉がある場合や、端末を再起動した後の扱いも必要です。銘柄・時間足・時刻の基準・対象の口座と建玉方式も、仕様に含めておきましょう。

仕様と確認結果を対応させる例
仕様にする場面	決めておくこと	確認する結果の例
通常の条件成立	何を合図に、何回・どの数量で処理するか	想定した対象だけに処理し、同じ条件で重複しない
接続断・再起動・エラー	再確認する状態、再送する条件、記録する情報	既存の注文・建玉を照合し、不要な再注文をしない
停止・数量上限	新規だけ止めるか、既存建玉を誰が管理するか	上限や停止条件が守られ、残る建玉の扱いが説明できる

この表は仕様を整理する例で、推奨する売買戦略ではありません。実際の数量や損切り条件は、利用者がリスクを理解して決める必要があります。未決の項目が多ければ、注文する前に仕様の相談範囲と見積もりの前提を明確にします。

MQL5 Freelanceの現行規則も、要求事項を仕様書へまとめる形を取っています。同サービスの受領や紛争判断の基準になるため、重要な合意を曖昧な説明のまま残さず、仕様として確認します。ここでいう手続きは同サービスのもので、一般の外注契約すべてへ一律に当てはめるものではありません。

ソース・実行ファイル・変更できる権利を分ける

EAの実行ファイルを受け取ることと、プログラムを修正するためのソースを受け取ることは別です。MT4のMQ4・MT5のMQ5がソース、EX4・EX5がコンパイルした実行形式という違いを確認しましょう。実行形式だけで、利用者がルールを自由に書き換えられるわけではありません。

Marketについては、利用条件にある製品の使用ライセンスを確認します。完成したEAを使う権利を得ることを、ソースの所有や再配布・改変の権利をすべて得ることと同一視しません。

開発依頼では、ソースと実行ファイルのどちらを納品するか、説明書・設定例・対応環境も含むかを事前に確認します。将来、別の開発者へ修正を頼めるようにしたいなら、ソースを受け取れるかだけでなく、変更や第三者への提供が許される範囲も確認してください。

ソースを受け取っても、使う外部ライブラリや開発環境、版の情報がなければ、同じ状態を再現できない場合があります。権利の扱いと、技術的に再ビルド・修正できることを分けて考えましょう。無償で公開されたソースでも、利用条件と動作の確認は必要です。

納品物と保守の約束は別

ソース納品を受けても、将来のMT4・MT5や取引会社側の変更へ無料で対応する契約とは限りません。修正対象、連絡方法、対応する期間、追加費用が発生する範囲を、購入・依頼の条件で確認します。

動作確認・修正対応・費用を利用期間で考える

納品後は、仕様どおりかを確かめて受領する「検収」が必要です。バックテストの利益が多かったという理由だけで完了にせず、仕様に挙げた正常時・重複時・接続断・停止後の処理を確認します。利用予定と同じ口座条件のデモで、数量・建玉・エラーとログを照合してください。

MQL5 Freelanceでは、Work Acceptance後の支払いなど、工程と手続きが規則に定められています。確認を終えていないのに、単にファイルを受け取ったという理由だけで受領を判断せず、合意した仕様と結果を照らして確認します。不具合修正と、あとから追加したい新機能も区別しておきましょう。

比較する費用も、EAの本体価格や初回の開発費だけではありません。必要なVPS、外部サービス、修正、更新、将来の保守の範囲を確認します。金額や納期がまだ提示されていない段階で「買う方が必ず安い」「自作なら費用ゼロ」と決めつけないことが大切です。

作成を依頼しても、運用判断や口座の管理まで任せる契約になるわけではありません。停止・再開、残る建玉、資金の余力を誰が確認するかは利用者側でも整理します。完成したプログラムの動作確認と、将来の利益が出るかの評価は別です。