EDINETの保存JSONから有報の取得候補を作る：Node.jsで訂正・取下げ・不開示を分ける

EDINETの書類一覧を保存したら、次に必要なのは「どの行を取得処理へ渡すか」です。社名や書類名だけで絞ると、訂正、取下げ、不開示の操作情報まで混ぜてしまいます。

ここでは、1社の有価証券報告書・訂正有価証券報告書のうち、CSVがある書類の候補を作ります。ダウンロードできる自作コードを用意したので、APIキーのない状態でも架空データで同じ結果を再現できます。認証や一覧の取得手順はEDINET API v2の使い方を参照してください。

2ファイルを保存して実行する

次の2ファイルを同じフォルダへ保存します。ブラウザで内容が表示される場合は「名前を付けて保存」を使い、末尾に.txtを付けないでください。

• Node.jsコード：edinet-candidates.mjs
• 架空10行のJSON：edinet-candidates-demo.json
• コードの利用条件：MIT License

保存先のフォルダでPowerShellを開き、以下を実行します。確認環境はNode.js v24.8.0です。追加パッケージのインストールや環境変数の設定はありません。

node .\edinet-candidates.mjs .\edinet-candidates-demo.json E00000

E00000はこの教材の架空企業コードです。出力のcountsは次の値になります。

{
  "total": 10,
  "candidate": 2,
  "skip": 5,
  "review": 3
}

結果には一覧のfileDateとprocessDateTimeも残ります。後者は一覧に書かれた処理日時で、あなたがファイルを取得した日時ではありません。取得日時が必要なら、元ファイルと一緒に別途記録します。

10行を見比べて、選別理由を読む

rowsには候補だけでなく、対象外・要確認の行とreasonsも残ります。「少なくなったから成功」で終えず、期待した理由で外れたかを確認してください。

元のJSON全体を見たいときは公共データJSON確認ツールへ進めます。このCLIは取得候補を選ぶ教材なので、確認ツールとは判定目的が異なります。特に操作情報や同一docIDの重複を慎重に扱います。

公式の区分と、このコードの選別方針を分ける

金融庁の仕様書の3-1-2・4-1では、docTypeCodeの120が有報、130が訂正有報です。各区分・フラグは文字列で定義されています。"0"と数値の0を同じものとして補正しません。

候補にするのは、指定したedinetCodeに一致し、書類種別が120か130、csvFlag="1"、legalStatusが"1"または"2"の行です。さらに取下区分・不開示区分・書類情報修正区分がすべて"0"で、必要な識別子と期間・提出日時が揃うことを、この教材の条件にしています。

重要なのは、この条件から外れる行を、すべて「EDINETでは取得禁止」と解釈しないことです。対象外の会社やCSVのない書類は、このサンプルの目的から外しただけです。修正情報のある書類も、仕様上の取得不可を意味するとは限りません。条件を曖昧にしたまま自動処理へ渡さないため、reviewに残します。

判定の中心は、配布コードの次の部分です。reviewを優先するので、取下げと不明なフラグが同時に見つかった場合も要確認として残ります。

{
  decision: review.length ? 'review' : skip.length ? 'skip' : 'candidate',
  reasons: [...review, ...skip],
}

操作情報は書類の現在状態と同一視しない

仕様書3-1-6・3-1-7では、書類そのものと、その情報を修正・不開示にした操作情報を区別しています。たとえばdisclosureStatus="3"は不開示解除の情報です。値だけを見て新しい書類として採用せず、この教材では要確認にします。

同じdocIDが複数行ある場合も、すべてreviewにします。後に出た行で上書きする処理はありません。日別データをつなぐ実運用では、何日の一覧に含まれるどの操作なのかを整理する別の処理が必要です。

訂正報告書は原本を消す指示ではない

訂正書類は原本とは別のdocIDを持ちます。仕様書4-1によると、訂正書類のparentDocIDは提出操作上設定されている場合に出力されます。親IDがないだけで、公式データの不正や取得不可とは言えません。 このコードは対応関係を自動で推測しないため、その訂正行をcorrection_parent_requiredとして要確認にしています。

架空例ではDEMO0001とDEMO0002を両方残します。別の日の訂正がないこと、親書類が同じ入力に含まれること、訂正内容が財務値へ反映済みであることは調べていません。「最新の有報」を1本確定する用途には使えません。MCP化の設計記事へ進む場合も、この識別子を引き継ぎます。

自分の保存JSONを使うとき

手元に保存済みの書類一覧があれば、ファイル名と企業コードを差し替えます。これはコマンドの形式を示す例で、E00000は引き続き架空の値です。

node .\edinet-candidates.mjs .\saved-list.json E00000

入力はローカルのJSONファイル1個、上限2MiBです。type=2の一覧が必要です。ZIP・PDFやメタデータのみのtype=1は扱いません。標準出力へJSONを返すだけで、入力の上書きや書類の追加取得は行いません。必要ならPowerShell側で別名へ保存できます。

node .\edinet-candidates.mjs .\edinet-candidates-demo.json E00000 |
  Set-Content -Encoding utf8 .\candidates-demo-output.json

APIキー、Cookie、キー付きURLを渡す欄はありません。入力にある任意の文字列や企業名を結果へ丸ごと転記せず、固定した項目だけを出力します。生成した結果を社外へ共有してよいかどうかは、手元のデータの取扱い条件に従って判断してください。

0候補と、処理失敗を取り違えない

正常な空の一覧はtotal: 0で終わります。一方、JSONを読めなかったり一覧の前提が崩れたりした場合は、結果を出さず終了コード1で止まります。

同じ条件で保存した前後の本文を比べるならJSON差分比較ツールを使えます。ただし配列は位置で比べるので、先に同じdocIDの行を揃えてください。今回の候補一覧の2回分をそのまま比べて、訂正の系譜が確定するわけではありません。

検証した範囲と、次の工程

2026年10月5日に、配布コードと同じファイルをWindowsのNode.js v24.8.0で実行しました。架空10行の内訳に加え、重複docID、欠損・型違いのフラグ、延長期間、操作情報、親IDのない訂正、エラー本文、件数不一致、空の一覧、出力項目の限定、CLI、BOM付きJSON・容量上限、実在しない日付・時刻・逆転した期間を12件の自動テストで確認しています。

次の工程は、候補の識別子と保存時点を見直し、必要な書類を特定することです。書類取得、CSV展開、勘定科目の選別、訂正後の値の統合は別の処理です。今回の結果に売上高や利益の分析、投資判断は含まれません。

• APIキー・書類一覧・書類取得の仕様を読む
• 候補・取得・抽出を分けるMCPの設計へ
• 他の公共データAPIも比較する

出典は金融庁「EDINET API仕様書 Version 2」2026年6月版の3-1-2、3-1-5〜7、3-3、4-1です。仕様の参照と架空データの実行を分けて記録しており、認証付きAPIの動作を実測した記事ではありません。