問い合わせが減ります
このエラーはどういう意味かという質問が減ります。答えは結果の中にすでにあります。
構造
ひとつのオントロジーの上から、What・Why・How がそろって出ます。
検証器はたいてい What で止まります。何かが誤っているとだけ告げ、なぜか、ではどうするかは受け取った人に委ねます。MirrorMere は三つをそろえて出します。それができるのは、XBRL そのものをオントロジーとして築いているからです。
- What — 何が引っかかったか
- 文書のどの位置、どの値が引っかかったのかを名指しします。エラーコードだけ投げて探せとは言いません。
- Why — なぜ引っかかったか
- どの規則が捕らえ、その規則がどの条項を実装したものかまで一緒に届きます。数か月後に監査人が尋ねても、これがそのまま答えになります。
- How — ではどうするか
- 何が誤りかではなく、何を直すのかを書きます。エンジンを作った者ではなく、開示書類を手にしている人が読むための文です。
- 根拠 — XBRL オントロジー
- XBRL の概念と規則、エラーとその条項をオントロジーとして整理してあります。上の三つは、検証しながらその上で推論して得られます。
オントロジーと推論
「なぜ」を言えるのは、XBRL そのものをオントロジーとして築いたからです。
エラーコードしか吐かない検証器は「なぜ」を語れません。ここでは概念と規則、エラーとその根拠条項がひとつのオントロジーにまとまっており、判定はその上で SHACL が推論した結果です。推論の過程がそのまま理由になります。
ixbrlo:illegalMultipleUseOfId
a owl:Class ;
rdfs:subClassOf ixbrlo:ValidationError ;
rdfs:comment "id attribute reused across iXBRL elements that require uniqueness."@en ;
skos:note "Inline XBRL 1.1, Section 3 — ixe:illegalMultipleUseOfId"@en ;
skos:note "Inline XBRL 1.1, Section 4 — ixe:illegalMultipleUseOfId"@en ;
owl:equivalentClass <http://www.xbrl.org/2013/inlineXBRL/errors#illegalMultipleUseOfId> .語彙は W3C 標準、最後の行が指すのは XBRL International が公表するエラー識別子です。当社が作った名前はありません。
Why Path
エラーコードではなく、どの条項かが見えます。
エラーコードは、何かがおかしいとしか言いません。Why Path は、どのオブジェクトが、どの規則の、どの条項に引っかかったかまで示します。書類を手にした人がその場で直せて、あとで理由を問われても根拠を出せます。
直すまでが短くなります
どのオブジェクトか、どの条項かが名前で出ます。探し回る必要がありません。
判定を説明できます
監査人や規制当局に理由を問われれば、その道筋がそのまま答えになります。
入力
検証したファイル。
規則
XBRL 2.1 §3〜§5 の検査が走りました。
条項
違反 2 件。いずれも XBRL 2.1 §5.1.3.4 に結び付いています。
直すところ
ロール http://xbrl.org/role/conformance は link:label には使えません。
最後の 1 行が要点です。何が誤りかではなく、何を直せばよいかを示します。
信頼できる結果
このエンジンが「合格」と言えば、合格です。
検証結果は監査や提出の根拠になります。だから大事なのは二つです。答えがぶれないこと、そして「合格」が本当に合格を意味すること。推測や確率で答える部分がないので、同じ文書を百回入れれば百回同じ答えが出ます。
根拠なしに指摘しません
指摘には必ず、どの条項によるものかが付いてきます。触れる条項がなければ、ないと答えます。その指摘が本物かどうかを確かめるために人手を割く必要が減ります。
見ていないものを合格とは言いません
事情があって回せなかった検査は未実行と明記し、合格件数とは別に数えます。黙って通り過ぎたものがないので、異常なしという結果をそのまま受け取れます。
版を上げても結果は変わりません
標準テストはビルドのたびに一緒に走り、ひとつでも壊す変更は出ていきません。新しい版を入れたからといって、先月の結論がひっくり返ることはありません。
- 結果を出したバージョン
- どの結果でも、どのビルドから出たかをたどれます。
- 実行環境
- 食い違いが文書のせいか環境のせいかを分けてくれます。
- どのタクソノミを読んだか
- 双方が同じタクソノミを見ていたかどうかを、一行で突き合わせられます。
- 見つからなかったファイル
- この値がゼロでなければ、その分だけ検査できていないということです。黙って通す代わりに、その事実をそのまま書きます。
もう一度回しても、同じ答え。
検証コア
仕様ひとつにモジュールひとつ。
仕様ごとにモジュールが分かれています。エンジンをまるごと入れても、実際に扱うものだけを選んでも構いません。
| 仕様 | 何を検査するか |
|---|---|
| XBRL 2.1 Core | 数値と期間、単位、勘定定義が食い違っていないか |
| XBRL Dimensions 1.0 | 部門や地域といった内訳が、許された組み合わせになっているか |
| XBRL Formula 1.0 | 会社や規制当局が別に定めた計算・検査の規則に合っているか |
| XBRL Table Linkbase 1.0 | 規制当局が定めた表の様式どおりに出るか |
| Inline XBRL 1.1 | 人が見る画面と機械が読むデータが食い違っていないか |
| Open Information Model 1.0 | 同じ内容を XML・JSON・CSV に移しても意味が変わらないか |
| Extensible Enumerations 1.0 / 2.0 | 定められた一覧から選ぶ項目が、本当にその一覧の値になっているか |
| Report Packages 1.0 | 提出のひとまとめが規格どおりに作られているか |
| Taxonomy Packages 1.0 | タクソノミの配布物が規格どおりに作られ、インターネットなしで解決できるか |
| Units Registry 1.0 | 通貨・株式数・百分率といった単位が標準登録簿どおりか |
| Link Role Registry 1.0 | 標準登録簿に載っている役割名を正しく使っているか |
| Transformation Rules Registry v3 / v4 / v5 | 画面の「1,234」や「2025 年 3 月」をデータ値に移す変換が規格どおりか |
Calculation 1.1 はコアに同梱されています。どの組み合わせを選んでも、返る結果はすべて同じ形です。
Pure Java と速さ
標準テスト全体が約 20 秒で終わります。
Pure Java なのでネイティブコードも、別途入れるものもありません。それでいて、テスト全体をビルドの中で回せるだけ速い。リリースのたびに一度ではなく、何かを変えるたびに、です。
100%
XBRL International 検証試験を通過
~20s
全体を回すのにかかった時間
0
別途入れるもの
所要時間は機材によって変わります。大事なのは正確な数値ではなく桁です。テストは公開されているので、お手元の機材で実際に測れます。
Java 17 以上
JVM が動く場所ならどこでも動きます。別途の導入物も、同梱すべき外部プログラムもありません。