自称XBRL系ダクトテーププログラマ、ぱにです。よろしくお願いします。
あやぱにというサイトの開発・運営をしています。
あやぱには、EDINETから取得した大量保有報告書をデータ化して閲覧・検索できるようにしたサービスです。あやぱにの開発を経験して学んだ（ハマった）こと、考慮したことなどを共有したいと思います。
というか、自分のための備忘録であります。
対象読者
大量保有報告書に興味がある人。EDINETと聞いてピンときた人。XBRLの基本的な知識があり、活用方法を知りたい人。
このページに書かないこと
具体的なプログラムは出しません。あやぱには Azure/C# で開発・運営していますが、そっち方面の説明はしません。設計レベルの話ばかりです。
データ取得(API)編
XBRLをEDINETからとってきますが、これがなぜか単純にはいかないんだなぁ。
過去分は5年まで
大量保有報告書は、EDINETで開示から5年間閲覧可能。APIで取得可能な期間も同じです。
それより古いものが欲しければ、、、有報キャッチャーなどから取得するしかないかな。
対応
- 取得したデータ(XBRL)は捨てない。再取得は手間も時間もかかるし、いずれ取得できなくなる。
APIは403エラーをすぐに返す
EDINETは2023年1月からリニューアルされました。APIも同じ仕様のままアップデートされた模様で、それ以降なぜか「403 Forbidden」エラーが頻発するようになりました。（個人の感想です）
対応
- APIは連打しないこと。少なくとも数秒程度間隔をあける。並列処理なんてもってのほか。
- 403エラーは必ず拾って、ちょっと（最低数秒程度）待って、リトライする。最初からやり直ししてたら終わらない。
- 取得したデータを捨てない。（大事なことなので2回目）
書類一覧のキーは書類管理番号ではない
これはAPIからデータを集めてデータベース化してから気づいたのですが、APIで取得した書類一覧のユニークキーは「連番」です。書類管理番号ではありません。
同じ書類管理番号が日をまたいで出現することもありますし、同日に複数回出現することもあります。
対応
- 書類一覧APIは日付をパラメータに渡すので、RDBに１書類１レコードで格納する場合、ユニークキーは「日付」「連番」の組み合わせにする。
書類は取り下げられる（一度開示された書類が非開示になる）ケースがある
withdrawalStatus(取り下げ区分)が"1"または"2"の書類は、その時点（書類一覧APIを呼び出した時点）でEDINET閲覧サイトでは開示されていないものです。取り下げデータの扱いをあらかじめ決めておこう。
大量保有報告書XBRL解析編
XBRLからほしい情報を取り出します。XBRLを必要以上に難しく考えるのはやめましょう。XBRLインスタンスからほしい要素名を指定して取ってくる、それだけでいいんです。XBRLを処理するためのライブラリなんていらない、シンプルで高速なXMLパーサを使えばいい。名前空間？なにそれ、おいしいの？
ほしい情報の要素名を探す
タクソノミ要素リストから探せます。
大量保有報告書に関連するのはシート1, シート29-32 です。
大量保有報告書は原則拡張しないので、想定外の要素が出現することはありません。
あやぱにが使用している主な要素は以下の通りです。
| 要素名 | 日本語 |
|---|---|
| NameOfIssuer | 発行者の名称 |
| SecurityCodeOfIssuer | 発行者の証券コード |
| StockListing | 上場金融商品取引所 |
| IndividualOrCorporation | 個人・法人の別 |
| Name | 氏名又は名称 |
| PurposeOfHolding | 保有目的 |
| TotalNumberOfStocksEtcHeld | 保有株券等の数（総数） |
| HoldingRatioOfShareCertificatesEtc | 株券等保有割合 |
| HoldingRatioOfShareCertificatesEtcPerLastReport | 直前の報告書に記載された株券等保有割合 |
| TotalAmountOfFundingForAcquisition | 取得資金合計 |
データの取得はXBRLインスタンスからが簡単
大量保有報告書はInlineXBRLという仕様で作成されたHTMLと、そのHTMLから作成されたXBRLインスタンス（拡張子が .xbrl のファイル）が同封されています。
HTMLファイルは複数ファイルに分かれていますが、XBRLインスタンスは1つです。HTMLの余計な情報がそぎ落ちてデータだけの状態になっているので、XBRLインスタンスからデータを取得したほうが簡単です。
XBRLインスタンスから値を取得する場合は、名前空間は気にせず要素名だけで参照して問題ありません。
コンテキストについて
大量保有報告書では、コンテキストは「FilingDateInstant」と「FilingDateInstant_(ほにゃらら)Holder(数字)Member」というのがあります。
「FilingDateInstant」は書類で１つの値、もしくは共同保有者の合計としての値のコンテキストです。例えば、発行者の名称(NameOfIssuer)なんかはこのコンテキストです。
対して「FilingDateInstant_(ほにゃらら)Holder(数字)Member」は、保有者の個々を示すコンテキストです。複数名の連名で大量保有報告書が出される場合がありますが、各人の保有割合(HoldingRatioOfShareCertificatesEtc)が、各コンテキストの値としてそれぞれ紐づいています。
むすびにかえて
ここまで読んでくれてありがとう！さあ、大量保有報告書を分析してみましょう。
大量保有報告書は株主からみた保有銘柄の情報ですが、データ化することで、銘柄からみた株主の情報も見ることができるようになります。
新しい発見があるかもしれません！！