シェーフ・トレンド・サイクル（STC）を責任ある形でバックテストするには？

測定する前に、指標の概念を定義する

シェーフ・トレンド・サイクル（しばしばSTCと略される）は、価格変動を有界なオシレーター風の系列へ変換するトレンドフォロー系の指標である。責任あるバックテストは、安定したメカニズムと変動する条件を分けることから始まる：

• 安定したメカニズム：入力（移動平均、平滑化、そしてオシレーターへのマッピングなど）から指標がどのように計算されるか。
• 変動する条件：市場の期間、価格ソース、執行方法、そして取引環境。

指標そのものにしか関心がなくても、バックテストには「結果（outcome）」とみなすものの正確な定義が必要である。例えば、特定のSTCレベルや方向転換が、その後の価格変動と一致しているかどうかを評価するかもしれない。その選択は最初に明示しておく必要がある。なぜなら、評価ルールが異なれば結果も異なり得るからだ。

データ前提とコスト前提を明示的に設定する

慎重なバックテストはデータ・パイプラインに依存する。計算の前に、これらの前提を述べる：

• 価格データ：使用する系列（例：bid/askか、mid/lastか）と、欠けたタイムスタンプをどう扱うか。
• 時間の整合：時刻 t の指標値が、時刻 t で利用可能な情報だけを使って計算されるかどうか。
• リサンプリング：ネイティブの時間足を使うのか、それともリサンプリングするのか、また境界がどのように揃えられるか。

コストは重要である。指標ベースの評価は、コストを無視すると利益が出ているように見えることがある。以下について明示的な前提を使う：

• 取引コスト：コミッション、スプレッド、またはその両方（選んだ価格系列と一貫する形で表現する）。
• スリッページ：バックテストで参照する価格から、執行価格がどれだけずれるか。
• レイテンシ：次の足の始値、終値、または別のルールで約定すると仮定するかどうか。

不確実性を抑えるために、同じバックテストを複数のもっともらしいコスト・シナリオ（例：低/中/高のスリッページ）で実行する。結論が大きく変わるなら、それは頑健性に関する警告サインである。

アウト・オブ・サンプル検証とパラメータ安定性チェックでバイアスを制御する

指標バックテストでよくある失敗モードは 過学習（overfitting） である。これは、歴史的期間で良い見た目になるようにパラメータや選択ルールを調整するが、別の局面でのパフォーマンスを保証しない状態を指す。これを減らすには、ワークフローの段階を分ける：

1. 一度だけ定義：評価ルール（どのイベントが指標を発火させるか）と、パラメータセットの境界を、結果を見る前に決める。
2. トレーニング・ウィンドウで調整：パラメータを調整する場合でも、それはトレーニング区間でのみ行う。
3. アウト・オブ・サンプルで検証：調整に使わなかった後続データで、選んだ設定をテストする。
4. 複数の分割で繰り返す：ローリングまたはウォークフォワードの複数区間を使い、結果がたまたま一つの運の良い期間から来ている確率を下げる。

実務的なバイアス管理は パラメータ安定性 である。例えば、結論が狭いパラメータ範囲に依存しているなら、その関係は不安定である可能性が高い。小さなパラメータ変更で結論が反転しないかを確認する。

少なくとも1つの重要な制限または失敗モードを評価する

過去のバックテストの成功は、将来の結果を示すものではない。パフォーマンス指標は、レジームと執行前提に条件づけられていると考えるべきだ。最低限、次のような 重要な失敗モード を1つテストする：

• レジーム転換：トレンド指標は、レンジ相場では持続的なトレンドよりも挙動が異なることが多い。
• 指標の遅れ：平滑化は応答を遅らせる。評価ルールが、指標の情報遅れの後に結果を測っているかどうかを評価する。
• コスト/執行への感度：スプレッドを除いたり、非現実的な約定を仮定したりした後でしか指標が「機能しない」なら、その結論は脆い。

データリーケージ も確認するべきだ。指標値が、意思決定時点で利用可能だったデータだけを使って計算されていることを保証する。リーケージがあると、メカニズムが実運用では利用できなかったとしても、オシレーターのバックテストが正確に見えてしまうことがある。

検証と、次にあなたが尋ねるべき質問

責任ある検証プロセスは、2つの質問に独立して答える：

1. 再現性：同じデータ定義でバックテストを再実行すると、同じ結果が得られるか？
2. 外的妥当性：結論は、異なるアウト・オブ・サンプルのウィンドウやコスト・シナリオにまたがって持続するか？

次のステップとして、評価ルールと指標（メトリクス）を明確にする。例えば、方向の一致を測るのか、イベントベースのタイミング精度を測るのか、あるいは仮想ルールの収益性を測るのかを決める。次に、1つの要素だけを変えた後で、アウト・オブ・サンプルのプロセスを繰り返す。結果が1つの狭いセットアップでしか成り立たないなら、結論は一般的な約束ではなく「前提に条件づけられている（conditional on assumptions）」という形で述べるべきだ。

概念ページへのリンクも、計算とテストルールの整合性を保つのに役立つ。

DOCUMENT END