XBRLをC#で必死に紐解こうとしている（悪戦苦闘メモ）

途中なので、間違いとか乱文とかは許してほしいです。

現在、XBRLにプログラムからアクセスして、データを取得できるか模索中です。

注意点

筆者は、XMLの知識に乏しいです。リンク（Xlink:arcrole）とか意味不明です
XBRLの仕様書は都度参照していますが、難しくて泣きそうです
すごく遠回りしています
XBRLとは何なのか、の説明は省きます（つらい）

目的

EDINETから取得できるXBRL一式（圧縮されている）から、財務諸表等を再現する

環境

開発マシン
Microsoft Surface Pro4 (CPU：Core i5、RAM：8GB）
開発環境
Visual Studio 2015 Community Edition
開発言語
C#
データベース
現時点では利用無し。必要になったらSQLite辺りを使う予定
その他
随時、テキストエディタ等を利用。XMLを見る場合は、Visuai Studio CodeやEmEditor（Free版）を利用

参考リンク

いきなり（笑）

2017年版EDINETタクソノミの公表について：金融庁

※これを必死に読み解いています。

TeCA Web XBRL for Everybody!

※最終手段

使用ライブラリ

とにかく楽したいので、NuGetで探したところ、三つヒットしました。
利用者が多い二つを利用してみました。

作成者様、感謝しております。（外国の方みたいなので、通じないでしょうが）

ただし、結論を先に言うと、私の甘々な検証の結果、「これだけではどうにもならない」ことがわかっています。

Diwen.Xbrl

Githubはこちら。

GitHub - dgm9704/Xoxo: reading, writing and comparing XBRL

インスタンスをロードして、中身を追えます。
なにやら、要素の比較等もやってくれます。
タクソノミに関してはロードしてくれるものの、拡張リンクロール等の紐づけはやってくれません。
→つまり、XBRLのデータから勘定科目や計算方法を割り出すのは自力でやる、ということになります。

Gepsio

JeffFerguson.Gepsio.dllというものを使用しています。

Githubはこちら。

GitHub - JeffFerguson/gepsio: Gepsio is a .NET-based document object model for XBRL documents.

後述するかもしれませんが、インスタンスをロード（XbrlDocument.Load）するだけで、タクソノミも全部ロードしてくれるので、楽です。ローカルに無いものも、Webから（名前空間を参照して）取ってきてくれます。
ただ、高機能故か、読込はかなり遅いです。
（その代わりすごく高機能）

XBRLの要素

たぶん、実際にXBRLを読んでみないと実感できないと思いますが、一応重要そうな部分だけ書きます。
（普通、企業は自力でXBRL作ってないでしょう。変換ツールや会計ソフト使うはず）

インスタンスとタクソノミ

インスタンスは、データです。（すごく雑）
xml形式で、拡張子は.xbrlとなっているようです。
期間や、ある勘定科目の金額等、表示する要素のデータを保持します。

タクソノミは、インスタンスが保持しているデータの表現方法です。
例えば、計算順序、名称、表示方法等です。
日本では、金融庁が定義していますが、拡張もできるという素敵仕様です。（固定されていない）

インスタンスにあるデータを、何らかの方法でタクソノミと紐づけていくと、あら不思議、財務諸表とかが出来上がる、という仕組みです。

XBRLの仕様自体は、国際的に決まっています。
ただ、タクソノミの中身は、拡張性が高いが故に、国によって全く異なるようです。

コンテキスト

<xbrli:context id="Prior1QuarterInstant">
<xbrli:entity>
<xbrli:identifier scheme="http://disclosure.edinet-fsa.go.jp">X99001-000</xbrli:identifier>
</xbrli:entity>
<xbrli:period>
<xbrli:instant>2015-12-31</xbrli:instant>
</xbrli:period>
</xbrli:context>

計算期間、事業年度、報告書類等、分類を示します。
インスタンスに定義します。
インスタンスの金額項目等は、全ていずれかのコンテキストに属します。

id属性により、「いつ」の「何なのか」等が定義されます。（命名規則は決まっている）
上記なら、「１年前(Prior1の四半期末(Quarter)時点(Instant)」となります。
期間なら、Durationです。

シナリオ(Scenario) とかもあるみたいですが、何のことかわからないんだってばよ…(´；ω；`)ｳｩｩ

Fact

  <jpcrp_cor:NetSalesSummaryOfBusinessResults contextRef="Prior4YearDuration_NonConsolidatedMember" unitRef="JPY" decimals="-6">130747000000</jpcrp_cor:NetSalesSummaryOfBusinessResults>
  <jpcrp_cor:NetSalesSummaryOfBusinessResults contextRef="Prior3YearDuration_NonConsolidatedMember" unitRef="JPY" decimals="-6">154886000000</jpcrp_cor:NetSalesSummaryOfBusinessResults>
  <jpcrp_cor:NetSalesSummaryOfBusinessResults contextRef="Prior2YearDuration_NonConsolidatedMember" unitRef="JPY" decimals="-6">183448000000</jpcrp_cor:NetSalesSummaryOfBusinessResults>
  <jpcrp_cor:NetSalesSummaryOfBusinessResults contextRef="Prior1YearDuration_NonConsolidatedMember" unitRef="JPY" decimals="-6">196499000000</jpcrp_cor:NetSalesSummaryOfBusinessResults>
  <jpcrp_cor:NetSalesSummaryOfBusinessResults contextRef="CurrentYearDuration_NonConsolidatedMember" unitRef="JPY" decimals="-6">210346000000</jpcrp_cor:NetSalesSummaryOfBusinessResults>

上記ライブラリでは、どちらもFactというクラス名なので、そのまま使います。
金額等の要素を表します。
タグ名（ID）で勘定科目等を識別し、ContextRefで書類等を識別します。
タグの値が金額です。（注記事項とかだと、文字列になる）

ここから、いろんなものがたどれるはずだから…必死に追っています。

単純な項目はItemと呼び、複合要素はTupleと呼ぶらしい…

なお、「要素名（jpcrp_cor:NetSalesSummaryOfBusinessResults）」とcontextRef属性の値により、一意に識別されるようです。

スキーマ（リンクベース）

タクソノミの構成を「スキーマ」と呼んでいるようです。
（taxonomy = 分類）
構成 = スキーマじゃないか！

スキーマという概念は、非常にざっくりしていますが、要はインスタンス（データ）に意味を与えるもの、と思えばいいかと思います。

そのスキーマを構成するのが「リンクベース」と言って、以下の５種類があります。

ジェネリックラベルリンク
名称リンク（LabelLinkBase）
定義リンク（DefinitionLinkbase）
表示リンク（PresentationLinkbase）
計算リンク（CalculationLinkbase）

ざっくり説明すると、
名称リンク = 勘定科目等の定義
計算リンク = 計算書類ごとの計算方法
表示リンク = 計算書類等の表示方法

らしいです。
他の二つは、いまだにどう使えばいいかわかりません。

リンクベースは、複数インポートできます。
たとえば、「名称リンク」を、日本語版と英語版の二つインポートすると、一つのデータから、日本語名と英語名の二つにリンクできます。

この辺りは、「EDINET タクソノミのスキーマファイル」みたいなものも存在し、かなり意味が分からないです。
これも、「標準 + 法人独自定義」を簡単に組み合わせられるようにできるよう、配慮した仕様だと思っています。

乱暴な言い方をすると、インスタンスの要素名（jpcrp_cor:NetSalesSummaryOfBusinessResultsとか）を、各リンクベースに渡すと、結果を返してくれる、みたいなイメージです。
少なくとも、プログラム上はそうなっていないと、おかしいです。（カプセル化とはなんなのか）

行き詰っている点

私の当面の目標は、「Factと名称リンクを紐づける」ことです。ことなのですが…

上で、二つのライブラリを上げたのですが、どちらも目的を果たせません。

Diwen.Xbrlは、書いた通り、リンクベースは読み込んでくれないので、紐づけは自力実装となります。
あくまで、インスタンスを読込、作成、比較するライブラリです。

Gepsioは、「XbrlSchema.LabelLinkbase」という、いかにもよさそうなプロパティもあるんですが… なんと、「スキーマの最初に現れたLabelLinkしか返さない」という仕様です。
Githubに上がっているソースコードで確認しました。
（アメリカのものと思われるXBRLを見たけど、日本と違って、LabelLinkは一つしか定義しないのが普通な模様）

日本だと、LabelLinkは６つぐらい定義する（EDINETのサンプルインスタンスから）のが普通なので、一つだけ公開されてもどうにもなりません。

正解イメージ

//表示文字を返す
LabelLink link = LabelLinks.FindByFact(fact);

みたいな感じで取りたいのですが…
今は、LabekLinksの中身が、複数あるうちの一つなので、当然「そんな表示リンクは無いんだよ！」という状態です。

今後の展望

…どうしよう(´・ω・`)

正直、あくまで「XBRLから財務諸表を再現する」なら、上記のリンクベースへのアクセスを頑張って作るしかありません。
Gepsioを改変するのがきっと楽ですが…（改変利用は、ライセンス上問題なし）

どちらにしろ、自分で作るしかなさそうです。

一応言っておくと…

日本基準の勘定科目一覧というものがあり、それを使えばほとんどの勘定科目は、リンクベースを辿らなくても、名前がわかります。
分析用途なら、それで十分だと、個人的には思います。

長々と書きなぐりましたが、今後もいろいろ奮闘する所存です。

SE（たぶん）の雑感記

一応SEやっている筆者の思ったことを書き連ねます。会計学もやってたので、両方を生かした記事を書きたいと考えています。　でもテーマが定まってない感がすごい。