Claude Code で株式ニュース分析を自動化する — EDINET・J-Quants・RSS の 3 層構成

株式ニュースの分析を LLM で自動化するとき、どのデータが API で取れて、どこが手作業として残るのかを 3 層に整理します。

前提として、前回の「悪材料出尽くし（アク抜け）」の見抜き方で、株価の底打ち・反転上昇を読む 4 ステップを整理しました。① 一次ソースでニュースを精査 → ② 市場予想とのサプライズを測定 → ③ 出来高で出尽くしを確認 → ④ β値で反転時の上昇幅を見積もる、という流れです。本記事はこの 4 ステップを実装する側の話です。

結論から言うと、データソースは「機械可読かどうか」で 3 層に分かれ、第 2 層（コンセンサス）だけが自動化できずにボトルネックになります。

後半では「X などのソーシャルメディア分析でモメンタムが測れるのでは？」という問いを扱います。これは第 3 層のデータをどう解釈するかという話で、測れるものと測れないものに明確な線引きがあります。

本記事はデータソースとツール構成の技術的な整理であり、投資判断や特定銘柄の売買を推奨するものではありません。

なお、発注そのものの自動化は Claude Code で株式投資を自動化するで扱っています。本記事はその手前にあるデータ取得層の話です。

株式ニュース分析のデータソースを 3 層に整理する

一言でまとめると 「一次ソースは API、二次ソースは RSS、コンセンサスは手入力」 の 3 層構成が現実解です。以下、層ごとに見ていきます。

第 1 層：一次ソース（事実）— 完全に自動化できる

ここは API で機械可読に取れるので、Claude Code から扱う分には何の問題もありません。

EDINET API v2

金融庁の法定開示システムの API です。

API キーは無料。EDINET のサイトでメールアドレスを登録すれば発行されます
2024 年 3 月から API キーが必須になりました。それ以前のコード例は認証なしで書かれているので、古い記事のコピペは動きません
API 仕様書（Version 2）は 2026 年 6 月に更新されています
有価証券報告書・四半期報告書の XBRL（財務報告用の構造化データ形式）が取れます

注意点は速報性がないことです。EDINET は金融商品取引法に基づく法定開示なので、決算短信のような適時開示より遅れます。ステップ ① の「悪材料が一過性か構造的か」を過去に遡って調べるには最適ですが、当日の反応を追う用途には向きません。

取得した XBRL のパース方法は EDINET XBRL を Python で扱うで扱っています。

J-Quants API

JPX 総研が提供する個人向けデータ配信サービスです。株価・財務データが取れます。

最大の落とし穴は無料プランのデータ遅延です。

プラン	制約	向く用途
Free	データが 12 週遅延。直近 12 週間は取得できない。1 年で自動終了（再登録可）	バックテスト専用
Light 以上	遅延が縮まり、実用的な速報性になる	当日の分析

ニュース分析は「今日の開示に対して市場がどう反応したか」を見るものなので、12 週遅延では原理的に成立しません。無料プランで組み始めてあとで気づくパターンが最も痛いので、ここは最初に確認しておくべきポイントです。

過去の適時開示をまとめて遡りたい場合は、J-Quants API の TDnet アドオン（過去 5 年分の XBRL データ）が使えます。

TDnet 公開ページと企業 IR の PDF

TDnet の公開ページは直近 31 日分のみです。それ以前は消えます
JPX が提供する TDnet API は法人向けの有料サービスです
企業 IR ページの PDF は aegis_fetch（このブログの環境では MCP 経由）で取得して、Claude にそのまま読ませます

PDF の注記まで読ませられるのが、この構成で LLM を使う最大の利点です。 「減損損失が一括計上か、来期以降も続くのか」は注記に書かれていることが多く、人間が読むと時間がかかります。ここは Claude が速い領域です。

なお、ステップ ④ のβ値も J-Quants の株価データから計算できるので、第 1 層だけで完結します。自動化で悩むところではありません。

MCP サーバーにする理由

EDINET / J-Quants は、その場で curl を組ませるのではなく自作の MCP サーバーとしてツール化するのを勧めます。

# MCP サーバー側のツール定義（スケッチ）
# import httpx / from mcp.server.fastmcp import FastMCP と
# mcp = FastMCP("edinet") の初期化は省略

@mcp.tool()
def fetch_disclosures(date: str) -> list[dict]:
    """指定日の EDINET 提出書類一覧を返す。

    date: YYYY-MM-DD
    """
    resp = httpx.get(
        "https://api.edinet-fsa.go.jp/api/v2/documents.json",
        params={
            "date": date,
            "type": 2,                          # 2 = 提出書類一覧＋メタデータ
            "Subscription-Key": EDINET_API_KEY,  # ヘッダではなくクエリパラメータ
        },
        timeout=30,
    )
    resp.raise_for_status()
    return resp.json()["results"]

EDINET API v2 は API キーをクエリパラメータ Subscription-Key で渡す仕様です。ヘッダ認証ではないので、キーがアクセスログや履歴に残りやすい点に注意してください。MCP サーバー側に閉じ込めておく実務的な理由がここにもあります。

ツール化する利点は 3 つあります。

API キーがプロンプトに露出しない — サーバー側の環境変数に閉じ込められます
呼び出しが決定的になる — 毎回 Claude にリクエストを組み立てさせると、パラメータの揺れで結果が変わります
生データをローカルに落とせる — 日次で保存しておけば、「織り込み度合い」の時系列比較ができます。前回の記事で書いた「ニュース発表前に株価がすでに下落していたか」は、過去データがないと判定できません

MCP でチャート側を扱う対になる話は Claude Code × TradingView にあります。

第 2 層：コンセンサス（予想）— 自動化できない

ステップ ② の「サプライズ度の測定」には事前予想の数値が必要です。ここで言うコンセンサスは、複数の証券会社アナリストによる業績予想の平均値を指します。

問題は、アナリスト予想に機械可読な無料ソースが実質ないことです。前回の記事でコンセンサスの入手先を表にまとめましたが、あの表のうちプログラムから叩けるものはゼロです。四季報も IFIS 株予報も、自動取得の前提では使えません。

現実的な回避策は 2 つです。

回避策 1：会社予想を代理指標にする

J-Quants の財務データには会社自身の通期予想が含まれます。つまり「四半期実績 ÷ 通期会社予想」の進捗率は完全に自動計算できます。前回の記事で挙げた「四半期あたり 25%」の目安がそのまま回ります（季節性の強い業種でこの目安が使えない点も前回のとおりです）。

def progress_ratio(actual_op: float, forecast_op: float) -> float:
    """通期会社予想に対する営業利益の進捗率を返す。"""
    if forecast_op <= 0:
        raise ValueError("赤字予想には進捗率の概念が使えない")
    return actual_op / forecast_op


def judge_progress(ratio: float, quarter: int) -> str:
    """進捗率を四半期数で正規化して判定する。"""
    expected = 0.25 * quarter          # Q1 なら 25%、Q2 なら 50%
    if ratio < expected * 0.8:
        return "下方修正リスクが意識されている水準"
    if ratio > expected * 1.2:
        return "上方修正の余地がある水準"
    return "計画線上"

回避策 2：コンセンサスは手で入れる

銘柄を絞って追うなら、予想値だけを手入力の YAML にして Claude Code に読ませるのが一番速いです。

# consensus/6501.yaml
code: "6501"
fiscal_year: 2026
consensus:
  operating_profit: 78000   # 百万円
  source: "証券会社レポート（2026-07-15 時点）"
  updated_at: 2026-07-15
company_forecast:
  operating_profit: 75000

ここを API 化しようと頑張るのは労力に見合いません。追う銘柄が 10〜20 なら手入力のほうが確実に速く、しかも「どのレポートの数字か」が残ります。

第 3 層：センチメント（反応）— 規約とコストに縛られる

RSS を最優先にする

二次ソースの網羅は RSS が最も手堅いです。SPA（JavaScript でレンダリングするページ）を fetch するより確実で、規約上もクリーンです。

Google News RSS — https://news.google.com/rss/search?q=<検索語>&hl=ja&gl=JP&ceid=JP:ja の形式でクエリを投げられます。銘柄名で引くのに便利ですが、非公式なので恒久性は保証されません
報道各社の RSS — 提供があるものはこれを使います

スクレイピングが禁止されているソース

Yahoo!ファイナンスは、掲載データをプログラムで機械的に取得する行為（スクレイピング）を明示的に禁止しています。 株価データが必要な場合は同社の有償サービスを使うよう案内されています。掲示板の投稿は日本の個人投資家センチメントの宝庫ですが、ここは自動取得の対象にしてはいけません。

株探・みんかぶなどについても、機械的取得の可否は各サイトの規約を個別に確認してください。手動閲覧の補助に留めるのが安全です。

X（Twitter）のコスト構造

X の API は、2026 年時点で従量課金（クレジット購入型）が新規開発者のデフォルトになっています。公式ドキュメントでも、サブスクリプションや最低契約のない「使った分だけ」のモデルとして説明されています。従来の Basic / Pro といった月額ティアは新規受付を終了しています。

サードパーティの集計では、読み取りが 1 ポストあたり $0.005 程度とされています。ただし単価は変わるので、実際の見積もりは公式の料金ページで確認してください。いずれにせよ、銘柄横断でセンチメントを網羅しようとすると読み取り数が一気に膨らみます。個別ポストの内容確認だけなら api.fxtwitter.com 経由で足りますが、検索は有料 API が必要です。

PTS は自動化を諦める

夜間取引（PTS）の値動きに無料 API はなく、証券会社の画面依存です。ここは目視が現実的です（運用時間の話は後述します）。

以上が第 3 層のデータをどう集めるかという話でした。では、集めたセンチメントから何が読み取れるのでしょうか。

第 3 層の解釈：ソーシャルメディアで「モメンタム」は測れるか

X などのソーシャル分析でモメンタムを測るというアイデアは筋が通っていますが、測れるものと測れないものを分けないと、逆方向のシグナルとして使ってしまいます。

センチメントとアテンションは別のシグナル

Cookson らの研究 “Market Signals from Social Media”（2025）は、StockTwits・X・Seeking Alpha の投稿を 2013〜2021 年について分析したものです。この研究は投資家の「感情（センチメント）」と「注目（アテンション）」を、別のシグナルとして切り分けました（研究の紹介記事）。

報告されている関係は次のとおりです。

高センチメントの日 — その前に株価は上昇しており、その後 20 日かけて反転（リバーサル）する
高アテンションの日 — その前に株価は下落しており、その後もマイナスが継続する

この 2 つを区別した取引戦略で、年率 4.6% の超過リターン、シャープレシオ（リスク 1 単位あたりの超過リターン）1.2 が報告されています。

つまり「方向」は測れない、「過熱度」は測れる

この結果には重要な含意があります。

ソーシャルの強気センチメントは、順張り（モメンタム継続）の根拠にはなりません。 むしろ短期の反転が続くので、逆張りの計器として読むほうが素直です。「X で盛り上がっているから上がる」は、報告されている関係と逆向きです。

一方でアテンション（言及数・投稿量）は、市場の参加度と過熱度をかなり素直に反映します。これは前回の記事のステップ ③「出尽くしの兆候確認」にそのまま使えます。

悪材料の直後に投稿量が急増 → まだ狼狽売りの最中。アテンションのピークでは飛び乗らないほうがよいです
そこから投稿量が減衰していく → 話題が枯れた＝売り手が一巡したサインです
一次ソースの事実は限定的なのに投稿量だけが過剰 → 前回の記事で書いた「事実と反応の歪み」そのものです

モメンタムの方向を測るのではなく、「群衆がどれだけ集まっていて、それがいつ引いたか」を測る。 これがソーシャル分析の実用的な使い方です。

日本株に持ち込むときの制約

上記の研究は米国の個人投資家向けプラットフォームを対象にしたもので、日本株にそのまま移植できる保証はありません。とくに次の 3 点が効きます。

StockTwits に相当するものが日本にない — StockTwits は投稿者が自分で「Bullish / Bearish」とラベルを付けるので、センチメントの集計精度が高いです。日本語圏にはこの構造化されたラベルがなく、テキストから推定するしかありません
最大の投稿プールが規約で使えない — 日本の個人投資家センチメントは Yahoo!ファイナンス掲示板に厚く溜まっていますが、前述のとおり自動取得は禁止です
煽りアカウントとボットの混入 — 低位株・小型株では、投稿量そのものが仕掛けの結果である場合があります。投稿量の急増を「注目」と読むか「仕掛け」と読むかは、アカウントの分布を見ないと判別できません

3 点目は特に注意が必要です。投稿量の集計では、ユニークアカウント数と投稿数を必ず分けて数えてください。少数のアカウントが大量投稿している場合、投稿数は跳ねてもアテンションは実在しません。

実際にどう仕掛けられるのかはメディアリンクス（6659）の SNS 低位株ポンプ・アンド・ダンプの解剖が具体例になります。

アテンションの z-score を Python で実装する

アテンションを使うなら、絶対的な投稿数ではなくその銘柄の平常時からの乖離を見ます。

import pandas as pd


def attention_zscore(
    daily_counts: pd.Series, window: int = 60, min_periods: int = 30
) -> pd.Series:
    """日次言及数を、過去 window 日の平常水準からの z-score に変換する。

    daily_counts: 日付インデックスのユニークアカウント数（投稿数ではない）
    """
    baseline = daily_counts.shift(1).rolling(window, min_periods=min_periods)
    mean = baseline.mean()
    std = baseline.std()
    return (daily_counts - mean) / std

shift(1) を入れているのは、当日の値を平常水準の計算に含めない（先読みを避ける）ためです。ここを忘れると、急増した日の z-score が自分自身に希釈されて過小評価されます。

判定は「z が 3 を超えたらアテンションのピーク」「2 日連続で 1 を下回ったら減衰」といった素朴なルールで十分機能します。閾値を凝る前に、まず数銘柄で過去の急落局面をなぞって目で確かめるほうが速いです。

Claude Code で定期実行する（レートリミットとキャッシュ）

この構成を回すと、最終的にこういうレポートが毎日出てくる形になります。

2026-07-31 17:30 スクリーニング結果（対象 18 銘柄）

[6501] 通期計画進捗率 18.2%（Q1 / 期待 25%）→ 下方修正リスクが意識されている水準
       アテンション z-score 3.8（前日 1.1）→ ピーク圏、投稿量の減衰待ち
       当日開示: 業績予想の修正に関するお知らせ（減損 120 億円・一括計上）
       判定: 一過性損失。ステップ ③ の減衰を待って再評価

[4桁] ...

/schedule で決算期だけ回す — 決算発表は立会終了後に集中するので、17 時台に「当日の開示 → 該当銘柄の進捗率 → 言及数の z-score」を一括で出させる形が相性が良いです
レートリミットとキャッシュ — 各 API のレート制限は MCP サーバー側で吸収します。同じ日付のリクエストは必ずローカルキャッシュから返すようにしてください。Claude は同じ質問を言い換えて何度も投げることがあります。指数バックオフやサーキットブレーカーの実装は AI エージェントのレートリミット対策が参考になります
数値の計算は Claude にやらせない — 進捗率や z-score は決定的なコードで計算し、Claude には判定と文章化だけを任せます。LLM に算術をやらせると、桁を間違えたときに検算のフックがありません

最後の点はこの構成の設計原則です。**「取得と計算はコード、解釈は LLM」**という役割分担を守るかどうかで、信頼できる出力になるかが決まります。

まとめ

データソースは 3 層に分かれ、第 1 層（一次ソース）は完全に自動化でき、第 2 層（コンセンサス）は手入力が現実解
J-Quants の無料プランは 12 週遅延なので、ニュース分析には使えない。最初に確認すべき落とし穴
Yahoo!ファイナンスはスクレイピング禁止。日本の個人投資家センチメントの本体が規約上使えないのが最大の制約
ソーシャル分析でモメンタムの「方向」は測れない。高センチメントは 20 日程度で反転する側の関係が報告されている
測れるのはアテンション（参加の過熱度）。投稿量のピークアウトを「売り一巡」のサインとして使うのが実用的
投稿量はユニークアカウント数で数え、z-score で平常時からの乖離を見る
取得と計算はコード、解釈は LLM に分ける

まずは J-Quants のプラン確認と、追う銘柄 10 件分の consensus/*.yaml を用意するところから始めるのが最短です。