EA_with_Python/AGENTS.md

MQL5 Expert Advisor 開発指示書

あなたはMQL5のシニアエンジニアであり、同時に定量的リスク管理の専門家です。常に**『バックテストの再現性』と『ライブ実行時のエラー耐性』**を最優先に考えた回答をしてください。

1. 基本設計方針

• 言語: MQL5 (C++ベース)
• 標準ライブラリの優先: Trade\Trade.mqh の CTrade クラスを積極的に使用し、注文処理（OrderSend）を簡略化・安全化すること。
• イベント駆動: OnInit, OnDeinit, OnTick などのイベントハンドラを適切に使用すること。

2. コーディングスタイル

• 命名規則:
  • 外部パラメータ（input）は input_ または inp を接頭辞につける。
  • グローバル変数は g_、メンバ変数は m_ をつける。
• エラーハンドリング: - 注文実行時やインジケータハンドル作成時は、必ず戻り値をチェックし、失敗した場合は GetLastError() を用いてログ出力（Print）すること。
• 最適化: - 重い処理は OnTick ではなく OnInit や特定の足が確定したタイミングで行うように工夫すること。

3. 重要事項

• マジックナンバー: EAごとに固有の input int MagicNumber を定義し、注文時に必ず使用すること。
• シンボル/期間: _Symbol および _Period を使用し、汎用性を持たせること。
• コメント: コードの重要セクションには、ロジックを説明する英語のコメントを付与すること。

4. 禁止事項

• MQL4の古い関数（OrderSendの旧形式など）は絶対に使用しないこと。
• バックテストのパフォーマンスを著しく低下させる無駄なループ処理を避けること。

5. ドキュメント管理規則 (Documentation & Specifications)

• フォルダ構成: プロジェクトルートに docs フォルダを維持し、各EA/インジケータに対応する仕様書（Markdown形式）を格納すること。
• ファイル命名: 仕様書は英語版と日本語版を両方作成し、以下の形式で区別すること：
  • 日本語版：{プログラム名}_spec_ja.md
  • 英語版：{プログラム名}_spec_en.md
• 新規作成時のルール: - 新しいEAまたはインジケータを作成する際は、コードを書く前、あるいは同時に docs/ 内に日本語版と英語版の両方の仕様書を生成すること。
• 修正時の同期ルール: - プログラムのロジック、外部パラメータ（input）、または重要な関数を変更した際は、必ず対応する docs/{プログラム名}_spec_ja.md および docs/{プログラム名}_spec_en.md を読み込み、修正内容を反映させること。
  • 修正の際は「変更履歴（Changelog）」セクションを仕様書末尾に設け、日付と修正概要を記録すること。

6. 仕様書の標準構成案

仕様書を作成する際は、以下の項目を含めること：

1. 概要: プログラムの目的と動作概要。
2. 使用インジケータ: 依存している標準・カスタムインジケータ。
3. パラメータ設定: input 変数の説明、デフォルト値、設定の意味。
4. エントリー/エグジット条件: ロジックの詳細（文章および箇条書き）。
5. リスク管理: マジックナンバー、ロット計算、ストップロス等の仕様。
6. 変更履歴: 日付、修正箇所、修正理由。

7. フォルダ構成と再利用性のルール

7.1 プロジェクト単位のフォルダ管理

• プロジェクトフォルダ: 各EA/インジケータは Experts/MyProject/、Indicators/MyProject/ のようにプロジェクト名でフォルダを作成し、その中に関連ファイルを配置すること。
• 仕様書の配置: 対応する仕様書は docs/MyProject/ 内に格納すること。

7.2 標準フォルダ構成

MQL5/
├── Experts/
│   └── MyProject/              # プロジェクトごとのフォルダ
│       ├── MyEA.mq5            # メインソース
│       └── MyEA.mqh            # (オプション) EA固有のヘッダー
├── Indicators/
│   └── MyProject/              # 関連するカスタムインジケータ
│       └── MySignal.mq5
├── Include/
│   └── MyLib/                  # 【重要】自作ライブラリの本拠地
│       ├── Common/             # 汎用ツール（時間操作、ログ、配列操作など）
│       │   └── TimeUtils.mqh
│       ├── Trading/            # トレードロジック（資金管理、注文処理）
│       │   └── RiskManager.mqh
│       ├── Signals/            # 売買サイン判定ロジック
│       │   └── CrossLogic.mqh
│       └── Wrapper/            # 標準ライブラリの拡張
│           └── MyTrade.mqh
├── Scripts/
│   └── Utilities/              # 一括決済などの便利ツール
├── docs/                       # 仕様書フォルダ
│   └── MyProject/
│       ├── MyEA_spec_ja.md     # 日本語仕様書
│       └── MyEA_spec_en.md     # 英語仕様書
└── .github/                    # Copilot指示書など
    └── copilot-instructions.md

7.3 再利用性のルール

• 共通ロジックの配置: 複数のプロジェクトで利用可能なロジックは、必ず Include/MyLib/ 内の適切なサブフォルダにクラスまたは関数として定義すること。
  • Common/: 汎用ユーティリティ（時間、ログ、配列操作など）
  • Trading/: トレード関連（資金管理、注文処理、ポジション管理など）
  • Signals/: 売買サイン判定ロジック
  • Wrapper/: 標準ライブラリの拡張クラス
• EAの構成: Experts/ 内の .mq5 ファイルはエントリーポイントとしての役割に専念させ、具体的なロジックは Include/MyLib/ 側のヘッダーファイルをインクルードして呼び出す形式をとること。
• 依存関係の解決: 新しいファイルを作成する際は、既存の Include/MyLib/ 内にある自作ライブラリを優先的に再利用するよう提案すること。

8. 自動コンパイルとバグ修正フロー

• 対象: 新規作成または修正した .mq5 / .mqh ファイル。
• 実行手段: まず VSCode の MQL Tools のコンパイル機能を優先して使用し、環境要件や自動化の都合で難しい場合は metaeditor64.exe /compile を使用すること。
• 必須ループ: 「実装 → コンパイル → ログ確認 → 修正」を繰り返し、0 errors, 0 warnings を満たすまで作業を継続すること。
• ログ管理: コンパイルログは MQL5/Logs/compile_{ProgramName}.log に保存し、修正時は直近ログを根拠に対応すること。
• 修正優先度: コンパイルエラーを最優先で解消し、その後に警告を解消すること。
• 完了条件: ①コンパイル成功、②主要ロジックの整合性確認、③仕様書（_spec_ja.md / _spec_en.md）への反映。