EDINET活用記

公開: 2026-04-05

前回から続けて

前回(#01)ではEDINETのAPIでXBRLデータを取得できることを確認した。今回はそのデータを実際に大量処理してみて気づいたことを記録する。

処理を回してみると、想定外のことが次々と出てくるのが個人開発の醍醐味であり、つらいところでもある。

テストで数社分のデータを処理できたので、対象を広げて複数年度・複数企業の一括処理を試みた。

最初は1件ずつ順番に処理していたが、件数が増えると時間がかかりすぎる。試行錯誤の末、月単位のバッチ処理を並列で走らせる構成に落ち着いた。処理が途中で止まっても再開できるよう、進捗管理の仕組みも別途入れた。

しばらく回し続けて気づいたのは、エラーが発生するケースが思ったより多いことだ。

XBRLデータは企業が自分で作成して提出する。書式のルールはあるが、細かい部分では企業によって書き方にゆれがある。

よくあるパターンはこういったものだ。

属性の有無がばらばら 同じ科目でも、ある企業は属性を付けて記載し、別の企業は付けていない。パーサーが両方に対応しないと、どちらかのケースで正しく読み取れない。

数値のスケールが異なる 金額の単位が「円」の企業もあれば「百万円」「千円」の企業もある。単位情報をXBRLの属性から読み取って統一する処理が必要だった。ここを見落とすと、桁がまったく違う数値として集計されてしまう。

科目が存在しない 業種によっては、そもそもその科目が存在しない企業がある。売上原価がない、棚卸資産がないといったケースだ。欠損として扱うのか、ゼロとして扱うのかを判断しながら処理する必要がある。

エラーが出るたびにAIと一緒に原因を探った。エラーメッセージとその時のコードをAIに見せて「何が起きているか」を確認し、修正の方向性を相談する。

一人だとエラーの意味がわからなくて止まることがあるが、AIがいると「これはこういう意味」「こう直すと解消する可能性がある」とすぐに返ってくる。正解率100%ではないが、手がかりがもらえるだけでも全然違う。

特に役立ったのは、修正案を複数出してもらって選ぶという使い方だ。自分だけだと選択肢が思いつかない場面で、AIが「方法Aと方法B、どちらもある」と教えてくれると判断しやすい。

大量に処理すると、どうしても一定数の欠損や異常値が出る。すべてを完璧に処理しようとすると終わらない。

個人開発の現実として、8割〜9割が正しく処理できていれば十分と割り切ることにした。問題のあるデータはスキップして記録に残し、後から原因を確認できるようにしている。

完璧を目指すより、まず動くものを作って改善を続ける方が現実的だ。これはAIコーディングでも同じで、最初から完璧なコードを書こうとするより、動くコードを素早く作ってテストしながら直す進め方が合っていると感じている。

データを処理していると、企業や業種によって財務構造の個性が見えてくる。製造業とサービス業では資産構成がまったく違うし、同じ業種でも規模によって比率が異なる。

こういう発見が個人的な楽しさで、「もっとここを深掘りしたい」と思うと次の作業につながる。投資の文脈で使えそうなデータが見えてくることもある。

2016年度以降の複数年分の処理が進んでいる。全件を通すのにはまだ時間がかかるが、主要な財務項目は一定の精度で抽出できるようになってきた。

次はこのデータをどう見せるか、フロントエンドの設計に取り組む予定だ。