TradingView：データ・Pine・アラートとJSTの確認

チャートのサービスと、注文を受ける口座は別

ブラウザー、デスクトップとモバイルで使える分析環境です。保存レイアウトの利用はアカウントやプラン次第。資金を預かって注文を受ける業者と、チャートの利用者アカウントを区別し、取引パネルに表示する口座と配信元を確認します。

検索に並ぶ現金指数、先物の連続系列と指数CFDは別商品。提供者、完全なシンボル、商品、セッション、系列の接続や調整設定を残します。表示できる銘柄でも、接続した口座で売買できるとは限りません。

画面の配置を変える前に、ルールに必要な価格と周期を選びます。複数のウォッチリスト項目と、同時表示する複数チャートは別。現行の比較表ではBasicはタブあたり1チャートなので、三つの足を必ず一画面に並べられるとはしません。契約時の最新制限を確認します。

表示の時刻帯を変えても、Pineの既定hourは変わらない

架空足の開始を2026年10月6日13:30UTC、syminfo.timezoneをAmerica/New_Yorkと指定。当地は09:30なので既定のhourは9。Europe/Warsaw表示では15:30、表示をUTCへ変えると13:30ですが、hourは9のままです。

Pineの計算はチャートの表示ゾーンを読みません。Warsawで判定するなら、例えばhour(time, "Europe/Warsaw")を明示すると15。UTC全日時、銘柄ゾーンとフィルターのゾーンを記録します。これは実売買の記録ではなく、指定足の開始時刻の例。終了時刻と混同しません。

Pineのロジックと、コミュニティの人気は別の確認

Pineは指標、模擬戦略とアラート条件を表現する言語です。RSIなどの関数があっても、全初心者が30分で習得する根拠にはなりません。足の途中の閾値超えと確定終値の条件は別で、コード、頻度と利用可能時刻を揃えます。

公開スクリプトへの投稿規則・審査は、利益の優位性の認証ではありません。信号が当時使えた情報だけを使うか、後の確認で過去に印が置かれていないかを検証。非公開コードなら見られる範囲が限られ、いいね数、サブスクとモデレーションでは代替できません。

プランの料金と、取引所データの権利を分ける

現在の比較表はBasic、Essential、Plus、Premium、Ultimate。Premiumを全体で最上位とはしません。チャート数、指標、アラートの種類・件数、履歴、秒・tick足とリプレイの利用条件を自分の契約状態で確認します。通貨、地域、月払・年払、税と更新時の請求条件は実際の購入画面で確認し、古い2024年USDの参考価格を日本での現行料金にしません。

有料プランで全取引所のリアルタイムデータが付くとは限りません。チャートの配信元・遅延ラベルを読み、米株の既定データが主市場でなくCboe由来のケースも区別。業者で購入したデータを認証できる連携も、対応業者・取引所・口座の一覧を確認します。ロゴや日本語UIだけでは権利の範囲は決まりません。

足の途中、終値とアラートの保存コピー

架空H1ルールを「終値が1.1050より上」と指定。10:35に1.1052へ達しても、11:00の終値が1.1040なら、途中の閾値超えは起こったが終値条件は不成立です。実データではありません。同じ価格系列と判定時刻・アラート頻度で記録します。

戦略のエミュレーターは履歴の約定仮定を使います。Bar Magnifierは利用可能な下位足データで内側を調べますが、実約定や待ち行列の順番を再現した証明にはなりません。対象期間の下位足の範囲も確認します。異なるテスターの合計だけを比べて、どちらが正しいと断定しません。

サーバーで動くアラートは、作成時のコード・入力・銘柄・時間足の別コピーです。後からチャートを編集しても既存の稼働コピーは変わらず、必要な変更を反映するには作り直します。過去検証にはコード版、期間、費用、信号時刻と約定仮定を残します。

業者接続と、外部自動処理の状態を確認

実注文は具体的な契約法人、口座種類と商品の対応が必要です。OANDAというグループ名だけで全地域の対応は分かりません。例えばポーランドOANDA TMSの手順は同社CFD口座の接続を説明するもので、日本のOANDA口座への共通手順ではありません。接続できない場合にMetaTraderだけが選択肢とも限りません。

Pine戦略の模擬注文を、そのまま接続業者へ実送信する仕組みとはしません。Webhookを外部ソフトで解釈するなら別の執行システムとなり、受信、依頼、確認済み約定を別に管理します。

独立した架空の重複練習：同じdecision IDで、追加買い0.10 lotという同一依頼を二回受信。初期建玉ゼロ、両方が全量約定すると指定します。実際のTradingViewが常に再送するという主張ではありません。

IDには判断とルール版を区別する情報が必要。EURUSDだけをIDにすれば後の正規信号まで止めます。受信済みは約定済みではなく、メモリー内の集合は再起動で失われます。約定と記録の間に停止すれば結果不明もあり、再試行前に口座照合が必要。この表は重複処理の模型で、実環境のexactly-once保証ではありません。

日本向けの追加例：JSTの深夜をまたぐ窓に日付を付ける

架空の観測窓をJST2026年10月6日22:00以上、7日01:00未満と定義。これは商品の営業時間や注文許可ではなく、足の開始時刻を分類する3時間の半開区間です。下表は日付と名前付き時間帯を含めて検算した例です。

hour(time, "Asia/Tokyo")が22以上または1未満という時刻だけの条件は、他の日の同じ時間帯も含めます。「6日で22時以降」だけなら7日00:30が落ちます。一回限りの窓なら日付付きの両端を比較します。

start = timestamp("Asia/Tokyo", 2026, 10, 6, 22, 0)
finish = timestamp("Asia/Tokyo", 2026, 10, 7, 1, 0)
inWindow = time >= start and time < finish

Pineの時刻関数の意味に沿った説明用断片で、本稿でTradingView上のコンパイル・実売買を実行した報告ではありません。完全なスクリプト、対象シンボル、足の周期、確認時点とアラート保存コピーを別に検証します。銘柄ゾーンがNew Yorkなら15:30UTCは同日11:30で、日本の翌日00:30とは日付も違います。チャート表示をJSTへ変えるだけでコードの条件が変わったとは判断しません。

明日確かめる五つの対応関係

1. 完全シンボル、提供者、商品、セッションと時間帯を記録し、プランの制限内で日・4時間・1時間を比較。
2. 利用可能なリプレイ期間で書いた条件を練習。手動判断、模擬戦略と実約定を別記録。
3. 条件と頻度を明示したアラートを一つ確認。10:35の途中超えと11:00の終値がどちらの条件を満たすか分類。
4. 実法人、口座、商品と接続を確認。切断後の再依頼前は、最初の依頼が失敗したと推測せず履歴を照合。
5. テスター間はデータ・時刻・費用・約定仮定を揃え、最初の相違を記録。

TradingViewとMT5の照合で、表示の便利さとデータ・テスト・実執行を別に評価します。