MQL5商品化・配布前チェック実務ノート｜Inputs・HELP・Snapshot・manual・UserLive化の基本

MQL5でEAやインジケーターを作る時、開発中に動くことと、商品として配布できることは別です。

開発者の手元では動いていても、購入者や利用者が使う段階になると、Inputs欄が分かりにくい、初期値の意図が伝わらない、ログが多すぎる、HELPがない、エラー時に何を送ればよいか分からない、AdminDev用の設定が残っている、といった問題が出ることがあります。

商品化・配布前チェックで重要なのは、開発者用の状態と利用者用の状態を分けることです。AdminDevでは詳細確認し、UserLiveでは利用者が迷わない範囲に整理します。

この記事では、MQL5 EA・インジを商品化・配布する前に確認したいInputs、HELP、Snapshot、manual、AdminDev/UserLive分離、ログ粒度、販売後サポート導線を、開発実務ノートとして整理します。

完成EAソース全文、外部シート制御ロジック、認証ロジック、endpoint、token、URL実値、実運用set値、中核Entry条件は公開しません。本記事は、投資判断や売買指示ではなく、MQL5 EA・インジの商品化前チェックを整理するための技術記事です。

この記事で扱う実務課題

なぜ商品化前チェックが必要なのか

EAやインジは、開発中は開発者が直接ログを見て、設定を調整し、異常があればその場で原因を確認できます。

しかし、商品化・配布後は状況が変わります。利用者は内部仕様を知りません。ログの読み方も分からない場合があります。設定項目が多すぎると、意図しない変更で不具合に見える動作が起きる可能性があります。

商品化前チェックは、単に見た目を整える作業ではありません。利用者が安全に導入し、問題発生時に必要情報を送れるようにするための設計です。

AdminDevとUserLiveを分ける

商品化・配布前に必ず整理したいのが、AdminDevとUserLiveの分離です。

AdminDevは、開発者や管理者が検証するための版です。詳細ログ、外部連携確認、診断、開発用設定を多めに持ちます。

UserLiveは、利用者向けの配布版です。利用者が触るべきInputsだけを見せ、不要な設定、機密情報、開発用ログ、危険な切替を隠します。

AdminDevのまま配布すると、利用者が触る必要のない項目が見えてしまいます。UserLive化では、利用者が迷わず、かつサポートに必要な情報は取得できる状態にします。

Inputs欄は利用者向けに整理する

Inputs欄は、利用者が最初に触れる設定画面です。

ここが分かりにくいと、設定ミス、問い合わせ増加、意図しない挙動につながります。

開発中に必要なInputsと、利用者に見せるInputsは同じではありません。配布前には、利用者が触るべき項目と、固定すべき項目を分けます。

input初期値とruntime状態を混同しない

商品化前チェックでは、input初期値とruntime状態を混同しないことも重要です。

input初期値は、EA起動時に読み込まれる設定値です。一方、runtime状態は、EA稼働中に変化する現在状態です。

利用者に「この値です」と説明する時、それがinput初期値なのか、runtimeで変化した状態なのかを分けて説明できる必要があります。

HELP導線を用意する

HELPは、利用者が迷った時に確認するための導線です。

EAやインジ内にHELPログ、チャートコメント、manualへの案内、問い合わせ前チェックの案内を用意しておくと、サポート時のやり取りを減らせます。

HELPは長すぎる必要はありません。最初に何を見るか、問題が起きた時に何を送るかが分かるだけでも効果があります。

Snapshotで問い合わせ前の状態を共有する

Snapshotは、EAやインジの現在状態を要約したものです。

問い合わせ時に「動きません」とだけ送られても、原因は分かりません。Snapshotがあれば、現在のruntime状態、設定状態、停止理由、保有状態、ログモードなどを共有しやすくなります。

Snapshotは、機密情報をそのまま出すものではありません。endpoint、token、口座番号、顧客情報などは必ずマスクします。

manualは短くても必要

商品化・配布前には、manualを用意します。

最初から長い説明書を作る必要はありません。まずは、利用者が導入し、基本設定し、問題が起きた時に必要情報を送れる内容があれば十分です。

manualは、販売ページとは別に、利用者が導入後に確認できる実務資料として用意します。

実コード例1：配布プロファイルを分ける

以下は、設計判断を理解するために一般化した学習用コード例です。完成EAのソース全文ではありません。

// 学習用に一般化した配布プロファイル例です。
// 実運用EAの完成ソースではありません。

enum BuildProfile
{
   BUILD_PROFILE_ADMINDEV = 0,
   BUILD_PROFILE_USERLIVE
};

struct ReleaseProfile
{
   BuildProfile profile;
   bool showDeveloperLogs;
   bool showAdvancedSettings;
   bool allowExternalDiagnostics;
   string supportMode;
};

ReleaseProfile BuildReleaseProfile(BuildProfile profile)
{
   ReleaseProfile result;
   result.profile = profile;
   result.showDeveloperLogs = false;
   result.showAdvancedSettings = false;
   result.allowExternalDiagnostics = false;
   result.supportMode = "USER";

   if(profile == BUILD_PROFILE_ADMINDEV)
   {
      result.showDeveloperLogs = true;
      result.showAdvancedSettings = true;
      result.allowExternalDiagnostics = true;
      result.supportMode = "ADMINDEV";
   }

   return result;
}

この例では、AdminDevとUserLiveで表示するログや詳細設定を分けています。実際の認証処理、endpoint、token、外部制御詳細は扱っていません。

実コード例2：配布前selfcheckを行う

以下は、設計判断を理解するために一般化した学習用コード例です。完成EAのソース全文ではありません。

// 学習用に一般化した配布前selfcheck例です。
// 実運用EAの完成ソースではありません。

struct ReleaseSelfCheckResult
{
   bool ok;
   string reason;
};

ReleaseSelfCheckResult RunReleaseSelfCheck(const ReleaseProfile &profile)
{
   ReleaseSelfCheckResult result;
   result.ok = true;
   result.reason = "SELF_CHECK_OK";

   if(profile.profile == BUILD_PROFILE_USERLIVE &&
      profile.showDeveloperLogs)
   {
      result.ok = false;
      result.reason = "USERLIVE_DEV_LOG_VISIBLE";
      return result;
   }

   if(profile.profile == BUILD_PROFILE_USERLIVE &&
      profile.showAdvancedSettings)
   {
      result.ok = false;
      result.reason = "USERLIVE_ADVANCED_SETTING_VISIBLE";
      return result;
   }

   return result;
}

void PrintReleaseSelfCheck(const ReleaseSelfCheckResult &check)
{
   Print("DIAG/RELEASE_CHECK: event=",
         (check.ok ? "OK" : "NG"),
         " reason=", check.reason);
}

この例では、UserLive版で開発者向けログや詳細設定が見えていないかを確認しています。

配布前selfcheckでは、利用者向けに出してよい項目と、隠すべき項目を確認します。

実コード例3：HELPログを出す

以下は、設計判断を理解するために一般化した学習用コード例です。完成EAのソース全文ではありません。

// 学習用に一般化したHELPログ例です。
// 実運用EAの完成ソースではありません。

void PrintHelpSummary()
{
   Print("DIAG/HELP: event=GUIDE",
         " step=1",
         " message=Check AutoTrading, symbol, timeframe, and Inputs.");

   Print("DIAG/HELP: event=GUIDE",
         " step=2",
         " message=If a problem occurs, save Experts log, Journal log, set file, and screenshot.");

   Print("DIAG/HELP: event=GUIDE",
         " step=3",
         " message=Mask account number, token, endpoint, and personal information before sharing.");
}

HELPログは、利用者が何を確認すればよいかを案内するために使います。

長文である必要はありません。起動確認、ログ保存、問い合わせ前のマスク対象を案内できれば、サポート時に役立ちます。

実コード例4：問い合わせ用Snapshotを出す

以下は、設計判断を理解するために一般化した学習用コード例です。完成EAのソース全文ではありません。

// 学習用に一般化した問い合わせ用Snapshot例です。
// 実運用EAの完成ソースではありません。

struct SupportSnapshot
{
   string version;
   string symbol;
   string timeframe;
   string runtimeStatus;
   string lastReason;
   string logMode;
};

SupportSnapshot BuildSupportSnapshot()
{
   SupportSnapshot snap;
   snap.version = "sample";
   snap.symbol = _Symbol;
   snap.timeframe = EnumToString((ENUM_TIMEFRAMES)Period());
   snap.runtimeStatus = "READY";
   snap.lastReason = "OK";
   snap.logMode = "SUMMARY";

   return snap;
}

void PrintSupportSnapshot(const SupportSnapshot &snap)
{
   Print("DIAG/SNAPSHOT: event=SUPPORT",
         " version=", snap.version,
         " symbol=", snap.symbol,
         " timeframe=", snap.timeframe,
         " status=", snap.runtimeStatus,
         " reason=", snap.lastReason,
         " log_mode=", snap.logMode);
}

問い合わせ用Snapshotには、原因調査に必要な状態を入れます。ただし、口座番号、token、endpoint、Webhook URL、GAS URL、顧客情報などは含めません。

販売後サポート導線を設計する

商品化では、販売前のページだけでなく、販売後サポートの導線も重要です。

利用者が問題を報告する時に、何を送ればよいかが分かっていないと、調査が進みません。

商品化前には、EA本体だけでなく、販売ページ、manual、FAQ、問い合わせフォーム、免責ページのつながりも確認します。

配布前に隠すべき情報

配布前には、利用者に見せてはいけない情報が残っていないかを確認します。

特に、ログ、Inputs、チャート表示、manual、スクリーンショットに機密情報が出ないように確認します。

よくある失敗例

失敗1：AdminDevのまま配布する

開発者向けの詳細ログ、外部診断、危険な切替、endpoint確認項目が見えたままになる可能性があります。UserLive化してから配布します。

失敗2：Inputsが多すぎる

利用者がどれを触ればよいか分からなくなります。基本設定、リスク設定、表示設定、通知設定、詳細設定のように分類し、不要な項目は隠します。

失敗3：HELPがない

初回導入時や不具合時に、利用者が何を確認すればよいか分かりません。HELPログ、manual、FAQへの導線を用意します。

失敗4：Snapshotがない

問い合わせ時に現在状態を共有できません。version、symbol、timeframe、runtime status、last reason、log modeなどを要約できるようにします。

失敗5：manualが販売ページの説明だけになっている

販売ページは購入前説明、manualは導入後の実務資料です。導入、更新、確認、問い合わせ手順を分けて用意します。

失敗6：ログに機密情報が出る

endpoint、token、Webhook URL、GAS URL、口座番号、顧客情報がログへ出ると危険です。配布前にマスク方針を確認します。

失敗7：推奨値が売買助言に見える

実運用set値、推奨ロット、推奨銘柄、利益期待に見える表現は避けます。技術的な初期値や検証用条件として説明する場合も、投資助言に見えないよう注意します。

導入前・開発依頼前に整理する情報

EAやインジを商品化・配布する前には、次の情報を整理しておくと確認がスムーズになります。

• 配布対象はAdminDevかUserLiveか
• 利用者に見せるInputs
• 非表示にするInputs
• Inputsの表示順と日本語表記
• 安全側の初期値
• HELPログで案内する内容
• Snapshotに含める項目
• manualに入れる導入手順
• 更新時の手順
• 不具合報告時に送ってもらう情報
• ログ粒度
• 配布版で出してよいログ
• 隠すべきendpoint、token、URL、顧客情報
• 販売ページ、FAQ、問い合わせフォーム、免責ページの導線

商品化・配布前チェックは、EA本体だけで完結しません。利用者が導入し、確認し、問題が起きた時に必要情報を送れる流れまで設計します。

関連する技術講座・確認ページ

FAQ

開発中に動いていれば、そのまま配布してもよいですか？

避けた方が安全です。開発中に必要なInputs、詳細ログ、外部診断、開発用設定が利用者向けに残っている可能性があります。UserLive化してから配布前チェックを行います。

Inputsは多い方が便利ではありませんか？

開発者には便利でも、利用者には迷いの原因になる場合があります。利用者が触るべき項目、固定すべき項目、非表示にする項目を分けることが重要です。

HELPログは必要ですか？

必要です。HELPログやmanualへの案内があると、初回導入時や問い合わせ前に利用者が確認しやすくなります。サポート対応の効率も上がります。

Snapshotには何を入れるべきですか？

version、symbol、timeframe、runtime status、last reason、log mode、position summaryなど、問い合わせ時に状態把握できる情報を入れます。ただし、口座番号、token、endpoint、顧客情報は入れません。

AdminDevとUserLiveは必ず分けるべきですか？

販売や配布を前提にするなら分けた方が安全です。AdminDevは検証・診断向け、UserLiveは利用者向けとして、見せるInputsやログ粒度を変えます。

manualはどのくらい作ればよいですか？

最初は短くても構いません。導入手順、基本設定、正常起動確認、不具合報告時に送る情報、注意事項があれば実務上使いやすくなります。

ログにendpointやtokenを出してもよいですか？

出してはいけません。endpoint、token、Webhook URL、GAS URL、Google Sheet ID、口座番号、顧客情報は、ログ、画面表示、manual、スクリーンショットに出ないようにします。

推奨set値を配布してもよいですか？

技術的な初期値や検証用設定として扱う場合でも、利益保証、勝率保証、推奨ロット、推奨銘柄、売買助言に見えない表現にする必要があります。実運用値の公開は慎重に扱います。

関連する開発実務ノート

商品化・配布前チェックでは、ログ設計、長時間稼働、バックテスト、MT4資産のMT5再設計も重要です。販売後サポートを見据えて、関連する設計観点も確認してください。

• MQL5ログファースト開発実務ノート｜不具合調査しやすいEA・インジの作り方
• MQL5長時間稼働EA実務ノート｜フリーズ・重い・オブジェクト残存を防ぐ考え方
• MQL5バックテスト実務ノート｜検証条件・最適化・リアル差分を記録する考え方
• MT4資産をMT5へ作り直す実務ノート｜移植ではなく再設計で考える理由

まとめ

MQL5 EA・インジの商品化・配布前チェックでは、開発中に動くことだけでなく、利用者が迷わず導入し、問題発生時に必要情報を共有できることが重要です。

特に、次の4点を分けると、販売後サポートや不具合調査がしやすくなります。

• Inputs：利用者が触る項目、固定する項目、隠す項目を整理する
• HELP：初回確認、ログ確認、問い合わせ前の手順を案内する
• Snapshot：現在状態を要約し、問い合わせ時に共有できるようにする
• AdminDev / UserLive：開発者向け検証版と利用者向け配布版を分ける

また、manual、FAQ、問い合わせフォーム、免責ページとの導線も重要です。EA本体だけでなく、導入後の確認・更新・不具合報告までを設計しておくことで、利用者の迷いを減らせます。

完成EAの中核ロジックや実運用set値を公開しなくても、Inputs整理、HELP、Snapshot、manual、UserLive化の考え方を理解しておくことで、商品化・配布・販売後サポートの品質を上げやすくなります。