Sec 13f

@pipeworx/sec-13f

SEC Form 13Fに基づく機関投資家の保有情報を、証券を起点に検索できます。ホスト型で、呼び出し側にキーは不要です。 差分は後付けではなく、ここでは中心的な機能です。manager_changes と security_flows を使えば、「何が変わったか」を直接確認できます。保有状況の静的なスナップショットはニュースレターではありません。重要なのは変化です。

Pipeworx の一部です。AI エージェントを1683以上のライブデータソースにつなぐMCPゲートウェイです。

ツール

• who_owns(security, limit?) — ある証券を保有するマネージャーを、保有額の大きい順に表示します。企業名、ティッカー（OpenFIGIを通じてリアルタイムに解決。詳しくは下記の「ティッカーの解決」を参照）、または9文字のCUSIPを指定できます。
• manager_portfolio(manager, limit?) — 1人のマネージャーが報告した全ポジションを、保有額の大きい順に表示します（対象は現在の四半期のみです。変化については manager_changes を参照してください）。
• manager_changes(manager, quarter?, compare_to?, limit?) — 2つの読み込み済み四半期間において、1人のマネージャーが新規に取得、全売却、買い増し、または一部売却したポジションを表示します。デフォルトでは、そのマネージャーの直近2つの読み込み済み四半期を対象にします。
• security_flows(security, limit?) — ある証券について、読み込み済みの四半期ごとのポジション総額と保有者数に加えて、直近2つの四半期間に買い付け、売却、買い増し、または一部売却したマネージャーを表示します。
• manager_profile(manager) — 集中度（ポートフォリオに占める上位5銘柄／上位10銘柄の割合）、直近2つの読み込み済み四半期間の売買回転率、上位ポジションを表示します。セクターエクスポージャーは含まれません。13Fには業種／セクターのフィールドがなく、このパックでそれを捏造することもないためです。
• holdings_coverage() — 読み込み済みのSEC公開期間と四半期、四半期ごとの届出件数／保有件数、および差分を計算できるだけのデータが読み込まれているか（can_diff_quarters）を表示します。

ティッカーの解決 — 意図的にCUSIP↔ティッカーの対応表はありません

13FではポジションがCUSIPで報告されます。データセット内にティッカー列はありません。CUSIP識別子はCUSIP Global Servicesの独占所有物であるため、このパックではCUSIP↔ティッカーの大規模な対応表を作成、キャッシュ、再配布しません（有料の標準規格に関するルールと同じ方針です）。代わりに、ティッカー形式の入力（例："NVDA"）を受け取ると、呼び出しごとにOpenFIGIの公開マッピングAPIを通じてリアルタイムに解決します。OpenFIGIはオープンライセンスのBloomberg FIGIであり、そこで得られた証券の正式名称を、すでに取り込んである自社保有データの issuer_name と照合します。候補の中では、総保有額が最も大きいものを優先します（実際に事業を営む企業の機関投資家による最小の保有額でも、テーマ型／レバレッジ型ETFの最大の保有額を大きく上回るためです）。この方法で照合したすべての応答では、matched_on: "ticker_via_openfigi" と、解決結果（resolved_via.cusip、.figi、.issuer_name）が必ず報告され、黙って処理されることはありません。この方法を使う前は、who_owns("NVDA") は issuer_name を ILIKE '%NVDA%' で照合し、「Direxion Daily NVDA Bull 2X ETF」を実際のNVIDIA CORPORATIONのポジションと同列に表示していました。これは機能不足ではなく、誤った回答を黙って返す問題でした。

プロキシではなくホスト型にしている理由

取り込みプログラムでローカルビルドを受け入れるのは、上流では答えられない質問を可能にする場合だけです。これはまさにそのケースです。SECは13Fをマネージャー単位で公開しており、その上に構築されたすべてのAPIも同じ構造です。 自社の edgar_institutional_holdings の説明にもあるとおり、「$TICKERを保有するファンドはどれか」に答えるには、約8,000の届出者それぞれに対して実行する必要があります。これはデータ構造の問題であり、レート制限の問題ではありません。上流のどのサービスでも解決できません。フラットテーブルに対するインデックス付きのクエリを1回実行することで、この構造を反転できます。

13Fで分からないこと

13Fは過剰に読み取られることが多いため、ここおよびすべての応答で明記しています。

• 米国上場株式のロングポジションのみです。 ショートポジション、現金、債券、米国以外の保有資産は規則により除外されます。「Xはどれだけ保有しているか」という問いに答えられるのは、この範囲内に限られます。
• 四半期ごとの報告で、提出も遅れます。 期間終了後、最大45日以内に提出されます。これは遅れた時点のスナップショットであり、現在のポジションではありません。
• 1億ドルの基準額があります。 この基準額を下回る運用会社は報告を提出しないため、データがないことは証拠になりません。
• ティッカー列はありません。 記録上の識別子はCUSIPのみです。発行体名は提出者が入力したとおりです（「NVIDIA CORP」）。ティッカー検索は発行体名との照合にフォールバックし、そのことをmatched_onに示します。

数値に影響する重要な点

単一の運用会社が、異なる投資裁量によるものや、普通株式と併せたプットやコールなど、同じ証券を複数の行で報告することがあります。who_ownsは、順位付けの前に運用会社ごとに行を集約します。これをしないと、最大の保有者ではなく最大の行が得られます。見た目は同じように妥当ですが、別のリストです。

データと更新

ソース：https://www.sec.gov/data-research/sec-markets-data/form-13f-data-sets — 7つのTSVを含む、直近3か月分のZIPです。そのうち3つを使用します：SUBMISSION（アクセッション番号 → CIK）、COVERPAGE（アクセッション番号 → 運用会社）、INFOTABLE（保有情報。リリースあたり約380万行、非圧縮時396MB）。

ファイル名には対象期間が含まれます（01mar2026-31may2026_form13f.zip）。この名前は導出できません。リリースは暦上の四半期に合わせて公開されるわけではありません。ワーカー設定とスクリプトのどちらも、SECのインデックスページを参照して最新のリンクを取得します。四半期をハードコードすると、一度取り込んだ後は古いデータを永久に提供することになります。

• 通常のパス：workers/data-pipeline（sec-13f-submissions、sec-13f-managers、sec-13f-holdings）。
• 過去データの一括取り込み／復旧（Supabaseサービスキーまたはリンク済みのsupabase CLIが必要です）： node scripts/ingest-sec-13f.mjs --only holdings。
• ゲートウェイの管理者ルート経由で過去データを一括取り込み（必要なのはPIPEWORX_INTERNAL_SECRETのみです。すべてのフリートセッションがすでに持っている認証情報で、生のDBキーは不要です）：node scripts/ingest-sec-13f-admin.mjs --url https://www.sec.gov/files/structureddata/data/form-13f-data-sets/<window>_form13f.zip。ゲートウェイのPOST /admin/sec13f_load経由で送信します（許可リストに登録されたテーブルのみ、1回の呼び出しにつき最大3,000行。このホスト型データ取り込みで共通の上限です）。第2四半期のデータ（フリート #339。manager_changes／security_flowsで実際に差分を確認するために必要でした）はこの方法で取り込みました。
• 鮮度：shared/src/freshness.tsに200日のSLAで登録されています。リリース間隔に約45日の提出遅延を加味しているため、リリースを見逃した場合は四半期以内に検知されます。

スキーマとインデックス：supabase/migrations/061_sec_13f.sql。(cusip, value_usd DESC)インデックスが逆引きを実用的にしています。これがないと、380万行のシーケンシャルスキャンになり、置き換え前のAPIより構築に時間がかかります。

複数四半期の一括取り込み — 処理量、再開、深さによる劣化

2026-09-04に四半期3～8を読み込んで測定しました（フリート #1245。manager_changes／security_flowsで実際の傾向を表示できるよう、2四半期から8四半期に拡張）：

• 管理者ルート経由で約870行/秒のため、1四半期分の約280万～380万件の保有明細行の処理には、数分ではなく約1～2時間かかります。8四半期分の所要時間もそれに応じて見積もってください。
• **ローダーは再開可能であり、全件成功か全件失敗かのどちらかではありません。**すべての書き込みで、テーブルの実際の一意な ID（保有明細は infotable_sk、運用会社／提出情報は accession_number）をキーに Prefer: resolution=merge-duplicates を使用しており、scripts/ingest-sec-13f-admin.mjs にはこの用途の --skip-rows N が用意されています。四半期の途中で読み込みが停止した場合、削除して再読み込みしてはいけません。正確な確定件数（pg_class.reltuples ではなく count(*)。pg_class.reltuples は次の autovacuum まで古いままです）を取得し、読み込み前の基準件数を差し引いて、--skip-rows <delta> で再開してください。バッチは POST ごとにアトミック（最大3,000行）なので、差分は必ずバッチサイズの整数倍になり、不完全な行の破損を後から修復する必要はありません。**後で停止する可能性のある Monitor／ログ監視を付けずに、このローダーを実行しないでください。**ハーネスでは、Monitor と run_in_background ローダーが同じプロセスグループを共有することがあります。そのため、Monitor に TaskStop を実行すると、エラー出力がまったくないまま、同じグループ内のローダーまで終了することがあります。ログは行の途中で止まるだけです。そうなると無言のクラッシュとまったく同じように見えるため、DB 側の障害と判断する前に確認してください。
• **sec.gov はフリート全体で同じ外向き IP を共有しており、IP 単位でレート制限を行います。**このローダーの ZIP 取得中に、別のレーンで SEC の一括取得（Form 4／インサイダー、EDGAR 全文、XBRL）を実行したところ、SEC の Akamai フロントエンドから 429 が返され、延長可能な10分間のタイムアウトが発生しました。一括で sec.gov から取得を始める前に調整してください。CLAUDE.md の Cross-Project Rules を参照してください。
• データの深さが増えると、ILIKE／ティッカーパスでの who_owns は遅くなります。問題はインデックスではなくヒープです。resolveTicker() の issuer_name ILIKE '%name%' ORDER BY value_usd DESC LIMIT 50（CUSIP 検索の前に、通常のティッカー呼び出しのたびに実行されます）は、sec_13f_holdings_issuer_trgm_idx GIN トライグラムインデックスを実際に使用しています。約1,010万行／1.8GB のヒープに対する EXPLAIN (ANALYZE, BUFFERS) では、インデックス処理は87msでした。5.27秒のコールド実行時間のうち、残りの5.16秒は、照合された約2.8万行のテーブルページを取得するBitmap Heap Scanに費やされていました。その大半は Supabase の512MBの shared_buffers に常駐していません。同じ条件で再実行したウォーム実行は107msでした。このコストはインデックスで処理できる内容ではなく、テーブルサイズに応じて増加します。8四半期分（約9.7GBのヒープ）では、四半期3で計測した約5～20秒を超えるコールドティッカー検索時間が見込まれ、今後四半期が追加されるたびに増え続けます。リゾルバーテーブルによる対応（ティッカー→CUSIP をキャッシュし、resolveTicker() のスキャンをコールド呼び出しごとではなく、銘柄ごとに一度だけ実行する）は、このバックフィルを妨げないよう別途追跡しています。 (解決済み：マイグレーション154でリゾルバーテーブルを構築し、8,510msから2.1msになりました。)
• who_owns は DB 内で合計を計算します。その理由は特定のクエリプランではなく、COUNT の往復処理です（フリート #1254、マイグレーション156）。最初に2つのクエリプラン修正が入りました。上記の154と、windowQuarterMap を対象とした155です。しかし、どちらも who_owns の速度を改善せず、メガキャップ銘柄では28～30秒のままでした。実際のボトルネックは次のとおりです。最新の期間における MSFT の保有明細行は10,729件、accession は6,801件であるため、1回の呼び出しでPostgREST リクエストが103回、順次実行されていました。まず Range ページが11回、その後、提出情報と運用会社を結合するために150件ずつ46回ずつのチャンクが実行され、運用会社25件が返されていました。修正として sec_13f_who_owns() を追加し、期間の絞り込み、修正提出の重複排除、運用会社の結合、グループ化をサーバー側で1回のリクエストで行います。MSFT は29.81秒から11.75秒に、AAPL は27.78秒から9.68秒になり、すべての運用会社の合計値は変わりませんでした。 意図的に取得件数を減らしているわけではありません。上記の分割行に関する注記を参照してください。行数を制限すると #427 のバグが発生し、運用会社自身の合計値が気づかないうちに小さくなります。node scripts/sec13f-who-owns-bench.mjs before|after|--diff で検証してください。このベンチマークは、処理時間だけでなく、運用会社の合計値に変更があった場合にも失敗します。 応答には aggregated_in_db が含まれます。これが false の場合、RPC が 404 になったため、パックは従来の103往復の処理にフォールバックしています。つまり、マイグレーション156より先にデプロイされています。これは正しい動作ですが遅いため、遅い who_owns を一から再調査する前に、まず確認すべき点です。

クイックスタート

MCP クライアント（Claude Desktop、Cursor、Windsurf など）に追加します：

{
  "mcpServers": {
    "sec-13f": {
      "url": "https://gateway.pipeworx.io/sec-13f/mcp"
    }
  }
}

このエンドポイントが実際に提供するもの

https://gateway.pipeworx.io/sec-13f/mcp の tools/list は、上の表にあるツールに加えて、共有 Pipeworx メタツールの ask_pipeworx、discover_tools、search_within、remember／recall およびその他のゲートウェイ全体で使えるツールを返します。そのため、表示されるツール数はこの表より多くなります。現在、単一パックのエンドポイントには、パック独自のツールとともに、約 30 個の共有ツールが一覧表示されます。接続の initialize 応答には正確な範囲が記載されており、その日の状況を確認する際の正式な情報源となります。

これは意図的な設計であり、偶然に多重化されているわけではありません。メタツールを使うと、このパックで扱えない質問にも、カタログ全体を対象にルーティングする ask_pipeworx を介して回答できます。MCP サーバーを 2 つ目に追加する必要はありません。現時点では、メタツールなしでパックのエンドポイントをマウントする方法はありません。追加のスキーマによるコンテキストのコストがルーティングのメリットを上回る場合は、複数のパックエンドポイントではなく、フルゲートウェイに一度だけ接続してください。

または、Pipeworx のフルゲートウェイに接続すると、このパックだけでなく、各パックのすべてのツールが直接一覧表示されます：

{
  "mcpServers": {
    "pipeworx": {
      "url": "https://gateway.pipeworx.io/mcp"
    }
  }
}

どちらの URL も同じゲートウェイと同じ 1683+ 個のデータソースに接続します。違いは、どのパックのツールが直接一覧表示されるかだけです。どちらからも ask_pipeworx を使ってすべてのツールにアクセスできます。

MCP クライアントをお持ちでない場合：HTTP 経由で呼び出す

curl -X POST https://gateway.pipeworx.io/v1/tools/who_owns \
  -H 'Content-Type: application/json' \
  -d '{"security":"NVIDIA","limit":25}'

最初の呼び出しにアカウントは必要ありません。任意のツールを確認するには、GET https://gateway.pipeworx.io/v1/tools/who_owns を実行します。ツールを探すには、{"query":"..."} を指定して POST https://gateway.pipeworx.io/v1/tools/search_packs を実行します。

スタンドアロン（ゲートウェイアカウント不要）

このパッケージは、ローカルの stdio MCP サーバーとしても動作します。Pipeworx アカウントもゲートウェイ経由の往復も不要です：

{
  "mcpServers": {
    "sec-13f": {
      "command": "npx",
      "args": ["-y", "@pipeworx/mcp-sec-13f"]
    }
  }
}

または、直接実行して起動を確認できます：

npx -y @pipeworx/mcp-sec-13f

stdin/stdout 経由で MCP 通信を行い、このパックのツールのみを対象に initialize／tools/list／tools/call に応答します。上記のゲートウェイ接続で追加される共有メタツールは含まれません。同じソース、同じツールですが、ask_pipeworx によるルーティングはありません。

ask_pipeworx を使う

ツールを直接呼び出す代わりに、自然な英語で質問できます。これは上記のパックエンドポイントでも、フルゲートウェイでも利用できます：

ask_pipeworx({ question: "your question about Sec 13f data" })

ゲートウェイが適切なツールを選び、引数を自動的に入力します。

詳細情報

• ドキュメントとガイド
• pipeworx.io

ライセンス

MIT