EDINET API vs EDINET DB — 金融庁APIを直接使う場合との違い
2026-02-21
目次
「有報のデータを取りたいならEDINET APIを直接叩けばいいのでは?」という疑問は当然あると思います。EDINET APIは金融庁が無料で公開しており、誰でも使えます。ただ、実際にやってみるとデータを取得してからが長い。EDINET DBはその「取得してから」の部分を丸ごと解決するために作りました。
EDINET APIとは
金融庁が運営するEDINET（Electronic Disclosure for Investors' NETwork）上の開示書類を、プログラムから取得できるREST APIです。2024年3月にv2へアップデートされ、APIキーが必須になりました。利用登録はEDINET公式サイトから無料で行えます。
主な機能は2つ。書類一覧の取得（日付指定）と、個別書類のダウンロードです。取得できる書類は有価証券報告書、四半期報告書、大量保有報告書など。有報の財務データを扱う場合は type=5 を指定すると、XBRLをCSV変換したデータが手に入ります。
公式ドキュメントには明記されていませんが、短時間に大量のリクエストを送るとレスポンスが返らなくなります。実測では1リクエストあたり3〜5秒の間隔が必要で、これを守らないと接続が切断されます。大量取得を前提としたバッチ処理では、この暗黙のレート制限がボトルネックになるでしょう。
EDINET APIを直接使う場合の課題
EDINET APIそのものはシンプルです。問題はAPIの先にあります。
1. 日付指定で1日ずつ取得する必要がある
書類一覧APIは日付パラメータが必須で、1回のリクエストで1日分しか取得できません。
# 書類一覧API（1日分）
GET https://api.edinet-fsa.go.jp/api/v2/documents.json
?date=2025-06-25
&type=2
&Subscription-Key=YOUR_API_KEY
3月決算企業の有報提出は6月中旬〜下旬に集中します。FY2024の有報を全て集めるには、5月〜9月頃までの約90日分をループで叩く必要があります。1リクエスト5秒としても、一覧取得だけで7〜8分。そこから個別のCSVを1件ずつダウンロードするので、3,000社分の有報を揃えるには数時間かかることになります。
2. XBRLの名寄せが必要
ここが最大の壁です。有報CSVには element_id と context_id と value の組み合わせが数千行並んでいます。「売上高」を取り出すだけでも、会計基準ごとに異なるelement_idを知っておく必要があります。
# JP GAAPの売上高
jpcrp_cor:NetSalesSummaryOfBusinessResults
# IFRSの売上高
jpcrp_cor:RevenueIFRSSummaryOfBusinessResults
# US GAAPの売上高
jpcrp_cor:RevenueUSGAAPSummaryOfBusinessResults
# IFRS企業の独自拡張（ソニーの場合）
jpcrp030000-asr_E01264:RevenueIFRSSummaryOfBusinessResults
# IFRS企業の独自拡張（日立の場合、プレフィックスが異なる）
jpcrp030000-asr_E01737:RevenueIFRSSummaryOfBusinessResults
24指標 × 3会計基準で、標準element_idだけでも72パターン。加えてIFRS企業の独自拡張IDは企業ごとにプレフィックスが変わるため、正規表現でのフォールバック処理まで組まないと全社カバーできません。EDINET DBの場合、約3,850社のうち99.6%で売上高が取得できているのは、この2層の名寄せ処理（標準マッピング + REGEXP フォールバック）を実装しているからです。詳しくはデータソースの解説をご覧ください。
3. context_idのフィルタリング
同じelement_idでも、連結と単体、当期と前期でcontext_idが異なります。見落とすと、連結の売上高を取りたかったのに単体の値を拾ってしまう、という事故が起きます。
| context_id | 意味 | 用途 |
|---|---|---|
CurrentYearDuration |
当期・連結 | 通常はこれを使う |
CurrentYearDuration_NonConsolidatedMember |
当期・単体 | 個別財務が必要な場合 |
Prior1YearDuration |
前期・連結 | 前年比較時 |
CurrentYearInstant |
当期末・連結 | BS項目（総資産等） |
CurrentYearInstant_NonConsolidatedMember |
当期末・単体 | 個別BS項目 |
PL項目は Duration（期間）、BS項目は Instant（時点）。これを間違えると値が取れないか、別の期の値を取得してしまいます。連結指標を取る場合は NonConsolidatedMember を除外するフィルタが必要です。
4. データの保存と更新
取得したCSVをどこに保存するか、差分更新をどう行うか。データベース設計も自前で必要になります。有報の提出は3月決算企業が6月に集中するため、その時期だけで3,000件以上のCSVをパースすることになります。
差分更新も一筋縄ではいきません。同じ企業が訂正報告書を提出した場合、既存データを上書きする必要があります。EDINETの書類一覧APIには「訂正」を示すフラグがありますが、どの書類を訂正しているかの紐付けは自前で実装しなければなりません。データベースのスキーマ設計、エラーハンドリング、ログ、リトライ処理まで含めると、パイプラインの保守コードは想像以上に膨らみます。
実装コストの見積もり
EDINET APIからデータパイプラインを一から構築する場合、経験のあるPythonエンジニアでも2〜4週間は見ておくのをおすすめします。
| 工程 | 目安 | 内容 |
|---|---|---|
| API調査・プロトタイプ | 2〜3日 | v2 API仕様の理解、認証、レート制限の把握 |
| CSV取得・パース | 2〜3日 | 日付ループ、ZIP展開、UTF-16タブ区切りの処理 |
| 名寄せロジック | 5〜7日 | element_idマッピング、IFRS/US GAAP対応、REGEXP フォールバック |
| DB設計・投入 | 2〜3日 | スキーマ設計、差分更新、訂正報告書の処理 |
| テスト・検証 | 3〜5日 | IR数値との突合、エッジケース対応（保険業、バイオ等） |
初期構築だけでなく、保守コストも無視できません。EDINETのAPI仕様は過去に変更実績があり（v1→v2で認証必須化）、XBRLタクソノミも年度で更新されます。データ品質の監視、エラー時のリトライ、スケジューラーの運用を含めると、月に数時間の保守作業が継続的に発生します。
EDINET DBが解決する問題
EDINET DBは、上記の課題を全て処理済みの状態でデータを提供しています。
| 課題 | EDINET API直接 | EDINET DB |
|---|---|---|
| データ取得 | 日付ループ + ZIP展開 + CSVパース | APIを1回叩くだけ |
| 名寄せ | element_idマッピングを自前実装 | 24指標が標準化済み |
| 会計基準差異 | JP GAAP/IFRS/US GAAPを個別対応 | 全基準を統一カラムで提供 |
| 企業数 | 取得した分だけ | 約3,800社を収録済み |
| 更新頻度 | 自前でスケジューリング | 毎朝8:00に自動更新 |
| AI連携 | 自前でデータ加工が必要 | MCP Serverで直接接続 |
コード比較
トヨタ自動車の売上高を取得する場合の違いを見てみましょう。
EDINET APIの場合（Python概要）
# 1. 書類一覧から有報のdocIDを探す（約90日分ループ）
# 5秒/リクエスト × 90日 = 約7.5分
for date in date_range("2025-06-01", "2025-08-31"):
res = requests.get(DOCUMENTS_URL,
params={"date": date, "type": 2,
"Subscription-Key": API_KEY})
time.sleep(5)
# 2. docIDでCSVをダウンロード（type=5でXBRL CSV）
res = requests.get(f"{DOC_URL}/{doc_id}?type=5&...")
# 3. ZIPを展開、UTF-16タブ区切りでパース
df = pd.read_csv(csv_path, sep="\t",
encoding="utf-16")
# 4. element_idで売上高を検索（3基準 + 企業独自拡張）
revenue_ids = [
"jpcrp_cor:NetSalesSummaryOfBusinessResults",
"jpcrp_cor:RevenueIFRSSummaryOfBusinessResults",
"jpcrp_cor:RevenueUSGAAPSummaryOfBusinessResults",
]
# 5. context_idフィルタ（NonConsolidated除外）
# 6. 値を数値に変換（カンマ除去、None処理）
# → 全体で200〜300行のコード
EDINET DB APIの場合
curl -H "X-API-Key: YOUR_KEY" \
"https://edinetdb.jp/api/v1/company/E02144/financials"
たった1行。レスポンスには売上高だけでなく、24指標の最大6年分が構造化されたJSONで返ってきます。ChatGPTやClaude.aiなどのAIチャットからMCPで直接接続すれば、「トヨタの売上推移を見せて」と聞くだけでAIがEDINET DBのデータベースにアクセスし、取得から分析・解釈まで行ってくれます。ローカルへのインストールは不要です。実際のMCP活用例はこちらの記事で紹介しています。
EDINET APIを直接使うべきケース
EDINET DBは万能ではありません。以下のケースではEDINET APIを直接使うのが正解です。
- テキストデータが必要な場合 — 事業リスク、MD&A、注記の全文テキストが必要なら、直接APIからXBRLを取得する必要があります。EDINET DBのAPIでは、これらのテキストデータは提供していません。有報テキストの読み方については有報の読み方ガイドも参考になるかと思います
- 四半期報告書が必要な場合 — EDINET DBは有報（年次報告書）のみが対象です。四半期決算の速報性が必要な分析には向きません
- 非上場企業の有報が必要な場合 — EDINET DBは上場企業約3,850社を収録。非上場の大企業（サントリー、竹中工務店など）の有報はEDINET APIから直接取得してください
- XBRLの生データが必要な研究用途 — タクソノミの変遷を追う研究やNLP分析など、構造化されたデータではなく生のXBRLが必要な場合
- 独自の名寄せロジックを組みたい場合 — EDINET DBの名寄せに含まれない独自指標（例: 特定業種のKPI）を取得するなら、自前で名寄せを実装する必要があります
逆に、上場企業のROEランキングを出したい、複数社の売上推移を比較したい、といった横断分析をやりたいなら、EDINET DBの方が圧倒的に手早いです。名寄せ済みのデータに1回APIを叩くだけでアクセスできます。
料金比較 — Build vs Buy
EDINET APIそのものは無料ですが、パイプラインの構築・保守にはエンジニアの工数がかかります。EDINET DBを使う場合との比較を整理しました。
| EDINET API（自前構築） | EDINET DB | |
|---|---|---|
| API利用料 | 無料 | Free: 100回/日、Pro: 月額制 |
| 初期構築コスト | 2〜4週間（エンジニア工数） | なし（APIキー発行のみ） |
| 保守コスト | 月数時間（API変更対応、監視） | なし |
| インフラ費用 | DB・スケジューラーの運用費 | なし |
| データ品質保証 | 自前でテスト・突合 | IR突合済み（上位20社で検証済み） |
少量の企業データを単発で取得したいだけなら、EDINET APIを直接叩くのが手軽です。一方で、数百社以上の横断分析を継続的に行うなら、パイプラインの構築・保守コストはFreeプランのAPI利用料を大きく上回ります。典型的なBuild vs Buyの判断になるでしょう。
始め方
EDINET DBのAPIは3ステップで使い始められます。現在はベータ期間中で、Pro相当のAPI/MCPが無料で利用可能です。