SEC 提出書類(10-K・10-Q・8-K・決算)でデューデリジェンスエージェントを作る

10-K を読むのはほとんど Ctrl+F だ。それを 50 社分やるとなると立派な仕事になる。退屈な 80% を SEC EDGAR への検索&抽出エージェントで置き換え、人間のアナリストにとって重要な 20% を残そう。
要点
- •アーキテクチャ:ティッカー検索 → SEC Filings Search(提出書類 + 決算 + 株式統計)→ 長い箇所には URL Extract → セクション単位の引用付きで LLM が回答。
- •コスト上限:SEC Filings Search は 1 回 120 credits(≈ $0.12)。典型的な 3 問の企業レビューで credit 約 $0.40 + LLM トークン約 $0.05。
- •エージェントが正しくできること:事実の参照(セグメント売上、資本的支出の推移、ガバナンス、前年比のリスクファクター変化)、役員報酬の要約、直近の 8-K イベント。
- •依然として人間が必要なこと:経営陣の質、マーケットポジショニング、案件固有の論点など、提出書類の文言の外にある判断。
なぜこれを自動化する価値があるか
上場企業に対する一次デューデリジェンスの読み込みは、ほとんどが機械的だ:最新の 10-K を取り、リスクファクターと MD&A を走り読みし、直近の 8-K を確認し、最新の決算説明会に目を通す。アソシエイトレベルのアナリストは 1 社あたり 2〜4 時間をこれに費やす。アウトプットが深い洞察になることはまれで — それは別のより上級の人物が後で推論する、構造化された事実パターンだ。
その「事実パターン」のステップこそ、小さなエージェントが引き受けられるものだ。SEC を検索し、該当箇所を抽出し、引用付きで要約する。推論は上級者が依然として行う — だが彼らは 4 時間の読み込みではなく 5 分の読み込みから始められる。
これが今、実用的になった理由は 3 つある:
- 提出書類に対するセマンティック検索のおかげで、200 ページを読む代わりに「セグメント売上はどう変化したか」と尋ねれば、正しい様式の正しい段落が返ってくる。
- ロングコンテキスト LLM は 10-K 1 本と 8-K を数本、作業メモリに保持し、ドキュメント横断の質問に答えられる。
- プロンプト中の引用規律により、アウトプットを数秒で検証可能にできる — まさにコンプライアンスやレビューのワークフローが要求するものだ。
アーキテクチャ
question + ticker
│
├─ /api/company/facts (2 credits)
│ ↳ confirm ticker, get CIK and sector
│
├─ /api/search/sec (120 credits)
│ ↳ semantic search across 10-K/10-Q/8-K/earnings/equity stats
│
├─ /api/extract (2 credits per URL)
│ ↳ pull full text of the top 3-5 most relevant filings
│
└─ Claude / GPT-4 with citation-required prompt
↳ "answer + [Form, Fiscal Period, Section]"質問 1 件あたりのコスト:API で約 130 credits(約 $0.13)+ LLM 約 $0.03。3 問の企業レビュー(財務の推移、リスクファクターの差分、直近の重要事象)で約 $0.45〜$0.60 に収まる。どんな妥当な請求レートでもアナリスト 1 時間と比べれば、計算は明らかだ。
元を取るシステムプロンプト
金融 RAG においてアウトプット品質を最も大きく左右する単一要因はシステムプロンプトだ。我々が使っているものはこれだ:
You are a financial research assistant for an investment team. You answer
questions about US public companies using SEC filings, earnings call
transcripts, and equity statistics retrieved by your tools.
Rules — non-negotiable:
1. Cite every numeric claim with: [Form, Fiscal Period, Section]. Example:
"Operating income rose 12% YoY to $4.1B [10-K FY2025, Item 7 MD&A]."
2. Quote numbers verbatim. Do not round, paraphrase, or convert. If a
filing says "$4,127M", do not say "$4.1B" unless the filing itself does.
3. If the answer requires content you have not extracted, say so:
"I could not retrieve the FY2024 10-K for the segment-level breakdown.
Please re-run with that filing in scope."
4. Do not infer from training-data knowledge. If your tools didn't return
it, you don't know it.
5. Default to the most recent fiscal period available. State the period
you used.
6. Format multi-figure answers as a small markdown table with one column
per fiscal period. Always end with a one-line "How I read this" summary.
Tone: precise, terse, no marketing language.ルール 1、2、4 の 3 つで、我々が計測してきた捏造問題の約 90% が解消される。ルール 3(上品に「分からない」と言う)こそ、自信たっぷりに数値をでっち上げるチャットボットとこれを分ける点だ。
エージェントがきれいに処理するサンプルクエリ
- 「Apple のサービス売上の推移を直近 5 会計年度で比較して」 → 該当する複数の 10-K から引き、MD&A への引用付きの表を返す。
- 「NVIDIA のリスクファクターは FY2023 と FY2025 の間で何が変わった?」 → ドキュメント横断の差分を取り、各様式の Item 1A を引用する。
- 「$TICKER の直近 4 件の 8-K を要約して」 → 8-K にフィルターしたセマンティック検索を行い、提出日順に並べる。
- 「Microsoft の CFO は直近の決算説明会で AI 資本的支出について何と言った?」 → トランスクリプトを検索し、該当する Q&A 箇所を抽出してそのまま引用する。
どこで限界が来るか — そして正しい人間への引き継ぎ
エージェントは予測可能な 3 箇所でつまずく:
- 経営陣の質に関する判断。提出書類は彼らが何をしたかは教えてくれるが、彼らに能力があるかは教えてくれない。エージェントに尋ねてはいけない。
- 提出書類の外にある業界比較。「この粗利益率は同業他社と比べてどうか」が問いなら、エージェントは検索された提出書類にあるものしか知らない。同業比較には別のデータセットを用意するか、企業ごとにエージェントを 1 回ずつ走らせて集計する必要がある。
- 将来見通しのコメント。提出書類には将来見通しに関する記述が含まれるが、特に指示しない限りモデルはそれを額面通りに扱う。プロンプトに追加する:「将来見通しの記述は明示的にフラグを立てること。ガイダンスを事実として提示しないこと」。
最小構成のビルド
リサーチエージェントの解説と同じ Claude のツール利用ループのパターンが当てはまる — 変わるのはツールとシステムプロンプトだけだ:
from anthropic import Anthropic
import requests
KEY = "pk_yourkey"
client = Anthropic()
def fetch_tool(path: str) -> dict:
return requests.get(f"https://www.apipick.com{path}/tool-schema").json()["claude"]
TOOLS = [
fetch_tool("/api/search/sec"),
fetch_tool("/api/extract"),
fetch_tool("/api/company/facts"),
]
def call_tool(block):
name_to_path = {
"sec_search": "/api/search/sec",
"extract_urls": "/api/extract",
"company_facts": "/api/company/facts",
}
path = name_to_path[block.name]
method = "GET" if block.name == "company_facts" else "POST"
if method == "GET":
resp = requests.get(
f"https://www.apipick.com{path}",
params=block.input,
headers={"x-api-key": KEY},
timeout=30,
)
else:
resp = requests.post(
f"https://www.apipick.com{path}",
json=block.input,
headers={"x-api-key": KEY},
timeout=30,
)
return {
"type": "tool_result",
"tool_use_id": block.id,
"content": resp.text,
"is_error": resp.status_code != 200,
}
def due_dil(question: str) -> str:
messages = [{"role": "user", "content": question}]
while True:
r = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=2048,
system=SYSTEM_PROMPT, # the one above
tools=TOOLS,
messages=messages,
)
messages.append({"role": "assistant", "content": r.content})
if r.stop_reason == "end_turn":
return "\n".join(b.text for b in r.content if b.type == "text")
if r.stop_reason == "tool_use":
results = [call_tool(b) for b in r.content if b.type == "tool_use"]
messages.append({"role": "user", "content": results})
print(due_dil("Compare Snowflake's product revenue YoY for the last 4 quarters."))次にどこへ持っていくか
- 反復レビュー用のテンプレート。エージェントを小さな CLI で包み、ティッカーを受け取って固定形式の markdown ブリーフを出力させる:「直近の 8-K」「セグメント売上の推移」「リスクファクターの差分」。同じエージェント、スクリプト化したプロンプト。
- ウォッチリストモード。毎朝ティッカーに対してエージェントを走らせ、今日の答えを昨日の答えと差分する。差分だけを浮かび上がらせる。朝のブリーフィングパターンと相性が良い。
- 特許と予測市場を組み合わせる。テック / バイオテック銘柄には、IP の変化にPatent Searchを、群衆が織り込む結果(例:薬剤承認の確率)にPrediction Marketsを重ねる。
このパターンは一般化する。SEC は我々が提供する中で最も密度が高く、最もスキーマに優しいコーパスだ — だがそのループ(「セマンティック検索 → URL 抽出 → 引用付きで回答」)は、あなたが気にかけるどんな構造化ドキュメントのコーパスにも当てはまる:法的提出書類、科学論文の抄録、特許クレーム。まずデューデリジェンスエージェントを作り、それからアーキテクチャを横展開しよう。
よくある質問
SEC インデックスの鮮度は?
提出書類は EDGAR に受理されてから数時間以内にインデックスされる。8-K(時間に敏感なもの — 重要事象、経営陣の交代、買収)については、これは通常、当日中ワークフローには十分速い。新しい 8-K を 1 時間以内に通知してほしい場合は、検索とは別に SEC の RSS フィードを組み合わせ、エージェントは検知ではなくコンテンツ分析にのみ使うこと。
決算説明会のトランスクリプトはカバーするか?
はい — SEC Filings Search のインデックスは、提出書類そのものに加えて米国の決算説明会トランスクリプトと株式統計(株価/出来高、時価総額の履歴)を含む。1 回のセマンティッククエリでこれらのどのソースからも引ける。
スケールでやる場合のコストレバーは?
3 つ。(1) SEC 検索に 120 credits を費やす前に、Company Facts(2 credits)で事前フィルターし、ティッカーが実在する上場企業かを確認する。(2) (ティッカー, 四半期) で検索結果をキャッシュする — 提出書類はスケジュールでしか更新されない。(3) 多数の狭い検索ではなく、質問あたり 1 回の広い検索を使う。エージェントは結果をまたいで統合するのが得意だ。
エージェントは米国外の提出書類を扱えるか?
SEC Filings Search は米国上場企業(10-K、10-Q、8-K)をカバーする。英国企業については UK Legal Search と Web Search を組み合わせる。その他の法域については、該当する各国規制当局のサイト(Companies House、SEDAR など)に対して Web Search + URL Extract にフォールバックする。
数値のハルシネーションを避けるには?
システムプロンプトに入れる 3 つのルールが最も効く。(1)「抽出したテキストから数値はそのまま引用する — 言い換えたり丸めたりしない」。(2)「常に提出書類の様式、会計期間、セクション参照を含める」。(3)「該当する提出書類が抽出されていない場合は明示的にそう言う — 学習データから推測しない」。この 3 つを合わせれば捏造のほとんどが消える。
この記事で使われている API
API Pick の CEO。AI エージェントと LLM ワークフロー向けの本番運用可能な API について執筆。