ITエンジニアの種籾(たねもみ)

IT技術とか株式投資とか。

EDINET API

2020年 09月 16日

目次

はじめに

EDINET で公開されている文書にアクセスするには

  • 閲覧サイトで文書を検索してダウンロード。主にブラウザ。
  • EDINET API で文書を把握して取得。HTTP クライアントであれば何でも良い。

の2つの方法があります。

株式投資のための情報収集ツール「どにち株」では、 毎週土曜日に、その週に登録された有報をダウンロードしたい と考えています。

それを機械化するにあたって、EDINET API を使いたいなと思い、仕様を調査しました。

本記事では調査した結果、EDINET API のポイントを整理しています。

EDINET API とは?

EDINET API は、プログラムを介して EDINET のデータベースから効率的にデータを取得できる API です。

EDINET API を使うと、下の図のように、

  • EDINET で公開してる文書の把握
  • EDINET で公開してる文書の取得

ができるようになります。

概要

どんな API があるのか?

  • 提出された書類を把握するための API (書類一覧 API)

    • 日付ごとに提出書類情報、書類情報修正情報等を把握
  • 提供された書類を取得するための API (書類取得 API)

    • リクエストパラメータにより取得する書類の種類を指定

詳細な仕様は EDINET で公開されているガイド「EDINET API 仕様書」を見てください。 ここからは、プログラムによる機械化を念頭にしたときの各 API のポイントを整理していきます。

書類一覧 API

API の例

下記が例で、出力も確認できます。

https://disclosure.edinet-fsa.go.jp/api/v1/documents.json?date=2020-09-16&type=2

当日の更新タイミング

当日分のデータは、「日本時間 8 時 30 分過ぎから、原則 1 分毎」で更新されます。 今日の日付をパラメータにセットしたときのことです。

レスポンスが変化する条件は

  1. 書類提出
  2. 財務局職員による書類情報修正
  3. 財務局職員による書類の不開示

です。

書類提出はわかりやすいですが、書類の情報修正と不開示はわかりにくいので、あとで整理します。

過去分の更新タイミング

過去分のデータは、「1日 1 回、日本時間 24 時過ぎ」に更新されます。 いくつか過去のを見てみると「0:03」あたりに更新されてるようなので、ほぼ 24 時と考えて良いです。

私は、毎週土曜日に今週分一式を取得しようと考えているので、1:00 以降に取得すれば問題なさそうです。

レスポンスが変化する条件は

  1. 縦覧の終了
  2. 書類の取下げ
  3. 財務局職員による書類情報修正
  4. 財務局職員による書類の不開示

です。

これもまた分かりづらいので、あとで整理します。

寄り道

ちょっと寄り道ですが、ガイドにレスポンスの情報のことをファイルという言葉で表現しています。 提出文書のことのファイルなのか、と混乱しやすいですが、API の結果が事前にファイルで作られていると想像できます。

EDINET API でレスポンスする内容は、アクセス権による変化もなく、すべての利用者に同じ情報を返せばよいです。 なので、データベースなどに情報を取りに行くのではなく、事前にバッチ処理でレスポンスの内容をファイルとして作成してあるのだと思います。

設計ミスでありがちな、「情報変化しないのに毎回 DB アクセスしちゃう」のをちゃんと考えて回避しているようです。 EDINET のシステムを作ったエンジニアの賢さが垣間見えました。

寄り道でした。

情報更新の内容

過去分の情報が更新されるということなので、しっかり整理しておきます。 私は、毎週土曜日に今週分一式を取得しようと考えているので、過去分が更新されるとやっかいだなと感じています。

ただし、重要なので最後にももう一度記述しますが、更新されるのは提出文書の属性情報だけであり、提出文書自体が更新されることはありません。 なので、それほど過去分が更新されることに対して悲観することはないです。

1. 縦覧の終了

文書ごとに縦覧期間が決まっており、縦覧終了になると書類一覧 API の結果も変化します。

参考までに、有報関連の縦覧期間は下記です。

縦覧書類 公衆縦覧期間
有価証券報告書 受理した日から5年を経過する日まで
四半期報告書 受理した日から3年を経過する日まで
半期報告書 受理した日から3年を経過する日まで

EDINET API 自体が、「5 年を経過したファイル日付のファイルは削除」という仕様です。 有価証券報告書も 5 年なので、縦覧期間終了と EDINET API の対応期間と同一なので、 縦覧期間終了と同時に API でそもそも情報さえもとれなくなります。

四半期報告書と半期報告書は 3 年なので、今回の更新にあたります。 3 年過ぎちゃうと、昨日まで情報とれてたのに、とれなくなるということになります。

では、本題の縦覧終了すると API のレスポンスがどうなるかです。 縦覧終了すると、連番及び書類管理番号以外が null(区分及びフラグは”0”)に更新されます。 提出者 EDINET コードが null、かつ取下区分が”0”となっている場合は、縦覧終了となった書類であると判断できます。

図式化すると以下のようなイメージです。

実行日 API の date パラメータ 取れる情報
2017/9/15 2017-09-15 情報1 = { 連番=N1, 書類管理番号=M1, 各種情報=XXX }
2020/9/16 2017-09-15 情報1 = { 連番=N1, 書類管理番号=M1, 各種情報=null や 0 }

2. 書類の取下げ

開示した書類は法令の規定により、取下げられることがあります。

それにもない、提出文書は、連番、書類管理番号、親書類管理番号及び取下区分以外が null(区分及びフラグは”0”)に更新されます。

取下区分は、取下書は”1”、取り下げられた書類は”2”、それ以外は”0”が出力されます。 なので、取り下げられることによって、取下区分は 0 から 2 に更新されます。 そして、取下げた日に取下げ文書として、取下区分が 1 の情報が追加 されます。

図式化すると以下のようなイメージです。 9/15 に情報2(文書 M2)により、情報1の文書が取下げられた場合です。

実行日 API の date パラメータ 取れる情報
2020/9/1 2017-09-01 情報1 = { 連番=N1, 書類管理番号=M1, 取下区分=0 }
2020/9/16 2017-09-01 情報1 = { 連番=N1, 書類管理番号=M1, 取下区分=2 }
2020/9/16 2017-09-15 情報2 = { 連番=N2, 書類管理番号=M2, 取下区分=1 }

3. 財務局職員による書類情報修正

提出後に入力誤り等の修正が必要となる場合があります。ただし、提出された書類自体は修正されないです。

修正される場合がある項目は次のとおりです。

  • ファンドコード
  • 府令コード
  • 様式コード
  • 書類種別コード
  • 期間(自) 期間(至)
  • 提出日時
  • 提出書類概要
  • 発行会社 EDINET コード
  • 対象 EDINET コード
  • 子会社 EDINET コード
  • 親書類管理番号

提出時にこれらの情報を提出社が入力ミスするってことでしょう。

更新のされかたは、これまでと違って特殊です。

誤りのあった登録済みの文書の書類一覧 API のレスポンスでは、書類情報修正区分が 2 に更新されます。 訂正した、例えば「様式コード」などの情報は更新されません。

訂正日の書類一覧 API で、更新された情報が取得できます。 その際の書類情報修正区分は 1 です。そして、正しい情報が入っています。

参考までに、書類情報修正区分は財務局職員が書類を修正した情報は”1”、修正された書類は”2”、それ以外は”0”が出力されます。

ややこしいですが、

  • 登録された日の情報は訂正後の情報には更新されず、訂正されたよというマークとして書類情報修正区分が 2 になる
  • 訂正した日の情報一覧に更新後の正しい情報が含まれる
  • 提出文書自体は変更されないので、文書 ID は同一

です。

図式化すると以下のようなイメージです。 9/15 に情報2(文書 M1 のまま)により、情報1の文書が訂正された場合です。

実行日 API の date パラメータ 取れる情報
2020/9/1 2017-09-01 情報1 = { 連番=N1, 書類管理番号=M1, 書類情報修正区分=0, 誤った情報 }
2020/9/16 2017-09-01 情報1 = { 連番=N1, 書類管理番号=M1, 書類情報修正区分=2, 誤った情報 }
2020/9/16 2017-09-15 情報2 = { 連番=N2, 書類管理番号=M1, 書類情報修正区分=1, 訂正済みの情報 }

この仕様を考慮すると、API の引数に指定する日付は文書の提出日でもなく、情報の登録日や更新日という解釈が正しそうです。 気になったので、「提出日」でガイドを grep すると以下が見つかりました。

磁気ディスク提出又は紙面提出で提出日が書類提出操作より過去になる場合、当該書類提出の情報は、書類提出操作日をファイル日付とする提出書類一覧に記載されます提出日をファイル日付とする提出書類一覧には記載されないので注意してください。

補足:「ファイル日付」という記述で混乱しますが、API のパラメータの日付と考えてください。(上の方で書いた「寄り道」を参照してください。)

4. 財務局職員による書類の不開示

提出書類は、開示後に、書類の全てまたは一部が不開示となることがあります。 また、不開示が解除される場合もあります。

「3. 財務局職員による書類情報修正」に似た仕様になっており、元の情報はそのままで、不開示や解除した日に情報が追加されます。

同じように開示不開示区分があり、以下の仕様です。

  • 財務局職員によって書類の不開示を開始した情報は”1” ※不開示した日に新しく生成される
  • 不開示とされている書類は”2” ※不開示した日に対象の情報にセットされる
  • 財務局職員によって書類の不開示を解除した情報は”3” ※解除した日に新しく生成される
  • それ以外は”0”が出力されます。 ※不開示 → 解除で通常に戻った場合も 0 でセットされる

図式化すると以下のようなイメージです。 9/11 に情報2(文書 M1 のまま)により、情報1の文書が不開示にされ、9/15 に解除された場合です。

実行日 API の date パラメータ 取れる情報
2020/9/1 2017-09-01 情報1 = { 連番=N1, 書類管理番号=M1, 開示不開示区分=0 }
2020/9/11 2017-09-01 情報1 = { 連番=N1, 書類管理番号=M1, 開示不開示区分=2 }
2020/9/11 2017-09-10 情報2 = { 連番=N2, 書類管理番号=M1, 開示不開示区分=1 }
2020/9/16 2017-09-01 情報1 = { 連番=N1, 書類管理番号=M1, 開示不開示区分=0 }
2020/9/16 2017-09-15 情報3 = { 連番=N3, 書類管理番号=M1, 開示不開示区分=3 }

情報更新への対策

ここまで、更新の中身と内容を整理してきました。 API の仕様が、使う側を考えて、よくできていることが理解できました。

縦覧期間の終了のケースを除いた他の更新パターン3つは、 過去の情報を更新した際には、操作日の書類一覧 API の結果に操作内容が含まれるようになっています。

なので、「過去の情報変わってないかな?」と過去の日付を指定して書類一覧 API を呼び出す必要がありません。

それぞれ、更新のための操作日に

  1. 書類の取下げ : 取下げ(取下区分=1)の情報が登録される
  2. 財務局職員による書類情報修正 : 訂正(書類情報修正区分=1)後の情報が登録される
  3. 財務局職員による書類の不開示 : 不開示(開示不開示区分=1)、解除(開示不開示区分=3)の情報が登録される

ようになっています。

これらを考えると、それぞれの更新情報に対するすべきことは以下です。

更新情報 すべき対処
2. 書類の取下げ情報 親書類管理番号で辿れる元の文書をなかったことにする
3. 書類情報修正情報 書類の情報を、訂正後の情報に書き換える
4. 書類の不開示情報(不開示) 書類管理番号で辿れる元の文書をなかったことにする
4.書類の不開示情報(解除) 書類管理番号で辿れる元の文書を復活させる

書類取得 API

API の例

下記が例です。

https://disclosure.edinet-fsa.go.jp//api/v1/documents/書類管理番号?type=2

type の設定内容は以下です。

typeの内容

レスポンス

PDF 以外は zip で、いい感じですね。

ファイルダウンロードで、シンプルなのでこれ以上ポイントなしです。

まとめ

EDINET API の仕様を調べて、機械化する場合のポイントを整理しました。

情報の更新があるので、書類一覧 PI は少し複雑です。 ですが、結局次の4パターンを気をつければ大丈夫です。

更新情報 すべき対処
2. 書類の取下げ情報 親書類管理番号で辿れる元の文書をなかったことにする
3. 書類情報修正情報 書類の情報を、訂正後の情報に書き換える
4. 書類の不開示情報(不開示) 書類管理番号で辿れる元の文書をなかったことにする
4.書類の不開示情報(解除) 書類管理番号で辿れる元の文書を復活させる

書類取得 API はファイルダウンロードだけなので、非常にシンプルで言うことなしです。

これで、株式投資のための情報収集ツール「どにち株」のダウンロードツールの EDINET 版の設計ができそうです。

広告