0.1秒で次世代TDnetのサンプルデータを作成する方法

XBRL TDnet

このエントリでは、次世代TDnetのサンプルデータを素早く簡単に大量に作成する方法を説明する。

目的
目的は、簡単にたくさんの次世代TDnetのサンプルデータを作ることだ。サンプルデータは、次世代TDnetのデータ利用者のシステム開発ではいずれ必要になるものだが、データ作りは退屈で面倒な作業だ。少なくとも私が自分でやりたい仕事ではない。
東証から提供されたサンプルに設定された金額が不適切（連結売上高が100万円で、営業利益が200万円だったりする）なのを見ても、適切な金額を設定するのが難しいことがわかる。

作戦
以下の処理を行うプログラムを作ることにしよう。

  • 現行タクソノミで作成されているインスタンスを、次世代タクソノミ版に変換する。（変換処理）
  • 事前にテンプレートを作成し、データをテンプレートに流し込んで出力ファイルを作成する。（レンダリング処理）

変換処理
ＸＢＲＬインスタンスには、ファクト（報告項目）とユニットとコンテキストの情報がある。ユニットは変更なしなので、変換処理では、ファクト（報告項目）とコンテキストをそれぞれ以下の通り変換する。

ファクト（報告項目）の変換
東証によれば、現在のＸＢＲＬインスタンスの報告項目と次世代の報告項目が１対１で対応する。対応関係はマッピングリストとして提供されている。よって、報告項目の変換はマッピングリストに従って機械的にやればよい。
例えば、年次決算短信（様式=acedjpsm）の連結（Consolidated）の売上高（NetSales）であれば、実績メンバー(ResultMember)で連結メンバー(ConsolidatedMember)の売上高(NetSales)という具合に機械的に決まる。

コンテキストの変換
コンテキストは、必要なディメンション分増幅させる。

現行のコンテキストは、相対年度×期間時点×連結非連結の組み合わせ分存在する。次世代では、連結非連結がディメンション軸となり、さらに３つの軸（業績予想軸、配当スケジュール軸、前回今回軸）が新たに追加されるため、相対年度×期間時点×連結非連結×業績予想×配当スケジュール×前回今回の組み合わせ分存在することになる。

例えば、今年度(CurrentYear)の期間(Duration)のコンテキストは、現行では、CurrentYearConsolidatedDuration(連結)とCurrentYearNonCosolidatedDuration(非連結)の２つだけだ。しかし、次世代では、連結非連結軸が３種類（２メンバー＋軸なし）×業績予想軸５種類（４メンバー＋軸なし）×配当スケジュール軸６種類（５メンバー＋軸なし）×前回今回軸３種類（２メンバー＋軸なし）で２７０パターン存在しうることになる。もちろん、インスタンスにこれらすべてのコンテキストが定義されるわけではなく、必要なのはファクトが存在するコンテキストだけだ。ファクトのコンテキストは、前述のファクトの変換で決まる。

レンダリング処理
次世代TDnetでは、XBRLデータは、InlineXBRLとスキーマファイルと定義リンクベースの３ファイルが１セットだ。事前にこれら３ファイルのテンプレートを作成し、現行インスタンスから変換した情報を流し込む。

InlineXBRLテンプレート
InlineXBRLはベースがXHTMLなので、XHTMLでレイアウトを作成しておく。ファクトを埋めたいところにはプレースホルダを置いておき、レンダリング処理時にファクトに置き換えるようにする。

スキーマテンプレート
スキーマは、参照するファイルが固定で決まるので、特に問題なくテンプレートを作れる。

定義リンクベーステンプレート
標準タクソノミの taxonomy\jp\tse\tdnet\ed\r\2013-01-21 にあるものから該当する様式のファイルをコピーして、相対パスで記述されているhref属性を絶対パスに変更すればよい。

実装例
Pythonで作成したツールの実装は、ここからダウンロードできる。（実際にツールで変換して作成したサンプルデータも同封）

応用
テンプレート方式でInlineXBRLを作る仕組みは、とても簡単に実装できることがわかったが、一般的なインラインXBRL作成ツールに比べて、柔軟性に欠ける。
逆に言うと、柔軟性が必要ない、拡張がなく様式がある程度固定的なXBRLの場合には、テンプレート方式の作成ツールが簡単に作れる可能性が高い、ということだ。例えば、今回変換ツールを作成した次世代TDnetの決算短信サマリや業績予想・修正予想、また、次世代EDINETの大量保有報告書などの作成ツールに応用することができるだろう。

TDnet更改に向けたXBRLユーザーセミナー開催のお知らせ

XBRL TDnet

XBRL Japanのサイトにて告知が出ていましたので、ご紹介します。

申込期限が明日22日の正午までなので、ご希望の方はお急ぎください。お金はかかりません。特に参加制限などは記載されていないようなので、だれでも関心のある人は参加できそうですね。

一般社団法人XBRL Japan（以下、XBRL Japan）は、以下の通りXBRLセミナーを開催いたします。

第１回テーマ：TDnet更改に向けたXBRLユーザーセミナー

【概要】
2013年1月に開催された東京証券取引所様によるTDnetユーザ向けの説明会において、2014年のTDnet更改に対応したXBRLに関する説明が行われました。本セミナーでは、TDnet更改後の適時開示システムにおけるXBRLの理解を深めるために、XBRLの基礎的な説明、東京証券取引所様の配布資料を使ったXBRLの解説などを行います。

【当日のスケジュール】
1. XBRLの基礎
TDnet更改に対応した新タクソノミなどを理解するための基礎的なXBRL仕様についてご説明します。
2. 2014年のTDnet更改に対応したXBRLに関する詳細解説
2013年1月の説明会での東京証券取引所様の配布資料を使ったXBRLの詳細解説を行います。その後、質疑応答などを行います。
3. インラインXBRL、Dimension仕様などの海外事例の簡単な紹介

【日時】
2013年2月25日（月）　10:10〜12:00（予定）／開場は10:00になります。

【場所】
東京証券取引所アローズ1階　プレゼンテーション・ステージ
※セミナー会場へは西口玄関からご来場ください。
http://www.tse.or.jp/about/tse/map/index.html

【申込期日】
2月22日（金）　午前12:00

【ご参加方法】
XBRL Japanのサイト参照

私はもう参加申し込みしました。

繰り返しますが、申込期限は明日22日の正午までです。

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は、情報の粒度がそろっていて、比較可能性も高い。最近は間違いもほとんどなく、安心して利用できる情報だ。更改まであと１年もないこの状況で、急いで変更する必要性はないはずだ。

EXCELで決算短信XBRLを使った独自の財務DBを作る 〜簡単で実用的なXBRLの活用のすすめ〜

XBRL

このエッセイでは、決算短信サマリのXBRLを使って、上場企業の財務情報のデータベースを作成するという問題に取り組む。
XBRLの専用ソフトを使わずとも、EXCELだけで十分実用的なデータベースを作れるということがわかる。

XBRLの予備概念

最初に必要な概念をいくつか確認しておこう。
XBRLの正確な仕様はびっくりするほど複雑で難しいが、利用者が理解しなければいけない概念はたった２つしかない。「コンテキスト」と「要素」だ。

XBRLでは、すべての事実がコンテキストと要素の組み合わせで記述されていることを理解しよう。要素は測定される概念で、コンテキストは期間やシナリオのことだ。例えば『X社の2012年3月期の売上高100万円』という事実がXBRLで記述されていたとしよう。この場合「X社の2012年3月期」がコンテキストで、「売上高」が要素となる。

事実　＝　コンテキスト　×　要素

ここで重要なのは、事実はコンテキストと要素の組み合わせでユニーク（一意）になっている、ということだ。

決算短信サマリ

決算短信とは、一般的に決算発表と呼ばれている。現在、上場企業は四半期ごとの決算発表が義務付けられている。決算短信は、東証TDnetで公表することになっていて、直近の31日分ならだれでも自由に閲覧することができる。 その決算短信の冒頭２ページに、重要な係数（売上・利益・配当金など）がまとめられているが、その部分のことを特に「決算短信サマリ」といっている。 TDnetでは決算短信サマリに対していち早くXBRLが適用され、2008年7月から従来のPDFの開示に加えて、XBRLでも開示されるようになった。（現在もPDFとXBRLの2重開示）

決算短信サマリのXBRLには、以下の特長がある。

  • スクリーニングなどに必要十分な、重要な財務データがそろっている
  • 実質的に企業拡張がなく、適切に集約された項目で記述されているため比較しやすい
  • 比較的単純で、データ不正が少ない

では、このような決算短信サマリのデータを使って、財務データベースを作ろう。

ワークシート関数

VBAを使ってXBRLから必要な項目を抜き出すためのワークシート関数を作成する。定義するワークシート関数は、以下の３つだ。

sm_Fact

事実（ファクト）の値を取得する。見つからなかった場合には、xlErrValueを返す。

Function sm_Fact(path, elementName, Optional contextId = "", Optional attr = "VALUE")

'[引数]
'path XBRLインスタンスのパス（URLまたはファイルパス）
'elementName 要素名
'contextID コンテキストID（省略するとすべてのコンテキスト）
'attr　取得する属性を指定する（大文字・小文字は区別しない）
' "Value": 値を取得する（デフォルト）
' "ContextID": コンテキストIDを取得する

sm_Context

コンテキストの情報を取得する。見つからなかった場合には、xlErrValueを返す。

Function sm_Context(path, contextId, Optional attr = "ID")

'[引数]
'path XBRLインスタンスのパス（URLまたはファイルパス）
'contextID コンテキストID
'attr 取得する属性を指定する（大文字・小文字は区別しない）
' "ID": コンテキストIDを取得する（デフォルト）
' "startDate": 開始日を返す
' "endDate": 終了日を返す
' "instant": 基準日を返す
' "consolidate": 連結かどうかを返す

sm_FindElement

複数の要素から、XBRLにファクト存在する要素を返す。見つからなかった場合には、xlErrValueを返す。

Function sm_FindElement(path, elementName As Range, Optional contextId = "")

'[引数]
'path XBRLインスタンスのパス（URLまたはファイルパス）
'elementName 要素が入力されているセルの範囲
'contextID コンテキストID（省略するとすべてのコンテキスト）

完全なコードはここにある（コメント行を含めても200行未満だ）。

ワークシート関数を使う

これらのワークシート関数の使い方を説明しよう。

最初にもっとも単純なケースを考えてみることにする。 XBRLデータに１つしか事実が記述されないことがわかっている要素の値を取得したい場合がある。 決算短信サマリなら、企業名(CompanyName)、証券コード(SecuritiesCode)、事業年度終了日(FiscalYearEnd)などだ。 これらの要素のファクトの値を取得するときは、ファクトのコンテキストがなんであるかは気にする必要はない（まともなXBRLデータなら適切なコンテキストで記述されているはずだ）。
この場合は、sm_Factを使う。コンテキストは気にしないので３番目の引数のContextIDは省略してよい。
例えば、以下の数式で、XBRLデータ「C:\xbrl\tdnet-qcedjpsm-91010-20130123068307.xbrl」から、企業名(CompanyName)の値を取得できる。

=sm_Fact("C:\xbrl\tdnet-qcedjpsm-91010-20130123068307.xbrl", "CompanyName")

次に、最も一般的なケースを考えてみよう。
多くの要素は、いくつかのコンテキストでいくつかのファクトとして記述されている。 例えば、連結企業の通期の決算短信サマリでは、４種類の売上高(NetSales)が記述されている。今期の連結売上高・売上高（単独）、前期の連結売上高・売上高（単独）だ。

  • 今期の連結売上高＝今期連結コンテキスト(CurrentYearConsolidatedDuration)　×　売上高(NetSales)
  • 今期の売上高（単独）＝今期単独(CurrentYearNonConsolidatedDuration)　×　売上高(NetSales)
  • 前期の連結売上高＝前期連結(PriorYearConsolidatedDuration)　×　売上高(NetSales)
  • 前期の売上高（単独）＝前期単独(PriorYearConsolidatedDuration)　×　売上高(NetSales)

このようなケースでは、3番目の引数のContextIDを省略せずにsm_Factを使う。
例えば、今期の連結売上高を抜き出すなら以下の数式をセルに記述する。

=sm_Fact("C:\xbrl\tdnet-qcedjpsm-91010-20130123068307.xbrl", "NetSales", "CurrentYearConsolidatedDuration")

今期の連結売上高の金額を取得することはできた。では、その「今期」とはいつからいつまでだろうか。
それを知るには sm_Context を使えばよい。

=sm_Context("C:\xbrl\tdnet-qcedjpsm-91010-20130123068307.xbrl", "CurrentYearConsolidatedDuration", "startDate")

=sm_Context("C:\xbrl\tdnet-qcedjpsm-91010-20130123068307.xbrl", "CurrentYearConsolidatedDuration", "endDate")

第3引数に"startDate"を指定すると、そのコンテキストの開始日を取得できる。"endDate"を指定すればコンテキストの終了日になる。

最後に、売上高に複数の要素を集約するケースを考えてみよう。

各社の決算短信サマリを見ていくと、「売上高」にもいろいろな種類があることがわかる。
一般的に売上高(NetSales)のほかに、営業収入(OperatingRevenues)、営業総収入(GrossOperatingRevenues)などが使われている。これらは厳密には異なる勘定科目だが、同じ項目に集約したい。

このような場合には、sm_FindElement と sm_Fact を組み合わせて使えばよい。
今期の連結売上高として、NetSalesとOperatingRevenuesとGrossOperatingRevenuesのいずれかの要素のファクトを取得する場合、以下のようにすればよい。（セルA1〜セルA3に"NetSales", "OperatingRevenues", "GrossOperatingRevenues"とそれぞれ入力されているものとする）

=sm_Fact("C:\xbrl\tdnet-qcedjpsm-91010-20130123068307.xbrl", sm_FindElement("C:\xbrl\tdnet-qcedjpsm-91010-20130123068307.xbrl", A1:A3, "CurrentYearConsolidatedDuration") ,"CurrentYearConsolidatedDuration")

決算短信サマリから財務DBの項目を取得するワークシートを作成する

ここまで説明したことを使えば、決算短信サマリのXBRLデータから財務DBの項目を取得するワークシートを作成することができる。
完成した財務DB作成ツール（Excelファイル）はここにある。

会社情報

まず「会社情報」を取得する。
会社情報は、そのデータを提出した企業やそのデータそのものの情報（メタ情報）で、具体的には「文書名(DocumentName)」「上場会社名(CompanyName)」「URL(URL)」などがある（その他にも要素がある。詳しくは東証が開示している決算短信サマリー企業拡張タクソノミ作成要領(PDF)の49/124ページなどを参照）。

直感的にわかるとおり、会社情報は１つのXBRLデータに１つずつしか情報を持たない。よって、sm_Fact関数を使って簡単に取得できる。たとえば、上場会社名なら以下のように記述すればよい。

=sm_Fact(XBRLインスタンス, "CompanyName")

会社情報から６項目（上場会社名(CompanyName),文書名(DocumentName),証券コード(SecuritiesCode),提出日(FilingDate),決算期(FiscalYearEnd),URL(URL)）を取得する。提出日と決算期の値は日付なので DATEVALUE 関数を使って変換しておくとよい。

コンテキストID

次に、データを取得するコンテキストIDを取得する。コンテキストIDは、後に経営状況（売上、各利益など）や財政状態（総資産など）を取得するために利用する。 このツールでは、決算短信から連結優先で直近のデータを取得したい。そこで、そのデータの「最新時点コンテキスト」「最新期間コンテキスト」「今年度期間コンテキスト」の３コンテキストのIDを取得する。

コンテキストIDの命名ルールによって、「最新時点コンテキスト」がわかれば、「最新期間コンテキスト」と「今年度期間コンテキスト」は機械的に決まる。「最新期間コンテキスト」は〜Instantを〜Durationに置き換えればよい。「今年度期間コンテキスト」はCurrentYearConsolidatedDuration(連結)かCurrentYearNonConsolidatedDuration(非連結)の2択だが、「最新期間コンテキスト」から連結か非連結か判別できる。

では「最新時点コンテキスト」はどうやってとればよいか。命名ルールによると、四半期か年次か、連結か非連結かがわかれば一意に定まることになっている。したがって、その情報をXBRLからとればよいのだが、ここではもっと簡単でうまい方法がある。

決算短信サマリの場合、連結優先の「最新時点コンテキスト」を簡単に取得できる暗黙のルール（明文化されているかもしれないけど）がある。すなわち、会社情報のファクトは連結優先の最新時点コンテキストで定義されているのだ。つまり、会社情報（上場会社名や文書名など）のファクトのContextIDを見ればよい。

=sm_Fact(XBRLインスタンス, "CompanyName",,"ContextID")

これでターゲットのコンテキストがわかった。では、実際にデータベース化する値を集めていこう。

経営成績

経営成績の各出力項目（「売上高」「営業利益」「経常利益」「純利益」とそれぞれの増減率）は、「最新期間コンテキスト」に属する要素を集約して取得する。たとえば、「売上高」には「NetSales」「OperatingRevenues」など22種類の要素を集約している。（実際になんの要素を集約しているかはツールを見れば一目瞭然なので、ツールを見ながら読んでほしい）

財政状態

財政状態の各出力項目（「総資産」「純資産」「自己資本比率」）は、「最新時点コンテキスト」に属する要素を集約して取得する。

配当金

配当金の状況の各出力項目（「配当金1Q」「配当金2Q」「配当金3Q」「期末配当金」「通期配当金」）は、「今年度期間コンテキスト」に属する要素を取得している。集約はしていない。

集約の難しさ

このツールで行っている集約は、一つの実装例に過ぎない。XBRL上の要素を、データベース上の項目にどうやって当てはめていくか。たとえば、日本基準の売上高と米国基準の売上高を別々の項目に集約するか、それとも、同じ項目に集約するか。営業収益はどうか。完成工事高（一部の建設業で利用されている）は。経常収益（銀行業で利用されている）は売上なのか。

答えはデータベースを利用する人（あなた）がどう考えるかだ。唯一正しい答えはない。集約する要素を決めることはすなわち、データをモデル化することだ。モデルは利用目的によって変わる。

あなたが次にやるべきこと

完成したツールは、1つのXBRLから財務DBの１レコード分のデータを作成するものだ。
このツールを使ってデータベースを作るには、まず決算短信サマリのXBRLを集め、そして各XBRLデータごとに、ツールのセルA2にXBRLファイルのパスを入力して計算結果を別ファイル（別シート）に保存、という作業を繰り返せばよい。

これらはいずれも手作業でやるのは大変だ。だが、データさえ集めてしまえば、あとの作業は簡単にVBAで自動化できるだろう。

ではどうやってデータを集めるか。残念ながら、データを集める作業には苦労するだろう。
米国SECは、提出されたXBRLデータはFTPサーバにすべてまとめられ、自由に簡単に大量に自動的にダウンロードできるようになっている。 一方、TDnetを運営する東証は、一般的な利用者がXBRLデータをまとめて集める手段は提供していない。必要なものは一つ一つダウンロードする、1ヶ月で消す、というのがTDnetのやり方だ（ワイルドだろう？）。

そこで、あなたのような人件費を削減したい利用者は、XBRLデータを集めるには手か頭を使わなくてはいけない。
もしかしたら、有報キャッチャーウェブサービスやTeCAProが役に立つかもしれない。

実装例をアップしておくので、興味がある人はダウンロードして使ってみてほしい。

なぜこの記事を書いたか

運営しているサイトで開示していた（今はやめてしまった）財務データベースの復活の要望があった。この要望を出してくれた方に感謝の意をこめて、（サービスの復活は難しいので）エッセイという形でデータベースそのものの作り方を示した。

2008年に日本で先頭を切って導入されたXBRLは、いまだに一般的な有報や決算短信の閲覧者が気軽に使うようにはなっていない。このエッセイでは、XBRLを簡単に使えて役に立つ具体的なソフトを提示できたのではないかと思う。

XBRLのデータを利用する難しさは、XBRLそのものの複雑さにあるのではない（EXCELでも簡単にXBRLを利用できる）。
XBRLデータの利用で難しいのは、データにどのように要素やコンテキストが使われているかを理解することだ。データのくせやノウハウに属するこのような情報は特定のコアな利用者だけが握っていて、ほとんど表に出てきてないように思われる。決算短信サマリのXBRLについて、本稿が少しでも理解の助けになっていたら幸いだ。

パブコメ

６月に金融庁から出された次世代EDINETタクソノミ（案）について、公表された資料では、提出者がXBRLデータを作成する際のルールがわかりにくい、という指摘がありました。

いま発表されている資料では、ガイドラインのなかでルールを説明しようとしていて、ルール集はありません。会計実務指針だけあって会計基準がない、みたいなものです。

真のルール(?)は、ガイドラインに散らばるルールらしきものをかき集めて、帰納的に類推する必要があるのです。そのため、作成者によってルールを読み間違えたりするリスクが高い（典型的な帰納法の問題点ですね）わけです。

やっぱりそれはまずいでしょう。

まずルールありきで、ルールを守って適切なＸＢＲＬデータを作成する方法がガイドラインで説明されるべきです。
金融庁には、ぜひルールブックの作成をお願いしたいと思います。

データモデルにXBRLを用いたテンプレートエンジンの試作

データモデルにXBRLを用いたテンプレートエンジン（XBRL Template engine Prototype、略して「XTP」）を試作した。

テンプレートエンジンとは、『テンプレートと呼ばれる雛形と、あるデータモデルで表現される入力データを合成し、成果ドキュメントを出力するソフトウェアまたはソフトウェアコンポーネントである』(Wikipedia)。今回作成したXTPは、データモデルがXBRLインスタンスのテンプレートエンジンである。

想定する利用方法
TDnetで開示される決算短信サマリのXBRLから、ユーザがブラウザで見やすいHTML（日本語・英語）を作成する、といった利用方法が考えられる。（これをXTPの実装目標とした。）

開発ツール

処理概要
XTPプログラム（以下、XTP）は、A.テンプレート、B.XBRLインスタンス、C.マッピング情報を入力として、ドキュメントを生成する。

A.テンプレートは、動的に変更する部分は変数（$foo$、$bar$のように、「$」で囲む）として記述したHTMLなどのテキストファイル。XTPでは、A.テンプレートの文法はStringTemplateのものをそのまま採用した。

テンプレートイメージ

B.XBRLインスタンスはデータ。

C.マッピング情報は、A.のテンプレート上の変数に、B.のインスタンスからどのような値をどのようなフォーマットで設定するかを定義する。
マッピング情報イメージ

XTPでは、マッピング情報の定義に基づいてXBRLインスタンスを解析して必要な値を抜出し、テンプレート上の変数に割り当てる。テンプレート上の変数をテンプレートに展開するレンダリング処理は、StringTemplateが行う。
マッピング情報の記載は、DSL（ドメイン固有言語：独自の簡易的な言語）を定義し、そのDSLのパーサ・ジェネレータとしてANTLRを用いた。DSLを独自に実装することで、機能拡張がしやすくなる。

出力イメージ

実装
※特に隠すつもりはないので、ソース見せてよ、という方はご連絡ください。

所感

  • XTPの実装は簡単だったが、短信サマリのテンプレートを作るのが予想以上に手間取った
  • HTMLへの変換だけなら十分実用的
  • ラベルリンクを解析して、ラベルを出力できるとよい（今後の課題）
  • タプルやディメンションに対応するとよいのでは（今後の課題）
  • ANTLRは難しいがおもしろい（DSLは癖になる）
  • StringTemplateが機能豊富すぎて、XTPの機能の少なさが情けなくなる

あまりお金にはつながらないかなぁと思うのですが、もし興味をもっていただいて、使わせてほしい、とか、一緒に研究しよう、とか思っていただける方がいたらうれしいです。