ダマシを減らす二重確認の設計 — 主判定と補助判定でシグナルを絞り込む考え方

シグナルが点灯した直後に価格が逆行し、損切りにかかってから元の方向へ戻っていく——いわゆる「ダマシ」は、どんな単独シグナルにも一定の割合で紛れ込みます。本記事では、エントリー候補を検知する「主判定」と、その候補を通すか捨てるかを決める「補助判定」を分離し、二段階の確認でダマシを削る設計を整理します。特定の条件が成果を保証するという話ではなく、cBotへ落とし込む際の考え方を共有することが目的です。ダマシそのものの基礎はブレイクアウトとダマシの基礎で解説しています。

主判定（トリガー）の役割

主判定は、エントリー候補を見つけ出す検知器です。直近高値のブレイク、移動平均線のクロス、バンドへのタッチなど、「この形が出たら検討する」という条件がこれにあたります。候補を見逃さないことが仕事なので、反応の速さ——つまり感度が重視されます。

一方で、感度の高い判定はノイズも同じだけ拾います。ブレイクの瞬間だけを見ても、その後に続伸していく「本物」と、ヒゲだけ残して戻ってしまう「ダマシ」は区別がつきません。区別に必要な情報（終値がどこで確定したか、値幅が伴っていたか）は、シグナル発生の時点ではまだ存在していないからです。これが主判定単独の構造的な限界です。

補助判定（確認フィルター）の役割

補助判定は、主判定が挙げた候補を通すか捨てるかを決める側です。代表的な確認条件には次のようなものがあります。

• 確定バーの確認: ヒゲによる一時的な突破ではなく、終値がラインの外側で確定したかを見る
• 値幅の確認: ブレイク幅がATR(Average True Range、平均的な変動幅を測る指標)に対して十分かを見る。ATRの読み方はATRの基礎を参照してください
• 環境の確認: 上位足の方向や、トレンド相場とレンジ相場の区別と矛盾していないかを見る

補助判定は単独ではエントリーの瞬間を決められません。また、確認には時間がかかるため、条件を重ねるほどエントリーは遅れます。あくまで「候補を絞る」ことに専念する階層です。

なぜ二重確認か

一つの判定条件の中で「見逃さないこと」と「誤検知を捨てること」を両立させようとすると、感度を上げればダマシが増え、条件を厳しくすれば本物まで逃す、という綱引きになります。二重確認の核心は、この綱引きを階層の分離で解消することです。主判定は感度に振り切って候補を広めに出し、補助判定が精度を担当して候補を削る。層を分けることで、それぞれを別々に調整できるようになります。

設計上もっとも重要なのは、補助判定が主判定と独立した情報を見ていることです。たとえば期間違いのオシレーターを2本並べても、同じ値動きから同じ計算系統で導かれた指標は同じノイズに同時に反応するため、確認としてはほとんど機能しません。「価格がラインを抜けたか」という主判定に対して、終値の確定・変動幅・上位足の環境といった性質の異なる情報を重ねることで、初めて「二重」の意味が生まれます。

ただし、ダマシをゼロにすることはできません。確認を増やすほど、誤シグナルと一緒に本物の初動も削られ、エントリーは遅くなります。二重確認は「ダマシの一部を、遅延と機会損失というコストを払って削る」仕組みであり、そのコストをどこまで払うかは検証で決める性質のものです。

パラメータをどう考えるか

この設計で調整するのは、主判定の感度そのものよりも「確認の深さ」です。

• 待つバーの本数: 確定バーを1本待つか、2本連続の確定を求めるか。深く待つほど判断材料は増えますが、その分だけ入りは遅れます
• 値幅の下限: ブレイク幅にATRの一定割合を要求する場合、その割合をどの程度にするか。大きくするほど通過する候補は減ります
• 候補の有効期限: 主判定の発火から何本以内に確認が取れなければ破棄するか

短い時間足ほどノイズの比率が上がるため確認の価値は増しますが、遅延の相対的なコストも大きくなります。「これが正解」という組み合わせは存在しないため、通過した候補と捨てた候補の両方を記録し、バックテストで見比べる工程が前提になります。

cBot化する際の考慮点

二重確認の実装で特徴的なのは、状態を持つことです。主判定と補助判定は同じバーで成立するとは限らないため、「候補が出ている」という中間状態の管理が必要になります。

• 判定順序の固定: 主判定 → 候補登録 → 補助判定の順序を崩さないようにします。補助判定を先に評価すると、候補がないのに確認だけが成立する不整合を生みます
• 候補の保持と失効: 主判定の発火を方向・基準価格・有効期限とともにフィールドへ記録し、期限切れの候補は明示的に破棄します
• 逆方向シグナルの扱い: 候補の保持中に逆方向の主判定が出た場合、旧候補を破棄するのか併存させるのかをルール化しておきます
• 確定バーの使用: 主判定・補助判定とも Last(1) の確定値で評価すると、検証結果と実運用の食い違いを避けやすくなります。判定は足の確定ごとで十分なので OnBar ベースが素直です
• 本数の下限: ATRや上位足を参照する場合、必要な本数が揃っているかを Count で確認してから計算に進みます

// OnBar内: 主判定 → 候補登録 → 補助判定 の順で評価する
if (pendingBreakout == null && Bars.ClosePrices.Last(1) > recentHigh)
    pendingBreakout = new Candidate(Bars.OpenTimes.Last(1), expiryBars: 3);

if (pendingBreakout != null && IsConfirmed(atr, breakoutWidth))
{
    // リスク幅の設定と発注条件の確認を経てエントリー処理へ
    pendingBreakout = null;
}

実装の流れ

処理の流れを上流から並べると、次のようになります。

1. 主判定の監視: 足の確定ごとに、ブレイクやクロスなどのトリガー条件を評価します。
2. 候補登録: 発火したら、方向・基準価格・有効期限を添えて候補として保持します。
3. 補助判定: 独立した確認条件（確定バー・値幅・環境）を候補に対して評価します。
4. 振り分け: 確認が取れた候補だけをエントリー処理へ渡し、ATRなどを物差しにリスク幅を設定します。不合格・期限切れの候補は破棄します。
5. 記録: 候補ごとに「どの確認で落ちたか」「通過後にどう推移したか」を残し、確認条件の効き具合を後から検証できるようにします。

どう活用するか

「感度の高い検知」と「独立した情報による確認」を分けるという骨格は、主判定をブレイクからクロスへ、補助判定を値幅から上位足整合へ差し替えても崩れない、使い回しの効く設計です。

自分で組んでみたい方は、Claude Codeを併走させたcBot開発の設計メモとして、本記事の構成をそのまま使ってみてください。作るより相談したいという方は、ai-programming.xyzで個別の開発相談を受け付けています。体系的に学びたい方に向けては、スクールでこうした状態管理を含む戦略実装を、手を動かしながら学べるコースを用意しています。

本記事は一般的な情報提供を目的としています。投資助言ではありません。 取引判断はご自身の責任で行ってください。