自称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)が、各コンテキストの値としてそれぞれ紐づいています。

むすびにかえて

ここまで読んでくれてありがとう！さあ、大量保有報告書を分析してみましょう。
大量保有報告書は株主からみた保有銘柄の情報ですが、データ化することで、銘柄からみた株主の情報も見ることができるようになります。
新しい発見があるかもしれません！！