組み込み

検証器まで自前で作らないでください。検査だけお任せいただければ結構です。

MirrorMere は XBRL を作りません。作られたものを検査します。画面も、業務の流れも、配備の制約もそのままで結構です。検査はその下で行われます。

技術評価を依頼する一緒に解くということ

いま使える組み込み方

実際の準備状況のまま記します。

提供前のものを提供中とは書きません。ロードマップにあるものはロードマップと書きます。

提供中

Java SDK

ビルドに jar をひとつ入れて呼ぶだけです。別途動かしておくエージェントもサービスもありません。

提供中

CLI・バッチ

コマンドラインやバッチから走らせる jar ファイル 1 つです。すでにお使いのパイプラインにそのまま組み込めます。

提供中

コンテナ・プライベート配備

閉じた社内網の中でも制約なく動きます。文書に関する情報が外へ出ることはありません。

個別協議

OEM・ホワイトラベル

すでに販売されているソリューションに、合う形で組み込んでみてください。条件は案件ごとに取り決めます。

予定

REST API

HTTP 上で動く XBRL API は 2026 年下半期の提供予定です。

MirrorMere は表に出ません。

Java SDK

どこが、なぜ誤りなのか、そして何を見ればよいかまで返ります。

返ってくるのはエラーコードの一覧ではありません。文書のどこなのか、どの条項に触れたのか、だから開示書類を持つ人が何を見ればよいのかが一緒に届きます。Dimensions で引っかかっても Inline XBRL で引っかかっても同じ形で来るので、そのまま担当者の前に置けます。

ValidationOutcome outcome = validator.validate(report);

for (ValidationFinding f : outcome.errors()) {
    f.code();      // what went wrong
    f.specRef();   // the clause it breaks
    f.location();  // where in the document
}

一度呼べば、レビューに要るものはすでに全部入っています。どこが、なぜ、何を直すのか。

CLI・バッチ

コマンド三つですべて足ります。ほかには何も要りません。

validate: 開示書類を検査します。提出パッケージでも、複数に分かれた Inline XBRL ファイルでも、単体の文書でも受け取ります。ひとつの届出に属する複数ファイルは、まとめてひとつとして見ます。
cts: 公開されている標準テストをご自身で走らせます。全部でも、気になる部分だけでも構いません。認証ページの数値はここから出ています。
doctor: 結果を信じる前に、まず環境を点検します。タクソノミが所定の場所にあるか、環境に問題はないか。ファイルが欠けていれば、後で「異常なし」として流れる代わりに、ここで設定の問題として挙がります。

閉域網

インターネットにつながらない場所でも、そのまま動きます。

財務や監査の部署は、インターネットから切り離された網で仕事をしていることが少なくありません。検証に必要な資料をインターネットから取ってくるエンジンは、そこで止まります。もっと困るのは、検証を削ったまま何も言わずに通してしまう場合です。MirrorMere はそもそも外に出ません。

検証に使うタクソノミはファイルとして手元に置いていただきます。実行中にどこかから取ってくることはありません。
必要なファイルが欠けていれば、欠けていると告げます。代わりに通してしまうことはありません。
実行のたびに、どのタクソノミを使ったかを記録します。二つの環境で結果が違えば、言い争う前に突き合わせられます。
外に出る通信そのものがありません。利用状況もライセンス確認も送りません。

すでにオープンソースの道具をお使いなら

オープンソースでも構いません。

無料で使えるオープンソースの XBRL 検証ツールがあり、なかには当社と同じ Validating Processor 認証を受けたものもあります。たまに開示書類を一度検査する程度なら、それで足ります。検証を組み込んだ製品を販売される場合には、さらに三つが必要になります。

別に立てておくプログラムではなくライブラリ

MirrorMere は製品の中に入るために作った Pure Java のライブラリです。ビルドにファイルをひとつ入れ、コードから直に呼びます。別に立てておくプロセスも、間に架ける橋もありません。

尋ねる先があります

仕様が改訂されたとき、追随するのは当社の義務です。待つ側に回らずに済みます。詰まったときは、エンジンを書いた者に直接届きます。

なぜかまで答えます

MirrorMere は XBRL を移したオントロジーの上で推論します。ですから判定には、どこが・どの条項に触れたか・何を直すのかが一緒に届きます。開示書類を手にしている人がそのまま読んで直せる言葉で。

どちらか一方に絞る必要もありません。両方を並べて結果を突き合わせるのも妥当なやり方です。異なる実装が同じ答えを出せば、その一致自体が根拠になります。

標準への対応

仕様は変わり続けます。追いかけるのは当社の仕事です。

一度入れたら何年も使うものです。ですから仕様が改訂されれば当社が追随し、標準テストをすべて通り直すまでは何も出しません。ご質問はエンジンを作っている者に直接届きます。

テストを通ってから出します

版を出す前に標準テストをすべて通す必要があります。ひとつでも壊す変更は御社まで届きません。

改訂はひとつのモジュールで収まります

仕様が改訂されても、直すのはそのモジュールだけです。お使いの残りの部分はそのままです。

エラーの定義は一か所にまとめています

エラーの意味と根拠条項は、コードのあちこちではなく一か所にまとまっています。仕様が変わっても直す場所はひとつなので、反映が速く、抜けが起きにくくなります。

バージョン: 結果には、それを出したバージョンが必ず添えられます。数か月後に答えが変わったとき、何が変わったのかをたどれます。
仕様改訂への追随: 仕様や標準テストが改訂されたら、新しい版を出す前にテストを全量やり直します。
技術支援: エンジンをつくっている者と直接つながります。手前をふさぐ受付の列はありません。
配備: オンプレミスや閉域網での配備は例外ではなく前提です。改めて交渉することではありません。
評価用ライセンス: 評価期間中にお使いいただくライセンスをお渡しします。お試しの間は人数や件数の制限を設けません。
第三者ライセンス: 同梱する外部ライブラリとそのライセンスを配布物に一緒に入れてお渡しします。法務レビューにそのまま回せます。

「なぜ」を探し回る時間がなくなります。

まずご連絡を

何をつくっておられるか、お聞かせください。

何を作っておられるのか、どこで詰まっておられるのかをお聞かせいただければ、一緒に解いていきます。MirrorMere の値打ちはファイル一つではなく、そこにあります。

エンジンとコマンドライン実行ツール、標準テストのツールを一式でお渡しします。当社が使っているものと同じです。
こちらが選んだ例ではなく、実際にお使いの開示書類で回してみてください。
このサイトに書いた数値は、すべてご自身で出し直せます。テストは公開されており、実行ツールも同梱されています。
資料をやり取りする前に、まず秘密保持契約を結びます。

メールがよろしければ、そのままお送りください。 manager@codebplat.co.kr