XBRLのインライン化・ディメンション化による対応を考える

XBRL TDnet

次世代TDnetでは「決算短信サマリ」と「業績・配当予想の修正」において、Inline XBRLとDimensionを採用するらしい。このエントリでは、利用者側アプリケーションの対応を考えてみる。

Inline XBRL

Inline XBRLは、XBRLインスタンスの情報をHTMLに埋め込む技術だ。ブラウザで見る限りは普通のHTMLと同じだが、HTMLの中に、ブラウザでは見えないようにして、XBRLインスタンスの情報がタグ付してある。ブラウザは、理解できない(HTMLではない)タグは無視する、という性質を利用している。次世代EDINETでも採用されている。

次世代EDINETでもInline XBRLが採用されるが、開示データにはXBRLインスタンスが含まれる。次世代EDINETではEDINETがデータ受領時にXBRLインスタンスを作成し、同封する仕組みだからだ。そのため、XBRLデータを利用する場合、これまで通りXBRLインスタンスを使うことができる。

しかし、TDnetではXBRLインスタンスを作らないという。だとすると、データ利用者はInline XBRLを使わなければならない。

Dimension

Dimensionは、コンテキストに属性を持たせる仕組みだ。次世代TDnetでは、「連結・非連結」「実績・予想」「前回・今回」「年間配当スケジュール」の４つの属性（Axis(軸)という）を持たせる。従来は、コンテキストは期間（startDate、endDate、または、Instant）とシナリオによる連結・非連結の違いで定義されていたが、次世代TDnetでは、「連結・非連結」がDimensionによる定義になり、それに加えて３種類の属性の組み合わせでコンテキストが定義されることになる。結果、コンテキストの数が大幅に増えることになる。

想定アプリケーション

このエントリでは、現在の「決算短信サマリ」や「業績・配当予想の修正」のXBRLインスタンスを読み込んで、レコード指向のデータ形式（要するにCSVのようなもの）に集計し、出力するアプリケーションを想定する。

XBRLインスタンス ----> [アプリ] ----> 集計データ

もう少し、アプリを詳細にみておこう。

このアプリは、２つの機能に分けられる。１つは、XBRLインスタンスを読み込む機能で、もう一つは、集計する機能だ。

XBRLインスタンス ----> [読込処理] ----> 内部データモデル ----> [集計機能] ----> 集計データ

集計機能は、XBRLから取得したデータをどのように集計するかを定義し、その定義に従って集計する。つまり、集計機能は、集計の方法が定義された情報（集計定義）と、その定義に従って集計するエンジンから成り立っている。

[集計機能] ＝ [集計エンジン] ＋ 集計定義

このようなアプリを、これまでにいろいろなところで開発してきた。そして、それらを今年中に修正していかなければいけない。つまり、これは他人ごとではなく、完全に私の問題なのだ。

次世代TDnet対応

Inline XBRL対応

まず、Inline XBRLへの対応だ。これまで、XBRLインスタンスから読込んでいた処理を、Inline XBRLから読み込むように修正する必要がある。

XBRLインスタンス Inline XBRL ----> [読込処理] ----> 内部データモデル

コンテキストやユニットなどは、Inline XBRLでもXBRLインスタンスと似たようなタグで定義されているので修正は簡単だろう。しかし、ファクト情報は定義の方法が大きく違っている。たとえば、NetSalesのファクトを取得するXPathは、XBRLインスタンスでは

//tse-t-ed:NetSales

だが、Inline XBRLの場合は

//ix:*[@name="tse-t-ed:NetSales"]

となる。さらに、値はformat属性の値によって変換しなければいけないので、その変換ルール（Transformation ruleという）も実装する必要がある。

読込機能を修正せず、Inline XBRLを一旦XBRLインスタンスに変換してから読込む方法もある。しかし、XBRLインスタンスに変換する処理を実装するくらいなら、Inline XBRLから直接読み込めるように対応する方が簡単でパフォーマンスもよいだろう。

Dimension対応

Dimensionの対応には２つの側面がある。１つは、技術仕様としてのDimensionの対応が必要であること。もう１つは、Dimensionを採用することによって、要素が整理されることへの対応が必要であることだ。

技術仕様としてのDimension対応として、コンテキストの内部データモデルを修正する必要がある。例えば、コンテキストクラスというものがあったとすれば、そのプロパティにDimensionの情報を追加しなければならない。モデルが変わるので、そのモデルにかかわる読込処理や集計エンジンにも修正が必要になる。

XBRLインスタンス Inline XBRL ----> [読込処理] ----> 内部データモデル ----> [集計機能] ----> 集計データ

次に、Dimensionを採用することによって、要素が整理されることへの対応を考えてみよう。

要素が変わるということは、すなわち、集計方法が変わる、ということだ。Dimensionが採用されて、要素が表す情報量が減りコンテキストがもつ情報量が増える。それに伴い、集計定義でコンテキストから判断しなければいけないロジックが増える。例えば、予想と実績は、従来は別の要素だったが、次世代TDnetは同じ要素の別コンテキストということになる。

東証は、現在使われている要素・コンテキストと、次世代TDnetで想定される要素・コンテキストを読み替える資料「マッピングリスト」を提供することを表明している。マッピングリストを用いて、集計定義を修正する必要がある。

まとめ
次世代TDnetの決算短信サマリ・業績・配当予想修正の対応には以下の修正が必要だということがわかった。

  • Inline XBRLから読み込むように修正する
  • Transformation Ruleを実装する
  • 内部モデルのコンテキストのプロパティを増やし、Dimensionの情報を保持する
  • 要素の整理・コンテキストのDimension化により、集計エンジンと集計定義を修正する

まぁ、なんていうか、はっきり言ってしまえば、古いソースを生かしつつほぼ完全に作り直すレベルだ。

最後に
３つほど、言いたいことがある。

１．短信サマリと業績・配当予想修正は、XBRLの対象が増えるわけでもないのにこのような対応を利用者に強いる更改は、大義がないのではないか。

２．提出者（上場企業）がInline XBRLに正しくタグ付できるのか不安だ。Dimensionにより要素は減ったが、コンテキストの設定が格段に煩雑で不明瞭になった気がする。

３．Inline XBRLのタグ付が誤っていると、ブラウザでの見た目とXBRLの値が矛盾することになるためチェックが必要だ。さらにPDFもあるため、PDFでの見た目、Inlineのブラウザでの見た目、XBRLの値の３つでチェックすることになる。これまでは、PDFとXBRLの２つだけだったのに、チェック対象が増えるのは運用上も負担が増えることが懸念される。

現行の短信サマリと業績・配当予想修正のXBRLは、情報の粒度がそろっていて、比較可能性も高い。最近は間違いもほとんどなく、安心して利用できる情報だ。更改まであと１年もないこの状況で、急いで変更する必要性はないはずだ。