EA開発でトラブルを避けるための仕様書の作り方

EA開発でトラブルを避けるためには、依頼前に仕様書を整理しておくことが重要です。

「エントリー条件だけ」「画像だけ」「このインジと同じように」などの説明だけでは、開発側が判断する範囲が広くなり、完成後に「思っていた動きと違う」「通知の条件が違う」「決済の優先順位が違う」「ログで原因を追えない」といったズレが起きやすくなります。

EAの仕様書では、売買条件だけでなく、シグナル判定、発注処理、ロット管理、決済、停止条件、通知、外部連携、チャート表示、ログ、バックテスト条件、納品物、サポート範囲を分けて整理する必要があります。

この記事では、EA開発でトラブルを避けるための仕様書の作り方を、依頼者側・開発者側の両方で確認しやすい形に整理します。

なお、この記事はMT4/MT5、MQL4/MQL5、EA、インジケーター、コピーEA、通知・診断・補助ツールの開発依頼前整理を目的とした技術記事です。投資助言、売買指示、利益保証、勝率保証、損失回避保証、推奨ロット、推奨銘柄、推奨エントリー、特定ブローカー誘導を目的としたものではありません。

EA開発で仕様書が必要な理由

EAは、相場を見て自動的に判断しているように見えても、実際には決められた条件に従って処理を行うプログラムです。

そのため、どの条件でシグナルを出すのか、どのタイミングで発注するのか、注文できない時にどう扱うのか、どの条件で決済するのか、どのログを残すのかを事前に決めておく必要があります。

仕様書に必ず入れたい基本情報

仕様書の冒頭では、対象となるEAの基本情報を整理します。ここが曖昧だと、MT4用なのかMT5用なのか、新規作成なのか既存改修なのか、どの銘柄や時間足で使うのかが分からなくなります。

EAの責務を分けて書く

EA仕様書では、すべてを「売買条件」としてまとめず、役割ごとに分けて書くことが重要です。

特に、シグナル判定と発注処理、リスク管理と決済処理、通知と外部連携、表示と内部判定を混同すると、実装後の確認が難しくなります。

シグナル条件の書き方

シグナル条件は、「買い」「売り」「見送り」を判断するための条件です。仕様書では、BUY条件とSELL条件を分け、どの足で判定するのか、確定足か現在足か、複数条件をANDで見るのかORで見るのかを明確にします。

シグナル条件は、チャート上の見た目だけで判断せず、数値条件として書ける形にすることが重要です。画像で説明する場合でも、どの足のどの価格、どのインジケーター値、どのタイミングを見ているのかを補足してください。

発注処理の書き方

発注処理では、シグナルが成立した後に、どの注文を出すのかを決めます。シグナルが成立していても、ロット、証拠金、スプレッド、取引時間、最大ポジションなどで発注を見送る場合があります。

決済条件の書き方

決済条件は、EAの挙動に大きく影響します。TPとSLだけでなく、内部決済、トレーリング、建値移動、反対サイン決済、時間決済、バスケット決済、一括決済などを分けて書いてください。

複数の決済条件がある場合は、優先順位を必ず書いてください。たとえば、強制損切り、手動全決済、内部決済、トレーリング、通常TPが同時に関係する場合、どれを先に処理するかで結果が変わります。

リスク管理・停止条件の書き方

EA仕様書では、リスク管理や停止条件も重要です。EAが注文する条件だけでなく、注文しない条件、止める条件、通知だけ行う条件を分けてください。

通知・外部連携の書き方

Discord通知、Google Sheets連携、CSV出力、外部シート制御、ライセンス認証を使う場合は、売買ロジックとは別に仕様を書きます。

外部連携では、送信内容、送信タイミング、送信先、失敗時の扱い、通知頻度、認証情報の扱いを明確にしてください。

表示・パネルUIの書き方

チャート上にボタン、パネル、ラベル、ライン、損益情報、状態表示を出すEAでは、UI仕様を別に整理します。

表示内容と内部判定を混同すると、表示が変わっただけでロジックが変わったように見えることがあります。表示系と判定系は分けて書いてください。

ログ仕様の書き方

EA開発では、ログ仕様を最初から決めておくと、不具合調査や納品後の確認がしやすくなります。

ログは多ければよいわけではありません。初期化、設定読込、シグナル判定、発注前チェック、注文結果、決済理由、外部連携、エラー、停止理由を追える粒度で整理します。

バックテストではログ量が多すぎると検証速度に影響する場合があります。通常ログ、詳細ログ、バックテスト用簡易ログを分ける仕様にしておくと、運用と検証の両方で確認しやすくなります。

Inputs・setファイルの書き方

EA仕様書では、ユーザーが変更するinput、固定値にする項目、開発中だけ見せる項目を分けて整理します。

販売用や配布用のUserLive版では、endpoint、token、内部固定値、危険な検証スイッチを見せない方がよい場合があります。一方、AdminDev版では検証のために詳細inputを残す場合があります。

検証条件・完成判定の書き方

EA開発では、何をもって完成とするかを事前に決めておくことが重要です。

コンパイルエラーがないことは最低条件ですが、それだけでは完成とはいえません。初期化、設定読込、注文前チェック、注文結果、決済、通知、ログ、バックテスト、デモ確認などを分けて確認します。

よくある仕様書の不足例

仕様書が曖昧な場合、完成後に修正範囲や追加費用、確認範囲で認識違いが起きやすくなります。以下のような不足がないか確認してください。

仕様書テンプレート

以下の項目を埋める形にすると、EA開発依頼前の整理が進めやすくなります。すべてを最初から完璧に書く必要はありませんが、不明点は「未定」「相談したい」として残してください。

【1. 依頼概要】
・依頼区分：
・MT4 / MT5：
・新規作成 / 既存改修：
・対象ファイル：
・対象銘柄：
・時間足：
・利用環境：

【2. EAの目的】
・完全自動 / 半裁量 / 裁量補助 / 決済補助 / 通知 / 記録：
・このEAで実現したいこと：
・このEAで行わないこと：

【3. signal】
・BUY条件：
・SELL条件：
・判定足：
・使用インジケーター：
・フィルター：
・同時成立時の扱い：

【4. execution】
・注文タイプ：
・ロット計算：
・Magic Number：
・最大ポジション：
・スプレッド制限：
・取引時間：
・注文失敗時の扱い：

【5. risk】
・最大ロット：
・最大損失：
・含み損制限：
・連敗停止：
・外部停止：
・復帰条件：

【6. exit】
・TP：
・SL：
・トレーリング：
・建値移動：
・反対サイン決済：
・時間決済：
・一括決済：
・決済優先順位：

【7. notification / external】
・通知先：
・通知条件：
・WebRequest：
・Google Sheets：
・CSV出力：
・外部シート制御：
・認証：

【8. UI / 表示】
・パネル：
・ボタン：
・ライン：
・ラベル：
・色：
・削除時の扱い：

【9. log】
・INIT：
・SELFCHECK：
・GATE：
・ENTRY：
・EXIT：
・RISK：
・ERROR：
・外部連携ログ：

【10. 検証】
・バックテスト条件：
・デモ確認条件：
・確認するログ：
・確認するスクリーンショット：
・完成判定：

【11. 納品物】
・ex4 / ex5：
・mq4 / mq5：
・setファイル：
・簡易マニュアル：
・更新履歴：
・サポート範囲：

送らない方がよい情報

仕様書、setファイル、ログ、スクリーンショットを共有する時は、機密情報をそのまま含めないようにしてください。

相談前に確認する関連ページ

EA開発の仕様書を整理する時は、開発相談ページ、資料整理ページ、EA開発依頼前チェック、ログ確認、setファイル確認、不具合報告のページもあわせて確認してください。

よくある質問

仕様書がない状態でもEA開発を相談できますか？

相談は可能です。ただし、仕様書がない場合は、目的、対象銘柄、時間足、エントリー条件、決済条件、通知の有無、ログの有無、現在困っていることを分かる範囲で整理してください。内容が曖昧な場合は、まず仕様整理から進める形になります。

画像や動画だけで仕様書の代わりになりますか？

参考資料にはなりますが、画像や動画だけでは条件を正確に実装できない場合があります。どのタイミングで、どの条件が成立し、どの処理を行うのかを文章や表で補足してください。

売買ロジックの相談もできますか？

依頼者が指定した条件を技術仕様として整理し、EAとして実装する相談は可能です。ただし、売買判断、相場予測、利益保証、勝率保証、推奨ロット、推奨銘柄、推奨エントリーの提示は行いません。

既存EAのex5ファイルだけでも仕様書を作れますか？

ex5ファイルだけでは内部ロジックを直接確認できません。動作を観察して仕様を再整理することはできますが、内部処理の完全な再現や保護解除を前提とした改修には対応できません。mq5やmqhなどのソースコードがあるか確認してください。

仕様変更と不具合修正はどう分けますか？

事前に合意した仕様どおりに動かない場合は不具合確認の対象です。一方、当初仕様にない条件追加、通知追加、表示変更、ロジック変更、外部連携追加は仕様変更として扱う場合があります。仕様書に完成判定とサポート範囲を書いておくと分けやすくなります。

まとめ

EA開発でトラブルを避けるためには、売買条件だけでなく、signal、execution、risk、exit、notification、external control、UI、log、validationを分けて仕様書に整理することが重要です。

特に、確定足か現在足か、BUY条件とSELL条件、発注前チェック、Magic Number、決済優先順位、通知条件、外部連携失敗時の扱い、ログ仕様、完成判定は、後から認識違いが起きやすい部分です。

仕様書を用意する時は、対象環境、対象銘柄、時間足、エントリー条件、決済条件、リスク管理、通知、外部連携、表示、ログ、検証条件、納品物、サポート範囲を分けて整理してください。

Webhook URL、GAS URL、APIキー、認証トークン、VPSログイン情報、口座番号などの機密情報は、そのまま共有しないようにしてください。技術確認に必要な情報と、共有すべきでない情報を分けることも、EA開発依頼前の重要な準備です。