EAの口座縛りとは？コードへ直接書き込む方法と サーバー認証の違い

EAを販売・配布するとき、「購入者へ渡したEX5ファイルを、別の人や別の口座で使われないようにしたい」と考える方は多いのではないでしょうか。

そのようなときに使われる方法の一つが、EAの口座縛りです。

カオチャイ

口座縛りは、ex5ファイルの中に口座番号を書いておく方法ですよね？

YUKI

考え方は近いです。厳密には、EAのソースコードへ許可する口座番号を書き込み、コンパイルしてex5ファイルへ固定する方法です。購入者が増えるほど、口座番号の管理や再コンパイルの手間が増えていきます。

EAの口座縛りとは、指定したMT5口座でのみEAを利用できるようにする認証方法です。

この記事では、一般的なソースコード固定型の口座縛りの仕組みを先に解説し、その後に、サーバー側で口座を管理するMQLAuthとの違いを説明します。

EAの口座縛りとは？

EAの口座縛りとは、あらかじめ許可したMT5口座でのみEAを動かせるようにする方法です。

購入者へ渡したex5ファイルが第三者へ共有されたとしても、その第三者が使うMT5口座が許可されていなければ、EAの利用を制限できます。

ただし、口座縛りが識別するのは購入者本人ではなく、MT5口座です。ex5ファイル自体のコピーを物理的に防ぐものではありません。

そのため口座縛りは、ファイルが渡っても、登録していない口座ではEAを使わせないための利用制限として考えるのが適切です。

一般的な口座縛りは、ソースコードへ口座番号を固定する方式

一般的に「EAへ口座縛りを付ける」と言う場合、EAのソースコードであるmq5ファイルへ、許可するMT5口座番号を直接記述する方法を指すことが多いです。

ソースコード固定型の口座縛りが動く流れ

1. 利用者に稼働を許可する口座番号を教えてもらう
2. 販売者がmq5のソースコードへ許可口座番号を書き込む
3. 口座番号を含んだ状態でコンパイルし、ex5ファイルを作成する
4. 購入者へex5ファイルを配布する
5. EAが起動時に、現在ログインしているMT5口座番号を確認する
6. コード内へ書かれた許可口座番号と一致した場合だけ、EAの利用を許可する

許可された口座番号が1つだけであれば、その口座専用のex5ファイルになります。複数の口座番号をコードへ書けば、複数の購入者に同じex5ファイルを配ることもできます。

ただし、購入者を追加したり、口座番号を変更したりする場合は、許可口座の一覧を書き換えて再コンパイルし、新しいex5ファイルを配布し直す必要があります。

ex5ファイルしかないEAには、後から追加しにくい

ソースコードへ口座番号を固定する方式では、mq5ファイルが必要です。

すでにex5ファイルだけがあり、元のmq5ソースコードを持っていない場合は、通常は口座縛りを後から追加できません。

ex5ファイルとソースコードの違いを見る

ex5ファイルしかないEAは改造できる？mq5との違いとデコンパイルできない理由

コード固定型の口座縛りで起こりやすい販売後の負担

ソースコードへ口座番号を直接書く方法は、販売数が少ないうちは管理しやすい方法です。

一方で、購入者や商品数が増えると、口座番号の追加・変更・利用停止のたびに、EAファイルの更新作業が発生しやすくなります。

特に、購入者がFX会社を変えた、デモ口座からリアル口座へ切り替えた、口座を作り直したといった場合は、販売者側の作業が増えます。

また、利用期限の終了、返金対応、規約違反などで利用を止めたい場合も、ex5ファイルへ口座番号を固定しただけでは、販売後の管理が複雑になりがちです。

MQLAuthはサーバー経由で口座を縛る認証方式

MQLAuthは、EA・インジケーターのソースコード内へ許可口座番号を固定するのではなく、サーバー側で許可口座を管理する認証方式です。

EAまたはインジケーターには、MQLAuthサーバーへ認証を確認する処理を実装します。利用者がEA・インジケーターをMT5チャートへ適用すると、現在ログインしているMT5口座番号が自動で取得され、その口座番号をもとにMQLAuthサーバーへ認証確認が行われます。

取得されたMT5口座番号は、MQLAuthの管理画面にも自動で登録されます。販売者は管理画面から、許可する口座番号、利用期限、利用可否などを管理できます。

そのため、購入者の追加や口座変更が発生しても、EAのソースコードへ口座番号を追加して再コンパイルする必要はありません。

また、販売者が毎回手作業で口座番号を登録・変更しなくても、利用者自身で登録口座番号の変更手続きを進められるため、販売後の管理負担を抑えやすくなります。

MQLAuthの認証実装は、EAまたはインジケーターのソースコードとMQLAuth用の実装プロンプトをChatGPTやClaudeなどへ渡し、AIを使って進める運用を想定しています。

AIでMQLAuth認証を実装する流れを見る

AIでMT5 EAに口座認証を実装する方法｜プロンプトを使った認証導入

MQLAuthなら口座認証後の販売管理まで対応できる

EA販売で実際に負担になりやすいのは、口座認証を付ける作業そのものよりも、販売後の口座変更、期限管理、停止対応、アップデート案内です。

MQLAuthでは、口座番号認証に加えて、次のような販売後の管理を行えます。

例えば、購入者が口座を変更するたびにDMで情報を受け取り、販売者が手作業でEAを更新して再送する運用を続ける必要はありません。

また、体験版の期限終了、月額販売の利用停止、返金対応、規約違反時の利用停止、バージョンアップの案内なども、口座認証と同じ管理の流れで扱いやすくなります。

どちらの口座縛りが向いているか

ソースコード固定型が向くケース

• 利用者数が少なく、口座変更もほとんど発生しない
• 購入者ごとに個別EX5ファイルを作成する運用でも問題ない
• 利用期限・遠隔停止・メッセージ配信までは必要ない

MQLAuthが向くケース

• EA・インジケーターを継続的に販売・配布する
• 購入者の追加や口座変更のたびに再コンパイルしたくない
• 体験版、月額販売、利用期限の管理を行いたい
• 配布済みツールを必要に応じて遠隔停止したい
• アップデートや重要なお知らせを利用者へ届けたい

口座縛りを導入する前のチェックリスト

よくある質問

まとめ

一般的なEAの口座縛りは、許可するMT5口座番号をmq5のソースコードへ直接書き込み、コンパイル後のEX5ファイルへ固定する方法です。

この方法は、登録外口座での利用を抑えるために役立ちます。ただし、購入者の追加や口座変更が起きるたびに、ソースコードの修正、再コンパイル、EX5の再配布が必要になりやすい点は確認しておきましょう。

継続販売を行う場合は、口座番号認証だけでなく、利用者自身の口座変更、利用期限の自動停止、遠隔停止、アップデート案内まで管理できるMQLAuthのようなサーバー認証が向いています。

“`