ブログに戻る
engineering

すべての数値に住所がある

Onkar Dahale

LLMにトヨタの売上高を聞くと「約37兆円」と返ってきます。Axioraに聞くと 37,154,290,000,000 — XBRL要素名（jppfs_cor:Revenue）、EDINETの書類ID（S100TQGZ）、EDINETビューアへの直リンク付きで返ってきます。

この違いは重要です。「約37兆円」は昨年の数字かもしれないし、子会社の数字かもしれないし、四捨五入したブログ記事から生成された幻覚かもしれません。S100TQGZの37,154,290,000,000は、トヨタがFY2024の有価証券報告書で報告した数値であり、構造化XBRLからパースされ、特定の届出まで追跡可能です。

これが「すべての数値に住所がある」ということです。

住所の中身

Axiora APIが返すすべての財務データには source オブジェクトが付きます：

{
  "fiscal_year": 2024,
  "revenue": 37154290000000,
  "source": {
    "doc_id": "S100TQGZ",
    "edinet_url": "https://disclosure2.edinet-fsa.go.jp/WZEK0040.aspx?S100TQGZ",
    "filed_at": "2025-06-25T15:30:00+09:00"
  }
}

フィールドレベルの詳細を返すツールでは、さらに深く：

{
  "field_sources": {
    "revenue": {
      "xbrl_element": "jppfs_cor:Revenue",
      "context_ref": "CurrentYearDuration_ConsolidatedMember",
      "accounting_standard": "JP-GAAP",
      "period_start": "2024-04-01",
      "period_end": "2025-03-31"
    }
  }
}

これは後付けのメタデータではありません。数値を取得するデータベース結合と同じパスで出典情報が構築されます。

AIエージェントにとっての意味

AIエージェントがAxioraのMCPツールを呼び出すとき、出典情報は常に含まれます。エージェントがソースを要求する必要はなく、すべてのレスポンスに付いてきます。

  1. 出典を引用できる。「トヨタのFY2024売上高は37.15兆円（S100TQGZ、2025年6月25日届出）」は検証可能。「約37兆円」は検証不能。

  2. 鮮度を検出できる。 filed_atのタイムスタンプで、今年の報告書か昨年のものか判断できます。鮮度検証と組み合わせれば、古いデータはユーザーに届く前にフラグが立ちます。

  3. nullを説明できる。 フィールドがnullのとき、理由がわかります。IFRS企業はoperating_incomeを報告しません（必須項目ではないため）。日本基準企業はIFRSのordinary_incomeを報告しません。欠損データではなく、会計基準の構造的な違いです。

  4. 比較に注意書きを付けられる。 トヨタ（日本基準）とソニー（IFRS）の売上高を比較する場合、比較可能性の警告が自動的に発火します：日本基準の「売上高」とIFRSの「収益」はスコープが異なります。

強制装置としての出典情報

出典情報は誰かに頼まれて作ったのではありません。システムの他のすべての部分を正しくするために作りました。

すべての数値に出典を付けると決めたら、手を抜けなくなります：

  • パーサーは決定論的でなければならない。 同じ届出は常に同じ値を出力する必要があります。連結vs個別のコンテキスト解決、iXBRLと従来のXBRL、タクソノミ優先順位による重複排除 — すべてを処理し、再パースでもビット単位で同一の出力を生成します。665以上のテストケースで検証しています。

  • nullは隠さず説明しなければならない。 存在しない数値に出典は付けられませんが、なぜ存在しないかは説明できます。オントロジーは、どの会計基準でどのフィールドが構造的に欠落するかを知っています。

  • クロスソースの不一致は表面化しなければならない。 EDINET有報で37.154兆円、TDNet決算短信で37.5兆円 — どちらも「正しい」ですが、異なる届出で異なるスコープです。検証レイヤーがEDINETとTDNetをクロスチェックし、0.1%以上の差異をフラグします。

  • 算出指標は計算過程を見せなければならない。 健全性スコア、成長率、資本配分分類はXBRL値そのものではなく、XBRL値から計算されます。各算出指標は計算式、入力値、その入力値の出典届出を公開します。

アーキテクチャ

Axioraの出典情報はレスポンスレイヤーであり、エンドポイントごとのロジックではありません。単一のモジュール（provenance.py）が出典構築を担当します：

  1. 届出レベルの出典: {doc_id, edinet_url, filed_at} — コンパクト、常に利用可能。
  2. フィールドレベルの出典: {xbrl_element, context_ref, accounting_standard, period_start, period_end} — XBRL要素データがある場合に利用可能。
  3. 算出指標の出典: {formula, inputs, source_filing} — 健全性スコアなどの計算値向け。

REST APIは要求時に出典を含めます（?include=sources）。MCPインターフェースは常に含めます — AIエージェントはすべての呼び出しで出典情報の恩恵を受けるため、オプトインは不要です。

両方のインターフェースが同じ出典モジュールを呼びます。1つのコードパス、2つのトランスポート。

これが可能にすること

すべてのデータポイントに出典があれば、そうでなければ不可能な機能が構築できます：

  • 監査証跡: ファンドマネージャーはレポート内の任意の数値をEDINET届出まで遡れます。edinet_urlをクリックすればソースドキュメントが表示されます。

  • 再現性: 明日同じ企業をクエリしても、新しい届出が公開されない限り、同じ数値が同じ出典で返ってきます。レスポンスメタデータのcomputation_versionが、どの計算式バージョンで結果が生成されたかを示します。

  • 比較可能性の警告: 2社が異なる会計基準を使用していること — または同じ基準内でも異なる売上高概念を使用していること — をオントロジーが検出すると、レスポンスに自動的に警告が表示されます。

金融データ業界は何十年も「数値は正しいので信じてください」で運営してきました。基準はもっと高くあるべきです。すべての数値に住所があるべき。すべてのnullに理由があるべき。すべての比較に注意書きがあるべき。

それがAxioraの設計思想です。

Axioraは日本の上場企業4,000社以上の構造化財務データをREST APIとMCPで提供しています。ドキュメントを読む、またはアーキテクチャを見る。