ドンチャンチャネルとRSIを組み合わせる考え方 — 高値・安値更新に勢いの質を重ねる設計

「直近の高値を更新した」という事実は、更新した背景まで教えてくれません。勢いのある上昇の途中で抜けたのか、伸び切ったあとの最後のひと押しで抜けたのか、水準の更新だけを見ているうちは同じ一件として処理されます。本記事では、直近N本の高値・安値を機械的に切り出す ドンチャンチャネル に、値動きの勢いを0〜100の範囲に正規化する RSI を重ね、更新の「質」を仕分ける設計を整理します。RSIを逆張りのしきい値として使うのではなく、更新の裏付けを測る目盛りとして扱う点が、この構成の要点です。設計の考え方を共有するものであり、特定の設定が成果につながることを示すものではありません。

ドンチャンチャネルの役割

ドンチャンチャネルは、直近N本の高値と安値をそのまま線として引いただけの指標です。平滑化も重み付けもなく、価格から直接切り出した水準がそのまま表示されます。基礎についてはドンチャンチャネルとは何を測る指標かで扱っています。

この単純さは、判定条件としては扱いやすさになります。「終値が上限を超えたか」は真偽値ひとつで表現でき、実装者によって解釈が割れる余地がほとんどありません。イベントの発生時刻を機械的に確定させる役として、これほど素直な指標は多くないと考えられます。

その一方で、返ってくる情報は発生の有無だけです。上限を更新した足が、参加者の勢いを伴っていたのか、薄い値動きの中で少しだけ上端をはみ出したのかは、チャネルの側からは区別がつきません。この構造はブレイクアウトとダマシの基本でも触れているとおり、更新という現象そのものが持つ性質です。単独で使うと、質の違う更新が同じ重みで並ぶ点が扱いにくさになります。

RSI の役割

RSIは、一定期間内の値上がり幅と値下がり幅の比率を0〜100の範囲に置き換えた指標です。詳しくはRSIとは何を測る指標かをご覧ください。数値が高いほど上方向の値動きが優勢だった期間、低いほど下方向が優勢だった期間、という読み方になります。

チャネルと並べたときの性格の違いは、測っている対象にあります。チャネルが見ているのは価格の「位置」であり、RSIが見ているのは値動きの「速度」です。位置は更新したかどうかで白黒がつきますが、速度は連続量として推移します。この連続量を、更新が起きた瞬間の背景として読むのがここでの使い方です。

単独利用時の限界もはっきりしています。RSIは上限と下限を持つ有界の指標なので、方向感の強い局面では高い水準や低い水準に張り付いたまま長く推移します。そのため、一定水準に達したことを反転の合図として単独で扱うと、動きが続いている最中に何度も反応してしまいます。RSIが示しているのは行き過ぎの度合いであって、反転の時刻ではない、という整理が必要です。

なぜこの組み合わせか

両者の関係を整理すると、ドンチャンチャネルが「いま起きたこと」を、RSIが「その裏側にあった勢い」を担当する構成になります。

第一の接点は、同じ更新を水準で仕分ける ことにあります。上限を更新した足でRSIが中立の水準から明確に上へ振れているなら、価格の位置と値動きの速度が同じ向きを示している状態です。逆に、更新は起きているのにRSIが中立付近から動いていなければ、位置だけが先行して速度が伴っていない状態と読めます。同じ「上限更新」という現象を、速度の状態によって二種類に振り分ける形になり、ノイズフィルターとして機能することが期待されます。

第二の接点は、更新どうしを比較する 視点です。チャネルは高値を更新したかどうかしか記録しませんが、前回の更新時点のRSIを保持しておけば、今回の更新がその時より強い速度を伴っていたのかを比べられます。価格は切り上がっているのにRSIの山が切り下がっている状態は、ダイバージェンスとして知られる形です。更新の連続を並べて見ることで、上昇の勢いが積み増されているのか、細っているのかを判定する材料になります。

注意点として、この2つでは 変動幅の情報が欠けています。更新の有無と速度の強弱は分かっても、1本あたりどの程度動く相場なのかは分かりません。損切り幅や利益確定幅の設計まで含めたい場合は、ドンチャンチャネルとATRの組み合わせで扱った軸を三層目として重ねる拡張が検討対象になります。

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

唯一の正解と呼べる設定は存在しません。ここでは検証を始めるための足がかりとして、考え方の筋道だけを並べます。

チャネル期間は、細かい波まで拾いたいのか、大きな流れだけを対象にしたいのかで決まります。短い足で機敏に反応させたい場合は10〜20本程度、日足のような大きな時間軸では50本以上が引き合いに出されることが多いようです。期間を延ばすほど更新の回数は減り、一回あたりの重みは増していく関係にあります。

RSIの期間は14が慣例的に使われますが、これは絶対的な基準ではありません。期間を短くすると値の振れ幅が大きくなり、更新のたびに極端な数値が出やすくなります。長くすると滑らかになる代わりに、更新時点の勢いの差が見えにくくなります。チャネル期間との関係で言えば、チャネルより極端に短い期間を使うと、比較したい「山の高さ」がその都度別の性格の数値になってしまう点に注意が必要です。

しきい値の扱い方も設計の分かれ目です。中立の50を境に上下どちらが優勢かを見る使い方と、70や30といった水準を勢いの強さの目盛りとして読む使い方では、判定の意味が変わります。反転の根拠として使わないと決めておくと、条件の役割が混ざらずに済みます。どの数値を採る場合でも、バックテストとフォワード検証で挙動を確認してから先へ進めてください。

cBot化する際の考慮点

実装で詰まりやすい論点を4つ挙げます。

当該足を含めずに水準を求める: 判定する足の高値を含めて上限を計算すると、その足の高値によって上限が定義上更新されてしまいます。一つ手前の足までで確定させた水準を先に固定し、そこへ判定対象の足の終値をぶつける順序にすると、条件の意味がぶれずに済みます。

参照する足を一致させる: 更新の判定に使う足と、RSIを読む足はそろえておきます。片方を確定足、もう片方を形成中の足で見ると、同じ条件が足の途中で成立したり消えたりします。処理をOnBarに寄せておくと、この種のずれを構造的に避けられます。

前回の更新時点の値を保持する: 山の切り下がりを見る設計では、直近の更新が起きた足のRSIを状態変数として残す必要があります。あわせて、この記録をいつ捨てるかも決めておきます。反対側のラインに触れたら破棄する、一定本数が経過したら破棄するなど、基準を明文化しないと、遠い過去の値と比較し続ける実装になりがちです。

履歴不足をガードする: 起動直後は履歴が足りず、水準もRSIの値も信頼できません。チャネル期間とRSI期間の長いほうを基準に必要本数を割り出し、それを満たすまでは早期リターンで抜ける形にしておきます。

// 抜粋: 前バーまでで確定した上限と、更新時点のRSIを比較する
private RelativeStrengthIndex _rsi;
private double _lastBreakoutRsi = double.NaN;

protected override void OnStart()
{
    _rsi = Indicators.RelativeStrengthIndex(Bars.ClosePrices, RsiPeriod);
}

protected override void OnBar()
{
    if (Bars.Count < Math.Max(ChannelPeriod, RsiPeriod) + 2) return;

    // 判定対象の足（Last(1)）を含めず、その手前のN本で上限を求める
    double upper = double.MinValue;
    for (int i = 2; i <= ChannelPeriod + 1; i++)
        upper = Math.Max(upper, Bars.HighPrices.Last(i));

    double close  = Bars.ClosePrices.Last(1);
    double rsiNow = _rsi.Result.Last(1);

    if (close > upper)
    {
        bool momentumHolds = double.IsNaN(_lastBreakoutRsi) || rsiNow >= _lastBreakoutRsi;
        _lastBreakoutRsi = rsiNow;
        // momentumHolds が false の更新は、裏付けが弱い候補として別扱いにする
    }
}

決済条件をRSIに寄せるのは相性が良くありません。RSIは入口での裏付け確認に向く一方、撤退の水準は反対側のラインやATRベースなど、価格の幅を扱う系統で設計すると役割が混ざらずに済みます。

実装の流れ

全体の処理は、次の三層に整理できます。

1. 検知層: 確定足を受け取り、手前までで確定したチャネル水準と終値を比較して、更新が起きたかどうかを判定します
2. 評価層: 更新が起きた足のRSIを読み、中立水準との位置関係と、前回の更新時点との高低を確認します。裏付けが弱い場合は候補から外し、記録だけ残します
3. 出口層: 反対側のラインやミドルライン、変動幅ベースの水準から撤退基準を組み立て、通知または発注へ渡します

層ごとに関数を分けておくと、「評価層をRSIから別の指標へ入れ替える」「出口層の期間を外部パラメータに出す」といった手直しが、一箇所の書き換えで収まります。いきなり発注まで結ぶのではなく、まずは通知だけを出す構成で走らせ、どの更新が外れているのかを自分の目で確認する期間を設けると、条件の癖をつかみやすくなります。

どう活用するか

自分で組んでみたい方は、検知・評価・出口という区切りを、そのままClaude Codeへ渡す指示書の見出しに転用できます。「前回の更新時点の値を保持し、いつ破棄するか」という状態管理の部分は、指示を細かく書くほど実装が安定しやすい箇所です。

開発を任せたい方は、ai-programming.xyz へ相談する前に「更新をどの足で確定させるか」「裏付けが弱い更新をどう扱うか」の2点を言語化しておくと、仕様の詰めがスムーズです。体系的に学びたい方には、状態変数の寿命設計が、スクールの演習題材としてちょうどよい難度になります。

評価層に置く指標を入れ替えても、検知と出口の作りは変えずに済みます。一度組んだ三層をひな形として残しておくと、別のロジックを試すときの初速が上がります。

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