決算データをキレイに読み込むための『詳細なXBRLパーサー』の作り方です。
『XBRL（エックスビーアールエル）ファイル』に加えて、別途Webで公開されている『タクソノミファイル』を読み込むことで、上場企業の財務分析に役立つ詳細なデータを取得することができます。
『詳細なXBRLパーサー』では、XBRLインスタンスに加えて、
- マニフェスト (manifest)
- 各種スキーマ (schema、xsdファイル)
- プレゼンテーションリンク (presentationLink、表示リンク)
- デフィニションリンク (definitionLink、定義リンク)
- カルキュレーションリンク (calculationLink、計算リンク)
- ラベルリンク (labelLink、名称リンク)
- レファレンスリンク (referenceLink、参照リンク)
などを読み込みます。
そのパーサープログラムの作り方を紹介します。
概要部分を、単刀直入（たんとうちょくにゅう）に、天下り的（あまくだりてき）に書きます。
（コード例は 詳細なXBRLパーサーのコード例【Python】 に掲載しました）
プログラミング言語は、Python 3（パイソン）を使いました。
Pythonの開発には、Visual Studio Code（ビジュアルスタジオコード）を使いました。
XMLパーサーには、lxml.etree（エルエックスエムエル・イーツリー）を使いました。
OS（オーエス）は Windows 7 64bit です。
詳細なXBRLパーサーの開発には１か月かかりました。
ファイルが多岐にわたるぶん、作るところが多かったですが、個人でも開発可能ということがわかりました。
XBRLの読み込み方（XBRLのパース方法）
取り扱うXBRLは、『金融庁のEDINET（エディネット）』と、『東京証券取引所のTDnet（ティーディーネット）』で公開されているXBRLです。
これらのXBRLの読み込み方を紹介します。
マニフェスト ⇒ XBRLインスタンス ⇒ 発見可能なタクソノミ集合 (DTS)
ひとことで言うと、『マニフェスト (manifest)』を読み込んでから、『XBRLインスタンス（金額などが載っているファイル）』を読み込んで、スキーマ（拡張子がxsdのファイル）から『発見可能なタクソノミ集合 (DTS: Discoverable Taxonomy Set) 』を作る、という順番で読み込みました。
スリーステップです。
『マニフェスト』⇒『XBRLインスタンス』⇒『発見可能なタクソノミ集合 (DTS: Discoverable Taxonomy Set) 』の順番で読み込みました。
XBRLデータはお好みの形式にして活用する
ここまで読み込んだら、あとはお好みの形式（けいしき）に組み立てるだけです。
『XBRLインスタンス』と『発見可能なタクソノミ集合 (DTS)』を組み合わせて、必要な表に仕上げていきます。
XBRL ⇒ DTS で勘定科目の一覧を作る
『XBRLインスタンス』にある勘定科目のタグ名を『発見可能なタクソノミ集合 (DTS)』にわたせば、『勘定科目の日本語名、勘定科目の親子関係、本文中での登場位置』などが分かります。
これを利用して、勘定科目の集約や名寄せがしやすい便利な一覧を作ることができます。
読み込みの起点はマニフェストファイル
XBRLの読み込み方を簡潔にまとめると、『マニフェスト (manifest) ファイル』を起点（きてん）に読み込んで、内容を『XBRLデータ』と『DTSデータ』にまとめる、です。
マニフェストには、『XBRL』と『Inline XBRL（インラインXBRL、ix）』のありかが書かれていました。
『普通のXBRL』と『インラインXBRL』。
どちらを優先して読み込むのかは、マニフェストファイルを読み込むタイミングで判定しました。
最初に『普通のXBRL』のほうをさがして、それが無ければ、バラバラに分割されている『インラインXBRL』を読み込むようにしました。
マニフェストファイルを起点として、XBRLインスタンスを読み込み、発見可能なタクソノミ集合をつくる。
『詳細なXBRLパーサー』は、このような流れで作りました。
実際には様々な困難があった
さて、ここまでパーサー作りの大まかなところを書いてきましたが、実際の中身の開発はとても大変なものでした。その一部を紹介します。
どのような順番でファイルを読んだらいいのか？
もちろん、XBRLのzipから読み込むのですが、そこから先が難しかったです。
- バラバラに分割されたインラインXBRLを、どうやってまとめようか？
- マニフェストファイルが無いぞ…？
- マニフェストファイルに書かれているファイルが無いぞ…？
- マニフェストファイルは複数あるぞ…
- ２０１３年以前の初期のXBRLにも対応したいな…
マニフェストが複数あることについては、マニフェスト束ねるマニフェストが欲しいなって、少し思いました。
結論としては、zip内のフォルダごとにマニフェストファイルを探して、無ければそのフォルダにあった『普通のXBRL』を読み込む、みたいな感じになりました。それも無ければインラインXBRL。
６種類の拡張リンクの読み込みをどうやってまとめようか？
６種類の拡張リンクとは、『表示 (pre)・定義 (def)・計算 (cal)・ラベル (lab, lab-en)・ジェネリックラベル (gla)、参照 (ref)』の６種類のことです。
これらが載っているリンクベースファイルの構造は、どれもほとんど同じでした。
ですが、微妙にタグや名前空間が異なっていました。
どういう視点で見たら１つの関数で扱えるのか？
これをずいぶんと考えていました。
結論から言うと、タグを探すときに、『タグ名』で探すのではなくて、代わりにタグの『role属性』や『type属性』で検索するようにしたらOKでした。うまくまとまりました。
それでも最初は、６種類のPythonクラスを用意して、試行錯誤しながらまとめていました。
それはさながら、４つのちからの理論（電磁力・弱い力・強い力・重力）を統一しようという、大統一理論（だいとういつりろん）の構築の試みに似ているところが、少しあるような気がしました。
まとまりそうで、まとまらない、少しまとまってきた時は、辛そうで辛くない少し辛い桃屋のラー油を思い出しました。
ロケーター・リソース・アークの参照関係をどうやって解決しようか？
XBRLの仕様書を見ると、アーク (arc) でロケーター (locater) とロケーターをつなぐとか、ロケーターとリソース (resource) をつなぐとありました。
これは、XML（エックスエムエル）の仕様にある『エックスリンク (XLink, XML Linking Language) 』という仕組みとのことでした。
『ロケーターやリソースを、アークでつないでいく』というのは、まあ、言ってることは何となく分かったのですが、ではそれを、どうやってプログラムで表現したらいいのか？です。
これが難しかったです。
エックスリンクは、XBRLの仕組みの根幹（こんかん）を成す、最奥（さいおう）にして、ラスボス級の存在でした。
その複雑さたるや、htmlのアンカータグ <a href=”りんく”>こんにちは</a> の比ではなかったです。
アークでつなぐのに加えて、アークをはずすという処理も登場しました。
XBRLのそういった部分は、ファイルの書き方も１つではないようで、問題が出るたびに対応していきました。
XBRLパーサーの実装方法は、いくつもあるように思いました。
XBRLパーサーは個人でも書けた
XBRLは見るべきファイルが多くて大変でしたが、詳細なXBRLパーサーのプログラムは、個人でも書けることがわかりました。
開発に要した期間は、１か月でした。
EDINETとTDnetのXBRLをたくさん読み込んでみて、ほぼ止まらずにXBRL⇒CSV変換ができていたので、ひと区切りをつけました。
気がつけば、１か月もかかっていましたが、もし事前にXBRLパーサーの実装例や解説などがあれば、もっと短期間のうちに、もっと自身の目的にあったXBRLパーサーが書けたと思います。
詳細なXBRLパーサーのコード例【Python】を掲載しました。
以上です。
