Pine Scriptストラテジーの注文・決済設計｜指値・逆指値・分割決済
条件が成立したバー、注文が作成された時点、ブローカーエミュレーターが約定した時点、建玉が閉じた時点は同じとは限りません。さらに複数のstrategy.exit()は、コードの記述順に建玉数量を予約します。本記事は「どこで利確・損切りすべきか」ではなく、Pine Script v6の注文を状態遷移モデルとして読み、想定外の反転・部分決済・未決済の残数量を取引一覧まで追跡する方法を扱います。
この記事が役立つ方： Pineストラテジーの注文が想定外のバーや数量で約定する人／利確・損切り注文・部分決済・同方向の追加建玉を監査したい人
まず押さえる重要ポイント
- 売買条件の成立、注文作成、未約定、約定、取消、建玉更新を別イベントとして記録する。
strategy.entry()は反対建玉を既定で反転できる一方、strategy.order()は同方向の追加建玉など一部プロパティを無視する。- エントリー／注文で指値と逆指値を同時指定するとストップリミット注文、
strategy.exit()で同時指定するとTPとSLの利確・損切り注文になる。 - 複数の
strategy.exit()は先行する呼び出しから順に決済数量を予約し、後続の呼び出しの有効数量が縮小されることがある。 - チャートの注文マーカーだけでなく、ID、数量、作成バー、約定バー、取引一覧を一続きで照合する。
シグナルは注文ではなく、注文は約定ではない
- 01条件成立コードが注文関数を呼ぶ
- 02作成済みID・方向・価格・数量を持つ注文
- 03未約定指値／逆指値条件を待つ
- 04約定済み建玉または損益を更新
- 05取消済み明示的な取消またはOCAで失効
- 成行：作成済み → 次に利用可能なティック → 約定済み
- 価格指定注文：作成済み → 未約定 → 発動・約定または取消
- 利確・損切り注文：一方が約定 → 同系列の注文は縮小または取消
結論：注文を「関数名」ではなく状態遷移で読む
Pineの注文トラブルは、コード上の関数呼び出しを建玉更新と同じ出来事だと扱うと起きやすくなります。本記事は作成済み・未約定・約定済み・取消済みという論理状態と数量の所有関係を追います。「なぜそのバー・価格で約定したか」というブローカーエミュレーターの経路監査はTV12へ移し、決済予約の修正と混ぜません。
- 条件を記録する
どのバーで、どの確定値を使って条件が成立したか。
- 注文作成を記録する
関数、ID、方向、注文数量、指値、逆指値、from_entryを控える。
- 未約定を追う
価格注文が有効か、変更・再発行・取消されたかを確認する。
- 約定済みを記録する
状態が約定済みへ進んだことと有効数量を記録し、バー・価格の原因分析はTV12へ渡す。
- 建玉更新を確認する
反転、追加、部分決済、残数量、OCA取消を取引一覧と照合する。
成行・指値・逆指値・ストップリミットの発動条件を分ける
| タイプ | 作成時の指定 | 待つ条件 | よくある誤読 |
|---|---|---|---|
| 成行 | 指値／逆指値なし | 次の利用可能ティック | 条件成立バーの確定時に必ず約定すると思う |
| 指値 | 指値価格 | 指定価格または有利側 | 現在価格より不利／有利の方向を取り違える |
| 逆指値 | 逆指値価格 | 指定価格または不利側で発動 | 損切り専用と考える。エントリーにも使える |
| ストップリミット | エントリー／注文で逆指値と指値 | 逆指値で指値を有効化後、指値注文の約定を待つ | 逆指値到達だけで建玉が開くと思う |
| 決済の利確・損切り注文 | 決済で指値と逆指値 | TPまたはSLのうち先に発動した側 | ストップリミットと同じ1注文だと思う |
買いと売りでは有利・不利方向が反転します。公式例と小さな数量で確認してください。
strategy.entry()やstrategy.order()へ逆指値と指値の両方を渡すと、逆指値が指値注文を有効化する一つのストップリミット注文です。一方、strategy.exit()へ両方を渡すと、指値側の利確と逆指値側の逆指値による損切りという二つの決済注文を作ります。この差はコードレビュー表へ明記する価値があります。
エントリー・注文・価格指定決済・成行決済を交換可能な関数として扱わない
| コマンド | 主な役割 | 建玉との関係 | 監査ポイント |
|---|---|---|---|
| strategy.entry() | エントリーと既定反転 | 同方向の追加は追加建玉数の上限設定に従う | 反対建玉を閉じる数量が約定数量へ加算され得る |
| strategy.order() | 方向付きの基本注文 | 差引建玉を増減し、一部設定項目を無視 | 同方向の追加建玉を安全弁と思わない |
| strategy.exit() | エントリーに結び付く価格ベース決済 | 利確・損切り注文・部分決済・追従型 | from_entry、予約数量、OCAを確認 |
| strategy.close() | エントリーIDに対応する成行決済 | 次の利用可能ティックで約定 | FIFO／ANYとIDの期待を照合 |
| strategy.cancel() | 未約定注文の取消 | 保有中の建玉は閉じない | 毎バー再発行していないか確認 |
関数の詳細は現行TradingView公式ドキュメントを優先してください。
設定項目の「同方向の追加建玉」は、strategy.entry()が同方向に保持できるエントリー数の上限です。既定値は1ですが、同じティックに複数の価格注文が作られて発動する場合など、単純な「一バーに一つ」の安全弁とは限りません。またstrategy.order()は同方向の追加建玉設定を無視するため、混在させるならIDと差引建玉の変化を別に追います。
部分決済は「合計数量」だけでなく予約順序を確認する
複数のstrategy.exit()を同じエントリーへ向けると、各呼び出しはコードの実行順に建玉の一部を予約します。後続の呼び出しが指定した注文数量が残数量より大きければ、作成される決済数量は縮小されます。先に19を予約し、次に20を指定しても、元建玉が20なら後続の呼び出しが利用できるのは1だけです。
実効決済数量1 ＝ min（要求数量1、保有数量）残数量1 ＝ 保有数量 − 実効決済数量1実効決済数量2 ＝ min（要求数量2、残数量1）未予約数量 ＝ max（保有数量 − 実効決済数量の合計、0）負値は0として扱う概念モデルです。実際の注文変更、約定、取消、エントリー追加では再評価が必要です。同一のstrategy.exit()が作るTPとSLは、片方が約定するともう片方が取消される利確・損切り注文として働きます。複数の決済関数が作る注文は既定でstrategy.oca.reduceグループに入り、他注文の約定に応じて数量が減る場合があります。エントリー側のOCAの取消／縮小／未指定とは、グループ名と目的をコードコメントに残してください。
二段階利確・損切り注文を数量の保存則として実装する
以下は4単位の買いエントリーを2単位ずつ二つの利確・損切り注文へ割り当てる教育例です。エントリー条件は説明用であり、将来成績を示しません。各決済関数の呼び出しが2単位を予約し、合計がエントリー数量を超えない構造にしています。
//@version=6
strategy("Two-bracket reservation audit", overlay = true, pyramiding = 1,
initial_capital = 100000, margin_long = 100, margin_short = 100)
int fastLength = input.int(20, "Fast length", minval = 1)
int slowLength = input.int(50, "Slow length", minval = 2)
float fast = ta.sma(close, fastLength)
float slow = ta.sma(close, slowLength)
bool enterLong = ta.crossover(fast, slow) and strategy.position_size == 0
if enterLong
strategy.entry("Long", strategy.long, qty = 4)
if strategy.position_size > 0
float average = strategy.position_avg_price
float stopPrice = average * 0.98
float targetOne = average * 1.02
float targetTwo = average * 1.04
strategy.exit("Bracket 1", from_entry = "Long", qty = 2,
limit = targetOne, stop = stopPrice)
strategy.exit("Bracket 2", from_entry = "Long", qty = 2,
limit = targetTwo, stop = stopPrice)
plot(fast, "Fast", color.aqua)
plot(slow, "Slow", color.orange)
plot(strategy.position_size, "Position size", display = display.data_window)各利確・損切り注文はTPとSLを作り、それぞれ2単位を予約します。価格ギャップ・スリッページ・バー内経路は単純化できません。
監査用には、各注文ID、作成バー、指値／逆指値価格、要求注文数量、有効予約注文数量、約定バー、決済IDを表へ記録します。注文数量を3と3へ変えた場合、後続の呼び出しがどのように縮小されるかをミニ計算機で先に確認できます。
チャート・データウィンドウ・取引一覧を三点照合する
- 注文作成を可視化する
ラベルやプロットで条件成立バー、指値、逆指値、エントリーIDを表示します。
- 状態変数を確認する
strategy.position_size、strategy.opentrades、strategy.closedtrades、strategy.position_avg_priceをデータウィンドウで追います。 - 取引一覧へ移る
エントリーID／決済ID、時刻、価格、数量を取引一覧で照合します。
- 想定外を分類する
作成遅延、未約定、反転、予約縮小、OCA取消、FIFOのどれかへ分けます。
- 約定経路をTV12へ渡す
状態と数量が整合してなおバー・価格が違う場合だけ、同じ版IDでブローカーエミュレーター監査へ進みます。
| 症状 | 最初の確認 | 次の確認 |
|---|---|---|
| 後続逆指値数量が小さい | 先行決済の予約数量 | OCAによる縮小と未予約残 |
| 利確・損切り注文要求合計が建玉を超える | 呼び出し順と要求注文数量 | 各呼び出しの有効予約注文数量 |
| 取消した注文が戻る | 毎バーの再発行条件 | IDとstrategy.cancel()の順序 |
| 反転マーカーが大きい | 既存建玉数量 | 約定数量と新規建玉数量の差 |
| 指定IDと違う取引が先に閉じる | FIFO設定 | close_entries_rule |
原因を一つずつ切り分け、複数設定を同時に変更しないことが再現性につながります。
一注文一行の状態台帳で修正前後を分ける
- エントリー／注文／価格指定決済／成行決済の役割をコメントで区別したか
- すべての注文IDと
from_entryが実在し、一意な意図を持つか - 利確・損切り注文ごとの予約数量合計がエントリー数量と整合するか
- 同方向の追加建玉、FIFO／ANY、OCA、再計算設定を記録したか
- 指値／逆指値到達と約定を同義にしていないか
- 修正前後を同じ期間・銘柄・時間足・コストで再出力したか
注文デバッグの出口は、事象ごとに一行を持つ注文状態台帳です。版ID、バー番号、注文コマンド、注文ID、from_entry、状態、要求注文数量、有効予約注文数量、建玉の変更前／変更後、OCA動作を記録し、修正前後を別版として保存します。
台帳の合格条件は、各エントリー数量が予約済み・未予約・約定済み・取消済みのいずれかへ重複なく保存され、最終建玉数量と一致することです。バー・約定価格の説明列はTV12の監査記録へ外部キーで接続し、同じ表へ無理に詰め込みません。
複数の決済関数による予約数量
コードの記述順に3つの決済要求を適用し、後続注文が残数量へ縮小される概念を確認します。
逐次計算：r1＝min（b, a）、r2＝min（c, max（a−r1, 0））、r3＝min（d, max（a−r1−r2, 0））。合計＝r1＋r2＋r3、未予約＝max（a−合計, 0）。約定・取消・再発行は含まない概念モデルです。
よくある質問
strategy.exit()で指値と逆指値を指定するとストップリミット注文になりますか？
なりません。決済では利確の指値注文と損切りの逆指値注文という利確・損切り注文を作ります。エントリー／注文で両方を指定した場合はストップリミット注文です。
後に書いた逆指値が全建玉を閉じないのはなぜですか？
前のstrategy.exit()の呼び出しが建玉数量の一部を予約している可能性があります。後続の呼び出しは未予約の残数量しか利用できず、有効注文数量が自動縮小されることがあります。
同方向の追加建玉=1なら同方向注文は必ず一つだけですか？
単純にそうとは限りません。同方向の追加建玉は主にstrategy.entry()の同方向エントリー取引へ作用します。strategy.order()や同一ティックで発動する複数価格注文など、別の動作も公式仕様で確認してください。
strategy.cancel()は保有中の建玉も閉じますか？
閉じません。strategy.cancel()は指定IDの未約定注文を取り消す注文コマンドです。保有建玉を閉じる処理はstrategy.close()、strategy.close_all()、または適切な決済注文と区別します。
根拠資料と確認先
- TradingView Pine Script — Strategies注文タイプ、エントリー・注文・決済、部分決済、予約、OCA、追加建玉の公式解説。
- TradingView Pine Script — Strategies FAQ利確・損切り注文、複数利確、トレーリングストップ、注文デバッグの公式FAQ。
- TradingView Pine Script — Execution model履歴バー・リアルタイムバーの実行とロールバックの公式仕様。
- TradingView Help — Strategy properties注文約定・再計算・追加建玉などと設定項目の対応。
編集・発行: SG Group · 編集方針: TradingView公式ヘルプとPine Script公式文書を優先し、金融市場・商品に関する説明は取引所、監督当局、一次資料で補完しています。機能、データ、料金、接続条件は変わるため、実際の利用前に公式画面とリンク先の最新情報を確認してください。
重要事項: 本記事はTradingViewの画面、チャート、アラート、スクリーナー、ペーパートレード、Pine Script等の一般的な学習情報です。投資助言、売買シグナル、特定商品・データ提供者・ブローカーの推奨、将来価格や利益の保証ではありません。機能、料金、データ、取引所区分、通知、注文連携、Pine Scriptの仕様はプラン・地域・接続先・時点で異なり変更されることがあります。実際の資金を使う前に、TradingView公式資料、データ提供元、接続先事業者の最新条件を確認し、架空データまたはペーパートレードで手順を検証してください。