読者です 読者をやめる 読者になる 読者になる

SE(たぶん)の雑感記

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

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

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

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

注意点

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

目的

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

環境

参考リンク

いきなり(笑)

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属性により、「いつ」の「何なのか」等が定義されます。(命名規則は決まっている)
上記なら、「1年前(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 = 分類)
構成 = スキーマじゃないか!

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

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

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

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

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

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

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

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

行き詰っている点

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

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

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

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

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

正解イメージ

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

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

今後の展望

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

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

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

一応言っておくと…

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

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