EDINETの書類種別コード一覧と絞り込み：docTypeCode・formCodeで半期報告書・大量保有報告書を分ける

EDINET API v2の書類一覧は日付単位でしか取れません。有価証券報告書だけ、大量保有報告書だけ、と絞り込むのは取得した後の処理です。有報ならdocTypeCode=120で済みますが、半期報告書・変更報告書・大量保有報告書は、書類種別コードだけで分けようとすると取りこぼしや取り違えが起きます。

この記事では、金融庁のAPI仕様書と様式コードリストからコード表を確認し、保存済みの一覧を書類種別で数えて目的別に絞るNode.jsコードを配布します。認証や一覧の取得手順はEDINET API v2の使い方を参照してください。

書類種別コード（docTypeCode）一覧

仕様書4-1の書類種別コードは42件です。docTypeCodeは3桁の文字列で出力されます（仕様書3-1-2-2）。よく使うものを先に並べます。

残りは、有価証券通知書・届出書・発行登録の系統（010〜110）、親会社等状況報告書（200・210）、公開買付の関連書類（260・280・300〜340）、基準日の届出書（370）・変更の届出書（380）です。全42件は配布コードのDOC_TYPESに、仕様書の名称のまま入れています。

様式コードリストでは、有価証券通知書や基準日の届出書・変更の届出書の開示区分は「非開示」です。一覧に種別が出ていても、書類本体を読める書類とは限りません。

docTypeCodeだけでは分けられない3つのケース

1. 変更報告書は350に含まれる

書類種別コードには「変更報告書」がありません。様式コードリストを見ると、変更報告書は府令コード060（株券等の大量保有の状況の開示に関する内閣府令）の様式で、書類種別は「大量保有報告書」です。

docTypeCode=350で絞ると、新規の大量保有報告書と変更報告書が混ざります。最初の大量保有報告書だけを見たいなら、formCodeまで見る必要があります。変更報告書のparentDocIDには、基となる大量保有報告書や変更報告書の書類管理番号が入ります。ただし仕様書4-1は「提出操作上設定されている場合のみ」としているので、空でもおかしいとは限りません。

2. 半期報告書には043A00がある

様式コードリストの改版履歴（2024年7月1日）には、四半期報告書制度の廃止に伴い、第四号の三様式に半期報告書043A00と訂正半期報告書043A01を新設したと記録されています。第四号の三様式は、それまで四半期報告書（043000）の様式番号でした。

半期報告書をdocTypeCode=160で絞れば、どちらの様式も拾えます。問題になるのは、様式コードを数値として扱う処理です。手元のNode.js v24.8.0で確かめました。

node -e "console.log(Number('043A00'), Number('050000'), parseInt('043A00',10))"

NaN 50000 43

Number()はNaN、parseInt()は途中で切って43を返し、エラーにはなりません。先頭の0も消えます。DBの列を整数型にしている場合や、表計算ソフトで開いた一覧を読み直す場合も同じ問題が起きます。docTypeCode・ordinanceCode・formCodeは文字列で保存し、文字列で比べます。

四半期報告書（140・150）は、過去のファイル日付の一覧に残ります。仕様書1-2-2では、2015年4月1日以後に提出された四半期報告書の閲覧期間は10年（縦覧3年＋延長7年）です。制度廃止後の日付で140が出るかどうかは、実データで確認していません。

3. 大量保有の対象会社はissuerEdinetCodeで引く

大量保有報告書の提出者は、株式を保有する側です。仕様書3-1-2-2によると、大量保有の発行会社のEDINETコードはissuerEdinetCodeに出力されます。公開買付の対象会社はsubjectEdinetCodeです。

有報と同じ感覚でedinetCodeを照合すると、対象会社についての大量保有報告書は1件も当たりません。下の実行例でも、この違いを確かめます。

保存済みの一覧を、書類種別で数えて絞る

配布するコードは、保存済みの書類一覧（type=2）を読み、書類種別ごとの件数を数え、目的別のプリセットで絞ります。外部通信や書類の取得は行いません。

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

2ファイルを同じフォルダに保存し、PowerShellで実行します。確認環境はWindowsのNode.js v24.8.0で、追加パッケージは要りません。

node .\edinet-doctype-filter.mjs .\edinet-doctype-demo.json

以下はすべて、2026年10月5日に架空の12行を処理した出力です。

{
  "fileDate": "2026-08-14",
  "total": 12,
  "byDocType": {
    "120 有価証券報告書": 1,
    "130 訂正有価証券報告書": 1,
    "135 確認書": 1,
    "160 半期報告書": 2,
    "170 訂正半期報告書": 1,
    "180 臨時報告書": 1,
    "350 大量保有報告書": 3,
    "360 訂正大量保有報告書": 1,
    "unknown": 1
  }
}

unknownの1行は、取り下げられた書類を模した行です。仕様書3-1-5によると、取り下げられた書類は日次更新で連番・書類管理番号・親書類管理番号・取下区分以外がnullになります。閲覧期間が満了した書類も、連番と書類管理番号以外がnullです（3-1-4）。種別がnullの行は、元が何の書類だったか一覧からは分かりません。 過去に保存した一覧と照合したいなら、docIDをキーに取得時点の記録を残しておく必要があります。

大量保有を発行会社で絞る

node .\edinet-doctype-filter.mjs .\edinet-doctype-demo.json --preset=large-holding --issuer=E90001

{
  "preset": "large-holding",
  "matched": 3,
  "rows": [
    { "docID": "DEMO1007", "form": "大量保有報告書（第一号様式）", "kind": "initial_report", "filerEdinetCode": "E90010", "issuerEdinetCode": "E90001" },
    { "docID": "DEMO1008", "form": "変更報告書（第一号様式）", "kind": "change_report", "filerEdinetCode": "E90011", "parentDocID": "DEMO0998" },
    { "docID": "DEMO1010", "form": "訂正報告書（大量保有報告書・変更報告書）", "kind": "correction", "parentDocID": "DEMO1008" }
  ]
}

（読みやすさのため、出力の一部の項目を省略しています。）350の3行のうち、発行会社がE90001の2行と訂正の1行が出ました。kindは様式コードから決めたもので、initial_reportが大量保有報告書、change_reportが変更報告書です。

同じ条件を提出者で絞ると0件になります。

node .\edinet-doctype-filter.mjs .\edinet-doctype-demo.json --preset=large-holding --filer=E90001

{ "preset": "large-holding", "matched": 0, "rows": [] }

半期報告書を絞る

node .\edinet-doctype-filter.mjs .\edinet-doctype-demo.json --preset=semiannual

043A00と050000の半期報告書2行と、043A01の訂正半期報告書1行、合わせて3行が出ます。periodは2026-01-01..2026-12-31のように、半期ではなく1年の範囲になっています。仕様書3-1-2-2の注記*3は、期間（periodStart・periodEnd）を「有価証券報告書及び半期報告書では事業年度」と定めているためです。架空データはこの記載に合わせて作りました。中間期の末日がperiodEndに入るとは限らないので、期末日で書類を判定する処理では注意してください。実データでの値は確認していません。

プリセットと注意フラグ

絞り込んだ各行には、次のnotesが付くことがあります。行を消さずに残し、判断は人に任せる作りです。

• form_code_not_in_table：コード内の様式表にない様式コード。様式コードリストで確認する
• period_missing：期間が必要な書類なのに期間が空
• withdrawal_status_not_0・disclosure_status_not_0・legal_status_not_viewable：取下げ・不開示・閲覧期間の区分が通常と違う

数値の120のように文字列でないコードは一致させず、要約ではunknownに数えます。エラー本文（StatusCode: 401など）、件数の不一致、type=1のメタデータだけのファイルは、0件と区別するため終了コード1で止まります。これらの挙動は9件の自動テストで確認しました。

自分の保存JSONで使うとき

node .\edinet-doctype-filter.mjs .\saved-list.json --preset=annual --filer=E00000

E00000は書式を示すための架空の値です。入力は手元のJSONファイル1個（上限2MiB）で、APIキーやキー付きURLを渡す欄はありません。結果は標準出力に出すだけで、入力ファイルを書き換えません。

絞り込んだ結果から、取下げや不開示、訂正の系譜まで含めて取得候補を決めるなら、保存JSONから有報の取得候補を作るのコードへ進めます。こちらは書類種別の仕分け、向こうは1社の有報を取得するかどうかの判定で、役割が違います。

このコードは書類を種別で分けるところまでです。書類本体の取得、XBRL・CSVの読み取り、保有割合などの値の解釈は行いません。投資判断や法的な判断の材料として使う場合は、元の書類を確認してください。

次に読む

• EDINET API v2の使い方：APIキー・書類一覧・書類取得の仕様
• 保存JSONから有報の取得候補を作る（訂正・取下げ・不開示の扱い）
• EDINET APIをMCP化する設計：検索・取得・抽出の3ツール
• ほかの公共データAPIを比べる

出典は金融庁「EDINET API仕様書 Version 2」2026年6月版の1-2-2、3-1-2-2、3-1-4、3-1-5、4-1と、別紙1 様式コードリストです（いずれも2026年10月5日確認）。コード表は今後の改版で変わることがあるので、使う前に配布ページで更新日を確かめてください。