MQL5 max-position-limit完全ガイド｜実装・仕組み・注意点まで解説

1. MQL5のmax-position-limitとは何か（定義 / What）

【結論】
max-position-limitとは、EA（自動売買プログラム）において「同時に保有できるポジション数の上限」を制御するための基本的なリスク管理手法です。過剰エントリーや証拠金圧迫を防ぐために必須の設計要素です。

【定義】
max-position-limitとは「EAが同時に持てるポジション数（position）の最大値を制限するロジック」であり、MQL5の標準機能ではなく、開発者がコードで実装する必要があります。

1.1 max-position-limitの役割

max-position-limitは、EAの暴走を防ぐ「最もシンプルで効果的なフィルター（制御条件）」です。
特に以下のような状況で重要になります。

• 同一ロジックが連続してエントリーしてしまうケース
• スプレッド（spread）やスリッページ（slippage）悪化時でも注文が止まらないケース
• execution（約定処理）が遅延して重複注文が発生するケース

これらを防ぐために、「ポジション数」という明確な上限を設けることで、EAの挙動を安定させます。

1.2 なぜポジション数の制限が必要なのか

ポジション数を制限しない場合、以下のリスクが発生します。

• 過剰エントリー（Overtrading）
  → 同じ条件で何度も注文が出る
• 証拠金（margin）の急激な消費
  → ロスカットに直結
• ドローダウン（drawdown）の急拡大
  → 口座破綻リスク
• 注文競合（trade context busy）
  → 注文エラー・約定失敗

特にMQL5では、OnTickイベント（価格更新ごとに処理が走る）により、
条件が同じであれば短時間で複数のorderが発行される可能性があります。

そのため、
「条件が一致したからエントリー」ではなく
「エントリーしてよい状態か」を別に管理する必要があります。

1.3 max-position-limitの位置づけ（EA設計上）

EA設計において、max-position-limitは以下のレイヤーに属します。

• エントリー条件（シグナル）とは別
• リスク管理（Risk Control）の一部
• フィルター（Filter）の一種

整理すると：

• シグナル → エントリーするか判断
• フィルター → エントリーしてよいか制御

max-position-limitは後者に該当します。

1.4 関連する重要概念

理解を深めるために、関連用語を整理します。

• Position（ポジション）
  保有中の取引（Buy/Sellの状態）
• Order（注文）
  発注リクエスト（まだ約定していない可能性あり）
• Exposure（エクスポージャー）
  市場に晒しているリスク量
• Margin（証拠金）
  ポジション維持に必要な資金
• Execution（約定）
  注文が市場で成立すること

重要ポイント：

• 「注文数」ではなく「ポジション数」を制御する
• 約定後の状態を管理することが本質

1.5 他手法との違い（軽い補足）

max-position-limitは「数」を制御しますが、他にもリスク制御手法があります。

• ロットサイズ制御 → 1回あたりのリスク量
• DD制御 → 総損失
• スプレッドフィルター → execution品質

max-position-limitは「最も単純で即効性がある制御」であり、
初心者が最初に導入すべき安全装置です。

1.6 よくある誤解と注意点

初心者がつまずきやすいポイント：

• 「MT5に標準機能がある」と思っている
  → 実際は自作ロジックが必要
• 「1ポジション＝1注文」と誤解
  → 約定状態で区別される
• 「制限すれば安全」と過信
  → ロットやDD管理も必要

重要なのは、
max-position-limitは「単独では不十分だが、必須の基礎」である点です。

2. MQL5でmax-position-limitを実装する方法（手順 / How）

【結論】
MQL5でmax-position-limitを実装するには、「現在のポジション数を取得し、上限未満の場合のみ注文を許可する」条件分岐をエントリー前に追加します。

【定義】
実装とは、PositionTotalやPositionSelectを用いて「現在の保有ポジション数」を取得し、if文で制御する処理のことです。

2.1 基本ロジック（最小構成）

最もシンプルな実装は以下です。

int max_positions = 3;

if(PositionTotal() < max_positions)
{
    // エントリー処理
}

このコードの意味：

• PositionTotal() → 現在の全ポジション数を取得
• max_positions → 上限値（例：3）
• 条件成立時のみorder送信

2.2 実務で使う基本テンプレート

実際のEAでは、エントリー条件と組み合わせます。

int max_positions = 3;

// エントリー条件（例）
bool signal_buy = (Close[0] > Close[1]);

if(signal_buy)
{
    if(PositionTotal() < max_positions)
    {
        trade.Buy(0.1, _Symbol);
    }
}

ポイント：

• シグナル（signal）と制御（limit）は分離する
• order条件に直接組み込まない方が保守性が高い

2.3 シンボル別に制限する方法（重要）

実務では「全体ではなく、通貨ペアごと」に制御するケースが多いです。

int CountSymbolPositions(string symbol)
{
    int count = 0;

    for(int i = 0; i < PositionsTotal(); i++)
    {
        if(PositionGetSymbol(i) == symbol)
        {
            count++;
        }
    }
    return count;
}

使用例：

int max_positions = 2;

if(CountSymbolPositions(_Symbol) < max_positions)
{
    trade.Buy(0.1, _Symbol);
}

メリット：

• EURUSDだけ制限するなど柔軟な制御が可能
• ポートフォリオ運用に対応

2.4 マジックナンバーで制御する方法（高度）

EAごとにポジションを分離する場合：

int CountMagicPositions(int magic)
{
    int count = 0;

    for(int i = 0; i < PositionsTotal(); i++)
    {
        ulong ticket = PositionGetTicket(i);
        if(PositionSelectByTicket(ticket))
        {
            if(PositionGetInteger(POSITION_MAGIC) == magic)
            {
                count++;
            }
        }
    }
    return count;
}

使用例：

int max_positions = 3;
int magic = 123456;

if(CountMagicPositions(magic) < max_positions)
{
    trade.Buy(0.1, _Symbol);
}

ポイント：

• 複数EAの干渉を防ぐ
• 実運用では必須レベル

2.5 よくある失敗と注意点

① PositionTotal()だけで判断してしまう

• 他EAのポジションも含まれる
  → マジックナンバーで分離する

② 注文（Order）とポジションを混同

• 約定前の注文はカウントされない
  → execution遅延で重複エントリーの可能性あり

対策：

• フラグ管理 or 注文状態チェック追加

③ OnTickで多重実行される

// NG例
if(PositionTotal() < max_positions)
{
    trade.Buy(...); // 短時間で連続実行
}

対策：

• 前回エントリー時間を記録
• またはポジション存在チェック

④ スプレッド・スリッページ未考慮

• spread拡大時でもエントリーされる
• slippageにより想定外ポジション増加

対策例：

if(SymbolInfoInteger(_Symbol, SYMBOL_SPREAD) < 20)
{
    // エントリー
}

2.6 なぜこの方法で制御するのか（理由）

• MQL5はイベント駆動（OnTick）で動く
• 自動的なポジション制限機能が存在しない
• そのため「事前チェック」が唯一の防御手段

結論：

• エントリー前に必ずチェックする設計が必須

2.7 実務での推奨構成（まとめ）

実務では以下の3点を組み合わせます：

• max-position-limit（ポジション数制限）
• マジックナンバー制御
• シンボル単位の制御

これにより：

• EA間干渉防止
• 過剰リスク回避
• 安定したexecution

3. max-position-limitの仕組み（内部動作 / Why）

【結論】
max-position-limitは「ポジション状態（Position）」を毎Tick監視し、条件分岐でエントリーを抑制する仕組みです。MT5側に自動制限はなく、EA側で状態管理することで初めて成立します。

【定義】
仕組みとは、OnTick（価格更新イベント）→ 状態取得 → 条件判定 → 注文実行という一連の処理フローの中で、ポジション数を参照してエントリー可否を決定する動作を指します。

3.1 実行フロー（OnTickベースの制御）

MQL5のEAは以下の流れで動作します。

1. OnTickが発火（価格更新）
2. シグナル判定（エントリー条件）
3. ポジション数チェック（max-position-limit）
4. 注文送信（trade.Buy / Sell）
5. 約定（execution）→ ポジション化

擬似コード：

void OnTick()
{
    if(シグナル成立)
    {
        if(現在ポジション数 < 上限)
        {
            注文実行;
        }
    }
}

重要ポイント：

• 「エントリー後」ではなく「エントリー前」に制御する
• すべてのTickでこの判定が繰り返される

3.2 ポジションと注文の違い（最重要ポイント）

初心者が最も混乱するポイントです。

• Order（注文）
  → 発注リクエスト（まだ未約定の可能性あり）
• Position（ポジション）
  → 約定後の保有状態

max-position-limitが参照するのは：

👉 Position（約定済み）

つまり：

• 注文が通っていない状態はカウントされない
• execution遅延があると、制御が追いつかない可能性あり

3.3 なぜ重複エントリーが起きるのか

max-position-limitを理解するには、失敗パターンを理解する方が早いです。

原因：

• OnTickが高速で繰り返される
• 約定（execution）が遅れる
• PositionTotal()がまだ増えていない

結果：

Tick1 → 条件成立 → 注文
Tick2 → 条件成立 → まだ未約定 → 再注文
Tick3 → 同様

→ 意図せず複数ポジションが発生

3.4 実務的な対策（内部ロジック強化）

この問題に対する実務対策：

① 注文中フラグを持つ

bool is_ordering = false;

if(!is_ordering && PositionTotal() < max_positions)
{
    is_ordering = true;
    trade.Buy(...);
}

→ 二重発注防止

② 約定確認後にフラグ解除

• OnTradeTransactionで管理するのが理想
• または時間ベースで解除

③ PositionSelectで存在確認

if(!PositionSelect(_Symbol))
{
    // 新規エントリー許可
}

→ シンプルだが制御が強すぎる場合あり

3.5 ネッティング口座とヘッジ口座の違い

MQL5では口座タイプによって挙動が変わります。

ネッティング口座

• 1シンボル＝1ポジション
• ポジション数制御の意味が薄い

ヘッジ口座

• 複数ポジション可
• max-position-limitが有効

結論：

• 本記事の内容は主にヘッジ口座向け

3.6 なぜ標準機能が存在しないのか

理由は設計思想にあります。

• MT5は「自由度の高いトレード環境」
• 制限はユーザー（EA）が実装する前提
• ブローカーごとの仕様差にも対応可能

つまり：

👉 max-position-limitは「EA設計の責任領域」

3.7 他手法との構造的な違い

比較観点：

• ロット制御 → 金額ベース
• DD制御 → 損失ベース
• max-position-limit → 数量ベース

特徴：

• 最も単純
• 最も高速
• 最も確実に動く

ただし：

• リスク量の細かい制御はできない

3.8 まとめ（短文化）

• max-position-limitは「状態監視＋条件分岐」で実現
• ポジション（約定済み）を基準にする
• execution遅延が最大のリスク
• フラグ管理で補強するのが実務

4. max-position-limitと他手法の違い（比較 / vs 他手法）

【結論】
max-position-limitは「ポジション数」を制御する最もシンプルなリスク管理であり、ロット管理・DD制御・フィルター系とは役割が異なります。単独では不十分で、他手法と組み合わせることで初めて実務レベルの安全性になります。

【定義】
比較とは、リスク制御手法を「何を制御するか（数量・金額・条件）」という軸で整理し、用途の違いを明確にすることです。

4.1 リスク管理手法の全体像

EAのリスク管理は主に以下の4分類に分けられます。

4.2 max-position-limit vs ロット管理

違いの本質：数量 vs 金額

補足：

• max-position-limitだけでは「大ロット連発」は防げない
• ロット管理だけでは「ポジション乱発」は防げない

👉 両方必要

4.3 max-position-limit vs DD制御

違いの本質：事前制御 vs 事後制御

補足：

• DD制御は「最後の防衛ライン」
• max-position-limitは「一次防衛」

👉 両方で二層防御が理想

4.4 max-position-limit vs フィルター（spread / slippage）

違いの本質：数量制御 vs 環境制御

補足：

• スプレッドが広いときの無駄エントリーは防げない
• slippage悪化時の損失も抑えられない

👉 併用が前提

4.5 実務での最適な組み合わせ（推奨構成）

実務では以下の4層構造が基本です。

1. max-position-limit（数量制御）
2. ロット管理（リスク量制御）
3. フィルター（環境制御）
4. DD制御（最終防衛）

イメージ：

エントリー前
 ├ 数量チェック（max-position-limit）
 ├ ロット計算
 ├ スプレッド/スリッページ確認
 ↓
エントリー
 ↓
損失拡大時 → DD制御

4.6 よくある設計ミス

① max-position-limitだけで満足してしまう

→ ロット過大で破綻する

② DD制御に依存しすぎる

→ すでに損失発生後で遅い

③ フィルター未実装

→ execution品質が悪化（スプレッド拡大時の損失）

④ 手法がバラバラに実装されている

→ ロジックが複雑化・バグ増加

4.7 どの手法を優先すべきか（初心者向け）

優先順位：

1. max-position-limit（最優先）
2. ロット管理
3. フィルター
4. DD制御

理由：

• max-position-limitは実装が簡単で効果が即出る
• 他手法の前提になる「土台」

4.8 まとめ（短文化）

• max-position-limitは「数量制御」
• ロット管理は「金額制御」
• DD制御は「損失制御」
• フィルターは「環境制御」
• 実務では組み合わせが必須

5. max-position-limitの実務での使いどころ（応用 / Use Case）

【結論】
max-position-limitは「戦略の特性に応じて上限値を設計する」ことで効果が最大化されます。単なる固定値ではなく、ロジック・市場環境・資金管理と連動させるのが実務的です。

【定義】
使いどころとは、EAの戦略タイプ（トレンド・ナンピン・スキャルピングなど）に応じて、適切なポジション数制限を設計・適用することを指します。

5.1 トレンドフォロー型EAでの使い方

特徴：

• シグナル発生頻度が低い
• 1〜数ポジションで十分

推奨設定：

• max-position-limit：1〜3

理由：

• 同方向に複数ポジションを持つとリスク集中
• 過剰エントリーのメリットが少ない

実装例：

int max_positions = 2;

if(CountSymbolPositions(_Symbol) < max_positions)
{
    trade.Buy(0.1, _Symbol);
}

5.2 ナンピン・グリッド系EAでの使い方

特徴：

• ポジションを積み増す前提
• ドローダウン耐性が重要

推奨設定：

• max-position-limit：5〜20（戦略依存）

理由：

• 無制限だと破綻確率が急上昇
• 上限が「最大損失」を決定する

重要：

👉 この上限＝最悪シナリオのリスク

設計視点：

• ロット × ポジション数 × 値幅 ＝ 最大DD

5.3 スキャルピングEAでの使い方

特徴：

• 高頻度エントリー
• execution品質に依存（spread / slippage）

推奨設定：

• max-position-limit：1〜2

理由：

• 同時ポジションは基本不要
• execution遅延による重複注文防止

補助：

if(SymbolInfoInteger(_Symbol, SYMBOL_SPREAD) < 15)
{
    // エントリー許可
}

5.4 マルチ通貨EAでの使い方

特徴：

• 複数シンボルを同時運用
• 全体リスクが見えにくい

設計パターン：

① シンボルごと制限

CountSymbolPositions(_Symbol) < 2

② 全体制限

PositionTotal() < 10

③ ハイブリッド（推奨）

• シンボル単位 + 全体上限

理由：

• 一部通貨に偏るのを防ぐ
• ポートフォリオ全体を制御

5.5 実務でよく使う設計パターン

パターン① 固定上限

• max_positions = 3
• シンプル・初心者向け

パターン② 可変上限（資金連動）

int max_positions = AccountBalance() / 100000;

メリット：

• 資金増加に応じて拡張
• スケーラブル

パターン③ 状況依存（ボラティリティ連動）

• 高ボラ → 制限強化
• 低ボラ → 緩和

例：

if(ATR > threshold)
{
    max_positions = 2;
}
else
{
    max_positions = 5;
}

5.6 よくある失敗（実務）

① 上限値の根拠がない

→ バックテスト未検証

② ロットと連動していない

→ リスク過大

③ 市場環境を無視

→ ボラ急変で破綻

④ 複数EAで共有していない

→ 全体ポジション増加

5.7 実務視点の設計原則

重要ポイント：

• max-position-limitは「結果」から逆算する
• 最大DDを先に決める
• ロットと必ずセットで設計

式イメージ：

最大損失 ≒ ロット × ポジション数 × 値動き幅

5.8 まとめ（短文化）

• 戦略ごとに最適値は異なる
• ナンピン系は特に重要
• 固定値より「連動設計」が実務的
• max-position-limitはリスク設計の中核

6. よくある失敗・注意点（トラブルシューティング）

【結論】
max-position-limitは「実装は簡単だが、運用で崩れやすい」領域です。特に注文とポジションのズレ・複数EA干渉・イベント多重実行が主要な不具合原因になります。

【定義】
失敗・注意点とは、ポジション数制御が意図通り機能せず、過剰エントリーや未エントリーを引き起こす典型パターンとその対策を指します。

6.1 PositionTotal()だけで制御してしまう

【問題】
他EAや手動トレードのポジションも含まれてしまう。

if(PositionTotal() < max_positions)
{
    trade.Buy(...);
}

【影響】

• 意図せずエントリー停止
• 逆に制限が機能しないケースもある

【対策】

• マジックナンバーで分離

if(CountMagicPositions(magic) < max_positions)
{
    trade.Buy(...);
}

6.2 注文（Order）とポジション（Position）の混同

【問題】
約定前の注文がカウントされないため、重複エントリーが発生する。

【原因】

• execution遅延
• 約定前はPositionに反映されない

【典型パターン】

Tick1 → 注文送信
Tick2 → 未約定 → 再注文

【対策】

• 注文中フラグを導入
• OnTradeTransactionで約定管理

6.3 OnTickの多重実行による暴走

【問題】
OnTickは1秒間に何十回も実行されるため、条件が連続成立すると注文が連発される。

【NG例】

if(PositionTotal() < max_positions)
{
    trade.Buy(...);
}

【対策】

• エントリー間隔制御（時間フィルター）

datetime last_entry = 0;

if(TimeCurrent() - last_entry > 60)
{
    trade.Buy(...);
    last_entry = TimeCurrent();
}

6.4 ネッティング口座での誤動作

【問題】

• 1シンボル1ポジションしか持てない
• max-position-limitの意味が薄い

【症状】

• ポジション数が増えない
• ロジックが無意味になる

【対策】

• 口座タイプ確認

AccountInfoInteger(ACCOUNT_MARGIN_MODE)

6.5 シンボル未分離による誤制御

【問題】

• 全通貨ペアのポジションを合算してしまう

【影響】

• EURUSDの制御がUSDJPYに影響
• 意図しない停止

【対策】

• シンボル別カウント

CountSymbolPositions(_Symbol)

6.6 スプレッド・スリッページ未考慮

【問題】

• spread拡大時でもエントリー
• slippage悪化で想定外の価格で約定

【影響】

• 無駄ポジション増加
• パフォーマンス低下

【対策】

if(SymbolInfoInteger(_Symbol, SYMBOL_SPREAD) < 20)
{
    // エントリー許可
}

6.7 max-position-limitの過信

【問題】

• 「これだけで安全」と思ってしまう

【現実】

• ロット過大なら即破綻
• DD制御なしでは耐えられない

【対策】

• 他手法と組み合わせる

6.8 バックテストと実運用の差

【問題】

• バックテストでは問題ないのに本番で崩れる

【原因】

• execution遅延
• スプレッド変動
• 約定拒否

【対策】

• VPS環境でフォワードテスト
• 実ブローカー条件で検証

6.9 デバッグ方法（実務）

トラブル時はログを出すのが最速です。

Print("Current Positions: ", PositionTotal());

さらに：

Print("Symbol Count: ", CountSymbolPositions(_Symbol));

ポイント：

• 状態を可視化する
• 「なぜ動いたか」を追跡

6.10 まとめ（短文化）

• PositionとOrderの違いが最大の落とし穴
• OnTickの多重実行に注意
• マジック・シンボル分離は必須
• execution環境が結果を左右する
• max-position-limit単独では不十分

7. FAQ（よくある質問）

【結論】
max-position-limitは「ポジション数を制御するシンプルな仕組み」ですが、実運用では口座タイプ・注文状態・他EAとの関係を理解しないと誤動作します。以下のFAQで要点を短く整理します。

【定義】
FAQは、初心者がつまずきやすい疑問に対して「1問1答」で即解決できる形式の知識整理です。

7.1 max-position-limitはMT5の標準機能ですか？

いいえ、標準機能ではありません。
MQL5で自分で実装する必要があります。

7.2 PositionTotal()だけで制御して問題ないですか？

基本的には不十分です。
他EAや手動ポジションも含まれるため、マジックナンバーで分離するのが安全です。

7.3 注文（Order）とポジション（Position）の違いは何ですか？

注文は未約定、ポジションは約定済みです。
max-position-limitは「ポジション」を基準に制御します。

7.4 なぜポジション制限をしているのに複数エントリーされるのですか？

約定遅延（execution lag）が原因です。
OnTickが先に進み、ポジションが増える前に再注文されるためです。

7.5 ネッティング口座でも必要ですか？

基本的には不要です。
1シンボル1ポジションのため、制御の意味が薄くなります。

7.6 ロット管理とどちらが重要ですか？

両方必要ですが、役割が異なります。

• max-position-limit → 数量制御
• ロット管理 → 金額リスク制御

7.7 推奨されるmax-position-limitの値はいくつですか？

戦略によって異なります。

目安：

• スキャルピング：1〜2
• トレンドフォロー：1〜3
• ナンピン系：5以上（要検証）

7.8 スプレッドやスリッページも考慮すべきですか？

はい、必須です。
spreadやslippageを無視すると、無駄なエントリーが増えます。

7.9 max-position-limitだけでリスク管理は十分ですか？

不十分です。
ロット管理・DD制御・フィルターと組み合わせる必要があります。

7.10 実装後に確認すべきポイントは？

以下を必ずチェックしてください。

• ポジション数が意図通り制御されているか
• 他EAと干渉していないか
• execution遅延で崩れていないか

7.11 まとめ（短文化）

• max-position-limitは自作実装が必要
• ポジション基準で制御する
• execution遅延が最大の落とし穴
• 他のリスク管理と併用が前提