TradingViewスクリーナーの使い方：条件保存からウォッチリスト・アラートまで

スクリーナーは意思決定ではなく調査対象を減らす道具

TradingViewスクリーナーは、選択した母集団にフィルターを適用し、条件に一致するシンボルと項目を表へまとめる機能です。結果は特定時点のデータと設定に依存し、将来の上昇、約定可能性、商品適合性を保証しません。最初の目的は「買うものを決める」ではなく、「次に一次資料を読む対象を、説明できる方法で減らす」ことです。銘柄、取引所、データ提供元が違えば同名資産でも行が別になり得るため、ティッカー文字列だけで同一視しません。

操作は、スクリーナー種別を選ぶ、対象市場を決める、必要な列を表示する、少数のフィルターを順に加える、画面を保存する、候補を個別確認する、という流れです。人気画面やプリセットは入口にはなりますが、その定義や構成が将来も同じとは限りません。プリセット名を根拠にせず、実際に有効なフィルターと境界値を自分の調査記録へ転記します。

分母を固定してから条件を加える

同じフィルターでも、全世界株式、米国主要取引所、日本株、特定業種では意味が変わります。母集団には少なくとも、スクリーナー種別、国・地域、取引所、資産種別、通貨、主要上場か重複上場を含むかを記録します。店頭FXや暗号資産では、取引所またはデータ提供元の違いも識別子の一部です。数値が同じように見えても、セッション、出来高定義、遅延、通貨換算が一致するとは限りません。

スクリーナーによって利用できる市場・フィールド・保存・書き出し機能は異なります。画面上の説明を確認してください。

母集団件数を最初に保存すれば、「800件から24件へ絞った」のか「30件から24件へ絞った」のかを区別できます。結果だけをCSVに出しても、分母と除外条件がなければ選別の強さを再現できません。日付、タイムゾーン、画面名、フィルターのスクリーンショットまたはテキストを同じ記録へ残します。

フィルターを役割別に積み、二重計上を避ける

実務では、①対象として扱えるか、②売買や観測に必要なデータがあるか、③調査仮説に関係するか、の順で条件を加えます。たとえば株式の長期調査なら、上場市場と価格の有無を固定した後、流動性の最低条件、規模、収益性などを加えます。短期監視ならセッション、出来高、値幅などが中心になります。同じ「momentum」を複数の似た指標で重ねると、独立した確認が増えたのではなく、同じ値動きを何度も数えただけになり得ます。

• 適格性: 対象市場、価格の有無、最低流動性、必要列の欠損を処理する。
• 調査目的: 仮説に直接関係する2〜4条件に絞り、結果を見て追加し続けない。
• 並び替え: フィルターと順位付けを分け、上位表示の根拠となる列を一つ明記する。
• 検証: 候補ごとに公式開示、取引所仕様、データ時点を開き、集約値を照合する。

境界値・欠損値・更新差で結果が壊れないか確かめる

PER 15以下、出来高100万以上などの閾値は、自然法則ではなく利用者が置いた境界です。14.9と15.1が本質的に別の会社とは限りません。中心値だけでなく、閾値を少し緩めた場合と厳しくした場合の件数と顔ぶれを並べます。小さな変更で候補が全面的に入れ替わるなら、条件は不安定です。境界近くの候補は「除外」だけで終わらせず、別の観察リストへ置く方法もあります。

欠損値はゼロではありません。売上成長率が空欄の会社を0%として残す、負の利益でPERが計算不能な会社を極端に割安と扱う、といった処理は結論を歪めます。NAを除外したのか、別グループへ分けたのか、代替指標を使ったのかを記録します。また、決算更新、構成変更、為替換算、企業行動により同じ画面でも翌日に値が変わるため、結果の再現には実行時刻が必要です。

数値は機能説明用の架空例です。特定の指標、銘柄、閾値を推奨しません。

ウォッチリストをResearch・Ready・Invalidへ分ける

スクリーナー結果を一つの巨大なウォッチリストへ追加すると、なぜ入れたか、いつ外すかが失われます。候補を状態で分けます。Researchは一次資料未確認、Readyは観測条件と失効条件を記録済み、Invalidは前提が崩れたが学習のため保存、という例です。Readyは買い推奨や注文待機を意味せず、必要な確認項目が埋まったという作業状態にすぎません。

リストの各行には、追加日、スクリーナー画面名、通過理由、未確認事項、次回確認日、失効条件を付けます。TradingViewのウォッチリスト機能に自由記述が足りない場合は、金融テンプレートHubの調査票や外部の表へ識別子を保存し、チャート上の色やフラグだけを唯一の記録にしません。書き出しや高度表示の可否は現在の画面とプランを確認します。

1. 01Researchへ追加

   シンボル、取引所、通過画面、追加理由を保存する。

2. 02一次資料を照合

   発行体、取引所、データ提供元で数値・単位・日付を確認する。

3. 03Ready条件を書く

   観測する変化と、候補を外す失効条件を別々に記録する。

4. 04Invalidを残す

   削除で痕跡を消さず、外れた理由と日付を学習記録へ移す。

アラートは再調査の時点を知らせる

スクリーナーはある時点の横断検索、ウォッチリストは候補の状態管理、アラートは条件変化の通知です。三つを同じものとして扱わないと、毎分スクリーナーを再実行したり、アラートだけで売買判断したりする誤りを減らせます。価格、指標、ウォッチリストなど利用できるアラート条件は現在の機能に従い、条件、時間足、頻度、期限、通知先をTradingViewアラート設定ガイドの台帳形式で残します。

通知を受けたら、最初にシンボルと取引所、次にデータ時刻と確定足、最後にスクリーナー画面の再実行を確認します。通知文だけを見て注文へ進みません。条件を変更した場合、既存アラートが自動的に新設定へ追随すると思い込まず、現在のTradingView仕様に従って再作成の要否を確認します。Webhookへ認証情報や個人情報を入れないことも共通の安全ルールです。

保存画面と除外理由を週次で監査する

週次レビューでは、保存画面を同じ母集団・並び順で開き、最初の件数、各段階の通過件数、新規追加、継続、Invalid移動、欠損増加を記録します。候補の価格が上がったかだけで画面の良し悪しを判断せず、目的とした調査負荷の削減、一次資料との一致、境界値への依存、見落としを評価します。相場を見てから閾値を変えた場合は新しい版として保存し、旧版を上書きしません。

市場全体の背景を調べる場合はMacro Research Workbenchで公表済みマクロデータを別軸に整理します。株式の流動性と価格形成はStocksの価格形成ガイド、指数全体と構成銘柄の参加差はIndicesのbreadth解説へ分けます。スクリーナーの行だけで、市場構造や事業の質を代替しないことが重要です。

• 画面名に目的と版を入れ、実行日だけで意味を失わない名称にする。
• 候補件数だけでなく、NA件数と除外理由を同じ表へ残す。
• 閾値変更は別版として保存し、結果を見た後の最適化を可視化する。
• 毎週「削除した理由」を一件以上読み返し、screenの盲点を更新する。
• 機能、列名、対象範囲が変わった場合は公式ヘルプと画面定義を再確認する。