ポジション保護

はじめに

この SMA 戦略の変更版は、ローカル保護コントローラーを使用してオープンポジションを保護する仕組みを実装しています。このアプローチにより、柔軟なリスク管理と、特定の条件が満たされた場合のポジションの自動クローズが可能になります。

ポジション保護の主要コンポーネント

保護コントローラー

この戦略は、ポジション保護のために 2 つの主要なオブジェクトを使用します。

// 保護コントローラーの宣言
private readonly ProtectiveController _protectiveController = new();
private IProtectivePositionController _posController;

// このコードはメインの保護コントローラーを初期化し、
// 特定のポジションコントローラー用のプレースホルダーを作成します。
// ProtectiveController はすべてのポジションを管理し、
// IProtectivePositionController は特定のポジションを担当します。

_protectiveController: すべてのポジションの保護を管理するメインコントローラー。
_posController: 特定のポジション用のコントローラー。

保護の初期化

新しいポジションを開くとき、または既存のポジションを変更するときに、保護コントローラーが初期化されます。

// 新しいポジション用の保護コントローラーを初期化
this.WhenOwnTradeReceived()
	.Do(t =>
	{
		// ... (その他のコード)

		if (TakeValue.IsSet() || StopValue.IsSet())
		{
			_posController ??= _protectiveController.GetController(
				security.ToSecurityId(),
				portfolio.Name,
				new LocalProtectiveBehaviourFactory(security.PriceStep, security.Decimals),
				TakeValue, StopValue, true, default, default, true);
		}

		var info = _posController?.Update(t.Trade.Price, t.GetPosition());

		if (info is not null)
			ActiveProtection(info.Value);
	})
	.Apply(this);

// このコードは、新しい取引に関する情報を受信したときに、
// 新しいポジション用の保護コントローラーを作成して初期化します。
// また、コントローラー内のポジション情報を更新し、
// 必要に応じて保護を有効化します。

これにより、指定されたテイクプロフィットおよびストップロスのパラメーターを持つ、特定ポジション用のコントローラーが作成されます。

ポジション情報の更新

var info = _posController?.Update(t.Trade.Price, t.GetPosition());

if (info is not null)
	ActiveProtection(info.Value);

これにより、コントローラーはポジションの現在状態を追跡し、必要に応じて保護注文を調整できます。

保護の発動条件の確認

新しいデータを処理するメソッド (たとえば新しいローソク足を受信したとき) で、保護注文を発動する条件を確認します。

// ProcessCandle メソッドで保護発動条件を確認
var info = _posController?.TryActivate(candle.ClosePrice, CurrentTime);

if (info is not null)
	ActiveProtection(info.Value);

// このコードは、現在価格 (この場合はローソク足の終値) と時刻に基づいて、
// 保護注文を発動する必要があるかどうかを確認します。
// 条件が満たされた場合、ActiveProtection メソッドが呼び出されます。

ここでは、ローソク足の終値を現在価格として使用していますが、最後の取引価格や板情報の現在スプレッドなど、任意の関連価格値を使用できます。

保護注文の発動

保護注文を発動する条件が満たされると、対応するロジックが実行されます。

// 保護注文を発動するメソッド
private void ActiveProtection((bool isTake, Sides side, decimal price, decimal volume, OrderCondition condition) info)
{
	// 保護用 (ポジション決済用) 注文を通常注文として送信
	RegisterOrder(this.CreateOrder(info.side, info.price, info.volume));
}

// このメソッドは、保護コントローラーから受け取った情報に基づいて、
// ポジションをクローズする注文を作成して登録します。

このメソッドは、保護コントローラーから返されたパラメーターに従って、ポジションをクローズする注文を作成して登録します。

サーバー側ストップ注文との比較

サーバー側ストップ注文の利点

ストップ注文 (ストップロスとテイクプロフィット) はブローカーへ直接送信されます。
ブローカーはストップ条件の達成を独立して監視します。
ストップが発動すると、ブローカーは自動的に成行注文または指値注文を発注します。

ローカルアプローチの利点

柔軟性: 標準的なサーバー側ストップでは利用できない複雑な保護ロジックを実装できます。
機密性: ストップ水準に関する情報がブローカーへ送信されないため、市場によっては重要になる場合があります。
反応速度: 市況の変化に対して、より速く反応できる可能性があります。
適応性: 市場データや戦略ロジックに基づいて保護水準を動的に調整できます。
ブローカー/取引所実装からの独立性: 必要な種類の保護注文をブローカーまたは取引所がすべてサポートしているかどうかに関係なく、ローカルアプローチは同じように動作します。
履歴データでのテスト: ポジション保護を備えた戦略を履歴データで完全にテストできます。これはサーバー側ストップでは不可能です。

ローカルアプローチの欠点

取引ターミナル機能への依存: ターミナルが切断されると、保護は機能しません。
システム負荷: クライアント側で継続的な計算が必要です。
遅延: 保護条件が発動した後、注文を発注するまでに遅延が発生する可能性があります。

サーバー側ストップ注文の欠点

ブローカー/取引所実装への依存: すべてのブローカーまたは取引所がすべての種類の保護注文をサポートしているわけではないため、戦略機能が制限される可能性があります。
履歴データで完全にテストできないこと: サーバー側ストップは履歴データでのテスト時に正確にモデル化できないため、戦略の実際の有効性を評価することが難しくなります。
柔軟性の制限: 通常は基本的な種類のストップ注文のみが利用可能であり、複雑な保護メカニズムの実装可能性が制限されます。

まとめ

SMA 戦略でローカル保護コントローラーを使用すると、オープンポジションのリスクを効果的に管理できます。このアプローチは、保護パラメーター設定の柔軟性と、市況変化への迅速な反応を提供します。これは取引を成功させるうえで極めて重要です。