RSI Rangeを責任を持ってバックテストするには？
RSI Rangeとバックテスト可能なルールを定義する
RSI Rangeは、インジケーターを単一の「はい／いいえ」シグナルとして扱うのではなく、RSI値がバンド（たとえば「range-high」「range-low」ゾーン）内でどのように動くかを表す方法です。バックテストの前に、仕組みを平易な言葉で定義してください。
- RSIの計算方法（適用する場合は、参照期間の長さ、平滑化手法）。
- 「Range」が意味するもの（正確なバンド境界と、それが固定か導出か）。
- 測定するもの（たとえば、タッチ回数、バンド内にいた時間、反転、または持続性など）。
責任あるバックテストは、各概念を再現可能な決定論的ルールに落とし込むことから始まります。同じ説明から2人が異なるバンド定義をコード化してしまうなら、テスト結果は検証可能ではありません。
前提を設定し、データルールを選ぶ
バックテストは、データルールが正直であるのと同じだけ正直です。計算の前に、明確な前提を使い、それを述べてください。
- バーまたはティックの粒度：ローソク足（open/high/low/close）を使うのか、どのタイムフレームか？RSIはサンプリングに敏感です。
- 先読み回避：意思決定の瞬間に利用可能な値だけを使うようにする。
- 時間の扱い：日足データを使う場合、日中の順序を仮定できません。執行の前提はデータと一貫させてください。
- データクリーニング：欠けたバー、休日、外れ値をどう扱うかを決める。
実務的な方法として「データ契約（data contract）」を作ります。これは、正確なデータセット、タイムフレーム、タイムスタンプ、そして任意のフィルタリングを定義する短いチェックリストです。これがないと、2つのバックテストを意味のある形で比較できません。
仮説の一部としてコストと執行をモデル化する
多くのバックテストが失敗するのは、取引を摩擦のないものとして扱うからです。教育目的であっても、取引コストをモデル化することで誤解を招く結論を避けられます。
結果を大きく変え得る要素を含めてください。
- スプレッド、またはビッド／アスクの効果（簡略化した一定値であっても）。
- スリッページモデル（たとえば、執行ごとの固定の不利なオフセット、またはオフセットの範囲）。
- 注文のタイミング：エントリーは次のバーの始値で起きる想定か、バーの終値か、あるいはRSI Range条件を含むバーで起きる想定か？
- 保有時間または決済ロジック：エントリーと同じ決定論的な方法で定義する。
次に感度チェックを行います。結果が狭く楽観的なコスト仮定のもとでしか成り立たないなら、それは警告サインです。
堅牢な検証でバイアスを制御する
責任あるバックテストには、「結果を設計する」ことへのガードレールが必要です。よくあるバイアス制御には次が含まれます。
- ウォークフォワード検証：パラメータは過去データでのみフィットし、その後の未見データでテストする。
- アウト・オブ・サンプル評価：定義の調整に一度も使わないホールドアウト期間を保持する（バンド幅、閾値、RSIの長さ）。
- 複数の分割：複数の時間窓にわたって手順を繰り返し、特定の相場期間が支配する確率を下げる。
- パラメータの規律：調整する自由度の数を制限する。特定のパターンを追うために多くの閾値を調整すると、過学習のリスクがあります。
役立つ検証基準は次のようなものです。つまり、同じデータセットと前提が与えられたとき、同僚があなたの正確なパイプラインを再現して同じ指標のトレンドを見ることができるか？
少なくとも1つの重要な制限を認識する
RSI Rangeのバックテストは、いくつかの理由で破綻し得ます。失敗モードを積極的に探すべきです。
- レジーム転換：RSIの「レンジ挙動」は、ボラティリティ構造や市場参加が変わると変化する可能性がある。
- 非定常性：リターンやオシレーションの統計的性質は時間とともにずれるため、過去のバンドが後に同様に振る舞うとは限らない。
- 定義への過学習：バンド境界が結果を見た後で選ばれている場合、それらはノイズを符号化しているかもしれない。
- 執行の不一致：意思決定がインターバーの情報を使っているのに、バックテストがローソク足レベルの約定を前提としている場合、モデル化されたパフォーマンスが不自然に一貫してしまうことがある。
責任ある記事やノートブックでは、そのセットアップにとってどの制限が最も関連しているのか、そして検証がそれを検出しようとする試みは何かを明示すべきです。
明確で独立したチェックリストで検証する
事実を独立に検証したいなら、予測ではなく検証可能性に焦点を当てたチェックリストを使ってください。
- 定義の確認：RSIとバンドのルールは正確に再現できるか？
- データの確認：バックテストは先読みを防ぎ、明記されたタイムフレームと一致しているか？
- コストの確認：スプレッド／スリッページは透明性をもってモデル化されており、感度テストがあるか？
- バイアスの確認：ウォークフォワードまたはアウト・オブ・サンプル検証が、調整の範囲を限定して行われているか？
- 失敗モードの確認：少なくとも1つの攪乱シナリオ（コスト変更、異なる時間分割、または執行タイミングの変更）でテストしたか？
DOCUMENT END