ブログに戻る
engineeringdata

開発者のためのEDINET完全ガイド

Onkar Dahale

EDINETの英語の開発者ガイドは存在しません。公式ドキュメントは97ページの日本語PDF。Stack Overflowには質問が3つくらい。最良のリソースは、有価証券報告書が何か知っている前提のQiita記事です。

我々はAxioraをEDINETの上に構築したので、自分たちが最初に欲しかったガイドを書きました。日本の財務データを扱う開発者が知るべきことをすべてまとめています。

EDINETとは

EDINET（金融商品取引法に基づく有価証券報告書等の電子開示システム）は、日本の法定開示システムです。アメリカのSEC EDGARに相当しますが、APIは日付ベースのみ、ドキュメントは日本語のみ、XBRLタクソノミーは会計基準が1つではなく3つあります。

金融庁（FSA）が運営しています。日本のすべての上場企業 — さらに投資信託、REIT、公募で有価証券を発行するすべての主体 — がEDINETを通じて提出する義務があります。4,125社以上の上場企業の機械可読な財務データが、約10年分遡って公開されています。

データ自体は素晴らしい。それを取り出す開発体験はそうでもありません。

エコシステム: EDINET、TDnet、J-Quants

日本の金融データシステムは1つではなく3つあり、それぞれ役割が異なります。

日本の金融データエコシステム

EDINETには完全な法定書類があります。有価証券報告書（有報）、半期報告書、届出書。監査済みの財務諸表がXBRL形式で提出され、APIは無料です。決算期末の数週間〜数か月後に掲載されます。

TDnet（適時開示ネットワーク）はリアルタイム開示を扱います。決算短信、配当決定、M&A通知。トヨタが決算を発表すると、TDnetにはその日の午後に掲載されます。EDINETの詳細な法定書類は1か月後。TDnetのAPIは月額7万円です。

J-Quants APIはJPXの開発者向けサービス。株価と加工済み財務データをクリーンなJSONで提供。無料プランは12週間のデータ遅延があり、有料プランでリアルタイム。

AxioraはEDINETからデータを取得しています — 日本の企業財務の一次情報源です。

有報の中身

有価証券報告書は100-200ページ以上の文書で、以下を含みます：

  • 事業の概要 — セグメント、子会社、従業員
  • 事業の状況 — 経営者による分析（MD&A）
  • 事業等のリスク — リスク要因
  • 経理の状況 — 貸借対照表、損益計算書、キャッシュフロー計算書 — すべてXBRLタグ付き
  • コーポレート・ガバナンスの状況 — 取締役会構成、役員報酬
  • 監査報告書 — 独立監査人の意見

開発者にとって重要なのは、財務諸表のすべての数値がXBRLでエンコードされていること。これが機械可読性を実現すると同時に、データ抽出を困難にしています。

EDINET API

EDINET v2（2024年4月開始）は、すべての提出書類への無料のプログラムアクセスを提供しています。EDINETポータルで無料アカウントを作成するだけでAPIキーが取得できます。

curl "https://api.edinet-fsa.go.jp/api/v2/documents.json?date=2026-06-25&type=2" \
  -H "Ocp-Apim-Subscription-Key: YOUR_KEY"

6月25日に提出されたすべての書類が返ります。提出ピーク時の典型的な日には100-200件以上。

{
  "metadata": {
    "resultset": { "count": 142 },
    "status": "200"
  },
  "results": [
    {
      "docID": "S100ABCD",
      "edinetCode": "E02144",
      "secCode": "72030",
      "filerName": "トヨタ自動車株式会社",
      "docTypeCode": "120",
      "periodStart": "2024-04-01",
      "periodEnd": "2025-03-31",
      "xbrlFlag": "1"
    }
  ]
}

実際の書類をダウンロード: GET /documents/S100ABCD?type=1 はXBRLファイルを含むZIPを返します。

誰も教えてくれない問題

EDINET APIのフロー

EDINET APIは日付ベースのみです。企業検索はありません。GET /companies/7203/filingsというエンドポイントは存在しません。「トヨタの全提出書類を表示」という方法がないのです。

トヨタの有報を見つけるには：

  1. トヨタが3月決算で有報は6月頃に提出されることを知っている
  2. 6月の各日をクエリ: ?date=2026-06-01, ?date=2026-06-02…
  3. 各日の100件以上の結果からedinetCode: "E02144"をフィルタ
  4. 該当するZIPをダウンロード

全企業のデータベースを構築するには、すべての暦日を走査してすべての提出書類を処理する必要があります。5年分のバックフィルで約1,800回のAPIコールが必要 — XBRLのパースを始める前の段階で。

Axioraは30分ごとに自動でこれを行っています。

識別コード: 3つの体系、変換APIなし

識別子トヨタ発行元
EDINETコードE02144金融庁 — 提出者の識別
証券コード7203JPX — 画面に表示されるティッカー
ISINJP3633400001JASDEC — 国際標準

注意: EDINETのsecCodeは5桁（72030）を返します。末尾はチェックディジット。実際のティッカーは7203です。

これらの識別子間の変換APIはありません。EDINETコードリストのCSVをダウンロードして自分でマッピングテーブルを構築します。Axioraは内部でこのマッピングを維持し、APIでは両方のコードに対応しています。

XBRLパースが週末を台無しにする理由

ここが、我々が始める前に誰かに書いてほしかったセクションです。

XBRLは各財務値に機械可読なタグを付けます — 名前空間プレフィックスと概念名の組み合わせで。要素を見つけてテキストを取得。簡単ですね。

いいえ。「売上高」の要素名は、会計基準、業種、報告書のセクションによって変わります。単一のrevenueタグは存在しません。日本基準の製造業、サービス業、銀行、保険会社、米国基準、IFRSのそれぞれが、概念的に同じ数値に対して異なる要素名を使います。

XBRL要素のマッピング

1つのフィールドに6つ以上の要素。全財務指標で数百のXBRL要素を52の正規化フィールドにマッピングしています。コアフィールド（売上高、純利益、総資産、EPS、キャッシュフロー）は完全に取得済み。新しいフィールド（売上総利益、販管費、棚卸資産、設備投資、研究開発費など）は現在、過去データのバックフィルを進めています。

コンテキスト: バグの温床

すべてのXBRL値には報告期間と連結区分を示すcontextRefがあります。パースのバグのほとんどがここに潜んでいます。

一般的な提出書類には連結と個別（非連結）の両方の数値が含まれています：

  • CurrentYearDuration — 当期、連結、フロー項目
  • CurrentYearInstant — 期末時点、連結
  • CurrentYearInstant_NonConsolidatedMember — 個別

間違ったコンテキストをパースすると、グループではなく親会社単体の売上高を取得してしまいます。日本最大級の企業では、親会社単体と連結グループの差は数十兆円に達します。正しいコンテキスト解決には、期間、連結範囲、会計基準を同時に考慮する優先順位システムが必要です。

2つのフォーマット

古い提出書類は従来のXBRL（純粋なXML、10-50MB）。最近はインラインXBRL（iXBRL）— XBRLタグが埋め込まれたHTML（1-5MB）。

iXBRLには巧妙な罠があります。スケーリング属性です。HTMLに表示されるテキストは29,929,992ですが、scale="6"属性により10^6を掛ける必要があります — 実際の値は¥29,929,992,000,000。この属性を見落とすと、データベースのすべての数値が100万分の1になります。

最近の提出の約60%がiXBRL。パーサーは両方のフォーマットに対応する必要があります。

エンコーディングと数値の罠

古い提出書類はShift-JISエンコーディング。マイナスは△1,234（三角記号）、▲1,234（塗りつぶし三角）、(1,234)（括弧）、または通常のマイナス記号や全角マイナスで表現されます。全角カンマ，と半角カンマ,が混在。ダッシュ―はゼロ、null、「該当なし」のいずれかを意味し、提出企業次第。

これらの表現はすべて、どこかの企業が実際にそう提出したから存在します。20年かけて進化した政府の書類提出システムには、ゼロから設計するなら想定しないエッジケースが山積みです。

パイプライン

Axioraの処理パイプライン

EDINETの提出書類をAPIレスポンスに変換する流れ：

  1. EDINETを30分ごとにポーリング
  2. 有報のXBRL ZIPをダウンロード
  3. 従来のXBRLかiXBRLかを検出
  4. パース — 大きな従来XBRLはストリーミング、小さなiXBRLはフルDOMパース
  5. 要素名を52の正規化フィールドにタクソノミーでマッピング
  6. データベースにアップサート — 企業＋年度で競合解決
  7. REST APIで配信

数百行のパースコードが、1回のAPIコールになります。

import httpx

resp = httpx.get(
    "https://api.axiora.dev/v1/companies/7203/financials",
    headers={"Authorization": "Bearer ax_live_YOUR_KEY"},
)
data = resp.json()["data"][0]

print(f"売上高:   ¥{data['revenue']:,}")
print(f"純利益:   ¥{data['net_income']:,}")
print(f"総資産:   ¥{data['total_assets']:,}")
売上高:   ¥29,929,992,000,000
純利益:   ¥4,944,933,000,000
総資産:   ¥90,114,296,000,000

XBRLなし。ZIPファイルなし。タクソノミーマッピングなし。三角記号をマイナスに変換するコードなし。

EDINET vs. SEC EDGAR

EDGARを使ったことがある開発者にとって、EDINETは開発体験が一段下がる感覚です。

EDINETEDGAR
企業検索なしあり（名前、CIK、ティッカー）
全文検索なしあり
認証必要（無料キー）ほぼ不要
ドキュメント97ページの日本語PDF充実した英語ドキュメント
会計基準日本基準 + IFRS + 米国基準米国基準 + IFRS
データ品質優秀優秀

データの品質は同等 — どちらも法定の規制当局への提出書類です。違いは開発者インターフェースだけ。EDGARは開発者アクセスを念頭に構築されました。EDINETは規制遵守のために構築され、開発者アクセスは後から追加されました。

選択肢

自前で構築する。 無料ですが、最初のクリーンなデータポイントまでに2-4週間の工数を見込んでください。3つの会計基準と2つのフォーマットに対応するXBRLパーサー、313以上の要素のタクソノミーマッピング、Shift-JISトランスコーディング、日本語数値処理、毎日のEDINETポーリング、タクソノミー更新時のメンテナンス。我々はこれをやりました。だからAxioraを作ったのです。

EDINET APIを直接使う。 MD&Aのテキスト、リスク要因、監査意見など生の書類が必要な場合に適しています。数値はXBRL。パースは自分で。

Axioraのような構造化APIを使う。 同じEDINETのソースデータを、パース・正規化してJSONで配信。1回のAPIコール、XBRLの知識不要。

curl "https://api.axiora.dev/v1/companies/7203/financials?years=3" \
  -H "Authorization: Bearer your-key"

無料プラン。クレカ不要。APIキーを取得 →