自社EA「AutoYenPulse」の開発

AI MQL合同会社における自社EA(自動売買システム)の開発は、単なる収益源の一つではなく、事業戦略の核心的な柱である「共生的R&D (Symbiotic R&D)」モデルの中核を担うものです 。

これは、顧客向けのオーダーメイド開発事業と、自社EAの開発・運用が相互に利益をもたらし、イノベーションの好循環(フライホイール効果)を生み出す仕組みです

具体的には、以下のプロセスで機能します。

1. 「共生的R&D」の仕組み

AI MQLは、顧客(プロップファーム、FinTech企業など)向けに高度なオーダーメイドのEA開発(「矛」)を提供します

  1. 知見の獲得: これらの顧客プロジェクトを遂行する過程で、AI MQLは実世界の高度な課題に直面します。
  2. 知見の抽象化: 顧客の機密情報(特定の取引ロジックやパラメータ、専属的コード)を厳格に保護しつつ 、そこから得られる「派生的知見」(匿名化・汎用化されたアーキテクチャ概念、数学的原理、パフォーマンス最適化技術など)を特定・抽象化します 。
  3. 自社EAへの活用: 法的に堅牢な契約(ライセンス許諾)に基づき、これらの汎用的な「派生的知見」をAI MQL独自の「社内運用トレーディングシステム (内部EA)」の継続的な強化・改善に活用します 。

2. 自社EAの戦略的役割

このモデルにおいて、自社EAは以下の2つの重要な役割を果たします。

  • ① R&D触媒としての役割 自社EAは、顧客プロジェクトから得た最先端の知見を実践・検証し、さらに発展させるための「R&D(研究開発)の触媒」として機能します 。
  • ② 財務的安定性の基盤としての役割 内部EAの運用から得られる利益は、顧客プロジェクトの受注状況に左右されない、安定した収益源となります 。

3. イノベーションの好循環

この「共生的R&D」モデルにより、以下の好循環が生まれます

顧客プロジェクト(実世界の課題) → 派生的知見の獲得 → 内部EAの強化・収益性向上 → 安定収益の確保 → 収益を新たなR&Dへ再投資 → AI MQLの技術力・中核的能力が向上 → 将来の顧客により高い価値を提供

このように、AI MQLにとって自社EAの開発・運用は、顧客向けソリューション開発と不可分に結びついた、事業全体の技術力と安定性を支えるための「戦略的資産」として位置づけられています


XD_YenPulse v2.20 ファイル設計書

main.mq5を根幹として、機能ごとにmqhに分割します。

(1) ConfigLoader.mqh – 統一設定管理
(2) HandshakeManager.mqh – ハンドシェイクプロトコル
(3) HeartbeatMonitor.mqh – 多段階ハートビート監視
(4) FileUtils.mqh – ファイル操作ユーティリティ
(5) RiskManager.mqh – リスク管理
(6) PositionManager.mqh – ポジション管理
(7) NotificationManager.mqh – 通知管理
(8) TechnicalAnalyzer.mqh – テクニカル分析
(9) CommandHierarchy.mqh – 指揮命令階層
(10) SystemState.mqh – システム状態管理

YenPulse/
├── main.mq5              ← メインEA
└── Include/                           ← ヘッダーファイル
    ├── SystemState.mqh                # システム状態管理
    ├── ConfigLoader.mqh               # 設定ローダー
    ├── HandshakeManager.mqh           # ハンドシェイク管理
    ├── HeartbeatMonitor.mqh           # ハートビート監視
    ├── FileUtils.mqh                  # ファイルユーティリティ
    ├── RiskManager.mqh                # リスク管理
    ├── PositionManager.mqh            # ポジション管理
    ├── NotificationManager.mqh        # 通知管理
    ├── TechnicalAnalyzer.mqh          # テクニカル分析
    └── CommandHierarchy.mqh           # 指揮命令階層

config.jsonと通信ファイルは MQL5/Files/


(1) ConfigLoader.mqh – 統一設定管理

統一設定管理

  • config.jsonを単一の信頼できる情報源として読み込み
  • 設定の乖離リスクを完全排除

包括的な検証

  • 必須セクションの存在確認
  • 各パラメータの範囲検証
  • 階層的整合性チェック(例: daily < weekly < monthly)

型安全なアクセス

  • GetString(), GetInt(), GetDouble(), GetBool()
  • デフォルト値のサポート
  • 存在しないキーへの安全なアクセス

柔軟なパス指定

  • ドット記法とスラッシュ記法の両方をサポート
  • 例: “system/magic_number” または “system.magic_number”

エラーハンドリング

  • 詳細なエラーメッセージ
  • GetLastError()でエラー情報を取得可能

デバッグサポート

  • PrintConfig()で全設定を表示
  • 読み込み時の詳細なログ出力

(2) HandshakeManager.mqh – ハンドシェイクプロトコル

3フェーズハンドシェイク

  • Phase 1: EA初期化(config.json読み込み、ハートビート準備)
  • Phase 2: Python起動待機(python_heartbeat.txt監視)
  • Phase 3: 同期確立(system_state.json確認)

状態管理

  • 8つの状態を定義(OFF → INITIALIZING → WAITING_FOR_PYTHON → READY → OPERATIONAL)
  • 各フェーズで適切な状態遷移
  • system_state.jsonへの状態記録

タイムアウト処理

  • 設定可能なタイムアウト(デフォルト300秒)
  • タイムアウト時の適切なエラーハンドリング
  • 進捗表示で待機状況を可視化

アトミック操作

  • 一時ファイルを使用したアトミック書き込み
  • ファイル破損リスクの排除

詳細なログ

  • 各フェーズの進捗を詳細に記録
  • エラー情報の保存と取得
  • デバッグに役立つ情報出力

堅牢なエラー処理

  • タイムアウト検出
  • ファイルI/Oエラーハンドリング
  • 初期化失敗時の適切な状態設定

(3) HeartbeatMonitor.mqh – 多段階ハートビート監視

3段階アラートシステム

  • WARNING (300秒): 新規エントリー停止
  • CRITICAL (900秒): SL引き締め + 緊急アラート
  • EMERGENCY (1800秒): 全ポジション決済(設定による)

過剰反応防止

  • 段階的なエスカレーション
  • 各レベルで適切な対応
  • 誤検知による損失を最小化

リスク管理機能

  • TightenAllStopLosses(): CRITICAL時に全ポジションのSLを現在価格に近づける
  • CloseAllPositions(): EMERGENCY時の緊急決済(オプション)

双方向ハートビート

  • CheckPythonHeartbeat(): Python監視
  • SendEAHeartbeat(): 自身のハートビート送信

アトミック操作

  • 一時ファイルを使用した安全な書き込み
  • ファイル破損防止

統計追跡

  • 各レベルの発生回数記録
  • デバッグとシステム評価に有用

自動復旧

  • RecoverToNormal(): ハートビートが復旧すると自動的に通常状態に戻る
  • フラグのリセット

(4) FileUtils.mqh – ファイル操作ユーティリティ

防御的読み取り (ReadJSONSafely)

  • ファイル存在確認
  • サイズチェック(0バイトまたは10MB超を拒否)
  • 安全なファイルオープン
  • JSONパース検証
  • 構造検証

意味的妥当性検証

  • ValidateSignalJSON:
    • signal値の検証(BUY/SELL/NONE)
    • confidence範囲チェック(0.0-1.0)
    • エントリー価格の妥当性(現在価格から±10%以内)
    • SL/TP方向性の論理チェック
    • リスクリワード比の警告
  • ValidatePositionStatusJSON: ポジション状態の整合性
  • ValidateSystemStateJSON: システム状態の基本検証

アトミック書き込み

  • 一時ファイルへの完全書き込み
  • アトミックリネームによる置換
  • 読み手が不完全なデータを読まないことを保証

ユーティリティ機能

  • FileExists: ファイル存在確認
  • IsFileRecent: ファイルの新鮮さチェック
  • GetFileModificationTime: 更新時刻取得
  • GetFileSize: ファイルサイズ取得

包括的エラーハンドリング

  • 詳細なエラーメッセージ
  • GetLastError()でエラー情報を取得可能
  • ログ出力による問題の可視化

グローバル関数

  • クラスを意識せずに使える便利な関数
  • main.mq5から直接呼び出し可能

(5) RiskManager.mqh – リスク管理

階層的リスク制限

  • 取引単位: 1.5%(デフォルト)
  • 日次: 4%
  • 週次: 12%
  • 月次: 20%
  • 各レベルで独立したチェック

動的リスク調整

  • ボラティリティに応じた調整(ATR使用)
  • 勝率に応じた調整(過去20トレード)
  • ドローダウンに応じた調整
  • 範囲制限(0.5% – 2.0%)

ロットサイズ計算

  • リスク金額ベースの正確な計算
  • ティックバリューを考慮
  • シンボルの最小/最大/ステップを適用
  • 自動正規化

ドローダウン管理

  • リアルタイムDD追跡
  • 自動期間リセット(日次/週次/月次)
  • 基準残高の管理

統計追跡

  • 総取引数
  • 勝率計算
  • 直近勝率の計算(動的調整用)

包括的チェック

  • CheckAllLimits(): 全階層を一度にチェック
  • 個別制限チェック関数
  • 詳細なエラーメッセージ

(6) PositionManager.mqh – ポジション管理

1. ポジション管理

  • 新規ポジションオープン(検証付き)
  • ポジション変更(SL/TP)
  • 個別・全体ポジションクローズ

2. 自動監視機能

  • ATRベーストレーリングストップ:市場のボラティリティに応じて自動調整
  • 時間ベース決済:最大保有時間(デフォルト72時間)超過で自動決済

3. 情報取得

  • ポジション詳細情報(pips損益、保有時間など)
  • JSON形式でのステータス出力
  • オープンポジション数・総損益取得

4. 安全機能

  • 価格・ロット数の妥当性検証
  • エラーハンドリング
  • 詳細なログ出力

(7) NotificationManager.mqh – 通知管理

1. 多層通知システム

  • MT5標準アラート: ターミナルへの即座表示
  • MT5モバイル通知: スマホアプリへのプッシュ通知(HIGH以上)
  • Pushover統合: ファイル経由でPython側に通知依頼

2. 優先度管理

  • CRITICAL(緊急): クールダウンなし、全チャネル即送信
  • HIGH(重要): 5分クールダウン、モバイル通知含む
  • NORMAL(通常): 30分クールダウン
  • LOW(参考): 1時間クールダウン

3. クールダウン機能

  • 同じタイトルの通知が頻繁に送信されることを防止
  • 優先度別に異なるクールダウン時間
  • 緊急通知は強制送信可能

4. 統計追跡

  • 送信成功・失敗・スキップ数の記録
  • デストラクタでサマリー出力

(8) TechnicalAnalyzer.mqh – テクニカル分析

1. 包括的なテクニカル指標

  • 移動平均: SMA(20,50,200)、EMA(12,26)
  • モメンタム: RSI、ストキャスティクス
  • トレンド: ADX、+DI、-DI
  • ボラティリティ: ATR、ボリンジャーバンド
  • MACD: メインライン、シグナル、ヒストグラム

2. 高度な分析機能

  • トレンド判定: 複数指標の総合評価(BULLISH/BEARISH/NEUTRAL)
  • トレンド強度: 0.0-1.0のスコア
  • サポート/レジスタンス: 自動検出
  • ボラティリティ状態: HIGH/NORMAL/LOWの3段階

3. Python連携

  • 人間が読みやすい形式でコンテキスト生成
  • tech_context_h1.txtへのアトミック書き込み
  • 完全なマーケット情報を提供

(9) CommandHierarchy.mqh – 指揮命令階層

1. 6段階優先順位階層

  • EMERGENCY_STOP      (緊急停止)
  • RISK_MANAGEMENT     (リスク管理)
  • STATIC_RULES        (静的ルール)
  • AI_CONSENSUS        (AIコンセンサス)
  • AI_RECOMMENDATION   (AI推奨)
  • DEFAULT_ACTION      (デフォルト)

2. 動的優先順位昇格

特定の条件下でAI推奨が自動的に静的ルールより高い優先度に昇格

  • TIGHTEN_SL(SL引き締め): HIGH risk + 確信度≥75%
  • CLOSE_PARTIAL(部分決済): HIGH urgency + 確信度≥70%
  • CLOSE_ALL(全決済): CRITICAL risk + 確信度≥60%

3. コマンド衝突解決

  • 複数のコマンドから最優先を自動選択
  • 詳細なログ出力(採用理由・却下理由)
  • 統計追跡

4. 安全機能

  • コマンド検証
  • 優先度範囲チェック
  • 確信度検証

(10) SystemState.mqh – システム状態管理

1. 状態同期管理

8つのシステム状態管理

OFF → INITIALIZING → WAITING_FOR_PYTHON → READY → OPERATIONAL
↓ 
DEGRADED → EMERGENCY_MODE 
↓ 
FAILED_INIT

2. 状態同期管理

  • EA ⇔ Python の双方向状態監視
  • system_state.jsonを介した状態共有
  • 同期完了確認

3. 状態遷移検証

  • 妥当な状態遷移のみ許可
  • 不正な遷移を警告
  • 緊急状態への即座遷移をサポート

4. 履歴追跡

  • 最新50件の状態変更を記録
  • タイムスタンプ付き履歴
  • 統計情報(成功率など)

5. 安全機能

  • アトミックファイル書き込み
  • 状態整合性チェック
  • 取引可能状態の厳密な判定
最近の記事
おすすめ記事
  1. チャートの向こう側 オルタナティブデータはいかにして次世代のトレーディング・アルファを生み出すか

  2. 2025年10月31日 Claude大規模障害—なぜ当社のマルチコンセンサスAIは影響を受けなかったのか

  3. 認知の戦争 トレーダーの95%をチャレンジで失敗させる5つの心理バイアス

  4. クオンツの試練 トップティアのプロップデスクにあなたは通用するか?

  5. The Silent Killer 文字コードが引き起こした数十億円規模の金融インシデント、その解剖

  6. 「エッジ」の解体新書 プロップファームが無視できない取引システムの構築法

  7. プロップファームのパラドックス 彼らが求めるのは利益の英雄ではなく、リスクの番人である理由

  8. 大規模言語モデル(LLM)を用いたスイングトレード 学術的検証の不在が示唆する現実と課題

  9. 市場の極限状態における生存戦略 フラッシュクラッシュとブラック・スワンが示す、次世代取引システムの要件

  10. 自社AI EA開発プロジェクト「YenPulse」(5モデルAI.ver)の仕様書を公開します。

  1. 東京時間午前9時55分の特異性 仲値フィルターが不可欠である学術的根拠

  2. 大規模言語モデル(LLM)を用いたスイングトレード 学術的検証の不在が示唆する現実と課題

  3. 信頼性の経済学 高頻度取引(HFT)戦略におけるSREのROI算出法

アーカイブ
TOP