EDINET解析ガイド：書類・タグ・階層から、使いたい財務データを探す

企業の概要を知りたい段階と、分析用のデータを取得したい段階では、読む場所が違います。書類、項目、期間、表の構造を分けると、必要な作業を絞れます。

EDINETには、有価証券報告書だけでなく、有価証券届出書や大量保有報告書などもあります。提出者の名前が目的の企業に似ているだけで選ばず、書類種別と対象を確認します。金融庁：EDINETについて

例えば、ある企業の事業と年次の財務を調べたいなら、有価証券報告書が入口の一つです。一方、その企業の株式を誰が大量に保有しているかという問いでは、見る書類と提出者の関係が違います。

同じ書類の中でも、平均年間給与と連結従業員数の対象範囲が一致するとは限りません。「同じ報告書に載っている」ことと「同じ範囲で比較できる」ことを分けます。

会社を特定する情報だけでは、どの報告書を読んだかまでは決まりません。EDINET APIの一覧では docID が書類を識別する情報です。parentDocID などの関係情報や書類種別、訂正・取下げに関わる状態は、利用する仕様に沿って確認します。EDINET API仕様書

訂正報告書を見つけても、その一つに分析に必要な全数値が再収録されているとは限りません。元の書類と訂正内容を確認し、変更が必要な範囲を判断します。タイトルの文字だけで全体を置き換える設計は避けます。

タクソノミは項目の定義や関係、インスタンスは今回報告された値などを表します。値の対象と期間はコンテキスト、単位はユニットを確認します。これらは同じファイルの別の場所に記されていることがあります。

図は2026年版EDINETタクソノミの公式サンプルに含まれる一件を整理したものです。実在企業の業績やZENITH CodeのAPI応答を示す図ではありません。

例えば同じ売上高タグが複数あっても、前年・当年、連結・個別、セグメント別なら用途が違います。検索結果の先頭や最大値を採用する方法では、必要な条件を保証できません。

XBRLファイル内で要素が出現する順番を、そのまま財務諸表の表示順と考えないようにします。表示リンクは、項目の親子関係や順序を調べる材料です。

表示リンクの loc は項目への参照、presentationArc は項目間の関係をたどる手がかりです。order で順序、preferredLabel で表示に使うラベルの役割を確認します。同じ項目が異なる表の役割で使われることもあるため、関係が属するロールも残します。提出者別タクソノミ作成ガイドライン

表示上の子項目が全て足し算できるとは限りません。見出しや控除項目、符号、集計範囲などがあるためです。「親子関係を表示できた」と「小計を再計算して一致した」は、別の確認として扱います。

学習中の一件なら、元ファイルと公式定義を照合する方法で構いません。書類が増えたら、一度読んだ定義を再利用するキャッシュを考えます。キャッシュは、確認した内容を保存して、同じ定義を何度も読み直さない仕組みです。

ただし、見つけたタグを一つの名前だけで永続的に統合するのは避けます。タクソノミの版、名前空間、提出者別の定義、出典書類などを区別して残します。日本語ラベルが同じでも、必ず同じ意味とは限りません。

公開されている定義を集める処理と、分析用の共通項目へ対応付ける判断は別です。未知のタグを見つけたら自動で既存項目へ吸収する、という一段階の処理にしないことが大切です。

主要項目の推移を見たい場合と、一つの書類にあるタグを詳しく調べたい場合では、使うデータの形が違います。

APIで構造化されていても、用途に合う値かどうかの確認は残ります。例えば要素名を部分一致で検索した結果には、前年や別の範囲の候補が含まれる可能性があります。検索条件の一致だけで比較用の一行が完成するわけではありません。

最初は一社・一期・一項目を選び、応答の値と条件を確認します。その後、目的が推移なら年度を増やし、内訳なら同じ期間の範囲を広げます。一度に会社も年度も項目も増やさない方が、どの条件で結果が変わったかを確認しやすくなります。

• TDnet解析ガイド
• 財務データAPIの選び方

• EDINET解析①：書類の役割を理解する
• EDINET解析②：実際のタグ・コンテキスト・表示リンク
• 有価証券報告書のXBRL数値データAPI
• 会計基準による違い

私たち株式会社Crabgrassは、財務データAPI「ZENITH Code」を開発・提供しています。本記事は情報の読み方を説明するもので、特定の金融商品の売買を勧めるものではありません。