MQL5でSQLiteを使う方法｜EA設計と実装ガイド

この記事の結論

sqlite-mql5で重要なのは、SQLiteを売買シグナルの代替ではなく、EAの状態管理・検証ログ・取引履歴の保存に使う設計です。
MQL5では、データベース接続をOnInitで準備し、OnTickでは短い読み書きだけを行い、OnDeinitで確実に解放する構造が扱いやすくなります。
取引判断、注文前チェック、注文送信、約定後ログを分離すると、バックテストとフォワードテストの差を確認しやすくなります。
ただし、SQLiteへの保存は取引成績を改善する仕組みではありません。実運用ではスプレッド、約定差、ブローカー仕様、VPS環境の安定性を考慮する必要があります。

1. この設計が必要な理由

【結論】
MQL5 EAでSQLiteを使う理由は、EAの判断履歴、状態、検証結果を構造化して残すためです。
ログをPrintだけに依存すると、後から原因を追いにくくなります。SQLiteに保存すると、条件、注文、結果、エラーを同じ形式で比較しやすくなります。

MQL5のEAは、ティックごとにOnTickが呼ばれるイベント型のプログラムです。売買条件だけをOnTickに詰め込むと、なぜエントリーしたのか、なぜ見送ったのか、注文がどの条件で失敗したのかを後から確認しにくくなります。

SQLiteを組み込むと、次の情報をEA内部から保存できます。

• シグナル判定の結果
• フィルター判定の結果
• 注文前チェックの結果
• 注文送信後の戻り値
• ポジション状態
• ドローダウンや停止条件
• バックテストとフォワードテストの比較用データ

【定義】
sqlite-mql5設計とは、MQL5 EAからSQLiteデータベースを使い、売買判断の過程や実行結果を再検証できる形で保存する設計です。

1.1 SQLiteは売買ロジックではなく記録層として使う

SQLiteはデータ保存の仕組みです。SQLiteに過去の履歴を入れるだけで、売買判断の精度が上がるわけではありません。

EA設計では、シグナル判定とデータ保存を分ける必要があります。シグナル判定は相場条件を評価する処理です。SQLiteは、その評価結果を保存する処理です。

1.2 Printログだけでは足りない場面

Printログは簡単ですが、条件別の集計や取引ごとの追跡には向きません。特に、複数通貨EA、複数時間足EA、複数フィルターを持つEAでは、ログ量が増えます。

SQLiteに保存すると、同じ列構造でデータを蓄積できます。これにより、後から「どのフィルターで見送ったのか」「どの条件で注文が失敗したのか」を確認しやすくなります。

2. EA全体の設計思想

【結論】
sqlite-mql5のEA設計では、売買判断、リスク確認、注文処理、データベース保存を分離します。
OnTickは全処理を抱え込む場所ではなく、各モジュールを順番に呼び出す制御点として使うと管理しやすくなります。

基本的な処理順序は次のようになります。

相場認識
↓
フィルター判定
↓
シグナル判定
↓
リスク確認
↓
注文前チェック
↓
注文送信
↓
約定後管理
↓
SQLiteへの保存
↓
停止条件の確認

この流れにすると、データベース保存が売買判断に混ざりにくくなります。EAの目的は取引ルールを実行することであり、SQLiteは判断過程を検証しやすくする補助層です。

2.1 OnInit、OnTick、OnDeinitの役割

MQL5のEAでは、イベント関数の役割を分けることが重要です。

OnTickで重い集計を毎回実行すると、ティック処理が遅くなる場合があります。集計やメンテナンス処理は、必要に応じてOnTimerへ分ける設計が実用的です。

2.2 SQLite保存の対象を決める

保存対象を増やしすぎると、EAの構造が複雑になります。最初は、検証に必要な情報だけを保存します。

• 時刻
• 銘柄
• 時間足
• シグナル方向
• フィルター結果
• 注文前チェック結果
• 注文結果
• エラーコード
• スプレッド
• 有効証拠金
• ポジション数

保存する情報は、後から検証に使う列に限定します。目的のない保存は、実装量と確認負荷を増やします。

3. 基本構造

【結論】
sqlite-mql5の基本構造は、OnInitでデータベースを開き、テーブルを準備し、OnTickやOnTradeTransactionで必要な記録を追加し、OnDeinitで閉じる形です。
データベース処理は、失敗してもEA全体が危険な注文を出さないように設計します。

最小構成は次の4層です。

SQLiteは記録層に置きます。判定層がSQLiteに強く依存すると、データベースの失敗が売買判断に影響しやすくなります。

3.1 テーブル設計の基本

EA用のSQLiteテーブルは、最初から複雑にしないほうが扱いやすくなります。まずは、判定ログと注文ログを分けます。

signal_log
- id
- event_time
- symbol
- timeframe
- signal
- filter_status
- spread
- equity
- comment

trade_log
- id
- event_time
- symbol
- action
- volume
- price
- order_check_status
- order_send_status
- retcode
- comment

判定ログと注文ログを分けると、エントリーしなかった場面も保存できます。EA改善では、注文した場面だけでなく、注文を見送った場面の確認も重要です。

3.2 データベース失敗時の方針

データベース保存に失敗した場合の方針を事前に決めます。

• 保存失敗でも取引を継続する
• 保存失敗時は新規注文を止める
• 一定回数の失敗でEAを停止する

どの方針が適切かはEAの目的で変わります。検証重視のEAでは、ログ欠損が大きな問題になる場合があります。実行重視のEAでは、保存失敗だけで保有ポジション管理を止めると別のリスクになります。

4. 主要モジュールの役割

【結論】
sqlite-mql5の主要モジュールは、シグナル、フィルター、リスク、注文、記録に分けます。
モジュールを分けると、SQLiteを追加しても売買ロジックの見通しを保ちやすくなります。

SQLiteを記録管理に閉じ込めると、EAの各モジュールを単体で見直しやすくなります。

4.1 リスク管理モジュール

リスク管理では、注文前にロットと証拠金を確認します。ロット計算では、最小ロット、最大ロット、ロットステップ、ティックバリュー、ティックサイズ、損切り幅を考慮します。

バックテスト結果は将来の利益を保証しません。ロット方式を変えると、最大ドローダウン、連敗耐性、証拠金維持の挙動も変わります。

4.2 注文管理モジュール

MQL5で注文を扱う場合は、MqlTradeRequest、MqlTradeResult、MqlTradeCheckResultを分けて考えます。注文前にはOrderCheckで証拠金や取引条件を確認し、OrderSend後は戻り値と結果コードを保存します。

注文処理では、次の条件を確認します。

• 取引が許可されているか
• 銘柄が取引可能か
• スプレッドが許容範囲か
• ロットが最小ロット、最大ロット、ロットステップに合っているか
• 証拠金が足りているか
• ストップレベルとフリーズレベルに反していないか
• netting口座とhedging口座の違いを考慮しているか

SQLiteには、注文に成功した事実だけでなく、注文を止めた理由も保存します。見送り理由を残すと、条件が厳しすぎるのか、実行環境が合っていないのかを判断しやすくなります。

5. 実装パターン

【結論】
sqlite-mql5の実装パターンは、シンプルなログ保存型から始めるのが扱いやすいです。
EAの状態復元や複数通貨管理に使う場合は、保存設計と読み込みタイミングを慎重に決める必要があります。

代表的な実装パターンは次の通りです。

最初から状態復元型や複数通貨管理型にすると、設計の確認点が増えます。まず判定ログ保存型で構造を安定させ、必要に応じて拡張する流れが実装しやすくなります。

5.1 判定ログ保存型

判定ログ保存型では、エントリーの有無に関係なく、EAがどの判断をしたかを保存します。

保存する例は次の通りです。

• トレンド判定
• ボラティリティ判定
• スプレッド判定
• シグナル方向
• リスク確認結果
• 注文可否

この方式は、売買回数が少ないEAでも検証データを集めやすい点が利点です。

5.2 状態復元型

状態復元型では、EA停止前の状態をSQLiteに保存し、再起動後に読み込みます。たとえば、当日損失、停止フラグ、最後の取引時刻、銘柄別の状態などを保存します。

状態復元では、現在の口座状態とSQLite上の状態が食い違う可能性があります。再起動時には、実際のポジション、注文、口座情報を確認してから復元データを使う必要があります。

6. サンプルコード

【結論】
MQL5でSQLiteを使うサンプルは、OnInitでデータベースを開き、テーブルを作成し、OnTickで短いログを保存し、OnDeinitで閉じる構成にします。
注文処理を含める場合は、OrderCheckとOrderSendの結果を別のログとして保存します。

次のコードは、検証用の最小構成です。売買判断を行うEAではなく、EAの判断状態をSQLiteへ保存する構造を示します。

#property strict

long db = INVALID_HANDLE;
bool database_ready = false;

int OnInit()
{
   db = DatabaseOpen("ea_state.sqlite",
                     DATABASE_OPEN_READWRITE | DATABASE_OPEN_CREATE | DATABASE_OPEN_COMMON);

   if(db == INVALID_HANDLE)
   {
      Print("DatabaseOpen failed. error=", GetLastError());
      return INIT_FAILED;
   }

   string create_signal_table =
      "CREATE TABLE IF NOT EXISTS signal_log ("
      "id INTEGER PRIMARY KEY AUTOINCREMENT,"
      "event_time TEXT,"
      "symbol TEXT,"
      "timeframe INTEGER,"
      "signal TEXT,"
      "filter_status TEXT,"
      "spread REAL,"
      "equity REAL,"
      "comment TEXT"
      ");";

   if(!DatabaseExecute(db, create_signal_table))
   {
      Print("CREATE TABLE failed. error=", GetLastError());
      DatabaseClose(db);
      db = INVALID_HANDLE;
      return INIT_FAILED;
   }

   database_ready = true;
   return INIT_SUCCEEDED;
}

void OnDeinit(const int reason)
{
   if(db != INVALID_HANDLE)
   {
      DatabaseClose(db);
      db = INVALID_HANDLE;
   }
}

void OnTick()
{
   if(!database_ready)
      return;

   double ask = SymbolInfoDouble(_Symbol, SYMBOL_ASK);
   double bid = SymbolInfoDouble(_Symbol, SYMBOL_BID);

   if(ask <= 0.0 || bid <= 0.0)
   {
      Print("Invalid price. symbol=", _Symbol);
      return;
   }

   double spread_points = (ask - bid) / _Point;
   double equity = AccountInfoDouble(ACCOUNT_EQUITY);

   string signal = "none";
   string filter_status = "passed";
   string comment = "sample log";

   SaveSignalLog(signal, filter_status, spread_points, equity, comment);
}

bool SaveSignalLog(string signal,
                   string filter_status,
                   double spread_points,
                   double equity,
                   string comment)
{
   if(db == INVALID_HANDLE)
      return false;

   string query =
      "INSERT INTO signal_log "
      "(event_time, symbol, timeframe, signal, filter_status, spread, equity, comment) "
      "VALUES (?1, ?2, ?3, ?4, ?5, ?6, ?7, ?8);";

   long stmt = DatabasePrepare(db, query);
   if(stmt == INVALID_HANDLE)
   {
      Print("DatabasePrepare failed. error=", GetLastError());
      return false;
   }

   bool ok = true;
   ok = ok && DatabaseBind(stmt, 0, TimeToString(TimeCurrent(), TIME_DATE | TIME_SECONDS));
   ok = ok && DatabaseBind(stmt, 1, _Symbol);
   ok = ok && DatabaseBind(stmt, 2, (int)_Period);
   ok = ok && DatabaseBind(stmt, 3, signal);
   ok = ok && DatabaseBind(stmt, 4, filter_status);
   ok = ok && DatabaseBind(stmt, 5, spread_points);
   ok = ok && DatabaseBind(stmt, 6, equity);
   ok = ok && DatabaseBind(stmt, 7, comment);

   if(ok)
      ok = DatabaseRead(stmt);

   if(!ok)
      Print("Insert signal_log failed. error=", GetLastError());

   DatabaseFinalize(stmt);
   return ok;
}

6.1 サンプルコードの注意点

このコードは、SQLite連携の構造を示す検証用サンプルです。実運用EAでは、取引条件、スプレッド制限、ロット計算、注文前チェック、ポジション管理、停止条件を追加する必要があります。

OnTickで毎ティック保存すると、データ量が急増します。新しい足が確定した時だけ保存する、シグナル状態が変化した時だけ保存する、一定間隔で保存するなどの制御が必要です。

6.2 注文前チェック結果を保存する考え方

注文処理を行うEAでは、OrderSendの前にOrderCheckを使い、MqlTradeCheckResultの結果を保存します。注文が送信されなかった場合も、保存対象にすることが重要です。

bool CheckBeforeOrder(MqlTradeRequest &request, MqlTradeCheckResult &check)
{
   ResetLastError();

   if(!OrderCheck(request, check))
   {
      Print("OrderCheck failed. error=", GetLastError());
      return false;
   }

   if(check.retcode != TRADE_RETCODE_DONE)
   {
      Print("OrderCheck rejected. retcode=", check.retcode, " comment=", check.comment);
      return false;
   }

   return true;
}

OrderCheckで問題がない場合でも、OrderSend後に約定拒否、価格変動、スリッページが起こる場合があります。チェック結果と送信結果は別々に保存します。

7. 設計パターン比較

【結論】
sqlite-mql5の設計では、保存量、復元性、実装難易度、実運用負荷のバランスを比較して選びます。
初心者から中級者の段階では、判定ログ保存型と注文ログ保存型を組み合わせる構成が扱いやすいです。

SQLiteはローカルで完結しやすい点が利点です。一方で、EAのティック処理に重い保存や集計を入れると、取引判断の遅延につながる可能性があります。

7.1 初期設計で選びやすい構成

初期設計では、次の構成が扱いやすくなります。

• 判定ログはSQLiteに保存する
• 注文結果もSQLiteに保存する
• 集計はEA外で行う
• 状態復元は必要になってから追加する

この構成なら、EAの売買ロジックを大きく崩さずに検証データを残せます。

7.2 避けたい構成

避けたい構成は、SQLiteの読み書きと売買判断が密結合している構成です。データベース処理が失敗しただけで、シグナル判定やポジション管理まで不安定になる場合があります。

記録処理の失敗は記録処理として扱い、注文や決済の安全確認とは分けます。

8. バックテストで確認すべき項目

【結論】
バックテストでは、SQLiteに保存したログを使い、利益額だけでなく、判断過程とリスク指標を確認します。
総損益が良く見えても、最大ドローダウン、連敗数、取引回数、パラメータ依存性が弱いとは限りません。

確認すべき項目は次の通りです。

バックテスト結果は、テスター条件に強く影響されます。スプレッド、約定モデル、ヒストリーデータの品質が変わると、結果も変わります。

8.1 ログから見送り理由を確認する

SQLiteに見送り理由を保存しておくと、取引回数が少ない理由を確認できます。

• スプレッド制限で見送った
• トレンドフィルターで見送った
• 証拠金不足で見送った
• 既存ポジションがあるため見送った
• 時間帯制限で見送った

見送り理由が偏っている場合、条件が厳しすぎる可能性があります。ただし、条件を緩めることが成績改善を意味するわけではありません。必ず再検証が必要です。

8.2 過剰最適化を避ける

SQLiteに詳細ログを残すと、多くの条件を後から分析できます。一方で、分析できる項目が増えるほど、特定期間だけに合う調整を選びやすくなります。

過剰最適化を避けるには、次の点を確認します。

• 期間を分けても傾向が大きく崩れないか
• 銘柄を変えても極端に悪化しないか
• パラメータを少し変えても結果が崩れすぎないか
• 取引回数が少なすぎないか
• 最大ドローダウンが許容範囲にあるか

9. フォワードテストで確認すべき項目

【結論】
フォワードテストでは、SQLiteログを使って、バックテストと実際の稼働環境の差を確認します。
特に、約定差、スプレッド拡大、取引頻度、VPS環境、ブローカー差を確認する必要があります。

フォワードテストで確認する項目は次の通りです。

フォワードテストは、EAを実運用する前の確認工程です。デモ口座とリアル口座では、約定条件やスプレッド条件が異なる場合があります。

9.1 バックテストとの乖離を見る

SQLiteに同じ列構造でログを残すと、バックテストとフォワードテストを比較しやすくなります。

比較する項目は次の通りです。

• シグナル発生回数
• 注文見送り回数
• スプレッドによる見送り回数
• 約定失敗回数
• 平均スリッページ
• 最大ドローダウン
• 連敗数

乖離が大きい場合、テスター条件、スプレッド条件、約定条件、銘柄仕様の差を確認します。

9.2 状態復元の確認

VPSでEAを長期稼働させる場合、端末再起動やEA再読み込みが起こる可能性があります。SQLiteに保存した状態を使う場合でも、再起動後には実際のポジションと注文を確認します。

保存状態だけを信じると、すでに決済されたポジションを保有中として扱うなどの不整合が起こる場合があります。

10. 実運用での注意点

【結論】
sqlite-mql5を実運用で使う場合は、データベース処理よりも取引安全性を優先します。
保存処理の失敗、ファイル破損、VPS停止、ブローカー条件の違いがEA全体の挙動に影響しないように設計する必要があります。

実運用で注意する点は次の通りです。

• SQLite保存は取引成績を保証しない
• バックテストと実運用は一致しない
• スプレッド拡大で成績が悪化する場合がある
• 約定遅延やスリッページが発生する場合がある
• ブローカー仕様によりEAの挙動が変わる場合がある
• デモ口座とリアル口座で約定条件が異なる場合がある
• ログ保存の失敗時に新規注文を続けるか止めるかを決める
• レバレッジが高いほどドローダウンも大きくなりやすい

10.1 データベース処理を軽くする

OnTickで大量のINSERTや集計を行うと、処理が重くなる場合があります。実運用では、保存頻度を制御します。

• 新しい足で1回だけ保存する
• 状態が変わった時だけ保存する
• 注文前後だけ保存する
• 定期集計はOnTimerに分ける

ティックが多い銘柄では、保存処理の回数が想定以上に増えます。

10.2 口座タイプの違いを考慮する

MQL5では、netting口座とhedging口座でポジション管理の考え方が異なります。netting口座では同一銘柄のポジションが統合されます。hedging口座では同一銘柄で複数ポジションを持てる場合があります。

SQLiteにポジション状態を保存する場合は、口座タイプに応じて保存キーを決めます。銘柄だけで状態を管理すると、hedging口座で複数ポジションを区別できない場合があります。

11. よくある設計ミス

【結論】
sqlite-mql5で多い設計ミスは、SQLite処理をOnTickに詰め込みすぎること、保存失敗時の方針がないこと、売買判断と記録処理を混ぜることです。
データベースはEAを検証しやすくしますが、設計を誤ると不具合の原因にもなります。

11.1 OnTickで毎回すべて保存する

毎ティックで大量保存すると、データ量と処理負荷が増えます。新しい足、状態変化、注文前後など、保存タイミングを制限します。

11.2 保存失敗時の扱いがない

DatabaseOpen、DatabasePrepare、DatabaseBind、DatabaseRead、DatabaseExecuteの失敗を確認しない設計は危険です。保存に失敗した場合は、ログを出し、必要に応じて新規注文を止めます。

11.3 SQLiteの状態だけでポジションを判断する

実際のポジション状態は、口座上の状態を確認する必要があります。SQLiteの保存情報は補助情報です。EA再起動後は、PositionSelectやPositionGetDoubleなどで実際の状態を確認します。

11.4 注文結果だけを保存する

注文結果だけを保存すると、なぜエントリーしなかったのかが分かりません。EA改善では、見送り理由の保存も重要です。

11.5 パラメータを増やしすぎる

SQLiteログがあると分析項目を増やしやすくなります。しかし、フィルターやパラメータを増やしすぎると、過剰最適化の原因になります。目的が明確な条件だけを追加します。

12. まとめ

【結論】
sqlite-mql5は、EAの状態管理、検証ログ、注文結果の追跡に役立つ設計です。
SQLiteを記録層として分離し、OnInit、OnTick、OnDeinit、OnTradeTransactionの役割を整理すると、EAの挙動を検証しやすくなります。

sqlite-mql5設計では、SQLiteを売買ロジックの中心に置かず、判断過程を保存するために使います。判定、リスク管理、注文、記録を分けることで、EAの構造を保ちやすくなります。

実運用では、データベース保存よりも取引安全性を優先します。バックテスト結果は将来の利益を保証しません。フォワードテストで、スプレッド、約定差、ブローカー仕様、VPS環境、ログ保存の安定性を確認する必要があります。

FAQ

sqlite-mql5とは何ですか？

sqlite-mql5とは、MQL5 EAからSQLiteデータベースを使い、判断履歴、注文結果、状態管理データを保存する設計です。売買判断そのものではなく、検証と管理をしやすくするために使います。

MQL5 EAでSQLiteを使うメリットは何ですか？

MQL5 EAでSQLiteを使うメリットは、シグナル、見送り理由、注文結果、エラーを構造化して保存できることです。後から条件別に確認しやすくなります。

SQLiteを使えばEAの成績は良くなりますか？

SQLiteを使うだけでEAの成績が良くなるわけではありません。SQLiteは検証と状態管理を助ける仕組みであり、売買ロジックの優位性や実運用の成績を保証しません。

OnTickでSQLiteへ毎回保存してもよいですか？

OnTickで毎回保存すると、ティック数が多い銘柄では処理負荷とデータ量が増えます。新しい足、状態変化、注文前後など、保存するタイミングを制限する設計が扱いやすくなります。

SQLite保存に失敗した場合はどうすべきですか？

SQLite保存に失敗した場合は、エラーを記録し、EAの方針に応じて新規注文を継続するか停止するかを決めます。検証重視のEAでは、ログ欠損が判断材料の不足につながる場合があります。

バックテストでは何を確認すべきですか？

バックテストでは、総損益だけでなく、最大ドローダウン、勝率、損益比、取引回数、連敗数、スプレッド条件、パラメータ依存性を確認します。SQLiteログを使うと、見送り理由や注文失敗の傾向も確認しやすくなります。

フォワードテストでは何を確認すべきですか？

フォワードテストでは、約定差、スプレッド拡大、取引頻度、ドローダウン、バックテストとの乖離、ブローカー差、VPS環境の安定性を確認します。デモ口座とリアル口座では約定条件が異なる場合があります。

netting口座とhedging口座でSQLite設計は変わりますか？

netting口座とhedging口座では、ポジション管理の単位が変わるため、SQLiteの保存キーも変わる場合があります。hedging口座では複数ポジションを区別できるように、チケット番号などを保存する設計が必要です。