複数時間軸ピボット：確認と因果関係の整合性

実践の流れ

1. 別々に計算する各時間枠には、それぞれ独自のバー、ピボットポイント、カレンダーがあります。
2. 利用可能時刻を記録するピボット確定とデータ配信の遅延を含めます。
3. 後ろ向きに結合既に判明している最新の状況を利用する。
4. 候補の条件を固定する大きい価格構造でゾーンを、小さい構造でタイミングを定めます。
5. 付加価値を測定するより短い時間枠のみのベースラインと比較してください。

複数のスケールと複数の時間枠は異なるデザインです

複数のスケールとは、同じ H=1 シリーズ上で、2、5、10 のピボット半径を実行することを意味します。複数の時間枠とは、H=1、H=4、または日足バーを個別に計算することを意味します。これらは同等ではありません。4 つの H=1 バーを H=4 に集約すると、それらの内部シーケンスが破棄されます。半径 8 の H=1 ピボットは、半径 2 の H=4 ピボットと必ずしも一致するとは限りません。

TradingViewはバーの時間枠[1]を定義し、確認済みの上位時間枠リクエスト[2]について説明します。提案されたプロトコルでは、H=4はコンテキストにのみ割り当てられ、H=1はトリガーにのみ割り当てられます。トレードは、過去の結果が最も説得力があるように見える時間枠を選択することはできません。

どのようなコンテキストが貢献すべきかを明確に定義してください。方向性、基準ゾーン、またはボラティリティ体制を特定できるかもしれません。これら3つをすぐに組み合わせると、どの要素が役立つのかを見つけるのが難しくなります。まずは1つの役割から始め、より短い時間枠のベースラインと比較し、登録済みの実験としてのみ複雑さを追加してください。

極値が発生した時刻ではなく、データを使える時刻で結合する

各ピボットには、occurred_at、confirmed_at、およびavailable_atが必要です。最後のフィールドには、該当する場合、データ配信と処理の遅延が含まれます。H=1決定時間tでは、H=4状態のみを使用し、そのavailable_at≤tが必要です。H=4ピボットでr=2が必要な場合、極端なバーの閉鎖だけでは不十分です。さらに2つのH=4バーも閉鎖する必要があります。

pandas の後方 merge_asof は、左側キー時刻以下の最新の右側レコードを選びます。[3] available_at で結合し、銘柄と取引所ごとに分け、時刻順に並べ、文脈情報の最大有効期間を適用します。最近傍結合は未来の観測を選ぶ可能性があり、この因果的参照には適しません。

タイムスタンプが等しい場合、イベントの順序を明確にする必要があります。H=4 の更新が H=1 の決定より前に完了するか、処理遅延により後になって初めて利用可能になるかのいずれかです。実時間で等しいだけでは、データが使用可能であったとは言えません。また、最新の生データである H=4 ピボット更新と、必要な確定済みの高値と安値を含む完全な構造状態を区別する必要があります。

for each closed H1 bar t:
    h4 = latest_state(where available_at <= t, same_instrument=True)
    if h4 is None or h4.age > max_context_age: continue
    up = h4.H2 > h4.H1 + eps and h4.L2 > h4.L1 + eps
    near_support = abs(H1.low[t] - h4.last_low) <= zone_width
    if up and near_support: create_frozen_candidate(h4.anchor_ids, t)
    if candidate and H1.close[t] > candidate.micro_high + buffer:
        emit(signal_at=t, context_available_at=h4.available_at)
# Use only a micro_high confirmed before the trigger.

数値タイミングと有効なセットアップでも損失が発生する

安値を含む H=4 バーが 12:00 で終値となり、ピボットには 16:00 と 20:00 で終値の 2 つの右側バーが必要だとします。その安値は、13:00 での H=1 注文をサポートできません。この安値は、20:00 のデータが利用可能になった後にのみコンテキストに入ります。配信に 2 秒かかる場合、20:00:00 での決定は、依然として古い状態を使用する必要があります。

合成有効セットアップ: 既知の高値 H=4 が 110→116 に進み、安値 100→105 になります。提案されたサポート ゾーンは 104.7–105.3 です。H=1 は 105.1 に接触し、その後、既に確認されているマイクロ 高値 106 の上にある 106.2 で終値となります。106.3 でエントリーし、ストップ 104.7 を設定すると、1.6 ポイントのリスクが計画されます。 109.5における研究目標は、コスト控除前では2Rである。

失敗シナリオ：H=1のブレイクアウトが発生するものの、その後価格は104.7を下回って下落する。H=4の上昇トレンドは既知の履歴を記述したものであり、105が維持されることを保証するものではない。損失発生後にH=8に切り替えて、実際には弱気な状況だったと主張することは、その結果を観察した後にルールを変更することになる。

タイミングフィクスチャは、H=1 トリガーを、H=4 available_at タイムスタンプの前後数秒に移動させる必要があります。許可されたコンテキストは、宣言された境界でのみ変更する必要があります。H=4 バーが欠落している別のフィクスチャは、ギャップを記録せずに後で完了したバーに置き換えるのではなく、新しいピボットを未確認のままにしておく必要があります。

各スケールの役割とアンカーを固定する

完全な設定では、より大きなスケールにゾーン、より小さなスケールにトリガー、そして事前定義されたストップポリシーが割り当てられます。小規模なストップは、初期リスク距離を狭めることができますが、より大きな構造内の通常の動きに対して脆弱になる可能性があります。大規模なストップは、ポジションサイズと多くの場合保有期間を変更します。どちらも、取引ごとに事後的に選択すべきではありません。

候補を作成する際は、そのコンテキストアンカーID、価格、ゾーン幅、コンテキストの可用性、および作成時に既に確認済みの下位時間足のマイクロハイを保存します。新たに到着したコンテキストは、固定ルールに基づいて未成立の候補を無効にする可能性がありますが、以前のシグナルの理由を書き換えてはなりません。

擬似コードは構造の概略です。候補の有効化とトリガー評価には別の時刻を持たせます。厳密に後のバーを使う版では t>candidate.created_at とし、小さな高値は候補作成時刻までに確定している必要があります。作成バーが既にその高値を超えた場合の処理を定め、古い候補を棄却するか即時有効化する別版を登録します。

TTLは、経過取引時間またはH=1バーで設定します。非常に古いH=4状態は、最新の記録であるという理由だけで、新しい証拠とはみなされません。コンテキストの有効期限切れ、データの欠落、および真の弱気転換には、それぞれ別の理由コードを設定し、各ポリシーによる機会損失を測定できるようにします。

同じ出来高を重複して数えない

H=4 ボリュームには、その構成要素である H=1 バーの活動が含まれます。したがって、上昇する H=1 と H=4 ボリュームは、2 つの独立した観測値ではありません。スコアは満たされた条件をカウントできますが、任意の重み付けによってそのスコアが調整された勝率になるわけではありません。

より焦点を絞った特徴量は、H=4 構造を固定したまま、H=1 の押し戻し中の活動を同じ時間帯の H=1 基準と比較します。途中までの H=4 出来高を使うなら、開始から同じ分数だけ経過した過去の部分出来高と比べます。過去の完成した H=4 出来高と、開始直後の現在の H=4 バーは公平に比較できません。

入力スケジュールは計算式と同じくらい重要です。ボリュームの修正、バーの遅延、セッション定義の違いなどにより、同じ名目上のH=4期間でも、4つのローカルH=1バーとは異なる集計結果になる可能性があります。集計の出所を記録し、整合性チェックとして合計値を比較してから、確認事項を評価してください。

アブレーションでは、同じ候補セットと実行ルールを用いて、一度に1つのボリューム機能を追加する必要があります。複数のボリュームがプラスの状態であれば独立した確認が得られると仮定するのではなく、時間帯、ボラティリティ、流動性といった制御条件の下で改善が維持されるかどうかを検証してください。

より長い時間軸のコンテキストの増分価値を測定する

同じ H=1 検出器を、文脈フィルターなし、H=4 方向だけ、H=4 方向とゾーンへの近さ、の三条件で比較します。リスク、約定規則、検証期間を統一します。対象取引の部分集合を変えるだけでも勝率が上がるため、除外信号数、リスクへのエクスポージャー、純期待値を報告します。

H=4境界、予定されている閉鎖、夏時間変更、および欠落した観測値にわたってフィクスチャを実行します。データ受信順に再生し、バッチ時系列結合と比較します。バッチ処理が再生よりも早くH=4構造を検出した場合は、別のインジケータを追加する前に結合を修復します。

単一時間枠、複数スケールのベースラインも比較してみてください。同期がよりシンプルであるため、2つ目のバーカレンダーを必要とせずに、多くのメリットが得られる可能性があります。時間枠のペアと最大経過時間の設定を研究試験として登録し、最終テストの前に固定してください。

古いコンテキストによる失敗と、有効なコンテキストによる損失トレードは分けて報告してください。前者は同期または有効期限ポリシーの問題を示している可能性があり、後者は仮説の予測値に関係します。明確な分類を行うことで、あらゆる損失を別の尺度を選択することで説明してしまうことを防ぎます。

よくある落とし穴

この手法を使う前のチェックリスト

ご自身のデータで確認した項目にチェックを入れてください。進捗はこのブラウザに保存されますが、戦略の収益性を認定するものではありません。

• 各スケールに固定の役割を割り当てる。
• 未完了の上位時間枠の値を除外します。
• 上位足ピボットの右側確認窓がすべて確定するまで待つ。
• available_atを使用して逆方向に結合します。
• タイムスタンプが等しい場合の処理順序を定義します。
• 有効期限を超過したコンテキストを期限切れにします。
• 入れ子構造のボリュームは、独立した証拠としてカウントしないでください。
• 一括処理とデータ受信順の再生結果が一致することを確認する。

研究資料

各資料は、その横に記載された定義や根拠を支えています。擬似コード、架空の例、提案パラメータは別途検証が必要です。

1. Pine Script: TimeframesTradingView. 時間足の定義と単位を読みました。 確認日: 2026-10-11.
2. Other timeframes and dataTradingView. 確定済み上位足データを要求する例を読みました。 確認日: 2026-10-11.
3. pandas.merge_asofpandas. 後方一致、許容差、同時刻一致の動作を読みました。 確認日: 2026-10-11.

関連する手法