議会の株式取引開示を2026年にスクレイピングする方法（API & Python）

議会の株式取引開示データは、基礎となる記録が紛れもなく公開されている——議会議員には法律上の提出義務がある——にもかかわらず、実際に使える形にするには相応の手間がかかるケースです。下院書記官室と上院はそれぞれ独自の開示ポータルを運営しており、検索項目も PDF ベースのファイリングもそれぞれ異なり、どちらも統一された構造化 API を公開していません。このガイドでは、両ポータルへの自作アプローチとそれが破綻するポイント、ノーコードの選択肢、そして両院を一つのスキーマに正規化し個々のファイリングを構造化 JSON にパースする構造化 API を取り上げます。

なぜ議会の株式取引開示をスクレイピングするのか？

議会の財務開示データは、次のような用途を支えます。

• 公益のための透明性とジャーナリズム — 連邦議会議員や候補者が何を、いつ売買したと開示したかを、投票、委員会の担当分野、立法活動と突き合わせて追跡できます。
• コンプライアンスと利益相反リサーチ — ウォッチドッグ団体、学術研究者、報道機関向けに、議員の委員会が監督するセクターでの開示済み取引にフラグを立てられます。
• トレンドと報道範囲のリサーチ — 開示件数やファイリングの種類が、院、州、選挙サイクルによって時間の経過とともにどう変化するかを把握できます。
• ファイリングの適時性トラッキング — 定期取引報告書には法定の提出期限があり、提出期限延長のファイリング自体も追跡する価値のあるシグナルです。
• 市場データとの突き合わせ — 開示されたティッカーを Yahoo Finance や Google Finance のライブ株価と組み合わせて、開示された取引の背景を把握できます。

議会の開示情報をスクレイピングするのは合法か？

選択肢1: Python での自作スクレイパー（とそれが破綻する理由）

自作のスクレイパーは、互いに無関係な2つのシステムにアクセスし、自分で突き合わせる必要があります。

import requests
from bs4 import BeautifulSoup

# House Clerk: search returns an HTML results page, not JSON
house = requests.get(
    "https://disclosures-clerk.house.gov/PublicDisclosure/FinancialDisclosure",
    headers={"User-Agent": "Mozilla/5.0 (compatible; research-bot/1.0)"},
)
soup = BeautifulSoup(house.text, "html.parser")
# Each result links out to a separate PDF — no structured fields, no ticker

# Senate eFD requires a session/search form and returns its own HTML shape,
# entirely unrelated to the House Clerk's markup or fields

本当にエンジニアリングの時間がかかるのはここからです。

• 2つのポータル、2つのスキーマ。 下院書記官室と上院 eFD はそれぞれ独自の検索パラメータと結果のマークアップを持ち、共通の識別子もありません——欲しいフィールドはすべて院ごとに個別にマッピングし正規化する必要があります。
• ファイリング自体が PDF です。 検索結果は実際の開示情報の PDF を指しているだけで、個々の開示済み取引——ティッカー、取引種別、日付、金額レンジ——はその文書の中にあり検索結果には含まれないため、結局すべての PDF を取得してパースする必要があります。
• PDF のレイアウトはさまざまです。 ファイリングは議員、年、ファイリング種別を通じて固定のテンプレートではありません——定期取引報告書、年次報告書、ブラインドトラストのファイリングはそれぞれレイアウトが異なり、古いファイラーや提出件数の少ないファイラーの PDF はテキストではなくスキャン画像であることもあります。
• 両院を横断したティッカー単位の検索がありません。 どちらのポータルの検索機能も、「ティッカー X に関する下院・上院すべての開示済み取引」を1回のクエリで取得することはできません——広く取得した上で、すべての PDF をパースしてからクライアント側で絞り込む必要があります。

選択肢2: ノーコードツール

一部のダッシュボードやマーケットプレイスのスクレイパーが議会の取引データを提供していますが、そのほとんどは同じ2つのポータルを再スクレイピングし、フィールドの一部を再公開しているだけです。単発の調べものは省けますが、パースの問題は解決してくれません——結局は元の PDF から構造化された取引ごとのレコードは得られませんし、ほとんどのツールは提出期限延長やブラインドトラストのファイリング種別をそもそもカバーしていません。

選択肢3: 構造化された議会 API

Crawlora の議会株式取引開示 API は、下院書記官室と上院 eFD の両方を一つの検索形式に正規化し、個々のファイリングの PDF を構造化 JSON にパースします。議員名、ティッカー、日付範囲で検索できます。

curl "https://api.crawlora.net/api/v1/congress/stock-disclosures?chamber=house&last_name=pelosi&from=2025-01-01&to=2025-12-31" \
  -H "x-api-key: $CRAWLORA_API_KEY"

{
  "code": 200,
  "msg": "OK",
  "data": {
    "count": 4,
    "filings": [
      {
        "member": "Pelosi, Nancy",
        "office": "California, District 11",
        "chamber": "house",
        "filing_year": 2025,
        "filing_type": "periodic_transaction",
        "pdf_url": "https://disclosures-clerk.house.gov/public_disc/ptr-pdfs/2025/20025123.pdf"
      }
    ]
  }
}

続いて同じ方法で上院のファイリングを取得し、両方を Python でパースします。

import requests

h = {"x-api-key": "YOUR_API_KEY"}
base = "https://api.crawlora.net/api/v1/congress"

results = requests.get(f"{base}/stock-disclosures", headers=h, params={
    "chamber": "senate", "ticker": "AAPL", "election_year": 2024,
    "sort": "filing_year", "direction": "desc", "page": 1, "limit": 20,
}).json()["data"]["filings"]

pdf_url = results[0]["pdf_url"]
report = requests.get(f"{base}/report", headers=h, params={"url": pdf_url}).json()["data"]

stock-disclosures は chamber（house または senate）、member または個別の first_name/last_name、state、district、ticker、filer_type、election_year、そして from/to の日付範囲を受け付け、name・office・filing_year のいずれかで昇順・降順にソートでき、page と limit でページングできます。report はファイリングの pdf_url を受け取り、パース済みの開示情報を返します——実際のフィールドとスキーマはドキュメントで確認してください——手作業で開いて読む代わりに済みます。pdf_url をキーにファイリングごとに1行を保存し、スケジュールを組んで検索を再実行し、新たに提出された開示情報を捕捉しましょう。

収集できるもの

両院にわたる公開されている議会の財務開示データです。ファイリングの検索結果（議員名、役職／州／選挙区、院、ファイリング年、正規化されたファイリング種別、元文書の PDF URL）は議員、州、選挙区、ティッカー、ファイラー種別、選挙年で絞り込め、個々のファイリングの PDF からパースされたレポート内容も取得できます。ファイリング種別は年次報告書、定期取引報告書、提出期限延長、ブラインドトラスト、その他をカバーしており、定期取引報告書は報告期間内の個々の取引を開示するものです。

制約とよくある課題

• 2つのソースシステムを一つの形式に統合。 下院書記官室と上院 eFD はそれぞれ独立して公開しているため、正規化後であっても、通常のソース側の遅延や院ごとのフォーマットの違いが生じることを想定してください。
• レポートのパース精度は元の PDF に依存します。 レイアウトはファイリング種別やファイラーによって異なり、古いファイラーや提出件数の少ないファイラーの開示情報はテキストではなくスキャン画像であることがあります——パース品質は元文書自体の品質に左右されます。
• リアルタイムではありません。 これらは STOCK 法の下で法定の提出期限が定められた定期的なファイリングであり、ライブの取引フィードではありません——開示対象の取引と、それが実際に提出・公開されるタイミングの間には本質的なラグがあります。
• ティッカーのカバレッジはレポート種別によって異なります。 個々の保有情報の表示のされ方はファイリング種別によって異なります——検索だけに頼らず、ティッカー検索と report エンドポイントを組み合わせて元文書をパースしてください。
• 公開データのみであり、投資助言ではありません。 これは議員や候補者が法律上の義務としてすでに公開的に開示した内容を収集するものであり、取引のシグナルとして扱うことは決してなく、実際に提出された内容を超えて何かを推測する手段でもありません。

どこで使われるか

• 透明性ジャーナリズム — 開示された取引を委員会の担当分野、投票、立法活動と突き合わせて追跡できます。
• ウォッチドッグとコンプライアンスリサーチ — ファイリングの適時性を監視し、議員の委員会が監督するセクターでの開示情報にフラグを立てられます。
• 学術・政治リサーチ — 院、州、選挙サイクルごとの開示パターンを時系列で研究できます。
• 複数ソースをまたぐ金融リサーチ — 開示されたティッカーを Yahoo Finance や Google Finance のライブ株価と組み合わせられます。

出典

収集を始める

まずは無料でお試しください: 任意の公開 URL を無料ウェブスクレイパーに通すか、アンチボットチェッカーでサイトがボットをブロックするかどうかを確認できます。サインアップ不要です。

stock-disclosures の検索エンドポイントと report エンドポイントをプレイグラウンドで試し、API ドキュメントでスキーマを確認し、料金をご覧ください。議会の開示情報は、議員や候補者が公式に何を、いつ報告したかを教えてくれます。SEC EDGAR は上場企業向けに同じ開示駆動型のパターンをカバーしており、Yahoo Finance や Google Finance は開示されたティッカーにライブ株価と市場コンテキストを加えます。どちらか一方だけを読むのではなく、開示情報を市場データと組み合わせましょう。あわせてウェブスクレイピング API の選び方とウェブスクレイピングは合法かもご覧ください。