ローソク足の反転はいつ失敗する？
直接の答え
ローソク足の反転は、ローソク足パターンに含まれる視覚的な「転換（turning）」の情報が、周囲の市場レジームによって圧倒される場合、取引上の摩擦（スプレッド、手数料、スリッページ）によって損なわれる場合、または実行・解釈の問題（エントリーのタイミング、ローソク足の定義の違い、確認ルール）によって崩れる場合に失敗し得ます。ローソク足パターンは記述的な合図であって保証された予測ではないため、失敗とは、価格が元の方向にそのまま進む、あるいはコストと不確実性を埋めるほど動かないことを意味します。
仕組みと定義
ローソク足の反転とは、1本以上のローソク足を使って、買い圧と売り圧が変化していることを示し、方向転換の可能性を示唆することです。機械的には、この手法は次のような入力に依存します：
- ローソク足を作るために使う時間足（タイムフレーム）、
- ローソク足の形状を計算するために用いる、始値・高値・安値・終値の値、
- 「反転」を特定するためのルール（たとえば、特定の実体／ヒゲの幾何学的形状）と、確認のためのルール。
安定した仕組み：ローソク足の幾何学的形状は、定義された期間におけるそれらのOHLC値によって決まります。変動要因：その幾何学的形状が、需給の本当の変化を反映しているかどうかは、文脈（トレンドの強さ、ボラティリティ、流動性）に左右されます。そして、そのローソク足がクローズした後に市場がフォロー（追随）するかどうかにも依存します。
いつ失敗するか：レジームの感度、コスト、実行
-
レジームが反転の期待と一致しない 反転の合図は、市場が強い方向性の局面にあるときほど失敗しやすくなります。たとえば、一定のオーダーフローを伴う持続的なトレンドのような状況です。その場合、「逆方向」のローソク足が現れても、市場は行ったり来たり（オシレーション）を続け、その後に支配的な方向へ再開することがあります。言い換えれば、同じローソク足の形状でも、より広い条件が継続を後押しするのか、転換を後押しするのかで意味が変わり得ます。
-
コストと摩擦が支配し得る 反転が始まったとしても、結果は取引コストを差し引いた後のネットリターンに依存します。スプレッドや手数料は実質的な価格改善を減らし、信号となるローソク足の周辺で価格が素早く動くとスリッページによって約定が悪化します。期待される値動きがコストに比べて小さい場合、パターンが早いインパルスを生んだとしても、実務上は失敗のように見えることがあります。
-
実行のタイミングと確認ルールがテストと異なることがある ローソク足パターンは、ローソク足がクローズした後に特定されることがよくあります。実際の実行では、エントリーが異なる形で置かれる（たとえば、終値で入るのか、次のバーで入るのか）と、結果は大きく変わり得ます。同様に、バックテストが理想的な価格での約定を前提としていても、ライブ取引では現実的なビッド／アスク価格とレイテンシを使うため、反転確率が見かけ上縮小する可能性があります。
-
ローソク足の構築と解釈による曖昧さ ローソク足の「反転」は、ローソク足がどのように作られ、どう解釈されるかに敏感です。時間足の選択、市場セッション、データソースによってOHLC値が変わり、その結果としてローソク足の形状も変わります。さらに、「近い（near）」や「十分に大きい（large enough）」とみなす基準は、形式化されていない限り主観になりがちです。
限界とリスク：検証できる前提つき
過去の関係は将来の結果を保証しません。概念を独立して検証可能にする有用な方法は、たとえば次のように前提を明確に述べることです：時間足、ローソク足の厳密な定義、確認が必要かどうか、そしてテストが推定スリッページを伴うビッド／アスクでの実行を使っているかどうか。
重要な限界として、ローソク足の反転の特定は楽観的な選択効果を生み得ます。つまり、視覚的に定義された条件が起きた瞬間をまず選び、その後、市場レジームを十分にコントロールせずにパフォーマンスを判断してしまうのです。もう一つのリスクは、確認ルールを過去データに過剰適合させることです。パターン定義を少し変えるだけで、観測された結果が大きく振れることがあります。
検証のためには、アウト・オブ・サンプル期間でテストし、保守的な実行前提（現実的なスプレッドとスリッページ見積もり）で行ってください。また、異なるボラティリティのレジーム間で結果を比較し、パターンの挙動が市場状況の変化に応じて変わるかどうかを確認してください。
次に尋ねるべき質問
あなたの文脈で「いつ失敗するのか」を理解するには、次を問いかけてください：暗黙に置いているレジームの前提は何か（トレンドの強さとボラティリティ）、現実的なコストと約定（fill）の前提は何か、そしてパターン定義はデータ、バックテスト、ライブ実行の間で完全に一致しているのか？
DOCUMENT END