米下院議員の株式取引開示を毎朝モニタリングする仕組みを作った。Xの速報は約定ではなく開示PDFの転記だった

ペロシ氏が7月24日と7月28日に買った、という話は知っていた。なのに、開示が出たのは8月21日だった。

この2つの日付を並べた瞬間に、作ろうとしていたものの前提が崩れた。

きっかけは「今なにを持っているのか」

買った銘柄が開示に出るのは分かる。では、今のポートフォリオは開示に出るのか。

出ないなら、X検索で暫定的な保有を組んでおいて、そこに開示で分かるフローを積み上げていけばいい。そう考えて、定期モニタリングをmdx-playgroundのスラッシュコマンドとして組むつもりで、まず調査だけをClaude Codeに投げた。サブエージェントを適宜使うように、と添えた。

走らせたのは3本の並列調査だ。米下院書記官の公式開示を実機で叩く係、第三者の集約サイトとAPIとOSSを評価する係、そしてXで直近の購入と保有を拾う係を立てた。

24日の売買が、8月21日の開示で分かる理由

Xの係が最初に戻ってきた。 7月24日と7月28日のBloom Energy買い（株とコール）は、複数アカウントで一致して確認できた。開示は8月21日に提出され、8月24日にXで広まった。

ここで引っかかって、いったん調査を止めた。 24日と28日の売買を複数アカウントが確認できているのに、開示は8月21日。だとすると、そのアカウントたちは何を見て検知したのか。

答えは「誰も事前に検知していない」だった。 3つの日付は別々の出来事で、順番はこうなる。 7月24日と7月28日が約定で、8月21日がPTR（定期取引報告）の提出、8月24日がXでの拡散だった。速報アカウントは約定を掴んだのではなく、提出された開示PDFを読んで転記していた。

制度の側もそうできている。 PTRの提出期限は「取引を認知してから30日」と「取引日から45日」の早いほうで、延長はない。つまり、最長で45日遅れる。どのアカウントがどれだけ速く投稿しても、開示が出るまでは誰も知らない。

この一問で設計が決まった。監視の起点を約定日に置くわけにはいかない。提出日、つまり公式インデックスに新しい書類IDが載った日に置く。そしてXには速報を期待しない。

→ 米下院書記官の資産開示ポータル

PTR 1本に載っていた7件

ついでに、記憶の中の「ブルームバーグ・エナジー」はBloom Energy Corporation（BE）だと分かった。ブルームバーグとは何の関係もない。

該当のPTR（書類ID 20035143、2026年8月21日提出）には7件が載っていた。内訳は、BEの株15,000株と権利行使価格100ドルのコール200枚（どちらも7月24日と28日の2回に分かれる）、Intelの株10,000株と50ドルのコール50枚、そしてサンフランシスコのホテル再生LLCへの出資だ。所有者は7件とも配偶者だった。「ペロシ氏本人が買った」と書くと不正確になる。

同じ銘柄が株とオプションで別の行に立つ。行としてはどちらも正しい取引だが、金額はいずれも法定のレンジで、オプション側が指しているのはプレミアムだ。銘柄単位で足しても「BEをいくら買った」にはならないし、同じ銘柄への持ち高を二度読むことになる。台帳は最初から株とオプションを別レコードで持ち、銘柄単位の合計は出さない、と決めた。

第三者の係の報告は、ほとんどが「使えない」だった。 House Stock Watcherはサービス終了、OpenSecretsの個人資産は2018年で更新停止、Capitol TradesはBot検知でcurlもr.jina.aiも429、各社APIはキー必須だった。「現在の保有」を掲げているサイトを開くと、中身がコピー投資用に再構成した模倣ポートフォリオだったり、上限30%でキャップした仮想指数だったりする。そのまま引いたら誤報になる。

一方で、公式は拍子抜けするほど素直だった。認証もUser-Agentもいらず、素のcurlで年次インデックスのZIPが落ちてくる。 PDFはpdftotextにかけて正規表現で分解できる。試作パーサを47本のPDFに当てて、計681取引で取りこぼしも過検出もゼロだった。

生き残った第三者はUnusual Whalesだけで、これは正本ではなく照合相手として採った。 HTMLに埋まったJSONが公式PDFへの直リンク付きで、自前パーサの検算にちょうどいい。

Xの役割も書き換えた。速報性で公式に勝てない以上、残るのは2つだ。なぜ買ったと言われているかという文脈の取得と、自前の検知が見逃した書類IDが流れていないかを見る安全網である。

「持っている株数」は誰にも分からない

調査でいちばん効いたのは、フローとストックの非対称だった。

取引は1件ずつ開示されるが、金額はレンジでしか出ない。 100万1ドルから500万ドル、といった法定の区分に丸められる。だから取引をいくら積み上げても、株数の残高は復元できない。

確定値として持てるのは、年次報告のSchedule Aに載る前年12月31日時点の断面だけだ。そこで保有台帳は「年末の断面」と「その後に開示された増減」を並べる形にし、残高は計算しないと決めた。株数まで出しているトラッカー推定は、総額が1億3,500万ドルから4億1,300万ドルまで振れている。確定値と混ぜられない。

Codexのレビューが2回通らなかった

調査報告と設計案がまとまったところで、Codex（gpt-6-astra）にレビューさせた。 1回で通ると思っていたが、3回かかった。

1回目は「要修正」で、指摘は3件あった。

1月に提出されるPTRには前年12月の取引が混ざる。そのまま保有台帳へ入れると、年末断面と同じ売買が二重に重なる（実際、ある書類IDの18取引のうち11件が2025年12月分だった）
照合待ちの書類IDが残っているのに、翌日はSKIPしてしまう判定条件になっている
修正報告が提出されたときの経路がない

2回目でも1件残った。パースが終わって台帳に入れる前に止まった場合、翌日は照合済みとみなして台帳反映を飛ばす、という指摘だ。台帳反映と照合の状態を書類IDごとに独立して持つ形に直して、3回目でようやく致命的な問題なしになった。

残った指摘はどれも「途中で止まった翌日」と「訂正が来た日」の話だった。正常系だけを眺めていると設計から丸ごと抜ける類の穴で、自分ひとりでは気づけなかったと思う。

判断が要る4件は決裁フォームに出して選んだ。フローの正本をどこに置くか、保有台帳の初期値をどこから取るか、いつどこから実行するか、成果物をどこまで公開するか。 4件とも推奨案どおりにした。公式PDFを自前でパースし、保有は年次報告から自前で取り込み、毎朝のチェーンに組み込み、記録は非公開から始める。

実装は別セッションに切った

ここでセッションを切った。調査でコンテキストを使い切っており、実装はスクリプト4本にテストが付く長い作業になる。実装に必要な実物（PTR 6本と年次報告の抽出テキスト、インデックス2年分）は、memo配下に退避した。そのうえで引き継ぎプロンプトを出し、新しいセッションへ移った。

実装は3コミットに分けた。

Phase 1: 公式インデックスの条件付きGETと差分検知、PTRの構造化、台帳への冪等な追記。同じ書類IDを2回流しても件数が増えない。修正報告は自動反映せず止める
Phase 2: Unusual Whalesとの照合（PTR 6本の39取引が全件一致）、手順書 .claude/commands/pelosi-watch.md、毎朝のチェーンへの組み込み
Phase 3: 年次報告のSchedule Aから年末断面を作る。2025年末は上場株24銘柄とオプション7ポジション

Phase 3ではpdftotextの系統差に当たった。 Schedule Aは列が折り返すので、-layout では31行のうち13行しか取れない。 -table に替えると読める。ところが -table はxpdf系にしかなく、macOSのpopplerには無い。年に1回の年次突合だけはWindows機でやる、と手順書に書いて逃げた。

学習ゲートはスキップして、3コミットをmasterに入れた。

ほとんどの朝は1行で終わる

できあがったものは、毎朝1回動いて、たいていは何もしない。

新しいPTRは月に0〜1本しか出ない。公式インデックスの差分を見て新着がなければ、10秒以内に「SKIP」の1行で終わる。新着があった日だけ、PDFの構造化、台帳への反映、照合、Xでの文脈取得、記録の作成へ進む。

作る前は「毎朝ペロシ氏の取引を追うもの」を想像していた。実際に手元にあるのは、追わなくていい日を判定するものに近い。

今日の学び

「複数アカウントが確認している」と「事前に検知した」は別のことだ。日付が3つ並んでいたら、どれが約定でどれが開示でどれが拡散かを腑分けしてから設計に入る
公開データの監視は、データが生まれた日ではなく「生まれたことが分かる日」を起点にする
集約サイトの「現在の保有」は、その数字がどう作られたかを読むまで使わない。模倣ポートフォリオや仮想指数が「保有」の顔をして並んでいる
正常系だけの設計はレビューで必ず止まる。途中で止まった翌日と、訂正が届いた日を、自分でも先に置いてみる

#米下院開示#Claude Code#スラッシュコマンド#PDFパース#Codexレビュー#モニタリング