Pine Script v6入門：TradingViewでカスタムインジケーターとアラートを作る

indicator・strategy・libraryの役割を先に決める

indicatorはseriesを計算してchartへplotやdrawingを表示するscriptです。strategyは`strategy()`宣言と`strategy.*`機能を使い、historical/realtime bars上で仮想orderをsimu­lateします。libraryは他scriptからimportする再利用関数等を公開します。最初の学習では、注文や成績を扱わず、一つの数値を表示するindicatorが挙動を追いやすい入口です。

「買いsignalを作る」から始めると、表示の美しさと収益性を混同しやすくなります。本稿のsampleは、終値と単純移動平均の距離をpercentで表示し、距離が0を上抜いた確定barへ印を付けるだけです。これはmarket stateの可視化例で、entry、exit、stop、quantity、適合性を決めません。indicatorの動作確認後にstrategyへ変える場合は、order timing、commission、slippage、bar assumptionsを新しい仕様として設計します。

script typeを変えると実行・検証要件も変わります。単なる名前変更ではありません。

Pineはbarごとに実行され、realtime barでは繰り返し計算される

scriptをchartへ追加すると、利用可能なdatasetの古いbarから新しいbarへ順に実行されます。`close`、`high`等のbuilt-in seriesは現在実行中のbarの値を持ち、`close[1]`は一つ前のbarを参照します。historical barでは確定値を使って原則一回ずつ計算されます。open realtime barでは新しいupdateが来るたびに値が変わり、indicatorは繰り返し実行されます。

realtime update前には、そのbar上の一時的な計算状態を直前の確定状態へ戻すrollbackが起きます。open bar中に一度trueになった条件がclose時にはfalseになり、印が消えることがあります。reload後、以前のrealtime barはhistorical barとして最終値だけで再計算されるため、途中のtickを使った表示は再現されない場合があります。これがrepaintingの一つの経路です。

状態を保持する変数もrealtime再現性に関係します。`var`は通常、最初の初期化後にbarをまたいで値を保持し、`varip`はopen realtime bar内のupdate間でも値を保持できるため、historical barだけでは同じtick列を再生できない設計になり得ます。counterや配列へ値を追加する場合は、初期化条件、reset条件、最大要素数、`barstate.isnew`と`barstate.isconfirmed`の使い分けをREADMEへ明記します。確認時は一時的なplot、Data Window、Pine Logs等で「いつ値が増え、いつ戻り、いつ確定したか」を記録し、debug表示を外す前後で結果が変わらないことをtestします。`varip`を高速化のためだけに選ばず、同じ挙動を通常seriesで説明できる最小sampleを先に作ると、reload差とlogic errorを切り分けやすくなります。

中立的なdistance indicatorを一行ずつ読む

先頭の`//@version=6`はlanguage version、`indicator()`はscriptの名称と表示場所を宣言します。`input.int()`は利用者が変更できるlengthを作り、minimumを2に制限します。`ta.sma()`はbarごとにbaselineを計算し、`distancePct`は終値がbaselineから何%離れているかを表します。baselineが0の異常条件では`na`を返し、0除算を避けます。

//@version=6
indicator("Confirmed MA Distance — learning example", overlay = false)

int lengthInput = input.int(20, "Baseline length", minval = 2)
float baseline = ta.sma(close, lengthInput)
float distancePct = baseline == 0.0 ? na : (close / baseline - 1.0) * 100.0

bool crossedAbove = ta.crossover(distancePct, 0.0)
bool confirmedCross = barstate.isconfirmed and crossedAbove

plot(distancePct, "Distance from baseline (%)", color = color.teal, linewidth = 2)
hline(0.0, "Baseline", color = color.gray)
plotshape(confirmedCross, title = "Confirmed cross", style = shape.circle,
     location = location.bottom, color = color.orange, size = size.tiny)

alertcondition(confirmedCross, "Confirmed cross above baseline",
     "Confirmed MA-distance cross on {{exchange}}:{{ticker}} at {{close}}")

`ta.crossover()`は毎bar評価し、その結果と`barstate.isconfirmed`を別に組み合わせます。time-series functionを条件branch内だけで呼ぶと、barごとの履歴が不整合になる可能性があるため、計算を先に行う形はcode reviewもしやすくなります。`plot()`はdistance、`hline()`は0、`plotshape()`は確定crossを表示します。`alertcondition()`はalertを作成できるeventを宣言しますが、codeを追加しただけで通知が自動作成されるわけではありません。

input変更とchart変更を別test caseにする

inputを変更するとscriptは新しい設定でdatasetを再計算します。length 2、20、200は同じindicator名でもwarm-up、滑らかさ、cross回数が違います。結果を見て最良に見えるlengthを選び、その期間だけを成功例にすると過学習になります。学習testではdefault、minimum、典型値、極端値を事前に決め、`na`、scale、最初の有効bar、計算時間を確認します。

parameterの優劣ではなく、同じ仕様が説明どおり動くかを確認する表です。

timeframeやsymbolを変えると、scriptが読むbar列そのものが変わります。`request.security()`で別contextを取得する場合は、gaps、lookahead、higher/lower timeframe、confirmed valueを追加設計します。本稿sampleはchart contextだけを使い、multi-timeframe処理を隠しません。高度なdata requestを追加する前に、versionlessの現行Pine manualで推奨patternとlimitationを確認してください。

alertconditionと実際のalert instanceを分ける

`alertcondition()`はindicator利用者がCreate Alert dialogで選べるconditionを定義します。通知を動かすには、chart上でscript、symbol、timeframe、input、condition、frequency、message、expiration、delivery methodを選び、alert instanceを作成します。TradingViewは作成時のscriptとinput等をserver側で動かすsnapshotとして扱うため、chartのinputやcodeを後から変更しても既存instanceが自動的に同じ状態へ更新されると思い込まないでください。

sampleは`barstate.isconfirmed`とcrossを組み合わせ、open bar中の一時crossではなくclose時の条件を対象にします。それでもdata provider revision、session、timeframe、script reload、requested data等の差が消えるわけではありません。alert frequencyもOnce Per Bar Close等の現在の選択肢とconditionを整合させ、TradingViewアラートガイドの台帳へalert IDを保存します。

historical・open realtime・confirmed・reloadを四列で比較する

TradingViewはrepaintingをhistorical計算とrealtime計算・表示が異なる広い現象として説明しています。open barのRSIやMAが更新されるのは一般的な挙動ですが、未来dataを過去へ漏らすlookahead、過去位置へplotするoffset、unconfirmed higher-timeframe value、non-standard chartでのstrategy、intrabar依存等はmisleadingな結果を作り得ます。「repaintする／しない」の一語ではなく、何がいつ変わるかを記述します。

1. 01Historicalを保存

   reload直後の確定bar、cross、値をtimestamp付きで記録する。

2. 02Open barを観測

   update中のdistanceと一時crossを別列へ記録する。

3. 03Closeを確認

   bar確定後にalert conditionとshapeが残るか照合する。

4. 04Reloadする

   同じbarがhistoricalになった後、表示と時刻を再比較する。

5. 05Contextを変える

   input、timeframe、sessionを一つずつ変更し、差の原因を分離する。

SG Group無料TradingViewインジケーターを使う場合も、説明、input、source、confirmed/realtime挙動を同じchecklistで確認します。indicatorの見た目が整っていることは品質保証ではありません。公開scriptを利用する場合はauthor説明、open/closed source、更新履歴、権限、alert behaviorを確認します。

code・input・限界・alert再作成を一つの仕様書にする

scriptを自分用に保存または共有する前に、目的、計算式、input、単位、symbol/timeframeの想定、na処理、realtime behavior、repainting可能性、alert condition、変更履歴をREADMEへまとめます。「高精度」「勝てる」等の主張ではなく、何を計算し、何を計算しないかを書きます。第三者codeやlicenseを尊重し、理解せずにcopyしたlogicを自作として公開しません。

• Pine version、script version、最終review日を保存する。
• chart screenshotだけでなく、inputと完全symbol IDを添える。
• alert instanceを作り直す条件と、旧instanceを停止する手順を書く。
• known limitation、repainting behavior、data dependencyを利用者向けに説明する。
• strategy化した場合はcommission、slippage、order timing、datasetを新しい検証契約にする。

strategyへ発展させた後の結果は、既存のTradingViewバックテスト完全ガイドでdata quality、cost、trade list、robustness、out-of-sampleの順に確認し、Backtest & Robustness Labへexport dataを読み込めます。本稿はstrategy performanceを再説明せず、indicatorとalertが説明どおり実行されるところまでを責任範囲にします。