なぜXBRLはこうできているのか #1｜「100」だけでは財務データにならない――「JSONで十分」という反論から考える

この連載について

実際にEDINETデータを開き、AIへ渡して分析する手順は、既存の「AIで使うXBRL入門」シリーズで扱った。この新連載では一歩戻り、なぜXBRLがタクソノミとインスタンスを分け、この複雑な構造を選んだのかを考える。

数字の「100」をデータベースへ保存する。これだけなら難しくない。XMLなら <value>100</value>、JSONなら {"value": 100} と書ける。

では、この100は何だろう。売上高か、営業利益か。円か、百万円か。2025年3月期か、2026年3月期か。1年間の累計か、期末時点の残高か。企業グループ全体か、親会社だけか。

値を保存できることと、値の意味を第三者へ渡せることは同じではない。

XBRLはこの問題に対して、報告された値を置く**インスタンスと、値の意味や規則を定めるタクソノミを分けた。さらに各ファクトへ、会社や期間を示すコンテキストと、通貨などを示すユニット**を結び付ける。

しかし、ここで当然の疑問が出る。

会社、期間、単位、項目名をJSONへ追加すれば、同じことができるのではないか。

18ターンの議論で、この反論を中心に検討した。先に結論を言えば、独自のXMLやJSONでも、一社分のデータを正確に表すことはできる。XBRLの特徴は「XMLでしか表現できない情報」にあるのではない。

XBRLが用意したのは、財務データ専用の容器ではなく、複数の企業・規制当局・分析者が再利用できる意味と検証規則である。

運営者より――タクソノミを「項目一覧」だと思っていた

私自身、タクソノミを「売上高や営業利益といったタグの一覧」のように理解していた。しかし、それだけならXML SchemaやJSON Schema、データベースのテーブル定義でも作れそうだ。

では、なぜXBRLにはインスタンスとは別に多数のタクソノミファイルがあり、コンセプト、コンテキスト、ユニット、表示関係、計算関係などが分かれているのか。複雑なだけではないのか。

この新しい連載では、使い方ではなく、なぜその設計になったのかを一つずつ調べる。分かったふりをせず、一般的なデータ形式で代替できる部分と、XBRLが追加した部分を分けて考えたい。

この記事の土台にした記事・仕様

この記事は、主に次の公式資料を土台にした。それぞれが裏付ける範囲は異なる。

ベースにした記事・仕様	この記事で確認したこと
XBRL 2.1 Recommendation「XBRL framework」	報告をインスタンスとタクソノミに分け、インスタンスがファクト、タクソノミがコンセプトを定義する基本構造
XBRL International「XBRL Essentials」	一つのファクトを識別するには、値だけでなく企業・期間・単位・コンセプトが必要であること
XBRL International「Taxonomies」	タクソノミがコンセプト、ラベル、計算、検証、基準参照などを含む報告用の辞書であること
W3C「XML Schema Structures」	XML SchemaがXML文書の構造と内容を記述・制約できること
JSON Schema「Specification」	JSON Schemaもデータ構造と値の検証規則を定義できること
Financial Reporting Taxonomies Architecture	XBRLではコンセプトとしてのデータと、個々の表示方法を分けることが基本にあること

これらの資料は「XBRLだけが財務情報を表現できる」とは述べていない。むしろXML SchemaにもJSON Schemaにも検証能力がある。そのうえで、財務報告に必要な共通の意味をどう再利用するかが、今回の論点になる。

まず、独自JSONで作ってみる

レン（初学者の視点で確認する読者）は、議論の最初に次のような反論を出した。

レン（初学者の視点で確認する読者）

JSONに会社、期間、単位、項目名を全部入れればよいのではないでしょうか。それなら人にも読みやすく、XBRLより簡単に見えます。

実際、次のJSONはかなり多くの情報を持っている。

{
  "entity": "A社",
  "concept": "営業利益",
  "periodStart": "2025-04-01",
  "periodEnd": "2026-03-31",
  "scope": "連結",
  "unit": "JPY",
  "value": 100000000
}

JSON Schemaを作れば、期間を日付形式に限定し、値を数値型にし、unitを決められた候補だけに制限することもできる。XML Schemaでも、データベースでも同様の設計は可能だ。

コウ（XML・データベース設計者）は、ここを曖昧にしてはいけないと主張した。

コウ（XML・データベース設計者）

XBRLでなければ会社・期間・単位を表せない、という説明は誤りです。独自設計でも表せます。問題は、A社とB社が同じ設計と同じ意味を使う保証を、誰が作るかです。

一社のJSONから、千社の報告へ

独自JSONが困るのは、二社目を加えたときだ。

A社	B社	人間には分かりそうだが、機械には別物
concept: OperatingProfit	metric: OperatingIncome	本当に同じ利益概念か
scope: consolidated	group: true	同じ連結範囲か
unit: JPY	currency: yen	同じ単位体系か
periodStart/periodEnd	fiscalYear: 2025	同じ開始日・終了日か
value: 100000000	value: 100, unitScale: million	同じ桁か

二社が話し合ってAPI仕様を統一すれば解決できる。千社でも、全社が同じ仕様へ従い、毎年の変更を管理し、検証ツールを更新すれば解決できる。

だが、それはまさに標準を作り、維持する仕事である。

この図は設計上の違いを簡略化した編集部の整理である。実際のXBRLでも企業拡張やタグ付けの違いがあり、すべての数字が自動的に比較可能になるわけではない。

タクソノミとインスタンスを分ける理由

XBRL 2.1仕様は、報告を大きく二つに分ける。

• インスタンス：企業が実際に報告するファクトを置く。
• タクソノミ：そのファクトが使うコンセプトと関係を定義する。

先ほどのJSONに当てはめるなら、valueや対象期間がインスタンス側、そのconceptが何を意味し、どのデータ型・期間の性質を持つかという共通定義がタクソノミ側にある。

分離する最大の利点は、同じ定義を多数の報告から参照できることだ。

同じ場所に全部書く設計	定義と値を分ける設計
各社・各年度のファイルへ定義を重複して書く	共通タクソノミを複数社・複数年度で参照する
定義変更の影響を個別に追う	タクソノミの版として管理する
表示名と内部識別子が混ざりやすい	同じコンセプトへ日本語・英語など複数ラベルを付けられる
独自検証ツールが必要	XBRLプロセッサーが共通規則を解釈できる

ユウ（XBRLタクソノミ設計者）は、タクソノミを「人間が読む仕様書」だけだと考えると違いを見失うと説明した。タクソノミは、ソフトウェアが直接読み、ファクトに使われたコンセプト、型、期間の性質、関係などを確認するための機械可読な辞書でもある。

「100」をファクトにする四つの部品

XBRL Essentialsは、会社のある年の利益を報告する例を使い、ファクトを値だけではなく、コンセプトとコンテキスト情報の組合せとして説明している。

初心者向けに整理すると、最低限次の四つを見る。

部品	役割	今回の例
値	報告された数値	100,000,000
コンセプト	何を報告したか	営業利益
コンテキスト	誰の、いつの、どの範囲か	A社、2025年4月1日～2026年3月31日、連結
ユニット	何で測ったか	JPY

XBRLでは、数値の精度を示す情報も扱う。Inline XBRLでは、人間向け表示の倍率を機械向けの値へ反映する仕組みもある。ただし、通貨、表示倍率、数値の精度は別の概念である。「百万円表示だからdecimalsが百万円を表す」と考えると混同する。この詳細は後の回で実ファイルを使って扱う。

XBRLの検証が保証しないもの

議論では、標準化のメリットだけでなく、危険な安心感も争点になった。

ミユ（AIと構造化データを扱う技術者）は、ソフトウェアのテストがすべて成功してもバグがゼロとは限らないのと同じだと指摘した。

ミユ（AIと構造化データを扱う技術者）

「検証に通った」が「企業の説明も数字も真実である」に見えてしまうと危険です。機械が確認した規則と、人が判断すべき内容を分ける必要があります。

XBRLの検証で確認できる範囲は、使用する仕様やタクソノミ、提出ルールによって異なる。コンセプトが定義されているか、必要なコンテキストやユニットがあるか、定義された関係に従っているか、といった機械的な整合性を確認できる。

一方、次のことまでは自動的に保証しない。

• 元の会計処理や数値が経済実態を正しく表しているか
• 独自コンセプトの意味が他社の項目と完全に同じか
• 経営者の文章が妥当な見通しか
• 検証規則に含まれない誤りがないか
• 投資判断として買いか売りか

ナオ（企業開示を検証するリサーチャー）は、XBRLが保証する範囲を「構造と機械可読な規則の整合性」と表現し、監査や開示内容の責任とは区別すべきだとまとめた。

複雑さは、失敗ではなく代償か

ここまで読むと、XBRLの複雑さには理由があるように見える。しかし、理由があることと、使いやすいことは別だ。

XBRLが得たもの	同時に生じた負担
共通語彙の再利用	タクソノミを理解する学習コスト
複数の意味関係	スキーマと複数リンクベースへのファイル分散
企業固有開示への拡張性	企業間比較を難しくする独自コンセプト
機械検証	「検証済み＝内容も正しい」という誤解
国・制度をまたぐ標準	各制度の提出ルールとの組合せが必要

テツオ（一般読者向けの記事を点検する編集者）は、XBRLを「完全統一された世界共通辞書」と説明しないよう求めた。実際には、ベースとなる共通語彙があり、その上に国・制度や企業の拡張が重なる。共通部分は比較しやすくなるが、独自部分には解釈が残る。

この問題は、第5回から第7回で、ベースタクソノミ、制度別タクソノミ、企業拡張、アンカリングとして詳しく扱う。

AIが読めるなら、共通語彙は不要になるか

AIは、ラベルが違っても文章の類似性から「おそらく同じ項目」と推測できる。独自JSONや企業拡張コンセプトを読む費用は、以前より下がる可能性がある。

それでもミユ（AIと構造化データを扱う技術者）は、推測と定義を区別した。

• AIは二つの項目が似ていると推測できる。
• タクソノミは、報告制度がそのコンセプトをどう定義したかを示す。
• AIは欠けた対応関係の候補を作れる。
• XBRLは、その候補を期間・単位・関係・原文へ戻って検証する材料を提供する。

AIによってタクソノミが不要になるのか、それとも人間には扱いづらかったタクソノミをAIが使いやすくするのか。これは連載最終回で、PDFだけ、XBRLだけ、XBRLとタクソノミの三条件を実際に比較する。

第1回の結論

「JSONへ項目を足せばよい」という反論は正しい。一つの組織が自分の目的に合わせて財務データを保存するだけなら、XBRLを使わなくてもよい。

XBRLが必要とされたのは、同じ報告を多数の企業が繰り返し、規制当局が受け取り、投資家や分析システムが再利用するからだ。

XMLやJSONは、データを運ぶ容器を作れる。

XBRLは、財務報告で共有するコンセプト、期間、単位、関係、検証規則を再利用するための約束を作った。

ただし、その約束が比較可能性を生むには、正しいタグ付け、制度上の提出ルール、運用の継続が必要である。

出典を読むときのポイント

• XBRL 2.1 Recommendation：インスタンスとタクソノミの分離、コンセプト、コンテキスト、ユニットというXBRLの基本構造を確認した。
• XBRL International「XBRL Essentials」：ファクトが値だけでなく、企業・期間・単位・コンセプトの組合せとして解釈されることを確認した。
• XBRL International「Taxonomies」：タクソノミが報告用の辞書として、ラベル、計算、検証規則、基準参照などを含み得ることを確認した。
• XBRL International「XBRL Glossary」：XBRL報告がタクソノミを参照し、両者の組合せで内容を解釈できることと、xBRL-XML以外にもInline XBRL、xBRL-CSV、xBRL-JSONがあることを確認した。
• W3C「XML Schema Structures」：XML Schema自体にもXML文書の構造と内容を制約する能力があることを確認した。
• JSON Schema「Specification」：JSON SchemaのCoreとValidationが、JSONデータの構造と検証を定義することを確認した。
• Financial Reporting Taxonomies Architecture：財務報告タクソノミでコンセプトとしてのデータと表示を分ける設計原則を確認した。2005年の設計指針であり、現在の全提出制度を直接規定する資料としては扱っていない。

この記事は特定の投資判断を勧めるものではありません。