企業の開示は何回「訂正」されるのか
企業が公表する情報は、一度出したら終わりではありません。配当予想は決算のたびに見直され、決算発表の予定日も直前で動くことがあります。J-Quants API の多くのエンドポイントは、こうした更新を古いレコードを消して上書きするのではなく、履歴として積み重ねる設計になっています。
この記事では、配当金情報（/fins/dividend）と決算発表予定日（/fins/earnings-date）という2つのエンドポイントを実際に集計し、「公表されたデータが、実際どのくらいの頻度で・どのくらいの幅で更新されているか」を事実として示します。訂正が多い・少ないという評価をする記事ではなく、「確報は一発で決まらない」という構造そのものと、その構造をパイプライン側でどう扱うかを整理する記事です。
本記事は、「配当データの一生 — 予想から確定まで」の続編（シリーズ第2回）です。前回は配当金情報（/fins/dividend）1エンドポイントについて、レコードの構造と日付フィールドの読み方を扱いました。StatCode・FRCode・CARefNo など各フィールドの詳細は前回の記事をご覧ください。
本記事の集計・図表は 2025年8月〜2026年6月（決算発表予定日は2024年1月〜2026年7月） 時点で取得したデータに基づきます。
訂正がデータにどう残るか（/fins/dividend の設計）
配当金情報（/fins/dividend）には、レコードごとに更新区分を表す StatCode（1: 新規、2: 訂正、3: 削除）と、予想か決定かを表す FRCode（1: 決定、2: 予想）が用意されています。
ポイントは、訂正（StatCode=2）が発生しても過去の予想レコードは削除されないことです。新しいレコードが追加され、古いレコードとの関係は CARefNo（訂正・削除の対象となった通知のリファレンスナンバー）で辿れるようになっています。
1つの配当（銘柄×配当基準日年月×配当種類）は、典型的には「予想（FRCode=2）の新規公表 → 必要に応じて何度か訂正 → 決定（FRCode=1）の新規公表」という流れをたどります。決定は新しい通知として発行されるため、予想の訂正の連なりとは別チェーンになります。
実測：配当予想はどのくらい訂正されるか
全市場・2025年8月〜2026年6月に公表された配当金情報の実レコード（24,006件）で、StatCode の内訳を集計しました。
新規が71.8%、訂正が27.4%、削除が0.8%でした。4件に1件強が「訂正」レコードだったことになります。
では、1つの配当予想は平均して何回訂正されるのでしょうか。同じ期間のデータで、予想（FRCode=2）の通知を「銘柄×配当基準日年月×配当種類」単位でグループ化し、グループ内の訂正回数を数えました（対象期間の端に位置するグループは、訂正の連なりが期間の外に続いている可能性があります）。
訂正0回のグループが57.8%、1回以上訂正されたグループが42.2%でした。2回以上の訂正も7.9%あります。一方、決定（FRCode=1）側の通知が訂正されるケースは3.2%と少なく、訂正の大半は予想の段階で起きていることが分かります。
決算のたびに公表の機会が生じる構造上、一定の割合で予想値の見直しが発生するという、市場全体の分布です。
実測：決算発表予定日はどのくらい・どれだけ変わるか
決算発表予定日（/fins/earnings-date）は、2026年8月にリリースしたばかりの新しいエンドポイントです。このエンドポイントの位置づけは次のとおりです。
決算発表予定日の変更が報告された場合、以前のデータは削除されず、修正後の予定日が新たなデータとして追加されます。
つまり配当情報と同じ考え方で、予定日の変更履歴がそのまま残る設計です。一度公表された予定日が後から「未定」に変更された場合は、SchDate（予定日）が空文字になります。
日次で公表された実データ（PublicationDate 2024-01〜2026-07、40,178件）を「銘柄×決算区分（1Q/2Q/3Q/FY）×決算期末」でチェーン化し、同一決算区分あたりの公表回数と、変更があった場合の変更幅（暦日差）を集計しました。
予定日が変更されたチェーンは全体の2.7%でした。ほとんどの決算区分では、最初に公表された予定日のまま決算発表を迎えています。変更があった場合の変更幅は、1〜7日以内が88.5%を占め、大きくずれるケースは限られていました。
配当予想（訂正率42.2%）と決算発表予定日（変更率2.7%）を比べると、更新の起きる頻度は情報の種類によって大きく異なります。これも「どちらが良い・悪い」という話ではなく、扱う情報の性質（金額の見積もり vs. 日付というスケジュール情報）によって更新の起きやすさが異なる、という構造の違いとして見るのが妥当です。
パイプライン設計上の含意
複数レコードが積み重なるデータを自分のパイプラインで扱う場合、次のような整理が必要になります（特定の実装手法を推奨するものではなく、考慮点の整理です）。
- 「最新の状態」を特定する必要がある場合は、StatCode・FRCode（/fins/dividend）や、同一キーでの公表日（/fins/earnings-date の PubDate）の並び順など、各エンドポイントの仕様で定義されたフィールドを使ってレコードを並べ、最後に公表されたものを採用する、という設計が考えられます。
- 「ある時点でどう見えていたか」を再現する必要がある場合（バックテストの環境で当時の予想値を使う、など）は、削除されないレコードの履歴そのものが情報になります。最新値だけを持つデータでは、この用途には対応できません。
- /fins/earnings-date は scheduled_date パラメータで「指定日を現在有効な発表予定日とする全銘柄」を取得できる一方、code 指定では変更履歴を含む全レコードが返る、という2つの取得モードがあります。用途（最新状態が欲しいか、履歴が欲しいか）に応じてパラメータを選ぶ必要があります。
履歴が残っていること自体は、データの不備ではなく、公表情報の性質（見直されるもの）をそのまま表現した設計だと整理できます。
再現方法（CLI）
この記事の集計は、以下のコマンドで再現できます（jquants CLI・要ログイン）。
ステップ1：配当金情報のフィールド名を確認
jquants schema fins.dividend
決算発表予定日（/fins/earnings-date）は公開したばかりのエンドポイントで、本記事作成時点では jquants schema の対応リストにまだ含めていません。フィールド名は末尾の仕様書リンクに掲載しています。
ステップ2：個別銘柄の配当履歴を取得
jquants fins dividend --code 86970
ステップ3：配当金情報のバルクダウンロード（全市場・月次）
jquants bulk get --endpoint fins/dividend --date 2026-06 --download
ステップ4：決算発表予定日のバルクダウンロード（全市場・月次）
jquants bulk get --endpoint fins/earnings-date --date 2026-06 --download
ステップ5：解凍してCSVを集計
gunzip fins_dividend_202606.csv.gz
gunzip fins_earnings-date_202606.csv.gz
解凍後のCSVを、配当金情報は「銘柄×配当基準日年月×配当種類×予想/決定」、決算発表予定日は「銘柄×決算区分×決算期末」等のキーでグルーピングし、StatCode の内訳や訂正回数・変更回数を数えます。本記事の集計は Python の csv.DictReader + collections.Counter で実装しました。
まとめ
- 配当金情報（/fins/dividend）は、新規71.8%・訂正27.4%・削除0.8%という内訳で、訂正レコードが一定量含まれています
- 配当予想（FRCode=2）は、42.2%が1回以上訂正されていました。決定（FRCode=1）側の訂正は3.2%と少なく、訂正の大半は予想段階で発生しています
- 決算発表予定日（/fins/earnings-date）は、変更があったチェーンが全体の2.7%で、変更があった場合も88.5%は1〜7日以内の変更幅でした
- どちらのエンドポイントも、古いレコードを削除せず履歴として積み重ねる設計です。「最新状態の特定」と「当時の見え方の再現」で、必要なレコードの絞り方が異なります
関連する仕様ページ
本記事の図は、過去の一時点のデータを集計して切り出したものです。最新のデータや、期間・条件を変えた集計は、J-Quants API で取得・再現できます（/fins/dividend は Premium プランで利用できるエンドポイントです。取得できるデータ・期間はプランにより異なります）。
この記事は J-Quants 公式 X（@jpx_JQuants）で公開した記事を、加筆・再構成したものです。