EAの口座縛りとは？コードへ直接書き込む方法と サーバー認証の違い
yukik-aochai
シストレファクトリー
EAの口座認証は再コンパイル不要にできる？サーバー認証との違い
yukik-aochai
EAを販売していると、購入者の追加や口座変更のたびに、mq5を修正してex5を再コンパイル・再配布する作業が発生することがあります。
この手間は、許可する口座番号をEAのソースコードへ直接書き込む、いわゆるコード固定型の口座認証で起こりやすい問題です。
購入者が増えるたびに、毎回EAを作り直して送らないといけないんですか？
口座番号をコードへ固定する方式なら、その作業が必要になりやすいですね。初回にサーバー認証を実装しておけば、購入者追加や口座変更のためだけに再コンパイルする運用は減らせます。
結論から言うと、EAの口座認証は購入者追加・口座変更のためなら再コンパイル不要の運用にできます。
この記事で分かること
- 購入者追加のたびに再コンパイルが必要になる理由
- 口座番号をmq5へ直接書く認証方式の問題点
- サーバー認証なら再コンパイルを減らせる理由
- 口座変更・利用期限・遠隔停止を管理する方法
- MQLAuthが向いている販売者の特徴
結論：認証情報をサーバー側で管理すれば再コンパイルを減らせる
許可する口座番号をmq5へ直接書く方式では、購入者の追加や口座変更のたびに、ソースコードの修正とex5の再コンパイルが必要になります。
一方、サーバー認証では、EA側へ認証処理を一度実装し、許可する口座番号や利用状態はサーバー側で管理します。
そのため、購入者を追加したときや、利用者が登録口座を変更したときでも、認証情報の変更だけを理由にex5を作り直して送る必要がありません。
なぜ口座番号をコードへ固定すると再コンパイルが必要なのか
一般的な口座縛りでは、許可するMT5口座番号をmq5のソースコードへ直接書き込みます。
その状態でコンパイルして作成したex5ファイルは、コード内に書かれた口座番号だけを許可するEAになります。
コード固定型の口座認証の流れ
- 販売者がmq5へ許可口座番号を書き込む
- コンパイルしてex5ファイルを作成する
- 購入者へex5ファイルを配布する
- EAが起動時に、現在ログインしているMT5口座番号を確認する
- コード内の許可口座番号と一致したときだけEAを利用できる
新しい購入者を追加する場合は、その購入者の口座番号をmq5へ追加し、新しいex5ファイルを作成します。
既存購入者が古いex5を使い続けられる設計もありますが、販売者側ではどの購入者にどのファイルを渡したかを管理する必要があります。全利用者へ同じ最新版を配る運用にする場合は、既存購入者への更新案内も必要です。
コード固定型の口座縛りを詳しく見る
EAの口座縛りとは？コードへ直接書き込む方法と サーバー認証の違い
再コンパイルが発生しやすい4つの場面
新しい購入者を追加するとき
コード固定型では、新しい購入者の口座番号を許可リストへ追加し、ex5を作り直す必要があります。
販売数が増えるほど、mq5の編集、コンパイル、配布履歴の管理に時間がかかります。
購入者が口座を変更するとき
購入者がFX会社を変更した、口座を作り直した、デモ口座からリアル口座へ移行した場合は、許可口座番号を変更する必要があります。
新しい口座番号を追加して旧口座を残すと、利用できる口座が増え続けます。旧口座を無効にして新しい口座へ差し替える管理も必要です。
利用停止や期限変更をしたいとき
返金対応、規約違反、体験版の終了などで利用を止めたい場合も、コードへ口座番号を固定するだけでは対応しにくいことがあります。
特定の口座を許可リストから外した新しいex5を作成しても、対象者がすでに受け取った古いex5を使い続けている限り、そのファイルを遠隔で止めることはできません。
アップデートやバグの修正を行った時
配布ツールのアップデートやバグの修正を行った場合、修正後のコードに利用者の口座番号を入力して再配布し直す必要があります。
利用者の多いツールの場合、再配布の手間が大きいため、小さなバグは見逃したままになることも多いです。
サーバー認証なら口座情報をex5の外で管理できる
サーバー認証では、許可する口座番号の一覧をmq5へ固定しません。
代わりに、EAまたはインジケーターへサーバー認証の処理を実装し、利用できる口座番号や利用状態はサーバー側の管理画面で管理します。
サーバー認証の運用イメージ
- EAへサーバー認証の処理を一度だけ実装する
- 認証済みのex5ファイルを購入者へ配布する
- 購入者の口座情報はサーバー側で登録・変更する
- EAは認証結果に応じて利用可否を判断する
- 口座追加や変更のためにex5を作り直さずに済む
MQLAuthなら認証情報の変更をサーバー側で管理できる
MQLAuthは、EA・インジケーター販売者向けのサーバー認証システムです。
EAのmq5へ購入者ごとの口座番号を直接書き込むのではなく、MQLAuthの管理画面で利用者と口座番号を管理します。
そのため、購入者の追加や登録口座の変更があっても、認証情報のためだけにEAを再コンパイルして配り直す運用を減らせます。
MQLAuthを使った口座変更の運用
MQLAuthでは、利用者向けの口座変更機能を使い、利用者自身で変更手続きを進める運用ができます。販売者がDMやメールで口座番号を回収し、個別にex5を作り直して送る作業を減らせます。
さらにMQLAuthでは、口座番号認証だけでなく、販売後の利用者管理までまとめて行えます。
購入者管理が必要になるほど、口座番号認証だけでなく、期限・停止・案内まで一元管理できることが重要になります。
MQLAuthの認証実装は、EAまたはインジケーターのソースコードと認証実装用プロンプトをChatGPTやClaudeなどへ渡し、AIを使って進める運用を想定しています。
再コンパイル不要の口座認証が向いているケース
- EA・インジケーターを継続して販売・配布している
- 購入者の追加や口座変更が定期的に発生する
- 同じex5ファイルを複数の購入者へ配布したい
- 体験版や月額販売で利用期限を管理したい
- 返金対応・規約違反時などに利用を遠隔停止したい
- アップデート情報を利用者へ案内したい
反対に、販売数が少なく、購入者ごとに個別のex5ファイルを渡す運用でも問題がない場合は、口座番号をコードへ固定する方式でも対応できることがあります。
再コンパイル不要の認証運用を始める前のチェックリスト
- mq5のソースコードを保有している
- 初回の認証実装・コンパイルが必要なことを理解している
- 購入者追加・口座変更のたびに再コンパイルする負担を確認した
- 認証情報をサーバー側で管理する運用を検討している
- 利用者自身で口座変更できる仕組みが必要か確認した
- 利用期限・体験版・月額販売の管理が必要か確認した
- 配布済みEAを遠隔停止する必要があるか確認した
- アップデート案内をMT5チャートへ表示したいか確認した
よくある質問
- サーバー認証なら一度も再コンパイルせずに使えますか？
-
最初にサーバー認証をEA・インジケーターへ実装するときは、ソースコードの修正とコンパイルが必要です。その後は、口座追加・口座変更・利用期限・利用停止などの認証情報を変更するための再コンパイルを減らせます。
Q
- ex5ファイルだけでもサーバー認証を追加できますか？
-
通常はmq5のソースコードが必要です。ex5ファイルだけでは、認証処理を追加するための修正と再コンパイルができません。
Q
- 購入者が口座を変更した場合はどうなりますか？
-
口座番号をmq5へ固定する方式では、許可口座番号を書き換えて再コンパイルし、新しいex5ファイルを配布する必要があります。MQLAuthでは、利用者向けの口座変更機能を使い、利用者自身で変更手続きを進める運用ができます。
Q
- 利用期限の設定や、配布済みEAの停止もできますか？
-
MQLAuthでは、利用期限を設定して期限終了後にEA・インジケーターを自動停止する運用や、販売者の判断で配布済みのEA・インジケーターを遠隔停止する運用ができます。
Q
- アップデート情報を利用者へ知らせることはできますか？
-
MQLAuthでは、利用者のMT5チャートへ一斉メッセージを配信したり、新バージョンや更新情報を案内したりできます。
Q
まとめ
口座番号をmq5へ直接書く認証方式では、購入者の追加や口座変更のたびに、許可口座の更新、再コンパイル、ex5ファイルの再配布が必要になりやすくなります。
サーバー認証を使えば、最初に認証処理を実装した後は、口座番号や利用状態をサーバー側で管理できます。
EA・インジケーターを継続して販売する場合は、口座変更、利用期限、遠隔停止、アップデート案内まで管理できるMQLAuthのようなサーバー認証が向いています。
