MT5 EAのバックテスト結果やパラメータをSQLiteで一元管理する設計を解説。CSV運用の限界、テーブル構成、MQL5のDatabase API、戦略比較や再検証へつなげる実務フローを整理します。
EA検証でCSV管理が限界になりやすい理由
MT5でEAを開発すると、バックテスト結果、最適化パラメータ、対象銘柄、時間足、期間、ビルド番号などの情報が急速に増える。初期段階ではCSVで十分でも、戦略数や検証回数が増えると「どの設定で得た結果か」「同じ条件を再現できるか」が曖昧になりやすい。
この問題はファイル整理ではなく、検証プロセスの再現性に関わる。そこで有効なのが、SQLiteをEA検証用の戦略レジストリとして利用する設計である。
MQL5からSQLiteを直接扱う
MQL5にはSQLiteを扱うDatabase APIがあり、DatabaseOpenでデータベースを開き、DatabaseExecuteでSQLを実行できる。DatabasePrepareやDatabaseReadBindを使えば、検索結果を構造体へ読み込む処理も設計できる。
外部Pythonや別サーバーを必須とせず、MT5側だけで検証データを蓄積できる点が利点だ。CSVのインポートやSQL結果のCSVエクスポートも可能なため、既存運用から段階的に移行できる。
戦略レジストリの基本構成
データは「戦略」「検証実行」「結果」の3層に分けると管理しやすい。
strategies
EA名、strategy_id、バージョンなど、戦略そのものを識別する情報を保存する。
test_runs
symbol、timeframe、開始日、終了日、初期資金、parameter_set_idなど、1回のバックテスト条件を保存する。
test_results
net_profit、profit_factor、max_drawdown、trade_countなど、各test_runに対応する評価値を保存する。
重要なのは、結果だけでなく「結果を生成した条件」を残すことだ。利益だけをCSVへ並べても、条件を追跡できなければ比較可能な研究データになりにくい。
パラメータを別テーブル化する
EAでは入力値が頻繁に変わるため、parameter_setsとparameter_valuesを分離すると拡張しやすい。ATR期間、移動平均期間、損切り倍率などをparameter_set_idへ紐づければ、同一設定を複数期間・複数銘柄で再利用できる。
これにより「EURUSDで良かった設定が他銘柄でも機能したか」「最適化上位設定のアウト・オブ・サンプル成績はどうか」といった検索をSQLで行える。
書き込み競合を避ける
大量の最適化結果を保存する場合は、トランザクション単位で処理した方が整合性を管理しやすい。複数テストエージェントが同一DBへ直接書き込む構成は競合の原因になり得るため、結果を一度集約し、最終的なDB書き込みを一元化する設計が扱いやすい。
CSVは出力形式として残す
SQLite導入の目的はCSVの完全排除ではない。CSVはExcelやPythonへの受け渡しに便利である。SQLiteを正本として保持し、分析や共有が必要な部分だけCSVへ出力すれば、「保存形式」と「閲覧形式」を分離できる。
まとめ
MT5 EAの検証規模が大きくなるほど、単発のバックテスト結果より再現性と検索性が重要になる。SQLiteで戦略・実行条件・結果・パラメータをIDで紐づければ、検証履歴を構造化できる。
EA開発を継続的な研究プロセスとして運用するなら、SQLiteはバックテスト、再検証、比較分析を接続する実用的なデータ基盤になる。
