責任ある形でTEMAをバックテストするにはどうすればよいですか？
バックテストする前にTEMAが意味すること
TEMAは通常、3つの移動平均に基づく「3回平滑化された移動平均」の構成を指します。バックテストにおける重要な考え方はシンプルです。過去の価格から時系列の値を計算し、その値が変化したときに何をするか（たとえば意思決定の境界）をルールとして定義します。計算と評価の両方が透明であるとき、バックテストは責任あるものになります。
「implications（含意）」を議論する前に、2つを分けてください：
- インジケータの仕組み：正確な式、入力（価格の種類）、パラメータ（多くの場合は参照期間の長さ）。
- 意思決定ルール：インジケータ値を、測定可能な成果へどう変換するか。
この2つを曖昧にすると、インジケータの挙動を取引可能な優位性と取り違える可能性があります。
メカニズム：データ、コスト、前提、再現性を定義する
責任あるバックテストは、データ契約—どのデータを使い、どう使うかを文章で定義すること—から始まります。
TEMAについては、少なくとも次を定義してください：
- 価格入力：終値、ミッド、または別の一貫した項目。
- 時間の整合：時刻 t のシグナルが、バー t の終わりに利用可能な情報を使うのか、それとも t-1 までの情報だけを使うのか。
- サンプリング：どの時間足（例：1時間足のバー）か、そしてそれを一定に保つか。
- パラメータの扱い：TEMAの長さをどう選ぶか、固定するのか調整するのか。
前提としてコストで評価します。将来の正確なコストを知ることができなくても、次のようなコストの枠組みを含めるべきです：
- スプレッド／取引コスト：1回の取引あたり、または回転率あたりの推定として。
- スリッページ：執行時間の調整として。
- 取引頻度の影響：インジケータを多くの変化に変換すると、コスト感度が高まる可能性があります。
これらの前提を、式を定義するのと同じやり方で明示してください。インジケータのタイミングとコストのタイミングの整合が一貫していないと、バックテストは実執行では成立しないようなパフォーマンスを示してしまうことがあります。
エビデンスと例：隠れた先読みを避け、アウト・オブ・サンプルで検証する
よくある失敗パターンは先読みバイアスです。バックテストが、（たとえば「行動した」ときに）その時点で知られていなかったデータによって値を計算してしまうなど、整合の誤りにより未来の情報を偶然使ってしまいます。リスクを減らすには：
- 意思決定の時点までに利用可能だった過去データだけでTEMA値を計算する。
- 同じ整合で意思決定ルールを適用する。
- サニティチェックで検証する（たとえば入力を1本ずらすと、整合がずれている結果は実質的に変わるはずです）。
そして、アウト・オブ・サンプルで結果を検証します。責任あるワークフローでは、次の分離を保ちます：
- イン・サンプル：パラメータや閾値を決める。
- アウト・オブ・サンプル：評価だけ行う。
頑健性のために、複数のアウト・オブ・サンプル期間、または期間をまたいでサイクルを繰り返すウォークフォワード手法を検討してください。アウト・オブ・サンプルのパフォーマンスを確認する前にパラメータを調整しないでください。
限界とリスク：それでも何がうまくいかない可能性があるか
仕組みが良くても、バックテストが失敗するのは、過去の関係が将来の挙動を保証しないためです。
主な限界と失敗モードには次が含まれます：
- レジーム依存：移動平均の平滑化は、トレンド相場とレンジ相場で異なる性能を示し得ます。
- 過学習：多くのパラメータ値を試して最良を選ぶと、ノイズを捉えてしまう可能性があります。
- 執行の不一致：コスト、約定、レイテンシが前提と異なり得ます。
- データ品質の問題：欠けたバー、コーポレートアクション、不整合なフィードが計算を歪める可能性があります。
また、概念的な限界にも注意してください。TEMAは平滑化された統計量を表します。これを単独の「シグナル」として提示すると、パフォーマンスが意思決定ルール、タイミング、コストに依存する点を無視してしまいます。
検証：バックテストを信じる前に確認すべきこと
自分の作業を独立に検証するには、他者が再現できるチェックリストが必要です：
- 再計算：同じ入力と式からTEMA系列を再現できますか？
- タイミング監査：シグナルとコストの前提は、バーの利用可能性と一致していますか？
- 感度分析：パラメータ選択をわずかに変えると、結果は実質的に変わりますか？
- アウト・オブ・サンプルの規律：調整中に評価期間を触らずに保ちましたか？
- 要約指標：単一の数値ではなく、複数の指標（たとえば平均リターンやドローダウン）を報告します。
これらのチェックが成り立たない場合、バックテストを「将来の結果の証明」としてではなく、「前提が結果にどう影響するか」を探る探索的モデルとして扱ってください。
次の質問をするタイミング
バックテストがタイミング監査とコスト監査のもとで安定しているのに、それでも期間によって大きく変動するなら、次の検証ステップは単一の「最良」設定を探すことではありません。