こんにちは。
Do.です。
今日のテーマはこれです。
テーマ
AIエージェントにバックテスト用EAを作ってもらった
・とにかくバックテストが早いEAを作ってみた
部品があればEAを作るのは楽かもしれない
・先週からの新企画：一言メンタルコーナー
検証はメンタル安定につながる
・シンプルロジックFXの進捗
システムC リバースで面白い結果が出てきました
バックテストに指標データを取り込む機能追加
リバーストレードを安定させるための新機能発注
逆決済
連勝（リバース口座の連敗）をとめるTP連続フィルター
資金管理ロジックに累積損失額決済追加
とにかくバックテストが早いEAを作ってみた
システムCのメインEAのC_EA（元VQ_LC）は
様々な機能を詰め込んだので
バックテストに時間がかかります。
そこで、シンプルなエントリー部分の設定だけを変えて
バックテストを行いたいな、
と思ったんですね。
プログラマーさんに発注しようと思ったのですが、
この話をAI師匠にお話をしたら
「ちょっとおもしろそうだから作ってみようか？」
と言ってくださったので
お願いしました。
作成時の依頼内容は下記になります。
・これまで作ったBB_all、Break_EA（未公開EA）の2つのソースを元に大枠を作る
・エントリーと決済は仕様書を渡す
・最大の目的はバックテストの速さ
BB_all、Break_EAの部品とシステムCのエントリーロジックを使って
シンプルなバックテスト用EAを作る、というコンセプトです。
以下、最初の報告と途中のやり取りです。
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
<<最初の報告>>
■ 概要 仕様書に基づいて作った軽量版EAです。
pips変換、もみ合い基準値、履歴表示、通知はBB_allと同じ仕様、SL建値移動はBreak_1と同じ仕様で実装しています。
■ 軽量化のポイント BB_allから以下の重い処理を省きました。
・等間隔エントリーの撤去（寄与:最大） → ティック毎の価格差チェックと最大30ポジション管理がなくなりました
・ボリンジャーバンド計算の撤去（寄与:大） → 計算量を大幅に削減しました
・チャートオブジェクト描画の最適化（寄与:大） → BT時の履歴表示をON/OFFパラメーターで制御可能にしました（デフォルトOFF） →
BB_allにはこのパラメーターがなく、BT中も常に描画処理が走っていました
・大量ログ出力の削減（寄与:中）
・複数フィルター群の撤去（寄与:中） → 乖離率、パーフェクトオーダー、MTF、陰陽等
・複利計算の撤去（寄与:小）
■ 速度比較（実測値） 条件: USDJPY H1, 2025年通年, 全ティック, 同一PC
・BB_all: 167秒（2分47秒）※途中で強制終了 ・C_EA_0: 19秒 ※1年分完走 ・約9倍高速
■ コードサイズ ・BB_all: 18,479行 → C_EA_0: 765行（95.9%削減）
■ 添付ファイル内容 ・C_EA_0.mq5（ソースコード） ・C_EA_0.ex5（コンパイル済み） ・C_EA_0_報告書.md（詳細な報告書）
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
<<途中のやり取り>>
■ 報告1: ローソク足エントリー上限パラメータが効かない
─────────────────────────────
【結論】バグではなく、1ポジション制限との設計上の競合です。
C_EA_0は1ポジション制限（同時に1つのポジションしか持たない）が
かかっているため、1本のローソク足で最初のエントリーが成功すると、
そのポジションが決済されるまで次のエントリーは発生しません。
そのため、ローソク足エントリー上限を1にしても20にしても、
実質的に1ポジション制限で1回しかエントリーしないため結果が同じになります。
このパラメータは、将来ポジション数の上限を増やした場合に
機能する備えとしてそのまま残しています。
■ 報告2: もみ合い基準値の表示パラメータ未実装
─────────────────────────────
【対応】BB_allと同じ表示パラメータを全て追加しました。
追加したパラメータ（BB_allと同じデフォルト値）:
・バー表示 ON/OFF（デフォルト: true）
・開始位置（デフォルト: 3）
・太さ（デフォルト: 2）
・色（デフォルト: ForestGreen）
・もみ合い基準値pips表示 ON/OFF（デフォルト: true）
・pips表示の色（デフォルト: ForestGreen）
・フォント（デフォルト: Arial）
・フォントサイズ（デフォルト: 15）
表示方式もBB_allと同じOBJ_RECTANGLE（塗りつぶし矩形、チャート中央配置）
に変更しました。
■ 報告3: フォワードテストでドテンが動作しない
─────────────────────────────
【原因】
バックテストではポジションの状態が即座に反映されますが、
デモ口座/ライブ口座のフォワードテストでは、TP/SLが発動した後に
ポジション一覧への反映にタイムラグがあります。
v1.01のドテン検知は「ポジション一覧を毎ティック走査して、
前のティックにあったポジションが消えていたらTP/SL決済と判断する」
方式でしたが、このタイムラグによりフォワードでは検知に失敗していました。
【対応】
取引履歴（HistorySelect）からTP/SL決済を直接検出する
補助的な検知機能を追加しました。
・バックテストでは従来通りの方式で動作します（変更なし）
・フォワードテストでは、従来の方式に加えて取引履歴ベースの
検知が動作し、ポジション一覧のタイムラグを回避します
・二重にドテンが発動しないよう、ポジション保有中はスキップする
ガード条件を入れています
■ 変更概要
─────────
・バージョン: 1.01 → 1.02
・行数: 913行 → 1046行
・コンパイル: 0エラー 0警告
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
報告1について気がついたのでお伝えします。
バグではないとの結論でしたが、バグの可能性がある事に気が付きました。
例えば、一本のロウソク足がとても長い足だった場合、その一本の中でエントリーしたポジションが利確してすぐにドテンして、また利確してまたすぐにドテンといったことを繰り返すことはあります。
以前お伝えした下記の仕様です。
① 新しいローソク足が発生。発生前（ローソク足確定前）に既にポジションは持っている。
② ポジションが利確（損切）でドテンエントリー（1回目）
③ ②のポジションが利確（損切）でドテンエントリー（2回目）
④ ③のポジションが利確（損切）したが、3回目のエントリーは行わない
このように一本のロウソク足でドルエントリーが繰り返されると複数のポジションを持つので、それをパラメータで制限したいです。
よろしくお願いします。
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
■ 修正概要
v1.02 → v1.03: Filter_CandleEntry（ローソク足エントリー上限）パラメータが
ドテンエントリーで効かないバグを修正しました。
■ お詫び
v1.02の修正報告書にて、安藤さんからご報告いただいた
「ローソク足エントリー上限パラメータが効かない」件について、
「バグではなく1ポジション制限との設計上の競合です」と誤った結論をお伝えしました。
実際には、1本のローソク足内でTP/SL決済→ドテン→またTP/SL→またドテンと
繰り返されるシナリオにおいて、バーカウンターがドテンエントリーのルートで
チェックされていないバグでした。
安藤さんが「以前お伝えした仕様です」と再度ご指摘くださったおかげで
今回修正することができました。誤った判断でお手間をおかけし、申し訳ありませんでした。
■ バグの原因
SendOrder()を呼ぶルートが4つあるのに、バーカウンターのチェックが
1つのルート（MAクロスエントリー）にしか入っていませんでした。
ルート1: MAクロスエントリー → カウンターあり（v1.02でもOK）
ルート2: TP/SL決済後のドテン → カウンターなし（見落とし）
ルート3: フォワード向け履歴ドテン → カウンターなし（見落とし）
ルート4: MAクロス決済後のドテン → カウンターなし（見落とし）
このため、1本のローソク足内で TP/SL決済→ドテン→またTP/SL決済→またドテン
が無制限に繰り返されていました。
■ 修正内容（修正9）
バーカウンターのチェックとインクリメントを SendOrder() 関数に一本化しました。
全てのエントリーは SendOrder() を通るため、
ここに入れることで全ルートが自動的に制限されます。
SendOrder() の冒頭に追加（チェック）:
if (Filter_CandleEntry > 0 && g_iEntryCntThisBar >= Filter_CandleEntry)
→ 上限に達していたらエントリーしない（ログに「バーカウンター上限到達」と出力）
SendOrder() 成功時に追加（インクリメント）:
g_iEntryCntThisBar++
CheckEntry() から個別のチェック/インクリメントは削除しました。
（SendOrder内で管理するため不要になった）
■ 動作の例（Filter_CandleEntry = 2 の場合）
① 足内でポジション保有中
② TP/SL決済 → ドテン → SendOrderがカウンター=1に → エントリー成功
③ ②のポジションがTP/SL決済 → ドテン → カウンター=2 → エントリー成功
④ ③のポジションがTP/SL決済 → ドテン → カウンター=2 >= 上限2 → ブロック
→ 次のローソク足でカウンターリセット
■ 変更箇所まとめ
1. バージョン番号: 1.02 → 1.03
2. SendOrder(): バーカウンターチェック追加（全ルート共通関門）
3. SendOrder(): 成功時にバーカウンターインクリメント
4. CheckEntry(): 個別のバーカウンターチェックとインクリメントを削除
■ コンパイル結果
0 errors, 0 warnings（MetaEditor CLI）
■ バックテスト結果（USDJPY H1、2025年通年、全ティック）
Test passed
最終残高: 4,912.10 USD（初期10,000 USD）
実行時間: 約10秒
バーカウンター上限到達ログ: 13件
→ 「バーカウンター上限到達(2/2) ドテンエントリーしない」が正しく出力されており、
1本のローソク足内で2回ドテンした後、3回目が Filter_CandleEntry=2 でブロックされています。
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
途中でお詫びもされましたが（笑）
考えていた以上に、きちんと作ってくれている、
という印象です。
バックテストを行って
その速さも確認していますし。
この後も何度かやり取りをして
バックテストが早いEAを作る、
という目的に叶うEAは完成しました。
バグは潜んでいると思いますが
目的はバグがないEA作りではないので
このような簡易的なEA製作には良いな、という印象です。
このあたりのAIについては
とんでもなく進化が早いので
あと1年もあれば簡単な自然言語だけで
ライブでも使えるようなEAを作ることができるようになるかもしれませんね。
とても楽しみです。
新企画：一言メンタルコーナー
検証はメンタル安定につながる
今日のテーマはバックテストでしたが、
これも検証の一つです。
トレード中にメンタルが不安定になる一番の理由は、
負ける金額への恐怖です。
この恐怖をなくすには、最大ドローダウンを知ることが重要です。
あらかじめ検証を行って、
このロジックであれば
最大いくらまでなら負けを許容できる
という最大ドローダウンを把握しておくこと。
この最大ドローダウンを把握できないロジックは
怖くて使うことができないですよね。
検証には下記のように様々な方法があります。
・MT5過去チャートでの検証
・FT6、Trade Trainerなどの検証ソフトを使った検証
・インジケーター、EAを作っての検証
どんな方法でも良いので
とにかく検証で最大ドローダウンを把握することが大切です。
これを行う前に実資金を投入しての
ライブ取引は行わないようにしましょう。
それは、お金を捨てるだけの結果になりますから。
シンプルロジックFXの進捗
システムCの検証をひたすらやっています。
反転を使ったリバーストレードに
資金管理ロジックを追加すると、とても面白い結果になりました。
まだまだ大きな波があるので
これを少しでも安定させるために
新たな機能を発注しました。
これらの機能が整えば
複数のデモ口座で様々な設定を行って
ひたすら稼働させてみますね。
（リバーストレード自体はバックテストはできないので）
来週、新機能が搭載されたバージョンが完成したら
メンバーサイトにアップしますので
東京セミナー参加者のみなさんは
もう少しお待ち下さいね。
昨日、ひたすらリバーストレードのチャートを見ていると
自動売買のon/offと手動決済を取り入れると
非常に面白いかも、と感じました。
裁量と言っても難しい判断は不要で、
ダメな場合はすぐに自動でドテンしてくれるので
ストレスは少ないです。
また、メインEAを設置したチャートでは
ひたすら負けること（リバース口座では勝つこと）を
考え続けるので、それがとても新鮮です。
勝とうと思ってトレードを行わない、
負けようと思ってトレードを行うと
発想がとても柔軟になります。
この柔軟な発想こそが
システムCの大きな可能性につながると感じています。
リバーストレードはトレードではなく
完全にゲームだな、と思っています。
より面白いゲームに仕上げていきますね。
それでは、素敵な連休を。
感謝
Do.
