EDINET は金融庁が運営する開示書類の電子開示システムで、その API は 有価証券報告書・四半期報告書・大量保有報告書などを機械的に取れるようにしたものだ。 株価を返す API ではない。企業が何を出したかを追うための経路になる。
日本株を扱う API として J-Quants と並べて検討されることがありますが、返すものが別です。J-Quants は株価・財務の数値を返し、EDINET は企業が提出した書類そのものを返します。「決算の数字が欲しい」だけなら EDINET は遠回りで、「有価証券報告書の本文を読ませたい」「大量保有報告書の提出を検知したい」なら EDINET でなければ取れません。
取得は 2 段構えになる
いきなり目的の書類を引くことはできない。まず提出日を指定して一覧を取り、 そこに含まれる書類 ID を使って本体を取りに行く、という 2 段階になる。
一覧は JSON で返るが、本体は XBRL の ZIP か PDF だ。 つまり JSON で完結するのは書類のメタデータだけで、 中身の数値を使いたいなら XBRL を解く工程が別に要る。 ここを見落とすと「API を叩けば決算数値が JSON で返ってくる」という前提で 設計してしまい、後から解析基盤を足すことになる。
引ける軸は「提出日」であって「決算期」ではない
一覧は日付で引く。ここが実務でいちばん効いてくる制約で、 「2026 年 3 月期の有価証券報告書を集めたい」と考えても、 その決算期を直接指定する引き方にはならない。 提出が集中する時期の日付を順に舐めて、 返ってきた一覧から目的の決算期・書類種別を選り分けることになる。
提出済みの書類は訂正されることがあり、訂正報告書は別の書類として改めて提出日に現れます。日付で舐めて集めると、同じ決算期の同じ会社について複数の書類が集まります。最新の内容だけを使いたいなら、提出者と対象期間で名寄せしたうえで、訂正の有無を見て採用する版を決める処理が要ります。これを入れていないと、古い数値と新しい数値が混ざったまま集計されます。
API キーの発行が要る。古い記事のコードは動かない
現行は Version 2 で、リクエストにサブスクリプションキーを付ける。
キーを付けずに叩くと 401 が返り、invalid subscription key という
メッセージだけが来る。登録と発行の窓口は EDINET のトップページに案内がある。
以前はキー無しで叩ける版が動いており、その前提で書かれた解説記事やサンプルが今も検索で上位に出ます。旧版のエンドポイントは現在 403 を返すため、そのまま写すと動きません。認証エラーなのかエンドポイント違いなのかで切り分けが変わるので、まず現行の仕様書でエンドポイントとキーの渡し方を確認してから書き始めてください。
大量に取りに行く設計にはなっていない
一覧はまとめて返るが、本体は 1 件ずつ取る形になる。 「全上場企業の有価証券報告書を一括で落とす」ような使い方を前提にした インターフェースではないので、日次で一覧を取り、前回からの差分だけ 本体を落とすという運用に寄せるのが素直だ。
過去分をまとめて取る必要がある場合も、一度に走らせるのではなく 日付を区切って回し、取得済みのものは書類 ID で持っておいて 再取得しない作りにしておきたい。
使う前に規約を確認する必要がある
EDINET で公開されている情報の利用条件は、EDINET のウェブサイト上で 提示されている。金融庁は EDINET のサイト以外では、有償・無償を問わず この情報の提供を行っていないと明記している。 取得した内容を自分のサービスに載せる、あるいは再配布する形を考えているなら、 着手する前に規約の本文を読んでおくこと。 このページでは可否を断定していない。