なぜXBRLはこうできているのか #7｜『暫定値』まで機械に伝える――OIM Taxonomyが作り直そうとするもの

「売上高100億円」と書かれた二つのデータがある。一方は確定値、もう一方は推計値だったら、AIは同じ数字として扱ってよいのだろうか。

さらに、その100億円が監査済みなのか、後日訂正された値なのかでも、読み手の判断は変わる。人間なら注記、提出日時、訂正報告をたどって意味を補える。機械には、それらが明示されていなければ分からない。

XBRLには、会社、期間、単位、連結・単体、事業セグメントなどをファクトへ結び付ける仕組みがある。それでも現在のXBRLタクソノミは、2003年のXBRL 2.1と、その後に追加されたDimensions、Generic Links、Calculationsなど複数仕様の組合せでできている。提出規則の一部は別冊のマニュアルに残り、巨大なタクソノミは多数のXML・XLinkファイルへ分かれ、同じ要件を違う方法で表せる場合もある。

この状況を作り直そうとしているのが、OIM Taxonomy Modelである。OIMはOpen Information Modelの略で、ファイル形式ではなく、XBRLが表す情報のモデルを先に定義する考え方だ。

先に結論を言えば、OIM Taxonomyは「XMLをJSONへ変える計画」ではない。

別冊マニュアルやXBRL 2.1の複数の構文へ分散していた意味・制約・補助情報を、構文に依存しない標準モデルの対象として扱おうとする試みである。

ただし、2026年7月23日時点で完成した標準ではない。2025年12月17日に公開されたのは、何を実現すべきかを記したXBRL Taxonomy Model Requirements 1.0であり、文書自身が開発中と明記する。実装方式や採用時期が決まったと読むのは早い。

そこで、一般読者、タクソノミ設計、規制報告、API、AI、監査、仕様検証、編集の8人が24ターン議論した。中心の問いは、OIM Taxonomyが何を新しく扱おうとし、何をまだ解決していないのかである。

OIM Reportは先に進み、タクソノミが残った

OIMという言葉は今回初めて登場したわけではない。Open Information Model 1.0は2021年にRecommendationとなり、XBRLのレポートを構文から切り離して定義した。その結果、同じOIM Report ModelをxBRL-XML、xBRL-JSON、xBRL-CSVで表せる。

ところが、その仕様はタクソノミが持つラベル、参照、計算関係、表示・検証用の構造まではモデル化しなかった。値を運ぶ側はXML以外へ広がったのに、値の意味を定義する側にはXML SchemaとXLinkを組み合わせた従来構造が残ったのである。

レン（OIM Taxonomyを初めて知る一般読者）は、「数字をJSONで読めるようになったのに、辞書は複雑なXMLのままだったということか」と尋ねた。

ユウ（XBRLタクソノミ設計者）は、それだけではないと答えた。従来タクソノミの別構文を作るだけなら、情報の見せ方を変えるにとどまる。Requirements文書は、従来機能の整理に加え、提出制約、拡張制限、fact attributes、add-on bundleなど、これまで標準として扱いにくかった領域を要件として挙げている。

「外にあったルール」を内側へ寄せる

規制報告では、タクソノミだけを読んでも提出要件が全部分かるとは限らない。「会社名は必須」「この条件なら別の項目も必要」「このディメンションには独自メンバーを追加できない」といった規則が、人間向けのfiling manualに書かれることがある。

Requirements文書は、すべての法令をプログラムへ変換するとは言っていない。しかし、必須のfact positionなど単純な制約を宣言的に記述し、別冊マニュアルやFormulaへの依存を減らす目標を掲げる。ここでいう宣言的とは、複雑な判定手順を書くのではなく、「この報告位置は必須」「この属性に入るのはこの候補だけ」のように、満たすべき条件を構造として示すことだ。fact positionとは、会社・期間・ディメンション値などの組合せで特定される「値が入るべき住所」である。

企業拡張も対象になる。公開財務報告では、提出企業が固有のコンセプトやラベルを加えることがある。OIM Taxonomyの要件案では、ベースタクソノミ側が「新しいコンセプトは追加してよいが、既存ラベルは削除できない」「このドメインにはメンバーを追加できない」のように、変更可能な範囲を部品単位で制約できるようにする。

ミナ（規制報告データの運用専門家）は、これを「マニュアルをなくす話」ではなく、「ソフトウェアが提出前に案内できる規則を増やす話」と整理した。法令の例外や判断まで、単純な必須条件と同じように表現できるとは限らないからだ。

表はRequirements 1.0を基にした編集部の整理であり、完成仕様の機能一覧ではない。

表中のtaxonomy-supplied factsも、これまでにない発想を含む。たとえば、ある制度を使う全報告に同じ税率を適用するなら、各提出者が同じ値を繰り返し入れるのではなく、タクソノミが共通ファクトとして供給する。運用上は、税率が変わったときにどの版を使ったかを追跡できることが重要になると考えられる。ただし、Requirements文書は、その版管理や更新権限の具体策までは示していない。

「推計」は、新しいディメンションではない

OIM Taxonomyの提案で、一般読者にも違いが見えやすいのがfact attributesである。Requirements文書は、値に付けたい追加情報として、次の例を挙げる。

• 統計上の状態：推計、予測、暫定
• 変更・訂正：同じfact positionに以前報告した値を置き換えること
• 監査状態：監査済みか、監査日、監査人など

これらは会社、期間、地域、製品のように「どの値か」を分けるディメンションとは性格が違う。売上高100億円が推計から確定へ変わっても、別会社・別期間の売上高になったわけではない。そこで、同じfact positionの値に付く属性として扱う構想である。

レン（OIM Taxonomyを初めて知る一般読者）は、「監査済みという属性が付けば、数字が正しいと考えてよいのか」と尋ねた。

シン（監査データと情報ガバナンスの専門家）は、強く否定した。属性は「この値について、どのような監査状態が報告されたか」を機械可読にする器であり、監査の範囲、手続、結論を自動で保証しない。「監査済み」という語彙の定義、誰が付けられるか、変更履歴をどう残すかも運用上の論点になるが、Requirements文書は具体策を定めていない。

コウ（API・JSON・データ基盤設計者）は、ここに新しい複雑さが生まれると反論した。何をディメンション、property、attributeとして表すかの選択肢が増えれば、従来の「同じ要件を複数方式で表せる」問題を再生産しかねない。OIM Taxonomyが単一の推奨方法を促すなら、その境界を分かりやすく定められるかが重要になる。

add-on bundleは便利だが、「何を重ねたか」が結果を変える

現在のXBRL 2.1では、報告書が参照するURL群によってDTS（Discoverable Taxonomy Set、その報告に必要なタクソノミ文書一式）が実質的に固定される。公開後に第三者が翻訳ラベルやデータ品質規則を作っても、利用者が標準的な方法で後から重ねにくい。

OIM Taxonomyの要件案は、元のタクソノミを対象として明示するadd-on bundleを想定する。たとえば、公式タクソノミへ第三者の日本語訳を加える、受領拒否には使わない追加の品質チェックを加える、といった用途である。

マコ（AI・データ分析エンジニア）は、AIにとって有用な可能性を認めた。ラベル、定義、関係、品質規則を構造として選択的に渡せれば、巨大なXML文書群をそのまま読ませるより、必要な文脈を絞りやすい。

一方でマコ（AI・データ分析エンジニア）は、同じファクトでも、どのbundleを適用したかで、翻訳や品質判定が変わり得ると指摘した。AIの回答を再現するには、入力したファクトに加え、使ったタクソノミ、add-on bundle、変換設定などを記録することが有用だと考えられる。ただし、版管理や適用記録の具体方式はRequirements文書に定められていない。OIM Taxonomyが「AI-ready」を目標に掲げることと、AIの答えが自動的に正確・再現可能になることは同じではない。

CSVの公開データも、タクソノミの対象になる

XBRLの普及は、規制当局がタクソノミを作り、提出者がそれに従う場面に大きく支えられてきた。しかしRequirements文書は、データ公開者が自らタクソノミを選ぶdata publicationも明示する。

たとえば大量の統計をCSVで公開するとき、列名と値だけでは、項目の説明、翻訳、根拠となる定義、分類階層が別のページへ散らばる。xBRL-CSVとタクソノミを組み合わせれば、CSVの扱いやすさを保ちながら、それらのメタデータを結び付けられる。

これは第6回で見た「決算書以外のXBRL」にもつながる。OIM Taxonomyは、財務報告特有のbalance属性や必須のperiodをすべての報告タイプへ押し付けず、異なるreport typesを扱う要件を掲げる。財務諸表向けに育った仕組みを、統計、行政、監督など別種の報告にも適用できるモデルにすることが目標の一つである。

その一方、表形式の報告にはTable Linkbase、xBRL-CSV、xBRL-CSV Table Constraintsという、異なるが一部重なる仕組みがある。Requirements文書は、OIM Taxonomyの開発を通じて、これらを整合的にする将来ロードマップを作るよう求めるにとどまり、統合を決めてはいない。Table ConstraintsはxBRL-CSVメタデータで基本的な検証を高速に行う別仕様であり、OIM Taxonomyへ統合済みでも、Formula全体を置き換える仕様でもない。

AI-readyは「AIが正しく読める」の完成宣言ではない

XBRL Internationalによる2026年2月の説明は、OIM Taxonomyをsimple、modern、AI-readyにする取り組みとして紹介した。Requirements文書も、xBRL-JSONのファクトはLLMで利用しやすい一方、現在のタクソノミ情報は効果的に使いにくいという調査結果を背景に挙げる。

Requirements文書が掲げる機能から、編集部がAI利用で改善の余地があると考えたのは、次のような点である。実装や精度向上が実証されたという意味ではない。

ここでいうpropertyは、タクソノミ内のオブジェクトへ「この項目にはこの種類の情報を付けられる」と定義する型付きのメタデータである。報告値ごとの状態を表すfact attributeとは対象が違う。

1. XML SchemaとXLinkのファイル配置を追わず、タクソノミのオブジェクトを直接参照する
2. propertyと型を見て、コンセプト、ディメンション、関係の役割を区別する
3. 必須条件や拡張制限を、人間向けマニュアルだけでなく宣言的制約から読む
4. 必要な言語ラベルや品質規則だけをadd-on bundleとして加える
5. fact attributesから、推計・暫定・訂正・監査状態を値と分けて扱う

しかし、これらは利用しやすい入力を作る目標である。企業拡張が標準コンセプトと本当に同じ意味か、報告期間と連結範囲が分析目的に適切か、出典のどこまでが監査対象かをLLMが自動保証するものではない。

ナオ（標準仕様と一次資料を検証するリサーチャー）は、「AI-ready」を性能実績として書かないよう求めた。現時点で確認できるのは、標準団体がAIによる消費をRequirementsの目標へ入れたことまでである。OIM TaxonomyのPublic Working Draftも、相互運用実装も、利用効果を測る独立評価もまだ確認できない。

Periodを「全ファクト必須」にしない

もう一つ、財務報告以外へ広げるうえで重要な要件がある。XBRL 2.1のXML構文では、entity（誰の報告か）とperiod（いつの報告か）を明示する必要がある。一方、既存のOIM Report Modelは、entityとperiodをモデル上はoptionalとしている。

Requirements文書の「Support for different report types」は、この背景を明記している。XBRL 2.1は多様な報告に使われている一方、balance属性やmandatory period dimensionなど、財務報告の必要に合わせた機能を持つ。そのうえで、OIM Taxonomyはより広いreport typesを支援し、特定の報告タイプだけに必要な機能はoptionalにするか、仕様本体から外して拡張機能で実現すべきだとしている。

OIM Taxonomy RequirementsのREQ-DIM002は、さらに一歩進め、ハイパーキューブごとにperiod、unit、entityなどのcore dimensionsをrequired（必須）、optional（省略可能）、prohibited（使用不可）として制約できるよう求める。ここでいうハイパーキューブは、「この種類のファクトでは、どの軸を使ってよいか」を定める報告領域である。なお、何の項目かを示すconcept core dimensionは全ファクトで必須とされている。

これは単に入力項目を減らす話ではない。財務諸表の売上高なら期間は意味の一部なので、タクソノミがperiodをrequiredにできる。一方、固定的なコード一覧など、報告期間という軸を各ファクトへ持たせる意味が薄いデータでは、optionalまたはprohibitedにできる可能性がある。省略できるかどうかを提出者任せにせず、報告領域ごとにタクソノミが宣言する点が重要である。

「意味のないentityやperiodを毎ファクトへ強制しなければ、XBRLで自然に扱えるデータの幅が広がる」というのは、Requirementsの目的とREQ-DIM002を合わせた編集部の解釈である。文書はこの一文をそのまま掲げてはいないが、広いreport typesへの対応、財務報告固有機能のoptional化、core dimensionsのrequired／optional／prohibited指定を、それぞれ明示している。

省略可能でも、制約がなくなるわけではない

この点をラウンドテーブルで掘ると、レン（OIM Taxonomyを初めて知る一般読者）は「Periodを省略できるなら、何でも雑に記録できるのか」と尋ねた。

ミナ（規制報告データの運用専門家）は逆だと答えた。REQ-DIM002が目指すのは制約を外すことではなく、報告領域ごとにrequired／optional／prohibitedを宣言することだ。財務諸表ではperiod・entity・unitをrequiredにし、別のデータでは意味のない軸をprohibitedにする。optionalは曖昧さを放置する欄ではなく、同じモデルを複数の報告種別で使うための切り替えである。

ナオ（標準仕様と一次資料を検証するリサーチャー）は、Requirementsの第13章がrecord-based dataとして、event、reference、position、listing、time-seriesを列挙していることを確認した。さらに、レコード内の必須・任意フィールド、重複禁止、primary key、foreign keyを定義できる要件も置かれている。

データの例	Requirementsから読める方向	編集部の具体化
イベント台帳	event dataでは日付・時刻を含む必須フィールドを想定	財務periodではなく、イベント発生日をキーにする
銘柄・製品コード表	reference／listing dataを対象にする	全行に財務期間を付けず、コードと定義を結び付ける
設備稼働率などの測定値	time-series dataを対象にする	測定時点や間隔、対象設備を報告領域の要件にする

この表の具体例は、Requirementsが列挙したデータ種別を日常的なデータへ置き換えた編集部の説明であり、完成仕様の保証ではない。reporting requirements taxonomyが各fact positionやrecord fieldをmandatoryに定めることが前提になる。

コウ（API・JSON・データ基盤設計者）は、optionalを増やしすぎると、同じ「売上」でも期間なし・単位なしの値が混在し、比較やAI解釈で事故が起きると反論した。だからこそ、AIに読ませるときは「このreport typeでrequired／prohibitedなcore dimensionsとrecord keyをタクソノミから列挙し、根拠をREQ番号付きで示せ。推測は禁止」と指示する必要がある。省略可能という設計は、タクソノミの制約を読む作業とセットで初めて役に立つ。

残すもの、変えるもの、まだ決まっていないもの

OIM Taxonomyを「全面刷新だけ」または「互換レイヤーだけ」のどちらか一方とみなすのは正確ではない。Requirements文書は、一般に使われ、現在の推奨実務に沿うXBRL 2.1の構造をOIMへ変換できるよう求める。一方で、XML構文で可能なすべてを再現する必要はないとする。既存タクソノミの表現方法が違えば、変換時に設定が必要になる場合も認めている。

この表は完成仕様の欠陥を断定したものではない。現時点で要件として文書化された範囲と、Requirements段階ではまだ答えを確認できない問いを並べたものである。

テツオ（一般読者向けの記事を点検する編集者）は、記事の結論を「何ができそうか」の一覧で終えないよう求めた。重要なのは、標準として扱い直そうとしている範囲と、現段階の文書にはまだ書かれていない範囲を分けることだという。

討論では、add-on bundleの版・提供者を誰が管理するか、既存タクソノミの変換設定をどこへ記録するか、その記録を監査証拠としてどう残すかも争点になった。しかし、これらをOIM Taxonomyが意図的に制度側へ任せたのか、Requirements文書がまだ答えていないだけなのかは、現時点の一次資料から区別できない。

結論：XBRLの「外側」を、設計の対象に戻す

OIM Taxonomyが作り直そうとしているのは、XMLファイルの見た目ではない。

現在のXBRLタクソノミは、会計や規制報告の複雑さを長年引き受けてきた。その結果、機能はXBRL 2.1、Dimensions、Generic Links、Calculationなどへ分かれ、提出規則の一部は別冊マニュアルへ、翻訳や品質規則は既存タクソノミへ後から標準的に重ねにくい状態へ、値の状態は現在のモデルで直接表しにくい情報として残ることがある。

Requirements文書が次の世代のモデルで目標として掲げるのは、次のような再整理である。

• 意味をXML SchemaやXLinkの書き方から切り離す
• 同じ報告要件には推奨される一つの表し方を促す
• 提出規則と企業拡張の許容範囲を機械可読にする
• 推計・暫定・訂正・監査状態を値の属性として扱う
• period、entity、unitなどのcore dimensionを報告領域ごとに必須・省略可能・使用不可とする
• 翻訳と品質規則を後から選択的に追加する
• 財務報告以外の大規模な表・CSV公開にも適用できるようにする
• AIがタクソノミの意味を取り出しやすくする

これは、これまでXBRLとして扱いづらかった領域を要件の対象に加える方向転換である。同時に、Requirementsは完成品ではない。属性の共通語彙、bundleの信頼性、既存資産の移行記録、AI分析の再現性まで解決済みではない。

OIM Taxonomyの価値は、XBRLを単純にするという約束だけにない。

別冊マニュアルや現在の構造では直接表しにくかった情報のうち、どこまでを標準モデルの対象にできるかを問い直したことにある。

今後、最初のPublic Working Draftが出たときに見るべきなのは、JSONらしい見た目かどうかではない。推計値、企業拡張、提出制約、翻訳、品質規則が、異なる実装でも同じ意味として再現できる設計になったかである。

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

• XBRL International「XBRL Taxonomy Model Requirements 1.0」：OIM Taxonomyの正式な目標、対象機能、既存XBRLとの変換要件、企業拡張、選択的読込、add-on bundle、fact position、properties、fact attributes、core dimensionsのrequired／optional／prohibited指定、異なるreport types、tabular reportingを確認した。開発中のRequirements文書であることも同文書から確認した。
• XBRL International「Setting the direction for the future of XBRL taxonomies」：Requirements 1.0公開の位置付けと、従来のOIM Report Modelより実質的な変更を想定することを確認した。標準団体による説明として扱った。
• XBRL International「XBRL prepares for its next chapter」／「Progress on modernising XBRL」：2026年2〜3月時点の作業状況と、単純化・性能・AI利用という目標を確認した。実装済み性能の独立評価とは扱っていない。
• XBRL International「Introducing the OIM」／OIM 1.0 Recommendation：既存OIM Report Modelが構文非依存の報告モデルを定義し、xBRL-XML、xBRL-JSON、xBRL-CSVを支える一方、タクソノミ情報を対象外としていたことを確認した。
• XBRL International「Core Taxonomy Information 1.0」：タクソノミ情報を構文非依存に扱う先行段階と、必要な情報だけを扱うことによる性能・利用性改善の考え方を確認した。
• XBRL International「xBRL-CSV Table Constraints 1.0」：大規模表データへ必須・列挙・一意キー・参照キー等を効率的に適用する仕様がProposed Recommendation段階であることを確認した。標準団体の解説と併せ、Formulaを全面置換するものとは扱っていない。