スキャルピング・リスクはどの入力を使う？
直接の答え
「スキャルピング・リスク」（という概念）は、単一の普遍的なインジケーターではありません。これは、短い保有時間を使うときに、どれくらいの損失が起こり得るかを見積もるための入力群を用いるリスク・フレームワークです。あなたが使う入力によって、検証できること、前提としていること、そしてそのフレームワークがどこで破綻し得るかが決まります。
仕組みと定義
入力を説明する実用的な方法は、安定したメカニクスと変動する条件に分けることです。
安定したメカニクス（フレームワークの入力）
- リスク目標（ルール）： 定義された単位（たとえば、1回の取引ごと、1セッションごと、または1日ごと）に対して受け入れる最大損失。これにより「リスク」を測定可能な上限に変換します。
- ポジションサイジング手法： リスク上限から取引サイズへの対応付け。ここでの入力には、口座通貨に対して、価格変動がどれくらいの値になるかの想定が含まれます（たとえば、口座のどれだけの単位が1 pipあたりで変化するか）。
- 時間枠と保有の前提： 意図しているスキャルピングの時間軸（短期の取引をどれくらいの長さで保有する想定か）。これは、リスクが執行タイミングにどれほど敏感かに影響します。
- イベント定義： リスク計測の開始と終了が何を意味するか（エントリーの瞬間、エグジットの瞬間、そして計測が注文約定時点で止まるのか、より後の価格で止まるのか）。
変動する条件（市場および実装の入力）
- 取引コスト： スプレッド、手数料、その他の1取引あたりのコスト。
- 執行の質： スリッページ（期待した約定と実際の約定の差）、部分約定、注文処理の遅延。
- 流動性とボラティリティのレジーム： 価格がどれくらいの速さで動くか、そして意図した時間枠の中で注文がどれほど確実に約定するか。
- 取引環境と制約： プラットフォームの挙動、許可されている注文タイプ、そしてより広いスプレッドや薄い流動性の期間に取引するかどうか。
どう機能するか（概念的に）
これらの入力を使って、スキャルピング・リスクのフレームワークは、リスク目標に対する想定される最悪ケースまたは参照損失を計算し、その計算された損失が上限の範囲に収まるかを確認します。ポイントは、フレームワークが検証できるのは、入力が正確に書き下されている場合のみだということです（コストや執行の前提を含めて）。
証拠または例（明示的な前提つき）
リスク・フレームワークが、損失を1回の取引ごとに上限を設けるように定義されている、一般的な例を考えます。
前提：
- リスク上限：1回の取引で失ってよいと考える固定の口座金額。
- ポジションサイジング：想定する価格変動距離から計算される（たとえば、ストップ距離、または参照損失距離に基づく）。
- コスト：損失計算から差し引く、または損失計算に含めるための、取引あたりの想定総コスト。
- 執行：想定するスリッページ量（最初の「理想化した」チェックではゼロの可能性もあります）。
重要な依存関係：
- 実際のスプレッド + 手数料 + スリッページが、想定したコストより高い場合、実現した損失はリスク上限を超える可能性があります。
- 約定が想定より後になると、有効な価格変動が変わり、ストップ距離から実現損失への対応付けが再び破綻します。
これは予測ではありません。入力が、リスクの数式をどう制御するかを示すデモンストレーションです。
制限とリスク（重大な失敗パターン）
- 前提の不一致： ほとんどの失敗は、理想化された入力（たとえば低いスリッページや安定したコスト）を使うことから生じますが、実際の条件はそれより悪いことが多いです。
- コストへの感度： スキャルピングは短い時間枠を使うため、取引コストや執行遅延が結果を支配しやすくなります。
- レジームの変化： ボラティリティ、スプレッド、スリッページの過去の関係は、将来の挙動を保証しません。
- 定義の曖昧さ： フレームワークが「リスク計測の開始/終了」が何を意味するのか（注文の送信 vs. 約定）を定義していない場合、比較は信頼できなくなります。
検証または次の質問
スキャルピング・リスクのセットアップが首尾一貫しているかを独立に検証するには、各入力を文書化し、整合性をテストしてください：
- 同じリスク目標とポジションサイジング手法を維持する。
- 暗黙にせず、明示的なコスト前提（スリッページを含む）を使う。
- エントリー/エグジットの定義と、計測境界の定義を同じものとして検証する。
役に立つ次の質問は次のとおりです：あなたの定義に埋め込まれている執行の前提（スリッページ、遅延、コスト合計）は何で、それらの前提を意図的により保守的にした場合、リスクはどう変わるでしょうか？
DOCUMENT END