前回の記事では、TradingView公式MCPをCodex経由で接続し、日本株のデータを取得できるところまで確認しました。（前回記事：TradingView MCPをChatGPTで使える？日本株で接続・検証してみた）
ただ、接続できるだけでは実際の投資分析に役立つとは限りません。
そこで今回は一歩進めて、
「TradingView MCPから取得したデータを、日本株分析にどこまで使えるのか」
を実際に検証しました。
まず、アドバンテスト・キオクシアHD・東京エレクトロンの3銘柄から日足データを取得し、同じ条件で比較します。
さらに、
「こちらから銘柄を指定するのではなく、条件に合う日本株をTradingView側から探せないか」
というスクリーニングにも挑戦しました。
結論からいうと、
- 個別銘柄の日足OHLCV取得 → 成功
- 取得データを使った指標計算 → 成功
- 複数銘柄の同条件比較 → 成功
- 日本株Screenerによる候補抽出 → HTTP 429で未完了
という結果になりました。
※この記事は2026年9月24～25日時点の検証結果です。TradingView MCPはBeta版のため、今後仕様や利用状況が変わる可能性があります。
今回検証した3銘柄
比較したのは、値動きの大きい半導体関連3銘柄です。
- 6857 アドバンテスト
- 285A キオクシアHD
- 8035 東京エレクトロン
TradingView MCPから、2026年8月24日～9月24日の日足OHLCVを各21本取得しました。
今回はTradingViewから完成した分析結果を取得するのではなく、価格・出来高の元データを取得し、その後の計算をPython側で行っています。
計算したのは以下の指標です。
- 5営業日騰落率
- 20営業日騰落率
- SMA5
- SMA20
- 20日高値・安値
- 20日高値までの距離
- 最新出来高
- 20日平均出来高
- 出来高倍率
- RSI14
同じデータ・同じ計算方法を使うことで、複数銘柄を横並びで比較します。
Codexの利用上限も意識して、外部データ取得を最小限にする
今回の検証では、必要以上にMCPへ問い合わせないことも意識しました。
実際に開発を続けていると、調査やコード修正などでCodexの利用枠を消費します。
そこで今回は、
「外部から取得する必要があるデータだけ取得し、ローカルで計算できるものはPythonで処理する」
という方針にしました。
3銘柄について、それぞれ1回ずつOHLCVを取得。
TradingView MCPへのOHLCV取得リクエストは、
3銘柄 × 1回 = 合計3回
です。
取得したOHLCVから、SMAやRSI、騰落率、出来高倍率などをPython側で計算しました。
つまり、
TradingView MCP → 必要なOHLCVを取得 → Pythonで計算
という構成です。
外部サービスへの問い合わせとローカル処理を分けることで、MCPへの不要なリクエストを減らしながら検証できます。
3銘柄を同じ条件で比較した結果
結果は次のようになりました。
| 銘柄 | 9/24取得値※ | 5日騰落率 | 20日騰落率 | SMA5 | SMA20 | 20日高値まで | 出来高倍率 | RSI14 |
|---|---|---|---|---|---|---|---|---|
| アドバンテスト | 33,060円 | +6.37% | -4.17% | 31,242 | 32,953 | +9.26% | 0.99倍 | 49.31 |
| キオクシアHD | 54,580円 | +7.89% | +7.17% | 52,312 | 52,899.5 | +11.84% | 0.93倍 | 56.06 |
| 東京エレクトロン | 53,920円 | +5.87% | -2.23% | 52,068 | 53,668.5 | +6.70% | 1.26倍 | 50.28 |
※TradingView MCPでは市場データに遅延があるため、9月24日の値は取得時点の値として扱っています。
3銘柄とも直近5営業日は上昇していますが、中身には違いがありました。
アドバンテスト
5日騰落率は+6.37%と短期的には戻していますが、20日騰落率は-4.17%。
SMA5はSMA20を下回っており、中期的な上昇トレンドへ完全に戻ったとは判断しにくい状態です。
今回の数値だけで見るなら、さらに上昇を追うというより、反転が継続するか確認したい局面でした。
キオクシアHD
5日騰落率+7.89%、20日騰落率+7.17%。
今回比較した3銘柄の中では、中期的な上昇が最も明確でした。
RSI14は56.06。強さは確認できますが、新規に追いかけるなら価格位置を確認したいところです。
東京エレクトロン
5日騰落率は+5.87%ですが、20日では-2.23%。
特徴的だったのは出来高倍率です。
3銘柄の中で唯一1倍を明確に上回る1.26倍となっており、直近の値動きに出来高が伴っていました。
このように同じ条件で計算すると、単純な騰落率だけではなく、
「どういう状態で上がっているのか」
まで比較できます。
指定した監視銘柄を同条件で比較する用途については、TradingView MCPから取得したデータを十分活用できそうです。
では、銘柄自体をTradingViewから探せないのか？
ここで次の疑問が出ました。
今回はこちらから3銘柄を指定しています。
しかし実際の運用を考えると、
条件に合う日本株をTradingView側から探せた方が便利です。
理想は、
日本株をスクリーニング
↓
候補銘柄だけOHLCV取得
↓
Pythonでテクニカル指標を計算
↓
自作のBUY条件で判定
という流れです。
全東証銘柄のOHLCVを1銘柄ずつ取得するより、最初に候補を絞れればMCPの利用量も大きく減らせます。
自作ツールのBUY条件で銘柄を探せるか
現在、Pythonで日本株の分析・自動売買ツールを開発中です。
そこで今回は、TradingView MCPのScreenerで候補銘柄を絞り込み、その後に自作ツールと同じBUY条件で判定できないか試すことにしました。
現在使っているBUY判定は、以下3条件のうち2つ以上を満たすことです。
- RSI14 < 35
- MACD > MACD_SIGNAL
- Close <= BB_LOWER × 1.02
ここでTradingView独自の「買い」「強い買い」といった評価を、そのまま売買判定に使うわけではありません。
目指したのは、
TradingView Screener
↓
候補銘柄を抽出
↓
OHLCVを取得
↓
Pythonで指標を計算
↓
自作ツールのBUY条件で判定
という流れです。
これが実現すれば、こちらから分析する銘柄を毎回指定するだけでなく、
「条件に合いそうな日本株を探すところから始める」
ことが可能になります。
TradingView公式MCPにはScreener機能がある
TradingView公式MCPには「run_screener」というScreener機能が用意されています。
公式ドキュメント：
https://www.tradingview.com/mcp/docs/
日本市場（japan）も対象となっており、価格や出来高などの条件を指定して銘柄を抽出できます。
そのため仕様上は、
Screenerで候補を絞る
↓
必要な銘柄だけOHLCVを取得する
という構成が考えられます。
これが安定して使えれば、全銘柄の日足を片っ端から取得する必要がなくなり、今回意識しているCodexやMCPの利用量削減とも相性が良さそうです。
実際に日本株Screenerを動かしてみた
そこで実際に、日本市場を対象としてScreenerを実行しました。
最初に確認したかったのは、複雑なBUY条件ではありません。
まず、
「TradingView MCPのScreenerから日本株を正常に取得できるか」
を確認します。
最終的なテスト条件はシンプルです。
- Market：Japan
- Symbol type：Stock
- Volume：1以上
- 出来高降順
- 最大5銘柄
ところが、2026年9月24日の実行では、
HTTP 429（Too Many Requests）
が返ってきました。
対象となったのは、
scanner.tradingview.com/japan/scan
です。
この時点では、一時的な利用制限などの可能性も考えられます。
そこで無理に再試行せず、その日の検証は終了しました。
翌日、最初の1回だけ再検証
翌9月25日。
時間を空けた状態で、同じScreenerをもう一度だけ実行しました。
今回は、
- Screener呼び出し：1回
- OHLCV呼び出し：0回
- TradingView MCP総呼び出し：1回
です。
しかし結果は、
再びHTTP 429
でした。
そのため再試行は行わず、検証を終了しました。
結果として、
Screener
↓
候補銘柄
↓
OHLCV
↓
BUY判定
という一連の流れを最後まで実証することはできませんでした。
自分の環境だけで起きているのか？
もし自分の設定ミスだけで429が出ているのであれば、TradingView MCPそのものの評価材料にはしにくいため、追加で調べました。
TradingView公式MCPは現在Betaとして提供されています。
公式ドキュメント：
https://www.tradingview.com/mcp/docs/
さらに今回調べたところ、同時期にTradingView MCPを利用している他のユーザーからも、
scanner系endpointでHTTP 429が発生する
という報告が複数確認できました。
例えば、
- 少数のリクエストでも429になる
- Newsなど別機能は動くがscannerが429になる
- scannerが長時間429になった後、自然に復旧した
といった報告があります。
参考：
もちろん、これだけで、
「今回の429はTradingView側の障害だった」
と断定することはできません。
TradingViewから今回の事象について公式な障害発表を確認したわけではなく、ユーザーごとの利用制限など別の要因である可能性も残ります。
ただし少なくとも、
「自分の設定ミスだけで発生した特殊な事象」とも言い切れない
状況でした。
今回どこまで使えたのか
今回の検証で特に感じたのは、
「機能として存在すること」と「安定して運用できること」は別
という点です。
ScreenerそのものはTradingView公式MCPに用意されています。
しかし、毎営業日の分析や自動化に利用するなら、安定して応答するか、429発生時にどう処理するかまで確認する必要があります。
現時点では日足・スイング分析との相性が良さそう
今回実際に動かせた範囲では、TradingView MCPは日足を使った監視銘柄の比較と相性が良さそうです。
例えば、
監視銘柄の日足を取得
↓
Pythonで同じ指標を計算
↓
AIで横並び比較
という使い方です。
TradingView側ですべての分析を完結させる必要はありません。
今回のように、
TradingView：データ取得
Python：指標計算・売買ロジック
AI：比較・整理
と役割を分けることで、自分で計算条件を管理しながら分析できます。
また、必要なデータだけ取得してローカルで計算すれば、Codexの利用量を抑えることにもつながります。
TradingView MCPの市場データには遅延があるため、今回確認した使い方もリアルタイム売買ではなく、日足ベースの分析を前提としています。
RSI14の数値には注意
今回計算したRSI14には注意点があります。
取得した日足は21本です。
そのデータからRSI14を計算しているため、より長期間の履歴を使ったRSIとは数値がずれる可能性があります。
今回の21本はあくまで、
3銘柄を同じ条件で比較するための検証データ
です。
実際にScreenerから自作BUY条件まで接続する場合は、より長い日足履歴を取得して判定する必要があります。
まとめ
今回の検証では、TradingView MCPから日本株の日足OHLCVを取得し、Pythonで指標を計算して3銘柄を同じ条件で比較するところまで実行できました。
結果は、
- 個別銘柄の日足OHLCV取得 → 成功
- Pythonでの指標計算 → 成功
- 複数銘柄の比較 → 成功
- 日本株Screener → HTTP 429で未完了
となりました。
今回特に使いやすかったのは、
TradingViewでデータ取得 → Pythonで計算 → AIで比較・整理
という役割分担です。
一方、Screenerについては9月24日・25日の2日間ともHTTP 429となり、
Screener → 候補抽出 → OHLCV取得 → 自作BUY条件で判定
までつなげることはできませんでした。
そのため現時点では、
個別銘柄の日足取得・比較分析には使える。
全市場からの自動スクリーニングは、安定性を含めて追加検証が必要。
というのが今回の結論です。
Screenerが正常に利用できる状態になったら、次は候補銘柄の抽出から自作BUY条件による判定までつなげて検証します。
コメント