webhookでTradingViewアラートを自動化する方法と注意点

TradingViewはチャート分析や戦略作りで最も人気のあるツールのひとつですが、そのアラートだけではブローカーに注文は送られません。アラートと執行をつなぐ橋がwebhookです。アラートが発動した瞬間に、指定したアドレスへ自動で送られるメッセージのことです。この記事では、その仕組み、メッセージに何を書くか、そして事前に知っておくべき信頼性とセキュリティの落とし穴を解説します。

webhookとは

webhookとは、何かが起きたときに一方のシステムが他方へHTTPリクエストを送る仕組みです。受け手のシステムが「何か新しいことは？」と絶えず問い合わせる必要がありません。TradingViewの場合、アラート条件が満たされると、TradingViewのサーバーが設定されたwebhook URLへPOSTリクエストを送り、その本文にはメッセージ欄に書いたテキストが入ります。

受け手の側、たとえば自動化プラットフォームは、メッセージを読み取り、何をすべきか（買い、売り、決済、数量）を判断して、ブローカー口座へ注文を送ります。覚えておきたいのは、TradingViewはメッセージを送るだけだということです。執行、リスク管理、妥当性チェックに関する判断はすべて受け手側で行われます。

TradingViewのヘルプセンターによれば、webhookの配信はサブスクリプションのプランによって異なり、通常はアカウントで二段階認証を有効にする必要があります。要件は変わる可能性があるため、最新の詳細は公式サイトで確認してください。

インジケーターアラートとストラテジーアラート

自動化で使われるアラートには主に2種類あります。

• インジケーター（条件）アラート： インジケーター、価格、またはPineコード内のアラート関数に対して作成します。ロジックがシンプルな場合や、インジケーター自体がシグナルを送るタイミングを決める場合に向いています。
• ストラテジーアラート： ストラテジー型のスクリプトに対して作成し、ストラテジーエンジンが仮想注文（エントリー、決済、ドテン）を執行したときに発動します。注文自体の情報、たとえば方向やサイズをメッセージに含められるのが利点です。

この違いは挙動を変えるため重要です。ストラテジーアラートはストラテジーの設定、たとえば足の確定時のみ計算するのかティックごとに計算するのかに左右されます。バックテストが足の確定で動いていたのにライブのアラートが足の途中で動くなら、結果は変わり得ます。設定を確認し、一貫させましょう。

メッセージの作り方：JSONとプレースホルダー

ほとんどの自動化システムは、フィールドと値で構成されるJSON形式のメッセージを想定しています。言葉で説明すると、典型的なメッセージには、どの銘柄を取引するか、どの方向か、何枚か、場合によっては戦略IDや接続を識別するトークンといったフィールドが含まれます。正確な形式は受け手側が決めるため、テンプレートは必ず利用するプラットフォームのドキュメントからコピーしてください。

TradingViewはプレースホルダーに対応しています。二重の波かっこで囲んだ変数で、送信時に実際の値に置き換えられます。銘柄、終値、時刻のプレースホルダーがあり、ストラテジーアラートでは注文の方向や数量のものもあります。プレースホルダーを正しく使えば、同じメッセージのテンプレートを書き直さずに複数のチャートで使い回せます。

守っておきたいルール：

• JSONを正しい形式に保つ。フィールド名とテキストはダブルクォートで囲み、フィールドの間にはカンマを入れ、最後に余分なカンマを付けない。
• すべての状況で値が入るとは限らないフィールドに頼らない。
• TradingViewのアラートログで置き換え後のメッセージを確認し、実際に何が送られたかを見る。

正しい銘柄と限月のロールオーバー

先物には特有の問題があります。つなぎ足（たとえばNQ1!）は期近限月を表示し自動で切り替わりますが、ブローカーはどの限月を取引するかを具体的に知る必要があります。メッセージがつなぎ足の名前を送るなら、受け手側がそれを正しい限月に変換しなければなりません。特定の限月を送るなら、ロールの時期にアラートを更新する必要があります。詳しい説明は先物の限月ロールオーバーの記事にあります。

信頼性で考えるべきこと

良い自動化とは、うまく動かなかったときにそれがわかる自動化です。気をつけるべき点：

1. アラートの期限切れ： 一部のプランではアラートに有効期限があります。期限が切れたアラートは何の知らせもなく送信を止めます。リマインダーを設定しておきましょう。
2. スクリプトの変更： インジケーターやストラテジーを編集しても、既存のアラートは古いバージョンのまま動き続けることがあります。通常は作り直す必要があります。
3. アラートの重複： 同じチャートに2つのアラートがある場合や、1本の足で複数回発動するアラートは、重複した注文を送ることがあります。発動頻度は意図的に設定し、できれば受け手側で重複を検知させましょう。
4. 遅延： webhookはインターネット経由で届くため遅れることがあります。速い相場ではわずかな遅れも価格に影響します。スリッページと執行コストの記事を参照してください。
5. 受け手側の障害： 受信サーバーが利用できなければ、メッセージは失われることがあります。良いシステムならそれを通知してくれます。

webhook URLを守る

webhook URLは実質的に鍵です。それを知り、メッセージの形式も知っている人なら誰でも、あなたの口座に注文を送れてしまいます。したがって：

• スクリーンショット、掲示板、チャットグループにURLを載せない。
• 可能なら、受け手側が検証する秘密のトークンをメッセージに含める。
• URLが漏れた疑いがあれば、新しい接続を作り、古いものを無効にする。
• 受け手側でリスク上限を設定し、不正な形式のメッセージが来ても巨大なポジションを持たないようにする。

運用開始前のチェックリスト

• アラートと同じ計算設定で戦略を検証したか？
• メッセージは受け手のドキュメントに沿った正しいJSONか？
• 銘柄は正しい限月に対応づけられているか？
• アラートの有効期限を把握しているか？
• 日次損失上限と最大枚数を設定したか？
• まずシミュレーションですべてを試したか？

まとめ

• webhookは単なる伝達役です。TradingViewがメッセージを送り、受け手側が執行とリスク管理を担います。
• ストラテジーアラートは方向と数量を渡せますが、計算設定の一貫性が必要です。
• 正しいJSONと正しいプレースホルダーで、多くのミスを防げます。
• 期限切れ、重複、スクリプトの編集はよくある障害の原因です。
• webhook URLは秘密情報です。パスワードと同じように扱いましょう。

実際の流れを見たい方には、TradingViewアラートをWeCoreに接続するガイドがあります。WeCoreはアラートを受け取り、あなたのブローカー口座やプロップファーム口座での注文に変換し、自動リスク上限を適用します。シミュレーションモードから始められます。