EDINET API v2の使い方：APIキー取得・書類一覧・書類取得の仕様と有報をAIで読む設計

同じ条件で保存した2本文の変更箇所を調べる場合は、JSON差分比較ツールで欠落・null・0・型変更を分けられます。配列の位置比較なので、docIDが同じ記録を手元で揃えてから比較します。6件の期待例と比較条件で読み方を確認してください。実APIの取得や訂正書類の自動判定は行いません。

金融庁の EDINET API（Version 2）は、書類一覧 API と書類取得 API の2本だけで構成されています。エンドポイントは単純ですが、日付単位でしか一覧が取れない、エラーでも HTTP 200 が返る、書類取得は Content-Type で成否を判定する、閲覧期間は10年で満了後は中身が消える、といった仕様を知らないままエージェントに渡すと必ず詰まります。

EDINET を含む5つの公共 API の比較は日本の公共データAPI 5選にあります。MCP サーバーにする設計は続編のEDINET APIをMCP化する設計で扱います。

有報以外の半期報告書・臨時報告書・大量保有報告書を取り出したい場合は、書類種別コード（docTypeCode）一覧と絞り込みを先に確認してください。変更報告書は大量保有報告書と同じ350で、様式コードで分けます。

APIキーなしで一覧処理の間違いを確かめる

気象庁・EDINETのJSON確認ツールで「EDINET」を選び、「架空サンプルを入れる」→「JSONを確認する」と進むと、書類一覧の読み取りをブラウザ内で試せます。実APIへ接続しないのでキーは不要です。認証キーや個人情報は貼り付けません。

サンプルは2件です。DEMO0001はフラグ上の取得不可条件なし、DEMO0002は取下げ済み・閲覧期間満了と表示され、親docIDにはDEMO0001が残ります。2件を表示できても、実際の書類取得や財務内容の評価に成功したことにはなりません。 企業名・書類番号・日時は学習用の架空値です。

本文エラーを試すなら、次のJSONを同じ画面へ貼り付けて確認します。

{"StatusCode":401,"message":"training fixture"}

期待する結果は「API本文のエラー 401」。HTTP 200を成功とみなして書類を保存する処理へ進ませません。試験用のJSONだけで確認でき、キーなしの実APIへ再送信する必要もありません。

この確認で分かるのは、本文のエラーと一覧のフラグです。成功時のZIP/PDFはJSONではないので、このツールでは読みません。APIへ進む手順は以下、AIへ渡す出典と権限の設計はEDINET MCPの設計案を参照してください。

保存済みの前後JSONで、取得を止める変更を再現する

まず本文の成功を確認し、その後に同じ書類のフラグを比べます。下の2本文は学習用に作った省略版の架空JSONです。実際の企業開示、過去の取得結果、APIレスポンス全項目を示したものではありません。APIキーは不要で、実APIへのリクエストも行いません。

変更前：

{
  "metadata": {"status":"200","parameter":{"date":"2026-10-01","type":"2"},"resultset":{"count":1},"processDateTime":"2026-10-01 18:00"},
  "results": [{"docID":"DEMO0001","csvFlag":"1","legalStatus":"1","withdrawalStatus":"0","disclosureStatus":"0"}]
}

変更後：

{
  "metadata": {"status":"200","parameter":{"date":"2026-10-01","type":"2"},"resultset":{"count":1},"processDateTime":"2026-10-01 18:30"},
  "results": [{"docID":"DEMO0001","csvFlag":"1","legalStatus":"1","withdrawalStatus":"0","disclosureStatus":"2"}]
}

1. JSON差分比較ツールへ変更前・変更後をそれぞれ貼り付け、「2つのJSONを比較する」を押します。
2. 追加0・削除0・型変更0・値変更2を確認します。場所は/metadata/processDateTimeと/results/0/disclosureStatusです。
3. 変更後だけを気象庁・EDINETのJSON確認ツールへ貼り付け、EDINETモードで確認します。DEMO0001に「不開示」が出ることを確かめます。

この読み方は、金融庁API仕様書の3-1-7（不開示）と3-3（本文ステータス）を2026年10月4日に再確認した範囲です。ツールは表示した違いの業務上の意味や、実際に取得できるかを保証しません。

差分の前にエラーが出たら

本文の401なら比較や書類保存へ進まず、手元のキーと設定を確認します。429なら自動再試行を止め、取得間隔と既存キャッシュを見直します。HTMLやJSON構文エラーなら、保存したファイルがログイン画面・エラーページ・コピー途中になっていないかを確認します。ZIP/PDFはこのJSONツールの対象外です。

実データを使う場合は、日付・type・取得時刻・docIDを手元で記録し、同じ書類を揃えてから比較してください。入力には認証キーや個人情報を含めないでください。欠落・null・0・配列の順番を区別する説明で、比較する前提を確認できます。

APIキーの取得手順（仕様書2-3章）

仕様書の第2章は、ほぼ全ページがアカウント作成と API キー発行の画面手順です。流れを要約します。

1. ポップアップ許可の事前設定。 ブラウザ（仕様書は Microsoft Edge で説明）のポップアップ許可サイトに https://api.edinet-fsa.go.jp を追加します。API キー発行画面・削除画面を開くのに必要とされています。
2. サインアップ。 EDINET 閲覧サイトの「ログイン」からサインイン画面を開き、「今すぐサインアップ」へ。メールアドレスと画像認証を入力すると @microsoftonline.com から確認コードが届きます。
3. パスワード設定。 12〜256文字、小文字・大文字・数字・記号のうち3種以上。
4. 多要素認証。 国コードと電話番号を登録し、SMS の確認コードか自動音声通話で確認します。
5. API キー発行。 サインイン後の API キー発行画面で連絡先（電話番号はハイフンなし）を登録すると、API キーが表示されます。「リクエストパラメータとして使用するため、忘れずに保存」と書かれています。

実際に https://api.edinet-fsa.go.jp/api/auth/index.aspx?mode=1 を開くと、Azure AD B2C（fsaedinetauth.b2clogin.com）の認可エンドポイントへ 302 リダイレクトされることは確認しました。手順が Microsoft の画面で説明されているのはこのためです。

書類一覧API：日付単位でしか引けない

GET https://api.edinet-fsa.go.jp/api/v2/documents.json?date=YYYY-MM-DD&type=2&Subscription-Key=<APIキー>

企業名や書類種別で検索するパラメータはありません。 「その日に提出処理された書類（と、その日に登録された書類情報修正・開示不開示区分の変更）」が1日分まとめて返るだけです。特定企業の有報を探すなら、提出日を推定して日付を回すか、日次で一覧を取り込んで自前のインデックスを持つ必要があります。

仕様書1-2-1 は「まず type=1 でメタデータの件数を見て、前回より増えていなければ後続処理をしない」という使い方を推奨しています。

メタデータ（type=1）

{
  "metadata": {
    "title": "提出された書類を把握するためのAPI",
    "parameter": { "date": "2023-04-03", "type": "1" },
    "resultset": { "count": 1 },
    "processDateTime": "2023-04-03 13:01",
    "status": "200",
    "message": "OK"
  }
}

（仕様書掲載のサンプル。日付・時刻は日本時間。）processDateTime は一覧の内容に変更がなくても更新されます。

提出書類一覧（type=2）の results 項目

results 配列の各要素は40項目です。仕様書3-1-2-2 から、設計で効く項目を抜き出します。

edinetCode 等の提出者情報は後から変わることがありますが、一覧上は変更されない（仕様書 *2）とされています。提出者の最新情報は EDINET コードリスト（https://disclosure2dl.edinet-fsa.go.jp/searchdocument/codelist/Edinetcode.zip）で別途照合します。

書類取得API：Content-Typeで成否を判定する

GET https://api.edinet-fsa.go.jp/api/v2/documents/<docID>?type=1&Subscription-Key=<APIキー>

ZIP の中身は type=1 なら PublicDoc（提出本文書）と AuditDoc（監査報告書）、type=5 なら XBRL_TO_CSV フォルダです。閲覧サイトの XBRL ダウンロードと違い、XbrlSearchDlInfo.csv は含まれません（その情報は書類一覧 API 側にあります）。

仕様書3-3 が明記している重要な癖がこれです。

• 成功時は Content-Type が application/octet-stream（ZIP）または application/pdf
• 失敗時は application/json; charset=utf-8 で、HTTP ステータスは 200 のまま

「HTTP 200 で何かバイナリが返ってきた」だけでは成否が分からないので、Content-Type を見てから保存します。

ステータスコード（実測した401を含む）

仕様書3-3 の一覧です。パラメータ誤り等のエラーは JSON 本文で返り、HTTP ステータスは 200 です。

400・404・500 は metadata.status / metadata.message に入り、401 と 429 は StatusCode と message のトップレベル形式です。キーなしで実際に叩いた結果がこちらです（2026-09-14）。

curl -s -w "HTTP %{http_code} type %{content_type}\n" \
  "https://api.edinet-fsa.go.jp/api/v2/documents.json?date=2026-09-11&type=2"

{"StatusCode": 401,"message": "Access denied due to invalid subscription key.Make sure to provide a valid key for an active subscription."}
HTTP 200 type application/json; charset=utf-8

無効なキー（Subscription-Key=invalid）でも、書類取得 API（documents/S1000001?type=1）でも同じ応答でした。仕様書のとおり HTTP は 200 で、判定は本文の StatusCode です。429 の具体的な閾値（何秒に何回か）は仕様書に数値の記載がなく、利用規約は「短時間における大量のアクセスその他のAPI機能の運用に支障を与える行為」を禁止し、負荷状況に応じたアクセス制限があり得るとしています。

更新タイミングとデータの範囲

閲覧期間は書類種別ごとに決まっています。

閲覧期間が満了すると、一覧上の当該書類は legalStatus=0 になり、seqNumber と docID 以外が null（区分・フラグは 0）に更新され、書類取得 API では取れなくなります。延長期間中（legalStatus=2）の書類は、法定縦覧期間内と同様には訂正されないことがある、とも注記されています。

保存した一覧から、次に読む書類を選ぶ

1社の有報・訂正有報を整理するなら、保存JSONから有報の取得候補を作るで配布するNode.jsコードを使えます。架空10行を候補2・除外5・要確認3へ分け、親docIDを残します。操作情報や未知のフラグを保留し、API接続や書類取得は行いません。

有価証券報告書をAIエージェントで読む設計

キーを取得した後に組む前提で、設計だけ先に固めておきます。

1. 一覧の取り込みは日次バッチにする

書類一覧 API は日付単位なので、エージェントが「トヨタの直近の有報」と聞かれてから日付を総当たりするのは現実的ではありません。日次で type=2 を取り込み、docID をキーに edinetCode・docTypeCode・periodEnd・submitDateTime・各フラグ・legalStatus をローカルに持ちます。当日分の再取得は seqNumber の差分で足ります。

2. 絞り込みはコードで行う

有報は docTypeCode=120、訂正有報は 130。企業は edinetCode または JCN で特定し、filerName の文字列一致では結ばない。withdrawalStatus=2（取り下げられた書類）と disclosureStatus=2（不開示中）は除外し、legalStatus=0 は取得不可として扱います。

3. 訂正の系譜を追う

訂正有価証券報告書は parentDocID に訂正前の書類の docID を持ちます（提出操作上設定されている場合）。「最新版らしい1件」を名前で選ばず、原本と訂正を parentDocID でつないで両方の docID を残します。

4. モデルに渡すのは ZIP ではなく抽出結果

type=5 の CSV（XBRL_TO_CSV）か type=1 の XBRL からサーバー側で必要な項目だけ抽出し、値・単位・期間・連結/個別の区別を揃えてから渡します。CSV のレイアウトは仕様書が「書類閲覧操作ガイド」を参照先にしており、本記事では確認していません。数値を扱う前にそのガイドで列定義を確認してください。

5. 出典は docID と submitDateTime

回答に付ける出典は、docID、docDescription、filerName、submitDateTime、periodStart〜periodEnd、取得日時のセットです。API キーは URL に載るため、Subscription-Key を含む URL をそのまま出典やログに残さない運用が必須です。出典オブジェクトの共通形はMCPのprovenance用outputSchema設計、3ツール構成の具体案はEDINET APIをMCP化する設計を参照してください。

まとめ

• EDINET API v2 は書類一覧（documents.json?date=）と書類取得（documents/{docID}?type=1〜5）の2本。認証はクエリの Subscription-Key
• API キーは閲覧サイトのサインアップ → メール確認 → パスワード → 多要素認証 → 連絡先登録で発行される（仕様書2-3章）
• 一覧は日付単位のみ。企業名検索はないので、日次で取り込んで docID をキーにローカルで持つ
• エラーでも HTTP 200。一覧は本文の status、書類取得は Content-Type で判定する。キーなしの401応答は実測済み
• 閲覧期間は有報で10年。満了すると legalStatus=0 になり docID 以外が null になる
• 本記事はキー未取得のため実行未検証。仕様と実際の挙動が異なる可能性がある

キーを取得して実測できた時点で、この記事の testedWith と各節を更新します。それまでは、仕様書の記載と、キーなしで返る401だけを事実として扱ってください。