財務諸表の階層化の仕組み

標準化した列だけを配る形は扱いやすい一方、名寄せ後のキーだけに頼ると、会社独自の科目（拡張タグ）は落ちてしまいます。ZENITH Code は両方を別の出力として用意しています。

1. 1

   表示リンク → 木と並び順

   親子関係と並び順（order）から木を作り、その順で並べます。

2. 2

   役割（ロール）→ どの計算書か

   表示リンクの役割の識別子から、貸借対照表・損益計算書・キャッシュ・フロー計算書・包括利益計算書・株主資本等変動計算書・概況のどれかに分類します。

3. 3

   計算リンク → 足し引きの関係

   どの科目がどの合計に、足す（+1）か引く（−1）かを読み取り、小計の判定と検算に使います。

4. 4

   ラベル → 科目名

   まず提出者が付けた独自のラベルを使い、無ければ標準のラベル辞書で科目名を決めます。

/stable/financial-statement-full の応答では、計算書ごとの items 配列の 1 要素が決算書の 1 行です。各行には次の情報が付きます。

items は応答の statements.statements の下に、計算書の区分（BS・PL・CF・CI・SS など）ごとに入っています。行の識別に使う key や tree_tag も付きます。

• check_circle名寄せできなかった行は master_key が空になり、行のキーは科目名の英語表記と所属する区分の名前から作ります。
• check_circle名寄せは、完全一致 → 前方一致 → 接頭辞を除いた一致 の順に試します。
• check_circle同じ標準キーに、会計基準ごとの綴りのタグが競合した場合は、書類が申告した会計基準と綴りが合うほうを先に選び、その中で別名の優先順位と値の有無で決めます。
• check_circle競合に負けたタグも、項目としては残します。

名寄せの辞書は、標準の項目 308（XBRL のタグを対応づけている項目。ほかに計算・導出した項目が 71）と、約 4,700 通りの XBRL のタグ名からなります（辞書の定義の数で、実データでの一致件数ではありません）。

実際の例: 2026 年 9 月 16 日は、09:02 に短信を取り込み、09:16 に階層データの構築が終わりました。

実測では、TDnet の決算短信（XBRL 付き）は、開示から解析が終わるまで中央値で約 46 分、9 割が 50 分以内です（直近 30 日の 526 件で計測。2026-10-16 時点）。データの種類によって配信までの時間は違います。API に反映される時刻の目安は、ほかのデータと同じく、TDnet 由来が毎日 16:30、EDINET 由来が毎日 19:00（日本時間）です。

• check_circle同じ銘柄・同じ決算期・同じ四半期では、提出が新しい開示を優先します。
• check_circle貸借対照表・損益計算書などの区分ごとに、実際に数値を持っている最新の開示を採ります。
• check_circle業績予想と配当は常に決算短信から、セグメントなどは有価証券報告書から加えます。
• check_circle1 株あたりの指標だけは例外で、訂正の書類からのみ入れ替えます。

自己資本は、どの基準でも「親会社の所有者に帰属する持分」の意味にそろえています。どの取り方にするかは基準の名前ではなく、開示されたタグの組み合わせで判定します。

• check_circle売上は、表紙で名乗っている科目名を正とします。同じ期に 2 つの基準の値があるときは、後の基準を採ります。
• check_circle会計基準を移行した年は、申告した基準と違う基準の値を公開しません。
• check_circle連結の詳細な計算書があるのに単体の値しか無い項目は、連結の欄に載せず空欄にします。
• check_circle12 か月でない変則的な決算期は、年率で計算する指標から外します。
• check_circle決算期を変更したときは、12 か月の通期の行をそのまま残し、第 4 四半期の報告書を Q4 として加えます。
• check_circle四半期累計の書類や米国基準の書類などで詳細なタグが付いていないものは、概況（サマリー）だけを表示します。

1. 2026 年 8 月有価証券報告書（EDINET）の全量を、新しい処理で組み直しました。
2. 2026 年 9 月 6〜7 日全銘柄を再構築しました（約 8 時間）。事前に決めた 9 項目の受入確認のうち、複数が不合格でした。
3. 2026 年 9 月 8〜9 日修正したうえで再び実施し、受入確認に合格しました。

• check_circle検査 → 修正 → 再構築 → 再測定 を 1 回りとして繰り返します。
• check_circle検査には約 50 本の読み取り専用の確認クエリを使います。データを書き換えることはありません。
• check_circle件数が動いたら、データより先に検査の式を疑います。受入の条件は、実行する前に決めて固定します。
• check_circle提出者側の誤りは、補正のルールを作らず、1 件ずつ記録します。

2026-10-20 時点の集計です。

リクエストの例

curl "https://api.zenithcode.net/stable/financial-statement-full?symbol=7203&fiscalPeriod=2026-06&quarter=Q1" \
  -H "x-api-key: YOUR_API_KEY"

const res = await fetch(
  "https://api.zenithcode.net/stable/financial-statement-full?symbol=7203",
  { headers: { "x-api-key": "YOUR_API_KEY" } },
);
const [row] = await res.json();
const items = row.statements.statements.BS.items;

for (const it of [...items].sort((a, b) => a.sort - b.sort)) {
  const indent = "  ".repeat(it.depth);
  const label = it.is_subtotal ? `[${it.label_ja}]` : it.label_ja;
  console.log(indent + label, it.is_abstract ? "" : it.value);
}

このページはデータの作り方の説明です。データの正確性・完全性を保証するものではなく、投資の判断を勧めるものでもありません。