【ITニュース解説】The same SEC filing has two acceptance times, depending on which EDGAR file you read

米国証券取引委員会（SEC）は、企業の財務情報や事業活動に関する重要な開示書類を投資家や一般公開するための電子開示システム「EDGAR（エドガー）」を提供している。EDGARは、上場企業が四半期報告書や年次報告書、株主総会に関する書類など、多岐にわたる情報を提出する場所であり、これらの情報は透明性の確保と公正な市場形成のために不可欠だ。

EDGARから提供される企業提出書類には、その書類がSECに受理された日時を示す「受理時間（acceptanceDateTime）」という情報が含まれる。この受理時間は、企業活動のタイミングを正確に把握する上で非常に重要だ。例えば、企業が好決算を発表したのが市場取引開始前か終了後かによって、その情報が株価に与える影響は大きく異なる。また、内部者取引の報告書（Form 4）がどの取引日に該当するか、あるいは特定のイベントが株価に与える影響を分析する「イベントスタディ」において、そのイベントの発生日を特定する際にも、正確な受理時間は不可欠なデータとなる。

しかし、EDGARから取得できるこの重要な「受理時間」に、データの一貫性に関する問題が発見された。同じ企業が提出した同じ書類であっても、その時間情報を取得する方法によって、異なる値が示されるという状況だ。具体的には、SECが提供するAPI（data.sec.gov/submissions/CIK##########.json）を通じて企業ごとの提出書類をまとめて取得した場合に得られるacceptanceDateTimeと、個別の提出書類のインデックスページ（.../{accession}-index.htm）に記載されている「Accepted」の時間との間でずれが生じることが確認された。

このずれは、主にタイムゾーンの解釈に関わるものだ。APIから提供される時間は「2026-07-14T14:30:38.000Z」のように、「Z」で示されるUTC（協定世界時）を基盤としている。一方、インデックスページに表示される時間は米国東部時間（US Eastern time）であり、これは書類自体のSGMLヘッダーに記載された時間と一致する。米国東部時間は、夏時間（Daylight Time）の期間はUTCより4時間遅く、標準時間（Standard Time）の期間はUTCより5時間遅くなる。

詳細な調査の結果、多くの企業において、APIから取得した受理時間がインデックスページの時間と合致しないことが判明した。そのずれのパターンは一貫しており、APIの時間がインデックスページの時間よりも正確に米国東部のオフセット分（夏時間なら+4時間、標準時間なら+5時間）だけ遅れている、つまり未来の時間を指している状態だった。例えば、JPMorganが米国東部時間の午前6時30分に受理された8-K報告書は、API上ではUTCの午後2時30分として記録されてしまう。これは、市場取引開始前ではなく、取引開始後の時間として誤って認識される可能性があることを意味する。

さらに複雑なことに、この不整合は一律に全ての企業で発生しているわけではない。調査対象の25社のうち、Microsoft（MSFT）やGoogle（GOOGL）など一部の企業ファイルでは、APIの時間が正しく表示されていた。しかし、Apple（AAPL）やNVIDIA（NVDA）、Amazon（AMZN）などのファイルでは、全ての提出書類で時間情報にずれが生じていた。

興味深い発見として、同じ書類でも、異なる種類のファイルから取得すると時間情報が異なる事例も確認された。例えば、Appleの取締役によるForm 4（内部者取引報告書）は、Apple自身の企業ファイルと、該当する取締役自身のファイルの両方に存在する。この場合、取締役自身のファイルから取得した時間は正しかったが、Appleの企業ファイルから取得した時間は、標準時間の時期であれば5時間遅れていた。

この問題の根本原因はまだ仮説の段階だが、EDGARのファイルがシステムによって再構築される際に、特定の処理が影響している可能性が考えられる。調査の結果、10月2日以前に受理された最新の書類を持つファイルは正しく、10月5日以降に受理された最新の書類を持つファイルはずれが生じていた。これは、10月初旬以降に再構築されたファイルに、余分なタイムゾーンオフセットが誤って適用されているためではないか、という推測がされている。

システムエンジニアとして、このようなデータの不整合は深刻な問題を引き起こす可能性がある。金融市場のデータは「時間」が極めて重要な要素であり、わずかな時間のずれが誤った分析結果や意思決定を招く危険性があるからだ。株取引の自動化システムや、経済指標の発表に合わせた高速取引システムなどでは、ミリ秒単位の正確性が求められることもある。

この問題に対処するためには、最も信頼性の高い情報源から受理時間を取得することが推奨される。具体的には、個別の提出書類のインデックスページ、あるいはそのSGMLヘッダーから直接時間情報を読み取ることが最も確実な方法となる。しかし、この方法は、全ての書類に対して個別にリクエストを送信する必要があるため、処理コストが増大するという欠点がある。

より効率的な解決策として、ファイルごとの「ずれ」を一度だけ測定し、その補正値を他の書類に適用する方法が提案されている。これは、特定の企業のファイル内で受理時間のずれが一貫しているという調査結果に基づいている。まず、特定のファイルから一つの書類を選び、そのAPIから取得した受理時間とインデックスページに記載された正確な時間を比較することで、そのファイルのずれの大きさを特定する。一度ずれのパターンが分かれば、そのファイル内の他の全ての書類のAPI時間に対して、同じ補正を適用することで正しい受理時間を導き出せる。記事では、Python言語を用いた具体的なコード例も示されており、これによりUTC表記のAPI時間から正しい現地時間（またはUTC）を計算し直すことが可能になる。

ただし、EDGARのファイルは再構築されるたびに時間情報の扱いが変わる可能性があるため、ファイルを再ダウンロードする際には、再度ずれのキャリブレーション（測定と補正）を行う必要がある。異なる季節（夏時間と標準時間）の二つの書類でキャリブレーションを行い、もしそれらの結果が一致しない場合は、個々の書類のインデックスページから時間を読み取るなど、より慎重なアプローチを取ることが賢明だ。

この事例は、公開APIから取得できるデータであっても、そのデータが「何を意味しているのか」「どのように処理されているのか」を深く理解し、常にデータの正確性を検証することの重要性を示している。特に、時間情報や位置情報など、外部要因によって解釈が変わる可能性のあるデータを取り扱う際には、複数の情報源を比較したり、システムの挙動を詳細に調査したりする姿勢が、信頼性の高いシステムを構築するために不可欠だと言える。