TradingViewアラート設定：条件・頻度・通知を検証する手順

アラートは監視条件を再現可能な仕様へ変換する

TradingViewアラートは、価格、drawing、indicator、strategyまたはPine Script等の条件を監視し、設定した頻度と通知先へ知らせる機能です。実務では「通知が来たら取引する」のではなく、「証拠を更新する条件を満たしたので、symbol、bar、source、前提を再確認する」と定義します。注文可否、損失許容、商品適合性、約定価格は別工程です。

作成前に一文で「完全symbol XYZの1時間足closeが102.50を下から上へcrossし、そのbarが確定した時、一度通知する」のように書きます。その文をsource、operand、operator、threshold、interval、bar state、frequencyへ分解して画面と照合します。条件や利用可能な通知先はplan、端末、権限、時点で変わるため、現在の公式ヘルプと設定画面を優先します。

価格・drawing・indicator・Pine条件の出所を区別する

価格アラートではlast等のseriesと固定値、drawing alertではline等のobject、indicator alertではplotまたはcondition、Pineではalertcondition()やalert()等のscript logicが関係します。同じ「cross」という表示でも、sourceと更新時点が違えば結果は一致しません。alert作成画面で完全symbol、exchange/provider、condition名、intervalを読み、台帳へ転記します。

利用可能なsourceと選択肢は現在のTradingView仕様を確認します。

indicatorやscriptを更新した後、既存alertが新しい入力へ自動追随すると想定しません。作成時の条件snapshotを台帳へ残し、現在の公式仕様に従って再作成が必要か確認します。リペイントや確定足の確認はindicator設定チェックリストと組み合わせます。

「上にある状態」と「下から上へcrossしたevent」を分ける

A > Bは現在の状態、AがBをcrossing upは直前にA≤Bで現在A>Bとなったeventです。価格がthresholdの上に数bar留まる場合、状態条件は評価のたびに真、cross eventは境界通過時だけ真になる設計が一般的です。ただし画面のcondition名、script logic、frequencyとの組合せで通知数は変わります。日本語ラベルだけでなく数式へ書き換えます。

cross条件では、前bar値、現在bar値、equalの扱い、tick内更新、bar確定を確認します。indicator同士のcrossなら両方のinputsとtimeframeを保存します。drawingを移動した場合はthresholdが変わり得るため、作成時のanchorを画像へ残します。複数条件をAND/ORで組み合わせる場合は、括弧を付けた論理式と各部分の真偽を別々にテストします。

bar内評価と通知頻度を別々に決める

進行中barでは価格とindicatorが何度も変わります。once、once per bar、once per bar close等の選択は、conditionが評価される時点と通知を抑制する規則へ関係します。bar closeを選べばintrabar変動の一部を避けられますが、すべてのdata revisionやhigher-timeframe挙動を解決するわけではありません。目的が早い気付きか、確定値の記録かを先に決めます。

具体的な名称と挙動はalert typeと現在の公式説明で確認します。

期限、timezone、取引sessionも頻度と同じ台帳へ入れます。週末や休場中に期限切れとなる場合、通知がなかったことはconditionが偽だった証明ではありません。作成直後、期限の中間、期限前にactive状態を点検し、停止、error、expired、triggeredを区別します。外国市場の時間換算はForexセッション解説で確認できます。

通知文を再確認手順にし、webhookから秘密情報を除く

通知文にはalert ID、full symbol、provider、interval、condition、frequency、trigger time、timezone、次の確認行動を入れます。「XYZ BUY」のような短文はsourceと理由が分からず、転送先で誤解されます。動的placeholderを使う場合は、どの値がtrigger時点で挿入されるかをtestし、未展開文字や桁、timezoneを確認します。

• 含める: alert ID、symbol、interval、condition、trigger時刻、chartを開いた後の確認順。
• 含めない: password、API secret、session token、個人情報、口座番号、無条件の発注命令。
• Webhook: 受信側を認証・検証し、allowlist、rate limit、重複排除、log、停止手順を用意する。
• 端末通知: OS permission、focus mode、email filter、network切断をtestする。

102.50のcrossを確定1時間足で一度だけ確認する

架空alert A-017は、Venue XのXYZ、1時間足closeが102.50を下から上へcrossし、そのbarが確定した時に一度だけapp通知する仕様です。現在値101.20なら距離は101.20−102.50=−1.30、threshold比は−1.30÷102.50×100≈−1.27%です。これは「あと1.27%で必ず到達」ではなく、現在の入力とthresholdの位置関係だけを示します。

symbol、価格、期限はすべて架空で、売買推奨ではありません。

testではthresholdを現在値の近くへ無断変更せず、paperまたは専用の架空条件で通知経路を確認します。本番条件を変更する場合は新しいIDとversionを作り、旧alertを停止した証拠を残します。通知後に注文サイズを検討する場合も、stop-lossとposition sizingの解説で損失許容を別計算し、alertをrisk判断に代用しません。

作成・test・監視・終了までを一つの台帳で管理する

alertの完了条件は保存ボタンを押すことではありません。仕様文と画面設定が一致し、test経路が届き、active一覧へIDと期限が表示され、trigger後の再確認行動が定義され、停止方法を実行できることです。週次レビューでorphan alert、重複条件、期限切れ、古いscript、使わない通知先を整理します。

1. 01仕様を一文で書く

   full symbol、source、operator、threshold、interval、bar state、frequencyを明記する。

2. 02画面と照合

   condition名、inputs、timezone、expiry、channelを一項目ずつ確認する。

3. 03安全にtest

   架空条件または非発注環境でplaceholder、遅延、重複、通知permissionを確認する。

4. 04台帳へ登録

   alert ID、作成日時、script version、画像、owner、停止手順を保存する。

5. 05通知後に再検証

   symbol、timestamp、bar状態、設定snapshot、反証条件を読み、結論を別に記録する。

indicator conditionを使う場合は無料TradingViewインジケーターを観察し、Pineで独自conditionを作る場合はPine Script v6入門へ進みます。過去のtrigger性能を評価する時はBacktest Labへ分け、本稿ではalert運用の再現性と安全性に集中します。